advertisement

CSEP 590 Final Project Greg Hullender CESP 590 – Practical Applications of Modern Cryptography Greg Hullender Microsoft Campus Tuesday, March 7, 2006 Final Project -1- CSEP 590 Final Project Greg Hullender Estimating a Lower Bound on the Entropy of HTTPS Public Keys Greg Hullender Abstract Public Key Cryptography secures online commerce on https sites, but this is only as secure as the keys themselves. A poor random number generator could lead to some sites sharing prime factors, making it trivial to compute their private keys. This paper aims to place an upper bound on the actual risk by using a large sample of actual public keys to estimate a lower bound on the entropy of the primes chosen for the modulus of the keys. Background Most e-commerce depends on the security of “https” web pages. Those pages implement “TSL/SSL” [1] which depends on the security of RSA public key cryptography. [2] In the RSA public key system, a site-owner picks two large prime numbers (p and q) at random, where large means anywhere from 256 to 4096 bits long. The owner publishes the product of those two primes (called the modulus) plus another number (called the exponent) and together these two numbers constitute the public key. The private key is simply the same modulus plus the multiplicative inverse of the public exponent, modulo (p-1)(q-1). The security of the algorithm rests on the fact that the private exponent cannot be computed easily without knowing p and q, and that the problem of factoring the modulus is intractable. Accordingly, the site owner has to keep p, q, and the private exponent as closely-guarded secrets. A potential weakness is the entropy of the random-number generator used to produce p and q. This is not just a theoretical concern; the same problem has affected other systems in the recent past. For example, in 2003, it was reported that many implementations of the popular Kerberos protocol used a random-number generator that only had about 20 bits of entropy. [3] It’s at least conceivable that many sites using TLS/SSL have a similar problem. To exploit this weakness, if it exists, an attacker would obtain a large number of public keys from https sites and compute the Greatest Common Divisor (GCD) of the moduli of all possible pairs of keys. Unlike the problem of factoring the modulus, the problem of computing the GCD from a pair of keys is only O(n2), where n is the length of the modulus. If the GCD of two keys is not 1, that means they share a prime, and the GCD will be that shared prime. Division of each modulus by the shared prime recovers the unshared one. The secret exponents (for both keys) can then be computed using the Extended Euclidean algorithm – the same way the legitimate owners created them in the first place. [2] Experimental Procedure -2- CSEP 590 Final Project Greg Hullender Summary: I queried hundreds of thousands of domains for their public keys, collecting 50,727 unique 1024-bit moduli. I then computed the GCD of all 1.25 billion pairs, all of which were 1, which means I didn’t find any compromised keys in my sample. Details: I got a list of 15,000,000 “active” domains from Microsoft’s MSN Search. A domain is “active” if it shows some signs of being used. (E.g. customers click on it when it shows as a result of a search.) The list included hit counts as well as domain names, and I selected domains from the top of it in order to maximize the probability that I would find domains with public keys. (Someone could equally well start with the Registrar database.) This potentially has the effect of biasing the experiment towards more popular sites, which one might expect to be more careful about choosing their keys, but casual examination of the list reveals that most of these are very small organizations, so that risk is probably small. Because TLS/SSL is a property of a domain, not a web page, it’s sufficient to query domains to get public keys. Microsoft’s .NET Framework 2.0 contains primitives in the TCPIP library to open a secure connection to a domain and authenticate its public key using its X509 [4] certificate. In order to maximize the number of keys, I accepted all certificates, no matter what authentication problems they had (e.g. expiration). Unfortunately, Microsoft does not document the format it uses to store public keys, but Michael Gallant’s RSAPubKeyData.cs [5] provides excellent APIs to extract keys in any of several different formats. Finally, I used the Miracl [6] library from Shamus Software to do the GCD calculations. All experiments were done on a single-processor 2.4GHz Pentium 4 running Windows XP. Experimental Results I tested 598,705 domains and found 113,397 public keys, of which 60,543 were unique. (Duplicates result from the same company having multiple domains. For example, Google appears to use the same public key on dozens of different domains.) Of the unique ones, 50,727 (over 80%) were 1024-bit keys. This process took two weeks, although it can be optimized to much less with better use of multithreading. Next I used Miracl’s multi-precision arithmetic package to compute the pair-wise GCDs. My machine could do about 5600 of these per second, so it took about 2 ½ days to completely analyze all 50,727 keys. This process did not detect any duplicates. Interpreting the Results -3- CSEP 590 Final Project Greg Hullender We can answer (or partly answer) three important questions from these results: What would it take to scale this process up to test all key pairs on the web? What is the maximum number of compromised sites on the web? What is the maximum number of sites using key generation with entropy as low as Kerberos v4? Scaling up Since I could query about 100,000 domains per day, it would have taken 150 days to interrogate all 15,000,000 domains in my list. Obviously this scales linearly with the number of computers – someone with 20 machines could do it in just a week. (There are other optimizations that could speed this up, but those are outside the scope of this paper.) At the point I stopped, roughly one site in 5 had a public key – half of them duplicates. One expects this to drop off as one gets to less and less popular sites, but there should definitely be no more than 1,500,000 sites with public keys. My machine would have taken 6 years to compute the GCD of all these pairs, since that task scales quadratically. A modern Opteron 64-bit dual-processor system is about 7× as fast as my machine, so a set of 20 machines should be able to complete this task in under three weeks. What is the maximum number of compromised sites on the web? How many compromised pairs could there be, given we found none? Imagine that there are x reused primes. There are then 2x vulnerable pairs. Order these pairs according to the value of the not-duplicated prime, so each pair has a left half and a right half. (Ignore the possibility of triples or worse.) If we randomly select M keys from a total population of N, then we’d get the following probabilities p x N Probability a random URL is a left half The binomial distribution tells us that xx M N Expected number of left-halves among M URLs That is, we ought to have x̅ “left-hand” keys, which means we should see a duplicate if we drew any of the corresponding z̅ “right-hand” keys. The odds of not seeing a duplicate in any of M keys (when there are x̅ out of N) are -4- CSEP 590 Final Project Greg Hullender M 1 xM 1 2 N 2 assume 1/2 because we found none Solving for x and using 1,500,000 for N and 50,727 for M we get x N2 ln 2 606 M2 So there is only a 50% chance that there are as many as 600 duplicated primes and therefore as many as 1200 vulnerable keys out of 1,500,000 or no more than about 0.04%. Since that estimate for the number of domains with unique keys is unquestionably high, it’s unlikely there are as many as 1,000 compromised sites. Estimating Entropy Assume that most users are generating truly random 512-bit primes, so there is no significant chance that any two will get the same prime. Now assume that some proportion of sites are using an inferior key generator with considerably lower entropy. We’ll use these variables: M m M/m b p All sites surveyed Proportion of sites using bad key generation Number of sites using bad key generation Number of bits of randomness (entropy) in bad key generator Probability we missed seeing any collisions This is simply a form of the “Birthday Problem” from statistics, treating N/m as the number of people and 2b are the number of possible “birthdays.” (See Appendix.) Directly plugging these numbers into the Birthday Equation we get M 1 2b 1 ln m p (This will not be very accurate for small numbers of bits, but we’re not interested in key generators with entropy below 8 anyway, since they’re extremely unlikely to have gone undetected.) Using this equation, we can estimate the proportion of sites that would have to be using the Kerberos v4 random-number generator for us to have a 50% chance of failing to see any collisions: -5- CSEP 590 Final Project m M 2b 1 ln Greg Hullender 1 p 50, 727 221 ln 2 64 In other words, we’re 50% confident that no more than one site in 64 is using a key generator as bad as the Kerberos v4 one. If we actually had tested all 3,000,000 domains instead of just over 50,000, we’d estimate no more than one in about 4,000 had that problem – assuming we still found no collisions. From the same equation, what’s the proportion if they’re using the old 15-bit Unix rand() function? m 50, 727 216 ln 2 238 So if even one site in 200 were using something as crude as the rand() function, we should have spotted one. We can also put a limit on the entropy of the random number generators used by all sites (that is, assume m = 1). M 2 m b log 2 1 1 ln p 50, 727 2 log 2 1 ln 2 30.8 This says we’re 50% confident that the average site is at least generating 31-bit random primes. Had we tested all 1,500,000 domains without a collision, that estimate would go up to 40.5 bits. Conclusions If this low-entropy key generation is a problem at all, it certainly isn’t a common one. Someone with the resources could certainly do a comprehensive test of all domains, but the results of this sample show that he or she is unlikely to retrieve as many as 1,000 private keys this way. Further, since the test explicitly included all the high-value sites -6- CSEP 590 Final Project Greg Hullender on the Internet, it seems impossible that a malefactor could actually make money by attempting this. References [1] Tim Dierks, Eric Rescorla, 2005, The TLS Protocol, Version 1.1, The Internet Engineering Task Force, http://www.ietf.org/internet-drafts/draft-ietf-tlsrfc2246-bis-13.txt [2] Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone, 1997, Handbook of Applied Cryptography, CRC Press, pp 287 ff. [3] Massachusetts Institute of Technology, 2003, Security Advisory http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-004-krb4.txt [4] R. Housley, W. Ford, W. Polk, D. Solo, 1999, Internet X.509 Public Key Infrastructure, Certificate and CRL Profile, The Internet Engineering Task Force, http://www.ietf.org/rfc/rfc2459.txt [5] Michel I. Gallant , JkeyNet: Using ASN.1 encoded public keys in .NET, JavaScience http://www.jensign.com/JavaScience/dotnet/JKeyNet/index.html [6] Shamus Software, Ltd., Multiprecision Integer and Rational Arithmetic C/C++ Library, http://indigo.ie/~mscott/ Appendix The Birthday Problem A group of m people having n possible birthdays (usually 365) has the following probability of no shared birthdays m p i 1 ni n m i 1 n i 1 Making use of the following approximation (which is quite good if i/n is small) i i ln 1 n n We can approximate ln p -7- CSEP 590 Final Project m ln p i 1 Greg Hullender i n m m 1 2n 2 m 2n Since we usually want to estimate the expected number of people before the probability of no collisions drops to p, we solve for m m 2n ln This is the formula used above. -8- 1 p