5 ms·

If this actually works there has to be some huge, embarrassing vuln in Apple's Secure Enclave Processor on par with the "CTS Labs" AMD secure coprocessor hoopla

If this actually works there has to be some huge, embarrassing vuln in Apple's Secure Enclave Processor on par with the "CTS Labs" AMD secure coprocessor hoopla that hit the news just this week.[1][2] The SEP is supposed to enforce a time delay between passcode attempts to prevent this sort of brute forcing. The timer could be defeated in older models by cutting power at just the right time, but Apple's whitepaper says it's supposed to survive restarts now.[3] Based on the screenshots it looks like it can load custom firmware on the iPhone. That's bad. [1] https://www.anandtech.com/show/12525/security-researchers-publish-ryzen-flaws-gave-amd-24-hours-to-respond https://www.anandtech.com/show/12525/security-researchers-pu... [2] HN discussion: https://news.ycombinator.com/item?id=16597626 https://news.ycombinator.com/item?id=16597626 [3] p15: https://images.apple.com/business/docs/iOS_Security_Guide.pdf https://images.apple.com/business/docs/iOS_Security_Guide.pd...

Scaevolus 9y ago
It's worse, since this attack doesn't require root privileges to run!
- thisacctforreal 9y ago
  sure, but it does require physical access for at least a couple hours, up to multiple days, if you don't use a predictable pincode. And from what I gather it doesn't even threaten a passphrase.
  - abalone 9y ago
    It supposedly threatens 6 digit passcodes, the default that 99.9% of iOS users will use. And the whole point of a passcode is to protect against physical access.
dheera 9y ago
Time delays only provide a false sense of security. In theory I could always cut open the casing and just plug wires straight into the EMMC or whatever you have in there. Your time delay UI is useless if I just bypass your UI and wire straight into the hardware. Of course that's non-trivial EE work, but the point is it's possible, for someone with enough money and the right equipment. What would make it intractable is to ditch the idea that a 4 digit pin is protecting you from anything. There's simply not enough entropy in that. Time delays are useful protection when over a network. But not when the attacker has physical console access, e.g. to a phone. At that point proper cryptography and mathematics is the only good protection.
- jrockway 9y ago
  I mean, I don't think they're dumb enough to put unencrypted data out on busses that you can just probe. All the encryption is done inside the same package as the CPU; if you read the RAM or flash directly, you'll just get garbage because it's encrypted. https://www.arm.com/products/security-on-arm/trustzone https://www.arm.com/products/security-on-arm/trustzone is the generic version of this, no idea what exactly Apple is doing. Anyway, to break the encryption involves finding bugs in the software that runs in the secure zone (the same way you'd defeat a time delay in a networked application) or by opening up the CPU die and figuring it out with an electron microscope (perhaps while the CPU is running). Ultimately, software is going to be the productive attack vector. While the TrustZone docs emphasize "small" for the amount of code that runs in the secure zone, no programmer can ever do "small" on a deadline and so I wouldn't trust it to provide any actual security. But the hardware infrastructure is there to be pretty secure against any adversary that doesn't have a lot of time or money, if the programmers do their job correctly. (I don't trust it because of the time schedules involved for these SoCs. One or two a year, with a lifetime of maybe a couple years. Nobody is going to spend the money to do the hard work like looking for bugs just so that someone can't rip Netflix video feeds. The engineering work would be more expensive than whatever their contract with the DRM vendors says they have to pay if they get hacked, which is the only incentive to be secure... and I doubt Apple would sign one of those.
- greglindahl 9y ago
  One of the points of having a secure enclave is that it can enforce things like time delays. I doubt that the time delay in question is only enforced by the UI outside the enclave.
- abalone 9y ago
  You misunderstand the SEP. It contains an externally unreadable private key baked in at manufacturing time that encrypts protected data. Your "wires" would read garbage. The iOS security white paper is worth a read. Perhaps a nation-state actor could shave down the processor and read that key with a SEM or some crazy thing, but that's literally how far the design is supposed to have pushed iOS security. Which is what makes this hack so embarrassingly bad (if confirmed).
