Hello! Thank you for your response regarding the key attestation and for clarifying the "storage of Secure Enclave” keys. I was confused by the description of kSecAttrTokenIDSecureEnclave (https://developer.apple.com/documentation/security/ksecattrtokenidsecureenclave?language=objc), which explicitly states that items created with this parameter are stored in the Secure Enclave. Can you confirm that operations involving keys protected by the Secure Enclave are performed within the SEP and that no private data leaves the SEP during these operations? Thanks!

Hello everyone, following up on the question asked and the answer provided, on iOS now, I get the impression that App Attest allows us to get an attestation from Apple about the fact that the environment on which the app is installed can be trusted. Unless I'm mistaken, I don't believe the App Attest mechanism can specifically certifies that a key created within the app (SecKeyCreateRandomKey with kSecAttrTokenIDSecureEnclave) is actually located in the Secure Enclave. If that's the case, is there another process on iOS that allows us to get a certification from Apple regarding this point? (this certification for instance could be provided to a remote server for validation) Thanks!

The thing is com.apple.developer.nfc.readersession.iso7816.select-identifiers Info.plist record is also needed in order to work with smart cards through CoreNFC API, but the specific A000000308000010000100 is not required in this record, whereas it seems to be the case with CryptoTokenKit API. It seems weird to me that this behavior occurs on every smart card, independently of what it contains, whereas an AID it the Info.plist record should be needed only if corresponds to an application in the smart card. I can ensure this issue happens on a smart card which does not contain any application with the A000000308000010000100 ID. I understand by reading the Apple documentation (https://support.apple.com/en-gb/guide/deployment/depd0b888248/web), that PIV smart cards have a native support from iOS 16.1. Thus, I believe it is not a coincidence that this AID, which seems to be mandatory for every smart card, is related to PIV. Could it be possible that there is a kind of "system default" CryptoTokenKit supporting PIV cards which could have an influence on the behavior of other apps/CTK extensions ? My main concern is that as this specific AID is not mentioned in the Apple documentation, there could be other hidden ones which would be mandatory in some cases in order to work with any smart card.

Thank you for the answer. The sysdiagnose log should be now completely uploaded to Feedback Assistant with the FB22339746 bug report.

Hello, We asked Apple if it is possible to use our iPad USBDriverKit driver on the iPhone 15, and they told us that it is not supported.

This was our problem indeed. Although not conformant to the Apple specs, it used to work, and it wouldn't since Ventura. Thanks Eskimo for the help on that.

No, we had no contact with this person. However, I have no doubt that, if he is using smart cards for his auth, and it used to work and not working anymore with Ventura, it is the same problem: basically, CryptoTokenKit smart card drivers don't work at all anymore, so it is easy to diagnose. By the way, I had no response from the feedback I sent through the assistant. This is becoming critical now that Ventura is out. Is there any way to push this, either from my side or your side? Thank you.

Hi, thank you for your interest in this. I was kinda hoping you would hop in... The feedback ticket is FB11675669 (https://feedbackassistant.apple.com/feedback/11675669). For information, the CryptokTokenKit is still called successfully when the card is inserted, and we can return some certificates when the smart card content is queried, but it is never called later when an application tries to make use of KeyChain APIs. All the calls we see are successfull, and seem to return the correct information, but it just goes blank at some point.