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.

A client asked why we can't detect other apps installed on a device without an MDM profile, we explained this isn't possible due to privacy and security restrictions on iOS. A regular app cannot find other apps that are installed unless part of the same group. The client then told us to download SpyBuster (on the App Store) which somehow is collecting a list of Bundle IDs or names of all installed apps somehow. We were skeptical, but sure enough, the app showed us a list of apps we had installed. How is it doing this?!?! No MDM profile associated with the app. No special permissions requested. No access to anything shown in privacy & security in settings. Is there a special entitlement we're not aware of? Just seems like they must be using a private API call to get this info but that would of course mean it should be pulled from the App Store. We'd love to have this capability in our apps if it's legit and accepted by App Store review. Thanks!

We are interested in using a hardware-bound key to sign requests made to a server prior to a user being logged in. We would do this using a launch daemon. The goal here is to have a high degree of assurance that a request came from a particular device. The normal way to do this would be with a private key in the Secure Enclave. Based on these threads: https://forums.developer.apple.com/forums/thread/719342 https://forums.developer.apple.com/forums/thread/115833 and the write-up about the Data Protection Keychain, it doesn't appear possible with the SE. Rather, it seems that we must wait until we have a logged-in user context before we can use the SE. My questions are: am I correct in that the SE is not usable in the system context prior to login? is there any other way on macOS to sign a request in such a way that we know it comes from a specific device? Thanks.

Hi everyone, I'm currently developing a custom authorization plugin for macOS and have encountered an issue that I need help with. I've modified the auth DB to use my custom plugin instead of the default login window. Although I'm able to set both the name and password as context values, the login process is failing, and I'm seeing the following error in the security agent log: <string>builtin:prelogin</string>     <string>builtin:policy-banner</string>     <string>MyPlugin:login</string>     <string>MyPlugin:value</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> I am setting name and password in MyPlugin:login and also able to see same in MyPlugin:value mechanics. 2 2024-07-25 06:53:30.813047-0700 0x2e3b Info 0x0 822 0 SecurityAgentHelper-x86_64: (MyPlugin) *****The name and password is test and test1234**** But 2024-07-25 02:33:00.777530-0700 0x8772 Debug 0x0 1527 0 SecurityAgent: (MCXMechanism) [com.apple.ManagedClient:MCXSecurityPlugin] MCXSecurityAgent.invoke kAuthorizationEnvironmentName is NULL 2024-07-25 02:33:00.777530-0700 0x8772 Debug 0x0 1527 0 SecurityAgent: (MCXMechanism) [com.apple.ManagedClient:MCXSecurityPlugin] MCXSecurityAgent.invoke - user logging in is '(null)' Has anyone encountered this issue before or have any insights into what might be causing the kAuthorizationEnvironmentName is NULL error and why the user logging in is shown as '(null)'? Any guidance or suggestions on how to resolve this would be greatly appreciated.

Hello! I have a question regarding AVSpeechSynthesizer and privacy concerns. Does the processing in AVSpeechSynthesizer occur on device, or is any part of the audio or text shared with Apple for service improvement or other purposes?

I created a simple web browser using WKWebView, but as far as I can tell, there is not a way to auto-populate credentials or save credentials a user enters into a login form at a 3rd-party website like Netflix (i.e., not my own app domain). Is this correct? If this is wrong, what are the APIs to support this? My use case is that I want to create an immersive app in visionOS that includes a window that lets the user surf the web (among other things). Ideally, I could just use a Safari window in my immersive app, but I don't think this is possible either. My work around is to create my own web browser... which works, minus the credential issue. Is it possible to bring a Safari window into an immersive visionOS app's experience? (IMHO, that would be a great feature)

Hi Folks, I have a need to create and store a 256 bit symmetric key that I use to encrypt and decrypt data stored on disk. There is also a need to continue to do this both in the backgroud and in the application extensions. As far as I know, SE does not work with symmetric key, but there is an option to encrypt the symmetric key with an SE-protected asymmetric key. The question arises, how is this different from just storing the key in Keychain, since I can't take advantage of SE's main advantage of not storing the key in memory, even for a short time. (Anyway, I can't not store the key in memory anyway, because the key is used by a third-party framework.) Should I also use SE for this purpose, decrypt my symmetric key, give the symmetric key to the framework for a short time and then zeroize it?

Is there a way for an app to interact with the new iOS 18 feature "Locked/Hidden Apps"? In our apps we prompt our users for biometric authentication ourselves and found that locking an app seems to interfere with that.

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?

I am building a command line app to interface to a Bosch Smart Home Controller (SHC) using URLSession and running into a problem with certificate authentication. Sending a request to the SHC results in a -1202 error "The certificate for this server is invalid..." which was expected as it's counted as a self-signed cert. In URLSessionDelegate SecTrustEvaluateWithError returned the CFError.localisedDescription Smart Home Controller Productive Root CA” certificate is not trusted So I used SecItemAdd to add this certificate to my login keychain and then set it to "Always Trust", but the error still persists. routines:OPENSSL_internal:SSLV3_ALERT_BAD_CERTIFICATE:/AppleInternal/Library/BuildRoots/a8fc4767-fd9e-11ee-8f2e-b26cde007628/Library/Caches/com.apple.xbs/Sources/boringssl/ssl/tls_record.cc:592:SSL alert number 42 I've tried various workarounds and also added an intermediate certificate received from the SHC to my login keychain with "Always Trust" set but the error persists - am I missing something?

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.