[crypto] Redundant GHASH computation as FI mitigation #28485
Conversation
nasahlpa
added
the
CherryPick:earlgrey_1.0.0
There was a problem hiding this comment.
Thanks @nasahlpa I think this is very useful.
The hardening has low code size. There is a stack size consumption penalty but I think avoiding this would add significant code size. the hardening is optional at runtime through setting the key level also.
Compute the GHASH state twice and compare it. When a mismatch due to a FI attack is detected, trap. The redundant check is only conducted for key.security_level > kOtcryptoKeySecurityLevelLow. Signed-off-by: Pascal Nasahl <[email protected]>
nasahlpa
force-pushed
the
aes_gcm_fi_hardening
branch
from
cd8dd8d to
906a284
Compare
| // Compare the GHASH state. Do this only at a single share to avoid | ||
| // introducing SCA leakage. | ||
| HARDENED_CHECK_EQ( | ||
| memcmp(&ctx->state0.data, ctx_redundant.state0.data, kGhashBlockNumBytes), |
There was a problem hiding this comment.
Is memcmp constant time? If it is not, then it might still introduce some DFA possibility
There was a problem hiding this comment.
should be constant time
There was a problem hiding this comment.
Just to double check, we are sure not to use hardened_memeq instead?
There was a problem hiding this comment.
memcmp not constant time IIUC, hardened_memeq cannot be used due to non-word alignment of struct
There was a problem hiding this comment.
Thanks for the offline discussion. We should switch here to the new constant time memeq function introduced in this PR #28501.
3 participants
Compute the GHASH state twice and compare it. When a mismatch due to a FI attack is detected, trap. The redundant check is only conducted for key.security_level > kOtcryptoKeySecurityLevelLow.