* 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.
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.
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.
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.
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)
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.
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.
Well they certainly really want to crack the Secure Enclave, so maybe this case is moot.
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.
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.
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.
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...
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.
Physical defenses are not security through obscurity, and why you assuming they don't use known ciphers?
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).
Don't discuss your (or others') votes.
Don't interrupt the discussion to meta-discuss the scoring system.
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 mean, we're talking about threat models where chip-level doping has been shown as an attack. This just seems to be a variation on the same claims of copy protection tamper resistant dongles we've had forever. That someone builds a secure system that is premised on a secret being held in a tiny tamper-resistant piece, only the tamper resistance is eventually cracked.
It might even be the case that you don't even need to exfiltrate the UID from the Enclave, what the FBI needs to do is test a large number of PIN codes without triggering the backoff timer or wipe. But the wipe mechanism and backoff timer runs in the application processor, not on the enclave, and so it is succeptable to cracking attacks the same way much copy protection techniques are.
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 used to crack disk protection on the Commodore 64 and no matter how sophisticated the mechanism all I really needed to do was figure out one memory location to insert a NOP into, or change a BNE/BEQ branch destination, and I was done. Cracking often came down to mutating 1 or 2 bytes in the whole system.
(BTW, why the downvote? If you think I'm wrong, post a rebuttal)