HTTPS Certificates Show Where Their Key Comes From
dan.enigmabridge.com
dan.enigmabridge.com
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.
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-...
and just to add, the paper itself and a video of the author's presentation are available at this page.
Uh huh.
So https://dan.enigmabridge.com/re-investigating-the-origins-of... has some more details, and the paper is at https://www.usenix.org/conference/usenixsecurity16/technical...
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.
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.
> 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
This is just a FUD piece trying to sell their fancy cloud-based secure hype generator. Don't let your dirty hippie sysadmins use scary "Software standard use" methods like OpenSSL for key management!
> ... whether companies think about the quality of their encryption keys or let their administrators use any tool at hand – instead of using secure hardware key generators > Use of validated secure hardware for key generation is the best approach to protect against many attacks.
To be fair, some method for evaluating the security weaknesses in public keys (like blacklisting the weak Debian keys) is a good thing. I just take offense at this "custom secure hardware > standard software" thing.
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/) 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.
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.
> Enigma Bridge has expanded on the discovery and built a tool that can with great accuracy tell which security mechanisms companies use for their https key generation.
[1] http://i0.wp.com/dan.enigmabridge.com/wp-content/uploads/201...
- Gravatar
- Wordpress stats
Which am I missing?