
How to defeat Ed25519 and EdDSA using faults - lisper
https://research.kudelskisecurity.com/2017/10/04/defeating-eddsa-with-faults/
======
tptacek
The most important thing to understand about this attack is that it's premised
on attackers physically flipping bits, usually in targeted memory locations,
during particular phases of computation. Even for attackers with physical
access to a device, it's not an easy attack to pull off. It's for the most
part not a line of attacks relevant to client/server and cloud software (your
cloud provider has less dramatic ways of destroying your security).

The textbook example of a setting where fault attacks matter is smart cards:
they're computing devices that perform crypto operations and their users are
naturally adversarial (the card controls their access to some resource they'd
naturally prefer unfettered access to). The crypto in a smart card needs to
work even when the custodian of the card is zapping it with lasers.

The paper mentions IOT as a setting that will increasingly implicate fault
attacks. To some extent, maybe. Most IOT devices aren't adversarial with the
people whose custody they're in; in other words, if you can get your hands on
an IOT device once deployed, the threat model for that device basically
already says you own all the "secrets" in the device.

Another pretty important thing to know is that while the paper is interesting,
it's not unexpected that DFA attacks would compromise EdDSA; they compromise
pretty much everything, don't they?

Finally: I think you really don't care what your crypto library has to say
about DFA attacks on its EdDSA implementation. All the mainstream
implementations will be "vulnerable" to the attack (EdDSA is unworkably slow
with the most obvious workaround of checking the signatures you yourself
generate). If you need protection against fault attacks in your threat model,
you are _way_ past the point where library safeguards will help you. This is
probably the point at which you can't responsibly ship products without
getting an actual crypto consultancy to sign off on it.

These are relatively straightforward attacks, both conceptually (the paper has
a pretty useful breakdown of "nine" attacks on EdDSA that are basically the
same fundamental attack applied to different phases of the algorithm) and to
simulate in software, so if you really want to get your head around it, boot
up a Sage shell, get EdDSA working, and just play with fake "bit flips".

~~~
Lery
You seems to have read the second paper which got published on the same topic
shortly after this work was presented at FDTC. However both papers are about
the same kind of fault attacks. And since you mention playing around, the
first paper and the blog post here also provide some python code for you to
play with bit flips.

Regarding the IOT setup, I know first hand that Nest products are trying very
hard to be secure even in case of physical possession. Especially on the
firmware signature verification part. But they rely on some fun post-quantum
scheme, not on EdDSA.

It's true that in the end it all boils down to your threat model, but I bet
smartcard producers are glad someone researched this before they got on the
EdDSA train.

~~~
floodyberry-
> but I bet smartcard producers are glad someone researched this before they
> got on the EdDSA train.

If the only thing controlling whether they implement something is if they can
find negative results on google, I don't think they'll be glad for very long.

------
loup-vaillant
Crap, now I have to update my manual¹, and advise the paranoid to verify the
signature they just generated. Perhaps even provide a helper function for it?

(I still think letting the user control `r` is too dangerous.)

[1]: [http://loup-vaillant.fr/projects/monocypher/](http://loup-
vaillant.fr/projects/monocypher/)

~~~
Lery
You don't really want to verify the signature you've just generated, if you
care about perf, because verification is twice as costly as signing.

~~~
marcosdumay
Yet, if you then proceed to send your signed document over a network, for it
to be rejected 10 minutes later because of a bad signature and then you have
to start from the beginning again, that verification cost is irrelevant.

~~~
loup-vaillant
How frequent do you expect failures to be? (That would attack induced
failures). There's a threshold below which the "10 minutes later" cost less
than wasting 3ms _every single time_.

------
meta_AU
It has always seemed like a footgun for the algorithm to totally cave if the
'r' value is reused for the same key and different message. This attack uses
the deterministic 'r' generation using the key and the message (to ensure that
the 'r' is only reused if the message is the same), but then glitches the hash
function that is used on the message during signing (so the same'r' is used on
a different message).

Edit: Removed silly question on why the order has to be 'r' before the second
hash. Spolier: Signature is two parts - and at least one needs to be fixed to
prevent an forger just modifying both. That needs to be the 'r' part, so it
has to be before the S.

~~~
loup-vaillant
I have another, perhaps less silly question.

The way EdDSA works, one needs to hash the message twice, in a way that makes
incremental hashing impossible (you need to complete the first pass before you
begin the second):

    
    
      r = Hash(secret_key | message)
      R = Base_point × r
      H = Hash(R | public_key | message)
      // use H to compute the signature
    

Because of this, we cannot have a streaming interface. Thus, signing and
verifying huge messages is a hassle. I _think_ there are ways to avoid this,
_if_ we're willing to mess with EdDSA (I'm not).

We could for instance change the second hash to this:

    
    
      H = Hash(public_key | message | R)
    

By _appending_ R to the rest, instead of _pre-pending_ it, we can perform the
two hashes in parallel, and use the result of the first hash only for the last
bit of the second hash.

