We all enjoy watching the exciting stuff around WWDC like new Macs, iOS 16 consumer features, etc, but some stuff is not as noticeable. Apple is addressing a few crucial enterprise concerns, which is what we will be talking about today. Features like endpoint security and attestation are becoming staples of the security industry.

Zero Trust is at the forefront of everyones mind in a quasi Post-COVID world. A few areas that Apple has announced enhancements are with endpoint security and device trust. Today, we will cover these areas along with some of the underpinning technologies that might be new to us.

WWDC Announcements on Endpoint Security

Apple released Endpoint Security back in MacOS Catalina when they deprecated KAuth and OpenBSM audit APIs along with the unsupported MAC Kernel Framework.

This change is why you no longer need Kernel Extensions (KEXTs). The Endpoint Security frameworks enable your ability to build products like Symantec DLP (DLP Solutions) or Crowdstrike (EDR Solutions).

When they released this for Catalina, it only supported critical events like forking processes, opening files, and kernel events. By Monterey, that meant around 100 events.

This year, crucial new events like authentication, xProtect, and Login/Logout are now supported. That level of visibility is HUGE for the enterprise especially those who refuse to see Macs as not Windows.

Authentication Events

Some of the examples of authentication events are:

• Password Auth
• Touch ID Auth
• Cryptographic Tokens
• Auto Unlock

The only way you could look at these events was by using deprecated technologies like OpenBSM.

Login/Logout Events

Some of the examples of these events are:

• Login Window
• Screen Sharing
• SSH
• /usr/bin/login

This is a huge step-up because you can see lateral movement across device suites, see remote access attempts, and virtually any event that gets you access to the system.

Gatekeeper events are a whole other story. Now we can get insight into malicious software detection and remediation. It would be nice if you could see any application launches, but what we are getting here in Ventura is a big help.

Muting with Precision Coming with Ventura

Catalina introduced muting via audit token or executable image path. It helps with preventing deadlocks, hangs, etc. It also helps with performance impact.

Some event types started being muted last year to help with system stability. NOW, with Ventura you can use target path muting, which gives you PRECISION!

These are now event specific where you can also use target process executable image path as shown in the code below:

Mute inversion is also being added which lets you reverse mute so you only receive the events you actually care about, which makes a huge difference in performance. As an example you can see below, you can target file events for specific target paths:

FINALLY ESLOGGER!!!!

Sorry my friends at JAMF/CMDReporter, but FINALLY we can now leverage our security products to ingest MacOS events without needing a 3rd party tool.

ESLogger will ship with MacOS Ventura and will be able to capture events formatted with JSON to allow ingestion into services. This is a huge difference and should hopefully let us simplify our MacOS stack. ESLogger does require root and TCC Full Disk Access authorization, but thats fairly obvious.

You can invoke ESLogger via terminal and here is an example of the raw JSON:

Managed Device Attestation

Something that I have been waiting for someone to emulate is Workspace ONE Access model for Device Compliance. Lets talk about how that works real quick.

The basic idea, is that you have a certificate with its UDID in the Subject Alternative Name field like so:

By having the UDID, you can leverage the API to validate the health and state of the device. This is used for MFA/Zero Trust by not just validating the identity of the user, but also the device state. In Zero Trust, we dont trust the perimeter or really ANYTHING so it makes 100% sense. I covered this last year in my Zero Trust guide. Apple has a nifty little picture of that on the slides:

Anyways, thats the idea without going too crazy. People hammer Zero Trust to death, so I dont find the need to do so. Attestation will focus on device identity. My article from last week, covers user authentication with some of the user identity concepts aka enrollment SSO and platform SSO.

To discuss Device Attestation, were going to cover the new requirements, what Apple changed to adapt to these new capabilities, and what exactly Device Attestation is.

What is Managed Device Attestation

Simply, attestation means that you are making a statement of fact. This means in Apple that you trust the following:

• Apples Secure Enclave
• Apples Attestation Servers
• Manufacturing Records
• The OS Catalog

