6 ms·

Probably useful to mention this in the comments here: this works for the 5c, but not the 6 and beyond, due to the addition of the Secure Enclave.

xt00 10y ago
So the secure enclave must have an embedded flash inside the processor that includes the pin code attempt counter -- meaning that writing to the external flash would not happen at all right?
- Sanddancer 10y ago
  From what Apple's released on how iPhone security works [1], it sounds like such keys are still written to external flash, just in a much more low-level way. So there may be a theoretical way to do this attack on a more recent iphone, but you'd have to do a lot more reverse engineering to figure out a few layers of undocumented proprietary protocols. [1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guide.pdf
  - gizmo686 10y ago
    From skimming the paper, : "Each Secure Enclave is provisioned during fabrication with its own UID (Unique ID) that is not accessible to other parts of the system and is not known to Apple. When the device starts up, an ephemeral key is created, entangled with its UID, and used to encrypt the Secure Enclave’s portion of the device’s memory space. Additionally, data that is saved to the file system by the Secure Enclave is encrypted with a key entangled with the UID and an anti-replay counter. " This sounds like the secure enclave chip has a secret key, and all of its uses of external memory are encrypted using said key. This sounds like one would either need to break the crypto system itself, or compromise the secure enclave co-processor.
    - firebones 10y ago
      How would one provision a secure enclave at fabrication time? What does that even mean?
      - xt00 10y ago
        Most likely it's a fuse type thing. It literally is a one time programmable fuse that is set by some subroutine. Basically you execute that function and bam you get back some key that says that it worked. You try to execute again and the fuses have already been set and the key is the same. Many ICs have built in one time programmable memories or fuses to be used during provisioning. Such as to set a MAC address on a Ethernet chip or wifi chip. It's literally burned into the chip in the factory and cannot be changed. It's a one time thing and does not change after reboot or anything.
      - rtpg 10y ago
        In chip manufacturing, there's a way to make a "random" pattern on a chip, unknown even to the manufacturer. So a part of the SoC is random, but can be read by other parts. That becomes the random ID. Imagine it like taking that piece of paper to give lottery numbers, throwing a couple darts on it, and then using that as the ID. Except the dart throwing happens in a way where you can't actually control/see the result during manufacturing. There's a term for this that eludes me.
        shabble 10y ago
        I'm curious what this process would be. My understanding was they'd typically have a small section of write-once fuses/PROM, and then some final process step to permanently program an ID into that area. That would mean the process to do so could possibly be recorded (or compromised), so I'm interested if there's a fabrication technique to reliably create random ROM sections. Do you have any more info?
        rtpg 10y ago
        https://en.m.wikipedia.org/wiki/Physical_unclonable_function https://en.m.wikipedia.org/wiki/Physical_unclonable_function it's called a physically unclonable function. The page is a bit obtuse, honestly I might have misunderstood a part of it.
  - xt00 10y ago
    The basic issue with using an external memory is that you simply become a man in the middle and control what is happening the whole way. There is not some sort of magic "more low level way" available on flash ICs.. The flash device on any apple device can be fully emulated either by an FPGA or a special high speed setup that still has the flash IC attached to it. When the magic command comes in to write the value to store how many attempts have occurred you respond as if the value was written correctly but then don't actually write it. Assuming the block of memory that is being written is encoded with a particular checksum that is also including some checksum that was calculated on the local copy inside the secure enclave then the main problem we would run into would be that the secure enclave may store some value like that checksum in its memory locally in flash. So when you go to attempt the next passcode it reads the previous checksum from the external nand flash IC and sees that you are using the correct checksum, but the value you stored for the attempt counter does not sum up properly. So basically you would also need to reverse engineer their checksum process to screw up some other value to make the checksum add up properly. The alternative as I suggested is to just store the actual attempt counter in the internal flash of the main A8 or whatever processor in the secure enclave. That way it forces the hacker to have to be a much more sophisticated user and take more risk to damage the chip to basically completely remove the chip, FIB it to cut down to the proper layer--if apple was smart they would bury the flash for the secure enclave under a bunch of important metal routing that would be super difficult to get around, then even a super sophisticated nation state actor would be highly challenged to do this modification.. Desoldering the flash IC and soldering in an interposer that has an FPC that connects to an FPGA that is purpose built for this setup could be done in like 30 mins or less. So if apple wants to make this scheme difficult to do, they should embed it deep inside the main processor and not rely upon the external flash at all.
    - Relys 10y ago
      Great description. You remind me of Joe Grand (L0pht Heavy Industries), Joe FitzPatrick (NSAPlayset), Hector Martin (fail0verflow) and Micah Scott (scanlime). All are brilliant Electric Engineers with a security background. Do you have an EE degree too? Anyways, thanks for the detailed explanation. :)
  - abalone 10y ago
    No, it does not rely on "undocumented proprietary protocols". The document you link clearly states that external flash contents are encrypted with a key that resides in the secure enclave, entangled with the user passcode. Furthermore the secure enclave has guards against brute forcing the passcode with an escalating time delay. What's different in more recent phones (>=A7 processor) is the secure enclave enforces that time delay, as opposed to the operating system, which is the reason why this brute force attack works on the 5c/A6.
