Side-channel vulnerability in libgcrypt - the Marvin Attack

[Jacob Bachmeyer]

Hubert Kario via Gcrypt-devel wrote:
> On Saturday, 16 March 2024 00:43:58 CET, NIIBE Yutaka wrote:
>> Hubert Kario <hkario at redhat.com> wrote:
>>> Actually no. If the time slots are consistent (say, the USB device 
>>> returns
>>> the message only on the second, on the dot), then the attacker can 
>>> tune the
>>> time when it _starts_ the operation so that it end exactly at the 
>>> second.
>>> Then quicker operations will be returned earlier, while slower will be
>>> returned a second later.
>>
>> This is not the communication of USB bus.  The request from host is also
>> time-slotted.  Your claim above would be only valid if the attacker can
>> start the request of the crypto operation from another channel where
>> timing can be accurately controlled, and the responce is on USB bus (for
>> some reason).
>
> If the communication is like that in both directions, then yes, it's more
> problematic. But as long as there is a variability in the responses, the
> statistical tests I'm using will still work.
>
> Like, if the operation normally takes between 1.8 and 2.2 s, and the
> communication can happen every 0.1 s, then the attack is still possible.
>
> It only won't be possible if the inherent variability is completely 
> hidden
> by the quantization, like if in the above example the communication could
> happen only every 10 s.

The method to harden a USB device against this type of attack is to work 
out the worst-case computation time, and always hold the response until 
that time (measured in USB time slots) has elapsed.  To use numbers from 
your example, the device performs the operation, completing it in 18 to 
22 time slots, but holds the response until 24 time slots have elapsed 
from the request.

This of course requires actually knowing how your program works and its 
worst-case running time, which sadly is probably rare in modern 
commercial programming.

The device also must guard against a malicious host by having its own 
clock (which is needed for its processor and USB interface anyway) and 
shutting down if the time slots it sees on the bus do not align with the 
USB spec.  (If I remember correctly, the USB spec requires each time 
slot to be some number of milliseconds, but the USB host determines the 
precise timing.)  Otherwise, a non-standard malicious host could "bend" 
the slot timing enough that the fixed response delay is not always 
sufficient for the operation to complete.


-- Jacob