Hi, I’m currently working on an app that uses a third-party SDK to perform smart card authentication via PKCS#11 APIs. Specifically, the app interacts with the smart card to retrieve certificates, detect the card reader, and perform encryption and decryption operations on provided data. I’m wondering if it's possible to replace the PKCS#11 APIs and the third-party SDK with Apple's CryptoTokenKit framework. Does CryptoTokenKit provide equivalent functionality for smart card authentication, certificate management, and encryption/decryption operations? Additionally, I’ve come across the following CryptoTokenKit documentation: CryptoTokenKit API - TKSmartCardSlotManager Could you provide an example code or any guidance on how to implement this functionality using CryptoTokenKit, particularly for interacting with smart cards, managing certificates, and performing cryptographic operations? Thank you for your assistance.

We are using device certificates for authentication when logging into our web page. After updating an iPhone 12 to iOS 18, the authentication process takes up to two minutes to respond. Upon investigating IIS, it was found that the certificate is not being presented from the iPhone, resulting in a timeout. This issue is affecting our operations, and we need a solution urgently. Could you please advise on how to resolve this?

I'm trying to create an "Extensible Enterprise SSO" extension as described in the Introducing Extensible Enterprise SSO tech talk. My SSO extension works fine, but I want to be able to access the camera (via AVFoundation) from within the SSO extension. According to this thread (which I can't seem to be able to reply to) - it should be possible to access the camera from within an SSO extension, however this doesn't work for me. When I try to access the camera, I get the permission dialog, but after accepting, the camera preview is empty and no camera frames are produced. I don't get any errors/warnings in the logs, but it immediately fires AVCaptureSession.wasInterruptedNotification notification with AVCaptureSessionInterruptionReasonKey = 1 which corresponds to videoDeviceNotAvailableInBackground. However, the SSO extension view controller is clearly not in the background, so is this a bug - or are there special rules for requesting camera permission in an SSO extension? The same camera access works fine in the host app, just not inside the extension. Interestingly, accessing the camera in a WKWebView using various webcam test pages, doesn't work either. All of these tests have been on iPadOS 18.

Hi Guys I try to use smart card reader with my ipad project and after trying to make init session with the card got error from cryptotokenkit Message from debug log : [smartcard] slot refused to allocate exclusive session for the card "Session error: Error Domain=CryptoTokenKit Code=-2 "(null)"" // connect to the card mngr?.getSlot(withName: slotName, reply: { (slot:TKSmartCardSlot?) in let card = slot?.makeSmartCard() if card != nil { // begin session card?.beginSession{ ( success:Bool,error:Error?) in if success { // Send 1st APDU card?.send(ins: 0x84, p1: 0x00, p2: 0x00,le:8){ (data:Data?,sw:UInt16,error:Error?) in if error != nil { print("sendIns error:",error!) }else{ print("Response:",data!,String(sw,radix: 16)) //String(format: "%02X", data! as CVarArg) } } }else{ print("Session error:",error!) } } }else{ print("No card found") } })

Hi, I have a certificate, how can I display the certificate content in my Mac app just like Keychain Access app does. Can I popup the certificate content dialog just like Keychain Access app?

I would like to be able to reset an user password through some automated scripts, would need help regarding that.

I try to send apdu command via smartcard with Cryptotokenkit on IOS application but got some error in debug log [smartcard] slot refused to allocate exclusive session for the card "error domain=cryptotokenkit code=-2 "(null)"" for my code please see below code // connect to the card mngr?.getSlot(withName: slotName, reply: { (slot:TKSmartCardSlot?) in let card = slot?.makeSmartCard() if card != nil { // begin session card?.beginSession{ ( success:Bool,error:Error?) in if success { // Send 1st APDU card?.send(ins: 0x84, p1: 0x00, p2: 0x00,le:8){ (data:Data?,sw:UInt16,error:Error?) in if error != nil { print("sendIns error:",error!) }else{ print("Response:",data!,String(sw,radix: 16)) //String(format: "%02X", data! as CVarArg) } } }else{ print("Session error:",error!) } } }else{ print("No card found") } }) So i'm not sure what i do wrong on this

