On Wednesday, 20 March 2024 02:44:51 CET, Jacob Bachmeyer wrote:
Hubert Kario via Gcrypt-devel wrote:
On Saturday, 16 March 2024 00:43:58 CET, NIIBE Yutaka wrote: ...
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.
IIUC, there are ways to do polling more often... some gaming mice advertise
that as a feature.
But, yes, if there is no differentiation in the reply times, or they don't
depend on the secret data, then you will fix the timing side-channel.
It should be noted that this will protect only against timing
side-channel.
There are other side-channels, like sound:
https://arstechnica.com/information-technology/2013/12/new-attack-steals-e-mail-decryption-keys-by-capturing-computer-sounds/
or power related (using remote CCTV cameras):
https://arstechnica.com/information-technology/2023/06/hackers-can-steal-cryptographic-keys-by-video-recording-connected-power-leds-60-feet-away/
Fixing it so that the timing of the actual operation is actually
independent
of secret data is a first step in fixing the power side channels.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
