Hello Apple Technical Support,
We need a documented feasibility clarification before implementing a native
macOS app running in the logged-in user's context. The app needs to generate
and persist a software RSA 3072-bit private key in the Data Protection
Keychain (DPK), for RS256 (RSASSA-PKCS1-v1_5 with SHA-256).
The required properties are effective private-key non-exportability and
signing-only use, enforced beyond our app's choice not to call export or
other cryptographic operations. We also need a supported way to verify
these properties without attempting any private-key export.
We distinguish these requirements from access-group authorization,
kSecAttrSynchronizable=false, ThisDeviceOnly accessibility, and hardware-bound
keys. We recognize that access groups are a different boundary from exact
CDHash/build exclusivity; we do not claim that exclusivity is satisfied.
Group membership alone does not establish the requested key properties,
including for another process legitimately entitled to the same group.
Environment: recorded static header provenance is MacOSX27.0.sdk (Command
Line Tools), not a successful build or runtime validation. Target macOS
version and build: Apple M4, 16GB in memory, macOS Tahoe version 26.6.2.
No DPK implementation or experiment is being submitted as evidence.
Please clarify these four points:
-
Is there an officially supported API/attribute combination to generate
and persist this software RSA3072 key in DPK with enforceable
non-exportability and signing-only use (no decrypt, unwrap or derive)?
If yes, please identify the exact APIs, attribute placement and values,
applicable macOS/SDK versions, and enforcement limits. Please distinguish
actual key restrictions from requested attributes or app-side policy. -
How does that combination, if supported, relate to the generic macOS
kSecKeyExtractable=false exception documented for
SecKeyCopyExternalRepresentation [1], versus the Apple DTS explanation
that raw bytes of standard DPK keys can be obtained through that API [2]?
Does the exception apply to software RSA keys generated in DPK, or only
to other key implementations? Please distinguish kSecKeyExtractable from
kSecAttrIsExtractable where relevant. -
Which supported attributes, query APIs or other evidence establish
effective non-exportability and signing-only restrictions without
attempting export? Please specify whether SecKeyCopyAttributes or an
item query guarantees the required fields for this key/store combination,
and how absent or unsupported fields must be interpreted. We will not
treat a missing field as false or infer enforcement from creation inputs. -
If this combination is not supported for software RSA in DPK, please
confirm that limitation explicitly and distinguish it from hardware-bound
keys. We are not asking to substitute Secure Enclave/EC or another
algorithm, and do not assume hardware guarantees apply to software RSA.
References:
[1] SecKeyCopyExternalRepresentation
https://developer.apple.com/documentation/security/seckeycopyexternalrepresentation(::)
[2] Apple DTS reply (June 2023), Developer Forums thread 731001
https://developer.apple.com/forums/thread/731001
[3] TN3137: On Mac keychain APIs and implementations
https://developer.apple.com/documentation/technotes/tn3137-on-mac-keychains
[4] Protecting keys with the Secure Enclave
https://developer.apple.com/documentation/security/protecting-keys-with-the-secure-enclave
An applicable technical answer with references and limits, or an explicit
statement that this combination is unsupported, would resolve the feasibility
question. If support or a non-exporting verification method cannot be
established, we will keep support NOT_ESTABLISHED and implementation blocked.
A successful signature or access-group isolation alone would not close it.
Thank you.
fapontec
The answer here is going to depend on exactly what you mean by export:
- If you want to guarantee that the key bits never show up in your process, and thus it’s impossible for your app to accidentally export them, then there’s no way to achieve this goal [1]. The only way to meet that exportability constraint is with an SE-protected key, and the SE has no RSA support.
- If you’re OK with the key bits being present in your process then you can use a standard data protection keychain item. If you use your App ID as its keychain access group, which is the default, then only your app can access it (because using a keychain access group is authorised by your provisioning profile and your App ID is registered to your team).
Of course, that second point assumes that SIP is enable. If SIP is disabled then all bets are off because some other process can reach into your address space and grab the key bits from there.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Well, without jumping through significant hoops. You could add a hardware token that supports RSA. Or you could create a CTK appex that exposes a virtual token that supports RSA. Of course, with the latter the key bits must necessarily show up in your CTK appex’s process, so that’s just shuffling the deckchairs.
