Skip to content
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

Merged
merged 2 commits into from
May 14, 2021

Conversation

pan-apple
Copy link
Contributor

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. On Init, 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.

{
// Storage doesn't have an existing keypair. Let's create one and add it to the storage.
ReturnErrorOnFailure(mIssuer.Initialize());
ReturnErrorOnFailure(mIssuer.Serialize(serializedKey));
Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@tcarmelveilleux tcarmelveilleux left a 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.

@pan-apple pan-apple force-pushed the persist-example-ca-keypair branch from a2a87ef to 1fed564 Compare May 14, 2021 23:01
@pan-apple pan-apple requested a review from woody-apple May 14, 2021 23:02
@woody-apple woody-apple merged commit d7c56ff into project-chip:master May 14, 2021
@pan-apple pan-apple deleted the persist-example-ca-keypair branch May 14, 2021 23:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants