Any device that needs to be connected to the Internet of Things (IoT) first needs to be connected to the internet. This connection can happen via cellular, Wi-Fi, or Ethernet. This article addresses the challenges faced while designing devices connected with 802.11 technology. Some of the challenges include provisioning of the Wi-Fi connection details, connecting to multiple Wi-Fi networks, device firmware upgrades and security constraints. Lantronix solutions that alleviate these challenges and enable quick deployment of Wi-Fi based solutions are also highlighted.
Provisioning the Wi-Fi Connection
The first step in getting a device connected is to be able to talk on the network. On an Ethernet network, that is easy enough. Plug in the cable, the Dynamic Host Configuration Protocol (DHCP) server automatically assigns an address, and the device is ready to communicate. With a cellular connection, the SIM card already contains secure identification information and is provisioned over-the-air by the mobile network operator so the device can access the network.
With Wi-Fi each device has to be provisioned with the details of the network or networks that it will connect to. At the most basic level, that includes Service Set Identifier (SSID), the security suite, and the passphrase or authentication credentials needed to connect.
If the 802.11 module doesn’t have a Software enabled Access Point (SoftAP) feature, then configuration needs to be done via a serial or Ethernet interface. This means that a host processor has to have a user interface and manage the configuration of the device, which adds significant cost and complexity to a design, especially if a display needs to be added to the device. This cost and complexity can be avoided by using a Wi-Fi device that has a SoftAP feature. This feature allows the 802.11 module to advertise itself as an Access Point, thus allowing Wi-Fi clients to make a connection to the module, without relying on the older and less-supported Ad-Hoc mode.
Using the SoftAP
The first consideration that the designer needs to think of is whether what works in the lab will work in deploying tens of thousands of devices by users of varied skill levels. Most modules with SoftAP will allow someone to connect to some limited web configuration manager, scan for available infrastructure networks, and select which one to connect to. The usual instructions for an end user would be:
-
Connect your phone’s Wi-Fi to the network: ACMEWidget
-
Enter the password which is ACME_Designs
-
Now open your phone’s browser, touch the URL bar (hope you know what that is!) and type: 10.10.0.1 and press enter
-
On the display find the link that says Scan
-
After a few seconds select your infrastructure Wi-Fi network
-
Enter the password to your infrastructure Wi-Fi network in the box that comes up and press Enter
-
Reboot and hope the LEDs show a connection! (if the 802.11 module you selected does not have simultaneous SoftAP and Station mode)
This might work well in the lab, but deploying such a device will result in increased maintenance and technical support costs. It also limits the ability to include the provisioning of the device into a company’s existing configuration utilities if those exist.
The way to solve this issue is to choose a module that allows for an easy way to programmatically provision the Wi-Fi details. For example, Lantronix has devised a feature in its web server, called WebAPI, which uses HTTP POST messages to directly access configuration of the xPico Wi-Fi module.
Lantronix has also published the xPico Wi-Fi Utilities Android App that only requires the user to select which network they want the xPico Wi-Fi to connect to and the password. All the other steps seen above are eliminated. This functionality makes it easy to integrate configuration into an 802.11 module for end devices that require minimal user interaction.
Connecting between Multiple Wi-Fi Networks
When a device moves to different locations, it is possible that it will move to locations that have different Wi-FI networks. While the warehouse might have one SSID and password, the front office might have another. And the users of your device will expect that your device behaves just like their smartphone or tablet: provision each Wi-Fi network once, and after that move between them with the device connecting automatically when each network is in range.
Most 802.11 modules can only store the connection details for one Wi-Fi network. While that works nicely in the lab, deploying a ventilator that needs IT to come reconfigure each time it gets moved to a different hospital wing will not be acceptable. This means that the processor attached to the 802.11 module will now need to implement a Wi-Fi configuration manager. Also the dataflow between processor and module will need to be periodically interrupted for the processor to ask the module to do a scan of wireless networks, and then make the decision to reconfigure the 802.11 module via the serial port.
Implementing a Wi-Fi configuration manager on the attached processor means that the 802.11 module’s web server might not be usable for provisioning, since the data from the user interface needs to go to the processor and not to the module itself. The attached processor will now need to implement a whole new web server, which significantly increases complexity of the design.
To avoid these issues while still maintaining the ease-of-use that customers expect, the Lantronix xPico Wi-Fi has an advanced configuration manager as part of the Lantronix Device Server Software Suite. This configuration manager includes the WLAN Profiles feature, which can automatically store the provisioning details for multiple Wi-Fi networks in the flash of the xPico Wi-Fi. This means that an end device will be able to roam between Wi-Fi networks without any interaction by the end user or by the attached micro controller.
Device Service and Maintenance
Simultaneous SoftAP
In many use cases, the device goes into an end user facility with a secure network, where the end user does not want to give a technician from the service company access to their network. The traditional model is to take the device off the network and connect it to a computer that the service technician brings to the site for any service or reprogramming of the device.This creates an issue if there is a central management system monitoring the device as an alarm will go off because the device has gone off line. In addition, if the device is controlling access like a door, then the door is unusable while it is being serviced.
A solution to this is to use an 802.11 module that not only has a SoftAP, but that can run the SoftAP simultaneously to the Client interface. Ideally the module will also allow for simultaneous access to the resources of the module as well as the attached microcontroller. This way, the technician can access the device, without having to have the credentials to get onto the end customer’s network.
The Lantronix xPico Wi-Fi is a module that has both simultaneous SoftAP and can connect to an enterprise Wi- Fi network. This allows a data tunnel between the end device and a Cloud application as well as supporting the Wifi module’s configuration from both interfaces simultaneously. This is a unique feature of the Lantronix Device Server application.
Over the Air Firmware Upgrades
An 802.11 module will sometimes need to have the firmware upgraded, whether to deploy new features or fixfirmware issues discovered since the device was deployed. Software engineers should have a plan from the beginning on how firmware upgrades will be done. Most modules will allow for an upgrade with either a serial or a JTAG cable. This requires the end device to bring out the connection to a header, and also for physical access to the device to do the upgrades.
Another option which some modules offer is to do an over the air (OTA) upgrade using the Wi-Fi connection of the device. Ideally, the upgrade would be done in a failsafe manner, such that if the Wi-Fi connection or power supply is interrupted, the device is left in a working state.
The Lantronix xPico Wi-Fi includes an OTA upgrade application that resides in a different part of flash than the main firmware application. This means that if the upgrade fails for any reason, the xPico Wi-Fi will boot back into the OTA upgrade application to receive a new main firmware image.
The OTA upgrade application also stores the WLAN Profile of the client that it is connected to, and just like the configuration manager, the OTA upgrade application can be managed via the WebAPI. This means that the xPico Wi-Fi, out of the box, can do failsafe upgrades that are scripted using the HTTP POST requests, and can be done either locally on the SoftAP interface or remotely through the Client interface.
Security
There are many aspects of security that need to be taken into account when selecting an 802.11 module. These include security of the wireless connection, as well as data security.
Wireless Security
Wireless security restricts access to a wireless network by requiring a password, and also encrypts databetween the 802.11 module and the Access Point. It’s important to understand the implementation and practical differences between the different methods of connection.
One of the first decisions to make is whether the device will support Enterprise security or Personal security. Personal security is the usual name for a network with Pre-shared key. This is the most common type of network deployed, as it’s the easiest for both administration and end users. With Personal security, everybody uses the same passphrase to connect to the network. The vulnerability is that anybody who knows the passphrase can connect, and if the passphrase changes, all end users need to be notified and deployed devices reconfigured.
Enterprise security, or 802.1x, addresses that vulnerability by having a separate username and password for each user, and using a back-end RADIUS server for authenticating the user and exchanging the encryption key after the authentication is complete. This type of security is much more challenging to administer as it requires the server to authenticate. Also in many cases, end devices need to be provisioned with certificates for the authentication to work.
Whether Enterprise or Personal, the connection uses an encryption key for the data. The key can be generated at connection time, as in Wi-Fi Protected Access (WPA) or WPA2, or be the actual connection password as in Wired Equivalent Privacy (WEP).
WPA2 is the most secure as it uses an Advanced Encryption Standard (AES) based encryption method. Both WPA and WEP have exploitable vulnerabilities. Note that WEP has been obsoleted by the Wi-Fi Alliance, so any new Access Point deployed will not likely have WEP support.
An important issue to consider is that when deploying an end device, the existing network may use any of the three methods, so the 802.11 module chosen should support all of them. WEP presents a special challenge in that WEP requires a key of either 10 (WEP64) or 26 (WEP128) hexadecimal digits.
Because such a key is difficult for end users to remember, Access Point manufacturers allow users to enter a passphrase instead. Since the passphrase to hexadecimal key conversion is not part of the WEP specification, different Access Point manufacturers chose different conversion algorithms. Lantronix has identified 32 different algorithms that Access Points use.
The Lantronix SmartConnect EasyWEP feature takes care of managing the different conversion algorithms so that your users can enter their passphrase and are not required to use a hexadecimal key to connect to their WEP network. The SmartConnect EasyWEP feature uses the xPico Wi-Fi’s WebAPI to accept a passphrase, and then tries each known conversion algorithm to try to establish a connection to the Access Point. When it finds the conversion algorithm that completes the connection, it saves the WLAN Profile into flash with the correct hexadecimal key for future use.
Selecting a module that only allows for entry of hex key instead of also allowing passphrase can cause unnecessary technical support calls or returns as users that only know the passphrase for their network will not know how to connect the end device to the network.
Data Security
The wireless security part only encrypts data going between the end device and the nearest Access Point. The unencrypted data payload can be intercepted at two points: first, upstream of the wireless Access Point, as the data is no longer encrypted with the wireless security key; second, by another device on the wireless network if using an insecure key or on a network that uses no wireless security.
The two usual methods for encrypting data are Advanced Encryption Standard (AES) and Secure Sockets Layer/Transport Layer Security (SSL/TLS). AES is the NIST-approved method for symmetrical key encryption. Each end of the connection has the same key to encrypt and decrypt the data. This makes it very easy to deploy, as it can be done when configuring the device. The encryption and decryption steps are CPU intensive, so it’s best to choose an 802.11 module that handles that part, so as to not have to implement it in the attached micro controller.
The drawback of this method of encryption is that the designer has to control both of the devices that will talk to each other, since the key needs to be provisioned into both the end device and the server. To allow for clients to connect to servers that are not owned, it is possible to use SSL/TLS, which is the method used in secure HTTP or HTTPS. This method uses asymmetric cryptography to establish the connection, and then exchange temporary symmetric keys on a connection by connection basis.
The vulnerability with SSL/TLS lies in the initial exchange of the certificates. Since there is no pre-configured key, it is open to a man in the middle (MITM) attack, by a user that redirects DNS to their server and then sends a certificate impersonating the end server. The way that this issue was addressed was with the introduction of Certificate Authorities (CA). These are entities that are trusted by default, and any server certificate has to be signed with the certificate of a CA, or an intermediary that can verify the relationship, also called a certificate chain.
This method presents a more complex configuration of the end device. The device needs to be configured with the certificates for the trusted CAs so that it can verify the certificate chain of the servers that it will connect to. Also since certificates have expiration dates, there has to be a system in place to retrieve and install new certificates before expiration, to keep the chain of trust intact and prevent MITM attacks.
Many of the data encryption and device configuration tasks can be offloaded to the 802.11 module. The Lantronix xPico Wi-Fi includes the Lantronix Device Server Software Suite, which includes encryption capabilities, including easy configuration, so that the encryption is completely transparent to the end device.