Imagine that you just checked into a hotel.
You’re in the lift on the way to your room, holding a key.
You get to your room; you wave, swipe or turn the key; and the door opens.
Assuming the door wouldn’t open until you presented the key, it certainly feels like security of a sort, doesn’t it?
But what if your key isn’t unique?
What if your key opens every other door in the hotel (or, for that matter, if every other key opens your door)?
How would you ever know, just for starters?
You could make a habit of trying your key on a random selection of doors every time you use a hotel, but even that might not help, because:
- You’ll probably get into trouble, especially if you do manage to open someone else’s door unexpectedly.
- Some hotels only let you access your own floor, so you’ll never know if your key might open doors on other floors.
- Your key might be fine until the hotel next reboots its lock control server.
- Other keys might open your door, even if your key doesn’t open other people’s.
In short, you have to assume that the hotel’s key management software (or its locksmith service) knows what it’s doing.
From hotel keys to router keys
Now imagine you just finished setting up a secure router at home or at work, taking it out of its box, putting it through its first-time setup, and connecting it to the network.
You might similarly assume that tasks related to key setup, such as generating public-private keypairs, were done correctly.
In fact, history suggests that key creation tasks sometimes aren’t done well at all, especially on small, cheap routers where generating pseudorandom numbers is hard to do well because there just aren’t many sources of unpredictable data inside the router’s limited hardware.
If the clock always sets itself, say, to 01:00 on 01 January 1991, every time you power up, then randomisation routines that rely on the time of day to mix things up at the outset are not going to get very mixed up at all.
But what if conventional checks showed you that your router’s cryptographic keys looked OK, or at least that on the 10 routers you just deployed, all the keys were dfferent?
You’d probably be reasonably happy that their “room keys” wouldn’t open each other’s doors.
Things are not always what they seem
Researchers at Royal Holloway, a UK institution already well-known for its cryptographic work, found that your happiness might be misplaced.
What’s more, they found out sort-of by mistake, though we don’t mean to denigrate their work by putting it that way.
They decided to use a fast network scanner called Zmap to check up on the FREAK vulnerability, and measure how many servers still needed patching.
FREAK, of course, is a recently-reported security bug that allows an attacker to trick each end of a TLS (secure) internet connection into dropping back to a level of encryption that is rather easy to break these days.
FREAK involves going back to 512-bit RSA keys, a size that was already successfully cracked by civilian researchers with unexceptional equipment back in 1999.
And Zmap is a special type of internet scanning tool that can, in theory, make a probe to almost every active computer on the internet within one hour.
Just the combination for a Friday afternoon experiment in a cryptography lab!
The team quickly measured that just under 10% of servers on the internet were still vulnerable to FREAK.
Useful information.
A little disappointing, perhaps, because by now you might expect the proportion to be much lower; but also somewhat encouraging, because the original FREAK report, released two weeks ago, put the figure at 26%.
If that was all the researchers had found, you might already consider this objective measurement to be “a good return on investment for a Friday afternoon’s work,” to borrow the authors’ own words.
Bugs within bugs
But there’s more.
While they were about it, the researchers noticed that a surprising number of servers that were FREAKable presented exactly the same 512-bit RSA key when they were tricked into falling back to old-style encryption.
As it happens, many servers cheat a little bit with RSA keys, because generating a public-private keypair is a lot slower than merely using that keypair for encryption and decryption.
So, instead of generating a unique keypair for every connection, they only generate a keypair when the server starts up, and keep on using it until the server is restarted.
In theory, someone who grabs your private key could then decrypt every connection that was protected with it, which increases the risk compared to creating a new keypair every time.
But the idea is that if a crook gets into your server and acquires your temporary private key, then all security bets are off anyway, so this can be considered an acceptable risk.
What is definitely not an acceptable risk is sharing keypairs with other servers in other locations belonging to other organisations.
Otherwise, if any one of the others were hacked (or maliciously revealed the private key to cybercrooks), then you’d fall along with them.
The key that opens many doors
In the Royal Holloway paper, the authors found that one particular 512-bit RSA key, exposed during FREAK testing, was repeated a whopping 28,394 times.
That’s an awfully big hotel to have the same key for every door!
Worse still, that repeated key seemed to belong to a VPN router product.
Ironically, a VPN is a Virtual Private Network – a secure, encrypted network “tunnel” that is supposed to let your remote workers connect back to head office in much greater safety than if they were to use the open internet.
Does it matter?
You’re probably thinking, “Why fuss about repeated RSA keys if those keys only show up during a FREAK attack, which is a bug in its own right anyway?”
The point is that the repeated-key bug reveals that, somewhere in those affected VPN routers, there exists an egregious programming mistake to do with cryptographic randomness.
That bug could affect other aspects of the router’s encryption setup code.
Yet the researchers only spotted that bug because they happened to be looking for a completely different one.
Two take-aways
There are two important take-aways here:
- Finding programming mistakes is hard; sometimes it requires serendipitous coincidences.
- If you are the vendor of the affected router (check yours: you’ll soon see if it’s you), you have a code review to do.
Image of cutaway lock thanks to Wapcaplet at the English language Wikipedia.
Image of router courtesy of Shutterstock.
