Unlocking Zero Trust Security: Apple MDA for MDM Device Enrollment and Web Application Security

Linda Ikechukwu

Follow Smallstep

Even the U.S Department of Defense has a roadmap in place to implement department-wide Zero Trust security, why don’t you 👀?

Device identity, which ensures the accurate identification, posture check, and authentication of devices (ranging from laptops to autonomous IoT devices) seeking connection to organizational resources, is a key pillar of the zero trust security model.

However, common methods used for device identification and certificate enrollment into organizational MDMs have significant shortcomings. They don't assure that the device enrolling into your MDM is genuinely a trusted device. If a user's access credentials are compromised, a rogue device can be registered using those credentials. And that’s why [Apple’s Managed Device Attestation (MDA) which is Apple’s implementation of ACME Device Attestation is such a huge deal.

This article explores the concept of zero trust, clarifying what it is and isn't, and how Apple's MDA fits into this security model. It discusses all the things you can do with Apple MDA: enroll devices for certificates that validate devices to systems like Wi-Fi, VPNs, and web applications. It also delves into a current limitation regarding the use of Apple MDA certificates on web applications and recommends a path forward.

What Zero Trust Security Is and Isn’t in Simple Terms

Zero Trust security is an IT security model that mandates strict identity verification of every person and device trying to access resources on a network, regardless of whether they are sitting within or outside of the network perimeter. Each user or endpoint desiring to access a resource must directly authenticate with that resource..

The transition to cloud computing, remote work, Bring Your Own Device (BYOD) policies, and the Internet of Things (IoT) has made securing network perimeters insufficient. It's no longer effective to assume that all activity within a secured network is trustworthy.

Traditional IT network security operates on a castle-and-moat concept, meaning that while no one outside the network can access internal data, everyone inside is trusted by default and usually and can access whatever they wish. For instance, if an employee wants to access an internally application like Jira hosted on Cloudfare, they can authenticate to a VPN, which grants them access to the subnet where the application is hosted, instead of directly authenticating to the application. With such setup, one could poke around the network and access resources outside the scope of their jobs. Consequently, if an attacker gains network access, they have unrestricted control over its contents.

In contrast, the zero trust security model helps prevent data breaches and shrink your attack surface by limiting internal lateral movement and enforcing context-based, least privilege access per resource rather than network-level access. Users and devices are not trusted by default, even if they are connected to a private network such as a corporate LAN and have been previously verified.

While 'zero trust' is has been gravely misused as a marketing term by vendors, stripped to the basics, it offers significant security benefits, reducing cyberattack risk and attack surface. Even the U.S Department of Defense has a roadmap to implement department-wide Zero Trust network, and if you’re serious about security in your organisation, you should too.

Zero Trust is not a single product or solution. It's a comprehensive security paradigm that promotes zero implicit trust. This means that neither the authenticator nor the authenticated implicitly trusts the other until it is proven.

Implementing a zero trust security architecture for your organisation will involve incorporating different technologies, products and solutions, and doesn’t mean that you have to completely overhaul your existing security solutions.

The National Institute of Standards and Technology's guide on deploying zero trust security in enterprises recommends that enterprises develop dynamic risk-based policies for individual resource access requests taking into account:

• The level of confidence in the subject's identity for that specific request.
• Whether access to the resource is permissible given the level of confidence in the subject's identity.
• The security posture of the device used for the request.
• Additional factors that might alter the confidence level (e.g., time, location of the subject, subject’s security posture).

And that’s where Apple MDA fits into a zero trust security model. With Apple MDA, you can cryptographically validate that:

• A device is a genuine Apple device
• A device is a specific device (attesting a globally unique device serial number or hardware ID for supervised devices and an MDM enrollment ID that is unique within a single organization for BYOD devices)
• A device is managed by the organisation’s MDM server
• A device has certain properties (for example, the serial number)
• A private key is hardware bound to the device, that it isn’t jailbroken, and other security posture characteristics.

Why Apple Managed Device Attestation for Zero Trust Security?

With Apple's Managed Device Attestation, organizations can securely identify, authenticate, and enroll devices, which is a core tenet of zero trust security.

The Simple Certificate Enrolment Protocol (SCEP) commonly used by Mobile Device Management (MDM) for device enrolment has a flaw: verifying the organization and the device is tough as there's no initial identity for the device. If a user's credentials are compromised, any device can enroll using them, and the device's eligibility is unverified. The protocol assumes any correct user credential is legit, a risky assumption given the prevalence of impersonation attacks.

With the IETF’s ACME Device Attestation protocol, an organization's issuing Certification Authority (CA) ACME service can request an attestation of the properties of the device being enrolled, which the device can obtain this from an attestation CA. The issuing CA's ACME service can then verify the integrity of the attested device properties cryptographically. It can also optionally cross-check them with the organization's device inventory. Upon successful verification, it can confirm that the device belongs to the organization.

Apple’s Managed Device Attestation, co-developed with Google and Smallstep, is an implementation of the ACME Device Attestation protocol available in iOS 16, iPadOS 16.1, macOS 14 and tvOS 16 or later, with Apple servers taking on the role of the attestation CA. The device requests verification of its identity with an Apple attestation server. If successful, the Apple attestation Public Key Infrastructure (PKI) issues a signed attestation certificate to the device.

The device then sends this certificate as a response to an ACME Device Attestation challenge from the ACME server. Upon receiving the certificate, the ACME server validates it using the attestation root CA, which is controlled by Apple. This process allows for secure enrollment of new Apple phones or laptops onto your network.

• Strong cryptographic device identity: ACME DA uses cryptographic coprocessors (TPM 2.0 or Apple Secure Enclave) with asymmetric cryptography in a challenge-response protocol to allow devices to “attest” to their identity. The keys used for attestation are hardware-bound and non-extractable and cannot be moved to a different device, offering the highest assurance of device legitimacy.
• Zero-touch enrollment: ACME DA, used in conjunction with a device inventory, facilitates seamless device enrollment without manual intervention, ideal for remote and large-scale deployments. Since devices can strongly authenticate themselves, from anywhere, over the public internet, you can drop-ship devices to end-users and configure them to automatically bootstrap when they start up.

Asides authenticating devices to enroll to organisation MDM (which is the most popular use case), ACME Device Attestation can also be used in:

• Authenticating devices to access Wifi using EAP-TLS
• Authenticating devices to access VPN
• Authenticating devices to access infrastructure like Databases, git repositories, Kubernetes clusters, SSH hosts, etc (either as a single factor, or as a second factor in conjunction with user authentication)
• Authenticating devices to access resources via Web Browsers (again, either as a single factor, or as a second factor in conjunction with user authentication). However, at the moment, certificates issued using MDA on macOS are not currently accessible by Web Browsers, but there’s a way forward.

Current Limitations of ACME MDA on macOS for Web Application authentication and Recommended Path Forward

If you're planning to use a certificate from Apple MDA on MacOS to access an internal web app hosted on say Cloudflare via Cloudflare Access mTLS, you should be aware of this limitation.

Certificates and keys on macOS are typically managed in the file protection keychain, an OS subsystem that is visible to end-users via the Keychain Access app and manages login (per-user) and system (per-device) keys. As the name suggests, keys on this keychain are stored on-disk.

There is also another less familiar keychain on macOS called the data protection keychain. The data protection keychain is a more secure option than the file protection keychain because keys on the data protection keychain can be hardware-bound and access to keys can be restricted to specific applications using Keychain Access Groups. Some information about data protection keychain keys is available by running /usr/libexec/mdmclient QueryCertificates.

Keys and certificates created via MDA (using the ACMECertificate MDM payload) are always stored by macOS on the data protection keychain in a Keychain Access Group that’s restricted to a small set of Apple apps.

These keys are available for WiFi (EAP-TLS), built-in VPN, and certain other system services, as the relevant processes are in the same System Keychain Access Group. However, because these keys do not appear in the Keychain Access app, they’re consequently not visible or usable by other user-space processes, including Web Browsers. Nonetheless, there is a glimmer of optimism.

At present, Apple refers to the "file protection keychain" as the "legacy keychain" in their online documentation. This suggests that they may soon retire the "file protection keychain", and the "data protection keychain" will likely become mainstream and accessible to other applications through Keychain Access Groups.

While this is yet to become the reality, here’s our recommended path forward if you want to use keys or certificates issued from Apple MDA directly in a browser:

1. Start with SCEP, now. Smallstep can integrate with Jamf to deliver certificates to macOS and iOS devices on the file protection keychain today, using the SCEP protocol with Dynamic SCEP Challenges. This will serve as a proof-of-concept. While it’s not as strong a mechanism as ACME DA, is still a dramatic improvement with a straightforward migration path.
2. Use ACME DA as soon as the data protection keychain opens up. As soon as ACME DA certificates are available to other applications via Keychain Access Groups, step CLI will be able to automatically deliver a derived certificate to the file protection keychain where Web Browsers could find it. This would serve as a stopgap until Web Browsers are upgraded to look for certificates in the data protection keychain.
3. Use ACME DA directly in Web Browsers. Once Browsers are upgraded to look for certificates in the data protection keychain, step CLI would no longer be necessary for this use case.

💡Note: There’s another workaround. Smallstep supports ACME Device Attestation for other TPMs and TPM-like devices like a Yubikey. We can support Device Attestation today using a Yubikey, and deliver a certificate to the file protection keychain.

Let Smallstep Help You Confidently Identify and Authenticate Devices With ACME Device Attestation

ACME Device attestation effectively eliminates the possibility of impersonation and reduces IT support costs with zero-touch enrollment. Smallstep is here to be the ACME server for your enterprise and replace your painfully manual and insecure device enrollment processes. Forget about configuring PKIs, CAs, and tokens. Just plug in and be on your way.

And for cases where Apple DA is not supported, Smallstep has backwards-compatible support for all of the legacy enrollment protocols and validation services including SCEP, NDES, OCSP, and CRL, so you have nothing to worry about.

Interested? Contact us or sign up on the platform to connect Jamf or Intune to issue client certificates for VPN and Wifi in minutes.