4.5 million web servers have private keys that are publicly known!

Late in 2015, we wrote about a survey by a European security consultancy called SEC Consult that looked at the cryptographic safety of the average web server.

The results were worrying: 3,200,000 publicly-visible web servers were using private keys that weren’t actually private.

In fact, they were already publicly known, and detectably so.

Let’s remind ourselves why that matters.

Regular encryption algorithms, such as the widely-used and highly-recommended AES, implement symmetric encryption.

This works just like the deadlock on your front door: you turn the key one way to lock, and you turn the same key in the other direction to unlock.

This sort of system is simple, effective and quick, but has two tricky disadvantages:

• If you want someone else to be able to unlock the door, you have to trust them with a copy of the key. There’s nothing to stop them losing it, or even from making illicit copies for other people.
• To send them a copy of the key in order to set up a secure communication channel, you have to have a secure channel already. Otherwise, you can’t get the key to them without the risk of it being copied along the way.

So, in the electronic world, symmetric encryption on its own is not much use for online commerce, because the whole idea is to handle orders and payments from new customers whom you’ve never met in person, and probably never will.

That’s where public-key cryptography, also called asymmetric encryption, comes into the equation.

Invented in the UK and then independently in the USA in the 1970s, asymmetric encryption relies on two keys: a public key that locks your data, and a corresponding private key that can unlock it.

You generate public and private keys in pairs, a process that is much slower than actually using either of the keys later on, but nevertheless takes only a few seconds on a modern computer.

The mathematics of asymmetric encryption is such that:

• You can’t decipher the original data using just the public key. Only the private key can do that.
• You can’t figure out the private key from the public key. Keys can only be generated together in pairs.

Private really does mean private

Done correctly, you really can make your public key public, whereupon everyone in the world can communicate securely with you, provided that you keep your private key private.

But if someone manages to get hold of your private key, they may be able to masquerade as you in many ways:

• By setting up an imposter web server that identifies itself as your official site.
• By digitally signing software so that it looks like an official release of yours.
• By logging into third-party servers and “proving” that they are you by identifying themselves using your private key.

So, nine months after SEC Consult’s report identifying 3,200,000 web servers with private keys that were already publicly known, you might think that the warning would have sunk in.

But this time round, they found that the count had gone up to 4,500,000 servers with private keys that simply weren’t private.

How do private keys become public?

One common reason for shared private keys is when a vendor sells a home networking product, such as a router, that has a private key burned into the router’s downloadable firmware.

In other words, the vendor generates a public/private key pair, as expected…

…but then shares it with every similar device that gets shipped.

For a while, no one may notice, but once the secret’s out, anyone can get the private key, possibly for hundreds of thousands of devices at the same time, simply by buying a device of their own and extracting the private key.

Or they may well be able to recover the private key by simply downloading the vendor’s latest firmware update file and extracting the key from there.

Sharing private keys in this way just doesn’t make sense. (If it did, they wouldn’t be called private keys.)

Each device needs its own private key, ideally one that’s generated, along with its matching public key, when the device is first deployed.

That way, the private key doesn’t even exist until the device is actually installed and prepared for use.

What to do?

We need to get collectively better at this, so we’ll repeat the advice we gave last time.

If you create firmware for embedded devices:

• Don’t share or re-use private keys. If you generate firmware files for each device, customise the keys in each firmware image and use it once only. If you generate keys when the device first starts up, don’t rely on “random” data sources that are likely to be the same on every router at first boot (e.g how long since the power came on, or how much memory is installed).
• Don’t enable remote administration by default.
• Don’t let users activate a new device until they have set all necessary passwords. In other words, get rid of default passwords and keys- every crook has a list of what they are.

If you use embedded devices:

• Set proper passwords before taking the device online.
• Only turn on remote administration when genuinely necessary. Also, consider two-factor authentication for external users, to reduce the risk posed by stolen passwords.
• Verify your remote access settings. Consider using a network diagnostic tool such as nmap. You may as well scan your own network for security mistakes. The crooks will!
• Re-generate cryptographic keys, if you can, as part of installing the device. This is a way to get rid of any low-quality keys inherited by default.