Hubert Kario via Gcrypt-devel wrote:
On Saturday, 16 March 2024 00:43:58 CET, NIIBE Yutaka wrote:
Hubert Kario <hka...@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
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
