Deploy Managed Device Attestation
Managed Device Attestation is a powerful technology for securing managed devices that can help to thwart many types of attacks, including device property obfuscation, key extraction, and impersonation. Managed Device Attestation is made up of two technologies:
Device information attestation provides attested properties of a managed device in response to the device management service
DeviceInformationquery. This gives the device management service important security and compliance information about a device.ACME attestation proves the identity of a device to relying parties. It provisions a hardware-bound identity on a device. When the client requests a certificate from an ACME server it provides those same attested properties.
These two technologies are strong building blocks which enable you to create a zero-trust architecture based on Apple devices. It’s important to note that organizations only get security benefits if the deployment model built around managed devices incorporates attestations properly. This page describes some possible deployment models.
Components
A deployment model around Managed Device Attestation involves the following components:
The device: The device being managed, which is an iPhone, iPad, Mac, Apple TV, or Apple Vision Pro.
The device management service: The service managing the devices using the device management protocol.
The ACME server: The server issuing client certificates to devices.
Relying parties: The parties that consume the identity’s certificate. They include web servers, VPN servers, recipients of signed email messages, and so on. The device management service also acts as a relying party.
Deployment models
This document describes three deployment models with increasing flexibility as well as an increasing demand on infrastructure requirements and integrations:
Secure the device management channel: This model hardens the communication between a device and the device management service. It ensures that the device management service knows which device it is managing, and provides strong evidence that the device is compliant with organizational policies.
ACME server driven authorization: This gives the Certificate Authority control over authentication and authorization of the device. Relying parties only evaluate whether the certificate is valid and issued by a trusted Certificate Authority.
Differential authorization: The ACME server is responsible for authentication, and relying parties perform authorization based on the authentication. This enables each relying party to make its own, differential authorization decision.
Secure the device management channel deployment model
The device management protocol requires the device to authenticate itself to the device management service using a client identity. This identity is provisioned during device enrollment. In this deployment model, the provisioning of the client identity uses ACME attestation. This gives the device management service a very strong assurance that each incoming connection was initiated by the same legitimate Apple device that enrolled. When the enrollment isn’t a User Enrollment, the device management service also has very strong evidence of the serial number and UDID of the device.
In this deployment model, the issued identities are used only by managed devices to authenticate to the device management service. This means the device management service is also the relying party and usually the instance issuing certificates.
To use this deployment model, the identity is provisioned at enrollment time by providing the device an enrollment profile including an ACME payload (although it is possible to “upgrade” an existing enrollment that didn’t initially use Managed Device Attestation). Using the provided information the device contacts the ACME component of the device management service to request a certificate. You can use custom rules as well, but commonly a certificate is issued if:
The device is known beforehand, for example because it’s registered in Apple School Manager or Apple Business Manager.
The device is related to an enrollment authenticated by a user.
After the device is enrolled, the device management service can additionally withhold apps, configurations, and accounts until the device meets organizational requirements by using device information attestation to query attested dynamic properties such as operating system version and FileVault status.
The same approach can be used to request a fresh attestation when relevant changes occur.
A more complex setup for this scenario involves an ACME server external to the device management service. This either requires an integration between the ACME and the device management service to retrieve information about the device and the enrollment authentication status or issuing certificates which include persistent information from the attestation to enable the device management service to perform its trust evaluation.
ACME server-driven authorization deployment model
In this deployment model, authorization for a device is based only upon whether the issued certificate is trusted. During the ACME flow, the ACME server decides whether to issue a certificate. If the decision requires any information other than what is in the attestation certificate, the ACME server must gather it. The ACME server only issues a certificate if its trust evaluation is passed and the device meets the criteria defined by the organization.
For example, if your organization requires that authorized devices must be enrolled in a device management service, there needs to be a connection between the ACME and the device management service.
This deployment model works best when there are many relying parties that use the same authorization conditions. After the ACME server has performed its trust evaluation, relying parties only need to perform standard certificate validation and trust evaluation to verify access.
Note: Depending on your security requirements, you may want to consider how the deployment deals with devices which have lost their authorization for example by adjusting certificate lifetimes or revocation checking done by the relying party.
Differential authorization deployment model
In this deployment model the ACME server is responsible only for issuing a certificate that authenticates the device. Relying parties determine authorization each time they evaluate the device’s identity certificate and apply their own, individual authorization rules.
The ACME server should include any stateless information in the issued certificate that relying parties need to identify and authorize the device, for example any data that the ACME server received in the attestation certificate.
When the device connects and in addition to verifying the trust of the issued certificate, the relying party can also query the device management service for any dynamic properties. This allows authorization decisions to be based on up-to-date information and can also support deauthorization and reauthorization events. Depending on organizational requirements and criticality of the relying party, authorization decisions may also be cached for a defined amount of time to handle repeated connection events and speed up authorization decisions.