One of the simplest principles of cryptography is that the secret keys which are used for encryption must be kept, well, secret. Exposing the key to anyone other than the intended recipient of the message can pretty obviously lead to a compromise of the encrypted data. So, for example, hardcoding a secret key into a firmware image is unlikely to lead to secure communications using that key. Unfortunately, networking device makers—and the creators of free software firmware replacements for those devices—seem to have missed, or ignored, this basic principle.

The problem stems from the SSL keys that are installed into the firmware images for the devices. In many cases, those keys—including the supposedly private key—are generated when the image is built and then flashed into hundreds or thousands of different devices. If one can get access to the private SSL key, traffic encrypted with it (which might include HTTPS or VPN traffic) can be trivially decrypted. As the announcement of the LittleBlackBox project describes, it is, unfortunately, rather easy to obtain said keys; in fact the project provides a database of thousands of private keys indexed by their public key.

In practical terms, that means an attacker can access a vulnerable SSL-protected web site, retrieve the public key certificate, look up the corresponding private key, and decrypt any traffic that is sent or received by the web site. An attacker could also do a man-in-the-middle attack by pretending to be the site in question, as there would be no way to determine that the spoofer wasn't the real site. In order to do either of those things, though, the attacker must get access to the encrypted data stream.

Open, or weakly secured, wireless networks are the easiest way for an attacker to get that access—or to become a man in the middle. As the concerns over Firesheep have shown, there is still a lot of traffic that travels unencrypted over wireless networks. Ironically, HTTPS is touted as a solution to that problem, but that only works if the private keys are kept secret. For the web applications targeted by Firesheep, that is not likely to be a problem, as their private keys were presumably generated individually and kept safe. But for others who might be using wireless networks to configure their routers—or connect to another network via VPN—it could be a much bigger problem.

While reconfiguring your router from the local coffee shop may be a pretty rare event, even having the HTTPS-enabled web server available over the internet gives an attacker the ability to retrieve the public key, which can then be looked up in the LittleBlackBox database. If that SSL key is used for other things like VPN—something that might well be used at an open WiFi hotspot—that traffic is at risk as well. The right solution seems clear: don't supply default "secrets". In some ways, this problem parallels the longstanding, but hopefully improving, situation with default administrative passwords.

Device manufacturers and firmware projects should not be shipping SSL keys and either generate them at "first boot" or provide a way for users to generate and upload their own keys. There are a few different reasons that it isn't always done that way today, from concerns over devices having enough entropy to generate a random key to the amount of time it can take to generate a key on a slow CPU, but those reasons aren't really offset by the damage that could be done. Users who enable HTTPS access to their devices do so with the idea that it will be more secure, and can be used in places where unencrypted communication doesn't make sense.

There are also hurdles to overcome in either creating a key for each device (and/or firmware image) or providing instructions for users but, once again, that really doesn't help users that are relying on the device for secure communications. While some in the DD-WRT community don't see it as a big problem it is likely more serious than they are crediting. It would make far more sense to disable HTTPS access entirely—perhaps requiring a manual process to generate keys and enable that access—than it does to provide well-known keys.

While the problem highlighted by LittleBlackBox isn't earth-shattering, it does show the sometimes cavalier attitude towards security that is shown by some in the embedded device arena. When you are selling (or providing) a device or firmware that is meant to secure someone's network, it makes sense to proceed carefully. And to keep secrets, secret.