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

Add a validate_key entry point to the PSA driver interface #3617

Closed
gilles-peskine-arm opened this issue Aug 27, 2020 · 1 comment · Fixed by #3695
Closed

Add a validate_key entry point to the PSA driver interface #3617

gilles-peskine-arm opened this issue Aug 27, 2020 · 1 comment · Fixed by #3695
Assignees
Labels
component-crypto Crypto primitives and low-level interfaces

Comments

@gilles-peskine-arm
Copy link
Contributor

According to the PSA driver interface,

Transparent drivers are not involved when importing, exporting, copying or destroying keys

However, for some types of keys (mostly asymmetric keys), it's important that some validation is done before attempting operations. For example, a bad key might cause an infinite loop or a division by zero. More subtly, certain operations with ECC keys are functionally robust, but leak private information when used with invalid keys (see e.g. Validation of Elliptic Curve Public Keys, Why do public keys need to be validated?).

It's important to make sure that the key is validated before use. And it should be feasible to enforce this in compliance testing. With the current interface, transparent drivers need to validate the key before each use, which is error-prone and wasteful.

The core can do the validation itself, but @stevew817 noted in #3492 that this is not satisfactory because it means that the core has to include its own ECC arithmetic code to perform the validation in software.

So there should be a key validation entry point, which the core must call before using a key. And the specification should guarantee that when the core requests an operation on the key, the key has already been validated. Whether the key is only ever validated on import or potentially at another time (e.g. on first use) could be left up to the core implementation.

@gilles-peskine-arm
Copy link
Contributor Author

@stevew817 Noted that a validate entry point doesn't work when import modifies the key data. While PSA implementations are only required to support importing the canonical key representation, there are common cases where keys may be canonicalized on import. For example, in Mbed TLS:

  • RSA keys are accepted in multiple formats (with or without SubjectPublicKeyInfo wrapping).
  • Curve25519 and Curve448 are accepted with the forced bits unmasked.

Instead there should be an import entry point, just like for opaque driver. The job of this entry point would usually be to validate the key and copy it from the input buffer passed to psa_import_key to the internal buffer. If the key is in non-canonical format, the import entry point would need to convert and not just copy.

@bensze01 bensze01 modified the milestones: September 2020 Sprint, Driver interface: API design and prototype Jul 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component-crypto Crypto primitives and low-level interfaces
Projects
None yet
3 participants