
HTTPS Certificates Show Where Their Key Comes From - dc352
https://dan.enigmabridge.com/your-https-certificate-shows-where-its-key-comes-from/
======
rgbrenner
If you follow the links, you'll end up here:
[https://www.usenix.org/conference/usenixsecurity16/technical...](https://www.usenix.org/conference/usenixsecurity16/technical-
sessions/presentation/svenda)

 _Can bits of an RSA public key leak information about design and
implementation choices such as the prime generation algorithm? We analysed
over 60 million freshly generated key pairs from 22 open- and closedsource
libraries and from 16 different smartcards, revealing significant leakage. The
bias introduced by different choices is sufficiently large to classify a
probable library or smartcard with high accuracy based only on the values of
public keys. Such a classification can be used to decrease the anonymity set
of users of anonymous mailers or operators of linked Tor hidden services, to
quickly detect keys from the same vulnerable library or to verify a claim of
use of secure hardware by a remote party._

~~~
lolc
I found the original page hard to read. Reading the abstract of the paper
cleared all the confusion.

~~~
Animats
Right. The paper is much better than the PR.

It's not clear there's a real security problem here in being able to identify
the prime generator for RSA keys. Unless that generator is weaker than it
should be. They did find at least two key generators which look suspicious.
One generator never generates certain byte combinations, which indicates a
possible serious weakness in the random number generation.

Weak RSA key generators have been found in the past. Big flap back in 2012.[1]
Some keys were found which were products of two large primes where two keys
shared the one factor. This is hugely unlikely statistically; the generator
had to be defective. This isn't that bad.

The real worry, of course, is a designed-in weakness in the random number
generator, one that's not detectable by the usual statistical tests.

[1] [http://arstechnica.com/business/2012/02/crypto-shocker-
four-...](http://arstechnica.com/business/2012/02/crypto-shocker-four-of-
every-1000-public-keys-provide-no-security/)

------
voltagex_
>To help solve this serious issue, Enigma Bridge is proud to have developed a
cost-effective, ground-breaking hardware security service which is based in
the cloud.

Uh huh.

So [https://dan.enigmabridge.com/re-investigating-the-origins-
of...](https://dan.enigmabridge.com/re-investigating-the-origins-of-rsa-
public-keys/) has some more details, and the paper is at
[https://www.usenix.org/conference/usenixsecurity16/technical...](https://www.usenix.org/conference/usenixsecurity16/technical-
sessions/presentation/svenda)

It took me a couple of reads through the article to work out they're not
necessarily talking about key strength, but fingerprinting the software /
hardware that created the key in the first place.

~~~
djsumdog
That's what I gathered, and it's not a huge deal unless a certain
implementation is found to have a major bug. If a certain key generator is
generating predictable or not-entirely-random keys and you can identify which
system use those implementation, it can help script an attack vector.

~~~
timv
> _If a certain key generator is generating predictable or not-entirely-random
> keys and you can identify which system use those implementation, it can help
> script an attack vector_

Even then it's only relevant if fingerprinting makes the attack substantially
easier that simply trying the exploit.

Suppose that NastySSL 0.0.1 has a bug that reduces the strength of the keys it
generates.

If the bug (i.e. the reduction in strength) is significant, but not extreme,
so that it takes about 48 hours of CPU time to break a key, then it would
absolutely be useful to be able to fingerprint the keys produced by that tool.

If, on the other hand, the bug is extreme, so that I can break keys in seconds
(perhaps only in a subset of cases), then the fingerprinting _might_ be
helpful in saving me a few milliseconds, but it's not that big a deal.

It's an interesting (but not overly surprising) line of research, and I expect
that someone will find a way to make use of it in some sort of future attack
vector, but it's hard to see an immediately obvious attack at face value.

------
ryan-c
The tool this seems to be based on is here:
[http://www.fi.muni.cz/~xsekan/](http://www.fi.muni.cz/~xsekan/)

~~~
peterwwillis
_" Q: So what did you do?

A: Figured out that RSA public key is leaking info about a library which
created it. So we can tell which library you used for your key - based on
public key only.

Q: Is single key enough to identify source library?

A: Sometimes yes, but mostly no. If you have 5 keys from the same source, it
will be quite accurate. Just press Classify button above.

Q: Can I mutually distinguish all libraries?

A: Not always. Source libraries introducing exactly same bias to the value of
generated public moduli will be undistinguishable.

Q: Can I identify also the version of used library?

A: Sometimes. The new version of a library that did not change source code of
key generation method will not be distinguishable from the older one. E.g.,
OpenSSL 1.0.2f is not distinguishable from OpenSSL 1.0.2g, but OpenSSL 1.0.2g
is distinguishable from OpenSSL 2.0.12 FIPS.

Q: Have you tested all libraries of the world?

A: No. We test a lot of them, but not all. We also did not test all possible
version of given library. We are also missing hardware sources like SSL
accelerators (contact us please, if you have one and like to contribute).

Q: How quickly will be the information leakage vulnerability you found fixed?

A: Probably not soon. The fix would require changing code of key generation
method for the most libraries. And developers don't like to mess with that
part of crypto too often. Even if fixed in the new version, lot of old legacy
libraries will use for a long time.

Q: So how can I protect my key(s)?

A: If you need just one key, it is easy - just generate 5 keys instead of one,
let all to be classified by our tool
([http://crcs.cz/rsapp/](http://crcs.cz/rsapp/)) and then keep the one which
is classified with the least accuracy. If you need more keys to keep, it is
slightly more tricky, but still can be done (with more keys generated and
discarded).

Q: Are data you gathered and used publicly available?

A: Definitely! Download everything in datasets section and try own analysis.
Please don't forget to cite us."_

Apologies for the really long post, but this really should have been the
entire article.

------
peterwwillis
In other news, it is less likely that an SSL key was generated using IIS if
the platform it is running on is AIX.

I mean, it's a useful tip when targeting a relatively dark target, but at the
same time it isn't an absolute indicator of anything other than what generated
the key (which nobody was really surprised at before, since everything from
the prng to implementation differences could result in unique signatures for
keys).

This will be useful when someone finds an implementation-specific hole in a
key gen and someone wants to sweep the internet for servers with bad keys.

------
d33
I flicked through the article and couldn't see it written quickly - what
information could be extracted from my SSH public key and how?

~~~
djmdjm
which software (e.g. ssh-keygen, puttygen) you used to generate it.

~~~
username223
I don't see why this is a big deal. There are only a handful of such programs
(as shown by this goofy graph with no y axis label[1]). If one or more of them
is vulnerable, an attacker can just try all (< 20?) possible exploits without
bothering to sniff for information leaks. Otherwise, sniffing those leaks
tells him you run foobar-keygen, which leaks its identity and has no known
vulnerabilities.

[1] [http://i0.wp.com/dan.enigmabridge.com/wp-
content/uploads/201...](http://i0.wp.com/dan.enigmabridge.com/wp-
content/uploads/2016/11/ClassificationGroups_and_their_security.png)

------
rurban
It didn't detect my old gnupg rsa-1024 key, even if it has lots of attachments
and subkeys. So call me sceptical.

------
0xmohit
Amusing that a _security blog_ has more than half a dozen trackers.

~~~
grzm
They are very secure in their tracking :) I see

\- Facebook

\- Google

\- Gravatar

\- Pinterest

\- Wordpress stats

Which am I missing?

