When we enable 3rd party authentication plugin using SFAuthorization window, and during unlock the screen, we have observed the widgets are not showing the content. Attaching the screenshot for reference. We are noticing this behavior from macOS 14.7.1 and macOS 15

Hi everyone, I’ve been working on storing keys and passwords in the macOS Keychain using the Keychain Services API. Specifically, I’m leveraging SecAccessControlCreateWithFlags to bind items to access control flags, and overall, it’s been working smoothly. I have a question regarding the .applicationPassword flag of SecAccessControlCreateWithFlags. While it successfully prompts the user to input a password, there are no apparent password rules, even a simple “1” is accepted. My questions are: Is there a way to enforce strong password requirements when using the .applicationPassword flag? If enforcing strong passwords isn’t possible, is there an alternative approach to provide a predefined strong password during the creation process, bypassing the need for user input? With SecAccessControlCreateWithFlags, I noticed the item isn’t stored in the traditional file-based Keychain but in an iOS-style Keychain, is there a way to store it in a file-based Keychain while marking it as unexportable? I appreciate any insights or suggestions. Thank you! Neil

Attempting to DECRYPT a cipher message using the Apple API SecKeyCreateDecryptedData(privateKey, .rsaEncryptionOAEPSHA256, encryptedMessage). Decryption ALWAYS fails for every algorithm. SecKeyCreateDecryptedDataWithParameters Error: `Domain=NSOSStatusErrorDomain Code=-50 "algid:encrypt:RSA:OAEP:SHA256: algorithm not supported by the key <SecKeyRef:('com.yubico.Authenticator.TokenExtension:5621CDF8560D4C412030886584EC4C9E394CC376DD9738B0CCBB51924FC26EB6') 0x3007fd150>" UserInfo={numberOfErrorsDeep=0, NSDescription=algid:encrypt:RSA:OAEP:SHA256: algorithm not supported by the key <SecKeyRef:('com.yubico.Authenticator.TokenExtension:5621CDF8560D4C412030886584EC4C9E394CC376DD9738B0CCBB51924FC26EB6') 0x3007fd150>}` Decryption failed: SecKeyCreateDecryptedData returned nil. Error: One or more parameters passed to a function were not valid. When checking with SecKeyIsAlgorithmSupported(privateKey, .decrypt, <ANYalgorithm>) all algorithms fail. Btw - The privateKey does support decryption when retrieving the attributes. Important to know: The private key is a reference to an external private key placed in the iOS Keychain via a 3rd party CryptoTokenKit Extension app. When I perform, the SecKeyCreateSignature(...) and pass in the SAME privateKey reference, the OS automatically calls the 3rd party app to perform a successful signing with the private key that reside on a YubiKey. Here's my code for obtaining the private key reference from an Identity: func getKeyPairFromIdentity() -> (privateKey: SecKey, publicKey: SecKey)? { let query = NSDictionary( dictionary: [ kSecClass as String: kSecClassIdentity, kSecAttrTokenID as String: self.tokenID!, kSecReturnRef as String: kCFBooleanTrue as Any ] ) var identityRef: CFTypeRef? let status = SecItemCopyMatching(query, &identityRef) if status == errSecSuccess, let identity = identityRef { var privateKeyRef: SecKey? let keyStatus = SecIdentityCopyPrivateKey(identity as! SecIdentity, &privateKeyRef) if keyStatus == errSecSuccess, let privateKey = privateKeyRef { let publicKey = SecKeyCopyPublicKey(privateKey) if let publicKey = publicKey { print("Private and public keys extracted successfully.") return (privateKey, publicKey) } else { print("Failed to extract public key from private key.") return nil } } else { print("SecIdentityCopyPrivateKey: Private key not found error: \(keyStatus)") return nil } } else { print("SecIdentity not found or error: \(status)") return nil } }

