Hello everyone, I'm trying to understand the actual limitations of the Secure Enclave (SEP) regarding cryptographic key capabilities, and more specifically how to generate and store the following key types in the keychain: Sign only: The key can only be used for digital signatures. Key agreement only: The key can only be used for key agreement operations. All operations: The key can be used for both signing and key agreement. I've noticed some apparent differences between Apple's Security framework and CryptoKit, and I'm trying to understand whether these differences reflect actual SEP limitations or simply framework-level restrictions. 1. Security framework: dual purpose keys I'm currently using SecKeyCreateRandomKey to generate Secure Enclave-backed keys. Here is the relevant code: NSDictionary *privateAttributes = @{ (__bridge id)kSecAttrIsPermanent : @YES, (__bridge id)kSecAttrAccessControl : ..., (__bridge id)kSecAttrApplicationTag : ..., // key agreement only (__bridge id)kSecAttrCanSign: @NO, (__bridge id)kSecAttrCanDerive: @YES }; NSMutableDictionary *attributes = [ @{ (__bridge id)kSecAttrKeyType : (__bridge id)kSecAttrKeyTypeECSECPrimeRandom, (__bridge id)kSecAttrTokenID : (__bridge id)kSecAttrTokenIDSecureEnclave, (__bridge id)kSecAttrKeySizeInBits : @256, (__bridge id)kSecPrivateKeyAttrs : privateAttributes } mutableCopy ]; CFErrorRef generationError = nullptr; SecKeyRef privateKey = SecKeyCreateRandomKey( (__bridge CFDictionaryRef)attributes, &generationError );However, when experimenting with these attributes, I encountered the following error: SecKeyCreateRandomKey failed: Error Domain=NSOSStatusErrorDomain Code=-50 "Failed to generate keypair" Underlying error: Error Domain=CryptoTokenKit Code=-8 "sepkey: sign requires '1' value when present"Using signing-only attributes results in the same kind of error. This makes me wonder whether the Security framework actually allows generating (and adding entries in the keyChain) only keys with both capabilities enabled. It is possible to create siging only key or key agreement only key with Security framework? 2. CryptoKit: Separate key types On the other hand, CryptoKit seems to expose two distinct Secure Enclave key types: P256.SecureEnclave.Signing.PrivateKey P256.SecureEnclave.KeyAgreement.PrivateKeyFrom the API design, it appears that CryptoKit only allows creating keys dedicated to one operation or the other. For example, a Signing.PrivateKey cannot be used for key agreement, and a KeyAgreement.PrivateKey cannot be used for signing. Is it possible to create both capabilities keys with CryptoKit framework? 3. Actual Secure Enclave limitations What are the actual cryptographic capability limitations imposed by the SEP itself? I'd particularly like to understand which restrictions originate from: The Secure Enclave hardware. Security and CryptoKit frameworks. Is there a documented way to generate and store in the keychain: A signing-only Secure Enclave key? A key-agreement-only Secure Enclave key? A Secure Enclave key supporting both operations? Thanks in advance, Idopte

