macOS Data Protection Keychain: supported non-exportable, signing-only software RSA3072 key?

Privacy & Security General
fapontec OP
Created
Replies 2
Boosts 0
Views 43
Participants 2

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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

Replies  2
Boosts 0
Views  43
Participants  2
Pokpong OP

I found documentation that helps narrow this down, but it does not seem to settle the DPK-specific conflict.

Apple documents kSecUseDataProtectionKeychain as the way to target the Data Protection Keychain on macOS. The key-generation API also accepts usage attributes in the private-key attributes dictionary, including kSecAttrCanSign, kSecAttrCanDecrypt and kSecAttrCanDerive. That gives you a documented way to request those settings at creation, but I could not find a documented non-export check that attests they are enforced for this exact software RSA DPK combination.

The documentation for SecKeyCopyExternalRepresentation says it fails on macOS when kSecKeyExtractable is false. However, Apple DTS has also said that raw bytes can be obtained from standard DPK keys with that API. I would not assume kSecKeyExtractable and kSecAttrIsExtractable are interchangeable, or treat the requested attributes or a missing value from SecKeyCopyAttributes as proof of enforcement without Apple confirming it for this key type and OS version.

The relevant references are key generation attributes, Data Protection Keychain and Apple's Mac keychain technote. Given the apparent mismatch, this looks like a good DTS question; I would ask them to reconcile those two statements and name a supported verification method without exporting the key.
fapontec OP

Thank you. This matches the unresolved distinction we are trying
to clarify: requesting key attributes is different from having
documented enforcement for software RSA keys in the Data Protection
Keychain.

Could Apple DTS confirm whether this exact combination is supported:
a persistent software RSA-3072 key in DPK, effective private-key
non-exportability, and signing-only use?

We would also appreciate clarification of the scope of
kSecKeyExtractable versus kSecAttrIsExtractable, and a supported
verification method that does not attempt private-key export.

If this combination is not supported for standard software DPK
keys, an explicit clarification would help us choose an appropriate
custody architecture rather than rely on unverified attributes.

We have not generated keys or performed export experiments.