A more involved tweak would hash the message first:

    
    
      r = Hash(message | secret_key)
      R = Base_point × r
      H = Hash(message | R | public_key)
    

That way you can hash the message _once_ , then duplicate the hash context to
complete the two hashes.

\---

Now the question: would those modifications work? Are they still immune to
collision attacks? How about length extension attacks?

Subsidiary question: if my modifications are secure, how DJB and al didn't
think of it? DJB in particular is reputed to be quite performance sensitive.

~~~
cryptonector
EdDSA is NOT online, but it's trivial to use it in an online way: sign a hash
of the data rather than the data. But now you're back to having collisions
(EdDSA is collision resistant). So it's a trade-off you have to make. As for
DJB's take on this, there were lengthy debates about this on the CFRG list,
and you find out for yourself (spoilers: he's very big on collision
resistance). Of course, the need for online algorithms is real, but there's
more than one way to skin that cat.

~~~
loup-vaillant
Do you have a link to those debates? I'm searching through the mailing list,
no luck so far.

~~~
cryptonector
The list archives are difficult to link to.

Look for posts around June 2015, e.g., with Subject:s like "Summary of the
poll: Elliptic Curves - signature scheme: friendliness to low memory
implementations" or subjects containing "IUF" (Init, Update, Final) here:

[https://www.ietf.org/mail-
archive/web/cfrg/current/mail5.htm...](https://www.ietf.org/mail-
archive/web/cfrg/current/mail5.html)

(The archives' main page is [https://www.ietf.org/mail-
archive/web/cfrg/current/maillist....](https://www.ietf.org/mail-
archive/web/cfrg/current/maillist.html))

------
clawoo
Anyone have any idea how does this affect Olm[1] (and possible NaCl and
libsodium)? I know it uses Ed25519 signatures for both the device fingerprint
and the one time pre keys.

[1]:
[https://git.matrix.org/git/olm/about/docs/signing.rst](https://git.matrix.org/git/olm/about/docs/signing.rst)

~~~
Arathorn
On the Matrix side we’re reading through the paper and seeing if/how it
applies to Olm.

~~~
tptacek
Why would you need to read through the paper to see if it applies? Are you
deployed in settings where attackers can physically flip bits or not? That
question, the only one that matters, is posed essentially in the abstract of
the paper.

~~~
Arathorn
Yup, Olm could conceivably be deployed in settings where attackers could
physically flip bits, but we're not aware of anyone doing so yet (all current
usage is on non-embedded devices where the hassle of bit flipping would be
enormous).

Assuming I've correctly skimmed the paper, it looks like it relies on your
Ed25519 impl incorrectly reusing the same 'r' value when signing messages -
and then deliberately flipping bits whilst it does so, in order to gradually
recover the private key. Our usage of Ed25519 doesn't reuse 'r' values, so I
think Olm is okay.

~~~
lvh
The article acknowledges RFC6979, which is the standard way to produce a
deterministic r that doesn't have this problem intrinsically. It also refs
RFC8032, which has EdDSA in it (both variants).

The fault attack acts after that deterministic generation, so tha fact that
Olm doesn't reuse r values explicitly doesn't matter. You're not _erroneously_
reusing r: the attack involves you trying to sign the same message twice, with
a fault occurring on the second signing.

------
jopsen
I wonder how long before someone demonstrates fault attacks triggered from a
sandbox in the cloud..

I imagine something like rowhammer could be used..

~~~
kerouanton
This attack uses physical fault injection, so it shouldn't be trivial for
remote attackers to use it, but it definitely is a nice demonstration, and
exposes vulnerabilities on chips that generate and store such keys, like maybe
pay-tv cards (remember the business of Kudekski/Nagra).

~~~
marcosdumay
Just a while ago there was a paper here about how to create faults using the
CPU's power management features, by software.

~~~
tptacek
Sure, and Rowhammer flips bits from software too. The point here is you need
relatively precise control not just in location but in timing of your bit
flips to break crypto like this. Rowhammer attackers have the luxury of
attacking bits that stay high-value for long periods of time. DFA attackers
get very tiny windows.

------
TurboHaskal
For a moment, I thought somebody wrote an article on how to beat edw519's HN
karma.

------
animal531
I believe the only way to defeat Ed209 is also through exploiting its faults.

~~~
loup-vaillant
Referring to its first demo? Really, the engineers were asking for that…
"glitch":

1) Failed to test Ed209 on demo conditions (medium sized meeting room).

2) Failed to anticipate the failure of the sound recognition algorithm ( _gun
on on carpet_ instead of _gun on concrete_ ).

3) Failed to implement software failsafes for the demo: a layer on the motor
system so it never touches anything (especially moving things such as humans),
a weapons system that doesn't actually fire…

4) Failed to implement a proper shut down button, such as a physical plug one
could pull from behind.

5) _Loaded the damn thing with live ammo._

