Lenovo and the Superfish Scam
I’m a bit late to the scene here, but I think it’s still worth making a stab at this. Also, this is being written on an airplane, where I am travelling home from San Francisco to NY with a case of bronchitis. So I am not exactly at my best.
Lenovo, one of the largest makers of windows-based laptops, sold out its customers as part of one of the worst deliberate violations of computer security I’ve ever seen, by shipping a piece of software called Superfish pre-installed on its computers. Superfish is, with absolutely no exaggeration, one of the most serious, unethical, despicable things I’ve seen in quite a lot time. It’s appalling.
So what is it, and what’s the big deal?
We need to start with some background, and talk a bit about how secure connections work on the internet.
Every time that you visit a website with a secure connection (a URL that starts with https), you’re using a protocol called TLS (formerly SSL). TLS is designed to do two things:
- Ensure that you are talking to who you think you’re talking to.
- Ensure that no one but you and the person you wanted to talk to can actually see what you’re saying.
The way that it does both of those is based on encryption. Every time you create a secure connect to a website, you’re exchanging credentials with the site to ensure that they’re who they say they are, and then based on those credentials, you establish an encryption key for the rest of your communication.
That connection-establishment process is the critical bit. You need to get some information that allows you to trust them to be who they claim to be. The security and integrity of everything that happens over the connection depends on the truth and integrity of that initial piece of identity verification.
The identity verification piece of TLS is built using public key cryptography, as part of a standard infrastructure for key maintenance and verification called X.509.
I’ve written about public key crypto before – see here. The basic idea behind public key crypto is that you’ve got two keys, called thepublicandprivatekeys. Anything which is encrypted with the public key can only be decrypted with the private key; anything which is encrypted with the private key can only be decrypted using the public key. Your public key is available to anyone who wants it; no one but you has access to your private key.
If you receive a message from me, and you can decrypt it with my public key, then you know, without a doubt, that you can be sure that I’m the one who encrypted it. Only my private key could have encrypted a message that could then be decrypted with my public key.
For that to work, though, there’s one thing that you need to be sure of: you need to be absolutely sure that the public key that you’ve got is reallymypublic key. If some clever person managed to somehow give you a different key, and convince you that it’s mine, then they can send you messages, and they’ll look exactly as if they came from me. If I handed you my public key on a USB thumbdrive, then you’re sure that the key came from me – but if you received it online, haw can you be sure that it was really me that gave it to you? Maybe someone switched it along the way?
In X.509, we use an idea of delegated trust. That is, we have some small collection of fundamental trusted authorities. Those authorities can issue public/private key pairs, so when someone need a public key, they can go to them and ask for it, and they’ll create one. The authority gives them acertificate , which is a copy of the new public key encrypted by the authority usingtheirprivate key.
Now, when someone connects to a website, the target site can state who they are by sending a copy of the certificate. The client site recieves the certificate, decrypts it using the authorities public key, and then starts using that public key to encrypt their communications.
If the two sides can keep talking, then the client knows who it’s talking to. It got a public key, and it’s using that public key to talk to the server; so the server couldn’t decrypt the communication unless it had the public key; and it trusts that that it got the right public key, because it was encrypted with the private key of the certificate authority.
This is great as far as it goes, but it leaves us with a single certificate authority (or, at best, a
small group). With billions of human users, and possibly trillions of networked devices, having a single authority isn’t manageable. They simple can’t produce enough keys for everyone. So we need to use our trust in the certificate authority to expand the pool of trust. We can do that by saying that if the certificate authority can declare that a particular entity is trustworthy, then we can usethatentity itself as a verifier. So now we’ve taken a single trusted authority, and expanded that trust to a collection of places. Each ofthosenewly trusted entities can now also issue new keys, and can certify their validity, by showingtheircertificate, plus the new encrypted public key. In general, anyone can issue a public key – and we can check its validity by looking at the chain of authorities that verified it, up to the root authority.
There’s a catch to this though: the base certificate providers. If you can trust them, then everything works: if you’ve got a certificate chain, you can use it to verify the identity of the party you’re talking to. But if there’s any question about the validity of the root certificate provider, if there’s any question whether or not you have the correct, valid public key for that provider, then you’re completely hosed. Ultimately, there’s some piece of seed information which you have to start off with. You need to accept the validity of an initial certificate authority based on some other mechanism. The people who sold you your computer, or the people who built your web browser, generally install aroot certificate– basically the public key for a trusted certificate authority.
If that root certificate isn’t trustworthy, thennothingthat results from it can be trusted. The untrustworthy root certificate can be used by an unscrupulous person to create new certificates allowing them to masquerade as anything that they want.
In particular, an untrustworthy root certificate it makes it easy to perform aman-in-the-middleattack. Suppose you want to talk to your bank, and somehow Joe Schmoe has planted a bad root certificate on your computer:
- You try to connect to Bank.
- Joe intercepts the request. He accepts your connection request, pretending to be the bank. Using his fake root certificate, he sends you a certificate claiming to be the bank.
- Now, you’re connected to Joe, believing that you’re connected to the bank. You try to log in to your account, sending your username and password.
- Joe receives your request, connects to the bank, passing on your request.
- Joe logs in to the bank on your behalf. The bank returns its successful login screen, showing your account numbers and balances.
- Joe copies the successful login screen from his connection to the bank to you.
- Every time that you send information to “the bank”, Joe decrypts it using his private key, and then sends it on to the bank masquerading as you. Similarly, when the bank sends something to you, he decrypts it using the banks public key, and then encrypts it with his his private key to send it to you.
- You now believe that you are connected to the bank over a secure connection. Everything that you do looks exactly as if you’re connected to the bank over a security encrypted link.
- Joe now has your login information, and control of your bank accounts.
In the Lenovo fiasco, Lenovo installed a system called Superfish, which deliberately installs a bad root certificate, and then uses that root certificate to create man-in-the-middle attacks onevery secure connectionever made with the computer.
Why does it do that? Purportedly for ad retargeting: it uses its man-in-the-middle to decrypt supposedly secure connections so that it can replace ads in the pages that you view. That way, Lenovo and Superfish get advertising money for the pages you view, instead of the page-owners.
It’s spectacularly despicable. It’s fundamentally compromisingeverythingyou do with your computer. It’s doing it in a way that you can’t detect. And it’s doing it all in a sleazy attempt to steal advertising money.
Based on this, I’ve got two pieces of advice:
- Don’teverbuy a Lenovo computer. Never, ever, ever. A company that would evenconsiderinstalling something like this isn’t a company that you can ever trust.
- If you have a Lenovo computer already, get rid of it. You could reformat your disks and install a fresh untainted copy of your operating system – but if your hardware manufacturer is a sleezy as Lenovo has demonstrated themselves to be, then there’s no reason to believe that that’s going to be sufficient.
This is, by far, the worst thing that I’ve ever seen a computer manufacturer do. They deserve to be run out of business for this.