Robert Graham detailed on the Errata Security blog how he was able to get the private key of the Superfish certificate. I understand that attackers can now use this key to generate certificates of their own which will be signed by the Superfish CA.

Won’t the same attack work on other root certificates already on a computer? Why was the private key on the computer in the first place?

  • 6
    @Calimo It is there because it is needed to the proxy can generate certificate on the fly to perform it's MITM function and inspect traffic without any warning to the user.
    – Stephane
    Feb 20, 2015 at 8:48
  • 2
    @FiascoLabs It should be noted that pretty much every Israeli serves in the IDF, and a good programmer would frequently find themselves in a high-tech IDF position rather than on the ground in Gaza.
    – ceejayoz
    Feb 20, 2015 at 16:46
  • 1
    @ceejayoz - In a country that small with as many threats as they have to face, they don't have the luxury of running a volunteer army. BTW, the password to access the private cert is komodia. Expect exploits soon. Anything that uses Komodia software is vulnerable to the attack (Qustodio, Keep my Child Secure, etc.) Feb 20, 2015 at 16:57
  • 1
    For a hands on experiment, try playing with mitmproxy. It's a proxy server that makes it easy to man-in-the-middle your own TLS connections. Like Superfish, it generates certificates on the fly to match the site you're looking at, and it signs each cert with a key that is stored local to the proxy, e.g. ~/.mitmproxy/mitmproxy-ca.pem. If you trust MITM proxy's CA certificate, then all of the on-the-fly certificates that it signs will also be trusted. Feb 21, 2015 at 1:33
  • 3
    Because they are idiots, mostly. Sane programs that need to perform a MITM for legitimate purposes (e.g. mitmproxy) will generate a key pair which is unique to the host. Feb 21, 2015 at 10:09

4 Answers 4


Unless the Superfish malware has been installed on your system, (which it might if you bought a Lenovo machine,) you don't have to worry. This attack worked because the secret it revealed was necessary for the malware to hijack the data; it is not a part of how legitimate certificates are authenticated.

It helps to understand the relationships between a certificate, a public key, and a private key. A private key is a secret number used to sign messages with digital signatures (or to encrypt web traffic), and it has a matching public key that can be used to verify those signatures. A certificate is a public document that contains a public key; web site owners put their public keys onto certificates and send them to companies called Certificate Authorities (CAs) who digitally sign them to prove their certificates are genuine. The digital signatures ensure the document has not been changed, assuring you the public key it contains is the genuine key of the site you're visiting.

CAs are companies everyone agrees to trust to only sign certificates from legitimate sources. They also have a private and public key pair. They keep the private key very secret, locked in a secure cryptographic device called a Hardware Security Module (HSM) and they restrict access to it so it can only be used to sign a customer's certificate when the customer generates a new key. But in order to be useful, everyone on the web needs to know their public keys. So these CAs put their own public key on a special certificate and sign it with their own private key ("self-signing"). They then send these self-signed "root certificates" to the browser vendors and OS vendors, who include them with their products. A real CA would never, ever, send out their private keys!

The trusted authority root certificates are the documents that validate all the certificates of all the connections your computer makes. Thus, your computer has to trust them. This malware is installing an untrustworthy certificate in a position of ultimate trust, compromising the security of the machine by allowing anyone who knows this key to forge a certificate for any site, hiding evidence of their tampering.

The malware abuses its position by generating phony public and private keys for every site you visit; after you connect it injects its payload into the web site's page. In order for your browser to trust these phony keys and not give you warnings, the malware generates a forged certificate that tricks your browser into believing the keys are legitimate. But like any certificate, the forgery needs to be signed by a trusted CA. To sign, the malware needs a public and private key, just like a real CA. Because the phony CA is forging these certificates right inside your computer, the private key needs to be inside your computer as well. It's impossible to keep such things secret from the owner of the computer, but they tried by taking some rudimentary steps to hide it. The blog you linked to described how he uncovered the secret.

No legitimate certificate authority would ever allow their private key to be leaked, much less send it out to a bunch of random computer owners. There was a case where a certificate authority had their secret key leaked; their reputation was ruined and they went bankrupt in a month. Since your computer doesn't contain the private keys of the legitimate certificate authorities, there is no secret for an attacker to crack.

  • 7
    It should be impossible for a legitimate CA's private keys to be leaked. They're stored in HSMs and the roots are offline. When CAs are compromised, usually some of their servers are broken into and convinced to issue fraudulent certificates; the private keys themselves aren't exposed. Feb 20, 2015 at 11:19
  • 7
    @MattNordhoff, yes, it certainly should be impossible, however, DigiNotar is the poster child example of a company that did not take such care, and it was leaked, and every browser maker in the world and every OS in the world pulled the DigiNotar certificates from their systems immediately; DigiNotar collapsed within the month. See en.wikipedia.org/wiki/DigiNotar for more on the story. Feb 20, 2015 at 15:36
  • Has the certificate involved been revoked yet? Feb 22, 2015 at 4:41
  • 1
    @LorenPechtel, CRLs are typically hosted by the root CA, and signed by the root CA that issued it. The Superfish certificate is a self signed root certificate, and is itself the trusted issuer. It has no host OU in the issuer field. It has no CRL distribution point OID. It doesn't give your browser enough of the information it needs to even find out if it should be revoked. I think a viable defense will be for browser makers to support some kind of blacklist of bad root CAs, and to eradicate them through normal application updates, but that's a really slow process. Feb 22, 2015 at 6:39
  • "Unless you have a Lenovo with the Superfish malware, you don't have to worry." I came to know about this only because I randomly check HN. On the other hand there are atleast thousands of users who have no idea that their security is somewhat compromised as they haven't seen that news ( including my parents , who have no idea what I was saying or doing when I was removing that certificate via Lenovo removal tool). Feb 22, 2015 at 7:42

