You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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.
According to the PSA driver interface,
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.
The text was updated successfully, but these errors were encountered: