PSA_ALG_ECDSA(PSA_ALG_ANY_HASH) should not allow PSA_ALG_ECDSA_ANY #533

New issue

Open

opened 2025-10-17 12:29:09 -05:00 by gilles-peskine-arm · 0 comments

gilles-peskine-arm commented

2025-10-17 12:29:09 -05:00

(Migrated from github.com)

According to the PSA Crypto API specification 1.1 for PSA_ALG_ECDSA_ANY:

This algorithm cannot be used with the wildcard key policy PSA_ALG_ECDSA(PSA_ALG_ANY_HASH).

Previous versions of the specification did not explicitly state whether PSA_ALG_ECDSA(PSA_ALG_ANY_HASH) covered PSA_ALG_ECDSA_ANY. In an implementation, if you don't pay attention, it probably does, since the encoding of PSA_ALG_ECDSA_ANY is equal to PSA_ALG_ECDSA(0).

In TF-PSA-Crypto 1.0.0, PSA_ALG_ECDSA(PSA_ALG_ANY_HASH) does allow PSA_ALG_ECDSA_ANY. I haven't checked but I believe this has always been the case every since the initial implementation.

I don't think there's a genuine security concern here. PSA_ALG_ECDSA(PSA_ALG_ANY_HASH) allows ECDSA with any hash, and this could be extended to a hash that PSA does not support but which an application calculates before passing to the signature function. (For example, MD5||SHA1 as used in TLS ≤1.1.) This is very similar to PSA_ALG_RSA_PKCS1V15_SIGN_RAW, which is_ allowed. It's weird that the two are treated differently. Admittedly, there is a difference in terms of security posture: RSA-PKCS#1v1.5 signature is secure even if what you pass as the “hash” input is actually not a hash but something malleable, whereas ECDSA is insecure. I'm not sure if that's enough to justify the different treatment.

I don't remember whether I explicitly thought about both cases when I added the hash wildcard; they aren't mentioned explicitly in the pull request that introduced it. But my natural inclination is to think that both should be covered by the wildcard.

However, now that this is stated explicitly in the PSA specification, we should comply to it.

According to the [PSA Crypto API specification 1.1 for `PSA_ALG_ECDSA_ANY`](https://arm-software.github.io/psa-api/crypto/1.1/api/ops/sign.html#c.PSA_ALG_ECDSA_ANY): > This algorithm cannot be used with the wildcard key policy `PSA_ALG_ECDSA(PSA_ALG_ANY_HASH)`. Previous versions of the specification did not explicitly state whether `PSA_ALG_ECDSA(PSA_ALG_ANY_HASH)` covered `PSA_ALG_ECDSA_ANY`. In an implementation, if you don't pay attention, it probably does, since the encoding of `PSA_ALG_ECDSA_ANY` is equal to `PSA_ALG_ECDSA(0)`. In TF-PSA-Crypto 1.0.0, `PSA_ALG_ECDSA(PSA_ALG_ANY_HASH)` does allow `PSA_ALG_ECDSA_ANY`. I haven't checked but I believe this has always been the case every since the [initial implementation]((https://github.com/ARMmbed/mbed-crypto/pull/15)). I don't think there's a genuine security concern here. `PSA_ALG_ECDSA(PSA_ALG_ANY_HASH)` allows ECDSA with any hash, and this could be extended to a hash that PSA does not support but which an application calculates before passing to the signature function. (For example, MD5||SHA1 as used in TLS ≤1.1.) This is very similar to [`PSA_ALG_RSA_PKCS1V15_SIGN_RAW`](https://arm-software.github.io/psa-api/crypto/1.1/api/ops/sign.html#c.PSA_ALG_RSA_PKCS1V15_SIGN_RAW), which is_ allowed. It's weird that the two are treated differently. Admittedly, there is a difference in terms of security posture: RSA-PKCS#1v1.5 signature is secure even if what you pass as the “hash” input is actually not a hash but something malleable, whereas ECDSA is insecure. I'm not sure if that's enough to justify the different treatment. I don't remember whether I explicitly thought about both cases when I added the hash wildcard; they aren't mentioned explicitly in [the pull request that introduced it](https://github.com/ARMmbed/mbed-crypto/pull/15). But my natural inclination is to think that both should be covered by the wildcard. However, now that this is stated explicitly in the PSA specification, we should comply to it.

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Mbed-TLS/TF-PSA-Crypto#533

No description provided.

Rows
Columns