What is Managed Device Attestation for iOS, iPad and tvOS?

Threats and malignancy not only emerge internally in the families of your favourite daily soaps but also in reality, at an industry level. In the former, often the incriminated protagonist offers evidence of their innocence. The same applies to Managed Device Attestation wherein a device provides proof of its authenticity. With the best regards and prayers for those bereaved fictional families, let us proceed to know more about one of the latest security features for managed devices to prevent enterprise-level mishaps.

Apple has come up with a key contemporary security feature to help organisations improve their device management capabilities when it comes to protecting their resources from attackers. In addition to the lockdown mode, which shields users against highly targeted mercenary spyware, Managed Device Attestation adds an extra protective layer for iOS, iPad, and tvOS.

Security then vs. Security now

Any organisation’s quintessential security feature is a perimeter around the company’s resources with an added firewall and VPNs. Although, as technology evolves, it has become easier for attackers to penetrate through the boundaries and exploit the data by pretending to be a genuine user. Moreover, cloud service providers store resources outside the previously mentioned perimeter which is more prone to external strikes. Also, threats may emerge internally.

The modern-day concept of a security landscape is locking every resource and following a Zero Touch Architecture. The core principle behind this architecture is Trust Evaluation which is a function for each of these resources, where the posture information of the client is the input and the result is the decision whether to accept or reject the request. Having accurate posture information is critical; otherwise, the attacker may find a way to penetrate and mishandle the resources.

“Knock-knock, who’s there?”

What consists of posture information? It contains the particulars about your device, namely- user identity, device identity, location, connectivity, time, device management, etc.

These different factors can be judged based on the type of resource being accessed. A piece of less critical information may need just one detail (usually the user identity) but highly confidential data may require all of the fields. It is up to your company to determine the posture information.

“Speaking of the MDM”

Prove a device’s identity with Managed Device Attestation

When making a request, a device can vouch for itself with Managed Device Attestation. Trust evaluations based on improved posture information are more reliable. Managed Device Attestation, in essence, ensures that genuine devices can access resources reliably while preventing attackers.

“The truth must prevail”

Attestation can be defined as a declaration of a fact that when trusted, is accepted. The facts for Managed Device Attestation are the identity and other characteristics of a device, and Apple is the signer. Trusting Apple is necessary in order to accept the validity of these device facts. It only needs to trust the Secure Enclave and the attestation servers belonging to Apple, which contain information about Apple’s operating system database and manufacturing records.

“Two is better than one”

When it comes to Managed Device Attestation, there are two ways in which it can be executed for managed devices to avail their attestation certificates. The DeviceInformation command enables the MDM server to surf through the attestation and through the ACME (Automated Certificate Management Environment) Profile Payload, which is very similar to the SCEP payload, the benefits of the attestation are made available throughout the organisation’s network.

The MDM server sends a DeviceInformation query which includes several key codes. From Apple’s servers, the device requests an attestation, which it then transmits to the MDM server. The MDM server then assesses the attestation. Sometimes it may claim that a device may exist with the same properties. This results in the requirement of the ACME Payload attestation.

With ACME payload attestation, one can yield the most secure evidence of device identity. The proof received is genuine and contains information about the hardware, device ID, its properties, hardware-bound keys, etc.

The Lie Detector – How attestations prevent threats

A compromised device would try concealing the truth about its properties. Apple points to attesting the same. The attestation would not be affected even if the OS is disputed. What if a faulty machine furnishes age-old certificates? The accuracy of the information is guaranteed by a “Nonce” in the attestation. ACME payload attestation reduces additional risks. When contacting the MDM server, a compromised device transmits the identifiers of other devices. Apple is responsible for verifying device identifiers through which it relates its ID to the user identity. Thus, confirming a TLS link. Moreover, the servers belonging to both your MDM and your establishment will correctly match the devices during communication.

An attacker may pretend to be a valid device by extracting a private key from it and using it to perform requests. A valid device could be faked by an attacker taking a private key from it and using it to perform requests. Apple certifies that the Secure Enclave, which has incredibly robust safeguards against exporting or importing private keys, is protecting the same. Finally, threats may occur when an impersonator manages to get a certificate issued from a certificate authority from a separate, stolen machine. In this regard, Apple should be applauded for making the certificate authority hold prominence over requesting devices and linking their certificate needs.

Implementing Managed Device Attestation

Shedding more light on the ACME Profile Payload Attestation, we begin with the MDM server. It must first install a profile with an ACME payload before continuing. The payload is like a handbook here, containing all the details of the what’s and how’s. The device constructs the required key to begin installing the profile.

The device acquires a DirectoryURL, which indicates the URLs to access, in order to maintain its connection with the ACME server. Then, the two systems generate an order and an account. The device in the token field receives a nonce that was generated by the ACME server and sent through it. Initially, server certificates were generated via the ACME protocol.

The device sends a certificate signing request that includes the payload’s certificate request characteristics. The ACME server should extensively authenticate the query before granting a certificate. It needs to make sure the ClientIdentifier is genuine and unutilised. The proper Apple CA must be the chain-up point for the attestation certificate. It would be valid to say that the ACME server issues the final word. The CSR’s properties, such as the SubjectAltName, can be honoured or overridden. The ACME payload installation is finished when the certificate is saved on the device in the keychain.

“Bringing it all together”

How can servers verify the device contacting them is actually the one it says it is? Only one private key is used by the device for many purposes, including receiving an acknowledgement from Apple, being in touch with other servers through TLS, and requesting an ACME server client certificate. We know that all of these activities were carried out by the same device since the key is hardware-bound. Additionally, the item is described in an attestation certificate we have. By combining these, organisation servers may now provide access with the assurance that the device is who it claims to be. You may apply the same for Wi-Fi, VPNs, Safari, Kerberos…you name it and it shall be covered.

Some bitter pills to swallow

While Managed Device Attestation brings you an array of benefits, it also comes with a set of limitations. Up to ten attestation-using, ACME payloads can be deployed concurrently on a single device. It should be remembered that even when rebooting to the same machine, hardware-bound keys will not be saved when executing a managed device’s backup. The MDM client identity gets an ACME payload, if you don’t do anything else with Managed Device Attestation, so the MDM server recognizes the device being managed.

Moreover, there is a curb on the frequency of requests for fresh attestation certificates. Typically, a new attestation can be issued per week, because creating new attestations consumes a lot of resources on the device and Apple’s servers. By providing a new nonce, you ask for a new attestation.

But just because there is a rate cap doesn’t mean you should request a new attestation every week. In addition to wasting resources, doing that will just slow down the MDM server detecting changes in device attributes. As an alternative, keep an eye out for changes to other DeviceInformation properties, like the OS version. Once one of those changes, you should ask for a new attestation. By doing this, it is made sure that the attestation is updated as soon as a change is made rather than allowing the rate limit to run out. Add the sporadic random request for a new attestation to keep the device honest in case it is compromised.

Conclusion

Managed Device Attestation brings about a revolutionary protective addition for managed devices to ensure safety at all levels and mitigate threats. To enhance the device identity aspect of your machine’s posture information, the DeviceInformation attestation can come into use for a smoother Trust Evaluation.

In a way, this attestation is not just about preventing malignancy from penetrating but also ensuring the integrity of devices remaining intact; a ‘happily ever after’ that we all hope to achieve without getting our ‘Apples’ poisoned!