This does not actually symbolicate the crash log for me. I filed FB13543963 about this.

FWIW: If so, the next step is to confirm that the data and its signature made it to your server intact. On both the iOS and server side, generate an independent hash of the data and the signature and check that they match. Turns out this was the issue, the cause being the same as the one discussed in this thread. But thanks anyway.

@eskimo I am not really getting anywhere with this so far other than that I can confirm the problem still persists in yesterday's beta 7. Would it be helpful if I opened a DTS incident for this?

Thank you for the clarification. I had hoped, though, that there was a way to proceed (the certificate the SPKI fingerprint from the Info.plist belongs to may since have expired, but the app may have knowledge of the current certificate's SPKI hash).

For the record: I suspect that you may be able to do this using one of the data representations, but I’ve not investigated that in depth. I tried converting a Keychain key to a CryptoKit key by utilising SecKeyCopyExternalRepresentation(_:_:), but as the documentation suggests that does not work: The operation couldn’t be completed. (OSStatus error -4 - export not implemented for key <SecKeyRef:('com.apple.setoken') (which should be errSecUnimplemented).

Thanks Quinn. Would it be possible then for someone other than Apple to create a profile (with a payload unrelated to logging) that auto-expires after installation?

Thanks Quinn, I did as you suggested (FB12036482).

I dug a little deeper (thanks, Quinn!) and found two possibly related errors in the system log. errSecNoSuchAttr seems to be caused by error:[-25303] Error Domain=NSOSStatusErrorDomain Code=-25303 "attribute u_CredRef not found in class keys" UserInfo={numberOfErrorsDeep=0, NSDescription=attribute u_CredRef not found in class keys} while errSecAuthFailed seems to be a fallout from evaluateAccessControl on LAContext[5448:4] cid:17 returned Error Domain=com.apple.LocalAuthentication Code=-1009 "ACL operation is not allowed: 'oe'" UserInfo={NSDebugDescription=ACL operation is not allowed: 'oe', NSLocalizedDescription=Vorgang ist nicht zulässig.} I filed this as FB11884381, FWIW.

Update: The documentation for SecItemUpdate includes the following w.r.t. the attributesToUpdate dictionary: Only real keychain attributes are permitted in this dictionary (no "meta" attributes are allowed.)  It is unclear (at least to me) what those "meta" attributes may be. Is kSecAttrAccessControl maybe one of them?

Thanks Quinn, here its is: https://developer.apple.com/forums/thread/720592

Have you tried calling  SecItemUpdate to change the  kSecAttrAccessControl value on the private key item? I'm currently struggling trying to do just that in a context where I have a private key inside the Secure Enclave further protected by an application password which I want to change. I have been unsuccessful getting the queryand attributesToUpdate dictionaries right though, with SecItemUpdate returning either errSecParam or errSecNoSuchAttr. Am I on the right track here or am I trying to do something that is not possible?

Hi Quinn, did anything ever come out of this?

Thanks again. Do you deem it worthwile to file an enhancement request asking for API parity in this regard (i.e. by providing an initializer on SecureEnclave.P256.Signing.PrivateKeythat takes a parameter akin to kSecAttrIsPermanent)?

Ok, I think I am getting close. So while SE keys are not actually stored inside the Secure Enclave keys generated by the Security framework are (or can be, depending on whether kSecAttrIsPermanentis set or not) stored in the keychain. Keys generated by Apple CryptoKit are not stored at all and there is no way to convert between the two kinds of keys. Correct?

Thanks Quinn! You know, there are days where I feel I would not get anything done without you helping me out... Does that mean the dataRepresentation of a SecureEnclave.P256.Signing.PrivateKey is already stored in the keychain by the system, but is inaccessible to client code so the only way for it to get a reference to such a key is to store the dataRepresentation itself and recreate the key from it? And if the key had instead been created by not using CryptoKit, but the Security framework (passing .privateKeyUsage in the access control list) it could later be retrieved by SecItemCopyMatching, correct?