I am using the CryptoTokenKit API in order to communicate with smart cards through NFC, with TKSmartCardSlotNFCSession. I call the createNFCSlotWithMessage method from TKSmartCardSlotManager, which displays successfuly the NFC dialog. However, when I put any smart card next to the phone, the NFC dialog shuts down instantly. I notice the following log in the system console: -[_NFReaderSession(Entitlement) validateAID:allowsPrefixMatch:]:317 Non-permissible identifier: A000000308000010000100 When I add the A000000308000010000100 AID mentioned in the error message to the Info.plist of my application, the NFC dialog does not shut down anymore and I am able to communicate with the smart card (using TKSmartCard). This behavior has been reproduced on an iPhone 16e, iOS 26.4. This AID does not correspond to anything in the smart card. It seems to be related to PIV, but this behavior also occurs with cards that are not PIV (PKCS#15...). Also, with an implementation using CoreNFC API instead of CryptoTokenKit API, this AID is not needed to be able to communicate with the card, so it seems CryptoTokenKit-specific. I did not find anything related to this in the documentation, have I missed something here ? Is this a special AID that is required all the time to work with NFC through CryptoTokenKit ?

We are using the CryptoTokenKit framework, specifically the classes TKSmartCardSlotManager, TKSmartCardSlot, and TKSmartCard, to communicate with smart cards through external USB readers on iOS and iPadOS. In most cases, we are able to detect readers via TKSmartCardSlotManager, and send APDU commands using transmitRequest method, with the following code (where self->_slot and self->_card are previously created TkSmartCardSlot and TkSmartCard, respectively): #import <CryptoTokenKit/CryptoTokenKit.h> - (NSData *)sendCardCommand:(NSData *)command { if (!self->_card || !self->_card.valid || self->_slot.state != TKSmartCardSlotStateValidCard) return nil; NSMutableData *res = [[NSMutableData alloc] init]; NSError *sessionError = nil; [self->_card inSessionWithError:&sessionError executeBlock:^BOOL(NSError **error) { dispatch_semaphore_t semaphore = dispatch_semaphore_create(0); try { [self->_card transmitRequest:command reply:^(NSData * _Nullable response, NSError* _Nullable apduError) { if (apduError != nil) self->_error = apduError; else [res appendData: response]; dispatch_semaphore_signal(semaphore); }]; } catch (NSException *exception) { dispatch_semaphore_signal(semaphore); } dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER); if (res.length == 0) return NO; return YES; }]; return res; } However, with certain other USB smart card readers, we occasionally encounter APDU communication failures when calling transmitRequest (for instance, with a HID Global OMNIKEY 5422), which returns the following error: "Domain: CryptoTokenKit Code: -2". Once a failure occurs and transmitRequest starts returning this error, all subsequent calls to transmitRequest fail with the same error. This persists even when: A different smart card is inserted The same card is reinserted A different USB reader (previously working correctly) is connected The TKSmartCard object is recreated via makeSmartCard The slot state changes (observed via KVO) All internal objects (TKSmartCard, TKSmartCardSlot) are reset in the application At this point, the system appears to be stuck in a non-recoverable state which affects all readers and cards, including those that were previously functioning correctly. The only way to recover from this state is terminating and restarting the application which is running the code. After restarting the app, everything works normally again. We have created a bug report: FB22339746. The issue has been reproduced on iOS 26.4 and 18.5. Also on iPadOS 18.1. Anyone has already faced a similar issue? Could it be related to some internal state of TKSmartCardSlotManager?

In my application, I am creating a simple NSMenu with NSMenuItems. The title of the NSMenuItems are adapted to the system language. So, when the system language is an RTL language (right to left), I want my NSMenuItem to be aligned at the right. I can't see anyone talking about this, or any option that could make me achieve that easily. NSMenuItem* item1; NSMenuItem* item2; item1 = [[NSMenuItem alloc] init]; item2 = [[NSMenuItem alloc] init]; item1.title = "foo"; item2.title = "bar"; item1.action = @selector(fooAction); item2.action = @selector(barAction); NSMenu *menu = [[NSMenu alloc] init]; [menu addItem:item1]; [menu addItem:item2];

Hello, We already submitted a feedback through the assistant about that, but I'm not sure we will ever get an answer, and it might be interesting for other people as well. On MacOS Ventura, It seems like applications using the KeyChain services are unable to see certificates provided by CryptoTokenKit smart card token drivers. In order to reproduce, you need a CryptotokenKit smart card driver appex working under Big Sur or Monterey. Install the same appex on Ventura. You'll see that Safari does not see the certificates provided by the appex, and cannot perform SSL/TLS client authentications with them. Similar symptoms can be seen with other apps (Chrome, mail clients, or even custom apps that directly use the Keychain API: token instances cannot be obtained from the app). We tested with both our own CryptoTokenKit driver (a TKSmartCard driver, which worked well with all previous MacOS versions), and the CryptoTokenKit driver from another company (Yubico). Both work on older MacOS, but not on Ventura. Has something changed in the security framework between Monterey and Ventura? Do we need to change something in our CryptoTokenKit, or is it a bug from MacOS? If it's a bug, is Apple aware of it, and will it be fixed? This is a functionality that is largely used in enterprise environments.

Hi, I wanted to confirm if it is possible to communicate through the USB-C ports of the newer iPads with USB devices that aren't supported natively by iOS. More specifically, we want to be able to interface CCID (smart cards / USB crypto tokens) devices from our app. It seems that, since iOS 16, the IOKit/DriverKit frameworks are now made available. Does it mean we have everything to interface any kind of USB devices from a mobile app? Will there be constraints when submitting the app to the app store later on? On which devices exactly is this possible? All devices that have a USB-C port (newer iPad Pro / iPad Air / iPad mini)? Only a subset of them? Thank you.