Apple Device Attestation.
Managed Device Attestation enables enterprises to verify Apple devices for security, protecting the corporate network. Here's how to use it.
Security background
In our interconnected world, the issue of device identity plays a critical role in online security. Traditional security models use perimeter defenses plus a firewall to attempt to verify devices - and block malicious ones.
The idea behind perimeter defenses is that a network (or part of a network) are secured at all the possible points of entry into the network from the outside.
Perimeters can also be established via Virtual Private Networks (VPNs) which only allow external users to connect through a single device or gateway (which is heavily secured).
Perimeter defenses are designed to keep external attackers at bay and out of internal networks. But in the modern mobile age, perimeter defenses no longer serve a purpose because devices are mobile and move from one location to another.
Devices today are smaller and can be concealed. They can be brought inside an organization's perimeter defenses effortlessly by visitors or even by employees.
Due to these factors, any attempt to verify and track a malicious mobile device using perimeter defenses is futile.
Instead, a Zero Trust security model is now used. The idea behind Zero Trust is every device or user is suspect until verified ("never trust, always verify").
One of the central tenets of Zero Trust is to replace the perimeter model with one of direct device to resource verification.
In this model, each resource accessed on a network verifies the client device directly - ensuring that the device is authorized to access the resource. If a device isn't verified (or the user isn't authenticated) access is denied.
Additionally, the widespread use of cloud resources means many organization resources are now distributed and outside security perimeters.
External perimeter threats still exist such as Direct Denial of Service (DDoS), Man-In-The-Middle attacks, and ransomware - just to name a few.
But these types of attack vectors are usually performed by large, gang, or state actors. As such they require a different security model.
Security and managed devices
Apple solves the problem of security on mobile devices using a verification and trust scheme that involves multiple resources.
This includes an Apple device's Secure Enclave - an area on newer Apple devices that may contain an Apple T2 chip, or a dedicated secure area. Secure enclaves use hardware encryption and also have the ability to generate secure private keys tied to each device.
Another way Apple and organizations secure devices is via the use of Mobile Device Management (MDM) servers.
Automatic Certificate Management Environment (ACME) servers can also be used - along with nonces ("Number-Once" or one-time secure random numbers), and encryption.
Internally Apple provides Device Attestation Servers (DAS), which contain lists of all known released and purchased Apple devices, serial numbers, and device Secure Enclave details.
Apple DAS ensures Apple can verify that any alleged Apple device trying to communicate with a network is in fact, the device claimed.
Using these components in concert, it's possible for an organization or resource to verify that an Apple device is authentic. This process is known as Managed Device Attestation (MDA).
MDA terminology
Security is a complex topic so we can't cover every aspect of MDA here. We'll only touch on a few key concepts.
But first, a little terminology used in MDA and in computer security in general:
- Managed Device Attestation - the process of asserting and verifying an Apple device
- MDM Server - a server managed by an organization or by Apple which manages Apple devices
- Cryptographic key - a unique encoded number used in secure information exchange across a network
- PKI - Public Key Infrastructure - software which manages cryptographic keys for security purposes
- ACME - The Automatic Certificate Management Environment protocol used to automate the exchange of certificate information
- ACME server - a PKI certificate server managed by an organization or by Apple which manages Apple devices
- Nonce - in cryptography, a one-time unique (usually random) number used as an identifier in network communication
- Perimeter - and organization's or computer's encircling network security inside which unauthorized communication are not allowed
- Threat actor - an individual or group which intends to carry out an attack on a network or on computing device(s)
- Attack surface - the ways in which a threat actor can break into or compromise a network or device
- Client - any remote computer attempting to connect to a network, device, or computer
- Trust evaluation - the process of verifying a connecting device's or user's identity
- Posture - in computer security a profile containing one or more pieces of information about a device or user which helps in trust evaluation
- UDID - a Unique Device number which identifies a device
- Certificate - an encrypted file exchanged across a network to provide identity and verification information about a device - usually a server
- Attestation - a declaration of fact, which, once verified allows a network to trust a device or user
The ACME protocol uses JSON-formatted text over HTTPS and is defined in IETF RFC 8555. ACME allows computers to automate the exchange of encrypted certificates to speed up secure communication.
Apple's servers and MDM servers communicate with or use ACME servers in the Device Attestation process.
In software, an attestation is a fact that is cryptographically signed. Once the signature is verified along with the device, the attestation is trusted. Using a legal analogy, think of an attestation as a verified, signed affidavit that states facts.
Organization servers can decide how much device attestation they require in order to trust a connecting device. In the case of Apple devices, attestations can include the device identity, properties, and optionally, other info such as certificates, profiles, and user IDs.
Using Apple Device Attestation, an Apple device can be verified by receiving and trusting these facts.
Device connection and verification
When an Apple device connects to a network, resource servers on the network can request device verification.
During this process, the connecting device is asked to connect to any existing MDM servers, which then triggers Apple's Device Attestation Servers to verify the device using the device's Secure Enclave.
Each modern Apple device has its own onboard Secure Enclave (which includes hardware-encrypted information). When the Secure Enclave verifies the device, Apple's attestation servers send a response to the MDM or organization's resource server to signify the device is valid.
If verification fails, the device is denied access to the requested organization resource. Apple calls this device info the Trust Foundation, which may include:
- Secure Enclave
- Apple attestation servers
- Manufacturing records (including serial number)
- Operating system catalog
MDM servers can issue a DeviceInformation command to an Apple device requesting the device info.
Once a device's attestation is returned to an MDM server, it's evaluated for validity. Device attestation declares to the MDM server that there is, in fact, a valid Apple device with the requested properties.
If ACME servers are used, an ACME payload can also be added. An ACME payload can be used in a device's ACME attestation, which further helps verify the device by means of a certificate.
ACME payloads support RSA or ECSECPrimeRandom encryption but it must be either 256-bit or 384-bit.
ACME is a bit like the Simple Certificate Enrollment Protocol (SCEP) used on network equipment. Most ACME server attestations require a hardware-bound key to ensure the information being verified is tied to the specific connecting device.
If an ACME attestation is requested, an ACME server configures and issues a new certificate, which the rest of the organization's servers can trust.
Note that the ACME attestation step usually only happens once the physical device attestation has completed. The certificate the ACME server issues is based on a unique temporary one-time private key generated by the Apple device itself.
Key exchange between a device and servers.
There are additional ways the ACME payload can be verified, depending on how the device is connecting. These include Safari ID, Kerberos, Wi-Fi's PayloadCertificateUUID, and a VPN's PayloadCertificateUUID.
There is currently an Device Attestation Extension under consideration by the IETF for inclusion in the ACME protocol.
Each attestation can optionally use a unique nonce, or random number, during communication to ensure stale security information can't be used twice.
This ensures Man-In-The-Middle attacks can't occur which can impersonate a device via a forged certificate.
If a malicious device tries to lie about the Apple properties of a device in order to try to impersonate a device, Apple's attestation servers will reject it - and the device validation fails.
By using a combination of these trusted details it becomes virtually impossible to impersonate an Apple device. Multiple attestations can be exchanged, leading to an attestation chain.
During device trust evaluation, each server considers a device's and user's security Posture, or details, which can include:
- User identity
- Device identity
- Location
- Connectivity
- Time
- Device management
Server architecture
Rate limiting
Device attestation uses significant resources on the device, including power. So Apple limits the number of times and the frequency a device attestation can be requested.
In general, for DeviceInformation, Apple only allows one request every seven days.
Using a new nonce in an attestation indicates a new attestation is being requested, while omitting a nonce indicates the device's previous attestation can be used.
Apple defines a key for attestation nonces: DeviceAttestationNonce.
For these reasons, servers or network devices shouldn't request a new attestation as soon as possible. Rather only request one when a device property has changed, or if a certain time period has elapsed.
Reacting to a failed attestation
Apple mentions that there is no trustworthy way to know why a device attestation has failed, only that it has.
However, if a device attestation does fail, the network or a server shouldn't assume the worst - the failure could be legitimate and doesn't necessarily indicate an attack.
Additional resources
The above description, is of course a gross simplification. To understand every detail of Apple Device Attestation, be sure to check out Apple's WWDC '22 session Discover Managed Device Attestation.
The attestation process is actually fairly complex and takes some study to understand fully.
For information on Apple PKI resources and certificates, see Apple PKI.
Using Apple Managed Device Attestation, you can vastly improve the security of your organization's Apple devices on your network.
You can verify devices before allowing them to access resources - and greatly reduce the likelihood a threat actor can use an Apple device as an attack vector.