- amluto 10y ago
  There's a feature provided by a fair number of flash chips called a "Replay Protected Memory Block" or RPMB. The idea is that you provision your flash chip with a secret shared only with the secure enclave (presumably stored on fuses in the secure enclave) and then you can use that key to read and write a small block of storage on the flash chip. It's "replay protected" because the crypto prevents an attacker from replaying old contents of the chip back to the secure element. If Intel ever stopped mucking around with SGX licensing policy, SGX + RPMB would be a really nice combination on laptops.
sigmar 10y ago
This is contradicted within the linked research: >The same approach could be applied to the newer models of iPhone. The same type of LGA60 NAND chips are used up to the iPhone 6 Plus. Any attacker with sufficient technical skills could repeat the experiments. Newer iPhones will require more sophisticated equipment and FPGA test board
- xmodem 10y ago
  The iOS security guide would appear to contradict this: https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guide.pdf > On devices with an A7 or later A-series processor, the delays are enforced by the Secure Enclave. If the device is restarted during a timed delay, the delay is still enforced, with the timer starting over for the current period. This is not super specific, but would imply that the secure enclave has its own storage.
- abalone 10y ago
  They are wrong. The A7 added a hardware passcode attempt counter that would defeat their method.[1] And that's not all. With the introduction of Touch ID, Apple has shifted to 6 digit passcodes as the standard. The authors note that their method would not work so well, even if they had infinite time: "Given six attempts per each rewrite this method would require at most 1667 rewrites to find a 4-digit passcode. For a 6-digit passcode it would require over 160 thousand rewrites and will very likely damage the Flash memory storage." If you want to decrypt the modern iPhone you'd probably have to try to poke inside of the secure enclave with an SEM or something. And then you're getting into the realm of hardware defenses against this kind of intrusion, like physical self-destruction when probed.. not sure if Apple's doing anything there but it's crazy stuff. [1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guide.pdf (page 12)
  - rasz_pl 10y ago
    You dont need to constantly rewrite flash, you can emulate it with fpga. In-Circuit eprom emulation is old as a rock.
xmodem 10y ago
The secure enclave was added in the 5S

xt00 10y ago

So the secure enclave must have an embedded flash inside the processor that includes the pin code attempt counter -- meaning that writing to the external flash would not happen at all right?

