3 ms·
read section 'Hardware Security Features' here: https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guid
by chillaxtian 11y ago
read section 'Hardware Security Features' here: https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guide.pdf
- teekert 11y agoOk, so: "The UID allows data to be cryptographically tied to a particular device. For example, the key hierarchy protecting the file system includes the UID, so if the memory chips are physically moved from one device to another, the files are inaccessible. The UID is not related to any other identifier on the device." The secure enclave must still give it's UID under some circumstances? This still does not appear to be immune to hardware hacking. Moreover, this UID can also be brute forced imo, when the memory chip and secure enclave are physically separated. Whatever is needed to de-encrypt the data must be brute force-able, especially when the memory is separated from the wipe-all-data initiator which does not seem to be impossible if you know the chip design well enough?
- chillaxtian 11y ago"The device’s unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused (UID) or compiled (GID) into the application processor and Secure Enclave during manufacturing. No software or firmware can read them directly; they can see only the results of encryption or decryption operations performed by dedicated AES engines implemented in silicon using the UID or GID as a key." re: brute forcing. they are AES 256 bit keys. good luck.
- teekert 11y agoWhere is the reply button under your comment chillaxtian? Edit: hmm, now it suddenly appeared... How about disabling the wipe signal by cutting some interconnects in the silicon? Is the function by which the AES keys are calculated from the password really completely inaccessible?
- joosters 11y agoIf you are doubting the documents, then exactly what evidence will persuade you? Sounds like your mind is already made up.
- evanosaurus 11y agoUnless there is a bug in their hardware implementation of AES-CCM or (shudder) some sort of crazy disclosure vulnerability in the APIs they provide, there is (presumably) no way to get at the UID. Even if you were to decap the chip and get at the UID physically, you still aren't any better off as it derives the actual encryption key on boot from the UID. The Secure Enclave is essentially a hardware security module, in more general terms. The only thing that leaves its boundaries are the results of crypto operations, not the parameters that went into calculating them.
- teekert 11y agoThank you. So you mean to say that making an electron micrograph of this chip will not even reveal it's secrets? If the data persists after removal of power, some physical structure contains the data. Somewhere a hash of the fingerprint/password needs to be stored, then somewhere the function to compute that into an AES cipher needs to be stored. I'm going on and on about this because I see no way in which this problem is not down-boil-able to brute-forcing the password the user puts in. Actually Apple admits this much! They can build a work around! What stops the three-letter-agency from building it? There must at some point be a complex user entered passphrase if you want to be safe. This can be a fingerprint of course but there is always the 4 letter password/passphrase that is the weak point. I could be completely wrong, so far I'm not convinced I am.
- chillaxtian 11y agoon page 11 of the security white paper, there is a diagram illustrating the key hierarchy. i believe that 'Hardware Key' refers to the UID. if this is the case, then learning the UID + user passcode gives you the root keys, from which you can decrypt the remaining key hierarchy until you reach the decrypted files.