Discover Managed Device Attestation

♪ ♪ Bob: Hi, I'm Bob Whiteman, Senior iOS Device Management Engineer. It is my pleasure to share with you an important new security feature for managed devices in enterprise and education environments. Let's start by reviewing the device security landscape. Your users need to access organization resources, such as websites, application servers, and databases. And there's attackers who also want to access those resources. The classic model for securing resources is perimeter security. You draw a security boundary around an intranet, and stand up a firewall or VPN that permits legitimate clients and rejects threats. But this model hasn't kept up with the way people interact with modern organizations. Cloud service providers put resources outside the perimeter. Threats can start from inside the perimeter.

And threats can spoof legitimate clients to penetrate the perimeter.

A more modern security model does not trust a network perimeter. Instead, each resource performs its own trust evaluation. This is a core principle of zero trust architecture.

You can think of trust evaluation as a function: the input is posture information about the client, and the output is the decision to grant or deny access. It's critical to get trust evaluation right. A false negative gets in the way of user activities, or worse, a false positive allows an attacker to access your resources. And that means having accurate posture information is also critical. Let's investigate common components of posture. You use all available information about the client and its request: who is making the request, what device they're using, where they are, and so on. Trust evaluation may use different details within the posture for accessing different resources. Accessing a low-security resource may only require the user's identity, but accessing critical infrastructure may require evaluating all posture items. It's up to the organization to decide which details are relevant.

One central element of posture is the user's identity. This indicates who is making the request.

Apple devices provide several technologies to support user identity, such as the Extensible Single Sign On feature, including the built-in Kerberos extension, to facilitate user authentication for apps, websites, and accounts. And the new Enrollment Single Sign On feature lets an app facilitate user authentications during and after the enrollment process of User Enrollments. But this session isn't about user identity, it's about device identity. This element of posture indicates which device is making the request.

The UDID that the device reports in each MDM communication is the primary way that your MDM server knows which device it's managing. The DeviceInformation query also provides to the MDM server attributes of the device, including the serial number. A managed device often communicates with other systems inside the organization aside from the MDM server. So, often the MDM server configures the device with client certificates that declare the device's identity to those other systems. These methods of identifying a device have served us well, but they amount to trusting that the device is the one that it claims to be. As the landscape has changed, with devices more distributed than ever before, our security needs have evolved. To address this, I'm excited to share a powerful new method for proving a device's identity, Managed Device Attestation. With Managed Device Attestation, a device provides strong evidence about itself when making a request. It improves posture information, so trust evaluations based on that are more accurate. In short, Managed Device Attestation means legitimate devices reliably access resources, and attackers are thwarted. This release brings Managed Device Attestation for iOS 16, iPadOS 16, and tvOS 16. This session we'll start with an overview of the new attestation features, explain the benefits of using attestations, and then dive into the implementation details. First, what are attestations? An attestation is a declaration of a fact. If you trust the entity making the claim, you accept that the fact is true. In software, an attestation is a fact that is cryptographically signed. This is usually an X.509 certificate. If you trust the signer, you accept that the fact is true. For Managed Device Attestation, the facts are the identity and other properties of a device, and the signer is Apple. Accepting the accuracy of these device facts requires trusting Apple. However, it doesn't require trusting every line of code ever written by Apple.

It only requires trusting the Secure Enclave and Apple's attestation servers, which access Apple's manufacturing records and operating system catalog. And if you keep your data on Apple devices at all, you're implicitly trusting those. Here's how we're bringing the power of attestations to managed devices. Managed Device Attestation offers two ways to use attestation certificates. We've enhanced the DeviceInformation MDM command, which makes the benefits of attestation available to the MDM server. And we've added support for the Automatic Certificate Management Environment, or ACME, protocol by adding an ACME profile payload, which makes the benefits of attestation available throughout the organization's infrastructure.

For DeviceInformation attestation, the MDM server issues a DeviceInformation query and specifies some new keys. The device obtains an attestation from Apple’s servers and returns it to the MDM server. Then the MDM server evaluates the attestation.

But be careful. DeviceInformation attestation declares to the MDM server, "A device exists with these properties." It does not prove that the device the MDM server is currently communicating with is that same device. For that, you need ACME payload attestation.

ACME payload attestation provides the strongest proof of the identity of the device. When you install a profile containing an ACME payload, the device requests a certificate from an organization ACME server. This is very similar to installing a SCEP payload. The device provides an attestation to the ACME server. Based upon this strong proof of the identity of the device, the ACME server issues a new client certificate that the rest of your organization's servers trust. These two new features use attestation certificates to prove several things: the device is genuine Apple hardware; the device is a specific device; the device has certain properties; and a private key is bound to the device. And it proves to different servers that they are communicating with the same device. How do these attestations benefit you? Attestations are primarily a security feature, so I'll describe some of the threats and how attestations mitigate them.

