Managed Device Attestation: ACME as the Bottom Turtle in Mobile Device Management

Herman Slatman

Follow Smallstep

If you are interested in using Smallstep as your ACME server for Managed Device Attestation on all of your Apple devices and beyond, click here. Have you ever wondered how to securely enroll a brand new phone or laptop onto your network and with your PKI? You may have never considered the question, unless you’re running a large IT department. Mobile Device Management (MDM) solutions often pair with the Simple Certificate Enrolment Protocol (SCEP), but they have a critical shortcoming: it’s hard to ensure you’re adding the right machine. There is a better way now. A new ACME challenge type proposed by Google—called the Device Attestation challenge and part of the new Managed Device Attestation functionality introduced by Apple—binds an identifier to a specific device using cryptographic hardware. We’re excited about this development and, if you care about security, you should be too.

The rest of this post describes the problem with classical certificate management methods in MDM, introduces the ACME Device Attestation challenge, and describes how you can get started using it.

Bootstrapping Trust

There are challenges associated with enrolling a device into an MDM solution. It's hard to verify that it belongs to the organization and is the intended device, because there is no known identity set up for the device the first time it identifies itself. This contains the potential for abuse; for example, when a phishing scammer compromises a user’s access credentials, the credentials can be used to add an unauthorized device to the user’s list of managed devices. The MDM solution then automatically provisions the device with a SCEP profile including a challenge, resulting in the device successfully requesting a client certificate from an internal CA. The client certificate, in turn, can authenticate other internal systems.

The problem of identifying a device and bootstrapping trust isn’t new. One solution to this problem is adding a hardware module dedicated to secure storage and computing. The hardware module can come in several forms, such as being integrated in the CPU, as a dedicated co-processor, as a special purpose device accessible via a hardware interface, or as a dedicated hardware appliance. The hardware module can provide capabilities including secure storage of keys, a cryptographically secure pseudo-random generator, and secure computation. Leveraging these capabilities makes it possible to anchor trust to the hardware module instead of having to trust the complete device hardware. Because the hardware module is typically smaller in terms of number of functionalities, physical components, and lines of firmware than a complete device, it becomes easier to reason about and verify its security properties, resulting in a smaller overall attack surface.

Trusted Platform Module (TPM) Attestation

A Trusted Platform Module (TPM) is a type of hardware that provides a way to verify its identity. A TPM is a secure co-processor using a standard interface. The Trusted Computing Group (TCG) developed the interface specification and its current version is 2.0. The standard interface specifies every TPM has an Endorsement Key (EK)—a private key created or injected at manufacturing time by the TPM manufacturer. The private key can’t be extracted from the TPM, but the TPM manufacturer certifies its public part. The corresponding EK certificate can reside inside the TPM too, or it is retrievable via a URL.

One special property of the EK is that it can’t be used to sign data and thus cannot be used to prove a device’s identity directly. The EK can only decrypt data encrypted to its public key. Key usage restrictions built into the TPM module implement this limitation of the EK. It was an intentional design decision, meant to prevent the TPM from being used to identify devices tracking purposes. Proving its identity thus requires a slightly more elaborate process, called device identity attestation. This process involves a (platform) attestor, a (platform) verifier, and the TPM and can work as follows:

• The attestor retrieves the EK certificate(s) from the TPM ①. Those can come from the TPM directly, or from a URL ②.
• The attestor instructs the TPM to create an Attestation Key (AK) ③ and corresponding certificate with application specific identifiers, such as a unique device ID ④.
• The attestor combines the AK and EK certificate(s) and sends them to the verifier ⑤.
• The verifier validates the EK certificate(s) is signed by a trusted TPM manufacturer ⑥ and cross-checks the identifying information with data from the manufacturing process.
• If validation is successful, the verifier challenges the attestor with a secret encrypted to the EK public key ⑦, ⑧.
• The attestor activates the AK by instructing the TPM to decrypt the secret from the verifier ⑨.
• The TPM decrypts the secret ⑩ and returns the plaintext to the attestor ⑪.
• The attestor sends the plaintext secret to the verifier ⑫.
• The verifier compares the plaintext secret to what it provided in the attestor before ⑬.
• If the comparison succeeds, the verifier issues a certificate for the AK ⑭ and sends the certificate to the attestor ⑮.

