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

Reliability improvements for OpenSSL tpm2 provider on an embedded system #42

Merged
merged 2 commits into from
Feb 15, 2024

Conversation

james-ctc
Copy link
Collaborator

Background

The existing implementation was occasionally failing especially when there was a migration from using non-TPM keys to supporting TPM protected keys (TSS2). Issues were observed during the loading and unloading of providers. There was also some concern that another call could impact which providers were loaded and their property strings.

There were significant improvements once the the tpm2-abrmd daemon was included and running. Generating keys, CSRs etc. didn't appear to need tpm2-abrmd however once TLS was being used tpm2-abrmd became essential.

It also became clear that the provider configuration depends on the key type. Hence the first line of the PEM key file is read so that the provider can be configured before actually loading the key.

Updates

feat: OpenSSL provider implementation now default for OpenSSL v3
feat: OpenSSL tpm2 provider load on first use, configured via property strings
feat: OpenSSL property strings configurable via cmake
feat: unit tests run for OpenSSL v1 and v3
feat: additional unit tests for tpm2 provider (OpenSSL v3 only)

provider handling changed following testing on an embedded system. Loading and unloading providers was proving unreliable. Approach changed to load providers early and use the property string to control which provider is used.

A mutex has been added so that another call can't change the provider configuration whilst in use.
There is support for general operations using the global OpenSSL library context and a separate context for use with TLS.

OpenSSL v3 uses providers. OpenSSL v1 uses previous code.

Note: the tpm2-abrmd daemon needs to be running for tpm2 where TLS is being used.

Functionality change

The meaning of UseTPM has been clarified to support interworking and upgrades from non-TPM keys to TPM protected keys.
For TLS the provider chosen is based on the PEM file and not the UseTPM OCPP configuration variable.
UseTPM is used to determine how a new key is to be generated and not how an existing key is used.
(part of this will be in a subsequent update to libocpp)

Configuration

cmake -DUSING_TPM2 to enable use of the tpm2 OpenSSL provider (disabled by default).
The propquery strings can be modified to suit the target e.g.

set(PROPQUERY_DEFAULT "provider=default")
set(PROPQUERY_TPM2 "?provider=tpm2")

The options configured in this PR were based on testing in a single environment so may need to be adapted for another system.

set(PROPQUERY_DEFAULT "provider!=tpm2")
set(PROPQUERY_TPM2 "?provider=tpm2,tpm2.digest!=yes,tpm2.cipher!=yes")

Copy link
Collaborator

@AssemblyJohn AssemblyJohn left a comment

Choose a reason for hiding this comment

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

The changes seem more solid than the old scoped provider, probably we should build upon this one and completely deprecate/remove the old one.

I would suggest a through test of the testcases on multiple platform and it has a go from my side.

feat: OpenSSL tpm2 provider load on first use, configured via
      property strings
feat: OpenSSL property strings configurable via cmake
feat: unit tests run for OpenSSL v1 and v3
feat: additional unit tests for tpm2 provider (OpenSSL v3 only)

provider handling changed following testing on an embedded system.
Loading and unloading providers was proving unreliable. Approach changed
to load providers early and use the property string to control
which provider is used.

A mutex has been added so that another call cann't change the
provider configuration whilst in use.

OpenSSL v3 uses providers. OpenSSL v1 uses previous code.

Note: the tpm2-abrmd daemon needs to be running for tpm2 where
      TLS is being used.

Signed-off-by: James Chapman <[email protected]>
@james-ctc james-ctc force-pushed the openssl1-openssl3-and-tpm2 branch from 53c67ba to 59d9f6f Compare February 14, 2024 16:17
Copy link
Collaborator

@AssemblyJohn AssemblyJohn left a comment

Choose a reason for hiding this comment

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

Looks good to me, however I do understand testing can be difficult when there is so much hardware involved. If all the tests/lint pass this PR has a go from me.

@james-ctc james-ctc force-pushed the openssl1-openssl3-and-tpm2 branch 2 times, most recently from 5063dcf to b95ee81 Compare February 15, 2024 13:40
Signed-off-by: James Chapman <[email protected]>
@james-ctc james-ctc force-pushed the openssl1-openssl3-and-tpm2 branch from b95ee81 to 42e2643 Compare February 15, 2024 13:44
@james-ctc james-ctc merged commit 7029d0c into main Feb 15, 2024
3 of 4 checks passed
@james-ctc james-ctc deleted the openssl1-openssl3-and-tpm2 branch February 15, 2024 13:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants