Post

Replies

Boosts

Views

Activity

USB-C custom device on iPads with iOS16
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.
0
1
1.8k
Oct ’22
CryptoTokenKit not working on Ventura
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.
18
4
6k
Mar ’23
Align NSMenuItem title to right
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];
Topic: Design SubTopic: General Tags:
0
1
152
Mar ’25
TkSmartCard transmitRequest persistently returning Cryptotokenkit error -2 on iOS/iPadOS
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?
2
0
284
Mar ’26
AID A000000308000010000100 seems mandatory to communicate with any smart card through TKSmartCardSlotNFCSession
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 ?
3
0
236
2w
USB-C custom device on iPads with iOS16
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.
Replies
0
Boosts
1
Views
1.8k
Activity
Oct ’22
CryptoTokenKit not working on Ventura
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.
Replies
18
Boosts
4
Views
6k
Activity
Mar ’23
Align NSMenuItem title to right
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];
Topic: Design SubTopic: General Tags:
Replies
0
Boosts
1
Views
152
Activity
Mar ’25
TkSmartCard transmitRequest persistently returning Cryptotokenkit error -2 on iOS/iPadOS
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?
Replies
2
Boosts
0
Views
284
Activity
Mar ’26
AID A000000308000010000100 seems mandatory to communicate with any smart card through TKSmartCardSlotNFCSession
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 ?
Replies
3
Boosts
0
Views
236
Activity
2w