On 17/03/2010 05:03, James Muir wrote:
> ** I just had the following realization:  I had assumed that the authors
> were attacking an openssl *server* running on the fpga board, but
> perhaps that is not so.  They don't seem to make that specific claim.
> They claim only to be attacking an "unmodi ed version of the OpenSSL
> library".  It is possible that they only created a toy RSA application
> that generates signatures using the openssl library (i.e. by making
> calls to specific openssl functions).  This would explain why they don't
> discuss message blinding -- because they didn't enable it in their toy
> application!  I suspect that's what they did.  In that case, their
> experimental results say very little about the susceptibility of an
> openssl server to fault attacks.  Wow... if I'm correct, then the
> authors really need to be more clear about exactly what they did.

What everyone said...

Plus ... even with their fix, all they have to do is induce two errors
in quick succession and OpenSSL will spit out the key whole.

In any case, this all seems entirely pointless: in order to mount the
attack, you have to have intimate access to the hardware. In other
words, what they have demonstrated is that DRM doesn't work. Groundbreaking.

Of course, the annoying fall-out is that there will be (already is) a
knee-jerk clamour for us to "fix" OpenSSL. Well, I've got news: securing
anything in the face of an unpredictable CPU seems well beyond the scope
of the OpenSSL project - or any other crypto library I am aware of. I'm
not even sure it's possible.



http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to