Sanddancer 10y ago
From what Apple's released on how iPhone security works [1], it sounds like such keys are still written to external flash, just in a much more low-level way. So there may be a theoretical way to do this attack on a more recent iphone, but you'd have to do a lot more reverse engineering to figure out a few layers of undocumented proprietary protocols. [1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guide.pdf
- gizmo686 10y ago
  From skimming the paper, : "Each Secure Enclave is provisioned during fabrication with its own UID (Unique ID) that is not accessible to other parts of the system and is not known to Apple. When the device starts up, an ephemeral key is created, entangled with its UID, and used to encrypt the Secure Enclave’s portion of the device’s memory space. Additionally, data that is saved to the file system by the Secure Enclave is encrypted with a key entangled with the UID and an anti-replay counter. " This sounds like the secure enclave chip has a secret key, and all of its uses of external memory are encrypted using said key. This sounds like one would either need to break the crypto system itself, or compromise the secure enclave co-processor.
  - firebones 10y ago
    How would one provision a secure enclave at fabrication time? What does that even mean?
    - xt00 10y ago
      Most likely it's a fuse type thing. It literally is a one time programmable fuse that is set by some subroutine. Basically you execute that function and bam you get back some key that says that it worked. You try to execute again and the fuses have already been set and the key is the same. Many ICs have built in one time programmable memories or fuses to be used during provisioning. Such as to set a MAC address on a Ethernet chip or wifi chip. It's literally burned into the chip in the factory and cannot be changed. It's a one time thing and does not change after reboot or anything.
    - rtpg 10y ago
      In chip manufacturing, there's a way to make a "random" pattern on a chip, unknown even to the manufacturer. So a part of the SoC is random, but can be read by other parts. That becomes the random ID. Imagine it like taking that piece of paper to give lottery numbers, throwing a couple darts on it, and then using that as the ID. Except the dart throwing happens in a way where you can't actually control/see the result during manufacturing. There's a term for this that eludes me.
      - shabble 10y ago
        I'm curious what this process would be. My understanding was they'd typically have a small section of write-once fuses/PROM, and then some final process step to permanently program an ID into that area. That would mean the process to do so could possibly be recorded (or compromised), so I'm interested if there's a fabrication technique to reliably create random ROM sections. Do you have any more info?
        rtpg 10y ago
        https://en.m.wikipedia.org/wiki/Physical_unclonable_function https://en.m.wikipedia.org/wiki/Physical_unclonable_function it's called a physically unclonable function. The page is a bit obtuse, honestly I might have misunderstood a part of it.
- xt00 10y ago
  The basic issue with using an external memory is that you simply become a man in the middle and control what is happening the whole way. There is not some sort of magic "more low level way" available on flash ICs.. The flash device on any apple device can be fully emulated either by an FPGA or a special high speed setup that still has the flash IC attached to it. When the magic command comes in to write the value to store how many attempts have occurred you respond as if the value was written correctly but then don't actually write it. Assuming the block of memory that is being written is encoded with a particular checksum that is also including some checksum that was calculated on the local copy inside the secure enclave then the main problem we would run into would be that the secure enclave may store some value like that checksum in its memory locally in flash. So when you go to attempt the next passcode it reads the previous checksum from the external nand flash IC and sees that you are using the correct checksum, but the value you stored for the attempt counter does not sum up properly. So basically you would also need to reverse engineer their checksum process to screw up some other value to make the checksum add up properly. The alternative as I suggested is to just store the actual attempt counter in the internal flash of the main A8 or whatever processor in the secure enclave. That way it forces the hacker to have to be a much more sophisticated user and take more risk to damage the chip to basically completely remove the chip, FIB it to cut down to the proper layer--if apple was smart they would bury the flash for the secure enclave under a bunch of important metal routing that would be super difficult to get around, then even a super sophisticated nation state actor would be highly challenged to do this modification.. Desoldering the flash IC and soldering in an interposer that has an FPC that connects to an FPGA that is purpose built for this setup could be done in like 30 mins or less. So if apple wants to make this scheme difficult to do, they should embed it deep inside the main processor and not rely upon the external flash at all.
  - Relys 10y ago
    Great description. You remind me of Joe Grand (L0pht Heavy Industries), Joe FitzPatrick (NSAPlayset), Hector Martin (fail0verflow) and Micah Scott (scanlime). All are brilliant Electric Engineers with a security background. Do you have an EE degree too? Anyways, thanks for the detailed explanation. :)
- abalone 10y ago
  No, it does not rely on "undocumented proprietary protocols". The document you link clearly states that external flash contents are encrypted with a key that resides in the secure enclave, entangled with the user passcode. Furthermore the secure enclave has guards against brute forcing the passcode with an escalating time delay. What's different in more recent phones (>=A7 processor) is the secure enclave enforces that time delay, as opposed to the operating system, which is the reason why this brute force attack works on the 5c/A6.
amluto 10y ago
There's a feature provided by a fair number of flash chips called a "Replay Protected Memory Block" or RPMB. The idea is that you provision your flash chip with a secret shared only with the secure enclave (presumably stored on fuses in the secure enclave) and then you can use that key to read and write a small block of storage on the flash chip. It's "replay protected" because the crypto prevents an attacker from replaying old contents of the chip back to the secure element. If Intel ever stopped mucking around with SGX licensing policy, SGX + RPMB would be a really nice combination on laptops.

sigmar 10y ago

This is contradicted within the linked research: >The same approach could be applied to the newer models of iPhone. The same type of LGA60 NAND chips are used up to the iPhone 6 Plus. Any attacker with sufficient technical skills could repeat the experiments. Newer iPhones will require more sophisticated equipment and FPGA test board

xmodem 10y ago
The iOS security guide would appear to contradict this: https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guide.pdf > On devices with an A7 or later A-series processor, the delays are enforced by the Secure Enclave. If the device is restarted during a timed delay, the delay is still enforced, with the timer starting over for the current period. This is not super specific, but would imply that the secure enclave has its own storage.
abalone 10y ago
They are wrong. The A7 added a hardware passcode attempt counter that would defeat their method.[1] And that's not all. With the introduction of Touch ID, Apple has shifted to 6 digit passcodes as the standard. The authors note that their method would not work so well, even if they had infinite time: "Given six attempts per each rewrite this method would require at most 1667 rewrites to find a 4-digit passcode. For a 6-digit passcode it would require over 160 thousand rewrites and will very likely damage the Flash memory storage." If you want to decrypt the modern iPhone you'd probably have to try to poke inside of the secure enclave with an SEM or something. And then you're getting into the realm of hardware defenses against this kind of intrusion, like physical self-destruction when probed.. not sure if Apple's doing anything there but it's crazy stuff. [1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guide.pdf (page 12)
- rasz_pl 10y ago
  You dont need to constantly rewrite flash, you can emulate it with fpga. In-Circuit eprom emulation is old as a rock.

xmodem 10y ago

The secure enclave was added in the 5S