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 TN3137 On Mac keychain APIs and implementations SecItem Fundamentals DevForums post SecItem Pitfalls and Best Practices DevForums post Investigating hard-to-reproduce keychain problems 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"

I regularly help developers with keychain problems, both here on DevForums and for my Day Job™ in DTS. Many of these problems are caused by a fundamental misunderstanding of how the keychain works. This post is my attempt to explain that. I wrote it primarily so that Future Quinn™ can direct folks here rather than explain everything from scratch (-: If you have questions or comments about any of this, put them in a new thread and apply the Security tag so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" SecItem: Fundamentals or How I Learned to Stop Worrying and Love the SecItem API The SecItem API seems very simple. After all, it only has four function calls, how hard can it be? In reality, things are not that easy. Various factors contribute to making this API much trickier than it might seem at first glance. This post explains the fundamental underpinnings of the keychain. For information about specific issues, see its companion post, SecItem: Pitfalls and Best Practices. Keychain Documentation Your basic starting point should be Keychain Items. If your code runs on the Mac, also read TN3137 On Mac keychain APIs and implementations. Read the doc comments in ＜Security／SecItem.h＞. In many cases those doc comments contain critical tidbits. When you read keychain documentation [1] and doc comments, keep in mind that statements specific to iOS typically apply to iPadOS, tvOS, and watchOS as well (r. 102786959). Also, they typically apply to macOS when you target the data protection keychain. Conversely, statements specific to macOS may not apply when you target the data protection keychain. [1] Except TN3137, which is very clear about this (-: Caveat Mac Developer macOS supports two different implementations: the original file-based keychain and the iOS-style data protection keychain. If you’re able to use the data protection keychain, do so. It’ll make your life easier. TN3137 On Mac keychain APIs and implementations explains this distinction in depth. The Four Freedoms^H^H^H^H^H^H^H^H Functions The SecItem API contains just four functions: SecItemAdd(_:_:) SecItemCopyMatching(_:_:) SecItemUpdate(_:_:) SecItemDelete(_:) These directly map to standard SQL database operations: SecItemAdd(_:_:) maps to INSERT. SecItemCopyMatching(_:_:) maps to SELECT. SecItemUpdate(_:_:) maps to UPDATE. SecItemDelete(_:) maps to DELETE. You can think of each keychain item class (generic password, certificate, and so on) as a separate SQL table within the database. The rows of that table are the individual keychain items for that class and the columns are the attributes of those items. Note Except for the digital identity class, kSecClassIdentity, where the values are split across the certificate and key tables. See Digital Identities Aren’t Real in SecItem: Pitfalls and Best Practices. This is not an accident. The data protection keychain is actually implemented as an SQLite database. If you’re curious about its structure, examine it on the Mac by pointing your favourite SQLite inspection tool — for example, the sqlite3 command-line tool — at the keychain database in ~／Library／Keychains／UUU／keychain-2.db, where UUU is a UUID. WARNING Do not depend on the location and structure of this file. These have changed in the past and are likely to change again in the future. If you embed knowledge of them into a shipping product, it’s likely that your product will have binary compatibility problems at some point in the future. The only reason I’m mentioning them here is because I find it helpful to poke around in the file to get a better understanding of how the API works. For information about which attributes are supported by each keychain item class — that is, what columns are in each table — see the Note box at the top of Item Attribute Keys and Values. Alternatively, look at the Attribute Key Constants doc comment in ＜Security／SecItem.h＞. Uniqueness A critical part of the keychain model is uniqueness. How does the keychain determine if item A is the same as item B? It turns out that this is class dependent. For each keychain item class there is a set of attributes that form the uniqueness constraint for items of that class. That is, if you try to add item A where all of its attributes are the same as item B, the add fails with errSecDuplicateItem. For more information, see the errSecDuplicateItem page. It has lists of attributes that make up this uniqueness constraint, one for each class. These uniqueness constraints are a major source of confusion, as discussed in the Queries and the Uniqueness Constraints section of SecItem: Pitfalls and Best Practices. Parameter Blocks Understanding The SecItem API is a classic ‘parameter block’ API. All of its inputs are dictionaries, and you have to know which properties to set in each dictionary to achieve your desired result. Likewise for when you read properties in output dictionaries. There are five different property groups: The item class property, kSecClass, determines the class of item you’re operating on: kSecClassGenericPassword, kSecClassCertificate, and so on. The item attribute properties, like kSecAttrAccessGroup, map directly to keychain item attributes. The search properties, like kSecMatchLimit, control how the system runs a query. The return type properties, like kSecReturnAttributes, determine what values the query returns. The value type properties, like kSecValueRef perform multiple duties, as explained below. There are other properties that perform a variety of specific functions. For example, kSecUseDataProtectionKeychain tells macOS to use the data protection keychain instead of the file-based keychain. These properties are hard to describe in general; for the details, see the documentation for each such property. Inputs Each of the four SecItem functions take dictionary input parameters of the same type, CFDictionary, but these dictionaries are not the same. Different dictionaries support different property groups: The first parameter of SecItemAdd(_:_:) is an add dictionary. It supports all property groups except the search properties. The first parameter of SecItemCopyMatching(_:_:) is a query and return dictionary. It supports all property groups. The first parameter of SecItemUpdate(_:_:) is a pure query dictionary. It supports all property groups except the return type properties. Likewise for the only parameter of SecItemDelete(_:). The second parameter of SecItemUpdate(_:_:) is an update dictionary. It supports the item attribute and value type property groups. Outputs Two of the SecItem functions, SecItemAdd(_:_:) and SecItemCopyMatching(_:_:), return values. These output parameters are of type CFTypeRef because the type of value you get back depends on the return type properties you supply in the input dictionary: If you supply a single return type property, except kSecReturnAttributes, you get back a value appropriate for that return type. If you supply multiple return type properties or kSecReturnAttributes, you get back a dictionary. This supports the item attribute and value type property groups. To get a non-attribute value from this dictionary, use the value type property that corresponds to its return type property. For example, if you set kSecReturnPersistentRef in the input dictionary, use kSecValuePersistentRef to get the persistent reference from the output dictionary. In the single item case, the type of value you get back depends on the return type property and the keychain item class: For kSecReturnData you get back the keychain item’s data. This makes most sense for password items, where the data holds the password. It also works for certificate items, where you get back the DER-encoded certificate. Using this for key items is kinda sketchy. If you want to export a key, called SecKeyCopyExternalRepresentation. Using this for digital identity items is nonsensical. For kSecReturnRef you get back an object reference. This only works for keychain item classes that have an object representation, namely certificates, keys, and digital identities. You get back a SecCertificate, a SecKey, or a SecIdentity, respectively. For kSecReturnPersistentRef you get back a data value that holds the persistent reference. Value Type Subtleties There are three properties in the value type property group: kSecValueData kSecValueRef kSecValuePersistentRef Their semantics vary based on the dictionary type. For kSecValueData: In an add dictionary, this is the value of the item to add. For example, when adding a generic password item (kSecClassGenericPassword), the value of this key is a Data value containing the password. This is not supported in a query dictionary. In an update dictionary, this is the new value for the item. For kSecValueRef: In add and query dictionaries, the system infers the class property and attribute properties from the supplied object. For example, if you supply a certificate object (SecCertificate, created using SecCertificateCreateWithData), the system will infer a kSecClass value of kSecClassCertificate and various attribute values, like kSecAttrSerialNumber, from that certificate object. This is not supported in an update dictionary. For kSecValuePersistentRef: For query dictionaries, this uniquely identifies the item to operate on. This is not supported in add and update dictionaries. Revision History 2023-09-12 Fixed various bugs in the revision history. Added a paragraph explaining how to determine which attributes are supported by each keychain item class. 2023-02-22 Made minor editorial changes. 2023-01-28 First posted.

Hello, I am browsing with Safari. A website asks me to access my microphone (it is a Safari prompt dialog, not a system dialog). I am answering "yes, you can access to my microphone". Everything works fine, my microphone is allowed. Now, i am going to macOS system settings, in "Privacy & Security" section. I open "Microphone" sub section: And i don't see any entry for Safari. My question is ... Why ? Safari is accessing to my microphone at this moment and i don't see any grant information about this in system settings... Maybe apple allows his own softwares but this is not good for security... I hope it is not the same behaviour for full disk access grant... Thanks

I've been trying to use Keychain from a Daemon for some time now. In the end, I managed to have the System Keychain work for my application and I moved to work on other parts. I finally went back to dealing with Keychain, but the code I wrote before stopped working. Even the application I wrote to test things out stopped working for me, and now it gives the The authorization was denied. error. To give more perspective into what I am doing, I am running a Sandboxed Launch Daemon wrapped in an App-like structure. I register it from my main app via SMAppService API. I also have a System Extension. My test app was structured in the same way and I used the following code to put a new key into the System Keychain and get its reference: var err: Unmanaged<CFError>? let access = SecAccessCreateWithOwnerAndACL(getuid(), getgid(), UInt32(kSecUseOnlyUID | kSecHonorRoot), nil, &err) if let err = err { log.error("Failed to create SecAccess: \(err.takeUnretainedValue().localizedDescription)") } let request = [ kSecClass: kSecClassGenericPassword, kSecAttrService: service, kSecAttrAccount: account, kSecValueData: passwordData, kSecAttrAccess: access as Any, kSecAttrSynchronizable: false, kSecUseDataProtectionKeychain: false, kSecReturnPersistentRef: true, ] as [String: Any] var result: CFTypeRef? let status = SecItemAdd(request as CFDictionary, &result) The goal of this was to share some secrets with a System Extension. The code above worked for me some time ago and I was able to use the System Keychain from my sandboxed daemon. Am I missing something again? Did something change in the meantime? Or did I do something last time that I haven't noticed? Should I cut my losses and avoid Keychain since Apple will not support it anyway?

Hi, We are getting error while fetching data from the keychain. Error code : "-25308" Error message : "User interaction is not allowed." This is happening in our Production app and many users are facing this issue. This issue is coming randomly for random users. Its working fine but suddenly we are getting this error randomly. We have tried to add delay when keychain is giving error randomly to minimise the issue but it is not fixing our issue and What could be the reason of this issue Can we have dedicated support for this? Thank You.

Hello Quinn “The Eskimo!”, I am trying to customize the mac os login screen. The initial thing I want to do is to add a link or a button on login screen, tapping which should open a web page. As suggested by you on different forums, I opened a DTS ticket and received the starter project for the same. Now the problem is, the starter project is crashing with following log, arguments: mechanism -1 will get arguments mechanism 2 will get arguments mechanism -1 did get arguments none mechanism -1 will get LAContext mechanism 2 will get LA context QAuthHostSimulator/QAuthHostEngineCallbackHelper.swift:144: Fatal error Could you please help me resolve this issue. Thanks.

Hi, I am writing in to check if there is a way to detect Frida. As we have a Mobile App Penetration Test (MAPT), and the tester uses Frida as the tool for the penetration test. We have implemented these codes to detect Frida and Objection: static bool isInjected0(){ NSArray *suspiciousLibraries = [NSArray arrayWithObjects:@"FridaGadget", @"frida", @"cynject", @"libcycript", nil]; int count = _dyld_image_count();//Get the number of loaded images if (count> 0) { for (int i = 0; i <count; i++) { //Traverse all image_names. Determine whether there are DynamicLibraries const char * dyld = _dyld_get_image_name(i); if (strstr(dyld, "DynamicLibraries")) { return YES; } for (NSString *suspiciousLibrary in suspiciousLibraries) { if ([[NSString stringWithUTF8String: dyld] rangeOfString:suspiciousLibrary].location != NSNotFound) { return YES; } } } } return NO; } We also added these codes to detect the default ports than Frida is using @interface FridaDetector : NSObject + (BOOL)detectFridaPort; + (BOOL)isPortOpen:(in_port_t)port; @end @implementation FridaDetector + (BOOL)detectFridaPort { in_port_t port = 27042; return [self isPortOpen:port]; } + (BOOL)isPortOpen:(in_port_t)port { int socketFileDescriptor = socket(AF_INET, SOCK_STREAM, 0); if (socketFileDescriptor == -1) { NSLog(@"Failed to create socket"); return NO; } struct sockaddr_in addr; memset(&addr, 0, sizeof(addr)); addr.sin_len = sizeof(addr); addr.sin_family = AF_INET; addr.sin_port = htons(port); // Ensuring the port is in network byte order addr.sin_addr.s_addr = inet_addr("127.0.0.1"); struct sockaddr bind_addr; memcpy(&bind_addr, &addr, sizeof(addr)); BOOL result = NO; if (bind(socketFileDescriptor, (struct sockaddr*)&bind_addr, sizeof(addr)) == -1) { NSLog(@"Failed to bind socket, port might be open"); result = YES; } else if (listen(socketFileDescriptor, SOMAXCONN) == -1) { NSLog(@"Failed to listen on socket, port might be open"); result = YES; } close(socketFileDescriptor); return result; } @end We are able to detect Frida on a normal device, but I believe the tester did some workaround to prevent us from detecting the Frida present on their device. Is there a better way to detect Frida and Objection?

We need to do some operations in a login screen, but when the user uses a WPA2-Enterprise network, the authentication to this network is only possible after the login process has already been completed. Is there a way to change the network on login screen or a way to authenticate on the WPA2-Enterprise network before a completed login? STEPS TO REPRODUCE 1 - Use a WPA2-Enterprise 2 - Set WPA2-Enterprise as Auto-Join/Principal 3 - Reboot the Machine 4 - On the logon screen it's impossible to authenticate on the enterprise network even then type the username and password.

Hi: I saw the post WWDC WebKit release notes said Safari will support largeblob extension from version 17. But when I create a credential with largeblob extension, different action takes according what authenticator used. The credential options is: "credCreateOptions": { "rp": { "name": "WebAuthn demo", "id": "webauthn.turinggear.com" }, "user": { "name": "Jonathon.Runte97@gmail.com", "displayName": "Jonathon.Runte97@gmail.com", "id": "bqShD9YGRicjM-1foXiBqrdCzTHTuG1bkmKaxzn7oEM" }, "challenge": "9BP4y2epk2b3MhRCRRS5tt4bdWYLPJcKBLMMiB_7p7E", "pubKeyCredParams": [ { "alg": -7, "type": "public-key" }, { "alg": -257, "type": "public-key" } ], "excludeCredentials": [], "authenticatorSelection": { "requireResidentKey": true, "residentKey": "required", "userVerification": "discouraged" }, "attestation": "none", "extensions": { "credProps": true, "largeBlob": { "support": "preferred" } } } When i choose use iPhone be my authenticator, it seems that largeblob act as it should be: "credential" : { "id": "ZRxBdH4LKE4eiVxbwcA4Kmn9VZk", "rawId": "ZRxBdH4LKE4eiVxbwcA4Kmn9VZk", "response": { "attestationObject": "o2NmbXRkbm9uZWdhdHRTdG10oGhhdXRoRGF0YViYSETDPyxegNfyH_fI_8t9iVRDn34LxYd8YH1k2u4xSk5dAAAAAPv8MAcVTk7MjAtuAgVX170AFGUcQXR-CyhOHolcW8HAOCpp_VWZpQECAyYgASFYICY6gkqg6OG_v1BlGCPj7gSwsu_c0vTmVzmfd7TsqEh5Ilgg_Cn0mAiO8QCx7J1xw809VBq8iI-U5pgY0I947B7XF9g", "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiOVcta3RMbEswemZDSXpFb2hNd3E3OTgxQXJlRzV0aEVBdmRHdXNHcUsxcyIsIm9yaWdpbiI6Imh0dHBzOi8vd2ViYXV0aG4udHVyaW5nZ2Vhci5jb20ifQ", "transports": [ "internal", "hybrid" ], "publicKeyAlgorithm": -7, "publicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEJjqCSqDo4b-_UGUYI-PuBLCy79zS9OZXOZ93tOyoSHn8KfSYCI7xALHsnXHDzT1UGryIj5TmmBjQj3jsHtcX2A", "authenticatorData": "SETDPyxegNfyH_fI_8t9iVRDn34LxYd8YH1k2u4xSk5dAAAAAPv8MAcVTk7MjAtuAgVX170AFGUcQXR-CyhOHolcW8HAOCpp_VWZpQECAyYgASFYICY6gkqg6OG_v1BlGCPj7gSwsu_c0vTmVzmfd7TsqEh5Ilgg_Cn0mAiO8QCx7J1xw809VBq8iI-U5pgY0I947B7XF9g" }, "type": "public-key", "clientExtensionResults": { "largeBlob": { "supported": true } }, "authenticatorAttachment": "platform" } Safari returns clientExtensionResults.largeBlob.supported= ture. But when I use an NFC authenticator with the same credCreateOptions, safari didnot return clientExtensionResults section. Response as follows(ignore the challenge and others random data): "credential" : { "id": "uEVMzgsINXj7bHFD5Z5xbMGJ7k6tnrMQSLjB4yB8_0GxbUPoWYUYX8E3D9XB24Cv-PMh6cRpCFt5klUHqsot2Yc48BVu5TN8sbabTgped2x46ljdsxFzaNCA8D2y9FZK8BHLLZTKHNuzJw4SCYUkzg", "rawId": "uEVMzgsINXj7bHFD5Z5xbMGJ7k6tnrMQSLjB4yB8_0GxbUPoWYUYX8E3D9XB24Cv-PMh6cRpCFt5klUHqsot2Yc48BVu5TN8sbabTgped2x46ljdsxFzaNCA8D2y9FZK8BHLLZTKHNuzJw4SCYUkzg", "response": { "attestationObject": "o2NmbXRkbm9uZWdhdHRTdG10oGhhdXRoRGF0YVj0SETDPyxegNfyH_fI_8t9iVRDn34LxYd8YH1k2u4xSk5FAAABeAAAAAAAAAAAAAAAAAAAAAAAcLhFTM4LCDV4-2xxQ-WecWzBie5OrZ6zEEi4weMgfP9BsW1D6FmFGF_BNw_VwduAr_jzIenEaQhbeZJVB6rKLdmHOPAVbuUzfLG2m04KXndseOpY3bMRc2jQgPA9svRWSvARyy2UyhzbsycOEgmFJM6lAQIDJiABIVggg2LXO5Q2U0ETrSxrLKxCfKKCTCitTCx9bpxD1Gw917ciWCDsxnw4Wd7M_UTiGQJ7swCMXN83nprsT8wkTlftXRizmw", "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiOUJQNHkyZXBrMmIzTWhSQ1JSUzV0dDRiZFdZTFBKY0tCTE1NaUJfN3A3RSIsIm9yaWdpbiI6Imh0dHBzOi8vd2ViYXV0aG4udHVyaW5nZ2Vhci5jb20ifQ", "transports": [ "nfc" ], "publicKeyAlgorithm": -7, "publicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEg2LXO5Q2U0ETrSxrLKxCfKKCTCitTCx9bpxD1Gw917fsxnw4Wd7M_UTiGQJ7swCMXN83nprsT8wkTlftXRizmw", "authenticatorData": "SETDPyxegNfyH_fI_8t9iVRDn34LxYd8YH1k2u4xSk5FAAABeAAAAAAAAAAAAAAAAAAAAAAAcLhFTM4LCDV4-2xxQ-WecWzBie5OrZ6zEEi4weMgfP9BsW1D6FmFGF_BNw_VwduAr_jzIenEaQhbeZJVB6rKLdmHOPAVbuUzfLG2m04KXndseOpY3bMRc2jQgPA9svRWSvARyy2UyhzbsycOEgmFJM6lAQIDJiABIVggg2LXO5Q2U0ETrSxrLKxCfKKCTCitTCx9bpxD1Gw917ciWCDsxnw4Wd7M_UTiGQJ7swCMXN83nprsT8wkTlftXRizmw" }, "type": "public-key", "clientExtensionResults": {}, "authenticatorAttachment": "cross-platform" } Even without a clientExtensionResults.largeBlob.supported= false. According to w3c, it should return clientExtensionResults.largeBlob.supported= false ? The NFC authenticaor do support largeblob extensions and act write with the same credCreateOptions on edge on windows. Does safari need some extra parameters? My safari is the newest version of 17.5 (19618.2.12.11.6), mac version is Sonoma 14.5(23F79). Thank you very much.

63 ??? (Foundation + 69644) [0x197ad600c] 63 ??? (com.apple.StreamingUnzipService + 39148) [0x1009a58ec] 60 ??? (com.apple.StreamingUnzipService + 47188) [0x1009a7854] 60 ??? (libsystem_kernel.dylib + 24156) [0x1e1d50e5c] 57 &lt;on behalf of appstored [175] (originated by nsurlsessiond [109])&gt; 3 &lt;on behalf of appstored [175] (originated by appstored [175]), Effective Thread QoS User Initiated, Requested Thread QoS User Initiated&gt; 3 ??? (com.apple.StreamingUnzipService + 47560) [0x1009a79c8] 3 ??? (libsystem_kernel.dylib + 24156) [0x1e1d50e5c] 3 &lt;on behalf of appstored [175] (originated by nsurlsessiond [109])&gt; 28 ??? (libsystem_pthread.dylib + 18680) [0x1f5af38f8] 28 ??? (libdispatch.dylib + 90268) [0x1a0b5409c] 28 ??? (libdispatch.dylib + 88212) [0x1a0b53894] 28 ??? (libdispatch.dylib + 26868) [0x1a0b448f4] 28 ??? (libdispatch.dylib + 29532) [0x1a0b4535c] 28 ??? (libdispatch.dylib + 15828) [0x1a0b41dd4] 28 ??? (libdispatch.dylib + 8508) [0x1a0b4013c] 28 ??? (com.apple.StreamingUnzipService + 74144) [0x1009ae1a0] 28 ??? (com.apple.StreamingUnzipService + 70208) [0x1009ad240] 27 ??? (com.apple.StreamingUnzipService + 70912) [0x1009ad500] 27 ??? (libsystem_kernel.dylib + 24156) [0x1e1d50e5c] 26 &lt;on behalf of appstored [175] (originated by nsurlsessiond [109])&gt; 1 &lt;on behalf of appstored [175] (originated by appstored [175]), Effective Thread QoS User Initiated, Requested Thread QoS User Initiated&gt; 1 ??? (com.apple.StreamingUnzipService + 70820) [0x1009ad4a4] 1 ??? (com.apple.StreamingUnzipService + 64680) [0x1009abca8] 1 ??? (libsystem_kernel.dylib + 26968) [0x1e1d51958] 1 &lt;on behalf of appstored [175] (origi

I'm having several issues with managing certificates in the default keychain using swift on macOS. I have a self containd command line test program with hardcoded pem format cert and private key. I can convert both pem formats to der via openssl. Issue 1, For Certificate: I can create a certificate and add it to the keychain. I am not able to find or delete the certificate after I add it. Issue 2, For the key: I can create the key but when I try to add it to the keychain I get "A required entitlement isn't present." In our actual app, I can add certs but can't find them (success but cert returned does not match). I can add keys and find them. All using similar code to my test app, so I decided to write the test and got stuck. I don't see any special entitlements for keychain access in our app. Looking for answers on issue 1 and issue 2. I have a self contained public github project here as it won't let me attach a zip: https://github.com/alfieeisenberg/cgcertmgr It won't let me attach a zip of the project or my source. In both cases below I tried with just labels, just tags, and both with same results. Here is how I'm trying to add keys: func addPrivateKeyToKeychain(privateKey: SecKey, label: String) -&gt; Bool { let addQuery: [NSString: Any] = [ kSecClass: kSecClassKey, kSecAttrKeyClass: kSecAttrKeyClassPrivate, kSecAttrLabel: label, kSecAttrApplicationTag: label, kSecValueRef: privateKey ] let status = SecItemAdd(addQuery as CFDictionary, nil) if status != errSecSuccess { if status == errSecDuplicateItem { print("\(#function): \(#line), Key already exists: errSecDuplicateItem") } print("\(#function): \(#line), status: \(status) \(SecCopyErrorMessageString(status, nil) as String? ?? "Unknown error")") } return status == errSecSuccess } Here is adding certs: func addCertificateToKeychain(certificate: SecCertificate, label: String) -&gt; Bool { let addQuery: [NSString: Any] = [ kSecClass: kSecClassCertificate, kSecAttrLabel: label, kSecAttrApplicationTag: label, kSecValueRef: certificate ] let status = SecItemAdd(addQuery as CFDictionary, nil) if status != errSecSuccess { print("\(#function): \(#line), status: \(status) \(SecCopyErrorMessageString(status, nil) as String? ?? "Unknown error")") } return status == errSecSuccess } And finding a cert: func findCertificateInKeychain(label: String) -&gt; SecCertificate? { let query: [NSString: Any] = [ kSecClass: kSecClassCertificate, kSecAttrLabel: label, kSecAttrApplicationTag: label, kSecReturnRef: kCFBooleanTrue!, kSecMatchLimit: kSecMatchLimitOne ] var item: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &amp;item) print("\(#function): \(#line), status: \(status)") if status != errSecSuccess { print("\(#function): \(#line), status: \(status) \(SecCopyErrorMessageString(status, nil) as String? ?? "Unknown error")") } guard status == errSecSuccess, let certificate = item else { print("\(#function): \(#line), Certificate not found") return nil } return (certificate as! SecCertificate) } Output: ===Trying Certs=== tryCerts(pemCertificate:): 338, Certificate added: true findCertificateInKeychain(label:): 272, status: -25300 findCertificateInKeychain(label:): 274, status: -25300 The specified item could not be found in the keychain. findCertificateInKeychain(label:): 277, Certificate not found tryCerts(pemCertificate:): 340, Certificate found: nil deleteCertificateFromKeychain(label:): 314, status: -25300 The specified item could not be found in the keychain. tryCerts(pemCertificate:): 342, Certificate deleted: false ===Trying Keys=== addPrivateKeyToKeychain(privateKey:label:): 256, status: -34018 A required entitlement isn't present. Program ended with exit code: 0

Hi, since the IoT cybersecurity, I need to hide the version of all sevices. For the 7000 port, AirTunes, I can't find the method to hide it. Like tomcat version hide, how can I hide the version of it?

We have a pair of apps that are used to monitor the location of a person and allow them to reach out for help when needed. The apps are designed to be used with persons with special needs. A large portion of our target audience is people that have cognitive disabilities. One app is used by people that monitor and help the person with needs, and the other is used by the person with needs who is not with them all the time. The issue we have is that our users have trouble understanding what to do when this verification popup appears. This popup continues to appear over and over and over. This is a severe health and safety issue for us. We find that the user is often times confused by the popup and is disabling the background location tracking preventing the needs provider from being able to track the location of the user. It would be great if there was a special Entitlement that could be granted that would prevent this 'feature' of iOS. Or possibly simply a setting that the user's provider can setup on their phone to stop the annoying and dangerous constant popups. If anybody knows of a way to prevent this popup, please let us know. Otherwise, if someone at Apple could suggest how we can make this happen in the future.

Due to changes in macOS 15 Sequoia with respect to container privacy/privileges, I have observed warnings with one of my apps (non-sandboxed) when its subsidiary crash reporter process tries to access the host app's data folder. I THINK I've worked around this issue by granting the crash reporter and the host app access to the same application group. I'm not 100% sure how all this works except that the problem went away :) The problem is, once the problem goes away on a given system, it goes away for good! Even with subsequent attempts to open a version of the app before the fix was in place, the system warning is not presented. I've tried to reset SystemPolicyAppBundles on the app via tccutil, but it makes no difference. Using the wisdom from one of Quinn's posts (https://developer.apple.com/forums/thread/706442) I set up a log stream invocation to try to gather clues, and I notice that when I launch my app now, I see messages like: Found provenance data on process: TA(82542d1beaf132a6, 2), 51084 Process was already in provenance sandbox, skipping: 51084, TA(82542d1beaf132a6, 2) I suspect this "provenance" may reflect the change in how the system treats my application. First: I wonder if it's a bug that any change in "provenance" should retroactively apply to versions of the app before the change was made. Second, I wonder if there's some way to RESET this provenance so that I can reproduce the bug again? I might be able to reproduce it by changing the bundle ID for the app but for purposes of testing against existing, shipped versions of the app, I'd love to be able to reset things for sanity-checking.

Hi Team, There is situation in which I want to implement session Resumption in IOS. I am using Network Framework but I am unable to find a way, how to enable the resumption . It will more beneficial for me if you guys can help me in that. Regards,

We've created a Message Filter Extension that relies on the network action workflow of Message Filter Extensions (ILMessageFilterExtension). Has anyone applied authentication to these calls? It works great when being called un-authenticated, but the logic behind this API costs us money, and we'd like to rate-limit it by the client to avoid someone DDOs'ing the exposed API and racking up our bill. We've followed https://developer.apple.com/documentation/sms_and_call_reporting/sms_and_mms_message_filtering/creating_a_message_filter_app_extension and set up a Shared Web Credential (both webcredential and messagefilter associated domains). Still, our calls never have the created and verified credentials forwarded to our service with the REST API call. Have any thoughts on how to apply a shared web credential to those delegated calls?

Recently our app went through a series of Mobile App Penetration Test (MAPT), and was flagged with bypassed SSL Pinning (https://cwe.mitre.org/data/definitions/693.html). The tester is using Frida and is able to attach to SSL_CTX_set_custom_verify() from libboringssl.dylib, as shown in this script (https://codeshare.frida.re/@federicodotta/ios13-pinning-bypass/). As per my research, though I'm not absolutely sure, I see that boringSSL was added since iOS 11 (https://developer.apple.com/forums/thread/88387) and (https://github.com/firebase/firebase-ios-sdk/issues/314). I would like to check if there is anyway around this, as I am using TrustKit (https://cocoapods.org/pods/TrustKit), and I realised many other pods also tag on SSL_CTX_set_custom_verify() for SSL Pinning. As our app requires SSL Pinning, and a resolution to this issue, I would like to ask if there is any solution, whether it being a recommended pod/library, or a native solution (preferred) to do SSL Certificate Pinning. Thank you.

Description: I'm encountering an SSL error (error code: -1200) when trying to establish a secure connection in my app. This issue only occurs when the network signal is low on Airtel. The connection works fine on a normal network signal. Here are the details: Device: iPhone 11 iOS Version: 17.2.1 Network Provider: Airtel Error Message: An SSL error has occurred and a secure connection to the server cannot be made. Error code: -1200 Tried different network settings and Observed the issue only on low network signal. Any insights or suggestions to resolve this issue would be greatly appreciated. Thank you!

I am trying to develop a custom plugin. Below is my auth plugin plist. However, the mechanism marked as privileged is not being triggered by macOS. If I remove the privilege, it gets called. Any pointers on this? TestPlugin:MyLogin and TestPlugin:MyUser,privileged are my custom plugins. <?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>comment</key> <string>Login mechanism based rule. Not for general use, yet.</string> <key>created</key> <real>728811899.153513</real> <key>mechanisms</key> <array> <string>builtin:prelogin</string> <string>TestPlugin:MyLogin</string> <string>TestPlugin:MyUser,privileged</string> <string>builtin:login-begin</string> <string>builtin:reset-password,privileged</string> <string>loginwindow:FDESupport,privileged</string> <string>builtin:forward-login,privileged</string> <string>builtin:auto-login,privileged</string> <string>builtin:authenticate,privileged</string> <string>PKINITMechanism:auth,privileged</string> <string>builtin:login-success</string> <string>loginwindow:success</string> <string>HomeDirMechanism:login,privileged</string> <string>HomeDirMechanism:status</string> <string>MCXMechanism:login</string> <string>CryptoTokenKit:login</string> <string>PSSOAuthPlugin:login-auth</string> <string>loginwindow:done</string> </array> <key>modified</key> <real>740052960.218761</real> <key>shared</key> <true/> <key>tries</key> <integer>10000</integer> <key>version</key> <integer>10</integer> </dict> </plist>

I have an app (currently not released on App Store) which runs on both iOS and macOS. The app has widgets for both iOS and macOS which uses user preference (set in app) into account while showing data. Before upgrading to macOS 15 (until Sonoma) widgets were working fine and app was launching correctly, but after upgrading to macOS 15 Sequoia, every time I launch the app it give popup saying '“Kontest” would like to access data from other apps. Keeping app data separate makes it easier to manage your privacy and security.' and also widgets do not get user preferences and throw the same type of error on Console application when using logging. My App group for both iOS and macOS is 'group.com.xxxxxx.yyyyy'. I am calling it as 'UserDefaults(suiteName: Constants.userDefaultsGroupID)!.bool(forKey: "shouldFetchAllEventsFromCalendar")'. Can anyone tell, what am I doing wrong here?

Hello, I am writing a macOS CLI application that holds cryptocurrency funds and uses Secure Enclave for security. I intend to create APIs so that other applications can create transactions from user's wallet in a secure way for the user. I am using P256 curve and authenticating a transaction involves making a signature for a hash of transaction data. Currently, this is how the authentication box looks like: However, this does not display any information about the transaction. If user is using my application, then I could display the information in the terminal. However, if some other CLI app wants to create transactions for the user, printing information in the terminal is insecure since a malicious app could override what is being printed. I see a rich authentication UI in apple apps. I wonder if there is a way to write UI for such applications. I would like to display some transaction information in the box instead of just "myapp needs to authenticate to continue". It would be great if there is a way to customize that text / add more text to it.

How do I delete or edit codes in the iOS Beta Passwords app?