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.

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?

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

I have an application which is based on a video streaming service. A critical thing about this app is that these videos must be secured all the way and can't be pirated. The current problem I have is that anyone can use voice recorder to capture my videos audio which isn't suitable this app purpose. My question is Is there anyway that I can disable using any voice recording apps (or the microphone) and detect if someone tried to while streaming videos from my app? Thanks in advance

Hi, We are developing react native app, and we are having issue with ATS policy in production build distributed to TestFlight internal testing, requests to https are being killed. The preview build ad-hoc distribution is working fine. (I am testing the app on physical device) I will described what I've tried and supply you with logs from different tools. I tried to disable ATS - requests are working enable ATS (no change to default config) - requests are failing with following error Task <55618987-64A8-4C04-9B00-2EFF074D796C>.<1> finished with error [-1022] Error Domain=NSURLErrorDomain Code=-1022 "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection." UserInfo={NSLocalizedDescription=The resource could not be loaded because the App Transport Security policy requires the use of a secure connection., NSErrorFailingURLStringKey=<private>, NSErrorFailingURLKey=<private>, _NSURLErrorRelatedURLSessionTaskErrorKey=<private>, _NSURLErrorFailingURLSessionTaskErrorKey=<private>, NSUnderlyingError=0x30127bb10 {Error Domain=kCFErrorDomainCFNetwork Code=-1022}} I tried to check server if it had met ATS requirements and ran ats-diagnostic ./TLSTool s_client -connect api.rankacy.com:443 * input stream did open * output stream did open * output stream has space * protocol: TLS 1.2 * cipher: ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 * trust result: unspecified * certificate info: * 0 + ecPublicKey 256 ecdsa-with-SHA384 'api.rankacy.com' * 1 + ecPublicKey 384 sha256-with-rsa-signature 'E6' * 2 + rsaEncryption 4096 sha256-with-rsa-signature 'ISRG Root X1' nscurl https://api.rankacy.com/ --verbose --ats-diagnostics Starting ATS Diagnostics Configuring ATS Info.plist keys and displaying the result of HTTPS loads to https://api.rankacy.com/. A test will "PASS" if URLSession:task:didCompleteWithError: returns a nil error. ================================================================================ Default ATS Secure Connection --- ATS Default Connection ATS Dictionary: { } Result : PASS --- ================================================================================ Allowing Arbitrary Loads --- Allow All Loads ATS Dictionary: { NSAllowsArbitraryLoads = true; } Result : PASS --- ================================================================================ Configuring TLS exceptions for api.rankacy.com --- TLSv1.3 ATS Dictionary: { NSExceptionDomains = { "api.rankacy.com" = { NSExceptionMinimumTLSVersion = "TLSv1.3"; }; }; } Result : PASS --- --- TLSv1.2 ATS Dictionary: { NSExceptionDomains = { "api.rankacy.com" = { NSExceptionMinimumTLSVersion = "TLSv1.2"; }; }; } Result : PASS --- --- TLSv1.1 ATS Dictionary: { NSExceptionDomains = { "api.rankacy.com" = { NSExceptionMinimumTLSVersion = "TLSv1.1"; }; }; } Result : PASS --- --- TLSv1.0 ATS Dictionary: { NSExceptionDomains = { "api.rankacy.com" = { NSExceptionMinimumTLSVersion = "TLSv1.0"; }; }; } Result : PASS --- ================================================================================ Configuring PFS exceptions for api.rankacy.com --- Disabling Perfect Forward Secrecy ATS Dictionary: { NSExceptionDomains = { "api.rankacy.com" = { NSExceptionRequiresForwardSecrecy = false; }; }; } Result : PASS --- ================================================================================ Configuring PFS exceptions and allowing insecure HTTP for api.rankacy.com --- Disabling Perfect Forward Secrecy and Allowing Insecure HTTP ATS Dictionary: { NSExceptionDomains = { "api.rankacy.com" = { NSExceptionAllowsInsecureHTTPLoads = true; NSExceptionRequiresForwardSecrecy = false; }; }; } Result : PASS --- ================================================================================ Configuring TLS exceptions with PFS disabled for api.rankacy.com --- TLSv1.3 with PFS disabled ATS Dictionary: { NSExceptionDomains = { "api.rankacy.com" = { NSExceptionMinimumTLSVersion = "TLSv1.3"; NSExceptionRequiresForwardSecrecy = false; }; }; } Result : PASS --- --- TLSv1.2 with PFS disabled ATS Dictionary: { NSExceptionDomains = { "api.rankacy.com" = { NSExceptionMinimumTLSVersion = "TLSv1.2"; NSExceptionRequiresForwardSecrecy = false; }; }; } Result : PASS --- --- TLSv1.1 with PFS disabled ATS Dictionary: { NSExceptionDomains = { "api.rankacy.com" = { NSExceptionMinimumTLSVersion = "TLSv1.1"; NSExceptionRequiresForwardSecrecy = false; }; }; } Result : PASS --- --- TLSv1.0 with PFS disabled ATS Dictionary: { NSExceptionDomains = { "api.rankacy.com" = { NSExceptionMinimumTLSVersion = "TLSv1.0"; NSExceptionRequiresForwardSecrecy = false; }; }; } Result : PASS --- ================================================================================ Configuring TLS exceptions with PFS disabled and insecure HTTP allowed for api.rankacy.com --- TLSv1.3 with PFS disabled and insecure HTTP allowed ATS Dictionary: { NSExceptionDomains = { "api.rankacy.com" = { NSExceptionAllowsInsecureHTTPLoads = true; NSExceptionMinimumTLSVersion = "TLSv1.3"; NSExceptionRequiresForwardSecrecy = false; }; }; } Result : PASS --- --- TLSv1.2 with PFS disabled and insecure HTTP allowed ATS Dictionary: { NSExceptionDomains = { "api.rankacy.com" = { NSExceptionAllowsInsecureHTTPLoads = true; NSExceptionMinimumTLSVersion = "TLSv1.2"; NSExceptionRequiresForwardSecrecy = false; }; }; } Result : PASS --- --- TLSv1.1 with PFS disabled and insecure HTTP allowed ATS Dictionary: { NSExceptionDomains = { "api.rankacy.com" = { NSExceptionAllowsInsecureHTTPLoads = true; NSExceptionMinimumTLSVersion = "TLSv1.1"; NSExceptionRequiresForwardSecrecy = false; }; }; } Result : PASS --- --- TLSv1.0 with PFS disabled and insecure HTTP allowed ATS Dictionary: { NSExceptionDomains = { "api.rankacy.com" = { NSExceptionAllowsInsecureHTTPLoads = true; NSExceptionMinimumTLSVersion = "TLSv1.0"; NSExceptionRequiresForwardSecrecy = false; }; }; } Result : PASS --- I am running out of ideas. Also it's hard to test because the preview ad-hoc build is working fine. So only after submitting the app to TestFlight I am having this issue Looking for your response Martin

