I lived with knowledge that one needs to provide his login password to unlock the login keychain. This does not seem to be entirely true after upgrading Tahoe to 26.4. For example, on 26.3: Go to ~/Library/Keychains Copy login.keychain-db to different name, say test.keychain-db. Double-click on test.keychain-db -> this should open Keychain Access with test in Custom keychains section, it will appear locked. Select test keychain and press Cmd+L to unlock it. When prompted, provide your login password. Result: the keychain is unlocked. When I preform above sequence of steps on 26.4 I am not able to unlock the copied keychain (the original login keychain appears implicitly unlocked).

Hi, I’m building a macOS tool that analyzes process behavior to detect autonomous / AI-like activity locally (process trees, file access patterns, and network usage). The system is fully user-space and runs locally in real time. I’m planning to use the Endpoint Security Framework for process and file event monitoring. This is an open-source project (non-enterprise), developed by a solo developer. My question: What are the realistic chances of getting Endpoint Security entitlements approved for this type of project? Are there specific requirements or common reasons for rejection I should be aware of? Thanks, sivan-rnd

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?

I have a question regarding Platform SSO and the use of Secure Enclave–backed keys with biometric policies. If we configure userSecureEnclaveKeyBiometricPolicy with userSecureEnclaveKey, my understanding is that the Secure Enclave key is protected by biometric authentication (e.g., Face ID / Touch ID). In this setup, during a login request that also refreshes the id_token and refresh_token, the assertion is signed using the userSecureEnclaveKey. My question is: Will this signing operation trigger a biometric prompt every time the assertion is generated (i.e., during login/token refresh) ?

I am developing a Flutter iOS application and encountering a crash when using biometric authentication (Face ID) via the local_auth plugin. ■ Environment Flutter: 3.x local_auth: 2.2.0 (also tested with 2.1.6) iOS: real device (Face ID is working normally for device unlock) Firebase Authentication (email/password) Xcode build ■ Issue When calling biometric authentication, the app crashes immediately. Code: final didAuthenticate = await auth.authenticate( localizedReason: 'Authenticate to login', options: const AuthenticationOptions( biometricOnly: false, useErrorDialogs: false, ), ); ■ Error Thread 1: signal SIGABRT Crash occurs in libsystem_kernel.dylib (__pthread_kill) Happens immediately when authenticate() is called No exception is caught in Dart (native crash) ■ Verified NSFaceIDUsageDescription is correctly included in Info.plist Confirmed it exists in the built Runner.app Info.plist localizedReason is non-empty and in English Flutter clean / pod install executed App reinstalled on device Face ID works normally outside the app ■ Question Under what conditions does LAContext.evaluatePolicy trigger SIGABRT instead of returning an error? Are there known issues with presenting biometric authentication UI in certain UI states (e.g., view controller hierarchy, scene lifecycle)? Could this be related to UIScene / rootViewController issues? What is the correct timing and context to call biometric authentication safely in iOS apps? I suspect this is related to native iOS behavior rather than Flutter logic. Any guidance would be appreciated.

Hello, sorry for the awkward text formatting but I kept getting prevented from positing due to "sensitive language"... Help.txt

I’m developing an iOS application and aiming to install a PKCS#12 (.p12) certificate into the com.apple.token keychain access group so that Microsoft Edge for iOS, managed via MDM/Intune, can read and use it for client certificate authentication. I’m attempting to save to the com.apple.token keychain access group, but I’m getting error -34018 (errSecMissingEntitlement) and the item isn’t saved. This occurs on both a physical device and the simulator. I’m using SecItemAdd from the Security framework to store it. Is this the correct approach? https://developer.apple.com/documentation/security/secitemadd(::) I have added com.apple.token to Keychain Sharing. I have also added com.apple.token to the app’s entitlements. Here is the code I’m using to observe this behavior: public static func installToTokenGroup(p12Data: Data, password: String) throws -> SecIdentity { // First, import the P12 to get the identity let options: [String: Any] = [ kSecImportExportPassphrase as String: password ] var items: CFArray? let importStatus = SecPKCS12Import(p12Data as CFData, options as CFDictionary, &items) guard importStatus == errSecSuccess, let array = items as? [[String: Any]], let dict = array.first else { throw NSError(domain: NSOSStatusErrorDomain, code: Int(importStatus), userInfo: [NSLocalizedDescriptionKey: "Failed to import P12: \(importStatus)"]) } let identity = dict[kSecImportItemIdentity as String] as! SecIdentity let addQuery: [String: Any] = [ kSecClass as String: kSecClassIdentity, kSecValueRef as String: identity, kSecAttrLabel as String: kSecAttrAccessGroupToken, kSecAttrAccessible as String: kSecAttrAccessibleAfterFirstUnlock, kSecAttrAccessGroup as String: kSecAttrAccessGroupToken ] let status = SecItemAdd(addQuery as CFDictionary, nil) if status != errSecSuccess && status != errSecDuplicateItem { throw NSError(domain: NSOSStatusErrorDomain, code: Int(status), userInfo: [NSLocalizedDescriptionKey: "Failed to add to token group: \(status)"]) } return identity }

