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

Cohabitation of secure element interfaces is poorly defined #3856

Open
gilles-peskine-arm opened this issue Nov 5, 2020 · 0 comments
Open
Labels
bug component-crypto Crypto primitives and low-level interfaces

Comments

@gilles-peskine-arm
Copy link
Contributor

There are currently two ways to define secure element drivers for PSA: the old-style dynamically registered way (enable MBEDTLS_PSA_CRYPTO_SE_C, register a driver with psa_register_se_driver(location, …)) and the new-style “unified driver interface” way (enable MBEDTLS_PSA_CRYPTO_DRIVERS, register a driver with {"type": "opaque", "location": …}).

We don't test what happens if both options are enabled. The behavior if a dynamically registered driver and a statically registered driver are registered for the same location is undefined.

We should define the behavior (presumably an error at dynamic registration time).

There should be a way to find out whether a location is in a statically registered driver, in a dynamically registered driver, or unassigned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug component-crypto Crypto primitives and low-level interfaces
Projects
None yet
Development

No branches or pull requests

3 participants