I'm building a tool for admins in the enterprise context. The app needs to do some things as root, such as executing a script. I was hoping to implement a workflow where the user clicks a button, then will be shown the authentication prompt, enter the credentials and then execute the desired action. However, I couldn't find a way to implement this. AuthorizationExecuteWithPrivileges looked promising, but that's deprecated since 10.7. I've now tried to use a launch daemon that's contained in the app bundle with XPC, but that seems overly complicated and has several downsides (daemon with global machservice and the approval of a launch daemon suggests to the user that something's always running in the background). Also I'd like to stream the output of the executed scripts in real time back to the UI which seems very complicated to implement in this fashion. Is there a better way to enable an app to perform authorized privilege escalation for certain actions? What about privileged helper tools? I couldn't find any documentation about them. I know privilege escalation is not allowed in the App Store, but that's not relevant for us.

Since Sun 15th Jun 04:30 (UTC+7) we received lots of following error that causes our device test failure. Could Apple please investigate further? ############################# Operations could not be completed. (com.apple.devicecheck.error error 4.) (serverUnavailable)

I have a binary executable which needs to be given Accessibility Permissions so it can inject keypresses and mouse moves. This was always possible up to macOS 15 - when the first keypress arrived the Accessibility Permissions window would open and allow me to add the executable. However this no longer works in macOS 26: the window still opens, I navigate to the executable file and select it but it doesn't appear in the list. No error message appears. I'm guessing that this may be due to some tightening of security in Tahoe but I need to figure out what to change with my executable to allow it to work.

We are interested in using a hardware-bound key in a launch daemon. In a previous post, Quinn explicitly told me this is not possible to use an SE keypair outside of the system context and my reading of the Apple documentation also supports that. That said, we have gotten the following key-creation and persistence flow to work, so we have some questions as to how this fits in with the above. (1) In a launch daemon (running thus as root), we do: let key = SecureEnclave.P256.Signing.PrivateKey() (2) We then use key.dataRepresentation to store a reference to the key in the system keychain as a kSecClassGenericPassword. (3) When we want to use the key, we fetch the data representation from system keychain and we "rehydrate" the key using: SecureEnclave.P256.Signing.PrivateKey(dataRepresentation: data) (4) We then use the output of the above to sign whatever we want. My questions: in the above flow, are we actually getting a hardware-bound key from the Secure Enclave or is this working because it's actually defaulting to a non-hardware-backed key? if it is an SE key, is it that the Apple documentation stating that you can only use the SE with the Data Protection Keychain in the user context is outdated (or wrong)? does the above work, but is not an approach sanctioned by Apple? Any feedback on this would be greatly appreciated.

For testing purposes we have code that calls SecTrustEvaluateAsyncWithError() with a trust object containing a hardcoded leaf certificate and the corresponding intermediate certificate required to form a valid chain. Because the leaf certificate has since expired we pass a date in the past via SecTrustSetVerifyDate() at wich the certificate was still valid, but trust evaluation fails: Error Domain=NSOSStatusErrorDomain Code=-67825 "“<redacted>” certificate is not standards compliant" UserInfo={NSLocalizedDescription=“<redacted>” certificate is not standards compliant, NSUnderlyingError=0x600000c282a0 {Error Domain=NSOSStatusErrorDomain Code=-67825 "Certificate 0 “<redacted>” has errors: Certificate Transparency validation required for this use;" UserInfo={NSLocalizedDescription=Certificate 0 “<redacted>” has errors: Certificate Transparency validation required for this use;}}} I know that App Transport Security enforces Certificate Transparency by default, but is there a way around that here?

Hi everyone, I’d like to clarify something regarding the behavior of Team IDs after an app transfer between Apple Developer accounts. I have an app update that enforces a force update for all users. My plan is to release this update under the current developer account, and then proceed with transferring the app to a different developer account shortly afterward. My concern is: once the transfer is complete, will users who download the same app version (released before the transfer) be logged out due to a change in Team ID? Specifically, does the transferred app continue to use the original Team ID (used to sign the last submitted build), or does the Team ID change immediately upon transfer — affecting Keychain access? Any insights or confirmation on this would be greatly appreciated. Thanks!

In some crashlog files, there are additional pieces of information related to codesigning. I can understand what most of themcorresponds to (ID, TeamID, Flags, Validation Category). But there is one I have some doubt about: Trust Level. As far as I can tell (or at least what Google and other search engines say), this is an unsigned 32 bit integer that defines the trust level with -1 being untrusted, 0, being basically an Apple executable and other potential bigger values corresponding to App Store binaries, Developer ID signature, etc. Yet, I'm not able to find a corresponding detailed documentation about this on Apple's developer website. I also had a look at the LightweightCodeRequirements "include" file and there does not seem to be such a field available. [Q] Is there any official documentation listing the different values for this trust level value and providing a clear description of what it corresponds to?

