Securing Your Apple Devices: A Deep Dive into Managed Device Attestation ->ACME + Intune

Imagine an employee tries to connect to your corporate VPN and WiFi network using a company-issued mobile device. Traditionally, they would authenticate with a password or certificate, but what if that device had been compromised? Without proper verification, a cloned or tampered device could gain access to sensitive company data, putting your entire network at risk.

This is where Managed Device Attestation steps in. By ensuring that only devices with verified hardware and software configurations can connect to your VPN and WiFi, it adds an essential layer of security. It verifies the device’s integrity before allowing network access, ensuring that only trusted devices can connect, and effectively mitigating the risk of unauthorized access.

This example directly addresses the importance of Managed Device Attestation in securing VPN and WiFi connections, emphasizing how it prevents compromised devices from gaining access.

Introducing Managed Device Attestation

With the increasing sophistication of attacks, simply relying on passwords or basic certificate-based authentication is no longer enough to secure access to your organization’s critical resources. Managed Device Attestation provides a robust solution to these challenges by ensuring that only devices with verified integrity can connect to your network.

Managed Device Attestation is a feature in iOS 16, iPadOS 16.1, macOS 14 and tvOS 16, or later. Managed Device Attestation provides strong evidence about which properties of a device can be used as part of a trust evaluation. This cryptographic declaration of device properties is based on the security of the Secure Enclave and the Apple attestation servers.

Managed device attestation helps protect against the following threats:

• A compromised device lying about its properties
• A compromised device providing an outdated attestation
• A compromised device sending a different device’s identifiers
• Private key extraction for use on a rogue device
• An attacker hijacking a certificate request to trick the CA into issuing the attacker a certificate

How It Enhances Device Security

Managed Device Attestation (MDA) empowers Apple devices to securely communicate with Apple servers through the Secure Enclave. This hardware-protected component houses a unique device identifier and certificates essential for establishing trust. When prompted, a device engages in an attestation process, sharing information about its hardware, software, and security status with Apple’s servers.

Apple validates this information, generating a device attestation report. This report certifies the device’s authenticity, identity, and adherence to specific security criteria. It verifies that the device is genuine Apple hardware, uniquely identifiable, and possesses expected properties like serial number. Crucially, MDA confirms the device’s private key is securely bound to its hardware, preventing unauthorized access.

As a Public Key Infrastructure (PKI) provider, we’re collaborating with Apple to leverage this device trust for certificate issuance. By integrating MDA with your ACME-based certificate management system, you can ensure that only authenticated and compliant devices receive certificates. These certificates serve as digital credentials, enabling secure communication with other systems like Wi-Fi networks, VPNs, and application firewalls.

This verification process is particularly crucial for environments that rely on VPNs and WiFi for secure remote access. Managed Device Attestation ensures that only devices with unaltered, trusted configurations can establish connections. This approach reduces the risk of unauthorized access from compromised or cloned devices, significantly bolstering the security of your network. By implementing Managed Device Attestation, organizations can:

• Prevent Device Spoofing: Ensure that only genuine devices with verified configurations can access sensitive networks.
• Mitigate Man-in-the-Middle Attacks: By verifying device integrity before network access, the risk of intercepting sensitive data is minimized.
• Strengthen Zero Trust Architectures: Managed Device Attestation aligns perfectly with the principles of Zero Trust, where no device is trusted by default, even if it is within the network perimeter.

---

Why we are moving away from SCEP

As organizations strive to secure their mobile devices and networks, it’s essential to examine the tools and protocols in use. One such protocol that has been widely used in the past is the Simple Certificate Enrollment Protocol (SCEP). While SCEP was a significant advancement when it was first introduced, helping to automate certificate issuance for a variety of devices, it has become increasingly clear that SCEP is no longer sufficient for the demands of modern mobile security.

Limitations of SCEP

SCEP was designed in an era when mobile device security threats were far less sophisticated than they are today. The protocol has several inherent limitations that make it less suitable for contemporary security needs:

