6

My company develops a WiFi-connected IoT product. I want to make sure that the process of getting the user's WiFi credentials into the device is as safe as possible. At the moment, the product is in a prototype stage, so we can (and will) make further changes before it hits the market.

At the moment, the process is as follows:

  1. The device creates its own WiFi hotspot. The credentials for this hotspot are printed onto a label on the device itself.
  2. The user visits a certain URL (a web page served by an embedded web server on the product, using plain HTTP)
  3. The user enters his WiFi credentials into a form on that page
  4. The device saves those credentials and uses them to connect to the user's WiFi

Several guys in the company think that this is secure. An attacker would need to get into the hotspot to sniff on the user's WiFi credentials.

I disagree since I think that getting into the WiFi is a pretty low hurdle. The attacker could have glanced at the credentials on the label during a visit, brute-forced his way into the WiFi hotspot or exploited a weakness in the WiFi hotspot authentication (not unheard of). I suggest to change the process to look as follows:

  1. The company creates a self-signed SSL root certificate.
  2. We use this root cert to sign individual certificates unique to each product sold. The product's certificate and private key is embedded in flash memory during manufacturing.
  3. The user goes to our website and downloads our root certificate and installs it into his operating system.
  4. The device creates its own WiFi hotspot. The credentials for this hotspot are printed onto a label on the device itself.
  5. The user visits a certain URL (a web page served by an embedded web server on the product, using HTTPS and the device's unique certificate. The browser trusts the certificate because our root cert is installed.)
  6. The user enters his WiFi credentials into a form on that page. The information is sent to the device over the TLS-encrypted channel.
  7. The device saves those credentials and uses them to connect to the user's WiFi

I think that this process is very secure. But it imposes other problems:

  • How can we update a device's certificate? Possible, but very cumbersome and a lot of effort.
  • The user has to manually install a certificate. This is not very user-friendly and less tech-savvy users may fail to do it correctly even if we provide very detailed instructions.

My question(s):

  1. Is the suggested process secure enough for an IoT product (imagine it as some kind of smart energy meter measuring your electricity consumption)?
  2. Is there any way to improve the user experience of the process (e.g. getting around the need to install our certificate)?
  3. Is there any way to improve the process in terms of implementation complexity for us (without compromising the user's security)?
  4. Are there alternative ways to get the WiFi credentials onto our device? We cannot use Bluetooth and the device has neither screen nor keyboard.
8
  • You could work with a established CA to get a certificate you could use to sign the hardware certs, that way the user wouldn't have to install an additional (your) root cert. However, I'm not sure if this would work either way, or may vary by browser, as once the user is on the hotspot network, they won't be able to perform CRL lookups which might throw an error anyway. – K.B. Jan 17 '18 at 17:51
  • @K.B. I'm pretty sure that this wouldn't be possible. When submitting a CSR, you need to specify a hostname the certificate shall be valid for. And the CA needs to verify that I do control this hostname. That is not doable since the server on the device is up if and only if the device is not connected to the internet. – Oromis Jan 18 '18 at 9:36
  • Again, I suspect this may not be the best route to go, even if it is possible, but CAs can issues certs, that you can then use to sign whatever cert you want (called an intermediary certificate). I don't know what the requirements for getting one of those are (I'd guess pretty stringent, since you're effectively being granted ability to sign things as the CA), but it can technically be done. – K.B. Jan 18 '18 at 19:43
  • On a more practical note; you could create an app (google play/apple store/windows store) that would have your trusted root cert embedded in it. That way you could tell the user 'download this app' (something most users will be comfortable with) rather than 'follow this sequence to install a trusted CA cert' (something most users are going to be confused by). – K.B. Jan 18 '18 at 19:46
  • On an even more practical note: if you made sure the hotspot used modern WiFi encryption (WPA2, soon WPA3), made sure the password was random (not procedurally generated based on MAC or something), and that the hotspot password was not listed on the outside of the box (so you had to buy the thing & open the box to find the password), I'd guess the HTTP only hotspot would probably be secure enough since it is only enabled for a short period of time (The hotspot turns off once it successfully connects to another network right?). – K.B. Jan 18 '18 at 19:50
1

Answering this question reminds me about the one I answered in regards to security on fire safety products.

Security is only as good as the weakest link. In this case it's the end user.

Asking end users to install root certificates is not only begging to raise questions (are you or your company even reputable enough to be a CA?), but will prove a waste of time if a user somehow works their way through things. You will need to update certs over time, or maybe even revoke one, the sky is the limit, and building a PKI is out of scope for a project like this.

Technologies such as WPS and Bluetooth pairing prove that easy is generally better suited for security in a wider audience. While WPS suffers from problems, it doesn't really matter as most WiFi routers come flashed with ISP branding and horrible default credentials based on serial numbers. Mine even offers a no way to disable "password recovery" feature, because storing plain-text passwords is never a bad idea right...

Local attacks aren't really prevented anyways, because who would honestly break into your house (a criminal offense), to tamper with a device for free WiFi (potentially another criminal offense), when they could commit more profitable criminal offenses like photographing your credit card(s)?

The initial scenario seems suitable, given that the hotspot only remains "on" for a limited time period, and times out when nothing is setup. Pushing the button on the device starts the "setup" phase again.

If you are interested in other ("exotic") solutions:

  • I've had fun with "key loaders" used in military or police radios before. Potentially adapt this idea with a USB key that holds WiFi setup info that erases after loading the info?
  • Generate a one time password, display it on the device for 60 seconds, and then require a device wipe to change device settings or pair the device again.
  • If this is going to be used in a commercial setting, pairing via bluetooth and then using an app to setup may be good idea.
  • If you want a more "high-tech" approach, use an app that transmits information to the device via NFC after a button on the device is pushed. Marketing departments really love buzz words like NFC.
  • Do as the fancy store payment terminals do. Include features like proprietary interfaces/standards and pressure sensitive switches that clear keys in volatile memory.
  • Assuming certificate based WiFi, you could load certs onto a YubiKey, and have a user place the Yubikey on the device. Have the key do all the crypto, and private key extraction would prove difficult to most attackers. Charge $$$ for including a "FIPS" model, because again marketing departments like buzzwords.

In the end, security is only good if it is usable. Keep that in mind for your end users.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.