I work for Brave, a browser with ~80M users. We want to introduce a new system for automatic updates called Omaha 4 (O4). It's the same system that powers automatic updates in Chrome. O4 runs as a separate application on users' systems. For Chrome, this works as follows: An app called GoogleUpdater.app regularly checks for updates in the background. When a new version is found, then GoogleUpdater.app installs it into Chrome's installation directory /Applications/Google Chrome.app. But consider what this means: A separate application, GoogleUpdater.app, is able to modify Google Chrome.app. This is especially surprising because, for example, the built-in Terminal.app is not able to modify Google Chrome.app. Here's how you can check this for yourself: (Re-)install Chrome with its DMG installer. Run the following command in Terminal: mkdir /Applications/Google\ Chrome.app/test. This works. Undo the command: rm -rf /Applications/Google\ Chrome.app/test Start Chrome and close it again. mkdir /Applications/Google\ Chrome.app/test now fails with "Operation not permitted". (These steps assume that Terminal does not have Full Disk Access and System Integrity Protection is enabled.) In other words, once Chrome was started at least once, another application (Terminal in this case) is no longer allowed to modify it. But at the same time, GoogleUpdater.app is able to modify Chrome. It regularly applies updates to the browser. For each update, this process begins with an mkdir call similarly to the one shown above. How is this possible? What is it in macOS that lets GoogleUpdater.app modify Chrome, but not another app such as Terminal? Note that Terminal is not sandboxed. I've checked that it's not related to codesigning or notarization issues. In our case, the main application (Brave) and the updater (BraveUpdater) are signed and notarized with the same certificate and have equivalent requirements, entitlements and provisioning profiles as Chrome and GoogleUpdater. The error that shows up in the Console for the disallowed mkdir call is: kernel (Sandbox) System Policy: mkdir(8917) deny(1) file-write-create /Applications/Google Chrome.app/foo (It's a similar error when BraveUpdater tries to install a new version into /Applications/Brave Browser.app.) The error goes away when I disable System Integrity Protection. But of course, we cannot ask users to do that. Any help would be greatly appreciated.

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?

Hi, my app is receiving all keyboard events through Input Monitoring preference. It completely stopped to work on macOS 15 Sequoia and I have no idea why. Where can I read what has been changed in Input Monitoring? Thanks!

Hi, When calling generateAssertion on DCAppAttestService.shared, it gives invalidKey error when there was an update for an offloaded app. The offloading and reinstall always works fine if it is the same version on app store that was offloaded from device, but if there is an update and the app tries to reuse the keyID from previous installation for generateAssertion, attestation service rejects the key with error code 3 (invalid key) for a significant portion of our user. In our internal testing it failed for more than a third of the update attempts. STEPS TO REPRODUCE: install v1 from app store generate key using DCAppAttestService.shared.generateKey Attest this key using DCAppAttestService.shared.attestKey Send the attestation objection to our server and verify with apple servers Generate assertions for network calls to backend using DCAppAttestService.shared.generateAssertion with keyID from step 2 Device offloads the app (manually triggered by user, or automatically by iOS) A new version v2 is published to App Store Use tries to open the app Latest version is download from the App Store App tries to use the keyID from step 2 to generate assertions DCAppAttestService throws invalidKey error (Error Domain=com.apple.devicecheck.error Code=3) Step 7 is critical here, if there is no new version of the app, the reinstalled v1 can reuse the key from step 2 without any issues Is this behaviour expected? Is there any way we can make sure the key is preserved between offloaded app updates? Thanks

We are facing an issue with Keychain sharing across our apps after our Team ID was updated. Below are the steps we have already tried and the current observations: Steps we have performed so far: After our Team ID changed, we opened and re-saved all the provisioning profiles. We created a Keychain Access Group: xxxx.net.soti.mobicontrol (net.soti.mobicontrol is one bundle id of one of the app) and added it to the entitlements of all related apps. We are saving and reading certificates using this access group only. Below is a sample code snippet we are using for the query: [genericPasswordQuery setObject:(id)kSecClassGenericPassword forKey:(id)kSecClass]; [genericPasswordQuery setObject:identifier forKey:(id)kSecAttrGeneric]; [genericPasswordQuery setObject:accessGroup forKey:(id)kSecAttrAccessGroup]; [genericPasswordQuery setObject:(id)kSecMatchLimitOne forKey:(id)kSecMatchLimit]; [genericPasswordQuery setObject:(id)kCFBooleanTrue forKey:(id)kSecReturnAttributes]; Issues we are facing: Keychain items are not being shared consistently across apps. We receive different errors at different times: Sometimes errSecDuplicateItem (-25299), even when there is no item in the Keychain. Sometimes it works in a debug build but fails in Ad Hoc / TestFlight builds. The behavior is inconsistent and unpredictable. Expectation / Clarification Needed from Apple: Are we missing any additional configuration steps after the Team ID update? Is there a known issue with Keychain Access Groups not working correctly in certain build types (Debug vs AdHoc/TestFlight)? Guidance on why we are intermittently getting -25299 and how to properly reset/re-add items in the Keychain. Any additional entitlement / provisioning profile configuration that we should double-check. Request you to please raise a support ticket with Apple Developer Technical Support including the above details, so that we can get guidance on the correct setup and resolve this issue.

Hello, I am currently working on iOS application development using Swift, targeting iOS 17 and above, and need to implement mTLS for network connections. In the registration API flow, the app generates a private key and CSR on the device, sends the CSR to the server (via the registration API), and receives back the signed client certificate (CRT) along with the intermediate/CA certificate. These certificates are then imported on the device. The challenge I am facing is pairing the received CRT with the previously generated private key in order to create a SecIdentity. Could you please suggest the correct approach to generate a SecIdentity in this scenario? If there are any sample code snippets, WWDC videos, or documentation references available, I would greatly appreciate it if you could share them. Thank you for your guidance.

I created an app in Xcode using ApplescriptObjC that is supposed to communicate with Finder and Adobe Illustrator. It has been working for the last 8 years, until now I have updated it for Sonoma and it no longer triggers the alerts for the user to approve the communication. It sends the Apple Events, but instead of the alert dialog I get this error in Console: "Sandboxed application with pid 15728 attempted to lookup App: "Finder"/"finder"/"com.apple.finder" 654/0x0:0x1d01d MACSstill-hintable sess=100017 but was denied due to sandboxing." The Illustrator error is prdictably similar. I added this to the app.entitlements file: <key>com.apple.security.automation.apple-events</key> <array> <string>com.apple.finder</string> <string>com.adobe.illustrator</string> </array> I added this to Info.plist: <key>NSAppleEventsUsageDescription</key> <string>This app requires access to Finder and Adobe Illustrator for automation.</string> I built the app, signed with the correct Developer ID Application Certificate. I've also packaged it into a signed DMG and installed it, with the same result as running it from Xcode. I tried stripping it down to just the lines of code that communicate with Finder and Illustrator, and built it with a different bundle identifier with the same result. What am I missing?

I am writing a MacOS app that uses the Apple crypto libraries to create, save, and use an RSA key pair. I am not using a Secure Enclave so that the private key can later the retrieved through the keychain. The problem I am running into is that on my and multiple other systems the creation and retrieval works fine. On a different system -- running MacOS 15.3 just like the working systems -- the SecKeyCreateRandomKey function appears to work fine and I get a key reference back, but on subsequent runs SecItemCopyMatching results in errSecItemNotFound. Why would it appear to save properly on some systems and not others? var error: Unmanaged<CFError>? let access = SecAccessControlCreateWithFlags(kCFAllocatorDefault, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, .biometryAny, &error)! let tag = TAG.data(using: .utf8)! // com.example.myapp.rsakey let attributes: [String: Any] = [ kSecAttrKeyType as String: KEY_TYPE, // set to kSecAttrKeyTypeRSA kSecAttrKeySizeInBits as String: 3072, kSecPrivateKeyAttrs as String: [ kSecAttrIsPermanent as String: true, kSecAttrApplicationTag as String: tag, kSecAttrAccessControl as String: access, ], ] guard let newKey = SecKeyCreateRandomKey(attributes as CFDictionary, &error) else { throw error!.takeRetainedValue() as Error } return newKey This runs fine on both systems, getting a valid key reference that I can use. But then if I immediately try to pull the key, it works on my system but not the other. let query = [ kSecClass as String: kSecClassKey, kSecAttrApplicationTag as String: tag, kSecReturnRef as String: true, ] var item: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &item) let msg = SecCopyErrorMessageString(status, nil) if status == errSecItemNotFound { print("key not found") } guard status == errSecSuccess else { print("other retrieval error") } return item as! SecKey I've also tried a separate query using the secCall function from here (https://developer.apple.com/forums/thread/710961) that gets ALL kSecClassKey items before and after the "create the key" function and it'll report the same amount of keys before and after on the bugged system. On the other machines where it works, it'll show one more key as expected. In the Signing & Capabilities section of the project config, I have Keychain Sharing set up with a group like com.example.myapp where my key uses a tag like com.example.myapp.rsakey. The entitlements file has an associated entry for Keychain Access Groups with value $(AppIdentifierPrefix)com.example.myapp.

Trying to apply 'always trust' to certificate added to keychain using both SecItemAdd() and SecPKCS12Import() with SecTrustSettingsSetTrustSettings(). I created a launchdaemon for this purpose. AuthorizationDB is modified so that any process running in root can apply trust to certificate. let option = SecTrustSettingsResult.trustRoot.rawValue // SecTrustSettingsResult.trustAsRoot.rawValue for non-root certificates let status = SecTrustSettingsSetTrustSettings(secCertificate, SecTrustSettingsDomain.admin, [kSecTrustSettingsResult: NSNumber(value: option.rawValue)] as CFTypeRef). Above code is used to trust certificates and it was working on os upto 14.7.4. In 14.7.5 SecTrustSettingsSetTrustSettings() returns errAuthorizationInteractionNotAllowed. In 15.5 modifying authorization db with AuthorizationRightSet() itself is returning errAuthorizationDenied.Tried manually editing authorization db via terminal and same error occurred. Did apple update anything on Security framework? Any other way to trust certificates?

My high-level goal is to add support for Game Mode in a Java game, which launches via a macOS "launcher" app that runs the actual java game as a separate process (e.g. using the java command line tool). I asked this over in the Graphics & Games section and was told this, which is why I'm reposting this here. I'm uncertain how to speak to CLI tools and Java games launched from a macOS app. These sound like security and sandboxing questions which we recommend you ask about in those sections of the forums. The system seems to decide whether to enable Game Mode based on values in the Info.plist (e.g. for LSApplicationCategoryType and GCSupportsGameMode). However, the child process can't seem to see these values. Is there a way to change that? (The rest of this post is copied from my other forums post to provide additional context.) Imagine a native macOS app that acts as a "launcher" for a Java game.** For example, the "launcher" app might use the Swift Process API or a similar method to run the java command line tool (lets assume the user has installed Java themselves) to run the game. I have seen How to Enable Game Mode. If the native launcher app's Info.plist has the following keys set: LSApplicationCategoryType set to public.app-category.games LSSupportsGameMode set to true (for macOS 26+) GCSupportsGameMode set to true The launcher itself can cause Game Mode to activate if the launcher is fullscreened. However, if the launcher opens a Java process that opens a window, then the Java window is fullscreened, Game Mode doesn't seem to activate. In this case activating Game Mode for the launcher itself is unnecessary, but you'd expect Game Mode to activate when the actual game in the Java window is fullscreened. Is there a way to get Game Mode to activate in the latter case? ** The concrete case I'm thinking of is a third-party Minecraft Java Edition launcher, but the issue can also be demonstrated in a sample project (FB13786152). It seems like the official Minecraft launcher is able to do this, though it's not clear how. (Is its bundle identifier hardcoded in the OS to allow for this? Changing a sample app's bundle identifier to be the same as the official Minecraft launcher gets the behavior I want, but obviously this is not a practical solution.)