A Simpler Solution for Hardening Security in Wi-Fi Connected IoT Designs

Wi-Fi connectivity is a key requirement for many Internet of Things (IoT) devices and a favorite target for hackers. Weak security implementations leave devices open to penetration during ongoing network communications. Worse, IoT devices can fall victim to attack early in their lifecycle when the device attempts to join trusted networks.

Using a dual-core wireless MCU from Texas Instruments, engineers can easily harden security IoT devices throughout the product lifecycle and support multilayered end-to-end security strategies.

Security components

Security in any system requires a multilayered approach. Although data encryption often gains the most attention among security measures, it is only one aspect of a robust security policy. Black-hat methods such as man-in-the-middle attacks exploit any weakness well before encrypted data exchange begins. Indeed, secure hosts authenticate clients to ensure that only authorized users, devices, or other systems gain access. Conversely, those clients authenticate the host to verify its identity.

This kind of mutual authentication lies at the heart of secure applications, but it ultimately relies on more fundamental mechanisms and policies. Foremost among these, secret keys and an established root of trust are the building blocks of any secure application. In the kind of public key infrastructure (PKI) typically used on the Internet, public keys paired with secret private keys provide essential validation of an entity’s identity. The X.509 certificate standard wraps the entity’s public key in a broader context that documents that identity, building on a chain of certificates to provide a solidly grounded root of trust for the application.

The use of secret keys, encryption, X.509 certificates, and root of trust is both a necessary and sufficient condition for building secure applications. Critical systems build on these components, adding middleware and application-level security protocols to meet stringent security requirements. For most applications, however, developers can lock down security using just these components and certain best practices for operations such as booting and over-the-air (OTA) updates.

Yet, even these “basic” components of security represent a combination of complex mechanisms and policies on their own. For product managers, the conflict quickly rises between creating complex security components, and focusing on the differentiating features of their application. Security implementation typically loses out because few IoT developers have the time to gain the knowledge or experience needed to stand toe-to-toe with elite hackers. The Texas Instruments wireless MCU provides a single device able to help make it a fair fight.

Wireless MCU

The TI wireless MCUs include the CC3220, a dual-core device that combines an ARM<® Cortex®-M4 core and a dedicated network processor core with integrated transceiver. The MCU comes in three variants: the CC3220R, CC3220S, and CC3220SF. All three come with 256 Kbytes of on-chip SRAM that can be retained during the device’s various low-power modes. The CC3220SF also integrates 1 Mbyte of flash that allows in-place execution of code, leaving the SRAM only for writeable data. A separate on-chip ROM provides a full set of Wi-Fi and Internet logical layers, enabling the network processor to deliver a comprehensive set of connectivity services without the intervention of the M4 core. Perhaps most important for IoT developers, the device leverages its embedded wireless features and its multiple on-chip hardware security mechanisms to support a broad array of secure services as described below.

Along with secure connectivity, the MCU offers a comprehensive set of peripherals and connection interfaces required for most IoT applications. The device provides a four-channel 12-bit analog-to-digital converter (ADC), four timers with 16-bit pulse-width modulation (PWM), watchdog timer and a broad set of interfaces including up to 27 GPIOs, 8-bit parallel camera, secure digital (SD) card, SPI, I²C, and UART ports as well as JTAG, cJTAG, and serial wire debug (SWD) interfaces.

For developers, using this device in complex designs is straightforward. Engineers can take advantage of its multiple interface options to leverage its extensive capabilities in relatively simple designs (Figure 1). TI further simplifies IoT design implementation with its CC3220S LaunchXL LaunchPad development and CC3220SF LaunchXL LaunchPad development kits. Along with a hardware evaluation board, the kits include a complete reference design, comprising hardware schematics, software development kit (SDK), and sample software.

Figure 1: TI LaunchPad development kits for its CC3220 wireless MCU provide a complete IoT evaluation system including a hardware reference design and software for secure connectivity. (Image source<: Texas Instruments)

Secure connectivity

With its extensive set of on-chip peripherals and simple design requirements, the CC3220 seems like one of many integrated MCUs designed for embedded applications such as IoT. However, unlike other highly integrated MCUs, the CC3220 offers on-chip support for a broad array of security components required to help ensure end-to-end security in IoT applications. Along with its features for secure authentication and session security, the device’s security mechanisms offer protection for all three states of data: Secure storage for “data at rest”; tamper and other run-time security measures for “data in use”; and secure exchange for “data in transit” (Figure 2).

Figure 2: In the TI CC3220 MCU, the network processor’s firmware leverages integrated security hardware to support end-to-end security ranging from encrypted storage, secure Wi-Fi access, and even an embedded secure Web server. (Image source: Texas Instruments)

The CC3220 MCU also differs from many ICs designed to offer low-level security mechanisms such as encryption and authentication. The TI MCU builds on integrated features like secure storage and hardware accelerated crypto to provide a complete set of higher level services and even embedded servers. For example, the device supports up to six secure sockets using standard transport layer security (TLS) protocol, and uses those sockets to provide an embedded HTTPS server. For secure authentication and data exchange, the device’s trusted root certificate catalog provides a mechanism to help ensure interactions with other trusted hosts and clients. At an even broader level, developers can also use the device to build on the TI root of trust for the critical process of establishing a chain of trust.

TI’s SimpleLink MCU software development kit (SDK) delivers these features through an API that abstracts detailed hardware or firmware supported functionality to a few simple calls. For example, developers connect to a network by calling an API routine:

sl_WlanConnect(access_point_name, name_length, MAC_address, security_parameters, optional_enterprise_parameters)

and setting security_parameters to one of the standard Wi-Fi security protocols supported by the device.

Once connected, the device can provide its higher-level services just as easily. For example, developers start the internal HTTP server with one simple call:

sl_NetAppStart(SL_NETAPP_HTTP_SERVER_ID).

Besides SL_NETAPP_HTTP_SERVER_ID, other reserved bitmap IDs start embedded servers for DHCP (Dynamic Host Configuration Protocol), DNS (Domain Name Server), and mDNS (multicast DNS).

Similarly, developers use simple API calls to leverage basic security mechanisms integrated in the chip. For example, the CC3220S and CC3220SF variants support an enhanced file system that stores data as encrypted files in flash memory (Figure 3). These MCUs transparently encrypt and decrypt data on the fly and allow access only through the API. When a secure file is created during development or at run time, the MCU creates four different tokens that represent different access rights: full access (master token), read/write access, write-only access, and read-only access.

Figure 3: TI’s CC3220S and CC3220SF offer extended security features including secure file storage on flash as well as extended debug security, including the ability to lock JTAG and debug ports. (Image source: Texas Instruments)

Developers take advantage of this security feature using API calls that resemble conventional file oriented operations, requiring only an additional parameter for an associated security token. As shown in Listing 1, developers create a new file using an API call (sl_FsOpen) with flags that indicate a secure file should be created. Subsequent calls to open the file require use of the provided token (MasterToken). For finer access control, developers can use an API call (sl_FsGetInfo) to read all four tokens created during file creation.

char* DeviceFileName = "MyFile.txt";

unsigned long MaxSize = 63 * 1024; //62.5K is max file size

long DeviceFileHandle = -1;

_i32 RetVal; //negative retval is an error

unsigned long Offset = 0;

unsigned char InputBuffer[100];

_u32 MasterToken = 0;

// Create a file and write data. The file in this example is secured, without signature and with a fail safe commit

//create a secure file if not exists and open it for write.

DeviceFileHandle = sl_FsOpen(unsigned char *)DeviceFileName,

 SL_FS_CREATE|SL_FS_OVERWRITE | SL_FS_CREATE_SECURE | SL_FS_CREATE_NOSIGNATURE | SL_FS_CREATE_MAX_SIZE( MaxSize ),

 &MasterToken);

Offset = 0;

//Preferred in secure file that the Offset and the length will be aligned to 16 bytes.

RetVal = sl_FsWrite( DeviceFileHandle, Offset, (unsigned char *)"HelloWorld", strlen("HelloWorld"));

RetVal = sl_FsClose(DeviceFileHandle, NULL, NULL , 0);

// open the same file for read, using the Token we got from the creation procedure above

DeviceFileHandle = sl_FsOpen(unsigned char *)DeviceFileName,

 SL_FS_READ,

 &MasterToken);

Offset = 0;

RetVal = sl_FsRead( DeviceFileHandle, Offset, (unsigned char *)InputBuffer, strlen("HelloWorld"));

RetVal = sl_FsClose(DeviceFileHandle, NULL, NULL , 0);

Listing 1: The SimpleLink SDK API provides developers with access to robust security features such as secure file access using familiar file-access calls that pass tokens (e.g., MasterToken) or flags, such as those for secure-file creation (SL_FS_CREATE_SECURE). (Code source: Texas Instruments)

Simplified provisioning

During development, a comprehensive set of on-chip security features significantly speeds creation of more robust IoT devices. During network deployment, however, the rollout of large IoT applications can fall seriously behind schedule when the IoT device cannot connect easily to the existing Wi-Fi network.

In a typical provisioning process for a Wi-Fi network, users configure devices with the network’s name and security credentials required to join the network. During this crucial stage, missteps in device setup and initialization can prevent connection or leave the device open to attack. For users, a device unable to connect is considered a failure regardless of its operational capabilities, and a device that is secretly hacked leaves an open door to the user’s entire network of devices.