We develop an SDK that requires sharing a device-specific identifier with our web API, in order to guarantee that certain artifacts are only used on the correct device. For the device-specific identifier, we use UIDevice.currentDevice.identifierForVendor which should not be restricted under ATT. In production, many developers are getting back to us with complaints of web requests being blocked: nw_endpoint_handler_path_change [C1 [our url]:443 waiting parent-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] blocked tracker Connection 1: received failure notification Connection 1: failed to connect 1:50, reason -1 Connection 1: encountered error(1:50) Task <FA03088C-DDFC-437E-A06F-E05CC930E3E0>.<1> HTTP load failed, 0/0 bytes (error code: -1009 [1:50]) Task <FA03088C-DDFC-437E-A06F-E05CC930E3E0>.<1> finished with error [-1009] Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_kCFStreamErrorCodeKey=50, NSUnderlyingError=0x3031118f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)" UserInfo={_NSURLErrorBlockedTrackerFailureKey=true, _kCFStreamErrorDomainKey=1, _kCFStreamErrorCodeKey=50, _NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <FA03088C-DDFC-437E-A06F-E05CC930E3E0>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <FA03088C-DDFC-437E-A06F-E05CC930E3E0>.<1>" ), NSLocalizedDescription=The Internet connection appears to be offline., NSErrorFailingURLStringKey=..., NSErrorFailingURLKey=..., _kCFStreamErrorDomainKey=1} Interestingly, I've made a few observations: The blacklist seems to be persistent, across devices. The blacklist stays in place regardless of whether we send no identifiable data in the web request (in fact, an empty ping request to our URL still gets blocked) The only way to get past the block is to use ATT, and request from the user that we track them across websites. This is false, because we don't track any user data whatsoever; and iOS disables ATT by default (in the settings app, users have to opt-in). Our iOS SDK already has an xcprivacy manifest mentioning the fact that we use a device-specific identifier, and that we send it to our web API URL. Still, we get blocked. How can we fix this? We can standup a proxy URL but I'd imagine it's only a matter of time before that also gets blocked. Apple has not provided any guidance on the specifics of how domains get blocked, and how they can be unblocked.

We are implementing just-in-time account creation using Platform Single Sign-on. After creating the account, we are registering the user with PSSO and we want to ensure that the IDP account used for account creation matches the IDP account used in the user registration flow. An easy way to do this appears to be using loginUsername on the ASAuthorizationProviderExtensionLoginManager object. loginUsername gets set during account creation and then we can check what the user is entering during registration. The documentation, however, marks this attribute as deprecated. There is no indication of what could be used instead. Is there some other value we could look at? Does Apple have a plan to introduce a preferred API option? Thanks!

Hello, The man page for xpcservices.plist states that: Services embedded in an application bundle will only be visible to the containing application (...) What exactly "visible" means? Doest that mean that there is a mechanism to prevent other programs than the embedding application to access the XPCService's mach port or it just means that the XPCService is not listed (e.g. launchctl list) and if attacker can guess the mach port they can access it? I'm asking to understand if there is a security gain using the -[NSXPCConnection setCodeSigningRequirement:] for embedded XPCServices.

Is the method used to unlock an iOS device available to an app? We would like to require a step-up to MFA (in our app) if passcode was used and allow for single factor if Face ID was used.

Hi, It may be a stupid question, but we really wonder if there is a way for MDM to push a unique mTLS cert to our iOS application or if it can populate a client certificate in the iOS where our application can access it. Like browser app, how do browser mTLS certs get pushed? Thanks, Ying

Hi, I just watched session "10203" on "Meet AccessorySetupKit". In 09:13, it was mentioned that there is special UI for entering PIN codes / passphrases. How exactly is this UI triggered? And is there any UI for setting a pin during initial setup? I couldn't find any further information about any of this in the documentation. Best, Klemens

I'm a new developer who is looking to make my first app easier to manage on my end by staying in the Apple ecosystem. My ideal backend is just pure and simple CloudKit. This should help me cut down on costs and increase my security, or so I thought. The more I looked into the issue of mobile app security --more specifically, preventing fraudulent access to backend APIs-- the more it seems like CloudKit is a disaster waiting to happen. While data in transit is encrypted and there's even end-to-end encryption for private DBs, securing an app's public DB in the presence of modified apps is a daunting, if not impossible task. My assumption is that a modified app cannot be trusted to make honest assertions about itself, the device, or its iCloud account, and can potentially lie its way into restricted areas of the DB. If an app is compromised, CloudKit queries from that app can be used to make malicious queries or even changes to the databases. I'm hoping App Attest, even with its potentially circular logic, can at least make life harder for fraudsters, competitors, and vandals (when combined with other security measures like jailbreak, debugging, hooking, and tampering detections), but I have not found a single mention on how App Attest might be used to protect CloudKit. There doesn't even seem to be a verified way for me to build a third party server that can handle App Attest and then tell CloudKit to allow a user through (with all the security hazards a new developer faces when configuring an authentication server). The message seems to be: App Attest is important, but you can't use it with CloudKit, so build your own server. Questions Is my assumption that a compromised app can make malicious queries or changes to an app's CloudKit DB correct? Can App Attest be made to protect a CloudKit public DB, with or without the involvement of a third-party server to handle attestations?