The AK certificate could be used for authentication directly, but would require verification of the AK certificate, and thus full trust in an attestation server. In an environment with multiple platforms and (potentially) multiple attestation servers, it requires implementation of platform specific verification of the attested identity. Any relying party would have to know about the identifiers used by your devices, requiring some method of synchronization with your internal device inventory. The recently introduced draft IETF RFC for ACME Device Attestation tackles these issues.

TPMs + ACME: Better Together

Frequent visitors of this blog and users of the Smallstep platform know we love the ACME protocol. Support for the protocol was introduced in v0.13.0 of step-ca, and since then we’ve added several functionalities, including support for IP identifiers, ACME revocation, and External Account Binding support. All these functionalities make using the ACME protocol on private networks more powerful. The new functionalities did not change the fact that ACME clients need to solve ACME challenges, however. Solving a challenge requires an ACME server like step-ca reaching out to the domain for which a certificate was requested and verifying that the client has control over the domain. Because the ACME protocol was designed for issuing certificates to web servers, the challenges work great for this type of system. They are not a great fit for client systems, like laptops and phones, because those types of devices are usually not accessible on a listening port.

That’s why we got very excited when we learned about Brandon Weeks’ draft RFC for ACME Device Attestation. As described before, the ACME protocol was designed for the Web PKI, but it did anticipate other use cases already. One of the extension points to the protocol, are the supported challenge types. The RFC describes a new ACME challenge type that uses TPM device identity attestation to authorize a certificate request. The process for using this new challenge type is as follows:

• Client creates an ACME account on the ACME server ① and receives response ②.
• Client requests a certificate including a device identifier Subject Alternative Name ③.
• Server responds with device-attest-01 challenge ④.
• Client creates key authorization value for the ACME account and challenge token ⑤.
• Client creates a new certificate private key, attested by the AK, certifying the key authorization value ⑥.
• The TPM sends the key parameters back to the Client ⑦.
• Client packs the key parameters and AK certificate chain in an attestation statement ⑧, sends it to the ACME server ⑨ and starts polling for the validation status ⑩.
• The Server verifies the attestation statement ⑪.
• If verification is successful, the ACME challenge is complete, and the response is sent to the ACME Client ⑫.
• The Client sends the CSR to the ACME Server ⑬.
• The Server finalizes the Order ⑭, issues the certificate ⑮ and returns it to the Client ⑯.

The ACME server decides how to perform the attestation statement validation, because this is not part of the RFC. Typically, this will include verifying the AK certificate chains to a root CA trusted by the ACME server, is otherwise valid (e.g. is within certificate validity dates, is not revoked, contains a Subject or at least one SAN, etc.), and whether the key authorization provided by the client is the same as what the server determined. The ACME server is also in charge of what information ends up in the issued certificate, which can be a sub- or superset of the properties the client provided.

The big change that the ACME Device Attestation proposal brings to how MDM solutions currently provision client certificates: private keys are now attested by the TPM and issued using a modern and well-defined protocol. Attesting keys allows systems to verify that a private key was generated inside a TPM and cannot be extracted from it. This makes it significantly harder for an unknown device to pose as a known device. By building on the well-defined and extendable ACME protocol, instead of retrofitting TPM attestation to older protocols supported by MDM solutions—such as the Simple Certificate Enrollment Protocol (SCEP), the Certificate Management Protocol (CMP), or Enrollment over Secure Transport (EST) protocol—potentially conflicting properties of the older protocols don’t constrain the implementation. Adoption of the retrofitted TPM attestation capabilities into legacy clients also won’t block its deployment, resulting in a more future-proof overall solution.

Challenges & Opportunities