First, a compromised device lies about its properties, so Apple attests to the properties. Even if the OS is compromised, that doesn't affect the reliability of the attestation. It only requires the Secure Enclave to be intact. Or a compromised device provides an outdated attestation of properties that have since changed. A nonce in the attestation ensures that the facts are up to date. ACME payload attestation mitigates other threats. A compromised device sends a different device's identifiers when communicating with the MDM server. So Apple attests device identifiers in a way that's tied to the client identity that the device uses to authenticate its TLS connection. This proves to your MDM server and other organization servers which device they are communicating with.

Or, an attacker extracts a private key from a legitimate device and uses it to make requests, spoofing the legitimate device. Apple attests that the private key is protected by the Secure Enclave, which has exceptionally strong protections against exporting or importing private keys. Last, an attacker hijacks a certificate request to get a certificate authority to issue a certificate for a different device. Apple attests the identity of the requesting device in a way that ties it to the certificate request, so the certificate authority only issues certificates to the legitimate device. Attestations give you security benefits that mitigate several threats. So how do you use them in your environment? Let's get into the details of how to implement Managed Device Attestation. First, there are the enhancements to the DeviceInformation command. An MDM server can issue this command to a managed device. The request includes a list of properties that the server wants to know. We've added a new property, DevicePropertiesAttestation. Adding it to the Queries array means the MDM server is requesting an attestation. To ensure that the attestation is fresh, the MDM server can use the DeviceAttestationNonce key. This appears at the same level in the request as the Queries key. This key is optional. Its value is a data object, with a maximum size of 32 bytes. Here's an example that requests attestation. The Queries array contains the DevicePropertiesAttestation key, and there's a 32 byte nonce. When obtaining the attestation is successful, the response contains a DevicePropertiesAttestation key. Its value is an array of data objects. Each element in the array is a certificate in a certificate chain. This is an example response. The leaf certificate appears first in the array, and it contains device properties in custom OIDs. The first two OIDs are device identifying properties, serial number and UDID. They are omitted from the certificate if the MDM enrollment is a User Enrollment. The remaining OIDs are anonymous, and available for all enrollment types. sepOS version refers to the version of the operating system that runs on the Secure Enclave. And the presence of the correct value in the nonce OID proves that the certificate was just generated. When the MDM server receives an attestation it must carefully validate it, in the following order. It verifies that the cert chain is rooted with the expected Apple certificate authority. The Apple certificate authority is available from the Apple Private PKI Repository. It verifies that the nonce in the leaf certificate matches the nonce in the DeviceInformation request, if one was specified. And then it parses out the remaining OIDs and evaluates their values. Generating new attestations uses significant resources on the device and Apple's servers, so there's a rate limit on how often new attestation certificates can be requested, currently one new attestation every seven days. You request a fresh attestation by specifying a new nonce. Omitting a nonce indicates that freshness is not a concern, so the device can return its most recent attestation instead. And if the nonce is specified and matches that cached attestation, the cached attestation is returned. When the MDM server validates the nonce in an attestation, it should detect a mismatched nonce and determine whether that was expected due to caching or not. But don't request a new attestation every seven days just because that's the rate limit. Doing that will only delay how quickly your MDM server discovers changes in device properties, not to mention waste resources. Instead, monitor for relevant changes in the other DeviceInformation properties, such as the OS version. When one of those changes, then request a fresh attestation. This ensures the attestation is updated as quickly as possible after a change, rather than waiting for the rate limit to expire. And, just in case the device is compromised and lying about these other properties, slip in the occasional random request for a fresh attestation to keep the device honest. Requesting an attestation may fail. When that happens, the device still responds but some information is omitted. Either the DevicePropertiesAttestation field is omitted from the response, or an expected OID or its value is omitted. There are many potential reasons for a failure: the device experiences a network issue reaching Apple's attestation servers. No server is up 100% of the time, so there may be an issue with Apple's attestation servers. Or the device hardware or software may be compromised, or it's not even genuine Apple hardware. In these last three cases, Apple's attestation servers refuse to issue an attestation for properties that they cannot verify. The different causes of a failed attestation range from a harmless network glitch to an active attack. Unfortunately, there is no trustworthy way for the MDM server to know the exact cause. This is because the only source of information about the failure is the device itself, which may be a compromised device that's lying. So how should an MDM server interpret a failure? Don't always assume the worst when attestation fails. If you have a zero trust architecture, here's how you would likely handle it. The organization calculates a trust score for the device, with a failed or unexpectedly stale attestation lowering that score. A lowered trust score triggers different actions, such as denying access to services, flagging the device for manual investigation, or remediating by wiping it and revoking its certificates. This ensures an appropriate response to a failed attestation. Let's move on to implementing ACME payload attestation. Installing an ACME payload involves several steps. I'll describe the different participants in the process, then each of those steps. We start with an iPhone, iPad or Apple TV.

