Hacker News Reader

Comment by RexRollman | Hacker News Reader

This whole thing makes me very suspicious of Apple's and Microsoft's whole disk encryption technologies. I can't help but wonder if back doors have been inserted into the products.

View on HN

Not impossible, but some smart people have been looking, at least for Apple's FileVault 2:

http://www.schneier.com/blog/archives/2012/08/an_analysis_of...

Paper here:

http://eprint.iacr.org/2012/374.pdf

Currently, there seem to be three vectors:

1) Weak passwords

2) If you opt-in to store a recovery key with Apple

3) If attacker has physical access to machine, and machine is powered on (direct memory access via Thunderbolt or Firewire) (Edit: seems like this is not the case, see below)

But no backdoor has been found (yet!)

> 3) If attacker has physical access to machine, and machine is powered on (direct memory access via Thunderbolt or Firewire)

I'm curious if this could be addressed with software protections somehow? Something that triggers memory wipes and automatic shutdowns?

http://www.intel.com/content/www/us/en/architecture-and-tech...

Though that specifically obviously requires hardware.

It seems that only protects against "pre-launch software" and BIOS level stuff. The scenario in question is for a live system where the disk is mounted and decrypted, with the OS running.

FileVault 2 is supposed to be secure against this* when the machine is powered on and locked or sleeping.

* Source http://security.stackexchange.com/questions/18720/how-secure...

Interesting. Apparently LUKS/dmcrypt on Linux is also protected from DMA attacks (firewire/thunderbolt devices).

> If you enable LUKS root, DMA attack mitigation is also enabled(boot.initrd.luks.mitigateDMAAttacks ). It consists of blacklisting firewire drivers.

Edit: still at risk of the "Evil Maid Attack" http://www.aspecrypt.com/evil_maid_attack.html

    3) If attacker has physical access to machine, and
       machine is powered on (direct memory access via
       Thunderbolt or Firewire)

This may have changed, but turning on FileVault used to disable DMA in many situations (laptop had been suspended being a key one) until the user logged back in. Not that this isn't a vector, but it's actually a very narrow one; you basically need the person to already be logged in at the time you want to steal the keys.

Hmm, I didn't know that. It seems you may be right:

http://www.frameloss.org/wp-content/uploads/2011/09/Lion-Mem...

Though apparently there was a company offering a commercial solution for getting FileVault passwords using this method so...

http://privacycast.com/filevault-vulnerability-how-to-protec...

There's also a really interesting pdf from Apple containing more details on FileVault 2:

http://training.apple.com/pdf/WP_FileVault2.pdf

which suggests turning on firmware passwords to prevent DMA.

Take a look at Alex Ionescu's "Ninja's and Harry Potter" talk from NoSuchCon this year [1].

He specifically mentions he could access the FileVault key of a machine by having physical access, and discovered two secret keys (KPPW and KPST) one of which is enabled when the input buffer is "SpecialisRevelio" [2].

It's a very interesting deck to read through.

[1] http://www.nosuchcon.org/talks/D1_02_Alex_Ninjas_and_Harry_P... [2] http://harrypotter.wikia.com/wiki/Specialis_Revelio

That's really very interesting, and quite concerning. I saw that talk was only presented in May. Any new info since then?

Why not just a backdoor in the OS? I mean...if we're seriously considering that apple would put a backdoor into FileVault, why not just put one in the OS proper?

FileVault could be some hypothetical magic uncrackable encryption with a keyspace bigger than the known universe...and it would never matter if there was a backdoor in the OS.

Of course there are back doors, like the well known NSAKEY one [1] in Windows. Apple also seem to have backdoors into encryption on both Mac and iOS [2].

If you want your data to be reasonably secure against someone who casually steals it then they're fine but if you want to be secure against government employees, or even well connected corporations, then Apple & Microsoft solutions are not very useful.

[1] https://en.wikipedia.org/wiki/NSAKEY [2] http://news.cnet.com/8301-13578_3-57583843-38/apple-deluged-...

Regarding [2], it's not clear yet what Apple does here: it looks like they bruteforce the iPhones when requested by the relevant authorities (possibly using a custom bootrom) and specifically not via a backdoor. If there was a backdoor, presumably Apple wouldn't have a backlog of requests[3]. Though no one really knows, and presumably it's always possible Apple will intentionally compromise their security in future if they get tired of having to bruteforce all these phones.

[3] http://www.informationweek.com/security/encryption/apple-iph...

This reminds me about something one of my teacher (a very stallman-like guy in his views) told us about encase. It's an (apparently) fairly common suite of tools used by law enforcement agencies around the world for forensic analysis. In the description of their decryption module (http://www.guidancesoftware.com/encase-forensic.htm#tab=2) they claim to be able to decrypt quite a few whole-disk encryption schemes. Now it's hard to imagine that they would put an outright lie on their website but there could be several explanations for that. I think the consensus among the students was that they were exaggerating quite a bit, and were only capable to do it upon some specific circumstances (weak passwords, setup errors, various cryptographic edge cases, etc). However the other obvious explanation was that some kind of backdoors were built among those schemes (you can notice the absence of common open source stuff like luks or truecrypt in the list) and that there's accords between some vendors and governmental agencies (via this software) to allow for access into their encryption schemes. I was fairly skeptical back then, but now I'm not so sure... There might be a combination of the two explanations. Someone well-versed into cryptography might be able to tell if some of those products have well-known vulnerabilities.

Edit : the site seems to have some difficulties, here's the google cache http://webcache.googleusercontent.com/search?q=cache:JZEtYXR... The description of the decryption suite is in the module tab.

Microsoft has a free program (for Law Enforcement) called COFFEE which, among other things, bypasses Bitlocker full-disk encryption.

You can find the Torrent at Wikileaks: https://wikileaks.org/wiki/Microsoft_COFEE_%28Computer_Onlin...

I have come across COFFEE before, its just a forensic tool. It doesn't do anything more than what 3rd party tools can do. It looks like a toolkit put together for investigators. Do you have any source to support that it can decrypt/bypass Bitlocker encryption? I couldn't find any information online.

[1] https://en.wikipedia.org/wiki/Computer_Online_Forensic_Evide...

The best part is when OS X asks you if you want to store the encryption 'recovery key' on Apple's servers ...

1) That's probably a perfectly reasonable option for my grandma. *

2) It provides Apple a fallback when some idiot loses 6 figures worth of IP. “We understand sir, you see, if you had chosen to backup your recovery key with us we would be able to help you”

* or would be, if the NSA wasn't spying on everything.

This is fine, since you have the option to decide. For most people it's okay to store the key on Apples servers. You are still protected if your computer is lost/stolen, for example.

And if you want to be safe from the government, just select "No".

Reply on news.ycombinator.com