• Lack of Robust Security Features: SCEP does not support advanced security mechanisms like device attestation or hardware-backed cryptographic validation. This leaves a gap in ensuring that certificates are only issued to trusted, uncompromised devices.
• Vulnerability to Man-in-the-Middle Attacks: SCEP’s reliance on basic encryption and authentication methods makes it more susceptible to man-in-the-middle attacks, where an attacker could intercept and alter the communication between a device and the certificate authority.
• Complexity in Managing Certificate Lifecycles: SCEP does not provide automated processes for certificate renewal and revocation, leading to administrative overhead and potential security lapses when certificates expire or need to be revoked.
• Limited Flexibility: SCEP was not designed with the complexities of modern, dynamic IT environments in mind. It lacks the flexibility to adapt to different use cases, such as the integration of device attestation, that are becoming increasingly important.

The Need for Modern Solutions

In contrast, modern protocols like ACME (Automatic Certificate Management Environment) are designed to address these limitations. ACME automates the entire certificate lifecycle, from issuance to renewal and revocation, with far greater security features, including support for Managed Device Attestation.

By adopting ACME and phasing out SCEP, organizations can significantly improve their security posture. Managed Device Attestation ensures that certificates are only issued to devices that have passed stringent integrity checks, reducing the risk of compromised devices accessing corporate networks. Furthermore, the integration of ACME with tools like Intune simplifies the management process, allowing IT teams to maintain robust security controls with less manual intervention.

---

ACME: A Cornerstone of Certificate Management

To fully leverage the power of Managed Device Attestation, integrating it with a robust certificate management solution is key. This is where the ACME protocol comes into play.

Understanding the ACME Protocol

The Automatic Certificate Management Environment (ACME) protocol is a standardized method developed by the Internet Engineering Task Force (IETF) to automate the process of obtaining, renewing, and revoking digital certificates. ACME was originally designed to streamline the process of issuing SSL/TLS certificates for securing web domains, but its utility has expanded to various use cases, including device management.

ACME simplifies the traditionally complex and manual processes of certificate management, enabling organizations to maintain secure communications and authentication without the burden of manual intervention. This automation is especially valuable in large-scale environments where managing certificates manually for thousands of devices can be error-prone and resource-intensive.

Combining Managed Device Attestation and ACME?

ACME works through a series of automated interactions between a client (typically a device or a service) and a Certificate Authority (CA). Here’s a simplified overview of how the protocol operates:

• Account Registration: The client initiates the process by registering with the CA. This involves creating an account, which may include submitting identifying information and agreeing to the terms of service.
• Certificate Request: Once the account is registered, the client requests a certificate from the CA. This request includes a public key and information about the domain or device for which the certificate is needed.
• Validation: The CA performs a validation check to ensure that the client is authorized to request a certificate for the specified domain or device. In the context of device management, this could involve checking the device’s identity and integrity through Managed Device Attestation.
• Certificate Issuance: Upon successful validation, the CA issues the certificate to the client. The client can then use this certificate to authenticate itself to services like VPNs, WiFi networks, or other secure resources.
• Certificate Renewal and Revocation: ACME also automates the renewal process, ensuring that certificates are always up-to-date. Additionally, if a certificate needs to be revoked (for example, if a device is compromised), the ACME protocol facilitates this process, reducing the risk of unauthorized access.

ACME Protocol Functions

ACME uses various URLs and resources for different management functions it can provide. Some functions include:

• New Nonce
• New Registration
• New Application
• New Authorization
• Revoke Certificate
• Key change

How ACME Improves Security Over SCEP

---

Combining Managed Device Attestation and ACME

An attestation is essentially a declaration of a fact, and if the entity making the claim is trustworthy, you can confidently accept that the fact is true. In the context of software, an attestation is a fact that is cryptographically signed, typically in the form of an X.509 certificate. Trusting the signer of the certificate means accepting the truth of the attested fact. For Managed Device Attestation, the facts pertain to the identity and other characteristics of a device, and the signer, in this case, is Apple. Accepting the accuracy of these device facts requires trust in Apple, but it does not mean trusting every line of code Apple has ever written.

