-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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] Implement RSA, ECC through new macOS 10.12 APIs #51620
Conversation
…ta and bypass keychains
Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @GrabYourPitchforks Issue Details…ta and bypass keychains NOT READY FOR REVIEW
|
Related to #38101 which I will likely try to revive at some point in some form. |
…s truly ephemeral keys
Maybe thing's have gotten better since I last tried in macOS world (or maybe I did a bunch of things wrong 😄 ) but the problem with "data" keys as I call them is they don't seem to work fully in place of keychain-backed keys. e.g. Oddly, if my recollection serves, ECDSA was more problematic than RSA. |
I fully expect that to be a problem, just scratching the unit test surface now to decide on a strategy. On iOS the keychain-backed APIs just don't exist so even if this works on a limited API surface it's still better than nothing. |
I expect, given @vcsjones' previous investigation, that instead of editing the current APIs what'll be needed is parallel API for RSA macOS and RSA iOS. |
There's still a lot of code that can be shared. For example, this PR passed the macOS tests with new APIs introduced in macOS 10.12 that exist on iOS too. I'm not necessarily saying the same approach will work everywhere but at least part of the code seems sharable. Locally the same change for key generation works for ECC too. I expect the key imports to be somewhat more problematic but let's see. Worst case I will have to split the implementations. |
Huh. I saw they were still in progress, hadn't noticed that the OSX legs had already finished. Since I'm surprised by this (vaguely recalling the issues that @vcsjones ran into), I'll trigger an OuterLoop run to see if it's only some more complex tests that fail. |
/azp run runtime-libraries-coreclr outerloop osx |
No pipelines are associated with this pull request. |
/azp run runtime-libraries-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
It's not that surprising that this part worked. It's still creating the old-style keys (as opposed to the iOS / data keys). The difference is that https://github.com/Apple-FOSS-Mirror/Security/blob/5bcad85836c8bbb383f660aaf25b555a805a48e4/OSX/libsecurity_keychain/lib/SecKey.cpp#L1667 |
The outerloop tests on CI have timed out. I tried to run them locally with UPD: |
/cc @MaximLipnin |
It contributes to #51098 but doesn't quite solve it. I have another PR in the pipeline to enable import of ephemeral RSA keys using the iOS-compatible APIs. Note that I am focusing now on the part that can be shared with macOS to simplify testing. Some of the APIs have slightly different semantics on iOS which may need specific tweaks but this should lay down the groundwork to make that happen. |
I was playing with it today and it's a mixed bag situation. First of all, the Second, it does seem to work for RSA keys even with the item export. On ECC though it hits the problematic code paths in the native code which explain the issues you've hit. I'll submit a PR later to convert the RSA code paths to use it. |
I got the ECC somewhat working locally without duplicating the keys. The trick is to understand what is going on. All the RSA/ECC keys work with the new Private ECC keys created with Private ECC keys created with Public ECC keys created with either I've come up with a code that converts most of the imports from I'll run the benchmarks from earlier Kevin's PR to see whether there is even significant benefit in using the |
/azp run runtime-libraries-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
src/libraries/Native/Unix/System.Security.Cryptography.Native.Apple/pal_ecc.c
Show resolved
Hide resolved
The failed test on the outer loop is likely unrelated:
|
SafeSecKeyRefHandle keychainPublic; | ||
SafeSecKeyRefHandle keychainPrivate; |
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.
Since these are not keychains (or even bound to them) the variables could probably use a better name.
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.
Good catch. I will fix it up in a follow up PR.
Since the variable renames are the only thing I saw, and CI takes a long time, I wouldn't bother with them. Thanks for spearheading this, @filipnavara! |
The new APIs are also available on iOS so the conditional blocks around the reimplemented APIs are removed. The implementation is not tested on iOS and may require some tweaks but it compiles at least.