How Should WiFi Passwords be securely stored on IOT (embedded) devices?

Question

Some devices need to store and (re)use a password (not the hash) like your mobile phone using home wifi, SmartTV, etc;

How should they store the password on their flash storage? So that a person who has physical access to the chip can not retrieve it?

If the PKI method is used, then the private key also needs to be around for the device in order to decrypt the password and use it to join the network. And that private suffers from the same problem.

Also, having some kind of master key means that once one device's master key is read, then all devices data can be encrypted using the master key.

How is this commonly implemented at present and ideally how should it be?

Answer 1

For Windows 7 and above, Microsoft enabled Protected Processes via the RunAsPPL=1 registry change. This protects the LSA from being dumped by even the SYSTEM account. The LSA (lsass.exe process) contains secrets including the WiFi keys and the machine credentials. In order to access these secrets again, the current-logged-in user must have his or her screen locked and unlocked, logged out and back in, or the machine rebooted followed by a successful login. I have tested and verified that tools such as WirelessKeyView will not work when lsass is protected in this way.

This sort of protection is still provided in software (and can be bypassed through kernel or driverspace technology, which has even been seen in the wild with malware such as Uroburos) -- but it is sufficient for many environments and certainly much better than no protection at all. For a hardware equivalent, many are looking at Intel SGX to provide a secure enclave. If the IoT manufacturers can leverage Intel SGX, or a similar technology, then that would be the best location to store shared secrets, such as WiFi passwords, credentials, and cryptographic key material.

N.B., part of this discussion was taken from a talk given by Thomas Dullien of Google -- http://www.slideshare.net/hashdays/why-johnny-cant-tell-if-he-is-compromised -- https://www.youtube.com/watch?v=kG2sISGNZmk

Answer 2

As has been mentioned as a comment to your question, all you can do is make it harder.

Current WiFi protocols require that the client and AP both know the PSK. This is unavoidable as it stands, and I am not sure of any plans to change this.

You can employ a number of different techniques to make secrets harder to obtain. You need to take into account your threat model though - what are you protecting, who are you protecting it from, and how long you want it to be protected for.

The task is not dissimilar to protecting the keys in a hardware security module. These often use advanced techniques to prevent someone - even with extended physical access - from getting secret keys out.

Specifically, for most IoT devices, they are already stored in a protected area i.e. inside the house. The Ring Doorbell and some CCTV IP cameras break this barrier and are in areas where an attacker can more easily access them - consideration should be made for this. That said, you should not rely on everyone in that protected area being benign - for example, if your teenager can only use a time-restricted SSID, they could try and recover another PSK for a normal SSID from another device.

Obviously you should protect the key being read out over the network, as we found in the Ring Doorbell (full disclosure, I am an employee of Pen Test Partners who found the issue). A number of common WiFi SoCs/boards come with SDKs that have holes such as these though.

Some WiFi SoCs/boards allow the PSK to be set once, and then make it hard to recover the key. At a bare minimum, these require connecting JTAG or SPI to read some memory. At worst, you may need to develop new attacks to recover the content of onboard EEPROM.

Physically potting boards makes accessing buses and chips harder, and will deter attackers.

This could be extended further to add anti-tamper functionality such as that found in hardware security mechanisms or Chip & Pin terminals.

Encrypting the key with a symmetric key is largely pointless in most small embedded systems that can by physically attacked.

Answer 3

if possible the key could be stored in a smartcard/HSM/TPM (i just call them Secure storage devices below), which doesnt let the key out but rather handles the operations (sign, encrypt etc) with the key.

especially for WPA WLANs the key itself is just used to derive something we could call a Session key and after that the password to the WLAN Hotspot isnt needed anymore, so this could be easily by a secure storage device.

one of the problems is that probably even with the runasppl as mentioned by @atdre the windows Network and Sharing center offers administrative accounts the key on a silver tablet directly in the GUI for Vista and above, so if you use windows you cannot do much unless you make a WLAN software that can handle secure storage devices for WLAN keys.

While I would say that a HSM is pure overkill a TPM is getting more and more common and is even required as to get a computer with Win10 sticker.

The more intresting question is to build a software that can work with the secure storage to create the WLAN handshake.