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 resources: DevForums tags: Security Foundation, Security Interface Security Foundation framework documentation Security Interface framework documentation BSD Privilege Escalation on macOS 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.

I'm trying to develop a GUI app on macOS that takes control of the screen so that user must perform certain actions before regaining control of the desktop. I don't want the user to be able to kill the process (for example via an "********" shell script that looks for the process and terminates it with kill). Based on this post it is not possible to create an unkillable process on macOS. I'm wondering, however, if it's possible to run the GUI process in root (or with other escalated privileges) such that the logged in user cannot kill it. So it's killable, but you need privileges above what the logged in user has (assuming they are not root). I'm not worried about a root user being able to kill it. Such an app would run in a managed context. I've played around with Service Background Tasks, but so far haven't found what I'm looking for. I'm hoping someone (especially from Apple) might be able to tell me if this goal is even achievable with macOS Sequoia (and beyond).

I'm sitting at my house and trying to sign my test device out of my apple ID so I can sign into a Sandbox user, but now I have an hour to kill because of this terribly broken "security" feature that thinks it's in an unfamiliar location, despite being at the only location it's ever known. Looks like I'll just be disabling this feature all together. Especially as a device with Developer Mode enabled, which gets reset regularly, there should be additional options here. Come on!

We are trying to develop an app that will be responsible for managing 5000+ managed iPads through Intune MDM. The user flow is to have a device locked to a single app when a user is not logged in, but to make the device available to other apps once a user is authenticated. We already tried UIAccessibility GuidedAccess Mode and autonomous single app mode but those were not sufficient due to our need to be able to toggle this from the background. When the device may be asleep. So another way we could achieve this functionality would be to control all app access under a launching mechanism. That way we could allow one app to be visible in our MDM configuration and try to access our business app through that using deep links. If this were to work, we would have to be able to hide an app and still make it launchable from the manager. Any ideas? Thanks

Our project currently uses a value called k_uuid as the unique identifier for each user. This value is generated based on the Identifier for Vendor (IDFV) and is stored both in the Keychain and local storage to prevent changes when the app is uninstalled and reinstalled. However, we are now facing a critical issue. We plan to transfer the app from Developer Account A to Developer Account B using Apple’s App Transfer Process. During this transfer: Our backend services will remain unchanged Our development team will remain the same Only the developer account will change We understand that during this transfer process, the Team ID associated with the developer account will change, which in turn will make it impossible to access the existing Keychain data. As a result, if a user uninstalls and reinstalls the app after the transfer, their original unique ID (k_uuid) will change. This will lead to serious consequences, including: Inability to recognize returning users Loss of user data such as subscriptions, virtual currency, and usage history Therefore, we urgently request guidance and assistance from Apple to: Ensure that the k_uuid remains unchanged after the app transfer, or Provide a solution that allows us to map users between the old and new environment, ensuring data continuity and integrity for all existing users

Good day. The Infrastructure Security team my company is concerned about potential information security incidents in https://appstoreconnect.apple.com/. We intend to: Collect logs of any activities within our organization (for example, someone adding a new user with administrative privileges or publishing a new application from a corporate account). Automatically deliver these logs to our SIEM (e.g., Splunk), so that alerts can be generated and potential security incidents can be addressed, such as breaches of internal policies by an employee or a compromise of a corporate account associated with https://appstoreconnect.apple.com/. Could you please advise on how this can be implemented?

