Reliability improvements for OpenSSL tpm2 provider on an embedded system #463
Conversation
|
One note related to the OpenSSL provider. At the moment we seem to use a global OpenSSL context using the OpenSSLProvider. I am not sure what side effects this could have. Would it be better to re-create the openssl context upon each connection? |
james-ctc
force-pushed
the
openssl1-openssl3-and-tpm2
branch
from
5837295 to
c112411
Compare
|
I understand, probably that's why the old problems could arise, since loading/unloading the DLL can cause issues it seems. If there are checks so that concurrency problems do not arise (I've noticed the mutex) and also that there is no mis-calling of the wrong function (using the TPM instead of the normal openssl) then it's fine on my side. |
fix: TPM & TLS working feat: support OpenSSL versions 1 and 3 feat: support libevse-security TPM2 updates Signed-off-by: James Chapman <[email protected]>
james-ctc
force-pushed
the
openssl1-openssl3-and-tpm2
branch
from
c112411 to
c709af2
Compare
Signed-off-by: James Chapman <[email protected]>
james-ctc
requested review from
Pietfried,
marcemmers and
maaikez
as code owners
james-ctc
requested review from
corneliusclaussen
and removed request for
AssemblyJohn
| "Connecting with security profile 3 but no client side certificate is present or valid")); | ||
| } | ||
|
|
||
| path_chain = std::string(certificate_key_pair.value().certificate_path.c_str()); |
There was a problem hiding this comment.
There is a possible error here. The get_key_pair can return 2 values for a valid certificate, one is certificate_path and another is 'certificate_single_path'. if the certificate_path there should be a fallback to the 'certificate_single_path'.
Example:
There was a problem hiding this comment.
I'll make the change.
However get_key_pair() could be updated so that this isn't required.
What if both certificate and certificate_single have values?
Is there a use case where certificate_single is needed on its own?
There was a problem hiding this comment.
Yes, there is a case with symlinks in the library. Because most of the times both will be present (chain & single) it is better to have this as both, and one can be empty. If both are non-null then the usage depends on the certificate setup.
Signed-off-by: James Chapman <[email protected]>
related to libevse-security PR42
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
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.
Changes
The code has been updated to use the new OpenSSL provider implementation in libevse-security. It provides a suitable implementation for: