ACME Device Attestation Explained

Carl Tashian

Follow Smallstep

Imagine this: As an organization, you have a list of your trusted devices and their hardware identifiers. When you ship a new trusted device to one of your users and they turn it on for the first time, their device immediately gets its own X.509 certificate from your internal CA and uses that certificate to authenticate itself to your MDM service, VPN, and WiFi. There’s no login necessary. From the user’s standpoint, the device is the password. From the organization’s standpoint, as long as the device is in “good security posture” (however the organization defines that), it’s safe to issue a certificate.

Now that the device is authenticated to the MDM server, the MDM server can confidently configure the device for additional client certificates (device-linked or not) for accessing internal resources like websites or databases. Since the MDM server knows the user associated with the device, it can request client certificates with user identifiers.

This is the future of device enrollment, it’s called ACME Device Attestation [IETF draft], and it’s available now in iOS 16 (and coming soon to Android, ChromeOS, and other platforms). The goal is to bring endpoint management into the era of Zero Trust.

Before we dive further into the details of ACME Device Attestation, let’s look at the recent history of certificate enrollment in Mobile Device Management (MDM).

How most MDM devices currently get certificates

ACME Device Attestation is a modern replacement for the 20+ year old SCEP protocol for certificate management. Simple Certificate Enrollment Protocol (SCEP) [RFC 8894] was originally designed for getting X.509 certificates to networking gear. The way it works is pretty simple: As long as the device knows the secret password and is configured to trust the organization’s Certificate Authority (CA), it can request a certificate for itself from the CA.

Around 2010, SCEP was adopted by Apple for their new Mobile Device Management (MDM) feature. For this use case, the user installs a configuration profile (an XML file created with Apple Configurator, or using an MDM platform like Jamf or SimpleMDM) onto the device.

At minimum, the profile has a couple of sections (payloads):

• A Certificate payload containing the CA’s root certificate, to establish trust with the CA
• A SCEP payload, which contains the SCEP CA URL and password, and whatever names should appear on the certificate. Once a SCEP payload is installed, the device will enroll itself with the CA in the background (the device does not, however, keep the certificate renewed; the MDM has to do that).

Why SCEP is an outdated approach

Because SCEP is secured with a password, an attacker with access to a configuration profile from the organization can get a certificate using SCEP and potentially impersonate the user.

And, let’s face it, passwords are becoming passé. The world is moving toward hardware-bound credentials that let devices authenticate to servers using an internal security chip instead of a password.

SCEP wasn’t designed to use these newer technologies.

Hardware authentication and biometrics like Touch ID and Face ID have enabled the rise of Zero Trust networking. By requiring device attestations in MDM, an organization’s security policies can better adhere to the principles of least privilege and defense in depth, without sacrificing the user experience. Organizations can begin to think of their internal network perimeter as a semipermeable membrane, not a firewall. And the rise of remote work has sped up the adoption of Zero Trust principles even more.

The new way: ACME Device Attestation

ACME Device Attestation brings automated certificate enrollment into the future. An attestation is a piece of data that’s cryptographically signed by a trusted party. In this case, to get a certificate using ACME, an iOS device can prove its device identifiers to a third-party CA, by sending the CA a device certificate signed by Apple.

ACME Device Attestation has a number of advantages over SCEP:

• No rogue devices! The CA can be configured to only issue certificates to devices with identifiers issued by the organization. When your security policy is restricted to a set of trusted devices, it makes life a lot more difficult for an attacker.
• Hardware-bound private keys! The CA can cryptographically confirm that the device’s private key is hardware-bound and is not exportable from the device.
• No more passwords! The ACME MDM configuration profile only has an internal ACME CA URL and some certificate request properties. A stolen configuration profile has almost no value to an attacker.

Finally, as with SCEP, if a device is stolen or lost you can immediately revoke all of the device’s access (for example via the Online Certificate Status Protocol (OCSP) [RFC 6960]).

How ACME Device Attestation Works

In iOS 16, Apple has added a new ACMECertificate payload type, and with it, the ability for a device to prove its identity to a CA by using a new extension to the ACME protocol: the device-attest-01 challenge type.

Here’s what a typical device enrollment might look like:

ACME Device Attestation flow, using a configuration profile and an MDM service

You may notice that this flow applies to both ACME and SCEP protocols. So, anywhere you currently use SCEP, you can now use ACME. But, in the details there are many differences that make ACME device enrollment a big step forward on any organization’s path toward Zero Trust.

Want to set up ACME enrollment for your Apple devices? We can help!