-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Persist keypair used by example opcert signer #6821
Persist keypair used by example opcert signer #6821
Conversation
{ | ||
// Storage doesn't have an existing keypair. Let's create one and add it to the storage. | ||
ReturnErrorOnFailure(mIssuer.Initialize()); | ||
ReturnErrorOnFailure(mIssuer.Serialize(serializedKey)); |
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.
This is storing a private key outside of secure storage, where it may leak and be exfiltrated.
Key storage should use different APIs than regular storage, so that crypto-accelerated or trustzone target can rely on their secure storage of the private part of the key pair.
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.
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.
These are only used for test tools. The intent is not use it for any product release. That's why it's named ExampleOperationalCredentialsIssuer.cpp
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.
Yes, I understand it's example code. I just see other usages elsewhere of how P-256 keys are used that make assumptions about serialization that are incompatible with iOS/Mac Secure Enclave, Android Keystore, ARM TrustZone in Cortex-M33, etc
I think it's OK in the short term, but it absolutely violates some of the Threat Model security requirements which are explicit in the spec, so I'm pointing it out early to make sure it doesn't "spread" too much.
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.
Agree with @tcarmelveilleux , I'm curious if we can either put this in a place that it's clear it's an example (directory), or make it only optionally compile in somehow?
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.
I added a warning and a file note to alert the users of the API about the storage of encryption keys.
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.
Approving since this is test code. Provided suggestions for more deterministically/safely handling the storage requirements.
a2a87ef
to
1fed564
Compare
Problem
The tools that are using example operational certificate signer should persist their signing key, so that on reruns same credentials are used for CASE session establishment.
Summary of Changes
Updated
ExampleOperationalCredentialsIssuer
class to take a reference to storage delegate. OnInit
, it'll lookup the storage for an existing keypair. If not found, it'll create one and persist it for the next run.Updated users of
ExampleOperationalCredentialsIssuer
to provide their storage delegates.