-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[macOS] Specify kSecUseDataProtectionKeychain when generating RSA/ECC keys #52759
Conversation
Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @GrabYourPitchforks Issue DetailsFixes #36107.
|
Did you actually see improvements in benchmarks? I'm a bit behind in responding to issues, but I did give this a shot and I did not see an improvement in performance. |
I'll re-run the benchmarks to make double sure that it takes the right code path. |
BenchmarkDotNet=v0.12.1.20210514-develop, OS=macOS Big Sur 11.3 (20E232) [Darwin 20.4.0]
(ignore the "allocated" column; the branch is few commits apart from the |
Woohoo. |
Looks like the tests fail on all the recent PRs, so the failures are unrelated. |
src/libraries/Native/Unix/System.Security.Cryptography.Native.Apple/pal_ecc.c
Show resolved
Hide resolved
@@ -24,6 +24,10 @@ int32_t AppleCryptoNative_EccGenerateKey(int32_t keySizeBits, | |||
{ | |||
CFDictionaryAddValue(attributes, kSecAttrKeyType, kSecAttrKeyTypeEC); | |||
CFDictionaryAddValue(attributes, kSecAttrKeySizeInBits, cfKeySizeValue); | |||
if (__builtin_available(macOS 10.15, iOS 13, tvOS 13, *)) | |||
{ | |||
CFDictionaryAddValue(attributes, kSecUseDataProtectionKeychain, kCFBooleanTrue); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Apple docs for this are... lacking. What's the effect? Does this let us get rid of the temporary keychains, and therefore make ephemeral load work?
If someone does PersistKeySet (where we load it into the default keychain for them) does this do anything weird?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The temporary keychains were already removed here in previous PR (#51620) that unified the key generation between iOS and macOS. However, by default macOS still generates ephemeral legacy CSSM keys that could be imported into (legacy) keychains. This attribute causes the code to create the iOS-style data keys instead. They don't interoperate with the legacy keychain SecItem* APIs well but that's never directly used in .NET (X509Certificate2.CopyWithPrivateKey will go through export and re-import using old APIs).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that the attribute existed in earlier macOS versions under the name kSecAttrNoLegacy
which was more fitting (but private API).
RSA key generation benchmarkBenchmarkDotNet=v0.12.1.20210515-develop, OS=macOS Big Sur 11.3 (20E232) [Darwin 20.4.0]
|
While many PRs are failing on building MacCatalyst and iOSSimulator, I can't bring myself to accept a merge here with that being true, since I can't convince myself that the __builtin_available / kSecUseDataProtectionKeychain aren't related. |
The problem with MacCatalyst / iOSSimulator should be fixed in |
/azp run runtime-staging |
Apparently the build was still picking the broken Mono :-/ I expected it to build the PR merge commit and not the PR tip commit. I rebased it, so let's try again... |
@bartonjs Can you give this another review? |
Fixes #36107.
Ref: #36107 (comment)