Because of how Superfish works, the certificate and its private key must be easily extractable.

Superfish creates signed certificates on the fly for the network connections it intercepts, without contacting a central server. In order to do this, the private key for the Superfish CA must be embedded in the software in an easy-to-use form. Now, they didn't need to make it a plaintext .pem file, but even the best security wouldn't have slowed down a serious reverse-engineering effort by more than a day or two.

You can't share a secret with the whole world and not expect anyone to find it. Real certificate authorities do a much better job of protecting their private key, by ensuring that it never leaves their certificate-signing computer.

  • 1
    Avast does something similar, but I think they use a different key for every installation
    – bobby
    Feb 20, 2015 at 5:18
  • 1
    Certainly the certificate must be easily extractable. However, does the private key need to be easily extractable?
    – user49075
    Feb 20, 2015 at 5:21
  • 8
    @RickyDemer, yes. You can't sign newly-generated site certificates without the CA private key.
    – Mark
    Feb 20, 2015 at 5:24
  • 1
    You may want to put that into your answer's initial sentence.
    – user49075
    Feb 20, 2015 at 5:25
  • 21
    The main issue with private key extraction is the use of the same root certificate on each install. It should be autogenerated (Fiddler does it) so the private key is specific to your computer.
    – Guillaume
    Feb 20, 2015 at 8:36

If you follow best practices when it comes to protecting private keys of root certificates it most certainly would not have been that easy.

If I understand Robert's blog correctly the password that protected the private key was embedded as a string in the adware binaries that shipped with the laptops. This is like shipping your safe together with your key obscurely taped to the bottom of the safe. Not a good idea! The password was also not very strong, meaning that even if it wasn't embedded in the adware for anyone to see, a determined person with knowledge and resources could be able to crack it in a reasonable amount of time.

The password to extract the private key was most likely embedded in the adware to enable the adware to decrypt traffic signed by the Superfish root cert on the fly to inject the advertising markup that the user would finally see on the web page.

This would never be the case with responsible Certificate Authorities and I'm fairly sure a CA needs to comply to certain standards, or even laws, that would prohibit them from doing such a thing.

If it was that easy to get the private keys of all root certificates PKI would have served no purpose and protect absolutely noting.

  • Embedded as a string, hmm, so doing a strings search on the binaries would show it? I think the key was taped to the front of the safe in plain sight then. Feb 20, 2015 at 6:19
  • Indeed, although in "their" defense, the binaries were obfuscated (fairly poorly) by packing them...
    – ilikebeets
    Feb 20, 2015 at 6:28
  • @FiascoLabs, yes, exactly. Reverse engineers unpacked the binary, ran strings on it, and used that output as the dictionary to attack the private key's password.
    – Foo Bar
    Feb 20, 2015 at 12:42
  • "Best practices" of protecting CA root private keys includes locking them in an HSM and requiring three-part smart card secret sharing schemes to access or alter them. This was a just a secret key baked into the malware in order to forge CA signatures on the fly; malware certainly couldn't install a hardware module to protect the secret bits! Feb 20, 2015 at 19:44
  • @JohnDeters: The root private keys are protected that well, perhaps, but the private keys for intermediate certificates, which are actually used for signing new SSL certificates, are only as secure as the CA server software, and due to trust delegation, are just about as powerful as the root keys.
    – Ben Voigt
    Feb 20, 2015 at 20:50

Superfish acts as a Man In The Middle. It dynamically generates keys which your browser trusts for domains you visit. To generate those keys it needs the private certificate, and while more obfuscation is possible, in the end it can't conceal that key.

What could be done though is to generate a unique key pair for the Certificate pair on each computer where the software is installed. This would mean that extracting the key used for the Root CA installed on one computer would not provide access to the communications of another computer with the software installed. This is not exactly rocket science, and it's inexcusable that Komodia don't do it.

I'd like to know whether other companies doing this sort of MITM are issuing unique keys. E.g. locally I've found certificates for "Skype Click to Call" and "avast! WEb/Mail Shield", which presumably function in a similar way. I've verified that if I visit https://www.google.com/ my browser sees a certificate signed by the avast key.

  • Actually Avast isn't as bad as it both uses unique keys and verifies the validity of the server cert from the real HTTPS connection: security.stackexchange.com/questions/82285/…
    – huyz
    Feb 23, 2015 at 6:54
  • Any info on Skype Click to Call?
    – mc0e
    Feb 23, 2015 at 19:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .