ACME

In the macOS 13.1 beta (4) I was able to make it accept an ACME certificate profile. Unfortunately without hardware-bound keys nor attestation, so no Managed Device Attestation possible (yet). Hopefully that follows suit. Linking this issue here for visibility: https://developer.apple.com/forums/thread/719032

Hi @MDMiOSDev and @maaino. I'm trying to deploy profile listed above. The beta returns similar errors however public iOS16 version returns internal server error. I found in logs: Cannot obtain ACME certificate: __NSCFError: Desc : internal server error Domain : NSURLErrorDomain Code : 500 any ideas?

I'm assuming EAB means External Account Binding, a part of the ACME protocol. I can't discuss Apple's plans. If you would like Apple to add support for EAB, please file feedback. In your feedback, please give a detailed reason why you want support for EAB. What's your use case? What does EAB do that cannot already be done with the ClientIdentifier?

spctl --verbose --assess --type execute -v TSR.app/ TSR.app/: rejected origin=Acme, Inc.codesign -dvv TSR.app/ Executable=/Users/edward3/Documents/projects/build-tsr-Desktop_Qt_5_5_0_clang_64bit-Release/tsr-app/TSR.app/Contents/MacOS/TSR Identifier=com.acme.tsr Format=bundle with Mach-O thin (x86_64) CodeDirectory v=20100 size=39347 flags=0x0(none) hashes=19e61+3 location=embedded Signature size=4804 Authority=Acme, Inc. Authority=DigiCert EV Code Signing CA (SHA2) Authority=DigiCert High Assurance EV Root CA Signed Time=Aug 24, 2015, 8:21:43 AM Info.plist entries=15 TeamIdentifier=not set Sealed Resources version=2 rules=12 files=39 Internal requirements count=1 size=96

The AllowAllAppsAccess key is for macOS only. It only works for ACME payloads if HardwareBound is false. On macOS there are two keychain technologies. The older file-based keychain supports AllowAllAppsAccess but does not support hardware-bound keys. You can see items in the file-based keychain using the Keychain Access app. Third party apps can access these items if they were installed with AllowAllAppsAccess set to true. The newer data protection keychain supports hardware-bound keys, and does not support AllowAllAppsAccess. Third party apps and processes cannot access the identities that device management installs into the data protection keychain (with one exception for VPN extensions). When installing an ACME payload on macOS it decides which keychain to use based upon the value of HardwareBound. Other Apple OSes only have a data protection keychain and do not have a file-based keychain, so all items go into the data protection keychain.

[quote='797344022, fxk510, /thread/760541?answerId=797344022#797344022, /profile/fxk510'] And I assume by general-purpose signing from 3rd party code you mean that Apple code might be able to do it, but we will not be able to accomplish it? [/quote] Yes, but that “general-purpose” rider is important. The key thing here is the “it” in the above quote. By “general-purpose” I’m talking about calling APIs, like SecKeyCreateSignature and Apple CryptoKit, that allow you to sign arbitrary data. Beyond that, for example, in the Platform SSO stuff, things get more nuanced. [quote='797411022, fxk510, /thread/760541?answerId=797411022#797411022, /profile/fxk510'] would an ACME certificate, which can be hardware bound, be used during the system context prior to login? [/quote] I don’t think so. I don’t know a lot about ACME, but it seems to me that they must be issued to the machine or the user. If they’re issued to the user, you can’t use them prior to login because the user’s keychain is locked. If th

I take it there is still no fix on the horizon?Has there been any murmur from ACME? Does anyone over there even give a s*** anymore?The official release of 10.13 causes the same crash. It is clearly a known/documented issue. I find it staggering that they released it without fixing this.My upgrade completed successfully. After poking around for a couple hours I thought Let's reboot and make sure we can get back in....big mistake.Has anyone successfully recovered any data from an affected machine?

@maraino Yes, we would be happy to collaborate on this. To summarize, the ACME profile only works i) if the device attestation is set to True. ii) if there's no Common Name present in the Subject of the CSR. We get this below error if we provide a CN. CSR names do not match identifiers exactly: CSR names = [test], Order names = [] We would like to understand how the Client Identifier will fit into this picture. Apologies for not getting back immediately. Thanks in advance.

I am not aware of any sample code, which is really a shame. Without sample code, writing USB serial device drivers is a very obscure science. However, if you can influence the code on the USB device you are better off implementing the USB CDC ACM protocol. That way your device appears under /dev/tty* and /dev/cu* without the need to write a device driver. And best of all, it works on Windows and Linux as well - again without device drivers. And on macOS, you probably don't want to use the /dev/tty* device but rather the /dev/cu* device. /dev/tty* is from the old days when you had a modem connected to your serial port and your software would become active if there was an incoming call.

It would be great if the device could attest that it is under management and have an OID for the check-in URL or the APNS topic is registered against. This might eliminate the ACME server's need to authorize a request against the MDM server or help improves the validation of the request etc. The only properties that could potentially appear in attestations are things that the Secure Enclave did. It's the OS's responsibility to enroll the device and keep track of the check-in URL, push topic, and other management-related properties. So to attest it, the OS would have to tell the Secure Enclave these properties. A compromised OS could lie to the Secure Enclave about these management properties. So to trust attestation of those properties, you'd have to trust the OS as well. And if you're trusting the OS, the attestation of that property isn't giving you any additional security over just asking the OS to report the property directly.

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

The passkey attestation configuration is declared here. The identity (certificate + private key) that gets installed is specified via a Declarative Device Management (DDM) Asset reference. DDM supports multiple types of certificate configurations, including ACME and SCEP. This identity will chain back to an arbitrary certificate on the MDM server. As some examples, this could be a known root certificate managed by the MDM provider and trusted by the corporate CA, or an MDM-owned certificate that was itself provisioned by the corporate CA; the details of this certificate are up to you and your MDM provider. The only requirement for the identity installed on the device is that it supports the ES256 signing algorithm (COSE identifier -7). Everything else about the certificate and how it gets installed is up to you. The attestation you get back is a basic attestation in the packed format, signed by the identity provisioned through DDM. That link specifies the verification algorithm for the attestation. F

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