[kyboren]

My impression of Apple's UID is that it's a physical unclonable function[1] whose output is directly connected to the key derivation circuitry. This means that there is, absent physically destructive attacks or side-channel vulnerabilities in the key derivation circuitry, no way to recover the UID/PUF output. Since PUFs typically get their values from random process variation, their values cannot be known before manufacturing. Since it can be used, in very well-defined operations with inherent rate limiting, but cannot be read out directly, there is no economically-feasible way to recover their values after manufacturing, either.

Of course, this is mostly speculation and would need some serious ChipWorks-style reverse engineering to determine if it's true, but that's my impression given what I've read from Apple's security documentation.

[1]: http://www.nxp.com/documents/other/75017366.pdf

[xnull]

> Since PUFs typically get their values from random process variation

How sure are we that this is the case, and how can we verify it? You can burn in whatever bits you want to the PUF. If there is a list, a product to UID mapping, a deterministic UID generation process or even PRNG that isn't strong enough the Secure Enclave falls.

[kyboren]

Well, again, I can't be sure, and you can't verify without reverse engineering the chip.

But that's not how PUFs work. The whole point of a "physical unclonable function" is that it's not just a set of bits that can be programmed to an arbitrary value; it's a part of a circuit which, based on physical characteristics of the apparatus, deterministically generates a response to a given challenge. The idea is that there is no such list for the PUF internal values--they're not controllable, and it would be extremely difficult to read their internal state without destroying the chip. Making lists would be very awkward: according to the Apple iOS Security Guide[1], the KDF takes 80ms per passcode attempt. So, generating a list of PUF outputs for all 10,000 4-digit numeric passcode would take Apple ~14 minutes--and it must be done on each device.

So, it's theoretically possible that Apple spends 14 minutes per device making a list of PUF outputs given all 4-digit numeric passcodes. However, a user who uses any other passcode would be completely unaffected (except having the search space reduced by 10,000), and I consider it highly unlikely that Apple can afford 14 minutes per device just for potential nefarious use given the volumes they produce.

Also, note that almost all other keys are 'tangled' with the output of the PUF, so a PRNG failure is not likely to cause predictable keys, depending on the failure mode and what PUF stimuli Apple records.

Of course, this is all a moot point, as none of this is verifiable (at least, to me and you).

[1]: https://www.apple.com/ipad/business/docs/iOS_Security_Feb14....

[xnull]

Actually, it does not look like the UID is a PUF - although it's a very interesting idea!

"Unique ID (UID) - A 256-bit AES key that’s burned into each processor at manufacture. It cannot be read by firmware or software, and is used only by the processor’s hardware AES engine. To obtain the actual key, an attacker would have to mount a highly sophisticated and expensive physical attack against the processor’s silicon. The UID is not related to any other identifier on the device including, but not limited to, the UDID." - https://www.apple.com/ipad/business/docs/iOS_Security_Feb14....

> "To obtain the actual key, an attacker would have to mount a highly sophisticated and expensive physical attack against the processor’s silicon."

This is not true if the UID is generated in some way that allows pilfering by the manufacturer.

> So, generating a list of PUF outputs for all 10,000 4-digit numeric passcode would take Apple ~14 minutes--and it must be done on each device.

The threat model here is not Apple, but the manufacturer. In this case the options I mentioned earlier would allow very fast attacks that could be launched selectively at target devices later on.

> Of course, this is all a moot point, as none of this is verifiable (at least, to me and you).

Definitely not verifiable of falsifiable by you or by me. I would suggest however that the claims and reputation of the Secure Enclave is not deserved. Finally, in crypto, skepticism is a feature.

[kyboren]

@xnull: interesting, my download of that file has slightly different text:

    The device’s unique ID (UID) and a device group ID (GID) are AES 256-bit keys *fused* into the application processor during manufacturing. No software or firmware can read them directly; they can see only the results of encryption or decryption operations performed using them. The UID is unique to each device and is not recorded by Apple or any of its suppliers.

(emphasis added)

That language, along with this gem later:

    The passcode is “tangled” with the device’s UID, so brute-force attempts must be performed on the device under attack

lead me to believe they're describing a PUF. By the way, can you save a local copy of that file? My SHA256 is b9d1f5290ebe56780af692e2b12037d6b7e085ef1f6050c1e27ea8426f94bfcc, what's yours?

>The threat model here is not Apple, but the manufacturer. In this case the options I mentioned earlier would allow very fast attacks that could be launched selectively at target devices later on.

Right, I understand. No matter what Apple says, you can't verify, so you can't trust.

>Definitely not verifiable of falsifiable by you or by me. I would suggest however that the claims and reputation of the Secure Enclave is not deserved. Finally, in crypto, skepticism is a feature.

Well, who am I to say whether Secure Enclave lives up to its hype? But definitely agreed about skepticism...

[xnull]

My digest agrees.

B9D1F5290EBE56780AF692E2B12037D6B7E085EF1F6050C1E27EA8426F94BFCC

I found the quote you've posted in my copy as well. The definition I selected was from the glossary at the bottom.

> "Tangled"

Seems to me to be referring to PBKDF2.