TazeTSchnitzel 9y ago
It seems like they don't have the exponential delays, but they do have delays. Why else would it take 3 days to unlock the phone if it has a 6-digit passcode? Apple's security paper says it would take more than 50 years to brute-force an alphanumeric 6-digit passcode at 80ms per iteration. I suspect that's still correct here (if “3 days or more” is for 6 numeric digits).
- TazeTSchnitzel 9y ago
  er, that should say 5 years, not 50. typo.
slededit 9y ago
If this new time delay is via an off-chip RC circuit (one of the few ways for a timer to work with the power off as the capacitor acts like a battery) then it could be defeated by changing the components. RC circuits can be made on chip, however large value resistors and capacitors are very expensive to place on-chip.

Scaevolus 9y ago

It's worse, since this attack doesn't require root privileges to run!

thisacctforreal 9y ago
sure, but it does require physical access for at least a couple hours, up to multiple days, if you don't use a predictable pincode. And from what I gather it doesn't even threaten a passphrase.
- abalone 9y ago
  It supposedly threatens 6 digit passcodes, the default that 99.9% of iOS users will use. And the whole point of a passcode is to protect against physical access.

dheera 9y ago

Time delays only provide a false sense of security. In theory I could always cut open the casing and just plug wires straight into the EMMC or whatever you have in there. Your time delay UI is useless if I just bypass your UI and wire straight into the hardware. Of course that's non-trivial EE work, but the point is it's possible, for someone with enough money and the right equipment. What would make it intractable is to ditch the idea that a 4 digit pin is protecting you from anything. There's simply not enough entropy in that. Time delays are useful protection when over a network. But not when the attacker has physical console access, e.g. to a phone. At that point proper cryptography and mathematics is the only good protection.

jrockway 9y ago
I mean, I don't think they're dumb enough to put unencrypted data out on busses that you can just probe. All the encryption is done inside the same package as the CPU; if you read the RAM or flash directly, you'll just get garbage because it's encrypted. https://www.arm.com/products/security-on-arm/trustzone https://www.arm.com/products/security-on-arm/trustzone is the generic version of this, no idea what exactly Apple is doing. Anyway, to break the encryption involves finding bugs in the software that runs in the secure zone (the same way you'd defeat a time delay in a networked application) or by opening up the CPU die and figuring it out with an electron microscope (perhaps while the CPU is running). Ultimately, software is going to be the productive attack vector. While the TrustZone docs emphasize "small" for the amount of code that runs in the secure zone, no programmer can ever do "small" on a deadline and so I wouldn't trust it to provide any actual security. But the hardware infrastructure is there to be pretty secure against any adversary that doesn't have a lot of time or money, if the programmers do their job correctly. (I don't trust it because of the time schedules involved for these SoCs. One or two a year, with a lifetime of maybe a couple years. Nobody is going to spend the money to do the hard work like looking for bugs just so that someone can't rip Netflix video feeds. The engineering work would be more expensive than whatever their contract with the DRM vendors says they have to pay if they get hacked, which is the only incentive to be secure... and I doubt Apple would sign one of those.
greglindahl 9y ago
One of the points of having a secure enclave is that it can enforce things like time delays. I doubt that the time delay in question is only enforced by the UI outside the enclave.
abalone 9y ago
You misunderstand the SEP. It contains an externally unreadable private key baked in at manufacturing time that encrypts protected data. Your "wires" would read garbage. The iOS security white paper is worth a read. Perhaps a nation-state actor could shave down the processor and read that key with a SEM or some crazy thing, but that's literally how far the design is supposed to have pushed iOS security. Which is what makes this hack so embarrassingly bad (if confirmed).

TazeTSchnitzel 9y ago

It seems like they don't have the exponential delays, but they do have delays. Why else would it take 3 days to unlock the phone if it has a 6-digit passcode? Apple's security paper says it would take more than 50 years to brute-force an alphanumeric 6-digit passcode at 80ms per iteration. I suspect that's still correct here (if “3 days or more” is for 6 numeric digits).

TazeTSchnitzel 9y ago
er, that should say 5 years, not 50. typo.

slededit 9y ago

If this new time delay is via an off-chip RC circuit (one of the few ways for a timer to work with the power off as the capacitor acts like a battery) then it could be defeated by changing the components. RC circuits can be made on chip, however large value resistors and capacitors are very expensive to place on-chip.