The trust required is limited to the Secure Enclave and Apple’s attestation servers, which rely on Apple’s manufacturing records and operating system catalog. If you’re already storing your data on Apple devices, you’re implicitly placing trust in these components. Managed Device Attestation leverages this trust by offering two primary ways to use attestation certificates: First, through the enhanced DeviceInformation MDM command, which makes the benefits of attestation accessible to the MDM server, and second, by supporting the ACME protocol via an ACME profile payload, which extends the benefits of attestation throughout the organization’s infrastructure.

DeviceInformation Attestation

For DeviceInformation attestation, the MDM server issues a DeviceInformation query and specifies some new keys. The device then obtains an attestation from Apple’s servers and returns it to the MDM server, which evaluates the attestation. However, it’s important to understand that DeviceInformation attestation merely declares, “A device exists with these properties.” It does not provide proof that the device currently communicating with the MDM server is indeed that same device. For this level of proof, ACME payload attestation is required.

ACME Payload Attestation

ACME payload attestation offers the strongest proof of a device’s identity. When a profile containing an ACME payload is installed, the device requests a certificate from an organization’s ACME server, similar to how a SCEP payload works. The device provides an attestation to the ACME server, and based on this robust proof of the device’s identity, the ACME server issues a new client certificate that is trusted by the organization’s servers.

These new features allow attestation certificates to prove several things: that the device is genuine Apple hardware, that it is a specific device, that it has certain properties, and that a private key is securely bound to the device. This proof is provided to various servers, confirming that they are communicating with the same device. The benefits of these attestations primarily revolve around security, as they mitigate several key threats.

For example, if a device is compromised and lies about its properties, Apple’s attestation ensures the accuracy of these properties. Even if the operating system is compromised, the reliability of the attestation remains intact as long as the Secure Enclave is unaffected. Additionally, ACME payload attestation mitigates other threats, such as a compromised device sending another device’s identifiers to the MDM server. Apple attests to the device identifiers in a way that is tied to the client identity used for TLS connections, ensuring the MDM server and other organization servers know which device they are communicating with.

Moreover, Apple attests that the private key is protected by the Secure Enclave, which offers exceptional security against exporting or importing private keys, thereby preventing an attacker from spoofing the legitimate device. If an attacker attempts to hijack a certificate request to get a certificate authority to issue a certificate for a different device, Apple’s attestation process ties the identity of the requesting device to the certificate request, ensuring that certificates are issued only to the legitimate device.

The ACME Payload Flow

Implementing Managed Device Attestation with the ACME payload provides a robust framework for securing device identity across your organization. Here’s a detailed flow of how the ACME payload works to ensure that only trusted devices with verified identities can access critical organizational resources:

Step 1: Profile Installation

The process begins when the MDM server installs a profile on the device that contains an ACME payload. This payload specifies various properties, including the type of key the device will generate, the properties of the certificate that the device will request, and the instructions for how to request this certificate from the ACME server.

Step 2: Key Generation

Upon receiving the ACME payload, the device generates the requested type of key. To use attestations effectively, this key must be hardware-bound. The most secure option is to use an ECSECPrimeRandom 384-bit key, as it provides the highest level of security by ensuring that the key is bound to the device’s hardware.

Step 3: Initial Contact with ACME Server

After generating the key, the device initiates contact with the ACME server. It requests the DirectoryURL, which provides the URLs for further communication with the ACME server. The device and server then proceed to create an account and an order for the certificate.

Step 4: Attestation Request and Validation

The ACME server offers the device-attest-01 validation type, which is designed for receiving attestations and issuing client certificates. The ACME server generates a nonce and sends it to the device within the token field. The device then requests an attestation from Apple’s servers, embedding the nonce (hashed using SHA-256) within the attestation request.

