Adding M2M security to RTOS-enabled MCUs, MPUs or FPGAs
In light of the continuing move toward ubiquitously connected devices using protocols such as machine-to-machine (M2M), security of the networks – mostly wireless – is of primary concern. It is still a dangerous world out there, with many who wish to disrupt society and the critical infrastructure that makes this connectivity possible.
Good security for an MCU, MPU or FPGA based embedded wired or wireless machine-to-machine (M2M) system, especially in today’s ubiquitously connected – but hackable - world, requires the following, all done using standard encryption algorithms:
- Network communication security using TLS
- Virtual private network security (VPN) using IPSec
- Secure login and system interaction using SSH
- Secure file transfer using SFTP
- Secure email – encrypted email and secure mail server links
- Secure web server – https
- Secure management – SNMP v3
- Secure boot using an encrypted and checked image
This article is based on our experience at Rowebots implementing these capabilities in our software. We briefly discuss each one of these areas as it applies to M2M as well as overall system level concerns. M2M systems require high security to safeguard information and systems. Without this seamless integration and testing, security holes will exist and systems will have vulnerabilities with potential dire consequences.
Network communication using TLS
In M2M systems, the wireless links, regardless of the radio type all have some sort of encryption to safeguard the wireless data. Within a node or between wireline nodes the payload data is in the clear in a mixed wireline/wireless system. One approach is to use transport layer security (TLS). TLS runs as an end-to-end encryption between two nodes in the network to ensure that overall the data is always secure regardless of the path it takes.
As shown in Figure 1, TLS is easy to set up and use and for this reason it is the favored method of communication security. Typically implementations adhere to the de facto openSSL interface standards for application portability. This API works as a presentation layer for the socket interface to provide security for an application.
Providing a TLS layer above socket communication will secure the communication through the socket for the secure application, while using sockets directly leaves communication non-secure with all data transmitted in the clear.
Virtual Private Networks (VPN) using IPSec
Sometimes, all communications between two points in the network are required to be secure. In this case, a VPN is set up (Figure 2). This protocol is internal to the TCP/IP implementation and encrypts all packets travelling between two nodes. Because IPSec works as part of the networking layer, all socket calls between the nodes will have automatic encryption.
Figure 2: Using a VPN and IPSec between two nodes can secure application communications for all traffic between the nodes.
One could ask, well why don't we just use this and nothing else everywhere. There are two reasons we don’t. The first is pretty easily understood: the VPN is just much more problematic to setup. For this reason it is not used as much.
The second reason is that the best security is built up in layers. By providing layers of security it is much more difficult to break in. Think of this like multiple locked doors to get into the vault – each layer makes the job more difficult. For this reason it is best to use more security than just a VPN.
To login and work on a remote system, telnet is often used on small systems. Today, by adding extra flash space, you can run Secure Shell (SSH) (Figure 3). SSH is like a secure telnet. But it is not telnet over TLS. SSH is its own protocol. It provides secure shell access with an SSH server running on the MCU.
Figure 3: SSH replaces Telnet providing secure communication between nodes. MCU offerings only provide SSH-Server which will allow remote clients to login and manipulate data without security concerns.
Currently no items