5 ms·

HTTPS Certificates Show Where Their Key Comes From

66 points by dc352 10y ago

d33 10y ago
I flicked through the article and couldn't see it written quickly - what information could be extracted from my SSH public key and how?
- SallySwanSmith 10y ago
  It seems like they won't say unless you are willing to pay > 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.
- djmdjm 10y ago
  which software (e.g. ssh-keygen, puttygen) you used to generate it.
  - username223 10y ago
    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/2016/11/ClassificationGroups_and_their_security.png http://i0.wp.com/dan.enigmabridge.com/wp-content/uploads/201...
voltagex_ 10y ago
>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-rsa-public-keys/ 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-sessions/presentation/svenda 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.
- djsumdog 10y ago
  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 10y ago
    > 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.
- terom 10y ago
  > The main purpose of https ... Until now, it has been widely accepted ... No one expected that ... were supposed to be completely hidden from users as well as attackers. The worrying discovery .. > 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.
rgbrenner 10y ago
If you follow the links, you'll end up here: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/svenda https://www.usenix.org/conference/usenixsecurity16/technical... 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 10y ago
  I found the original page hard to read. Reading the abstract of the paper cleared all the confusion.
  - Animats 10y ago
    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-of-every-1000-public-keys-provide-no-security/ http://arstechnica.com/business/2012/02/crypto-shocker-four-...
- deleted 10y ago
  [deleted]
ryan-c 10y ago
The tool this seems to be based on is here: http://www.fi.muni.cz/~xsekan/ http://www.fi.muni.cz/~xsekan/
- peterwwillis 10y ago
  "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 10y ago
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.
0xmohit 10y ago
Amusing that a security blog has more than half a dozen trackers.
- grzm 10y ago
  They are very secure in their tracking :) I see - Facebook - Google - Gravatar - Pinterest - Wordpress stats Which am I missing?
rurban 10y ago
It didn't detect my old gnupg rsa-1024 key, even if it has lots of attachments and subkeys. So call me sceptical.

66 points by dc352 10y ago

d33 10y ago

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

SallySwanSmith 10y ago
It seems like they won't say unless you are willing to pay > 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.
djmdjm 10y ago
which software (e.g. ssh-keygen, puttygen) you used to generate it.
- username223 10y ago
  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/2016/11/ClassificationGroups_and_their_security.png http://i0.wp.com/dan.enigmabridge.com/wp-content/uploads/201...

voltagex_ 10y ago

>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-rsa-public-keys/ 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-sessions/presentation/svenda 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.

djsumdog 10y ago
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 10y ago
  > 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.
terom 10y ago
> The main purpose of https ... Until now, it has been widely accepted ... No one expected that ... were supposed to be completely hidden from users as well as attackers. The worrying discovery .. > 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.

rgbrenner 10y ago

If you follow the links, you'll end up here: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/svenda https://www.usenix.org/conference/usenixsecurity16/technical... 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 10y ago
I found the original page hard to read. Reading the abstract of the paper cleared all the confusion.
- Animats 10y ago
  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-of-every-1000-public-keys-provide-no-security/ http://arstechnica.com/business/2012/02/crypto-shocker-four-...
deleted 10y ago
[deleted]

ryan-c 10y ago

The tool this seems to be based on is here: http://www.fi.muni.cz/~xsekan/ http://www.fi.muni.cz/~xsekan/

peterwwillis 10y ago
"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 10y ago

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.

0xmohit 10y ago

Amusing that a security blog has more than half a dozen trackers.

grzm 10y ago
They are very secure in their tracking :) I see - Facebook - Google - Gravatar - Pinterest - Wordpress stats Which am I missing?

rurban 10y ago

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