Even more so than conventional network products, IoT device provisioning can face significantly greater difficulty. Few IoT devices include local display and keyboard input options for providing provisioning information. Out-of-band methods such as the use of Bluetooth, NFC, or even USB to provide this information may be cost prohibitive, and add complexity to a design. Finally, the sheer number of devices in a large IoT application can make conventional provisioning methods impractical. In contrast, use of the same Wi-Fi medium for both provisioning and normal operations provides an attractive solution.

In practice, however, Wi-Fi provisioning has presented its own logistical and security challenges. To simplify this step for users, the wireless industry has evolved standards such as Wi-Fi Protected Setup (WPS). With WPS, users enter a personal identification number (PIN) or press a button (Push-Button Connect, or PBC).

The discovery of zero-day security flaws in WPS PIN mechanisms soured most users on this approach. Instead, a popular method, called AP mode, uses the device’s wireless connectivity to collect security credentials from the user. Here, the device temporarily operates as a Wi-Fi access point, creating a dedicated network. Users connect to this network with their mobile devices long enough to upload security credentials. After this provisioning step, the device switches to station mode and uses the newly supplied credentials to access the wireless network.

TI has supplemented these standard provisioning mechanisms with its own proprietary mechanism, called SmartConfig. In this approach, users load the network name (SSID) and password just once into their mobile devices. Any nearby IoT device can proactively scan for secure SmartConfig broadcasts and automatically load the encrypted provisioning information contained in the broadcast (Figure 4).

Figure 4: In the complete TI SmartConfig flow, users enter provisioning information, activate SmartConfig broadcasts from their mobile devices, and rely on the IoT device to automatically find the SmartConfig provisioning data. (Image source: Texas Instruments)

On completion, the CC3220-based IoT device can use its embedded Web server to notify the user, or simply upload its status to a cloud-based provisioning log. Using this approach, IoT developers can deliver a hands-off provisioning process that lets trusted IoT devices find their own way into secure IoT application networks.

Despite the apparent advantages of SmartConfig, the choice of provisioning method might hinge on other factors that dictate use of more conventional mechanisms, or even a combination of methods. The TI CC3220 wireless MCU provides the needed flexibility through its support of multiple provisioning methods. Along with the AP method and SmartConfig, the device allows developers to employ hybrid methods that combine AP with SmartConfig. Here, an IoT device can scan for SmartConfig broadcasts and respond to AP type interactions with the user, or automatically switch to AP mode if SmartConfig provisioning fails (see Figure 4 again).

In any of its supported provisioning methods, the network processor handles all aspects of the process including listening for SmartConfig broadcasts and loading the SSID and security credentials. The host’s involvement is limited to starting (or stopping) the process using a single command, WlanProvisioning:

_i16 sl_WlanProvisioning(_u8 ProvisioningCmd, _u8 RequestedRoleAfterSuccess, _u16 InactivityTimeoutSec, char *pSmartConfigKey, _u32 Flags);

ProvisioningCmd. This allows the host to start provisioning with a supported CC3220 provisioning method or stop the provisioning process. Breaking it down:

• RequestedRoleAfterSuccess indicates whether the IoT device should switch to station mode or AP mode after successful provisioning.
• InactivityTimeoutSec indicates when the device should automatically stop an incomplete provisioning process.
• pSmartConfigKey provides a secure key used to encrypt the provisioning credentials on the mobile side and decrypt them on the IoT device side.
• Flags : This provides specific configuration details used in the process.

Finally, the call returns STATUS_OK or various diagnostic error messages.

For the mobile side of this process, TI provides its SmartConfig API in a set of libraries for Java, Android, and iOS, allowing developers to embed the provisioning process in their mobile apps. As with the IoT device side, a mobile app starts SmartConfig broadcasts with a single command, using the TI SmartConfig class object (Listing 2).

try {

   smartConfig = new SmartConfig(smartConfigListener, freeData, passwordKey, paddedEncryptionKey,gateway, SSID, (byte) 0, "");

} catch (SocketException e) {

  Log.e(TAG, "Failed to create instance of smart config");

return;

}

Listing 2: Mobile app developers need only a single call to the TI SmartConfig library to invoke the SmartConfig provisioning in their smartphones or other mobile devices. (Code source: Texas Instruments)

Conclusion

For IoT developers, secure Wi-Fi connectivity and provisioning can present multiple challenges, not only in design cost and complexity, but also in eventual deployment. In the past, those challenges have forced developers to select between application features and security.

Utilizing its embedded features for secure connectivity, the TI CC3220 wireless MCU can significantly simplify design and deployment of devices able to support robust end-to-end security in IoT applications.