Database of Private SSL Keys Published

Trailrunner7 writes "A new project has produced a large and growing list of the private SSL keys that are hard-coded into many embedded devices, such as consumer home routers. The LittleBlackBox Project comprises a list of more than 2,000 private keys right now, each of which can be associated with the public key of a given router, making it a simple matter for an attacker to decrypt the traffic passing through the device. Published by a group called /dev/ttyS0, the LittleBlackBox database of private keys gives users the ability to find the key for a specific router in several different ways, including by searching for a known public key, looking up a device's model name, manufacturer or firmware version or even giving it a network capture, from which the program will extract the device's public certificate and then find the associated private SSL key."

Comments

Posted on Google Code

[Toe, The]

Here's Google's wikileaks-like test. The database is posted on Google Code. Will they remove it?

DD-WRT?

[Cheerio Boy]

So how does this affect things like dd-wrt, open-wrt, and tomato where custom firmware is in place?

Re:DD-WRT?

[blueg3]

DD-WRT, at least, installs with no SSL certificate in place and auto-generates one the first time it starts up.

This is really the correct solution, and a number of home routers actually do it.

Of course, there's a tradeoff. If you use a fixed certificate, you can have it legitimately signed. Then, if someone does a man-in-the-middle attack, you get the browser warning that they're using a self-signed certificate. Unless, of course, they're using the real fixed certificate. If, on the other hand, you use an autogenerated certificate, then the self-signed cert browser warning always appears (as you can only autogenerate self-signed certificates). The user learns that clicking through this warning is a necessary part of changing their router configuration. Then, any man-in-the-middle attack works, since anyone can make a self-signed certificate. (Yes, if they or the browser store the original cert and compare it to the new one, then this is no longer an issue.)

Realistically, I think this is a non-issue. If you're using home routers, they should only be configurable from the wired LAN, and only trusted people should be on that network.

VENONA

[schmidt349]

Encryption is only as strong as the idiots who implement it. The Soviets learned that the hard way during the early part of the Cold War, when they accidentally reused random one-time pad encryptors. That led to the NSA's VENONA project, and we decrypted a pretty good amount of Soviet diplomatic and spy traffic before they were tipped off.

Old problem

[plsuh]

Apple ran into something similar a long time ago for Mac OS X Server. The servermgrd daemon uses a self-signed SSL cert by default to secure communications with remote management tools. About four or five versions back the certificate was identical across all installations because it was contained in the installer package. Someone had to go down and show them that you could read all of the traffic by using sslsniff and the private key from your own copy of the installer. They changed to an individual, automatically generated certificate shortly thereafter.

--Paul

Re:what?

[cgenman]

More than likely, in a work situation, you'd be using hardware which generates a key pair upon initial configuration. The scenario above is more likely to apply to SOHO, or to consumer wireless hardware in the home

I'm vaguely shocked that any home routers would be using hardcoded private keys. That would be like every Schlage front door knob having identical keys. It's not just a mistake, it's extremely negligent security 101.