Breaking SSL on Embedded Devices

No, this is not some new SSL vulnerability. In fact, it’s a really old vulnerability, as old as cryptography itself: keep your secret keys secret.

A lot of embedded devices provide HTTPS support so that administrators can administer the devices securely over untrusted networks. Some devices, such as SSL VPNs, center their entire functionality around SSL encryption. OK, well SSL isn’t perfect, but it’s still the de facto standard for Web-based encryption. So far, so good.

Here’s where it gets fun: many of these devices use hard-coded SSL keys that are baked into the firmware. That means that if Alice and Bob are both using the same router with the same firmware version, then both of their routers have the same SSL keys. All Eve needs to do in order to decrypt their traffic is to download the firmware from the vendor’s Web site and extract the SSL private key from the firmware image.

However, there are some practical limitations to this attack. If Eve doesn’t know what router or firmware version Alice and Bob are using, it will be difficult to impossible for her to identify which firmware image to extract the SSL keys from. A good example of this is DD-WRT. There are several versions of DD-WRT available for each router supported by DD-WRT. And for each of those versions, there are several different “flavors”: micro, standard, VPN, etc. Even if Eve knows that Alice and Bob are running DD-WRT, that’s a lot of firmware images to work through. This becomes even more difficult when dealing with vendors whose firmware is not as standardized between releases.

That’s where the LittleBlackBox project comes in. It has a database of known default SSL private keys and associates those keys with their corresponding public keys. All Eve has to do is look up the public key of Alice and Bob’s router in the database, and she instantly has the rotuer’s private key.

She can also look up keys based on the device model, vendor, or firmware versions.

She can feed it a network capture file of Alice and Bob’s router traffic and it will find the public certificate exchange and automatically look up the corresponding private key for her.

She can give it the host name or IP address of Alice and Bob’s router, and it will retrieve the public certificate from the router and look up the corresponding private key for her.

She can…well, you get the picture. Of course, the keys have to be in the database in order for all this to work. Currently LittleBlackBox has over 2,000 unique private SSL keys and growing, primarily belonging to routers and VPNs. Although at the moment the vast majority of the keys belong to various DD-WRT firmware, there are keys from Cisco, Linksys, D-Link and Netgear as well.

LittleBlackBox can be downloaded here. If you have default SSL keys that are not currently in the database and wish to add them to the project, please download the latest version of LittleBlackBox and follow the submission guidelines in the docs/FAQ page.

Tagged , , , . Bookmark the permalink.

