TECH

How to use Apple managed device attestation to secure your networks

Apple Device Certification.

Managed Device Attestation allows businesses to verify the security of Apple devices, protecting the corporate network. Here's how to use it.

Security Overview

In our connected world, device identification plays a critical role in online security. Traditional security models use perimeter protection plus a firewall to scan devices and block malicious devices.

The idea of ​​perimeter protection is that the network (or part of the network) is protected at all possible points of entry into the network from the outside.

Perimeters can also be established using virtual private networks (VPNs), which allow external users to connect through only one device or gateway (which is securely protected).

Perimeter protection is designed to prevent external attackers and prevent access to internal networks. But in today's mobile era, perimeter security no longer serves the purpose as devices are mobile and move from one place to another.

Today's devices are smaller and can be hidden away. Visitors or even employees can easily move them inside the organization's perimeter.

Due to these factors, any attempt to verify and track a malicious mobile device using perimeter security will be futile.

The Zero Trust security model is now used instead. The idea of ​​zero trust is that every device or user is suspicious until verified (“never trust, always verify”).

One of the central principles of zero trust is replacing the perimeter model with a model of direct resource verification through the device.

In this model, each resource accessed on the network is directly verified by the client device, ensuring that the device is allowed to access the resource. If the device is not verified (or the user is not authenticated), access will be denied.

Additionally, the widespread use of cloud resources means that many of an organization's resources are now distributed and located outside security perimeters.

There are still external perimeter threats such as direct denial of service (DDoS), man-in-the-middle attacks, and ransomware, to name a few.

But these types of attacks are usually carried out by large gangs or state actors. Therefore, they require a different security model.

Security and managed devices

Apple solves the problem of security on mobile devices , using a verification and trust scheme involving multiple resources.

This includes the Apple device Secure Enclave, an area on new Apple devices that may contain the Apple T2 chip, or a dedicated secure area. Secure enclaves use hardware encryption and also have the ability to generate secure private keys tied to each device.

Another way to protect Apple devices and organizations is by using mobile device management (MDM) servers.

Automatic Certificate Management Environment (ACME) servers can also be used—along with nonces (“nonces” or one-time secure random numbers) and encryption.

Internally, Apple provides Device Assessment Servers (DAS) that contain lists of all known released and purchased Apple devices, serial numbers, and information about Secure Enclave devices.

Apple DAS ensures that Apple can verify that any purported Apple device attempting to communicate with the network is in fact the claimed device.

Using these components together allows an organization or resource to verify the authenticity of an Apple device. This process is known as managed device attestation (MDA).

MDA Terminology

Security is a complex topic, so we cannot cover every aspect of MDA here. We will touch on just a few key concepts.

But first, some terminology used in MDA and computer security in general:

  1. Managed Device Attestation – the process of approving and verifying an Apple device.
  2. MDM Server – a server managed by an organization or Apple, which manages Apple devices.
  3. Cryptographic key – a unique encoded number used in the secure exchange of information on the network.
  4. PKI – public key infrastructure – software that manages cryptographic keys for security purposes.
  5. ACME is an Automatic Certificate Management Environment protocol used to automate the exchange of certificate information.
  6. ACME Server is an organization-managed or Apple-managed PKI certificate server that manages Apple devices.
  7. Nonce – in cryptography, a one-time unique (usually random) number used as an identifier in network communications.
  8. Perimeter – and the network security of an organization or computer within which unauthorized communication is prohibited
  9. Perimeter – and the network security of an organization or computer within which unauthorized communication is prohibited
  10. An attacker is an individual or group intending to attack a network or computing device(s).
  11. Attack surface is the ways in which an attacker can penetrate or compromise a network or device .
  12. Client – any remote computer attempting to connect to a network, device or computer.
  13. Trust assessment – the process of verifying the identity of the connecting device or user.
  14. Position – in computer security profile containing one or more pieces of information about a device or user that help in assessing trust.
  15. UDID – a unique device number that identifies the device.
  16. Certificate – an encrypted file exchanged over a network to provide identification and verification information about a device (usually on a server).
  17. An attestation is a statement of fact that, once verified, allows a network to trust a device or user.
  18. >

The ACME protocol was developed by the Internet Security Research Group and is used in its popular service Let's Encrypt.

The ACME protocol uses JSON-formatted text over HTTPS and is defined in IETF RFC 8555. ACME allows computers to automate the exchange of encrypted certificates to speed up secure communications.

Apple servers and MDM servers communicate with or use ACME servers in the device attestation process.

