parallaxsecond/parsec-se-driver

PSA Secure Element Driver implementation using Parsec

parsec-se-driver's Issues

Test cross-compilation

It should be possible to cross-compile the SE driver to another target via the --target flag. It should be tested on the CI.
A target to start with would be armv7-unknown-linux-gnueabihf.

Implement authenticator selection

After the work in parallaxsecond/parsec-client-rust#41 is done the SE driver can identify the authenticator supported by Parsec and use an appropriate identity mechanism.

Create an agnostic variant of the SE driver that automatically routes to the most suitable provider

Summary

This request is to create an SE driver layer that allows clients of PSA Crypto to use Parsec in a platform-agnostic fashion. The driver would choose the correct provider based on information obtained from the service. Client code would then not have any compile-time coupling with a particular Parsec provider type (such as TPM). A common client build would be usable with multiple Parsec back-end providers.

Background

To consume the Parsec service into C code, we are using the PSA Crypto API as the programming surface, and Mbed Crypto as the glue layer to the Parsec client library. Mbed Crypto uses secure element (SE) drivers as a way of routing crypto operations to the correct place. Clients register these drivers and then use key lifetime properties as a way of specifying the SE driver that should be used.

This repo holds SE drivers that can be used to route PSA Crypto operations to Parsec.

However, Parsec itself is an abstraction that can have multiple implementations depending on the platform. These implementations are known as providers. Parsec has different providers for different types of platform hardware such as TPM or HSM.

The model we've adopted for the SE driver so far is that there is a precise 1-1 mapping between an SE driver and a Parsec provider. So, if you want to use a TPM platform, then you would use the TPM SE driver, which in turn would select for the TPM Parsec provider.

This model is conceptually quite clean, but it does mean that the client code needs full awareness of the platform in order to register the correct SE driver and use the correct key lifetimes for it. This is a tight coupling that might not always be desirable. Parsec is intended to be a platform-agnostic API, so client application code shouldn't be required to have this level of awareness unless it wants to.

It should be possible for an SE driver to select the Parsec provider automatically based on its configured knowledge of the platform. Client code can then just use a generic "Parsec" key lifetime and everything else is automatic.

With this variant of the SE driver, adopters of Parsec can have common application code on any platform.

Details

• Existing SE drivers can remain as they are. There might be some cases where an explicit client-side selection is desirable.
• We would introduce a new SE driver structure and associated key lifetime (names TBD).
• The new SE driver would choose its Parsec provider by listing the available providers in the service. In many cases, there is only one kind of platform hardware available, so the list of crypto providers may be a list of only one entry anyway. However, this cannot be guaranteed, so we would need to consult a preferentially-ordered list. This could be done by calling the existing ListProviders opcode, and treating the list as a preferential order (with the core provider filtered out). Or we could introduce a whole new opcode to produce the list, which avoids retro-fitting any kind of ordering semantics to the existing opcode, but requires more effort.

Client Code

Client C code would be completely agnostic and have no compile-time tie to any particular platform. The same builds could be used on TPM and non-TPM platforms, for example. The way of using Parsec would simply be to specify Parsec as the key lifetime, and everything else would be automatic.

Investigate stability of the SE driver

Placeholder issue to investigate how to define stability for the SE driver and how to enforce it.

Update Mbed TLS to version 2.25.0

Mbed TLS should be updated & verified soonest against 2.25.0, as the currently used version 2.22.0 has a known CVE-2020-16150.

@hug-dev

Update to Parsec 0.5.0

Currently, this SE driver only works with Parsec 0.4.0. It needs to be updated to work with 0.5.0. The main thing to do would be to increase parsec-client version to 0.5.0.

Check on the CI that Parsec is actually called

If something went wrong with the SE driver registration, it is possible that Mbed Crypto is called for crypto operations instead of Parsec. We should check that Parsec is actually called.
This could be done via ./parsec-tool list-keys checking that the result is not empty.