Add support for the Data Protection Keychain #793
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit allows to store certificates from the Data Protection Keychain, This functionality only works on code-signed applications. This commit also includes a fix that allows to retrieve a key from the data protection key chain depending on the uri parameters.
hslatman
reviewed
Jun 18, 2025
kms/mackms/mackms.go
Outdated
Comment on lines
1082
to
1087
| // Apple recommends to set KSecUseDataProtectionKeychain parameters always | ||
| // to true for all keychains operations. This option requires to use a | ||
| // code-signed application. | ||
| if u.useDataProtectionKeychain { | ||
| dict[security.KSecUseDataProtectionKeychain] = cf.True | ||
| // The data in the keychain item cannot be accessed after a restart |
There was a problem hiding this comment.
Is it possible to detect the required entitlements are available in the program? If so, when the intention is to use the data protection keychain, and the application isn't codesigned / missing entitlements, can it return an error indicating that case? This may not be necessary if errors from the OS are clear enough, but I've seen enough OSError codes that weren't overly clear 😅
There was a problem hiding this comment.
Apparently it should be possible to know this using SecCodeCheckValidity . We can add this in a different PR.
The current behavior is:
- When loading a certificate you will get a not found error. Something like:
mackms LoadCertificate failed: not found
- When storing a certificate you will get an error showing that an entitlement is missing:
mackms StoreCertificateChain failed: OSStatus -34018: A required entitlement isn't present.
Co-authored-by: Herman Slatman <hslatman@users.noreply.github.com>
joshdrake
previously approved these changes
Jun 18, 2025
joshdrake
approved these changes
Jun 20, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR adds support for storing certificates in the Data Protection Keychain. This functionality is only available for code-signed applications.
Additionally, this commit includes a fix that enables retrieving a key from the Data Protection Keychain or not based on URI parameters.
This last fix slightly changes the behavior: previously, keys stored in the Secure Enclave could be retrieved without specifying
se=true, but it was not possible to retrieve the proper key if a key in the Secure Enclave shares the same label as a key in the login keychain.