Tag Archives: encryption

Thoughts about the Apple vs FBI iPhone firmware case

Not trying to provide the full story here, just a few thoughts and directions as to security, privacy and civil rights. (for the backdrop – Apple’s Tim Cook letter explains it best: https://www.apple.com/customer-letter/)

From a technical perspective, Apple is fully capable to alleviating a lot of the barriers the FBI is currently facing with unlocking the phone (evidence) in question. It is an iPhone 5C, which does not have the enhanced security features implemented in iPhones from version 5S and above (security enclave – see Dan Guido’s technical writeup here: http://blog.trailofbits.com/2016/02/17/apple-can-comply-with-the-fbi-court-order/).

Additionally, when dealing with more modern versions, it is also feasible for Apple to provide updates to the security enclave firmware without erasing the content of the phone.

But from a legal perspective we are facing not only a slippery slope, but a cliff as someone eloquently noted on twitter. Abiding by a legal claim based on an archaic law (All Writs act – originally part of the Judiciary act of 1789) coupled with just as shaky probably cause claim, basically opens up the door for further requests that will build up on the precedent set here if Apple complies with the court’s order.
One can easily imagine how “national security” (see how well that worked out in the PATRIOT ACT) will be used to trump civil rights and provide access to anyone’s private information.

We have finally reached a time where technology, which was an easy crutch for law enforcement to rely on, is no longer there to enable spying (legal, or otherwise) on citizens. We are back to a time now where actual hard work needs to be done in order to act on suspicions and real investigations have to take place. Where HUMINT is back on the table, and law enforcement (and non-LE forces) have to step up their game, and again – do proper investigative work.

Security is obviously a passion for me, and supporting (and sometimes helping) it advance in order to provide everyone with privacy and comfort has been my ethics since I can remember myself dealing with it (technology, security, and privacy). So is national security and the pursuit of anything that threatens it, and I don’t need to show any credentials for either.

This is an interesting case, where these two allegedly face each other. But it’s a clear cut from where I’m standing. I’ve said it before, and I’ll say it again: Tim Cook and Apple drew a line in the sand. A very clear line. It is a critical time now to understand which side of the line everybody stands on. Smaller companies that lack Apple’s legal and market forces, which have bent over so far to similar “requests” from the government can find solace in a market leader drawing such a clear line. Large companies (I’m looking at you Google!) should also make their stand very clear – to support that line. Crossing that line means taking a step further towards being one of the regimes we protect ourselves from. Dark and dangerous ones, who do not value life, who treat people based on their social, financial, racial, gender, or belief standing differently. That’s not where or who we want to be.

Or at least I’d like to think so.

Update: Apparently Google is standing on the right side of the line:

Update 2 (2/20/16): Seems like the story is developing more rapidly, so figured I’d add a couple more elements here.

First – a good review from a forensic perspective on the FBI’s request puts the entire thing in even shadier legal standings if the data from the phone would be used in such a way: http://www.zdziarski.com/blog/?p=5645

Second – Apple today (2/20) updated that while the phone was in the FBI’s custody, it’s iCloud ID has been reset, basically eliminating one of the easier paths to recover data from the phone (http://abcnews.go.com/US/san-bernardino-shooters-apple-id-passcode-changed-government/story?id=37066070). This would have been a major oversight by the FBI, who would have failed to establish a clear “hands-off” policy on anything related to the terrorists assets – including it’s employer’s digitally controlled assets. Later in the day, and probably after getting under scrutiny for allegedly performing the iCloud account reset “on their own accord”, the San Bernardino County’s official account notified that it essentially tampered with the evidence based on the FBI’s request.

If this indeed is the case, we are looking at a much more problematic practice that exceeds incompetence, and moves into malpractice.

line-in-the-sand1

p.s. additional reading on this, from a couple of different authors who I wholeheartedly agree with:

http://www.macworld.com/article/3034355/ios/why-the-fbis-request-to-apple-will-affect-civil-rights-for-a-generation.html

And the EFF’s stand: https://www.eff.org/deeplinks/2016/02/eff-support-apple-encryption-battle

Mail Encryption for Android?

So, now that the saga with having a decent GPG mail client for Mac has been finally resolved (huge kudos to the guys at gpgtools!), it’s time to get some encryption love on an Android device.

I don’t know if you ever ended up searching for any decent GPG/PGP/SMIME (not that anyone uses SMIME) mail client for your Android, but the selection in the past couple of years has been pretty slim. Aside from the old K-9 (and paid for Kaiten), there isn’t really much out there. And these clients aren’t up to speed. Lacking PGP-Mime support means you can’t read most emails sent from a desktop machine (gpgtools uses OpenPGP mime format), add the fact that there isn’t much of an Exchange server support (no ActiveSync) and you are left wanting more (it was actually easier to download the encrypted message .asc, save it locally, fire up APG, decrypt it, save the plaintext locally, open it in a text editor, and delete all the clutter you just left on your sdcard. ugh.).

So, when I found _another_ mail app that claims to be able to do GPG, and Exchange, and isn’t a UI disaster, I had to give it a go.

Enter R2Mail2 (yeah, I know… marketing isn’t their strong suite). So far I have to say that installation has been a breeze (don’t forget to go through the weird process of managing the certificate store in the app, then adding your GPG keypair). And it works as advertised (!). OpenPGP mime support, encryption, decryption, signing, and yes – even Exchange (!!).

For what it’s worth – I’m giving it a try (meaning – the pay for version). Just giving my extra 2c to help you get on the PRISM “gotta-see-what-he’s-emailing-about” list 🙂

 

Apple, meet GPG, GPG, meet Apple.

Why is it so f&^#ing difficult to get this right? I’m looking at you “recently identified as the most valuable public company” – Apple!

The guys at GPGTools are doing some fantastic work in bringing a comprehensive GPG implementation into Mac OS X, and Apple seem to not only ignore the need for such an important tool, but consistently screw things up with Mail such that every new OS X update the  GPGMail plugin is rendered useless.

As a longtime supporter for gpgtools, and a longtime user of Apple products (sans the funky iPhone of course), I urge you – get this thing fixed.

And now – as I usually tell people who just rant and not offer any advice – how to somehow get things working:

The current solution for having a decent PGP experience on Mac OS X (and please – correct me if you have anything better/easier than this) is to do he following:

  1. Install Thunderbird. This is required as Apple’s Mail won’t work with any encryption plugins (that I know of) to handle PGP/GPG encrypted/signed emails.
  2. Install Enigmail. This is a “just works” plugin for Thunderbird to handle GPG. It simply just works. No hassle, great default config, recipient rules, the works…
  3. Install DavMail. This is a tricky one – it basically provides a local proxy for Microsoft’s OWA and “translates” it into IMAP/POP3/SMTP. The tricky part is that the application is not yet “signed” by the developer, and on Mac OS X 10.8.1 it simply won’t run in the default configuration (you’ll get a prompt to literally throw the application to the trash because it failed to start). Initially I just though botched download, but then realized that it’s got to do with Apple’s new gatekeeper… You’ll have to change the security settings to allow applications that were downloaded from _ANYWHERE_ to run (as opposed to application from the AppStore and “identified developers”): System Preferences -> Security and Privacy -> General.

It sounds like a kludge, and it is. But for now it works. At least until gpgtools manage to get enough support to have a version that works on Mountain Lion, or until Apple wakes up and start working with these guys and finally integrate it natively into the OS X Mail client.