In software, a confirmation is a fact signed with a cryptographic signature. Once the signature is verified with the device, the attestation is trusted. Using a legal analogy, think of an attestation as a verified, signed affidavit that states the facts.

An organization's servers can decide how much device attestation they require in order to trust a connecting device. For Apple devices, attestations may include device identities, properties, and optionally other information such as certificates, profiles, and user IDs.

Using Apple Device Validation, an Apple device can be verified by receiving and believing these facts.

Device connection and verification

When an Apple device connects to the network, the servers resources on the network may request a device scan.

During this process, the connecting device is prompted to connect to any existing MDM servers, which then launches Apple's device attestation servers to validate the device using the device's Secure Enclave.

Every modern Apple device has its own built-in Secure Enclave (which includes hardware-encrypted information). When Secure Enclave verifies a device, Apple's attestation servers send a response to the organization's MDM or resource server to confirm that the device is valid.

If the verification fails, the device will be denied access to the requested organizational resource. Apple refers to this device information as the Trust Foundation, which may include:

  1. Secure Enclave
  2. Apple Attestation Servers
  3. Manufacturing records (including serial number )
  4. Operating system directory

MDM servers can issue a DeviceInformation command to an Apple device requesting device information.

Once the device attestation is returned to the MDM server, it is evaluated for validity. Device attestation tells the MDM server that there is, in fact, a valid Apple device with the requested properties.

If you are using ACME servers, you can also add an ACME payload. The ACME payload can be used in ACME attestation of a device, which further helps verify the device with a certificate.

The ACME payload supports RSA or ECSECPrimeRandom encryption, but it must be 256-bit or 384-bit.

ACME is somewhat similar to the Simple Certificate Enrollment Protocol (SCEP) used in networking equipment. Most ACME server attestations require a hardware key to ensure that the information being verified is tied to the specific connecting device.

If ACME attestation is requested, the ACME server configures and issues a new certificate that can be trusted by the rest of the organization's servers.

Note that the ACME qualification phase typically occurs only after the physical device qualification has been completed. The certificate issued by the ACME server is based on a unique, temporary, one-time private key generated by the Apple device itself.

Key exchange between the device and servers.

There are additional ways to verify the ACME payload depending on how the device is connected. These include Safari ID, Kerberos, PayloadCertificateUUID Wi-Fi, and PayloadCertificateUUID VPN.

The IETF is currently considering expanding device qualification to be included in the ACME protocol.

Each attestation may optionally use a unique nonce or random number during communication to ensure that legacy security information cannot be used twice.

This ensures that there are no man-in-the-middle attacks that can impersonate a device using a fake certificate.

If a malicious device tries to lie about the properties of an Apple device to try to impersonate the device, Apple's attestation servers will reject it and device verification will fail.

When using a combination of this reliable data, it becomes almost impossible to impersonate an Apple device. Multiple attestations can be exchanged, resulting in a chain of attestations.

When assessing device trust, each server considers the device and user security status or details, which may include:

  1. User ID
  2. Device ID
  3. Location
  4. Connection
  5. Time
  6. Device management

Architecture server

Rate Limiting

Device attestation uses significant device resources, including power. As such, Apple is limiting the number of times and frequency of requesting device attestation.

Generally, for DeviceInformation, Apple only allows one request every seven days.

The use of a new nonce in the attestation indicates that a new attestation is being requested, while the absence of a nonce indicates that the previous device attestation can be used.

Apple defines a key for attestation nonces: DeviceAttestationNonce.

For these reasons, servers or network devices should not request a new attestation as soon as possible. Instead, request it only when a device property has changed or after a certain period of time has passed.

Reaction to failed certification

Apple mentions that There is no reliable way to know why device attestation failed, only that it did.

However, if device attestation fails, the network or server should not assume the worst—the failure may be legitimate and does not necessarily indicate an attack.

Additional Resources

The above description is, of course, a gross simplification. To understand every detail of Apple device attestation, be sure to check out the Apple WWDC '22 Discover Managed Device Attestation session.

The certification process is actually quite complex and requires some study to fully understand.

Apple has a page called “Managed Device Attestation for Apple Devices” in the Apple Platform Deployment Guide.

Also check out the two WWDC sessions '22 and '23 entitled “What's New in Apple Device Management.” Over the past years, Apple has also held several WWDC sessions focused on device management in general.

For information about Apple PKI resources and certificates, see Apple PKI.

Using Apple Managed Device Attestation, you can significantly improve the security of your organization's Apple devices on your network.

You can validate devices before allowing them access to resources, and significantly reduce the likelihood that an attacker can use an Apple device as an attack vector.

Follow AppleInsider on Google News.

Leave a Reply