Hello, I’m working on a security agent plugin for Mac. The plugin provides a mechanism with custom UI via SFAuthorizationPluginView and a privileged mechanism with the business logic. The plugin needs to support unlocking the device, so I changed the authorize right to invoke my agent: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>evaluate-mechanisms</string> <key>created</key> <real>731355374.33196402</real> <key>mechanisms</key> <array> <string>FooBar:loginUI</string> <string>builtin:reset-password,privileged</string> <string>FooBar:authenticate,privileged</string> <string>builtin:authenticate,privileged</string> </array> <key>modified</key> <real>795624943.31730103</real> <key>shared</key> <true/> <key>tries</key> <integer>10000</integer> <key>version</key> <integer>1</integer> </dict> </plist> I also changed the system.login.screensaver right to use authorize-session-owner: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>rule</string> <key>comment</key> <string>The owner or any administrator can unlock the screensaver, set rule to "authenticate-session-owner-or-admin" to enable SecurityAgent.</string> <key>created</key> <real>731355374.33196402</real> <key>modified</key> <real>795624943.32567298</real> <key>rule</key> <array> <string>authenticate-session-owner</string> </array> <key>version</key> <integer>1</integer> </dict> </plist> I also set screenUnlockMode to 2, as was suggested in this thread: macOS Sonoma Lock Screen with SFAutorizationPluginView is not hiding the macOS desktop. In the Display Authorization plugin at screensaver unlock thread, Quinn said that authorization plugins are not able to use Touch ID. However, on a MacBook with at touch bar, when I lock the screen, close the lid, and then open it, the touch bar invites me to unlock with Touch ID. If I choose to do so, the screen unlocks and I can interact with the computer, but the plugin UI stays on screen and never goes away, and after about 30 seconds the screen locks back. I can reliably reproduce it on a MacBook Pro with M1 chip running Tahoe 26.1. Is this a known macOS bug? What can I do about it? Ideally, I would like to be able to integrate Touch ID into my plugin, but since that seems to be impossible, the next best thing would be to reliably turn it off completely. Thanks in advance.

Our proposed solution to identify an app user when opening a website operated by app developer is: Apps sends a request to backed with app users auth header Backend fetches a generated authenticated url from website backend, based on users auth header App opens it in browser The browser journey is self contained within domain of the business. Would this interaction require an ATT request given that the users identity cannot be tracked back to the app user ? Thanks

I'm currently reviewing the various DCError cases defined in Apple’s DeviceCheck framework (reference: https://developer.apple.com/documentation/devicecheck/dcerror-swift.struct). To better understand how to handle these in production, I’m looking for a clear breakdown of: Which specific DCError values can occur during service.generateKey, service.attestKey, and service.generateAssertion The realworld scenarios or conditions that typically cause each error for each method. If anyone has insight on how these errors arise and what conditions trigger them, I’d appreciate your input.

I downloaded a P12 file (containing a private key) from the company server, and retrieved the private key from this P12 file using a password : private func loadPrivateKeyFromPKCS12(path: String, password: String) throws -> SecKey? { let p12Data: Data do { p12Data = try Data(contentsOf: fileURL) } catch let readError { ... } let options: [CFString: Any] = [ kSecImportExportPassphrase: password as CFString ] var items: CFArray? let status = SecPKCS12Import(p12Data as CFData, options as CFDictionary, &items) guard status == errSecSuccess else { throw exception } var privateKey: SecKey? let idd = identity as! SecIdentity let _ = SecIdentityCopyPrivateKey(idd, &privateKey) return privateKey } However, when I use this private key to call SecKeyCreateSignature for data signing, a dialog box always pops up to ask user to input the Mac admin password. What confuses me is that this private key is clearly stored in the local P12 file, and there should be no access to the keychain involved in this process. Why does the system still require the user's login password for signing? Is it possible to perform silent signing (without the system dialog popping up) in this scenario?

