I have a certificate and private key imported into the System Keychain which is used for client authentication in mTLS connections. I can go into the Keychain Access UI and open up the options for the private key, navigate to the "Access Control List" tab and whitelist certain applications which have access to this key. I am aware of the "security import" CLI command which allows me to set up the private key permissions using either the -A (allow all applications to access imported key) or -T (allow specific application to access imported key). But these only work for scenarios where I am importing a completely new Certificate + Private Key. However, is there a way to make these "Access Control List" changes from a CLI command for a private key that is already present in the keychain? I am deploying an application to a large number of machines and it is not feasible to have a manual step for adding the application to a whitelist in Keychain Access. Need to automate this stuff

General: Apple Platform Security support document Security Overview Cryptography: DevForums tags: Security, Apple CryptoKit Security framework documentation Apple CryptoKit framework documentation Common Crypto man pages — For the full list of pages, run: % man -k 3cc For more information about man pages, see Reading UNIX Manual Pages. On Cryptographic Key Formats DevForums post SecItem attributes for keys DevForums post CryptoCompatibility sample code Keychain: DevForums tags: Security Security > Keychain Items documentation On Mac Keychains DevForums post Smart cards and other secure tokens: DevForums tag: CryptoTokenKit CryptoTokenKit framework documentation Mac-specific frameworks: DevForums tags: Security Foundation, Security Interface Security Foundation framework documentation Security Interface framework documentation Related: Networking Resources — This covers high-level network security, including HTTPS and TLS. Network Extension Resources — This covers low-level network security, including VPN and content filters. Code Signing Resources Notarisation Resources Trusted Execution Resources — This includes Gatekeeper. App Sandbox Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi. I'm dealing with an issue trying to retrieve SmartCard certificates from the app. I'm getting status -25300 (errSecItemNotFound) for SecItemCopyMatching when the smartcard is connected. The FW Security and SecurityInterfaces are add to the project. This is the code OSStatus nStatus; static const void* kKeys[] = { kSecClass, kSecMatchLimit, kSecReturnRef, kSecAttrCanSign }; static const void* kValues[] = { kSecClassIdentity, kSecMatchLimitAll, kCFBooleanTrue, kCFBooleanTrue }; osxObject<CFDictionaryRef> query(CFDictionaryCreate( kCFAllocatorDefault, kKeys, kValues, 4, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks)); CFArrayRef result; OSStatus status = SecItemCopyMatching(query.get(),(CFTypeRef *)&result); //status retrieved is -25300 Why the status my be -25300 even when the smart card if configured and connected? Thanks

