ACME

For additional security we would like to avoid keeping generated certificates (their private keys) on our server after installing them on a device, This is a very good goal for security. However it still involves the movement of private keys, which is inherently less secure than a system where the private key never moves. Apple devices offer support for ACME and SCEP. With those protocols the private key is generated on the device and never moves. In addition Apple's support for ACME includes support for hardware-bound keys, which offer very strong protections against exporting private keys. Considering your attention to the security of your architecture, I would strongly suggest adopting ACME instead of identities generated by your MDM server. That aside, configuration profiles require that (in nearly all cases) when one payload references another payload, both payloads must be in the same configuration profile. That requirement applies to all identity types (PKCS12, ACME

I have a USB composite device with multiple interfaces that support CDC-ACM UARTs. My custom driver (.dext) loads and works for a single-channel USB-CDC-CCM device with these entries in the Info.plist: Two different answers here: (1) The IOKitPersonalities dictionary is basically a list* of specific match criteria, each of which is treated independently by the kernel. So the (general) way you match the same driver against different hardware configurations is by defining a separate personality dictionary for each configuration. See this Info.plist for a concrete example of this: /System/Library/DriverExtensions/com.apple.AppleUserHIDDrivers.dext/Info.plist Note that IOKitPersonalities is defined as a dictionary (instead of an array) because the top-level key value ends up being used in the IORegistry (it's returned by IORegistryEntryGetName), and using a dictionary ensures that the entry names are unambiguous within a given driver bundle. The keys themselves are not meaningful, nor does entry order ma

The developer figured it out. It doesn't match the nonce because Apple isn't using the nonce for ACME. Apple is using the challenge token. The challenge token hashes to an exact match of the freshness code OID. From device-attest-01: { type: device-attest-01, url: https://example.com/acme/chall/Rg5dV14Gh1Q, status: pending, token: evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA } { protected: base64url({ alg: ES256, kid: https://example.com/acme/acct/evOfKhNU60wg, nonce: SS2sSl1PtspvFZ08kNtzKd, url: https://example.com/acme/chall/Rg5dV14Gh1Q }), payload: base64url({ attObj: base64url(/* WebAuthn attestation object */), }), signature: Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4 } It may be the case that the term nonce is being used too loosely, which unfortunately is a dangerous thing when it has an actual definition in this protocol. We lost the best part of a week to this. ACME YAML needs to be corrected. I can't quite re-find the other instances I thought I saw claiming it's

I updated the Mac to 24F74 yesterday. So, there is a new attestation certificate today. Again, the contents of the freshness code OID do not match any hash of the nonces sent by the server. Does macOS store the nonce in a retrievable way or can we put something into debug mode and have it record what it's sending and receiving from the ACME server? It's like something is being lost in translation.

Thank you. I think this is an issue that only occurs during the development stage, if you don't have the server side validation step in place when you start testing the previous steps. So, I extracted the attestation certificate (to view with the UI) which had a timestamp of Mon May 5th at 21:18 GMT+1. My Mac is sending this same certificate for every request. I take it then that this won't change until there is a change to the information it contains, e.g. a software update, or it expires? I can't match the OID to any of the nonces that the ACME server sent that day. I'm not sure why there is such a discrepancy between the certificate start timestamp and when the actual transactions took place. I see a nonce generated at 19:16 and then another at 23:24. Is there something about the encoding of the OID that we're missing? The hex we see in the certificate, is it directly the SHA256 hash of the relevant nonce? So, if the nonce sent was: SS2sSl1PtspvFZ08kNtzKd Then the hex I should see in the certifica

First some background: There are two different features that use Managed Device Attestation: ACME attestation and DeviceInformation attestation. When you mention 7 days, that likely refers to the rate limit that applies to DeviceInformation attestation. ACME attestation only generates an attestation at the time the key is initially generated, so there's no 7 day rate limit. The freshness code OID is also different between the two features. For DeviceInformation attestation the freshness code is the value from the DeviceInformation command's DeviceAttestationNonce key. For ACME attestation, it's a SHA256 hash of the nonce specified by the ACME server in its response containing the device-attest-01 challenge. When the documentation uses the term matches, it means that the ACME server should hash the nonce it previously sent and compare that to the value in the freshness code OID.

Log in iPAD17 (section A) DExt's entry points are called in this sample within <1sec after plugin (1 or 3 times). 2 of 3 times those are called >5 sec later. Here are messages change handling USB2<=>USB3 (the gadget is actually USB2) efault 09:42:58.561261+0900 kernel IOAccessoryManagerUSBC::setLDCMPin(): ldcmPin: 2 [Trace] default 09:42:58.561335+0900 kernel IOAccessoryManagerUSBC::setLDCMPin(): ldcmPin: 2 [Trace] default 09:42:58.561851+0900 kernel IOPort::setLDCMState(): [Port-USB-C@1] setLDCMState: 3 [Measure] default 09:42:58.683860+0900 kernel wlan0:com.apple.p2p: reportDataPathEvents[6702]: WiFi default 09:42:58.747963+0900 kernel IOPortTransportState::handleStateChange(): [Port-USB-C@1: USB3] Handling state change... default 09:42:58.748028+0900 kernel IOServiceNotificationManager::sendMessages(): [Port-USB-C@1/USB3] Sending 2 message(s)... (m_propertyChanged: YES) default 09:42:58.748210+0900 kernel IOPortTransportState::handleStateChange(): [Port-USB-C@1: USB2] Handling state change... d