9
$\begingroup$

Assume we have a processor with a symmetric co-processor that supports AES. This processor does however not provide co-processor support for hash algorithms such as SHA-1 or SHA-256.

I've got the following strongly related questions:

  1. Would an HMAC implementation based on a hash implementation in software - which is not explicitly protected against side channel attacks - be vulnerable to side channel attacks?
  2. If so, are there reasons why such an attack would be stronger or less strong than e.g. a side channel attack against a symmetric cipher in CBC mode?
  3. Would it be possible to retrieve the key used to key the HMAC algorithm?
  4. Finally, could it be safer to opt for AES-CMAC instead in case an AES implementation in hardware is available?

It is assumed that the comparison of authentication tag values does not leak information. Both DPA and timing attacks could be considered.

The reason I'm asking is because hash algorithms are often not explicitly protected against side channel attacks. HMAC is still often used in this scenario.

$\endgroup$
  • $\begingroup$ Are you aware of any kind of side channel attacks against SHA-1 or SHA-2? There are no data dependent table look-ups like in AES and the algorithms appear to have a completely input independent operation flow. $\endgroup$ – Henrick Hellström Jan 30 '16 at 12:55
  • $\begingroup$ Yeah, I heard about that remark. But does that mean that the algorithm is completely free of side channel attacks by design? Would that also be the case for e.g. Keccak / SHA-3? $\endgroup$ – Maarten Bodewes Jan 30 '16 at 12:59
  • 2
    $\begingroup$ No, I'm not aware of these kind of side channel attacks. But I'm not aware of any papers that completely rule them out either. Oh, hey, I just found a paper about an attack on HMAC/SHA-1... $\endgroup$ – Maarten Bodewes Jan 30 '16 at 13:04
  • 2
    $\begingroup$ I've found some other papers against HMAC as well. Paper 1 against HMAC based on block cipher based hashes. Paper 2 against HMAC-SHA-2 (DPA + Hamming Weight oracle AFAICT). Paper 3 (a presentation really) general analysis of HMAC of SHA-3 candidates. $\endgroup$ – SEJPM Jan 30 '16 at 13:24
  • 3
    $\begingroup$ True, if the hardware leaks the number of bits affected by instructions that would otherwise be assumed to be atomic, all bets are off. This obviously begs the question exactly what might be assumed about the hardware? $\endgroup$ – Henrick Hellström Jan 30 '16 at 13:25
3
$\begingroup$

I am answering on the basis of this paper (pdf) linked in the comments, as well as some of the related papers it cites or is cited by. I am not aware of more realistic attacks on HMAC.

It assumes a DPA side channel that leaks the number of bits flipped when a new value is read into a CPU register (or in another instruction in some of the papers). I.e. it leaks the Hamming distance between the old value and the new. This allows a direct key recovery attack on HMAC, made easier by the fact that HMAC uses inner and outer keys that are conveniently a known distance apart.

If you assume such a side channel, there is not much you can securely do on the computer. In fact, a typical hardware implementation of HMAC would be almost equally likely to be vulnerable, if you still have to load the key from memory to use it.

  1. Would an HMAC implementation based on a hash implementation in software - which is not explicitly protected against side channel attacks - be vulnerable to side channel attacks?

I do not think it is a matter of software vs. hardware or even side channel protection. If such a side channel as described above exists, there is not much you can do securely on the CPU. Certainly most conventional data processing with secret values has to be rethought.

  1. If so, are there reasons why such an attack would be stronger or less strong than e.g. a side channel attack against a symmetric cipher in CBC mode?

Stronger, in the sense that it is a key-recovery attack, unlike e.g. padding oracle attacks that target CBC. But the assumptions are much stronger as well.

  1. Would it be possible to retrieve the key used to key the HMAC algorithm?

Yes, assuming.

  1. Finally, could it be safer to opt for AES-CMAC instead in case an AES implementation in hardware is available?

Not necessarily. For example, with AES-NI instructions you have to load the AES key into XMM registers, which has the potential of allowing a key-recovery attack in the same manner.

If you have a dedicated crypto chipset that also stores the keys then it may be a different matter. Of course, there is no a priori reason to assume it does not have the side channel too. And you need to get the keys into it securely.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.