@bl4sty published an algorithm for computing WiFi passwords for routers of the UPC company. UPC is also the biggest ISP in the Czech Republic. Dusan and @ had a UPC router so they thought it might be fun to have a look and see if the original implementation of UPC keys works. It did and they wrote a post about it. They say they haven’t found a UPC hotspot that would resist the two attacks – where the default password was set, i.e., 84% of UPC hotspots.
The bottom line is that if you try both algorithms – the original as well as the new one from Dusan, there is a little chance of missing the WiFi password if users didn’t change it. Some war-driving results suggest that only 18% of people change the default password (data from the Czech Republic).
The question is, whether one can do any better than UPC did and the answer is not straightforward. One can see the difficulties in the fact that UPC will now show a message, simply stating that the password is not secure and users should consider its change.
The problem is – how can you initialize a hardware device with a secret that would be hard to discover. If you say that it’s simple – even Windows now offer functions for generating random numbers – you are thinking inside the box. In fact, inside a very small box as devices where it becomes a problem don’t have a user interface with a lot of “random” user input and system activities that can be used as a source of randomness.
What UPC routers do is actually a reasonably good solution – they take a unique piece of information (name of the WiFi network, a.k.a. SSID) and use it as an input for some cryptographic functions. They also add a bit of ad-hoc processing (“obscurity”) based on strings like “UPCDEAULTPASSPHRASE”, add profanity checks, and a final formatting to map the result onto letters and digits. A good solution, if you look for something “software-only”.
Randomness – or more precisely a lack of randomness is the ultimate cause of the problem. WiFi routers are just one class of devices where this problem appears. Most of “industrial” / embedded computers and devices share this problem and even very secure devices, for example, payment terminals (terminals you touch / shove in your payment card in shops) may fail a thorough analysis.
There is no simple answer to this problem, although solutions exist. Here is a short list to show some possibilities.
- add a hardware component that will provide a hardware source of randomness;
- request user input and use it as one of the inputs for random-number generators;
- provide initial randomness at the same time when the device ID is set; or
- request randomness from a cloud service.
There are solutions, but it’s right to say that each of them adds an additional cost to the manufacturing or the operation of the devices. It is not clear at all, whether this is acceptable for WiFi routers for which customers would pay £5, including postage and packaging.
Actually, thinking about it, I’ve seen much worse solutions to the randomness problem.