iOS 18.4 introduced some requirements on the Key Usage of 802.1x server certificates, as described here. https://support.apple.com/en-us/121158 When using TLS_ECDHE_RSA or TLS_DHE_RSA cipher suites, 802.1X server certificates containing a Key Usage extension must have Digital Signature key usage set. When using the TLS_RSA cipher suite, 802.1X server certificates containing a Key Usage extension must have Key Encipherment key usage set. It reads like the change is supposed to affect 802.1x only. However, we have found out that the new restrictions are actually imposed on all TLS connections using the Network framework, including in Safari. Unlike other certificate errors which can be either ignored by users (as in Safari) or by code (via sec_protocol_options_set_verify_block), these new ones can't. Even if passing completion(true) in the TLS verification block, the connection still ends up in waiting state with error -9830: illegal parameter. I understand that these requirements are valid ones but as a generic TLS library I also expect that Network framework could at least allow overriding the behavior. The current treatment is not consistent with those on other certificate errors. Since I can't upload certificates, here is how to reproduce a certificate that fails. Create a OpenSSL config file test.cnf [ req ] default_bits = 2048 distinguished_name = dn x509_extensions = v3_ca prompt = no [ dn ] CN = example.com [ v3_ca ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = CA:TRUE keyUsage = critical, keyCertSign, cRLSign Generate certificate and private key openssl req -x509 -new -nodes -keyout key.pem -out cert.pem -days 365 -config test.cnf And here is the client code to test. // Target server and port let host = NWEndpoint.Host("example.com") let port = NWEndpoint.Port("443")! // Configure insecure TLS options let tlsOptions = NWProtocolTLS.Options() sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { _, _, completion in // Always trust completion(true) }, DispatchQueue.global()) let params = NWParameters(tls: tlsOptions) let connection = NWConnection(host: .init(host), port: .init(rawValue: port)!, using: params) connection.stateUpdateHandler = { newState in switch newState { case .ready: print("TLS connection established") case .failed(let error): print("Connection failed: \(error)") case .cancelled: print("Connection canceled") case .preparing: print("Connection preparing") case .waiting(let error): print("Connection waiting: \(error)") case .setup: print("Connection setup") default: break } } connection.start(queue: .global()) Output Connection preparing Connection waiting: -9830: illegal parameter Previously reported as FB17099740

Is it true that the auth.db file is reset after updates? If so, is this behavior expected and when does it occur specifically? Does this occur on minor updates as well or major OS updates only?

I'm using Secure Enclave to generate and use a private key like this: let access = SecAccessControlCreateWithFlags(nil, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, [.privateKeyUsage, .biometryAny], nil) let attributes: [String: Any] = [ kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom, kSecAttrKeySizeInBits as String: 256, kSecAttrTokenID as String: kSecAttrTokenIDSecureEnclave, kSecAttrAccessControl as String: access as Any, kSecAttrApplicationTag as String: "com.example.key".data(using: .utf8)!, kSecReturnRef as String: true ] let privateKey = SecKeyCreateRandomKey(attributes as CFDictionary, nil) Later, I use this key to sign a message: let signature = SecKeyCreateSignature(privateKey, .ecdsaSignatureMessageX962SHA256, dataToSign as CFData, nil) This prompts for biometric authentication, but shows the default system text. How can I customize or localize the biometric prompt (e.g., title, description, button text) shown during SecKeyCreateSignature? Thanks!

Hello! We have code that extracts macOS Installer package (.pkg, .mpkg) signature information using APIs defined in <xar/xar.h> The code opens the package using ‘xar_open’ API like this. func open(file: String) throws(XarError) { xarfile = xar_open(file, READ) if xarfile == nil { throw .fileOpenError } } This code produces a clang warning in our CI build system when built for macOS 12 and up. 'xar_open' was deprecated in macOS 12.0: xar is a deprecated file format and should not be used. Question #1: What is the appropriate / more preferred way to extract signature information from an Installer package given that xar related APIs are deprecated? We use xar APIs to validate the package signature prior to installation to prevent packagers not signed by our team ID from being installed. Question #2: “xar is a deprecated file format and should not be used.”. Does this phrase refer to the file format that should be avoided or the API that extract signature information? We distribute our product using Developer ID method that using pkg/mpkg formats which I believe internally follow the same structure as xar files. I hope this message does not mean we should rethink the distribution method for our products. Thank you. Filed FB FB17148233 as well.

Problem Statement: Pre-requisite is to generate a PKCS#12 file using openssl 3.x or above. Note: I have created a sample cert, but unable to upload it to this thread. Let me know if there is a different way I can upload. When trying to import a p12 certificate (generated using openssl 3.x) using SecPKCS12Import on MacOS (tried on Ventura, Sonoma, Sequoia). It is failing with the error code: -25264 and error message: MAC verification failed during PKCS12 import (wrong password?). I have tried importing in multiple ways through, Security Framework API (SecPKCS12Import) CLI (security import &lt;cert_name&gt; -k ~/Library/Keychains/login.keychain -P "&lt;password&gt;”) Drag and drop in to the Keychain Application All of them fail to import the p12 cert. RCA: The issues seems to be due to the difference in the MAC algorithm. The MAC algorithm used in the modern certs (by OpenSSL3 is SHA-256) which is not supported by the APPLE’s Security Framework. The keychain seems to be expecting the MAC algorithm to be SHA-1. Workaround: The current workaround is to convert the modern p12 cert to a legacy format (using openssl legacy provider which uses openssl 1.1.x consisting of insecure algorithms) which the SecPKCS12Import API understands. I have created a sample code using references from another similar thread (https://developer.apple.com/forums/thread/723242) from 2023. The steps to compile and execute the sample is mentioned in the same file. PFA the sample code by the name “pkcs12_modern_to_legacy_converter.cpp”. Also PFA a sample certificate which will help reproduce the issue by the name “modern_certificate.p12” whose password is “export”. Questions: Is there a fix on this issue? If yes, pls guide me through it; else, is it expected to be fixed in the future releases? Is there a different way to import the p12 cert which is resistant to the issue? This issue also poses a security concerns on using outdated cryptographic algorithms. Kindly share your thoughts. pkcs12_modern_to_legacy_converter.cpp

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.