I am trying to implement a login page in SwiftUI for an idp that relies on passkeys only, following the sample code from the food truck app. The registration of a new passkey works fine but when it comes to signing in, ASAuthorizationPlatformPublicKeyCredentialProvider().createCredentialAssertionRequest returns a signature that cannot be verified by the server. On safari (and other browsers) the signing in&up process works fine and additionally, a passkey registered from the swift app works on the web, which leads me to believe there is an issue in the AuthenticationServices framework as every other steps works without any problem. The verification of the signature happens on the server side (after several validation steps of the other parameters) with WebCrypto.subtle.verify(verifyAlgorithm, key, signature, data); With the data argument being a concat of the clientDataJSON and the authenticatorData and for an apple authenticator, the key argument (which is the public key stored by the server) is an EC2 key with the following verifyAlgorithm argument: verifyAlgorithm = { name: 'ECDSA', hash: { name: SHA-256 }, }; After carefully analyzing multiple responses, coming both from the app and safari, either on iOS or macOS, I can safely say that the ASAuthorizationResult.passkeyAssertion returns the expected values for: rawAuthenticatorData rawClientDataJSON credentialID userID Which all match the expected values during the server-side validation. The only remaining value from the ASAuthorizationResult.passkeyAssertion is the signature, which as mentioned above, is invalid when verified by the server. I already submitted a bug report (FB15113372) as well as a DTS request, but haven’t received any feedback yet. In order to further narrow down the problem, I replicated the signature verification process in a sage notebook. I got the same result: the signature produced in Safari is fine, but the one from the Swift app is invalid. I collected some thoughts of potential issues in this notebook, but I still haven’t been able to draw a clear conclusion on why does this issue occur. Hence if anyone has knowledge of this issue or has a similar problem with signature verification, their advice is most welcomed. Thank you in advance for your help PS: All the recent tests were made on the latest publicly available OS releases (iOS 18.01, macOS 15.0.1) and Xcode 16.0

Firstly, I want to keep my GUI app available for download on the Mac App Store, which means I need to provide the Endpoint Security functionality in some other executable, such as a daemon. I'm going to use a User Agent for user-aware background processing. Instead of the typical use of adding an Endpoint Security system extension to a macOS app, could I instead add the sysex to my User Agent bundle? I like the benefits of coupling the sysex to the client that will interact with it, and this would also allow me to not have to worry about managing a daemon. I could simply provide the User Agent in a downloadable installer signed with my Developer ID certificate.

I am working on a personal use app, to transcribe audio files. I have over 1000 Voice Memos of ideas for a dog training app and book, recorded while... walking dogs, of course. I seem to not have the built in transcription option, either because Sonoma doesn't support it or my region doesn't, but I have learned a lot of Swift building an app that works great fort files in a folder in Documents. I have also found the path to to all the Voice Memo recordings. But when I try to read the contents of the folder to build the queue for transcription I get The file “Recordings” couldn’t be opened because you don’t have permission to view it. I expected this to be locked down, and some searching brought me to this and I have added Access User Selected Files (Read Only) = YES to the entitlements file, but I am not seeing where in the TARGETS editor I would assign com.apple.security.files.user-selected.read-only. If I add it as a key under info I don't get a popup to select, either in Xcode or when running the app. If I try to add that key to the entitlements file it doesn't allow for selection either. I am sure I am just missing something in the documentation, likely as a result of being an Xcode & Swift noob. So, if I CAN do this and I am just missing something, can someone point the way? And if a folder inside another app is just verboten, manually copying those files to a documents folder for processing won't be the end of the world.

In the YouTube video WWDC24: Meet AccessorySetupKit | Apple two apps are demonstrated to showcase the functionality of AccessorySetupKit. Does anyone know where I can find the source code for these demo apps?

Please excuse my lack of understanding of what are probably fundamental concepts in iOS/iPadOS development but I have searched far and wide for documentation and haven't had much luck so far. I am not sure that what I want to do is even possible with an iPad iPadOS app. Goals: Develop a Swift iPadOS app that can digitally sign a file using a PIV SmartCard/Token (Personal Identity Verification Card): Insert a PIV SmartCard/Token (such as a Yubikey 5Ci) into the lightning port of an iPadOS device iPad (NOT MacOS) Interface with the SmartCard/Token to access the user's PIV certificate/signature and "use it" to sign a file Question 1: How to get the PIV Certificate from SmartCard/Token/Yubikey into iPadOS keychain?   * Do we need to get the PIV certificate into the iOS keychain? Is there another way to interact with a SmartCard directly?   * This should prompt the user for their PIN? Question 2: How to get our Swift app to hook into the event that the SmartCard/Token is inserted into the device and then interface with the user's certificate?   * When is the user prompted to enter their PIN for SmartCard/Token/Yubikey?   * Do we need to use CyrptoTokenKit to interface with a smartcard inserted into the lightning port of an iOS device?

I am getting issue on my application that my device is jailbroken security message I updated my device 18.2 what the solution

I regularly see folks confused by the difference in behaviour of app groups between macOS and iOS. One day I’ll have time to write this up for the official docs (r. 92322409) but, in the meantime, here’s a quick overview. [Well, it was a quick overview. Things have got considerably more complicated in recent years.] If you have questions or comments, start a new thread with the details. Put it in the Privacy & Security > General topic area and tag it with Code Signing and Entitlements. Oh, and if this is about app group container protection, also include Files and Storage. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" App Groups: macOS vs iOS: Fight! The app groups mechanism works differently on macOS and iOS. On iOS: App group IDs start with the group. prefix. To use an app group ID, first allocate it on the Developer website. This associates the app group ID with your team. Then claim the app group ID in your app’s App Groups entitlement (com.apple.security.application-groups) entitlement. Like all entitlements on iOS, that claim must be authorised by a provisioning profile. A profile will only authorise an app group ID that’s allocated by your team. For more background on provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. In contrast, on macOS: App group IDs typically start with your Team ID. They can’t be explicitly allocated on the Developer website. Code that isn’t sandboxed doesn’t need to claim the app group ID in the App Groups entitlement. [1] To use an app group, claim the app group ID in the App Groups entitlement. The App Groups entitlement is not restricted, meaning that this claim doesn’t need to be authorised by a provisioning profile. The App Store submission process checks that your app group IDs make sense. IMPORTANT In this context I’m using macOS to refer to a standard macOS app. In Mac Catalyst things behave as they do on iOS. Likewise for iOS Apps on Mac. Also, anything I say about iOS also applies to tvOS, watchOS, and visionOS. This difference is a product of the way that each platform protects app group content. On iOS the Developer website enforces group uniqueness, that is, the site prevents team B from using an app group ID that’s assigned to team A. In contrast, on macOS: App group IDs are prefixed with the Team ID solely to prevent collisions. The Mac App Store prevents you from publishing an app that uses an app group ID that’s used by another team. In macOS 15 and later, all apps are subject to app group container protection. [1] This was true prior to macOS 15. It may still technically be true in macOS 15 and later, but the most important thing, access to the app group container, requires the entitlement because of app group container protection. Crossing the Streams [… and mixing my pop culture metaphors!] In some circumstances you might need to share an app group between iOS and macOS code. For example, you might have a Mac app that needs to share an app group with: A Mac Catalyst app An iOS app that runs on macOS via iOS Apps on Mac The solution is to use an iOS-style app group ID in your Mac app. To do this: Confirm that the app group ID is registered to your team on the Developer website. Claim the app group ID in the App Groups entitlement. If you submit that app to the Mac App Store, the submission process checks that your app group ID claims make sense, that is, they either follow the macOS convention (use a prefix of the Team ID) or the iOS convention (allocate a group ID, with the group. prefix, on the Developer website). IMPORTANT Due to app group container protection, this approach is only viable for Mac App Store apps. For more details, see App Group Container Protection, below. App Groups and the Keychain The differences described above explain an oddity associated with keychain access. Consider this quote from Sharing Access to Keychain Items Among a Collection of Apps: Application groups When you collect related apps into an application group using the App Groups entitlement, they share access to a group container, and gain the ability to message each other in certain ways. Starting in iOS 8, the array of strings given by this entitlement also extends the list of keychain access groups. There are three things to note here: Using an app group ID as a keychain access group only works on iOS; it’s not supported on macOS [1] because doing so would be insecure. The App Groups entitlement must be authorised by a provisioning profile on iOS, and that process is what protects the keychain from unauthorised access. The required group. prefix means that these keychain access groups can’t collide with other keychain access groups, which all start with an App ID prefix (there’s also Apple-only keychain access groups that start with other prefixes, like apple). In contrast, standard keychain access groups are protected the same way on both platforms, using the Keychain Access Groups entitlement (keychain-access-groups). [1] Except for iOS Apps on Mac. Not Entirely Unsatisfied When you launch a Mac app that uses app groups you might see this log entry: type: error time: 10:41:35.858009+0000 process: taskgated-helper subsystem: com.apple.ManagedClient category: ProvisioningProfiles message: com.example.apple-samplecode.Test92322409: Unsatisfied entitlements: com.apple.security.application-groups Note The exact format of that log entry, and the circumstances under which it’s generated, varies by platform. On macOS 13.0.1 I was able to generate it by running a sandboxed app that claims the App Group entitlement and also claims some other restricted entitlement. This looks kinda worrying and can be the source of problems. You see this error when you have a sandboxed app that uses an app group. In a sandboxed app your use of the app group must be authorised by the App Groups entitlement. This message is telling you that your use of the App Groups entitlement is not authorised by your provisioning profile. On iOS this would be a show stopper. The trusted execution system would prevent your app from launching at all. On macOS that’s not the case. The trusted execution system knows that there’s no way to get a Mac provisioning profile that authorises the App Groups entitlement, and thus it allows the app to launch anyway. However, that’s not the end of the story. You might run into problems with: macOS 15’s app group container protection The entitlements validated flag App Group Container Protection macOS 15 introduced app group container protection. To access an app group container without user intervention: Claim access to the app group by listing its ID in the App Groups entitlement. Locate the container by calling the containerURL(forSecurityApplicationGroupIdentifier:) method. Ensure that at least one of the following criteria are met: Your app is deployed via the Mac App Store (A). Or via TestFlight when running on macOS 15.1 or later (B). Or the app group ID starts with your app’s Team ID (C). Or your app’s claim to the app group is authorised by a provisioning profile embedded in the app (D) [1]. If your app doesn’t follow these rules, the system prompts the user to approve its access to the container. If granted, that consent applies only for the duration of that app instance. For more on this, see: The System Integrity Protection section of the macOS Sequoia 15 Release Notes The System Integrity Protection section of the macOS Sequoia 15.1 Release Notes WWDC 2024 Session 10123 What’s new in privacy, starting at 12:23 The above criteria mean that you rarely run into the app group authorisation prompt when your app is deployed. If you encounter a case where that happens, feel free to start a thread here on DevForums. See the top of this post for info on the topic and tags to use. However, you might run into some issues during development: If you have a multiplatform app built from a single target — for example, if you created the project from the Multiplatform > App template — Xcode’s Signing & Capabilities editor doesn’t understand all of these app group nuances. To work around this, conditionalise the entitlements file build setting. See this thread for more. If you use an iOS-style app group ID in a macOS app, you might run into the authorisation prompt during day-to-day development. One way around this is to use a macOS-style app group ID during development and switch to the iOS-style app group ID for production. [1] This is what allows Mac Catalyst and iOS Apps on Mac to work. Entitlements Validated Flag If your app claims the app group entitlement but that claim isn’t authorised by a provisioning profile, the trusted execution system allows the app to launch but it clears its entitlements validated flag. Some subsystems that rely on entitlements will fail in this case. The most notable example of this is the data protection keychain. Note If you’re curious about this flag, use the procinfo subcommand of launchctl to view it. For example: % sudo launchctl procinfo `pgrep Test20230126` … code signing info = valid … entitlements validated … If the flag has been cleared, this line will be missing from the code signing info section. The practical impact of this is that, for a sandboxed app on macOS, you can either use app groups or use the data protection keychain, but not both. Needless to say, this is less than ideal (r. 104859788). IMPORTANT This doesn’t stop you using the keychain in general. You can still use the file-based keychain. For more information about these terms, see TN3137 On Mac keychain APIs and implementations. One place this often crops up is with Network Extension (NE) framework system extensions. These must be sandboxed and often use an app group as part of their IPC story. Specifically, they might want to publish an XPC named endpoint and, when doing that, the name listed in NEMachServiceName must be a ‘child’ of an app group. Fortunately, system extensions are effectively daemons and so can’t use the data protection keychain anyway. So, if you’re building an NE system extension, this message is probably nothing to be worried about. If you’re building some other program that’s affected by this, open a thread here on DevForums and let’s talk. See the top of this post for info on the topic and tags to use. Revision History 2024-11-05 Further clarified app group container protection. Reworked some other sections to account for this new reality. 2024-10-29 Clarified the points in App Group Container Protection. 2024-10-23 Fleshed out the discussion of app group container protection on macOS 15. 2024-09-04 Added information about app group container protection on macOS 15. 2023-01-31 Renamed the Not Entirely Unsatisfactory section to Not Entirely Unsatisfied. Updated it to describe the real impact of that log message. 2022-12-12 First posted.

