WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Discover Managed Device Attestation

Discover Managed Device Attestation

Privacy & SecurityBusiness & Education
Watch original video

Highlight

Managed Device Attestation uses the device’s Secure Enclave to generate a hardware-endorsed certificate chain, allowing the server to verify whether the device is issued by the enterprise, has not been tampered with, and meets specific security policies (such as turning on FileVault and setting password policies). It is suitable for MDM, VPN and Wi-Fi authentication scenarios.

Core Content

There’s a fundamental problem in enterprise IT management: When a device connects to your server, how can you be sure it’s actually a company-issued iPhone that hasn’t been tampered with?

The traditional approach is to rely on the device registration information of MDM (Mobile Device Management) - the server checks whether the device is in the MDM registry and meets certain configuration requirements. The problem is, this information can be faked. An attacker can modify the client code to make a jailbroken device pretend to be a compliant device. The information seen by the server is what the client wants you to see, and is not a reliable proof of the true status of the device.

Apple introduced Managed Device Attestation in iOS 16. The core of this mechanism is for the device’s Secure Enclave to generate a certificate chain, signed by Apple’s CA, proving that this is indeed an authentic, untampered Apple device. More importantly, the certificate can contain information about the security status of the device—whether certain security policies are enabled, whether it is jailbroken, whether it meets password requirements, etc. This information comes from the hardware judgment of the Secure Enclave and cannot be forged by the client application.

The whole process is: the server initiates an attestation challenge to the device, and the device’s Secure Enclave signs a nonce with the private key to generate a certificate chain. This certificate chain contains leaf certificates (device certificates) and intermediate certificates (Apple CA signatures). After the server verifies the certificate chain, it can extract the device’s security attributes from the certificate extension to determine whether the device complies with corporate policies.

The session also explained in detail the application of attestation in different scenarios: MDM servers can use it to verify device identities, VPN services can use it to ensure that only compliant devices can access the corporate intranet, and Wi-Fi authentication can use it to replace passwords to provide stronger security guarantees.

Detailed Content

Device Certification Challenge Process

(11:16) Device authentication starts with the MDM server initiating an attestation challenge. The server includes aDeviceAttestationNonce——A random number to ensure that the response to each request is unique.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>RequestType</key>
	<string>DeviceInformation</string>
	<key>Queries</key>
	<array>
		<string>DevicePropertiesAttestation</string>
	</array>
	<key>DeviceAttestationNonce</key>
	<data>
	bWFnaWMgd29yZHM6IHNxdWVhbWlzaCBvc3NpZnJhZ2U=
	</data>
</dict>
</plist>

Key Points: -RequestTypeforDeviceInformation, indicating querying device information -Queriesarray containsDevicePropertiesAttestation, request device attribute authentication -DeviceAttestationNonceIs a base64 encoded random number to prevent replay attacks

  • The nonce is generated by the server and must be used by the device to generate a signed response

(11:43) The device response contains an array of certificate chains, each in base64-encoded DER format.

<key>QueryResponses</key>
<dict>
	<key>DevicePropertiesAttestation</key>
	<array>
		<data>
		MIIC0TCCAli <!-- ... --> pIbnVw= <!-- Leaf certificate -->
		</data>
		<data>
		MIICSTCCAc6 <!-- ... --> wjtGA== <!-- Intermediate certificate -->
		</data>
	</array>
</dict>

Key Points:

  • first<data>Element is a leaf certificate (device certificate) that contains the security attributes of the device
  • the second<data>element is an intermediate certificate, signed by the Apple CA
  • The certificate chain can be traced back to Apple’s root certificate (Apple Root CA - Private PKI)
  • The server needs to verify the validity of the entire certificate chain

Certificate verification process

