Post

Replies

Boosts

Views

Activity

Reply to How to persist SecureEnclave.P256.Signing.PrivateKey
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).
Jun ’23
Reply to Using SecItemUpdate to change the kSecAttrAccessControl value of a private key protected by the Secure Enclave
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.
Dec ’22
Reply to Use kSecAttrAccessControl to only protect the private key in a SecIdentityRef
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?
Nov ’22
Reply to How to persist SecureEnclave.P256.Signing.PrivateKey
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?
Jun ’22
Reply to How to persist SecureEnclave.P256.Signing.PrivateKey
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?
Jun ’22
Reply to Use nscurl with client certificate?
Why do you need this in nscurl specifically? Mostly just to understand how specific status codes are handled on iOS. To elaborate: I have been hitting the same issue described here and here - the URL Loading System raises an error if it receives a response with the status code 403 and a client certificate was involved in the handshake (regardless of whether the certificate was accepted or not). I (re-)raised this as FB10026351. In my case all requests to the server require client authentication and the server may return 403 for unrelated reasons (e.g. for domain errors). The server team agreed to use a different status code for those cases but wanted me to make sure they don't pick one where a similar situation could arise. In my lab appointment the network engineer pointed out that there are in fact status codes other than 403 that receive special treatment and suggested using nscurl to quickly check how specific status codes are handled, but apparently the behaviour changes if a client certificate is involved. Here is what I found: Without client authentication: If no client certificate is involved and the server responds with 401 the client gets an error (NSURLErrorCannotConnectToHost) If no client certificate is involved and the server responds with 403 the client gets the response With client authentication: If a (valid) client certificate is involved and the server responds with 401 the client gets the response If a (valid) client certificate is involved and the server responds with 403 the client gets an error (NSURLErrorClientCertificateRequired) However, the scenarios involving a client certificate cannot be tested with nscurl, hence my question.
Jun ’22