
OpenSSL DSA key recovery attack - bqe
http://eprint.iacr.org/2016/594
======
zaroth
_Make Sure DSA Signing Exponentiations Really are Constant-Time_

"...the OpenSSL team committed two code changes relevant to this work. The
first adds a “constant-time” implementation of modular exponentiation..."

"The execution time of the “constant-time” implementation still depends on the
bit length of the exponent, which in the case of DSA should be kept secret
[12, 15, 27]. The second commit aims to “make sure DSA signing exponentiations
really are constant-time” by ensuring that the bit length of the exponent is
fixed."

"...While the procedure in this commit ensures that the bit length of the sum
kq is fixed, unfortunately it introduces a software defect. The function
BN_copy is not designed to propagate flags from the source to the destination.
In fact, OpenSSL exposes a distinct API BN_with_flags for that
functionality..."

"In contrast, with BN_copy the BN_FLG_CONSTTIME flag does not propagate to kq.
Consequently, the sum is not treated as secret, reverting the change made in
the first commit..."

Exploitation requires a local 'spy' process recording timing signals while the
handshakes are running. I assume this is an unprivileged process, otherwise
wouldn't the key be directly accessible?

~~~
joeyrideout
From section 5.2, _Attacking SSH_ (emphasis mine):

"...our client saves the hash of the concatenated string and the digital
signature raw bytes _sent from the server_. All subsequent messages, including
SSH_MSG_NEWKEYS and any client responses, are not required by our attack. Our
client therefore drops the connection at this stage, and repeats this process
several hundred times to build up a set of distinct trace, digital signature,
and digest tuples. See Section 6 for our explicit attack parameters. Figure 3
is a typical _signal extracted by our spy program in parallel to the handshake
between our client and the victim SSH server_."

This inclines me to believe that an attack can be executed _via connections to
a vulnerable SSH server_ , not from _a local process on the SSH server_.

~~~
cft
Random network delays would probably hide any meaningful timing signal in the
case of remote connections, thus they used a local process.

~~~
sk5t
One might expect this to be the default case, but it may not be so, given a
large enough sample size.

~~~
cft
Found further discussion here: [http://seclists.org/oss-
sec/2016/q2/514](http://seclists.org/oss-sec/2016/q2/514)

------
vessenes
Needs to listen to only a few hundred handshakes. Ugh. Something tells me this
could be deployed on AWS large instances with some success.

~~~
deckar01
As others have mentioned, the attack requires a local process that has a
shared cache, so it would also require a server that has a remote code
execution vulnerability.

~~~
vessenes
My memory is that there are ways to punch through virtualization that AWS uses
and get insight into cache hits/misses of other tenants, but I'm not sure if
that applies here.

In that world, you just rent some time on a large AWS instance and sit around
mucking with the cache timing waiting for another tenant to do some
cryptography.

I can't find the link to the paper now, but my thoughts went to combining
these two immediately -- you can get a local process without remote code
execution if you just log onto your shiny new multitenant virtual server.