After the server receives the certificate chain, it needs to perform the following verification steps:

  1. Verify certificate chain signature: Starting from the leaf certificate, verify the signature step by step until the Apple root certificate. Make sure each certificate is signed by a superior CA.

  2. Check certificate validity period: Confirm that each certificate is within the validity period and has not been revoked.

  3. Extract device attributes: Extract the security attributes of the device from the extension of the leaf certificate. These attributes include whether the device has FileVault turned on, whether it complies with the password policy, whether it is jailbroken, etc.

  4. Verify nonce: Check whether the signature of the nonce in the certificate matches the random number sent by the server to prevent replay attacks.

  5. Apply enterprise policy: Based on the extracted device attributes, determine whether the device meets enterprise security requirements. If not, device access can be denied or permissions can be downgraded.

Application scenarios

MDM server authentication: The MDM server can use attestation to verify the true identity of the device to ensure that only enterprise-issued devices can receive MDM commands. Traditional MDM relies on device IDs and profiles, which can be bypassed by jailbroken devices. Attestation provides hardware-level assurance that even if the device is jailbroken, the Secure Enclave’s signature cannot be forged.

VPN Access Control: Enterprise VPN can require the device to provide attestation before connecting to prove that the device meets the security policy. Only compliant devices can connect to the corporate intranet. This is stronger than traditional password or certificate authentication, as passwords can be compromised, certificates can be stolen, and attestation is tied to the device hardware.

Wi-Fi Authentication: Enterprise Wi-Fi can use attestation instead of password, and the device will automatically provide a certificate chain to prove its identity when it connects. This avoids the complexity of password management while providing stronger security assurance. Wi-Fi networks can determine the level of permissions allowed to access based on the security attributes of the device.

Certificate and private key management

The private key for Managed Device Attestation is generated and managed by the Secure Enclave and never leaves the secure hardware. This means that even if the device is completely compromised, the attacker cannot export the private key to forge the attestation. Secure Enclave will only generate signatures for legitimate attestation requests, and the signature operation is completed within the hardware, and the operating system cannot intervene or tamper with it.

Certificates are issued by Apple’s Private PKI (Public Key Infrastructure). Apple maintains an ecosystem of private CAs specifically for device certification. Enterprise servers need to trust Apple’s root certificate in order to verify the device certificate chain. This chain of trust is secure because Apple’s root certificate comes pre-installed on all Apple devices and is tightly controlled by Apple.

Core Takeaways

  • What: Integrate Managed Device Attestation into your MDM solution to enhance device authentication security.
    Why it’s worth doing: Traditional MDM authentication is easily bypassed by jailbroken devices. Attestation provides hardware-level security guarantees to ensure that only compliant devices can access enterprise services.
    How ​​to get started: In your MDM server implementation, add attestation challenge initiation logic and certificate verification logic. Refer to the attestation related API in the Apple Device Management document.

  • What: Use attestation to replace or enhance traditional authentication in VPN services.
    Why it’s worth doing: VPN is the entrance to the corporate intranet. If authentication is bypassed, attackers can directly access intranet resources. Attestation ensures that only devices that meet the security policy can connect, and even if the password is leaked, the internal network will not be intruded.
    How ​​to get started: In the authentication module of your VPN server, add the device attestation verification step. When the device is connected, attestation is required first, and the tunnel is allowed to be established after the verification is passed.

  • What to do: Enable attestation-based authentication on the enterprise Wi-Fi network.
    Why it’s worth it: Wi-Fi password management is an IT administrator’s nightmare—passwords need to be changed regularly, users can leak passwords, and guest devices are difficult to manage. attestation allows the device to automatically prove its identity without requiring the user to enter a password, and provides a higher level of security.
    How ​​to get started: In your Wi-Fi authentication server (such as RADIUS), configure certificate-based authentication to require devices to provide the Managed Device Attestation certificate chain when connecting.

  • What: Define enterprise device security policies and enforce them during attestation validation.
    Why it’s worth doing: Attestation not only verifies the identity of the device, but also verifies the security status of the device. You can define rules: only devices with FileVault turned on, strong passwords set, and not jailbroken can access corporate services.
    How ​​to get started: In your server-side verification logic, check the device attributes in the certificate according to the enterprise security policy. Devices that do not comply with the policy are denied access or have their permissions downgraded.

Comments

GitHub Issues · utterances