Searched hist:"22 a53545aa37c06a1ffd0f3c15e870b256a41cb7" (Results 1 – 2 of 2) sorted by relevance
| /rk3399_ARM-atf/drivers/auth/mbedtls/ |
| H A D | mbedtls_x509_parser.c | 22a53545aa37c06a1ffd0f3c15e870b256a41cb7 Tue May 30 17:49:29 UTC 2023 Demi Marie Obenour <demiobenour@gmail.com> 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>
|
| H A D | mbedtls_crypto.c | 22a53545aa37c06a1ffd0f3c15e870b256a41cb7 Tue May 30 17:49:29 UTC 2023 Demi Marie Obenour <demiobenour@gmail.com> 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>
|