Our product uses the “Sign in with Apple” feature, and now we need to transfer it to Apple. After reading the documentation, I still have questions and would like to get answers. Q1:Transfer App: After the receiving team receives the App, is the unique identifier obtained by the client App program login the original one? Or is it newly generated? If it is newly generated, from what point in time will it be newly generated? Q2:Transfer App: Is there any validity period for the transfer identifier? About how long? What will happen after the transfer identifier is expired? Q3:When does the transfer identifier (transfer identifier) start to be generated, when the transfer request is initiated or when the transfer is completed, and when I get the transfer identifier, can I directly exchange it for the receiving team's unique identifier? Looking forward to a reply, thanks!

Hello, It seems that an App Store version App uses a default sandbox configuration. However, my app contains multiple binaries, and I would like to apply additional sandbox restrictions to a specific binary. Is it possible to set different sandbox rules for different binaries within the same app? Thank you for your help!

We get a "The application "Finder" does not have permission to open "(null)“" error message in macOS 15.1 when trying to open unsigned applications. Is this a known bug in macOS 15.1 ? If so any indications of whether it will be fixed in the future. In macOS 15.0.1 the workaround for launching unsigned applications still worked.

Hello everyone, I’m encountering an issue with Sign in with Apple in my watchOS app and would appreciate any guidance. Background: Initially, I did not have the Sign in with Apple capability enabled on my watchOS app. I have since enabled the capability and grouped it with my iOS app. For new user accounts created after this change, everything works perfectly: The credentialState check returns .authorized on both iOS and watchOS. However, for existing user accounts (created before enabling the capability on watchOS): The credentialState check returns not authorized on watchOS. The check still returns .authorized on iOS for these accounts. Error Details: When calling ASAuthorizationAppleIDProvider.credentialState(forUserID:) on watchOS for existing accounts, I receive the following error: Error Domain=AKAuthenticationError Code=-7074 "(null)" My Suspicions: I believe the issue arises because the existing Sign in with Apple tokens are only associated with the iOS app’s bundle identifier and not with the watchOS app’s bundle identifier. Since the capability wasn’t enabled on the watchOS app when these accounts were created, their tokens aren’t valid for the watchOS app. Questions: Is this the correct explanation for why the credentialState check fails on watchOS for existing accounts, resulting in the AKAuthenticationError Code=-7074 error? Can I update or migrate the existing accounts so that their Sign in with Apple tokens are valid for the watchOS app as well? If so, how can this be achieved? Are there any best practices for handling this situation without requiring users to re-authenticate or removing the credentialState check from the watchOS app? Goal: I want to maintain the credentialState check on the watchOS app because it works correctly for new accounts and is important for security. I’m looking for a solution that allows existing users to continue using the app on their Apple Watch without interruption or additional sign-in steps. Any help or suggestions would be greatly appreciated! Thank you!

When we develop 'Sign in with Apple' function on our app, we visited https://appleid.apple.com to verify the account. However, appleid.apple.com is mapped to an American IP, and it is not suitable for our app which is operated in China. I wonder whether there is a China Mainland IP available for the verification? Thanks very much.

I have a sdk which reads and writes data to keychain everything works fine on local machine. But on testflight it can not read the data it previously wrote. every time app starts it tries to read but fails. I have other apps they works fine with the same sdk and same code on testflight and local. There is keychain access groups in entitlement file. the reason is not entitlement file. Any ideas?