We have successfully deployed our Qt C++ application on Windows and Android using OpenSSL with TLS Pre-Shared Key (PSK) authentication to connect to our servers. However, I understand that apps submitted to the App Store must use SecureTransport as the TLS backend on iOS. My understandiunig is that SecureTransport does not support PSK ciphersuites, which is critical for our security architecture. Questions: Does SecureTransport support TLS PSK authentication, or are there plans to add this feature? If PSK is not supported, what is Apple's recommended alternative for applications that require PSK-based authentication? Is there an approved exception process that would allow me to use OpenSSL for TLS connections on iOS while still complying with App Store guidelines? The application requires PSK for secure communication with our infrastructure, and we need guidance on how to maintain feature parity across all platforms while meeting App Store requirements

I'm trying to confirm the correct URL for Apple Attest development. There seems to be a fraud metric risk section that uses this: https://data-development.appattest.apple.com/v1/attestationData However the key verification seems to use this: https://data-development.appattest.apple.com/v1/attestation Currently I'm attempting to verify the key, so the second one seems likely. However I keep receiving a 404 despite vigorous validation of all fields included in the JSON as well as headers. Can anyone confirm please, which URL I should be sending my AppleAttestationRequest to?

I am developing a macOS system service (standalone binary running as a LaunchDaemon) that requires the ability to sign data using a private key which will be deployed via MDM. The Setup: Deployment: A .mobileconfig pushes a PKCS12 identity to the System Keychain. Security Requirement: For compliance and security reasons, we cannot set AllowAllAppsAccess to <true/>. The key must remain restricted. The Goal: I need to use the private key from the identity to be able to sign the data The Problem: The Certificate Payload does not support a TrustedApplications or AccessControl array to pre-authorize binary paths. As a result, when the process tries to use the private key for signing (SecKeyCreateSignature), it prompts the user to allow this operation which creates a disruption and is not desired. What i've tried so far: Manually adding my process to the key's ACL in keychain access obviously works and prevents any prompts but this is not an "automatable" solution. Using security tool in a script to attempt to modify the ACL in an automated way, but that also asks user for password and is not seamless. The Question: Is there a documented, MDM-compatible way to inject a specific binary path into the ACL of a private key? If not, is there a better way to achieve the end goal?

Hi, We are implementing Platform SSO and using attestKey during registration via ASAuthorizationProviderExtensionLoginManager. Could you clarify whether the attestKey flow involves sending attestation data to an Apple server for verification (similar to App Attest in the DeviceCheck framework), or if the attestation certificate chain is generated and signed entirely on-device without any Apple server interaction? The App Attest flow is clearly documented as using Apple’s attestation service, but the Platform SSO process is less clearly described. Thank you.

On Tahoe and earlier, ScreenCapture permissions can disappear and not return. Customers are having an issue with this disappearing and when our code executes CGRequestScreenCaptureAccess() nothing happens, the prompt does not appear. I can reproduce this by using the "-" button and removing the entry in the settings, then adding it back with the "+" button. CGPreflightScreenCaptureAccess() always returns the correct value but once the entry has been removed, CGRequestScreenCaptureAccess() requires a reboot before it will work again.

I’m looking for clarification on how rate limiting works for the App Attest service, especially in production environments. According to the entitlement documentation (https://developer.apple.com/documentation/BundleResources/Entitlements/com.apple.developer.devicecheck.appattest-environment), iOS ignores the environment setting once an app is distributed through TestFlight, the App Store, or Enterprise distribution, and always contacts the production App Attest endpoint. With that context, I have two questions: Rate‑Limiting Thresholds How exactly does rate limiting work for App Attest? Is there a defined threshold beyond which attestation requests begin to fail? The "Preparing to Use the App Attest Service" documentation (https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service) recommends ramping up no more than 10 million users per day per app, but I’m trying to understand what practical limits or failure conditions developers should expect. Per‑AppID Budgeting If multiple apps have different App IDs, do they each receive their own independent attestation budget/rate limit? Or is the rate limiting shared across all apps under the same developer account?

I can see the user’s real daily Screen Time perfectly inside a DeviceActivityReport extension on a physical device. It’s right there. But the moment I try to use that exact total inside my main app (for today’s log and a leaderboard), it dosnt work. I’ve tried, App Groups, Shared UserDefaults, Writing to a shared container file, CFPreferences Nothing makes it across. The report displays fine, but the containing app never receives the total. If this is sandboxed by design, I’d love confirmation. Thanks a lot

I've contacted Apple support about this topic, and they've directed me to this forum. I regularly perform Pentests of iOS applications. To properly assess the security of iOS apps, I must bypass given security precaution taken by our customers, such as certificate pinning. According to a number of blog articles, this appears to only be viable on jailbroken devices. If a target application requires a modern version of iOS, the security assessment can't be properly performed. As it should be in Apple's best interest, to offer secure applications on the App Store, what's the recommended approach to allow intrusive pentesting of iOS apps?