tree 9ccf256b7d0b94afb1b0741b6614b8fd3fd5e577
parent 300fa8865081d5d19f3fdb2406a99a80ad593507
author Demi Marie Obenour <demiobenour@gmail.com> 1685468969 -0400
committer Sandrine Bailleux <sandrine.bailleux@arm.com> 1686835860 +0200

fix(auth): allow hashes of different lengths

Trusted Board Boot supports multiple hash algorithms, including SHA-256,
SHA-384, and SHA-512.  These algorithms produce hashes of different
lengths, so the resulting DER-encoded hash objects are also of different
lengths.  However, the common Trusted Board Boot code only stores the
contents of the object, not its length.  Before commit
f47547b35462571636a76b737602e827ae43bc24, this was harmless: ASN.1
objects are self-delimiting, and any excess padding was ignored.
f47547b35462571636a76b737602e827ae43bc24 changed the code to reject
excess padding.  However, this breaks using a shorter hash in a build
that supports longer hashes: the shorter hash will have padding after
it, and verify_hash() will reject it.  This was found by an Arm
customer: TF-A v2.9 refused to boot, even though TF-A v2.6 (which did
not have f47547b35462571636a76b737602e827ae43bc24) worked just fine.

Storing the length of the hash turns out to be quite difficult.
However, it turns out that hashes verified by verify_hash() always come
from the ROTPK or an X.509 certificate extension.  Furthermore, _all_
X.509 certificate extensions used by Trusted Board Boot are ASN.1
DER encoded, so it is possible to reject padding in get_ext().  Padding
after the ROTPK is harmless, and it is better to ignore that padding
than to refuse to boot the system.

Change-Id: I28a19d7783e6036b65e86426d78c8e5b2ed6f542
Fixes: f47547b35462571636a76b737602e827ae43bc24 ("fix(auth): reject invalid padding in digests")
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>