It’s a bit surprising, actually, how easy many organizations make it for cyber criminals to misuse their encryption. Some may even leave private keys out for hackers, like a plate of cookies for Santa.
Recently, security researcher Hanno Böck was able to obtain private keys for at least 90 valid web page certificates. And when private keys find their way onto a web server, they can no longer be considered private. The danger is that once these not-so-private keys are accessed by unauthorized parties, they can be used in a man-in-the-middle attack to read and manipulate data. That is, unless organizations detect the key misuse first.
You would think that organizations would treat private keys with kid gloves. After all, they unlock the encryption that safeguards an organization’s most important information. Yet, it seems that many organizations still haven’t fully realized the implications of a private key breach. And this leads to some pretty sloppy behavior. Böck observed that “Many people are accidentally publishing their private keys. Sometimes they are released as part of applications, in Github repositories or with common filenames on web servers.”
When private keys are compromised, they must be revoked by the issuing certificate authority to minimize potential exposure. Böck points out that according to the CA Browser Forum Baseline Requirements, certificate authorities are required to revoke a compromised key within 24 hours of notification (Section 18.104.22.168 in the current Baseline Requirements 1.4.8). But that may not always happen in within the times prescribed.
A particularly odd case occurred recently with a certificate issued by a leading certificate authority. According to Böck, “They revoked the certificate shortly after it had been reported, but then issued shortly after that a new certificate with the same private key. After we reported this to Comodo we learned that the same problem occurred with a second certificate. In both cases Comodo revoked these new certificates immediately.”
This caused Böck to ponder how thoroughly certificate authorities actually check key compromises. His initial assumption was that “Obviously one would expect that they cryptographically verify that an exposed private key really is the private key belonging to a certificate.” But he wanted to test that premise.
First, he set about to forge a private key, which he would then use to try to trick leading certificate authorities into revoking certificates with a fake private key. Once that was accomplished, he reported the fake key as compromised—hidden among reports for several other legitimate key compromises that he had unearthed.
Here’s what Böck reported:
Symantec revoked a certificate based on a forged private key
Comodo didn’t fall for it. They answered Bock with a message that there was something wrong with this key.
Fully aware of the implications of this type of error, he was quick to point out that “No harm was done here, because the certificate was only issued for my own test domain. But I could’ve also faked private keys of other peoples' certificates. Very likely Symantec would have revoked them as well, causing downtimes for those sites. I even could’ve easily created a fake key belonging to Symantec’s own certificate.”
Laudably, Symantec took quick action to immediately uncover and correct faulty processes. They reassured customers that they “take these findings seriously and always appreciate opportunities to improve our CA operations.”
But the cold, hard reality is that this type of process error could happen to any certificate authority. To minimize any potential impact, organizations need to be prepared to manage all keys and certificates centrally and have the capabilities to take quick action if there is a process error that compromises security. After all, it’s the organizations who stand to lose the most from a key compromise, so they need to be prepared to monitor and remediate their own key and certificate security.
Do you have the protection you need to detect private key compromises or misuse?