Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

No excuses for ignoring security in IoT devices
SECURITY SHELF

No excuses for ignoring security in IoT devices 

A good example is the ESP8266, perhaps currently the most popular IoT WiFi chip. The ESP8266 is a self-contained, FCC certified, IEEE 802.11b/g/n WiFi device. It features a low-power 32-bit CPU, 64 KBytes of instruction RAM, 96 KBytes of data RAM, 4 MB of flash, and 16 general purpose input/output (GPIO) pins. The bare chip costs about $2.

Several ESP8266 prototype boards are available, ranging from a $3 board with a LED and etched WiFi antenna, to a $7 board complete with antenna, supporting components, and a micro-USB port for PC connectivity and easy programming. Other variants are designed for connection to microcontrollers and marketed as serial WiFi boards. Some vendors ship devices with no firmware, while others pre-install open-source NodeMCU or firmware that provides a modem-like AT command set for WiFi and TCP/IP connectivity. Developers can alternatively choose the Arduino Integrated Development Environment (IDE) with an ESP8266 add-on to write their own firmware and flash the board.

Some developers incorrectly suggest that small, inexpensive, memory-constrained processors such as the ESP8266 are incapable of encryption. Not only is the $2 chip capable of WPA2 with AES, but HTTPS libraries are freely available. It takes a few hours to download libraries, configure the Arduino IDE, and tweak sample code. The result is a $7 board that boots, connects to a WiFi access point using WPA2 with a pre-shared key (PSK), obtains an IP address via DHCP, and polls an Internet HTTPS server every ten seconds.

While more advanced features such as Diffie-Hellman and elliptic curve algorithms are not currently implemented, and may not be due to system constraints, TLS with AES-256 goes a long way to protect IoT communications. Instead of a certificate repository, the library includes a function to verify the remote server certificate’s SHA-1 fingerprint. A developer could therefore use a self-signed certificate if desired.

Building a product around this capability obviously requires additional functionality. For example, there must be a way for users to input wireless network configuration information. The ESP8266 includes serial input and even basic wireless access point capability. It proves that a $2 chip is capable of exchanging data with other processors, monitoring sensor inputs, outputting digital or analog data, and communicating across the Internet with a reasonable level of security.

IoT is an emerging area that would greatly benefit from security standards. Perhaps a Common Criteria approach would be a good fit. While not all vendors will be willing to have products formally evaluated, community-developed Protection Profiles could provide desperately needed guidance. Formal evaluations provide vendors an opportunity to differentiate their products and demonstrate their commitment to security.

It is time for consumers of IoT devices to be very clear with vendors. Appropriate security controls are mandatory. As a starting point, all Internet communication must be encrypted and authenticated. All devices must have access controls. Default passwords and shared encryption keys are not acceptable. Security controls must be included in product design, development, and quality assurance activities. Attempting to bolt security on after the fact is not an acceptable practice. The required technology exists and it is very affordable. There are simply no excuses for ignoring security in IoT devices.

Have a security question you’d like answered in a future column? Email eric.jacksch@iticonline.ca

Related posts