Hacker News Reader

Comment by d_theorist | Hacker News Reader

This is not really true. The secure enclave is a separate computer. It doesn't get software updates.

> possibly with the addition of a judicially compelled fingerprint scan or PIN brute force to get the encryption key out of whatever on-device escrow it's stored in

This is the whole problem. The keys are in the SE. You can't brute force the PIN because the SE rate-limits attempts (and that rate limiting cannot be overridden by an OS update because the SE is not run by the OS).

If you can get a fingerprint scan then all bets are obviously off, but then you don't need Apple at all.

View on HN

The device in question does not have a secure enclave. It's a 5c.

But it's more interesting to think about the case where the phone does have a secure enclave.

and yet it would be less interesting to consider if the password was a "six-character alphanumeric passcode with lowercase letters and numbers" because even if the software rate-limiting was disabled with a rogue firmware update, the PBKDF2 or similar iteration count makes brute-forcing impractical.

> A large iteration count is used to make each attempt slower. The iteration count is calibrated so that one attempt takes approximately 80 milliseconds. This means it would take more than 51⁄2 years to try all combinations of a six-character alphanumeric passcode with lowercase letters and numbers

(Page 12 of https://www.apple.com/business/docs/iOS_Security_Guide.pdf).

In that case, they could just bring the phone down to the morgue and unlock it with touch id.

Touch ID does not work after a reboot, to many attempts or a long of delay.

Additionally you don't have to use your thumb, so if you don't know what body part was used your out of luck.

If the phone is rebooted or if 48 hours have passed since the last passcode was entered, the touch ID can't be used to unlock the phone.

Touch ID requires the passcode after reboot or timeout. They'd need to do it very quickly.

Fingerprint scan really isn't enough though since after a restart, iPhones require the password to be entered.

Because fingerprints are not sufficient to generate / recover KEKs from.

Is that really true? The enclave's firmware is in ROM and non-upgradeable? I'd always assumed it got a signed blob like everything else does. Obviously it's possible to design a system like that, I just haven't seen it reported anywhere that it actually works like that.

Edit just to be clear: the requirement really is that the firmware be stored in a ROM somewhere, probably on the SoC. That's a lot of die space (code storing a fully crypto engine isn't small) to dedicate to this feature. Almost certainly what they did is put a bootstrap security engine in place that can validate external code loaded from storage. And if they did, that code can be swapped by the owner of the validation keys at will, breaking the security metaphor in question.

According to a former apple engineer that worked on this stuff, the enclave's firmware is indeed a signed blob:

https://twitter.com/JohnHedge/status/699882614212075520

The key thing would be for it to lose all stored keys on update when the current passphase has not been provided, and it sounds like that may not currently be the case.

Maybe in this case, Apple could comply, but a simple tweak would make it impossible in the future?

But "on update" isn't really the issue. If the code can be swapped underneath it, how does it know an "update" took place? Again you're in the situation where all of that process would have to be managed by hardware, when what is really happening is that the enclave is a computer running signed software that can be replaced.

Sure, but the signed firmware could be written to delete any stored keys when it accepts an update and the phone's passphrase has not been provided. That's assuming that it manages it's own update process, has the firmware securely stored within it's own die, etc. It's entirely possible ... but only Apple really knows.

I would not actually be shocked if they originally did wipe out stored info on firmware update, but had some issues with people updating their phone and losing everything, so they ifdef'd that particular bit out in the name of usability.

But... the firmware is stored in external storage. How does it even detect that an update was performed? You're saying that if the hardware had affirmative control over all the secure storage (e.g. the RPMB partitions on eMMC, etc...), then it could have been written to do this blanking.

Well, yeah. But then you'd have a system that couldn't be updated in the field without destroying the customer data (i.e. you'd have a secure boot implementation that couldn't receive bug fixes at all).

It's a chicken and egg problem. You're handling the problem of the "iPhone" not being a 100% snoop-and-tamper-proof device by positing the existence of an "interior" snoop-and-tamper-proof device. But that doesn't work, because it's turtles all the way down.

Ultimately you have to get to a situation where there is a piece of hardware (hardware on a single chip, even) making this determination in a way that has to be 100% right from the instant the devices go out the door. And that's not impossible, but it's asking too much, sorry. We're never going to get that.

It's certainly possible to design such a system with external firmware and still allow for secure updates.

The enclave would store (in secured storage) a hash of the last used firmware. Hardware would have a hash update capability, but this destroys all other stored information (i.e., keys) if used when the enclave is not currently in an unlocked state.

On boot, hardware verifies firmware signature as usual but also compares the firmware hash (already calculated for the signature check) to the stored value. If there is a mismatch, update the stored hash. Since the enclave is currently locked, the hardware clears the keys.

Since it's in hardware, you're correct that it would have to be 100% right, but that's quite feasible for a simple update mechanism (indeed, the most complicated bits are reused pieces from the signature check which already has this requirement).

Have it store the firmware itself encrypted with the UID. It never leaves the secure enclave so only the secure enclave itself could "sign" updates. You could still allow for recovery by providing a method to reset the UID.

Having the hardware require both the signature to pass as well as a valid PIN/fingerprint can't be that difficult.

Die space is cheap nowadays, especially stuff that doesn't need to be on all the time because of the death of Dennard scaling.

I'm not claiming it is in ROM or that it is not upgradeable if you are Apple and have physical access to the device. I'm not sure on that point. What I think must be the case is that Apple can't remotely upgrade the SE firmware as part of its iOS update mechanism. Although, to be perfectly honest, I have not seen this explicitly documented.

So... it sounds like you more or less agree with me. Apple can comply with this court order and open your secure device. We just differ as to whether they can do it over the air.

(FWIW: OTA firmware updates are routine in the industry. I've worked on such systems professionally, though not for Apple.)

The "bootstrap security engine" could store a hash of the blob in it's secure flash storage, and only update the hash if the user enters their pin, then reload the firmware blob. If the stored hash and blob hash ever don't match on boot, wipe the keys.

Reply on news.ycombinator.com