6 ms·

Any device that relies on hiding secrets inside the silicon itself is subject to hacking. Several secure-enclave like chips have been hacked in the past by usin

Any device that relies on hiding secrets inside the silicon itself is subject to hacking. Several secure-enclave like chips have been hacked in the past by using electron microscopes and direct probes on the silicon. If BlackHat conference independent security researchers have the resources to pull this off, Apple and the NSA certainly can. Exfiltrating the Enclave UID could be done by various mechanisms at the chip level, especially if you have access to the actual HW design and can fab devices to help. 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)

quantumpotato_ 11y ago
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.
- johntb86 11y ago
  If you need to plug the phone into the cryptobox to decrypt it, they're going to be in one place anyway.
tptacek 11y ago
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.
- cromwellian 11y ago
  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 https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.pdf
  - tptacek 11y ago
    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.
inopinatus 11y ago
> 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.
gruez 11y ago
>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-with-the-fbi-court-order/ https://blog.trailofbits.com/2016/02/17/apple-can-comply-wit...
- cromwellian 11y ago
  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.
  - Piskvorrr 11y ago
    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).
  - Dylan16807 11y ago
the_watcher 11y ago
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"
rsync 11y ago
"(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.

quantumpotato_ 11y ago

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.

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

tptacek 11y ago

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.

cromwellian 11y ago
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 https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.pdf
- tptacek 11y ago
  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.

inopinatus 11y ago

> 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.

gruez 11y ago

>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-with-the-fbi-court-order/ https://blog.trailofbits.com/2016/02/17/apple-can-comply-wit...

cromwellian 11y ago
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.
- Piskvorrr 11y ago
  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).
- Dylan16807 11y ago

the_watcher 11y ago

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"

rsync 11y ago

"(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.