I'm using SecKeyCreateRandomKey to generate a private key, encrypting some data with that key (with the public key from the generated private key), and then saving that encrypted data in the keychain. I'm seeing some odd behavior where I'm occasionally unable to access the encryption key (SecItemCopyMatching returns errSecItemNotFound) even though I can access the encrypted data (returned status is errSecSuccess and the result value is populated correctly). Both items are using the same accessibility attributes, so I'm left thinking that either there's some data-loss happening (the worst-case scenario), or that there's something slightly wrong with my query that causes it to fail in some circumstances. I've been beating my head against this for way too long at this point without being able to make much progress forward, so any help here would be much appreciated. Key generation: let attributes: NSDictionary = [ kSecAttrKeyType: kSecAttrKeyTypeECSECPrimeRandom, kSecAttrKeySizeInBits: 256, kSecAttrTokenID: kSecAttrTokenIDSecureEnclave, kSecPrivateKeyAttrs: [ kSecClass: kSecClassKey, kSecAttrApplicationTag: "some_valid_tag".data(using: .utf8)!, kSecAttrKeyType: kSecAttrKeyTypeECSECPrimeRandom, kSecAttrAccessible: kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly, kSecAttrAccessGroup: "SomeValidGroupIdentifier", kSecAttrIsPermanent: true, ], ] var error: Unmanaged<CFError>? guard let privateKey = SecKeyCreateRandomKey(attributes, &error) else { throw SomeError() } Key read operation: let query: NSDictionary = [ kSecClass: kSecClassKey, kSecAttrApplicationTag: "some_valid_tag".data(using: .utf8)!, kSecAttrKeyType: kSecAttrKeyTypeECSECPrimeRandom, kSecReturnRef: true, ] var result: AnyObject? let status = SecItemCopyMatching(query, &result) For reference, the read/write queries I'm using for the encrypted data look like: let readQuery = [ kSecClass: kSecClassKey, kSecAttrApplicationTag: "some_valid_tag_data".data(using: .utf8)!, kSecReturnData: true, ] let writeQuery = [ kSecClass: kSecClassKey, kSecAttrApplicationTag: "some_valid_tag_data".data(using: .utf8)!, kSecAttrAccessible: kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly, kSecAttrAccessGroup: "SomeValidGroupIdentifier, ] Is there something I'm missing here? Is there a way for me to get more insight into why the query is failing?

when i use NSURLSession have a https request,TLS always download server certificate,Instead of using cached certificates. Certificate related packages are as follows: 123 17.994520 106.53.111.71 192.168.199.159 TLSv1.3 1412 Server Hello, Change Cipher Spec, Application Data 124 17.994559 106.53.111.71 192.168.199.159 TCP 1412 443 → 65048 [ACK] Seq=1373 Ack=518 Win=30336 Len=1372 [TCP segment of a reassembled PDU]

Hello, Im trying to run this set of code as root Button("Unlock FPS") {                 do {                     let task = Process()                     task.executableURL = URL(fileURLWithPath: "/Somewhere/Somewhere/Somewhere/rbxfpsunlocker") But after hours of searching the internet I could not find anything, except on how to run the application as root in Debug mode. If anyone knows the answer please tell me.

Hi, I was wondering if there is a way to monitor if a certificate is exported from the keychain. Either by using some of the apis Endpoint Security provides or using another method. Thanks.

Hi, I want to use the iOs Secure Enclave to create a "Primary Device" Mechanism. It would work like this. Device Creates Enclave Key Pair and Sends the Public Key to the Server (Preferably Node JS) The Server encrypts a random message with the Public Key and sends it to the Device. I can be sure the Device is the only one able to decipher that string, because the private key is safe in the Secure Enclave Now the client would decrypt the message and send the result to the server which can compare it to the original message. When de- and encrypting Data in the ios ecosystem the process is straightforward. I Encrypt Data using SecKeyCreateEncryptedData and Decrypt using SecKeyCreateDecryptedData passing Public Key and CipherText Objects. Now my question is: how can I export the public Key to have my Node JS Backend encrypt Messages which will be decryptable again with the SecureEnclave.

My little Swift program on macOS 12.3.1 creates a cryptographic key for a symmetric cipher as follows: let parameters = NSMutableDictionary() var raw = 256 let num = CFNumberCreate(kCFAllocatorDefault, .sInt32Type, &raw)! var optError: Unmanaged<CFError>? parameters.setValue("Pix Cipher", forKey: kSecAttrLabel as String) parameters.setValue(kSecAttrKeyTypeAES, forKey: kSecAttrKeyType as String) parameters.setValue(num, forKey: kSecAttrKeySizeInBits as String) parameters.setValue(kCFBooleanTrue, forKey: kSecAttrIsPermanent as String) parameters.setValue(kCFBooleanTrue, forKey: kSecAttrCanEncrypt as String) parameters.setValue(kCFBooleanTrue, forKey: kSecAttrCanDecrypt as String) key = SecKeyGenerateSymmetric(parameters, &optError) This key can be stored in the Key Chain and works fine for encryption and decryption. But when I want to export it using var error: Unmanaged<CFError>? let cfData = SecKeyCopyExternalRepresentation(key!, &error) , this fails, with error set to something like Error Domain=NSOSStatusErrorDomain Code=-4 "MacOS error: -4" What does "MacOS error: -4" mean? (kCFMessagePortTransportError/kCSIdentityDeletedErr /unimpErr?) Why does SecKeyCopyExternalRepresentation not work? What is wrong with the key? Kind regards, Jakob

I'm trying to build a simple Mail Extension using Compose session handler for the Mac Catalyst App. The idea is to open a ComposeViewController on App Icon click from Mail Toolbar ( when the user adds the app extensions for the app from Mail Preference ). I'm using core data in a shared group and I want to show the list of the email address that the user has added from the app to the ComposeViewController. But on the extension window in the Mail, it shows : Permissions for “MyDemoApp”: • Email Contents Can read sensitive information from emails including the message subject and recipients. This applies to all outgoing messages. Since my Compose-Mail-Extension does not read subject/recipients in the Compose window, My app should not ask this permission from users. Is there any way to omit permissions which my app is not using?

DTS regularly receives questions about how to preserve keychain items across an App ID change, and so I thought I’d post a comprehensive answer here for the benefit of all. If you have any questions or comments, or other creative solutions!, please start a new thread here on DevForums, tagging it with Security so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" App ID Prefix Change and Keychain Access The list of keychain access groups your app can access is determined by three entitlements. For the details, see Sharing Access to Keychain Items Among a Collection of Apps. If your app changes its App ID prefix, this list changes and you’re likely to lose access to existing keychain items. This situation crops up under two circumstances: When you migrate your app from using a unique App ID prefix to using your Team ID as its App ID prefix. When you transfer your app to another team. In both cases you have to plan carefully for this change. If you only learn about the problem after you’ve made the change, consider undoing the change to give you time to come up with a plan before continuing. Note On macOS, the information in this post only applies to the data protection keychain. For more information about the subtleties of the keychain on macOS, see On Mac Keychains. For more about App ID prefix changes, see Technote 2311 Managing Multiple App ID Prefixes and QA1726 Resolving the Potential Loss of Keychain Access warning. Migrate From a Unique App ID Prefix to Your Team ID Historically each app was assigned its own App ID prefix. This is no longer the case. Best practice is for apps to use their Team ID as their App ID prefix. This enables multiple neat features, including keychain item sharing and pasteboard sharing. If you have an app that uses a unique App ID prefix, consider migrating it to use your Team ID. This is a good thing in general, as long as you manage the migration process carefully. Your app’s keychain access group list is built from three entitlements: keychain-access-groups, see Keychain Access Groups Entitlement application-identifier (com.apple.application-identifier on macOS) com.apple.security.application-groups, see App Groups Entitlement IMPORTANT A macOS app can’t use an app group as a keychain access group. The first two depend on the App ID prefix. If that changes, you lose access to any keychain items in those groups. WARNING Think carefully before using the keychain to store secrets that are the only way to access irreplaceable user data. While the keychain is very reliable, there are situations where a keychain item can be lost and it’s bad if it takes the user’s data with it. In some cases losing access to keychain items is not a big deal. For example, if your app uses the keychain to manage a single login credential, losing that is likely to be acceptable. The user can recover by logging in again. In other cases losing access to keychain items is unacceptable. For example, your app might manage access to dozens of different servers, each with unique login credentials. Your users will be grumpy if you require them to log in to all those servers again. In such situations you must carefully plan your migration. The key element here is the third item in the list above, the com.apple.security.application-groups entitlement. An app group is tied to your team, and so your app retains access to the corresponding keychain access group across an App ID change. This suggests the following approach: Release a version of your app that moves keychain items from other keychain access groups to a keychain access group corresponding to an app group. Give your users time to update to this new version, run it, and so move their keychain items. When you’re confident that the bulk of your users have done this, change your App ID prefix. Be wary of the following caveats: This approach won’t work on macOS because macOS apps can’t use an app group as a keychain access group. It’s hard to judge how long to wait at step 2. Transfer Your App to Another Team There is no supported way to maintain access to keychain items across an app transfer. This makes it critical that you plan the transfer carefully. Note The approach described in the previous section doesn’t work in this case because app groups are tied to a team. There are three potential approaches here: Do nothing Do not transfer your app Get creative Do Nothing In this case the user loses all the secrets that your app stored in the keychain. This may be acceptable for certain apps. For example, if your app uses the keychain to manage a single login credential, losing that is likely to be acceptable. The user can recover by logging in again. Do Not Transfer Another option is to not transfer your app. Instead, ship a new version of the app from the new team and have the old app recommend that the user upgrade. There are a number of advantages to this approach. The first is that there’s absolutely no risk of losing any user data. The two apps are completely independent. The second advantage is that the user can install both apps on their device at the same time. This opens up a variety of potential migration paths. For example, you might ship an update to the old app with an export feature that saves the user’s state, including their secrets, to a suitably encrypted file, and then match that with an import facility on the new app. Finally, this approach offers flexible timing. The user can complete their migration at their leisure. However, there are a bunch of clouds to go with these silver linings: Your users might never migrate to the new app. If this is a paid app, or an app with in-app purchase, the user will have to buy things again. You lose the original app’s history, ratings, reviews, and so on. Get Creative Finally, you could attempt something creative. For example, you might: Publish a new version of the app that supports exporting the user’s state, including the secrets. Tell your users to do this, with a deadline. Transfer the app and then, when the deadline expires, publish the new version with an import feature. Frankly, this isn’t very practical. The problem is with step 2: There’s no good way to get all your users to do the export, and if they don’t do it before the deadline there’s no way to do it after.

How to add 2FA using Mac Authorizaton plugin on ScreenSaver Lock Screen, lock/unlock case. It is working for Console login and switch user context and Im unable to add 2FA for screensaver unlock. I tried invoking the AuthPlugin for screensaver by adding the mechanisms(contains custom login screen and 2FA) to the system.login.screensaver plist. Any help is highly appreciated Thank You!.

Hi, Can I connect with a local server with self-signed cert that support the 2019 requirements? (https://support.apple.com/en-us/HT210176) The app loads content on UIWebView from a local server, like 192.168.1.50 for example, with self-signed cert. I have tried without success: Install the custom CA in iOS (Settings -> General -> Profile) Set into Info.plist the following configs: Allow Arbitrary Loads: YES Allow Arbitrary Loads: NO; Exception Domains: 192.168.1.50:8080; Allow Arbitrary Loads in Web Content: YES; Allow Arbitrary Loads: YES; Allow Arbitrary Loads in Web Content: YES; Allows Local Networking: YES Allow Arbitrary Loads: NO; Exception Domains: 192.168.1.50:8080; Allow Arbitrary Loads in Web Content: YES; Allows Local Networking: YES Is it possible works as I pretend? Load web content in a UIWebView from a local server with self-signed certificate? Please, some help for that. Thank you in advance.

In the same way that servers become a target when they contain secrets as mentioned in "Move beyond passwords" video, won't this make all of a person's Apple devices an even bigger target as they would provide ready access to the Keychain contents? When this is rolled out it will be imperative to no longer allow weak device authentication methods since this would make the iCloud Keychain and contents vulnerable from any single device with access to the keychain.