Searched hist:b621fb503c76f3bdf06ed5ed1d3a995df8da9c50 (Results 1 – 2 of 2) sorted by relevance
| /rk3399_ARM-atf/drivers/auth/mbedtls/ |
| H A D | mbedtls_x509_parser.c | fabd21ad36a4ae405fbc6a938151620cda8bc31e Thu Feb 09 10:26:54 UTC 2017 Antonio Nino Diaz <antonio.ninodiaz@arm.com> Revert "tbbr: Use constant-time bcmp() to compare hashes"
This reverts commit b621fb503c76f3bdf06ed5ed1d3a995df8da9c50.
Because of the Trusted Firmware design, timing-safe functions are not
needed. Using them may be misleading as it could be interpreted as being
a protection against private data leakage, which isn't the case here.
For each image, the SHA-256 hash is calculated. Some padding is appended
and the result is encrypted with a private key using RSA-2048. This is
the signature of the image. The public key is stored along with BL1 in
read-only memory and the encrypted hash is stored in the FIP.
When authenticating an image, the TF decrypts the hash stored in the FIP
and recalculates the hash of the image. If they don't match, the boot
sequence won't continue.
A constant-time comparison does not provide additional security as all
the data involved in this process is already known to any attacker.
There is no private data that can leaked through a timing attack when
authenticating an image.
`timingsafe_bcmp()` is kept in the codebase because it could be useful
in the future.
Change-Id: I44bdcd58faa586a050cc89447e38c142508c9888
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
b621fb503c76f3bdf06ed5ed1d3a995df8da9c50 Fri Jan 13 13:53:32 UTC 2017 Antonio Nino Diaz <antonio.ninodiaz@arm.com> tbbr: Use constant-time bcmp() to compare hashes
To avoid timing side-channel attacks, it is needed to use a constant
time memory comparison function when comparing hashes. The affected
code only cheks for equality so it isn't needed to use any variant of
memcmp(), bcmp() is enough.
Also, timingsafe_bcmp() is as fast as memcmp() when the two compared
regions are equal, so this change incurrs no performance hit in said
case. In case they are unequal, the boot sequence wouldn't continue as
normal, so performance is not an issue.
Change-Id: I1c7c70ddfa4438e6031c8814411fef79fd3bb4df
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
|
| H A D | mbedtls_crypto.c | fabd21ad36a4ae405fbc6a938151620cda8bc31e Thu Feb 09 10:26:54 UTC 2017 Antonio Nino Diaz <antonio.ninodiaz@arm.com> Revert "tbbr: Use constant-time bcmp() to compare hashes"
This reverts commit b621fb503c76f3bdf06ed5ed1d3a995df8da9c50.
Because of the Trusted Firmware design, timing-safe functions are not
needed. Using them may be misleading as it could be interpreted as being
a protection against private data leakage, which isn't the case here.
For each image, the SHA-256 hash is calculated. Some padding is appended
and the result is encrypted with a private key using RSA-2048. This is
the signature of the image. The public key is stored along with BL1 in
read-only memory and the encrypted hash is stored in the FIP.
When authenticating an image, the TF decrypts the hash stored in the FIP
and recalculates the hash of the image. If they don't match, the boot
sequence won't continue.
A constant-time comparison does not provide additional security as all
the data involved in this process is already known to any attacker.
There is no private data that can leaked through a timing attack when
authenticating an image.
`timingsafe_bcmp()` is kept in the codebase because it could be useful
in the future.
Change-Id: I44bdcd58faa586a050cc89447e38c142508c9888
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
b621fb503c76f3bdf06ed5ed1d3a995df8da9c50 Fri Jan 13 13:53:32 UTC 2017 Antonio Nino Diaz <antonio.ninodiaz@arm.com> tbbr: Use constant-time bcmp() to compare hashes
To avoid timing side-channel attacks, it is needed to use a constant
time memory comparison function when comparing hashes. The affected
code only cheks for equality so it isn't needed to use any variant of
memcmp(), bcmp() is enough.
Also, timingsafe_bcmp() is as fast as memcmp() when the two compared
regions are equal, so this change incurrs no performance hit in said
case. In case they are unequal, the boot sequence wouldn't continue as
normal, so performance is not an issue.
Change-Id: I1c7c70ddfa4438e6031c8814411fef79fd3bb4df
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
|