The attestation certificate that the device receives from Apple matches the private key generated earlier. However, this certificate is solely for attestation purposes and cannot be used for other functions like TLS.

Step 5: Certificate Request

The device submits a certificate signing request (CSR) to the ACME server, which includes the properties defined in the ACME payload, the attestation certificate chain, and the ClientIdentifier. The ClientIdentifier acts as a one-time-use ticket for certificate issuance, preventing multiple requests using the same identifier.

Step 6: Validation by ACME Server

The ACME server meticulously validates the CSR, ensuring that the ClientIdentifier is valid and has not been used before. It verifies that the attestation certificate chains up to the correct Apple Certificate Authority (CA). The public key in the attestation certificate must match the one in the CSR, and the nonce must correspond with the SHA-256 hash provided earlier. After these checks, the ACME server evaluates the remaining Object Identifiers (OIDs).

Step 7: Certificate Issuance

Upon successful validation, the ACME server issues a client certificate from the organization’s CA and returns it to the device. The device stores this certificate in its keychain, completing the installation of the ACME payload.

Step 8: Using the Certificate

The device uses this certificate for various services like MDM, Wi-Fi, VPN, Kerberos, and Safari, ensuring secure and authenticated communication with organizational servers. The hardware-bound key, combined with the attestation and certificate, provides a strong guarantee that all actions are performed by the same device.

---

Managed Device Attestation and ACME with Intune

With the latest service release, Microsoft Intune has initiated a phased rollout of an infrastructure update for new device enrollments, now supporting the Automated Certificate Management Environment (ACME) protocol. This means that when new Apple devices are enrolled, the management profile from Intune will now include an ACME certificate instead of a SCEP certificate. ACME offers enhanced security compared to SCEP by utilizing robust validation mechanisms and automated processes, reducing the risk of unauthorized certificate issuance and minimizing errors in certificate management.

Existing OS and hardware eligible devices do not get the ACME certificate unless they re-enroll. There is no change to the end user’s enrollment experience, and no changes to the Microsoft Intune admin center. This change only impacts enrollment certificates and has no impact on any device configuration policies.

ACME support is available for Apple Device Enrollment and Apple Configurator enrollment methods, with eligibility for the following OS versions:

• iOS 16.0 or later
• iPadOS 16.1 or later
• macOS 13.1 or later

As an MDM admin, there’s no need for additional configuration to deploy the ACME payload on your managed devices with Intune. Any eligible Apple device enrolled in Intune will automatically receive the ACME certificate.

To view the payload an eligible device receives when obtaining the ACME certificate from Microsoft Intune CA on a iOS device, navigate to Settings > General > VPN & Device Management and double-click on the “Management Profile”.

The payload used to configure Automated Certificate Management Environment (ACME) Certificate settings on the device can also be checked from Managed Preferences.

---

Conclusion

The evolving landscape of mobile security demands innovative and robust solutions, and the combination of Managed Device Attestation with the ACME protocol provides just that. By integrating these two powerful technologies, organizations can significantly enhance their security posture, ensuring that only trusted and verified devices can access critical resources.

Managed Device Attestation strengthens the foundation of device security by verifying the integrity and authenticity of devices, while ACME streamlines and automates certificate management, reducing the risk of unauthorized access and simplifying administrative tasks. Together, they create a comprehensive security framework that not only protects against a wide range of threats but also aligns with modern security practices like Zero Trust.

As organizations continue to adopt more mobile and remote work environments, the need for secure, efficient, and scalable solutions becomes increasingly critical. Implementing Managed Device Attestation and ACME within your infrastructure ensures that your mobile devices remain secure, your certificate management processes are streamlined, and your organization is well-protected against emerging threats.

By embracing these advanced security measures, you can confidently manage your device fleet, knowing that your devices are secure, your data is protected, and your organization is prepared for the future of mobile device security.