We rely on public-key cryptography to authenticate software we download from the Internet, like software updates, some Web-based software, and many device drivers. When we try to install or run such software, the system may automatically check the signature and warn us if it is missing or suspect. The system checks the signature by referring to a public-key certificate associated with the vendor who signed the software.
So what happens if the public-key certificate is fraudulent?
For that matter, what makes a certificate fraudulent, and how would such a thing arise?
A certificate is fraudulent if the name it carries does not accurately reflect the person or entity that actually controls the associated public/private crypto keys. And yes, there have been several cases of fraudulent public-key certificates.
In public-key cryptography, we use the private
key to construct a digital signature. No one except the key's owner should be able to create a valid digital signature. We use the corresponding public
key to validate a signature. A public-key certificate reliably identifies the owner of a particular public/private key pair: if Bob signed the data, then anyone should be able to use Bob's public-key certificate to validate his signature.
So, how might someone falsify Bob's digital signature, or Microsoft's for that matter? Let us look at four cases:
- Attacker steals the private key
- Attacker tricks a Certificate Authority into issuing a fraudulent certificate
- Attacker creates a legitimate certificate with a misleading name
- Attacker creates a completely fraudulent certificate
Stolen private key
If an attacker makes a usable copy of the victim's private key, then the attacker can sign data on the victim's behalf. There is no way to distinguish between data signed by the attacker with the victim's key and data signed legitimately by the victim.
SSL-enabled web sites carry private keys so that they may process incoming SSL connections. If attackers can harvest all
files on a site, including administrative files, then they may retrieve the private key as well. This allows the attacker to clone the original site and masquerade as its legitimate owner.
The Stuxnet worm apparently makes use of stolen private keys. According to reports,
Stuxnet carries some digitally signed device drivers, apparently signed by either of two legitimate South Korean vendors. This suggests that the Stuxnet development team arranged to steal copies of the vendors' private keys, and now uses them to sign the Stuxnet software.
Tricked certificate authority
I know of exactly one published case of this. No doubt there are more, if only because there are so many public-key certificates out there. Mistakes must happen more often than we know.
In 2001, Verisign issued a certificate to Microsoft that carried Microsoft's name. According to information I saw at the time, the associated private key was in fact in possession of a Microsoft employee who left their employ at this same time. The ex-employee kept the private key. In theory, the ex-employee could have then placed a Microsoft signature on code and tricked Microsoft software into accepting it.
This was a mistake by Verisign. Statements at the time suggested that the ex-employee was familiar to the people at Verisign responsible for issuing certificates, and exploited this relationship to get the certificate issued without all the proper checks and paperwork. Arguably this was a social engineering attack that induced some violations of Verisign's procedures.
The incident was documented to some degree in a Microsoft security bulletin
. Microsoft actually patched its software to look for this particular certificate and refuse to use it. At the time, that was the most reliable way to prevent someone from being tricked into using that certificate.
Misleading certificate name
Many SSL vendors rely on a semi-automatic system to produce and sell an SSL certificate. For example, if a vendor offers SSL certificates and is also my domain registrar and web hosting service, then it's easy for the vendor to verify that I own the domain in the SSL certificate. If the name is misleading, like the notorious "paypai.com" site from a decade ago, this might not raise eyebrows in an automated system.
If my vendor registers the name "11bean.com" for me and I use it to build a spoof site that looks like llbean.com
, then an automated issuing system probably won't stop me. When a victim lands on my site instead of the legitimate "llbean.com" site, a less observant person might not notice the subtly different name. When a victim tries to close a sale, the browser accepts the SSL certificate. After all, the name in the certificate matches the site's name, even though it's not quite the name the user really wanted.
DISCLAIMER: As I write this in late 2010, the domain "11bean.com" goes to a domain parking page and not to any sort of legitimate or suspicious site. As far as I know, there are no L. L. Bean spoofing pages out there, but Bean's is as vulnerable to this as any other Internet vendor.
Completely bogus certificate
A completely bogus certificate is one that contains a wrong name and is not signed by a recognized certificate authority like Verisign. There is software bundled with most public-key software packages (like OpenSSL) that will create arbitrary certificates. The creator can sign the certificate either with the public key it contains (a "self signed" certificate) or with another public key. In either case, our browsers will complain about the certificate, since it wasn't signed by a "recognized" certificate authority.
If we download a software upgrade that's supposed to be signed, the original software contains the appropriate public keys for validating the signatures.These keys may be stored in certificates, and an upgrade may add new certificates. In this case, a public key already in place is used to authenticate any new certificates. As with the browser, the software won't accept a new certificate unless it is signed with the appropriate key previously provided by the vendor.