Managed device attestation security
Managed device attestation is available in iOS 16, iPadOS 16, macOS 14, tvOS 16, watchOS 9, visionOS 1.1, or later. It uses the Secure Enclave to provide cryptographic assurances about the identity of a device and its security posture. iPhone, iPad, Apple TV devices require the A11 Bionic chip or later, and only Mac computers with Apple silicon are supported. Apple Vision Pro requires visionOS 1.1 or later. 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. Serial number | iOS 16 iPadOS 16 macOS 14 tvOS 16 watchOS 9 visionOS 1.1 | 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 watchOS 9 visionOS 1.1 | 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 watchOS 9 visionOS 1.1 | 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 watchOS 9 visionOS 1.1 | A unique and non-predictable code identifying a particular attestation. This indicates that the attestation was generated after the code was created. The code is hashed using SHA256. | |||||||||
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 watchOS 9 visionOS 1.1 | 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 watchOS 9 visionOS 1.1 | 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 watchOS 9 visionOS 1.1 | Attests the | |||||||||
A device can be triggered to request an attestation either with a command sent by the MDM server or as part of a certificate issuing process using ACME. In both cases, the device receives a freshness code from either the MDM or ACME server (that’s part of the request to the attestation server). The SHA256 hash of the freshness code is included as a property in the leaf certificate and allows the MDM or ACME server to verify that the attestation matches the request.
Upon receiving the attestation, a backend service must 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 MDM 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 server 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.
Creation of 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 created within the Secure Enclave so that it benefits from its strong hardware protections. This causes the private key to be wrapped with a class key 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.
Hardware-bound keys don’t survive 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 MDM client identity, the device unenrolls. In this scenario if the device was enrolled through Automated Device Enrollment, the device re-fetches its enrollment profile and reenrolls.