Hacker News Reader

A couple issues:

* Decapping and feature extraction even from simpler devices is error prone; you can destroy the device in the process. You only get one bite at the apple; you can't "image" the hardware and restore it later. Since the government is always targeting one specific phone, this is a real problem.

* There's no one byte you can write to bypass all the security on an iPhone, because (barring some unknown remanence effect) the protections come from crypto keys that are derived from user input.

* The phone is already using a serious KDF to derive keys, so given a strong passphrase, even if you extract the hardware key that's mixed in with passphrase, recovering the data protection key might still be difficult.

No, the chief protection against the PIN code hacking comes from the retry counter. The FBI doesn't need the crypto keys, it just needs the PIN code. So it needs to brute force about 10,000 PIN codes.

Any mechanism that prevents the application processor from either a) remembering it incremented the count b) corrupts the count or c) patches the logic that handles a retry count of 10, is sufficient to attack the phone.

Somewhere in the application processor, code like this is running:

if (numTries >= MAX_RETRY_ATTEMPTS) { wipe(); }

or

if (numTries >= MAX_RETRY_ATTEMPTS) { retryTime = retryTime * 2; }

Now there are two possibilities. Either there are redundant checks, or there aren't. If there aren't redundant checks, all you need to do is corrupt this code path or memory in a way that prevents it's execution, even if it is to crash the phone and trigger a reboot. Even with 5 minutes between crash reboot cycles, they could try all 10,000 pins in 34 days.

But you could also use more sophisticated attacks if you know where in RAM this state is stored. You couldn't need to de-capp the chip, you could just use local methods to flip the bits. The iPhone doesn't use ECC RAM, so there are a number of techniques you could use.

https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.pdf

You aren't limited to 10,000 possibilities. You can use an alphanumeric passphrase. The passphrase is run through PBKDF2 before being mixed with the device hardware key.

On phones after the 5C, nothing you can do with the AP helps you here; the 10-strikes rule is enforced by the SE, which is a separate piece of hardware. It's true that if you can flip bits in the SE, you can influence its behavior. But whatever you do to extract or set bits in SE needs to not cause the SE to freak out and wipe keys.

I'm speaking the case of the San Bernardino killers. Using strong alphanumeric pass phrases are anti-usability, the vast majority of people won't use them. Hell, the vast majority of people don't even have strong alphanumeric passwords on desktop services.

So it falls to either 2-factor or biometric to avoid PINs. Biometric of course has it's own problems.

Perhaps people should really carry around a Secure Enclave on a ring or something, and with a button to self-destruct it in case of emergency. (e.g. pinhole reset)

You only need the strong alphanumeric pass phrases on device startup, then you can use TouchID. I bought an iPhone 6 for exactly this reason (employer required strong passphrase, was too annoying to type in on the Android device I had at the time).

In a way, that's even worse. You're more likely to forget a complicated passphrase when you only have to type it in very seldomly.

You have to enter it every 48 hours.

Only if you don't unlock the phone in these 48 hours, no?

No, you have to enter it every 48 hours, regardless of what you have done with the phone in these 48 hours, and at every phone boot.

We can still imagine a state actor spending the megadollars to research a reliable chip-cloning process, to bring parallel brute-forcing within reach. I wonder if the NSA have been on a SEM/FIB equipment buying spree lately.

The ultimate way to defeat physical or software attacks is to exploit intrinsic properties of the universe, which suggests finding a mathematical and/or quantum structure impervious to both.

Your reply is the kind of comment I come to HN for - we've started off talking about mobile device security and ended up discussing unbreakable quantum encryption.

You seem to make the assumption that corrupting the secure enclave firmware is easy, or that its RAM is exposed of chip.

The entire point of an secure enclave is to completely enclose all the hardware and software needed to generate encryption keys in a single lump of silicon.