I have been trying to find a way to be able to sign some data with private key of an identity in login keychain without raising any prompts. I am able to do this with system keychain (obviously with correct permissions and checks) but not with login keychain. It always ends up asking user for their login password. Here is how the code looks, roughly, NSDictionary *query = @{ (__bridge id)kSecClass: (__bridge id)kSecClassIdentity, (__bridge id)kSecReturnRef: @YES, (__bridge id)kSecMatchLimit: (__bridge id)kSecMatchLimitAll }; CFTypeRef result = NULL; OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, (CFTypeRef *)&amp;amp;result); NSArray *identities = ( NSArray *)result; SecIdentityRef identity = NULL; for (id _ident in identities) { // pick one as required } SecKeyRef privateKey = NULL; OSStatus status = SecIdentityCopyPrivateKey(identity, &amp;amp;privateKey); NSData *strData = [string dataUsingEncoding:NSUTF8StringEncoding]; unsigned char hash[CC_SHA256_DIGEST_LENGTH]; CC_SHA256(strData.bytes, (CC_LONG)strData.length, hash); NSData *digestData = [NSData dataWithBytes:hash length:CC_SHA256_DIGEST_LENGTH]; CFErrorRef cfError = NULL; NSData *signature = (__bridge_transfer NSData *)SecKeyCreateSignature(privateKey, kSecKeyAlgorithmRSASignatureDigestPKCS1v15SHA256, (__bridge CFDataRef)digestData, &amp;amp;cfError); Above code raises these system logs in console default 08:44:52.781024+0000 securityd client is valid, proceeding default 08:44:52.781172+0000 securityd code requirement check failed (-67050), client is not Apple-signed default 08:44:52.781233+0000 securityd displaying keychain prompt for /Applications/Demo.app(81692) If the key is in login keychain, is there any way to do SecKeyCreateSignature without raising prompts? What does client is not Apple-signed mean? PS: Identities are pre-installed either manually or via some device management solution, the application is not installing them.

Hi, We are facing a major issue with our application. We are using FolioReaderkit to read epub files. Currently, it's working on the iOS 18.1 device and simulator, but it's not working on the iOS 18.2 and later version devices. we are facing this error in Folioreaderkit

Hi! We are developing an authentication plugin for macOS that integrates with the system's authentication flow. The plugin is designed to prompt the user for approval via a push notification in our app before allowing access. The plugin is added as the first mechanism in the authenticate rule, followed by the default builtin:authenticate as a fallback. When the system requests authentication (e.g., during screen unlock), our plugin successfully displays the custom UI and sends a push notification to the user's device. However, I've encountered the following issue: If the user does not approve the push notification within ~30 seconds, the system resets the screen lock (expected behavior). If the user approves the push notification within approximately 30 seconds but doesn’t start entering their password before the timeout expires, the system still resets the screen lock before they can enter their password, effectively canceling the session. What I've Tried: Attempted to imitate mouse movement after the push button was clicked to keep the session active. Created a display sleep prevention assertion using IOKit to prevent the screen from turning off. Used the caffeinate command to keep the display and system awake. Tried setting the result as allow for the authorization request and passing an empty password to prevent the display from turning off. I also checked the system logs when this issue occurred and found the following messages: ___loginwindow: -[LWScreenLock (Private) askForPasswordSecAgent] | localUser = >timeout loginwindow: -[LWScreenLock handleUnlockResult:] _block_invoke | ERROR: Unexpected _lockRequestedBy of:7 sleeping screen loginwindow: SleepDisplay | enter powerd: Process (loginwindow) is requesting display idle___ These messages suggest that the loginwindow process encounters a timeout condition, followed by the display entering sleep mode. Despite my attempts to prevent this behavior, the screen lock still resets prematurely. Questions: Is there a documented (or undocumented) system timeout for the entire authentication flow during screen unlock that I cannot override? Are there any strategies for pausing or extending the authentication timeout to allow for complex authentication flows like push notifications? Any guidance or insights would be greatly appreciated. Thank you!

Is it possible using the network framework to retrieve the list of certificates presented by the host alone, and not the reconstructed chain assembled by the system? For example, in OpenSSL one can call SSL_get_peer_cert_chain which will return exactly this - a list of the certificates presented by the server. This is useful for when you may want to manually reconstruct the chain, or if the server is misconfigured (for example, is missing an intermediate cert). Is something like this possible with the network framework? If I connect to a host that I know only returns 1 certificate, the trust ref already has the reconstructed chain by the time my code is called: sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { metadata, trustRef, verifyComplete in let trust = sec_trust_copy_ref(trustRef).takeRetainedValue() let numberOfCertificates = SecTrustGetCertificateCount(trust) // Returns 3 even though the server only sent 1

I have developed a sample app following the example found Updating your app package installer to use the new Service Management API and referring this discussion on XPC Security. The app is working fine, I have used Swift NSXPCConnection in favour of xpc_connection_create_mach_service used in the example. (I am running app directly from Xcode) I am trying to set up security requirements for the client connection using setCodeSigningRequirement on the connection instance. But it fails for even basic requirement connection.setCodeSigningRequirement("anchor apple"). Error is as follows. cannot open file at line 46986 of [554764a6e7] os_unix.c:46986: (0) open(/private/var/db/DetachedSignatures) - Undefined error: 0 xpc_support_check_token: anchor apple error: Error Domain=NSOSStatusErrorDomain Code=-67050 "(null)" status: -67050 I have used codesign -d --verbose=4 /path/to/executable to check the attributes I do get them in the terminal. Other way round, I have tried XPC service provider sending back process id (pid) with each request, and I am probing this id to get attributes using this code which gives all the details. func inspectCodeSignature(ofPIDString pidString: String) { guard let pid = pid_t(pidString) else { print("Invalid PID string: \(pidString)") return } let attributes = [kSecGuestAttributePid: pid] as CFDictionary var codeRef: SecCode? let status = SecCodeCopyGuestWithAttributes(nil, attributes, [], &codeRef) guard status == errSecSuccess, let code = codeRef else { print("Failed to get SecCode for PID \(pid) (status: \(status))") return } var staticCode: SecStaticCode? let staticStatus = SecCodeCopyStaticCode(code, [], &staticCode) guard staticStatus == errSecSuccess, let staticCodeRef = staticCode else { print("Failed to get SecStaticCode (status: \(staticStatus))") return } var infoDict: CFDictionary? if SecCodeCopySigningInformation(staticCodeRef, SecCSFlags(rawValue: kSecCSSigningInformation), &infoDict) == errSecSuccess, let info = infoDict as? [String: Any] { print("🔍 Code Signing Info for PID \(pid):") print("• Identifier: \(info["identifier"] ?? "N/A")") print("• Team ID: \(info["teamid"] ?? "N/A")") if let entitlements = info["entitlements-dict"] as? [String: Any] { print("• Entitlements:") for (key, value) in entitlements { print(" - \(key): \(value)") } } } else { print("Failed to retrieve signing information.") } var requirement: SecRequirement? if SecRequirementCreateWithString("anchor apple" as CFString, [], &requirement) == errSecSuccess, let req = requirement { let result = SecStaticCodeCheckValidity(staticCodeRef, [], req) if result == errSecSuccess { print("Signature is trusted (anchor apple)") } else { print("Signature is NOT trusted by Apple (failed anchor check)") } } var infoDict1: CFDictionary? let signingStatus = SecCodeCopySigningInformation(staticCodeRef, SecCSFlags(rawValue: kSecCSSigningInformation), &infoDict1) guard signingStatus == errSecSuccess, let info = infoDict1 as? [String: Any] else { print("Failed to retrieve signing information.") return } print("🔍 Signing Info for PID \(pid):") for (key, value) in info.sorted(by: { $0.key < $1.key }) { print("• \(key): \(value)") } } If connection.setCodeSigningRequirement does not works I plan to use above logic as backup. Q: Please advise is there some setting required to be enabled or I have to sign code with some flags enabled. Note: My app is not running in a Sandbox or Hardened Runtime, which I want.

Hi, I am creating a custom login window, so I am using SFAuthorizationpluginView, here I want to hide Submit Arrow botton which gets displayed beside username and password text feild , is there a way to hide this, please suggest.

I am developing a sample authorization plugin to sync the user’s local password to the network password. During the process, I prompt the user to enter both their old and new passwords in custom plugin. After the user enters the information, I use the following code to sync the passwords: try record.changePassword(oldPssword, toPassword: newPassword) However, I have noticed that this is clearing all saved keychain information, such as web passwords and certificates. Is it expected behavior for record.changePassword to clear previously stored keychain data? If so, how can I overcome this issue and ensure the keychain information is preserved while syncing the password? Thank you for your help!

I have Authorisation Plugin which talks using XPC to my Launch Daemon to perform privileged actions. I want to protect my XPC service narrowing it to be called from known trusted clients. Now since I want authorisation plugin code which is from apple to call my service, I cannot use my own team id or app group here. I am currently banking on following properties of client connection. Apple Team ID : EQHXZ8M8AV Bundle ID starting with com.apple. Client signature verified By Apple. This is what I have come up with. func isClientTrusted(connection: NSXPCConnection) -> Bool { let clientPID = connection.processIdentifier logInfo("🔍 Checking XPC Client - PID: \(clientPID)") var secCode: SecCode? var secStaticCode: SecStaticCode? let attributes = [kSecGuestAttributePid: clientPID] as NSDictionary let status = SecCodeCopyGuestWithAttributes(nil, attributes, [], &secCode) guard status == errSecSuccess, let code = secCode else { logInfo("Failed to get SecCode for PID \(clientPID)") return false } let staticStatus = SecCodeCopyStaticCode(code, [], &secStaticCode) guard staticStatus == errSecSuccess, let staticCode = secStaticCode else { logInfo("Failed to get SecStaticCode") return false } var signingInfo: CFDictionary? let signingStatus = SecCodeCopySigningInformation(staticCode, SecCSFlags(rawValue: kSecCSSigningInformation), &signingInfo) guard signingStatus == errSecSuccess, let info = signingInfo as? [String: Any] else { logInfo("Failed to retrieve signing info") return false } // Extract and Verify Team ID if let teamID = info["teamid"] as? String { logInfo("XPC Client Team ID: \(teamID)") if teamID != "EQHXZ8M8AV" { // Apple's official Team ID logInfo("Client is NOT signed by Apple") return false } } else { logInfo("Failed to retrieve Team ID") return false } // Verify Bundle ID Starts with "com.apple." if let bundleID = info["identifier"] as? String { logInfo("XPC Client Bundle ID: \(bundleID)") if !bundleID.hasPrefix("com.apple.") { logInfo("Client is NOT an Apple system process") return false } } else { logInfo("Failed to retrieve Bundle Identifier") return false } // Verify Apple Code Signature Trust var trustRequirement: SecRequirement? let trustStatus = SecRequirementCreateWithString("anchor apple" as CFString, [], &trustRequirement) guard trustStatus == errSecSuccess, let trust = trustRequirement else { logInfo("Failed to create trust requirement") return false } let verifyStatus = SecStaticCodeCheckValidity(staticCode, [], trust) if verifyStatus != errSecSuccess { logInfo("Client's signature is NOT trusted by Apple") return false } logInfo("Client is fully verified as Apple-trusted") return true } Q: Just wanted community feedback, is this correct approach?

I am developing an Authorisation Plugin which talks to Launch daemons over XPC. Above is working neat, now I have to decide on how to get it installed on a machine. Installation requires. Plugin Installation Launch Daemon Installation Both require Moving binary and text (.plist) file into privileged system managed directory. Firing install/load commands as root (sudo). I have referred this post BSD Privilege Escalation on macOS, but I am still not clear how to approach this. Q: My requirement is: I can use .pkg builder and install via script, however I have some initialisation task that needs to be performed. User will enter some details talk to a remote server and get some keys, all goes well restarts the system and my authorisation plugin will welcome him and get him started. If I cannot perform initialisation I will have to do it post restart on login screen which I want to avoid if possible. I tried unconventional way of using AppleScript from a SwiftUI application to run privileged commands, I am fine if it prompts for admin credentials, but it did not work. I don't want that I do something and when approving it from Apple it gets rejected. Basically, how can I provide some GUI to do initialisation during installation or may be an app which helps in this. Q: Please also guide if I am doing elevated actions, how will it affect app distribution mechanism. In Read Me for EvenBetterAuthorizationSample I read it does. Thanks.