Fault attacks on RSA in libgcrypt

[Jeff Burdges]

On Mon, 2016-08-22 at 19:42 +0200, Jeff Burdges wrote:
> I implemented the protection against fault attacks recommended in
> "Making RSA-PSS Provably Secure Against Non-Random Faults" by Gilles
> Barthe, François Dupressoir, Pierre-Alain Fouque, Benjamin Grégoire,
> Mehdi Tibouchi and Jean-Christophe Zapalowicz.
>   https://eprint.iacr.org/2014/252


I chatted with the hardware attack folk in the office briefly today.
And I'm no longer so sure this fault attack is actually realistic.  At
least it's much more subtle than I'd initially imagined.

In the Lenstra comparison, the two MPIs should live on the heap, but
actual comparison result should live in a register.  We could've
rowhammer like attacks on either the code page or on the MPIs, but
probably not on the comparison result itself, well not unless the thread
gets switched out.  

Non-random fault attacks on the code pages are obviously fatal, but
maybe that's out of scope, and quite unlikely.  I think attacks on the
MPIs do no good because our attacker is trying to obtain the first one,
so say zeroing those lengths ruins it, and they cannot make the first
match the second.  

I think our only plausible fault attack is to run a Lenstra-like
attack, while concurrently running code on the machine that attempts to
force the RSA task to be swapped out after the MPI comparison operation
fails, and rowhammer the OSes thread data structures to attempt to
switch this one register.  

At this point, we're discussing rowhammering kernel memory, so maybe a
privilege escalation would be easier. 

Thoughts?  It's probably worth better understanding the real strength of
the security proof.

Jeff

p.s.  It's worth asking if one can attack anything else too.  You could
maybe rowhammer a few bits in the private key to produce a faulty
modulus with small factors and small hamming distance to the original
modulus.  Ain't clear if one could really do this while preserving ed=1
mod phi though.  If not, the Lenstra comparison should still fail.  Yet,
phi need not be phi(n) exactly here, so maybe it's possible.  I'm unsure
if the security proof in that paper addresses this case, maybe not.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: </pipermail/attachments/20160823/81710782/attachment.sig>