The encryption that SSL/TLS provides (that puts the “secure” in HTTPS) uses a public–private key pair and a specific mathematical function. Generating the key pair requires a cryptographically secure random number that is impossible or very difficult to guess, which must be kept secret at all times. If this random number is leaked or guessed by a malicious actor, the private key can be reconstructed and used to impersonate a website or break the encryption.
The security of the encryption comes from the fact that the function is easy to calculate one way, but difficult to calculate its inverse. To demonstrate: multiplying the prime numbers 88117 and 44543 is easy, but the inverse, factorizing the semiprime 3924995531, is extremely lengthy in comparison.
One of the factors that determine the security of the key is the size of the number, i.e. the number of digits. In this case, a proper key should’ve had a length of 384 bits (or 116 decimal digits). In reality, the keys that eMudhra used had eight bits, which can only represent 256 possible values, and can be easily guessed even by brute force. The specific private keys were the numbers 4, 56, 66, 115, 155, 156, 230, and 237.
It’s also worth mentioning that these very poorly secured certificates were intermediate certificates. These are not used directly by websites to assure the end user that the communication with the website is secure - it’s even worse than that.
Intermediate certificates are used to sign the website certificates, so that the end user’s browser can look up the server certificates that websites give them, to determine if the certificate is genuine (and not, say, a man-in-the-middle that is intercepting the communication and merely pretending to be the real website).
Since anybody can easily just create a certificate, there has to be a way that an end user can be confident that the website they are visiting is actually the one they intend to visit. The way the current system works is that there is a curated list of CA (certificate authority) certificates that have been thoroughly vetted by multiple security organizations. These are used to “sign” server certificates. Every browser has a copy of the corresponding public CA certificate. The private certificates are kept very securely offline. There’s no easy way for anyone to create a certificate that “claims” to be (but actually isn’t) signed by one of these trusted CA certificates. This way, when a website provides its certificate, the browser can look at the signing key and know with a high degree of certainty that the website is what it says it is.
An intermediate certificate is a “delegate” subsidiary of a CA cert. It can be used as a proxy to its parent CA cert to sign other generated certs. So even if a website (or a man-in-the-middle) provides what appears to be a very secure cert with strong encryption, it may have been signed by a “broken” insecure intermediate cert. The browser, of course, doesn’t know - or care - about how insecure the the intermediate cert is - the browser has already implicitly trusted it. There fore, the browser has no way of knowing or alerting the user that their communication with the website has been compromised by someone pretending to be another website.
They were proper 384bit certs, just the upper 376 bits were 0 in all the listed certs. So it’s different to setting the key size in OpenSSL, and they were most likely rolling their own crypto.
ELI5?
Little eMudhra was asked to write down his a secret and hand it in to the teacher. He accidently gave the teacher the wrong paper.
Naughty boy
The encryption that SSL/TLS provides (that puts the “secure” in HTTPS) uses a public–private key pair and a specific mathematical function. Generating the key pair requires a cryptographically secure random number that is impossible or very difficult to guess, which must be kept secret at all times. If this random number is leaked or guessed by a malicious actor, the private key can be reconstructed and used to impersonate a website or break the encryption.
The security of the encryption comes from the fact that the function is easy to calculate one way, but difficult to calculate its inverse. To demonstrate: multiplying the prime numbers
88117and44543is easy, but the inverse, factorizing the semiprime3924995531, is extremely lengthy in comparison.One of the factors that determine the security of the key is the size of the number, i.e. the number of digits. In this case, a proper key should’ve had a length of 384 bits (or 116 decimal digits). In reality, the keys that eMudhra used had eight bits, which can only represent 256 possible values, and can be easily guessed even by brute force. The specific private keys were the numbers 4, 56, 66, 115, 155, 156, 230, and 237.
It’s also worth mentioning that these very poorly secured certificates were intermediate certificates. These are not used directly by websites to assure the end user that the communication with the website is secure - it’s even worse than that.
Intermediate certificates are used to sign the website certificates, so that the end user’s browser can look up the server certificates that websites give them, to determine if the certificate is genuine (and not, say, a man-in-the-middle that is intercepting the communication and merely pretending to be the real website).
Since anybody can easily just create a certificate, there has to be a way that an end user can be confident that the website they are visiting is actually the one they intend to visit. The way the current system works is that there is a curated list of CA (certificate authority) certificates that have been thoroughly vetted by multiple security organizations. These are used to “sign” server certificates. Every browser has a copy of the corresponding public CA certificate. The private certificates are kept very securely offline. There’s no easy way for anyone to create a certificate that “claims” to be (but actually isn’t) signed by one of these trusted CA certificates. This way, when a website provides its certificate, the browser can look at the signing key and know with a high degree of certainty that the website is what it says it is.
An intermediate certificate is a “delegate” subsidiary of a CA cert. It can be used as a proxy to its parent CA cert to sign other generated certs. So even if a website (or a man-in-the-middle) provides what appears to be a very secure cert with strong encryption, it may have been signed by a “broken” insecure intermediate cert. The browser, of course, doesn’t know - or care - about how insecure the the intermediate cert is - the browser has already implicitly trusted it. There fore, the browser has no way of knowing or alerting the user that their communication with the website has been compromised by someone pretending to be another website.
… Eight? Eight???
Four… Fucking… Pixels?
The working hypothesis is that this was some sort of debug or test key that was never meant to be used in production, being used in production.
I’m honestly skeptical about even this. I tried to generate an 8 bit key and got
rsa_gen_set_params:key size too small.And like, you need to go deliberately out of your way to not use OpenSSL.
They were proper 384bit certs, just the upper 376 bits were 0 in all the listed certs. So it’s different to setting the key size in OpenSSL, and they were most likely rolling their own crypto.
https://www.youtube.com/watch?v=87H6m2v4zNs
Not possible.