42 Responses to Breaking SSL on Embedded Devices

  1. Pingback: Tweets that mention /dev/ttyS0 » Blog Archive » Breaking SSL on Embedded Devices --

  2. Fab says:

    I don’t get it.

    Devices (just like desktop browsers) ship with the thrusted third parties certificates…but those only contain a public key that can be used to check the validity of the new SSL connection’s certificate….

    For example, if I connect to, google’s certificate is verified with the embedded third parties’s certificate….but at no time we have access to the private key of anyone….

  3. Craig says:


    That is correct, Google won’t give you their private key. But Google has to have their private key stored somewhere, just like embedded devices have to have their own private key stored somewhere on the device if they want to provide an HTTPS service.

    What we’ve done is taken a bunch of firmware images for various devices, extracted the file system from those firmware images and located the private key that the devices use for their HTTPS server. Since these are hard-coded private keys, everyone running that particular firmware has the same private key and we can now decrypt HTTPS connections to those devices.

    LittleBlackBox keeps a database of known private SSL keys and can match them to public certificates. So you can point it at a host, and it will get the host’s certificate and see if it has the corresponding private key in its database.

  4. Andrew says:

    I’m not following. Doesn’t SSL use the diffie-hellman key exchange, meaning there aren’t any stored private keys?

    Edit: I confused private key with shared secret key. DH does involve private keys, and if you are able to obtain both parties private keys, you can compute their shared secret key.

    Edit2: The attack is for SSL using RSA key exchange.

  5. Eric says:

    tried building it on my mac (snow leopard). she fails with “ld: library not found for -lcrt0.o”. after a quick google search didn’t reveal any obvious solutions, i’ve decided to avoid this particular rabbit hole.

  6. Keven says:

    Oh, that’s a good question. You would think that could have the device generate new keys on it’s own, even if all it did was to replace it’s current key every once in a while.

  7. honestly I couldnt agree more. Very well said dude, and merry xmas

  8. Hi, awesome post. Love very much. Thank you.

  9. Andy says:

    Is there a list of routers whose SSL keys have been decoded? I’m guessing a firmware update won’t fix this problem…I wonder how the industry will react to this.

  10. Pingback: Database of Network Device Private Keys Published | EconoLan

  11. Man, this is ridiculous: why not just writing a (2 line at most) script which checks if there is any key on the device and if not, it creates a (private, public) pair?


    But what are they thinking about?

  12. Pingback: Group Publishes Database of Embedded Private SSL Keys –

  13. Michael Taylor says:

    @Pedro: Because if the firmware image is mounted *read-only*, then the system cannot write the private key back to the image (storage, i.e. disk, EEPROM, Flash, etc.).

    Those vulnerable device firmwares that use OpenSSL (and gnuTLS) should be able to use Anonymous Diffie-Hellman (ANON-DH) would also be possible, but does not protect against from (active) man-in-the-middle (MITM) attacks, being slightly better than this situation. I don’t know if SRP (Secure Remote Password) based TLS key exchange would be suitable or not as I am not very familiar with it.

  14. @Michael Taylor:
    if you can configure a device, there is some non-readonly space in that device and the firmware image knows where it is and how to mount it and read onto it. So, that is not an excuse: if configurable, then manageable.

  15. Awsome post as well as to the point. I not really know if this is really the best place to question but do you people have any ideas on where exactly to employ several professional internet writers? Thank you!

  16. AH says:

    As a result of this, maybe DD-WRT will take action as a community and provide builds in the future where we can generate keys unique to the device, writing them to rw space on the device. Even providing a symlink to a default key that sits in the rw space would be useful.

  17. Kaz says:

    Is there any vulnerability in the WRT54GL routers? The stock firmware has the annoying property of regenerating the SSL cert whenever it is rebooted! But is the private half of that different?

    I use Tomato firmware. As far as I remember, that generates the key one time and then persists it.

  18. TE says:

    One challenge of generating a per device secret key is how to generate the random numbers to generate the key. Most of these devices don’t have any source of entropy. Perhaps they’ll use

  19. Kaz says:

    TE said “Most of these devices don’t have any source of entropy.”

    As soon as they are plugged into an network, there is inter-frame jitter that can be sampled.

    The Wi-Fi network can undoubtedly be used to extract some entropy bits, too.

  20. Mark says:

    Eric, take out the static option from the Makefile and all will be well.

  21. Daniel says:

    To poster Eric and other Mac users who get the “ld: library not found for -lcrt0.o” linker error when attempting to compile: try removing the -static flag from the Makefile.

  22. Pingback: Potential Vulnerability of SSL on Devices « Mocana DeviceLine Blog

  23. Pingback: JayMill's Netsec » Blog Archive » why LittleBlackBox isn’t that cool

  24. Pingback: Using default private keys to decrypt SSL streams « Laboratory B

  25. Craig says:


    Regarding DD-WRT, they are unlikely to fix it. They have stated that they “can’t imagine any situation where an attacker would be able to capture the encrypted traffic” (


    Yes, the fix is a two line script – once you cross-compile openssl so that you can generate the key, then completely change the firmware so that you have a writable partition to save the certificates to, then configure that partition to mount somewhere on the file system (more firmware modifications!). So while it is something that should have been done in the first place, it’s not always an easy fix.


    I haven’t tested the WRT54GL or Tomato, but based on what you’ve told me, they are probably not affected.

    To everyone having build problems on Macs, the fixes posted here should work. We’ve posted a bug report and this will be fixed in the next release.

  26. Lefty says:

    My experience is with not-completely-current Linksys devices (WRT54G et al), but they all have a chunk of flash memory that is writeable by the firmware that is used to store configuration already. How else would the devices persist their configuration across reboot?

    DD-WRT uses this space (if configured so) to store DHCP leases.

    It would be trivial to store the generated private and public keys in this configuration area. Generate them on first boot, have an option in the web interface for the router to purge them. Done.

    There really is no excuse whatsoever for baking the keys into the firmware itself.

  27. Craig says:


    Pretty much all routers have NVRAM storage for storing configuration data, and the certificates could be stored here (I think this is how Tomato does it??). But the firmware may still have to be modified to give more storage area to NVRAM for storing the certs (which may mean changing the firmware layout), plus extracting them to disk at run time, plus building in openssl or equivalent to build the certs in the first place.

    As a developer I can tell you that putting those changes in place, stress testing the changes to make sure they don’t break anything, putting it through QA and then re-doing that process for every single router is not going to be a trivial task. Not to mention that getting new firmware pushed out to the vendor site so that maybe 1% of the vendor’s customers can download it is not going to be seen as cost effective by management.

    Again, I agree that this is something that should have been done in the first place, but I’m not holding my breath for updates from vendors any time soon.

  28. Pingback: Is Your Router Secure? « Rich's Random Walks

  29. Pingback: Datenbank mit SSL Private Keys veröffentlicht | PHUTiLiTY

  30. AMcguinn says:

    The secure way to do this is for the device to create a ssl key pair itself — but then the user needs to extract the public key and configure their browser or other client software to accept it, or else they will get errors from their browser.

    The issue here is that the device manufacturers have preferred to give users the convenience of ssl with keys that have certificates signed by a CA, so they will be automatically accepted by browsers, rather than the actual security of having a truly secret key, which the users have to configure their browser to accept.

  31. Seo Services says:

    I love your blog.. very nice colors & theme. Did you create this website yourself or did you hire someone to do it for you? Plz reply back as I’m looking to create my own blog and would like to know wheere u got this from. thanks

  32. AMcguinn says:

    Actually, ignore my last comment, I’m obviously talking rubbish: there’s no way the certs can be CA-signed, because there’s no well-defined name for them to use. Craig’s explanation must be correct; they just avoided the complexity of generating and storing certs.

  33. Preserve doing work ,good work!

  34. Someone Notsoclose says:

    None of the certs I inspected (approx 10) in the SQLite-Archive have a domain as CN. How should anyone use these certs for SSL?

  35. Someone Notsoclose says:

    OK, to answer my own question: The only sensible reason would be that these certs are only placeholder certs, and the router generates new certs (always with the same key pair), as someone else mentioned above.

    i.e. the certs are not CA-signed, and a man-in-the-middle-attack (MITM) would be possibe anyways; but with this keypair database, you don’t have to be MITM to listen in.

  36. Pingback: Group Publishes Database of Embedded Private SSL Keys

  37. Pingback: LittleBlackBox v0.1.1: Breaking SSL on Embedded Devices

  38. Pingback: links for 2010-12-21 « Where Is All This Leading To?

  39. Craig says:


    I’m not sure what you mean when you say “generates new certs (always with the same key pair)”. A key pair is the combination of the public key and the private key (i.e., a pair of keys). If they are using the same key pair then they aren’t generating any new certs.

    Also, just because an SSL cert is self-signed doesn’t mean that MITM attacks are always possible. An administrator can tell his/her browser to trust the router’s self-signed certificate so that they won’t get SSL errors unless someone tries a MITM attack.

  40. Pingback: Database of Network Device Private Keys Published | Computer Security Articles

  41. Pingback: Library of embeded devices’ hard-wired SSL keys « Eikonal Blog

  42. Pingback: Open Source Pixels » Breaking SSL on Embedded Devices (/dev/ttyS0)