The Mac unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused (UID) or compiled (GID) into the Secure Enclave during manufacturing. No software or firmware can read the keys directly
It means that it can encrypt and decrypt data at the same speed as the interface/underlying storage. Encrypted storage doesn't slow down storage versus unencrypted usage.
More information on the GID/UID can be found in the iOS Security Guide:
With the exception of the Apple A8 and earlier SoCs, each Secure Enclave generates its own UID (Unique ID) during the manufacturing process. Because the UID is unique to each device and because it’s generated wholly within the Secure Enclave instead of in a manufacturing system outside of the device, the UID isn’t available for access or storage by Apple or any of its suppliers.
Software running on the Secure Enclave takes advantage of the UID to protect device-specific secrets. 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 isn’t related to any other identifier on the device.
The GID is common to all processors in a class of devices (for example, all devices using the Apple A8 processor).
The T2 is utilizing a physically unclonable function (PUF) and TRNG to create a public/private device key pair on die. At manufacturing, the T2 exposes the device public key to Apple, Apple signs with a group key posted to their CA. This is why they say they can revoke privileges via the CA. It's unclear to me whether the T2 regenerates this key pair each time it is requested, or whether it is encrypted and stored in memory. In the event the latter is the case, the encryption is being performed inside the secure enclave. "Secure enclave" used here is almost certainly distinct from Intel SGX, ARM TrustZone and the like. The page tables are protected. Row Hammer, Spectre, Meltdown and Foreshadow do not apply to something like T2, as the OS is considered trusted. The fundamental challenge that e.g. Intel's SGX has over this type of architecture is that a dedicated security co-processor doesn't need to maintain speculative execution behaviors necessitated by performance requirements, which expose numerous sidechannel attacks, and likely has minimal need to assume untrusted code operating in the T2 OS.
Indeed. Since Apple controls the full hardware and software stack, it's not surprising that they are making their own security chip without any of the ugly downsides of TPM (TPM has more complex interfaces and logic that try to cover a broader set of use cases than what Apple support). As another upside, they are also not reliant on any supplier code for the chip.
Comments
What does this mean?
Does anyone know the details underlying this?
It means that it can encrypt and decrypt data at the same speed as the interface/underlying storage. Encrypted storage doesn't slow down storage versus unencrypted usage.
More information on the GID/UID can be found in the iOS Security Guide:
https://www.apple.com/business/site/docs/iOS_Security_Guide....
[deleted]
The T2 is utilizing a physically unclonable function (PUF) and TRNG to create a public/private device key pair on die. At manufacturing, the T2 exposes the device public key to Apple, Apple signs with a group key posted to their CA. This is why they say they can revoke privileges via the CA. It's unclear to me whether the T2 regenerates this key pair each time it is requested, or whether it is encrypted and stored in memory. In the event the latter is the case, the encryption is being performed inside the secure enclave. "Secure enclave" used here is almost certainly distinct from Intel SGX, ARM TrustZone and the like. The page tables are protected. Row Hammer, Spectre, Meltdown and Foreshadow do not apply to something like T2, as the OS is considered trusted. The fundamental challenge that e.g. Intel's SGX has over this type of architecture is that a dedicated security co-processor doesn't need to maintain speculative execution behaviors necessitated by performance requirements, which expose numerous sidechannel attacks, and likely has minimal need to assume untrusted code operating in the T2 OS.
"line speed encrypted" ~= "encryption that goes as fast as the device would if not encrypting"
I don't have any insight into the details, but I'd guess that under the hood (and not-so-under the hood) it looks and behaves a lot like a TPM
Indeed. Since Apple controls the full hardware and software stack, it's not surprising that they are making their own security chip without any of the ugly downsides of TPM (TPM has more complex interfaces and logic that try to cover a broader set of use cases than what Apple support). As another upside, they are also not reliant on any supplier code for the chip.