IoT devices can be classified into three categories: IoT devices with limited capabilities (for example, sensors) : Tiny and cheap devices (typical cost of $0.20 or less) without a “real” CPU (ARM-like), often with a limited power source IoT devices with limited capabilities (for example, smart sensors, Fitbit) : Non-expensive devices (typically under $100) with a cheap CPU (usually ARM cortex M series) running MBED OS and limited memory (less than 256KB RAM), often with a limited power source. All other Internet of Things devices (for example, medical devices, smart TVs) : Devices with a strong CPU (ARM cortex A series) and sufficient memory, running linux, often connected to an external power source. Different requirements, different programming language
The second and third types of IoT devices can be protected by libsecurity features as described in previous posts. (See the link at top of this page for libsecurity blog posts.) The difference between those types affect the implementation of these features. With devices of the second type, the MBED OS doesn’t have a built in file system, and its networking layer implementation is different from that of Linux and MBED OS. Devices using Linux on top of Intel or AMD CPUs can use the de facto standard of NaCl cryptograhy library, while others must use the MBED TLS library. Differences between these types of devices result in the need for an adapter layer.
Another difference between the two types of IoT devices is their memory footprint, which impacts the programming languages relevant for each. The memory footprint of small devices dictates the use of C as the programing language, while for stronger devices with larger memory footprint that can run Linux, we chose the Go language. The libsecurity-c project was designed for the second category ― IoT devices with limited capabilities ― and is written in C. (Note that C could also be used for the third category of devices.) Since C is prone to memory leaks and security issues such as buffer overflow, and our general approach is to have full test coverage (including formal verification) for the libraries we develop, we have implemented a set of methodologies and testing tools.
Tested, and tested againThe extensive testing effort included using tools such as Valgrind, GCC and CLANG compilers, and IBM ExpliSAT for formal verification. In addition, a wrapper layer was written on top of the American Fuzzy Lop (AFL) fuzzer tool to verify the code and interfaces. As mentioned, differences between IoT devices forced us to add a connection layer for the cryptographic library, file system, networking, and hardware. The current library was tested on top of Linux (Intel and AMD CPU), BeagleBone Black device (Linux running on ARM Cortex A series CPU), and K64F devices (MBED OS on ARM M series CPU, with limited memory).
For MBED OS devices that don’t have a file system, we added a file system layer (in the current library, we added this layer for the most commonly used IoT devices ― K64F). A network adapter was written to handle the difference between Linux stack and the MBED OS stack.
Another aspect of networking is the Datagram Transport Layer Security (DTLS) communication used to send encrypted messages using SSL on top of UDP to log or Mule servers. As part of the current library, the implementation is on top of Linux or MBED TLS.The libsecurity-c project includes several examples of how to use its major features.
Help secure your devicesThe libsecurity-c project code is now available for you to use for your own devices. We’re hoping you will find it invaluable for protecting your small-device data. We also welcome your input to continue to improve the code.