Most of that you already trust except the attestation servers today. You will essentially leverage a special type of Certificate Authority called an ACME server, use ACME certificate request payloads, and special queries to facilitate the entire thing.

ACME: No NOT THAT ACME!

Did Apple finally sign a deal with the bad guys?!

No, not THAT ACME. Were talking about the Automatic Certificate Management Environment. This is going to be one of the key requirements for Device Attestation. Lets discuss what it is.

ACME was originally created by the Internet Security Research Group (ISRG) for its certificate service, which you may know as Lets Encrypt.

ACME is somewhat similar to services like SCEP. Ive actually reached out to SCEPman to see if they have plans to support ACME.

ACME streamlines and automates difficult processes like CSR generation, domain ownership verification, issuing certificates, and installing those certificates. The main use-case for ACME is for domain validation certificates (DVs).

ACME can also be used for organization validated (OV) and extended validation (EV) certificates. Those typically requires additional middleware coupled with the ACME agent. This process requires an ACME client and server which creates a secure connection like other certificate automation efforts by UEM vendors like Workspace ONE, JAMF, and Microsoft Endpoint Manager. It will primarily pass JSON back and forth over the SSL tunnel.

From the perspective of this article, the ACME client will live on iOS 16, iPadOS 16, and tvOS 16. You will only need an ACME server (if your MDM server doesn’t provide it). A few examples of things that provide ACME servers are:

• PrimeKey EJBCA (One of the most popular CAs today)
• LetsEncrypt
• GlobalSign
• Entrust

In my opinion, PrimeKey is the best option as theyre a full Enterprise CA and probably a more palatable option than buying individual certificates. You can obviously host your own open source ACME server, but it might be more practical to look at one of the options above.

Creating a SmallStep ACME Server Internally

I sorta needed to show you guys and girls how to build your own ACME server since its a REQUIREMENT right?! Check the demo below on how to build a Step ACME Server on Ubuntu. By no means is my setup perfect and I wasn’t shooting for that. I mainly wanted to show you all what a basic install would look like. You could have setup separate user accounts to run the Step service and do all sorts of smarter things than me. This is just a rudimentary setup to give you a better idea. It’s mostly moot at this point since the device-attest-01 extension proposal hasn’t been implemented from what I’ve seen.

What Apple Changes to Support Device Attestation

As you can see below, Apple introduces two new things in iOS 16, iPadOS 16, and tvOS 16. to make Device Attestation come to life. As I mentioned earlier.

DeviceInformation Queries that Enhance Attestation

The DeviceInformation query can now obtain and return attestation data from the device. That way the MDM server can evaluate the attestation. This is done with the DevicePropertiesAttestation request which is added to the queries array (aka you will see this in the future in your MDM console as a query type).

At that same level, the Device Attestation Nonce key exists now. Its an optional key that can be up to 32 bytes. An example can be seen below:

The response to that request above is the attestation. It provides back a DevicePropertiesAttestation key which is an array of data including a certificate and its full chain:

The device properties are returned within that certificate data in OIDs like other certificates. You will see the serial number and UDID like below:

Serial Number and UDID are omitted if the enrollment type is user enrollment, but that is not all that common in enterprise.

It will then validate the attestation by validating the Apple Enterprise Attestation Root CA, verify a valid nonce, and parse/evaluate the other OIDs.

The last thing to point out is that they throttle the validation to one request every 7 days. You can request a fresh attestation if you specify the nonce. You should omit the nonce if freshness is not a concern. By design, the MDM vendor should design their implementation to only refresh the attestation when things change, such as OS updates.

Failures could also happen because of network issues, attestation server issues, hardware changes, etc. but that is something your MDM vendor needs to account for. The MDM vendor needs to build logic properly to account for failures.

The ACME Payload

The ACME Payload that we mentioned earlier, is the source of truth of the devices attestation. That certificate is delivered to the device that your organization trusts. This will prove a few things:

• Apple Device is genuine
• Proves the Devices Identity
• Identifies Device Properties
• Provides the Device has a Private Key in Its Secure Enclave for the Attestation Certificate
• Proves to all Servers Your Device is Trusted and the Same Device

