Attestation process security
Attestation process security
When the ACME configuration specifies a hardware-bound key, or when the device management service requests a DeviceInformation attestation, the device uses the following steps:
The operating system requests a hardware-bound key from the Secure Enclave, called the attested key. For ACME attestation, this key is part of the issued certificate identity. For
DeviceInformationattestation the key is generated by the operating system and reused for all subsequentDeviceInformationattestations for the lifetime of the enrollment.The operating system requests a hardware attestation from the Secure Enclave. It specifies the attested key, the freshness code, and which properties it wants attested.
The Secure Enclave generates and returns a new hardware attestation.
The operating system sends the hardware attestation to the Apple attestation servers.
The attestation servers validate the request and either refuse to issue an attestation certificate or generate an attestation containing only the properties and values that it was able to confirm. The public key of the attestation certificate matches the attested key.
The operating system provides the resulting attestation certificate to the device management service or ACME solution.
For more information about validating the provided attestation certificate, see Validating a Managed Device Attestation on the Apple Developer website.
About hardware attestation
When the Secure Enclave generates a hardware attestation, it includes the following elements, among others:
Identifiers of the main logic board.
The public key of the attested key.
Hashes of the following software components which are calculated during the boot process and stored in hardware registers (similar to Sealed Key Protection):
The Secure Enclave firmware (sepOS).
The Image4 manifest attached to LLB which also contains a measurement of all other system-paired firmware.
The operating system Image4 manifest which contains measurements of all of the OS-paired firmware.
Other device-specific values like ECID and ChipID.
On Mac computers, details of the LocalPolicy.
The freshness code.
If the Secure Enclave is unable to unwrap the attested key, the Secure Enclave refuses to generate a hardware attestation. This ensures that the attested key is bound to that specific Secure Enclave and all other attested properties are associated with that key.
All of these elements are compiled into a custom binary structure and signed with the UIK. This ties the hardware attestation with a specific identity that Apple’s attestations can verify, allowing them to associate the request with a specific activation record, and therefore with a specific manufacturing record.
Generating the attestation certificate
When Apple’s attestation servers receive an attestation request they:
Validate the User Identity Key (UIK) signature of the hardware attestation. If the signature is invalid, no attestation is generated.
Look up
ucrtin Apple’s activation records which corresponds to the public key of UIK. If noucrtis found, no attestation is generated.Look up the
scrtwhich corresponds to theucrtof the device. Thescrtis a certificate issued by Apple servers during manufacturing based on the Silicon Identity Key (SIK). The SIK is generated by the Secure Enclave and its public key is collected during manufacturing from the device. The SIK is used during activation to verify that the Secure Enclave of the activating device is in possession of the private key. The SIK persists throughout the lifetime of a device and acts as a unique identifier. Using thescrt, the manufacturing record of the device is retrieved. If no record is found, no attestation is generated.Verify the identifiers of hardware components match manufacturing records. If the component identifiers don’t match manufacturing records, no attestation is generated.
Copies the freshness code into the attestation, if present.
If requested by the attestation:
Compare calculated hashes of the software components to known hashes from build records. If there’s a match, the official version number is inserted into the attestation; if not, the OID is omitted or its value is blank.
When images for LLB, Secure Enclave, or the main operating system are built, hashes are calculated and recorded in a build records database, along with the official version numbers for those images.
Calculate the UDID from the ECID and ChipID.
Copy values for the requested OIDs from the LocalPolicy into the attestation if the device is a Mac.
The practical result of these validations is that no attestation is generated if the attestation servers can’t recognize the device as genuine Apple hardware. Each property in the attestation certificate is included only if the attestation servers are able to verify the property’s value, with the exception of the freshness code which is included without any validation.