NIIBE Yutaka wrote:
Hello,
Jacob Bachmeyer <jcb62...@gmail.com> wrote:
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.
True. Thank you for showing this possibility. I didn't consider this
point.
To be fair, when I said "non-standard", I meant a USB host implemented
either using a programmable logic device or by bit-banging on MCU GPIO
pins. I do not believe that a PC's USB host controller, for example,
will allow that. I would expect standard hardware USB hosts to enforce
spec-compliant bus timing beyond software control. Therefore, the token
should shut down or possibly even wipe itself if it detects such
incorrect timing.
Well, in general, I suggest not keeping a USB token inserted into a host.
There are possibilities (in theory, or in history) that a decryption
service by a USB token might be providing a decryption oracle to an
attacker by some channel(s).
When a user has a practice of only powering the device when needed,
bandwidth to an attacker could be small, hopefully small enough. Slower
service is better too, for smaller bandwidth.
Leaving the token connected to the host and active (unlocked) raises a
different hazard: the token would then be available for malware on the
host to abuse at will. This largely defeats the purpose of using a
token in the first place, as the security benefits of tokens center
around preserving the security of the key even if the host is compromised.
Obvious decryption oracle: just ask the token to decrypt the
ciphertext. If it is connected and unlocked, it will. Oops.
It is a bit off-topic (from the original report). Sorry, It was me who
addressed USB communication.
And... yes, it's true that it's hard for programming to estimate
worst-case running time, it's also hard to guarantee constant-time
running time, in a given situation of programming environment and
hardware architecture.
The basic method is to do both sides of every branch and select the
result with the equivalent of a multiplexer. This obviously does not
work for loop-test branches, since loops must eventually terminate, and
still requires care at higher-levels that the set (and possibly
sequence) of operations performed is invariant with respect to secret
data, but it is possible as I understand.
This may also require avoiding the use of sufficiently-advanced
processors, if any exist that can detect that the result of a
speculative execution chain will not be used and elide the chain. This
could also be a good application for tokens containing simpler
processors intended for security over performance, if main processors
get advanced enough to do that.
-- Jacob
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