This means that all of its processing requirements (it's a complete co-processor) are on chip, it's RAM is on chip (not shared with it the main CPU, and probably has ECC), and it uses secure boot to cryptographically verify that it's firmware has not been tampered with before it starts executing. Additionally it may even be possible to update it bootloader in the future to prevent further updates without a passcode.

The end result means that attacking a secure element is very difficult. There are few, if any, exposure points that would allow you to fiddle with its internal state, and any attempts too should result in the secure element wiping stored keys, making further attacks a moot point.

I don't make that assumption, I worked on developing TPM modules myself in the 90s at research labs, and our prototypes had even more anti-tampering than so far revealed about Secure Enclave/Trustzone: we had micro-wire-meshes in the packaging to self-destruct on drilling or decapping, we had anti-ultrasonic and anti-TEMPEST shielding. I'm pretty familiar.

The point is that state actors have vast resources to pull off these attacks. The NSA intercepted hardware in the supply chain to implant attacks as documented by Snowden. Stuxnet was a super-elaborate attack on the physical resources of the Iranian nuclear program, which was obviously carried out with supply chain vendors like Siemens. Apple uses Samsung as a supplier, and the US government has very high level security arrangements with the South Koreans, so how do we know the chips haven't been compromised even before they arrive at Foxconn for assembly?

Here's an example of a TPM module being decapped and hacked at Blackhat: https://redmondmag.com/articles/2010/02/03/black-hat-enginee...

Attacks have been shown using silicon doping, security fuse cutting, etc.

If the NSA really wanted to crack the Secure Enclave, I have very little doubt about their ability to carry it out.

> If the NSA really wanted to crack the Secure Enclave, I have very little doubt about their ability to carry it out.

Well they certainly really want to crack the Secure Enclave, so maybe this case is moot.

The NSA cracking the Secure Enclave is not the same as the FBI cracking the Secure Enclave.

If the NSA can't crack the Secure Enclave in a terrorism case, it's not super useful that the NSA can crack the Secure Enclave.

Perhaps the NSA is savvy enough to know that a heroic effort isn't needed, and that the FBI is mostly looking to set precedent rather than find anything worth the cost and risk of chip-hacking.

Interesting stuff, cool post.

Seems to me when we are at a point were every time the NSA wants to get at some data, the have to start a heroic effort of attacking low level hardware, we are in a pretty good state in terms of device security.

>it's RAM is on chip (not shared with it the main CPU, and probably has ECC)

Apple's security guide would indicate otherwise, look on page 7. The secure enclave encrypts its portion of memory, but it isn't built into the secure enclave itself.

https://www.apple.com/business/docs/iOS_Security_Guide.pdf

Small nit but probably more like 1000000 codes since apple moved to 6-digit pins.

Is there anything preventing them from imaging the parts of the device that store data? The data in the image would be encrypted, of course, but wouldn't this give them essentially unlimited (or up to their budget) attempts at getting to the data?

It's encrypted against an effectively random 128 bit AES key. Unlimited time is not enough.

Unless there is weakness in the PRNG/RNG that creates the fused key in the secure enclave itself. Which is not out of question. I am not sure why FBI didn't ask apple politely how these keys are generated in the first place.

That seems excessively unlikely to me. The phone itself wouldn't have anything to seed a PRNG with, so the random number would need to come from an embedded hardware generator or a dedicated random number device in the factory, and both of those options would have huge amounts of engineering oversight.

The method I'm thinking of is:

1. Get a dump of the encrypted data.

2. Try to probe the hardware, potentially destroying it.

3. If the probe works, we're done. If not, put the encrypted data dump onto a fresh iPhone and repeat from step 2.

This way, you effectively get unlimited shots at an otherwise risky hardware probe.

If the encryption key didn't depend on the hardware this would work. Even the iPhone 5C that the recent court case is about relies on the hardware keeping a key secret and it doesn't contain the secure enclave. For an iPhone 5C, the encryption key is derived from the pin and a unique ID for the phone that the CPU itself can't read. The only thing that the application processor can do is perform some crypto instructions using the key, there isn't an operation that would just put the key into memory or a register that you can read from. Even if you have root and the phone in front of you with the password, there's nothing you can do short of decapping it to try to identify that key.

>You may not need to crack the OS, or even upload a new firmware. You just need to disable the mechanism that wipes the device and delays how many wrong tries you get. So for example, if you can manage to corrupt, or patch the part of the system that does that, then you can try thousands of PINs without worrying about triggering the timer or wipe, and without needing to upload a whole new firmware.

I disagree. The pin validation is done within the secure enclave. You can't do it outside the secure enclave because the pin is combined with a secret that is burned into the silicon of it. The secure enclave can and will enforce timeouts for repeated failures, as well as refuse to process any pin entries after too many attempts. Disabling the wipes or bypassing the timer won't do you any good when you only have a few attempts.

https://blog.trailofbits.com/2016/02/17/apple-can-comply-wit...

The state representing the number of attempts must be stored somewhere, and thus a determined adversary could eventually corrupt it.

Look, there's a big difference between trusting known ciphers that have been well studied by the world's top cryptographers, and a proprietary TPM chip that relies on security-through-obscurity.

The history of embedding secrets into black boxes is a history of them being broken. This isn't a theoretical concern, it's a very practical one.

Kerckhoff's principle should be adhered to if truly secure encryption is desired; alas, then all sorts of hard obstacles pop up (UX becomes a SPOF, most commonly - a secret always needs to be stored somewhere, if only in the user's head).

OTOH, the practical purpose of encryption is to remain unbroken for long enough, not to be completely unbreakable. As seen here, security-through-obscurity is practical enough in cases where user-obtained key material is too weak to provide enough protection using strong publicized crypto. In other words, it's a two-part key: one is in user's wetware, the other in phone's hardware (as per obXKCD, it's usually easier to attack the former).

The question is not whether a determined adversary could corrupt the counter. The question is whether they can corrupt the counter before they corrupt something else that causes total data loss.

Physical defenses are not security through obscurity, and why you assuming they don't use known ciphers?

"(BTW, why the downvote? If you think I'm wrong, post a rebuttal)"

Don't discuss your (or others') votes.

Don't interrupt the discussion to meta-discuss the scoring system.

Isn't the point of their efforts to make it so that Apple doesn't know how to get into the phones? If someone from BlackHat or Defcon can get in, the FBI should hire that person if they want access. The reason Apple is doing this is so that if they are served a court order, they can just say "we don't know how"

> You just need to disable the mechanism that wipes the device

Sure, to resist microscopic attacks, an IC must assert logical integrity to itself i.e. that the gates & wires are not compromised by a microscopic attack.

But just because you and I haven't imagined it, doesn't mean some kind of internal canary can't exist. Your naive code (below) of a counter might instead be based on quantum cryptography, or on intrinsic properties of a function or algorithm which if compromised the SE cannot function at all.

The existence of one-time password schemes like S/KEY gives me hope, since it is a sequence generator that simply doesn't function without input of the correct next value (technically the previous value from the hash function). S/KEY itself is not the answer (wrong UX and no intrinsically escalating timer), but I wanted to illustrate that you can generate a self-validating sequence without tracking integer position.

Apple apparently has a motive and the warchest for the R&D. If they're hiring cryptographers (has anyone checked?), they're acting on it.

I upvoted because I think you are absolutely correct. Better security could be had with a two-factor system -- plug the phone into a cryptobox to decrypt. Having everything in one place is vulnerable.

If you need to plug the phone into the cryptobox to decrypt it, they're going to be in one place anyway.