I'm a new app developer and I've read through most relevant posts on this topic here and elsewhere. Many of the forum posts here are specific to Objective-C, or old enough to be considered outdated in the fast-moving world of computing. Many of the posts elsewhere are about protecting authentication secrets, which doesn't apply in my case, and a lot are by someone with a product to sell, which I've ignored. My app is 99.9% Swift and I'm not going to store any authentication secrets in the IPA. What I'd like to protect is the core mechanism of my product, which has to be included in the binary and is small (&lt; 10k lines). I want to make it so it's harder to steal the source code than it is to recreate my functionality from scratch, which is difficult even with the app in front of them. From what I gathered, Swift code compiled by Xcode is protected from reverse engineering / decompilation by the following: Symbolization of the app Native builds from Xcode destroys names of variable, functions, etc. Swift code is compiled in such a way that makes stealing harder than Objective-C This should make me feel better, but the threat-level is increasing with the availability of free, commercial-grade decompilers (e.g. Ghidra) and machine learning. The fact that iOS 18 supports a checkm8 (i.e. jailbreakable) device means that decrypting the IPA from memory is still trivial. Questions People talk about stealing authentication secrets via reverse-engineering, but is the same true for mechanisms (i.e. code)? How common is the issue of source-code stealing in iOS apps? Can machine learning be leveraged to make decompilation/reverse engineering easier? Will I get rejected by App Review for obfuscating a small portion of my code?

Private Access Tokens (PATs) are headlined as something that can eliminate CAPTCHAs, but also includes app-to-server communications in its use cases. Because of this, they seem to perform a very similar function to DeviceCheck, since both aim to attest to the health of the device in question. I don't really understand the difference between the two and find this confusing. Since PATs are newer and more general, I'm more inclined to adopt them, but where does this leave DeviceCheck? Is it redundant? How does App Attest fit into all of this? If my goal is to minimize if not eliminiate fraudulent/malicious use of my app's APIs, should I use Private Access Tokens, DeviceCheck, and App Attest simultaneously to maximize my protection? If not, what is accepted to be the best practice? I admire Apple's dedication to privacy and security, but as a new developer I feel Apple could make it easier for their app developers to find out and implement the latest best practices.

A call to the API SecKeyGeneratePair in SecureEnclave for iOS18 returns an OSStatus 0 but the SecKeyRef is not present. Understand that this API is currently deprecated and there are plans to move to the new APIs, but I believe this API should still work in iOS18 as expected for now. The API works as expected on iPadOS 18. // Create SE key let sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault, kSecAttrAccessibleAfterFirstUnlock, .privateKeyUsage, nil)! let privKeyAttr = [ kSecAttrAccessControl: sacRef, kSecAttrIsPermanent: true, ] as NSDictionary os_log("Priv key params: %{public}@", log: osLogger, privKeyAttr) let keygenAttr = [ kSecAttrApplicationLabel: attrApplicationLabelSeKey, kSecAttrTokenID: kSecAttrTokenIDSecureEnclave, kSecPrivateKeyAttrs: privKeyAttr, kSecAttrKeyType: kSecAttrKeyTypeEC, kSecAttrKeySizeInBits: 256 ] as NSDictionary var error: Unmanaged<CFError>? os_log("keygen params: %{public}@", log: osLogger, keygenAttr) var keyRef: SecKey? let status = SecKeyGeneratePair(keygenAttr, &keyRef, nil) os_log("SecKeyGeneratePair osStatus: %{public}d, keyRef: %{public}@", log: osLogger, status, keyRef == nil ? "null" : "ref present")

I have a unique need here and hope there is someone out there that might be of help. There is a backend server that will send an x509 certificate and private key (as strings) after the mobile apps on-boarding process. Additionally, the app includes an AWS SDK that is used to talk to their IoT system. This SDK requires PKCS12 certificate format to pass authentication. (I believe the common method is to have bundled the cert into the app which is not an option for me here sadly) I suspect it may be possible to use some openSSL iOS framework to do this conversion at runtime but have not personally tried it yet as my go-to is usually trying things first with Apples APIs. So my question becomes is there a way to meet this requirement using any of the security APIs or other APIs that apple has like swift-nio-ssl? Thank you very much for your time. Best, Michael

The release notes state the following: To protect users’ privacy, app group containers (in ~/Library/Group Containers) are now protected by System Integrity Protection. This is similar to the protection added to app data containers in macOS Sonoma. An app that’s properly entitled for an app group continues to have access to the app group container. Specifically, the app must use FileManager to get the app group container path and meet one of the following requirements: the app is deployed through Mac App Store; the app group identifier is prefixed with the app’s Team ID; or the app group identifier is authorised by a provisioning profile embedded within the app. If the app doesn’t meet these requirements, the system might present the user a prompt to authorize the app’s use of the app group container. If granted, that consent applies only for the duration of that app instance. This restriction also applies to app extensions, although in that case the system won’t prompt the user for consent but will instead just deny the access. (114586798) We have a helper app which is not sandboxed (due to it requiring Accessibility access/permissions) that accesses our group container. I've tested our helper app with the current beta of macOS Sequoia 15 (24A5264n) and it still works correctly, however I'm not clear if these restrictions are actually enforced in the current beta. I've tried testing for this by accessing the group container via Terminal (with Full Disk Access disabled for Terminal), but did not get any alert mentioned in the notes (or been otherwise restricted). Are these restrictions currently enforced?

Hi, My application ships a copy of following cryptographic libraries: libp11-kit.0.dylib libnettle.8.dylib libgnutls.30.dylib It's purpose is to connect by secured HTTP to an optional server, that might be turned on to allow to receive HTTP requests. I think this is standard encryption, but do I need to mention this explicitely with App Uses Non-Exempt Encryption? The application doesn't encrypt content it is just for secured HTTP connections. regards, Joël

By calling the deactivationRequest from the main app bundle, we see Privacy & Security prompts for TouchID to deactivate the System Extension. We want to know if there's way to avoid that prompt. And also need know why the prompt pops up to deactivate our own app's System Extension component. We even tried to call the deactivate request from Daemon which contain the root access. We still see the prompt. https://developer.apple.com/documentation/systemextensions/ossystemextensionrequest/deactivationrequest(forextensionwithidentifier:queue:)

I'm using a file descriptor to write into a file. I've encountered a problem where if the underlying file is removed or recreated, the file descriptor becomes unstable. I have no reliable way to confirm if it's writing on the expected file. let url = URL(fileURLWithPath: "/path/") try FileManager.default.removeItem(at: url) FileManager.default.createFile(atPath: url.path, contents: .empty) let filePath = FilePath(url.path) var fileDescriptor = try FileDescriptor.open(filePath, .readWrite) // The file is recreated - may be done from a different process. try FileManager.default.removeItem(at: url) // L9 FileManager.default.createFile(atPath: url.path, contents: .empty) // L10 let dataToWrite = Data([1,1,1,1]) try fileDescriptor.writeAll(dataToWrite) // L13 let dataWritten = try Data(contentsOf: url) print(dataToWrite == dataWritten) // false I would expect L13 to result in an error. Given it doesn't: Is there a way to determine where fileDescriptor is writing? Is there a way to ensure that fileDescriptor is writing the content in the expected filePath?