Some of the ways this protects against attackers:

1. Apple attests to the device properties whereas a compromised device will lie.
2. The attestation nonce will prove the devices data is current.
3. Apple attests the device identifier.
4. Private key is protected in the Secure Enclave, which has many mitigations against exporting.
5. Apple attests the identity of the requesting device so that your CA only issues certs to the device.

The ACME Payload Flow

Lets cover what the ACME Payload Flow looks like. It can be a little daunting so lets see if I can help you understand it by breaking it down.

MDM Server Payload Installation

First, the MDM server installs the payload:

The payload contains:

• Key properties (Key Type, Size, and if Private Key in stored on the hardware)
• Certificate Request details (Key Usage, EKUs, Subject, SANs)
• ACME Request details (ACME server URL, client ID, whether or not to use the certificate for attestation)

Next, for the device to use the profile the private key must be hardware-bound. That key must house ECSECPrimeRandom for attestation (ACME also supports RSA, but that wont work here). Ideally, you will use 384-bit ECSECPrimeRandom keys.

ACME Server Certificate Request

Now, it will send the request to the ACME server:

Now a series of things occurs:

• Device connects to the ACME Server URL over HTTPs
• An account and order is created between the two systems
• The ACME server returns the device-attest-01 validation type
• None is generated in the token field

After the device creates the connection to the ACME Server URL, an account and order will be created on the ACME server. The ACME server will return the device-attest-01 validation type.

Attestation Server Flow

When you specify Attest in the payload it will talk to the attestation server next:

When the attestation request happens, its similar to the previous requests with the ACME server. The same OIDs are used, but the nonce is hashed with SHA-256 (and comes from the ACME server). The private key that matches the leaf certificate is also delivered in that request.

When communicating with the attestation server, a new certificate is requested. The device passes the CSR, the attestation chain, and the ClientIdentifier from the ACME payload. This works very similar like tickets with Kerberos.

Finishing up the Attestation Flow

The ACME server performs these checks below to ensure attestation is secure:

Now things finish up to complete the device attestation flow:

The certificate itself doesnt need to match the payload. Once its stored in the keychain the payload install is completed.

So the question is, how do all of your servers know it the same device. Its essentially two-factor:

1. The Device uses the same private key in various ways whether its talking to the attestation server, talking to the ACME server, or organizational servers.
2. Because the encryption key is hardware bound, we know it all comes from the same device.
3. We also have an attestation certificate describing that device, which gives your servers a high level of confidence.

Who Can Use the Attestation?

Several systems can use attestation by referencing the ACME payload UUID, such as: (up to 10 can be used simultaneously)

• MDM Identity Certificate
• Wi-Fi Certificates
• VPN Certificates
• Kerberos Certificates
• Safari Client ID

One note is that on device restoration, the hardware-bound keys are not preserved.

Some Thoughts on Device Attestation

So.. that was so MUCH right? Clearly, its crazy. Device attestation is a huge lift honestly. Any company that is just using ADCS is going to have to make some tough decisions.

Do I consider moving to PrimeKey? (Its super expensive) Or, do I build an internal ACME server? Its going to be a tough thing to consider, but the benefits are so huge. We are constantly facing risks around spoofing, MITM and a litany of other attacks.

Being able to prove that a device is EXACTLY what it SAYS it IS is invaluable. If you are like most companies and are investing heavily on Zero Trust, this is 100% necessary. The tech debt is a bit frustrating since its even more certificates you need to manage, but we know how it works. Apple provides opportunities and its up to you to take advantage of them.

Closing Thoughts

Overall, the security enhancements introduced in 2022 at WWDC are amazing. Apple buying into Zero Trust and supporting the initiatives of many is surprisingly clairvoyant of them. Apple who is primarily a prosumer company is showing their commitment to the enterprise.

Between Attestation and the Endpoint Security enhancements, we are becoming smarter and building insights that help tighten the perimeter. That is the spirit of the Zero Trust era and not