Essentially, the ACME Device Attestation RFC is fairly limited, describing only how a device can use a TPM-attested identity to solve an ACME challenge, gluing the two together. It doesn’t specify how a device attests its identity in the first place, or how the attested identity has to be verified by an ACME server. As far as the RFC is concerned, these are external processes that are platform- and implementation-specific. Because of that, the steps required to be performed for these processes are hard to fully standardize or could be too limiting. It is thus up to the platforms and integrators to design and implement them. Currently, there’s not yet a reference-worthy open source implementation of the specification. We’re working on support for the ACME Device Attestation challenge instep-ca, however, and we will soon start the implementation of a generic attestation statement verification library together with Brandon Weeks. ACME Device Attestation will also be available in our hosted solution. Let us know if you’re interested and what you would like to see in terms of functionality.

Despite the RFC’s short existence, swift adoption of the new challenge type seems inevitable, as Apple has announced support for Managed Device Attestation during WWDC 2022. Apple’s implementation is based on the ACME Device Attestation RFC, with servers from Apple taking on the role of the attestation CA. In this configuration, the device proves its identity to an Apple attestation server. If verification succeeds, the Apple attestation PKI signs a certificate and issues it to the device. The device sends the certificate as the ACME Device Attestation challenge response to the ACME server. When the ACME server receives the certificate, it validates the certificate with the attestation root CA controlled by Apple. This requires trust in Apple’s infrastructure and attestation PKI. Support for Managed Device Attestation in the Apple ecosystem will be introduced first in iOS 16, iPadOS 16 and tvOS 16, and macOS assumably will follow soon.

Besides the announcement from Apple, Google is also working on integrating support for ACME Device Attestation to Android and ChromeOS, encompassing the lion’s share of mobile phones and tablets deployed within organizations using MDM.

As described before, a device first needs to verify its identity to an attestation CA before it can validly respond to the device-attest-01 challenge. The attestation CA is also sometimes called a privacy CA or anonymization CA and can have (slightly) different responsibilities, depending on its deployment and configuration. Usually the attestation CA is an online system, providing centralized control over whether to issue a certificate. A platform can provide you with an attestation CA, as with Apple hardware, or it can be hosted in-house. We can provide solutions tailored to your specific use cases.

Having a strong, hardware-attested, cryptographic device identity also opens up many other use cases that rely on some kind of cryptographic root of trust. Some examples:

• Remote key provisioning of additional key material. Secrets can be exchanged by encrypting them to the (application-specific) AK for which a certificate was issued. The AK private key is only accessible by the TPM and is bound to its device identity, resulting in only the device being able to decrypt the (shared) secret(s).
• Perform remote boot or runtime attestation. This goes further than device identity attestation, by ensuring the firmware and operating system on the device are in some expected state and were not tampered with.
• Configure a VM to bootstrap with a virtualized TPM (vTPM) using the ACME Device Attestation challenge to obtain a certificate with AWS roles embedded, so that it can authenticate to AWS and be checked against AWS IAM Roles Anywhere for access policy decisions.
• Hardware-based attestation is currently a frequently discussed topic in various IETF working groups. Some notable examples are the RFCs for Attested (D)TLS and Network Device Integrity Verification. It seems inevitable TPMs will soon form a strong foundation for cryptographic device identity and standardized schemes relying on this identity in many industries. Hopping on the TPM bandwagon now may make a big difference in the near future.

Conclusion

Organizations rely on MDM solutions for several reasons, including credential provisioning, configuration management, and compliance monitoring. MDM solutions typically use outdated protocols such as SCEP to provision credentials and may not confidently assure the identity of the device that’s being enrolled. Managed Device Attestation, built on the new ACME Device Attestation challenge, combines a hardware-bound, cryptographic identity with a modern protocol for certificate automation. This combination offers a higher assurance of the device’s identity than typical enrollment methods. This makes it a secure foundation for other functionalities that require a trusted identity.

We are looking for organizations who want to replace their painful manual device enrollment processes with Managed Device Attestation. If that's you, join us here.

Supporting resources:

Apple’s Managed Device Attestation announcement at WWDC: https://developer.apple.com/videos/play/wwdc2022/10143/

Apple’s documentation about Managed Device Attestation with ACME: https://developer.apple.com/documentation/devicemanagement/acmecertificate

The IETF draft spec for ACME Device Attestation: https://datatracker.ietf.org/doc/draft-bweeks-acme-device-attest/

Notes from the latest ACME Working Group (discussed ACME Device Attestation): https://notes.ietf.org/s/notes-ietf-114-acme