In most cases this is managed by an MDM server. There's an ACME server. This implements the ACME protocol, RFC 8555, so it can issue client certificates from an organization certificate authority. And there's Apple's attestation servers that issue the attestations.

The first step is for the MDM server to install a profile containing an ACME payload. The payload specifies properties of the key the device will generate, properties of the certificate that the device will request, and how to request the certificate from the ACME server. To start installing the profile, the device generates the requested type of key. In order to use attestations, the key must be hardware-bound. While the ACME payload supports RSA and various sizes of keys, in order to get a hardware-bound key, you must use ECSECPrimeRandom. Your best choice is a ECSECPrimeRandom 384 bit key because that's the highest security hardware-bound key. Once the key is created, the device makes initial contact with the ACME server.

The device requests the DirectoryURL, which specifies the URLs to use for the rest of the process of communicating with the ACME server. Then the two systems create an account and an order. The server offers the device-attest-01 validation type. Then, the ACME server generates a nonce and sends it to the device in the token field. The ACME protocol was initially used to issue server certificates. Here however, the validation type we use was introduced in an IETF draft specifying an extension of the ACME protocol for receiving attestations and issuing client certificates.

Attestation is optional. When the payload specifies attestation, the device requests an attestation from Apple. This is nearly identical to the DeviceInformation attestation. It uses the same OIDs, and device-identifying OIDs are omitted for User Enrollments. But there's a few differences. The nonce is hashed using SHA-256 before embedding it in the attestation. The nonce comes from the ACME server, not the MDM server. And the private key that matches the attestation leaf certificate is the one the device just generated. The attestation certificate matches the private key, however that certificate can't be used for any purposes besides attestation. So the device requests from the ACME server another certificate matching the private key, and this cert is good for TLS.

The device provides a certificate signing request containing the certificate request properties from the payload. It provides the attestation chain. And it provides the ClientIdentifier from the ACME payload. Typically this is used like a ticket that is good for the issuance of a single certificate, to prevent repeated requests. The ACME server must carefully validate the request before issuing a certificate, in this order. It must verify that the ClientIdentifier is valid and unused. The attestation certificate must chain up to the correct Apple CA. The public key in the attestation leaf certificate must match the CSR. The nonce must match the SHA-256 hash of the one that the ACME server sent earlier. And then the ACME server can evaluate the remaining OIDs. And remember that attestations may fail. The ACME server should carefully consider a failure when issuing a certificate, just like we reviewed with a failed attestation in the DeviceInformation case. From here, things rapidly finish up. The ACME server issues a client certificate from the organization CA and returns it to the device.

The ACME server is the final authority for client certificate issuance. It can choose to honor or override the properties in the CSR such as the SubjectAltName. The device stores the certificate in the keychain, and this completes the installation of the ACME payload.

Let's tie all this together. How do servers know the device communicating with them is the one it claims to be? The device uses the same private key in multiple ways: when getting an attestation from Apple, when getting a client certificate from the ACME server, and when using TLS to communicate with other servers. Because the key is hardware-bound, we know all these actions were performed by the same device. And we have an attestation certificate which describes that device. Combining these, organization servers now have confidence in the device's identity when granting access.

Just like with the certificate and SCEP payloads, other payloads in the profile can reference the ACME payload in order to use the certificate. Use it for MDM, Wi-Fi, VPN, Kerberos, Safari. All these systems benefit from attestation.

A device can have up to 10 ACME payloads that use attestation installed at the same time. Note that hardware-bound keys are not preserved when a managed device's backup is restored, even when restoring to the same device. And if you do nothing else with Managed Device Attestation, use an ACME payload for the MDM client identity so the MDM server can be sure which device it's managing. Let's wrap up. You use Managed Device Attestation to remediate multiple classes of threats. You leverage DeviceInformation attestation to improve the device identity component of posture for better trust evaluation. And, you can now prove a device's identity as it accesses organization resources using ACME attestation. We look forward to your implementation of Managed Device Attestation. Together, we'll improve the security of your device deployments. Thank you, and have a great WWDC.