Side-channel vulnerability in libgcrypt - the Marvin Attack

[Jacob Bachmeyer]

NIIBE Yutaka wrote:
> Hello,
>
> Jacob Bachmeyer <jcb62281 at 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