What is Security?

A few weeks ago, Lars Lydersen shared his thoughts on steps the industry needed to take to improve IoT security, and this week applications engineer Ken Berringer kicks off an ongoing series focused on how we can do that.

As an embedded engineer at Silicon Labs, I know that everyone is concerned about security; however, their concerns and needs depend on what they are trying to protect. When it comes to wireless Internet of Things (IoT) devices, I can group most of the security concerns into three categories:

• Encrypted Communications
• Physical Flash Security
• Software Application Security

My team works on adding security features to address this concerns on all of our low-energy microcontrollers (MCUs) and wireless systems-on-a-chip (SoCs). Let’s dive into these three concerns.

1. Encrypted Communications

Encrypted Communications protects the information transmitted over wires, or wirelessly over the air. Most wireless IoT protocols use some form of the Advanced Encryption Standard (AES) cipher. Encrypting sensitive information transmitted over the air will protect against eavesdropping or someone hacking into the network.

Over-the-air encryption is built into the ZigBee, Bluetooth Smart, and Thread protocol stacks. Therefore, if you’re working on top of a wireless stack, you don’t need to know all of the gory details of things like the cipher block mode.

However, it is helpful to have a fundamental understanding of why it’s important. The basic AES cipher has a block size of 16-bytes. To improve security for message longer than 16-bytes, many protocols use a cipher block mode, such as the counter mode, to improve security. This effectively changes the cipher for each block and adds an additional measure of security.

To ensure that a message is not tampered with, many protocols use an authenticated block cipher mode. This mode includes an authentication code for each message to ensure data integrity and provide a fingerprint that is unique to the originator’s key.

Bluetooth Smart, ZigBee, IEEE-802.15.4, and Thread all use some form of the counter cipher block mode for encryption and CBC-MAC (Cipher Block Chaining Message Authentication Code) for authentication.

2.  Physical Flash Security

Physical Flash Security for an embedded processor, this is the degree of protection against someone physically connecting to the pins of the device and reading out the code. For a low-energy microcontroller or wireless SoC with embedded Flash, there is a three-step process for physical security.

• Lock the entire Flash
• Disable the normal debug connection
• Use a secure bootloader to upload encrypted firmware.

If these three steps are followed, the firmware on the device is very secure. Once the Flash is locked and the debug connection is disabled, even the manufacturer will not be able to read out the Flash contents. (This may limit Silicon Labs' ability to process a Return Materials Authorization.)

Physical security is not quite as secure as encrypted code. If the Flash contents are not encrypted, it is theoretically possible that someone with expert knowledge and sparing no expense might read out the Flash contents. Even for someone with expert knowledge and the expensive equipment required, this is still an expensive proposition. The economic deterrent is high enough to dissuade most hackers.

A higher level of security is possible by encrypting the code in Flash and using a run-time decryption algorithm to decrypt the code from Flash and run from RAM. However, run-time decryption is difficult to manage, requires a lot of RAM, and will have a performance/energy penalty.

3.  Software Application Security

Software Application Security is the ability to secure some portion of the software against other software running on the same platform. This is important if one person develops the communication stack and someone else develops the application. If the stack provider delivers source code or a linker library, it is easy for the application developer to develop application code on top of the stack. However, this also exposes the stack assembler code to the application developer.

Often there are more than two parties involved. For example, the stack developer might want to use a third party library. However, the stack developer needs to protect the third-party library code from the application code.

A secure application environment, would allow an untrusted application developer to develop an application on top of secured code. The untrusted developer would not have access to the secured assembler code or be able to reverse engineer the secured code. The ARM mbed OS provides this kind of application security using the mbed OS uVisor. Future microcontrollers will improve the performance of this solution.

What are your thoughts? What is the biggest security concern keeping you up at night?

Coming Up on this Blog

This is the first blog of a series on security. Upcoming blogs will go into more detail on these topics:\

• Encryption and cipher block modes for data security
• Secure Hash Algorithms and Authenticated Modes
• Galois Counter Mode
• Key Exchange using Elliptical Curve Cryptography
• Digital Signatures using Elliptical Curve Cryptography