Managed Device Attestation for Apple devices
Managed Device Attestation is available in iOS 16, iPadOS 16, macOS 14, tvOS 16, visionOS 1.1, watchOS 9, or later. It uses the Secure Enclave to provide cryptographic assurances about the identity of a device and its security posture. iPad, iPhone, Apple TV devices require the A11 Bionic chip or later, and only Mac computers with Apple silicon are supported. Managed Device Attestation helps to protect against the following threats:
A compromised device lying about its properties
A compromised device providing an outdated attestation
A compromised device sending a different device’s identifiers
Private key extraction for use on a rogue device
An attacker hijacking a certificate request to trick the certificate authority (CA) into issuing the attacker a certificate
With managed device attestation, a device can request an attestation from the Apple attestation servers, which return an array of data consisting of a leaf and intermediate certificate which is rooted in the Apple Enterprise Attestation Root CA. Depending on the device type, the leaf certificate can contain specific properties as shown in the following table.
OID and value | Minimum supported operating system versions | Description |
|---|---|---|
1.2.840.113635.100.8.9.1 Serial number | iOS 16 iPadOS 16 macOS 14 tvOS 16 visionOS 1.1 watchOS 9 | Represents the serial number of the device and can be used to identify a device. To help protect the user’s privacy, this value isn’t included when using Managed Device Attestation with User Enrollment. |
1.2.840.113635.100.8.9.2 UDID | iOS 16 iPadOS 16 macOS 14 tvOS 16 visionOS 1.1 watchOS 9 | Represents the unique hardware ID and can be used to identify a device. On a Mac, the UDID matches the provisioning UDID of the device. To help protect the user’s privacy, this value isn’t included when using Managed Device Attestation with User Enrollment. |
1.2.840.113635.100.8.10.2 sepOS version | iOS 16 iPadOS 16 macOS 14 tvOS 16 visionOS 1.1 watchOS 9 | Represents the version of the Secure Enclave firmware. |
1.2.840.113635.100.8.11.1 Freshness code | iOS 16 iPadOS 16 macOS 14 tvOS 16 visionOS 1.1 watchOS 9 | A unique and non-predictable code identifying a particular attestation. This indicates that the attestation was generated after the code was created. |
1.2.840.113635.100.8.13.1 SIP status | macOS 14 | Represents the SIP enablement status on a Mac with Apple silicon. |
1.2.840.113635.100.8.13.2 Secure boot status | macOS 14 | Represents the selected secure boot configuration of a Mac with Apple silicon. |
1.2.840.113635.100.8.13.3 Third-party kernel extensions allowed | macOS 14 | Represents whether or not third-party kernel extensions are allowed on a Mac with Apple silicon. |
1.2.840.113635.100.8.10.3 LLB version | iOS 16 iPadOS 16 macOS 14 tvOS 16 visionOS 1.1 watchOS 9 | Represents the version of the Low-Level Bootloader. |
1.2.840.113635.100.8.10.1 Operating system version | iOS 16 iPadOS 16 macOS 14 tvOS 16 visionOS 1.1 watchOS 9 | Represents the operating system and iBoot version. |
1.2.840.113635.100.8.9.4 Software update device ID | iOS 16 iPadOS 16 macOS 14 tvOS 16 visionOS 1.1 watchOS 9 | Attests the |
A request for an attestation is initiated either by a DeviceInformation request sent by the device management service or by installing an ACME configuration. In both cases, the device receives a freshness code from either the device management service or ACME solution. When using DeviceInformation attestation, the freshness code is the value of the DeviceAttestationNonce specified in the request. When using ACME attestation, the freshness code is the SHA-256 hash of the token from the device-attest-01 challenge. The resulting value is included as a property in the leaf certificate and allows the device management service or ACME solution to verify that the attestation matches the request.
Upon receiving the attestation, a backend service needs to carefully perform validation checks. These checks include ensuring the leaf cert was issued by the Apple Enterprise Attestation Root CA, comparing the hash of the freshness code to the expected value, and examining other properties in the attestation.
Depending on an organization’s deployment model, Managed Device Attestation can be an important foundation of a modern and secure deployment and used in different ways:
Use an ACME-issued certificate to authenticate the connection from the client to the device management service and leverage
DeviceInformationattestation to verify properties of a device on an ongoing basis.Verify the identity of a device and its security posture and have the ACME solution perform a trust evaluation before issuing a certificate. In this way it ensures that only devices meeting the required standards receive a certificate.
Embed the device’s properties from the attestation in an ACME certificate, and perform the trust evaluation on the relying parties.
Hardware-bound keys
As part of issuing a certificate using the ACME protocol, a device can be requested to provide an attestation which also causes the associated key pair to be protected by the Secure Enclave so that it benefits from its strong hardware security and helps to prevent exporting the private key.
To create a hardware-bound key, the ACME configuration needs to use the ECSECPrimeRandom algorithm with a key size of 256 or 384 bit. This specifies a key pair on the P-256 or P-384 curves as defined in NIST SP 800-186.
To generate the private key, the Secure Enclave first uses the following to create a wrapped cryptographic secret:
A combination of its hardware True Random Number Generator (TRNG)
Entropy stored within the secure non-volatile storage of the Secure Enclave
A Data Protection key
The operating system stores the wrapped secret however, the wrapped secret is useless by itself. To derive the private key the Secure Enclave needs to use the same secret, the same stored entropy, and the same Data Protection key. Because the stored entropy and Data Protection key are unique to that specific Secure Enclave, only that Secure Enclave is capable of generating the private key which effectively binds the hardware-bound key to that Secure Enclave.
When the device is erased, the Secure Enclave effaces the stored entropy. Because of this, a hardware-bound key can’t be regenerated after a backup and restore, even when restoring to the same device.
Any configurations containing an ACME payload with a hardware-bound key are removed upon restore. If a hardware-bound key is used as the device management service client identity, the device unenrolls. In this scenario if the device was enrolled through Automated Device Enrollment, the device fetches its enrollment profile again and reenrolls.