Adding M2M security to RTOS-enabled MCUs, MPUs or FPGAs -

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.

Figure 1: TLS secure end-to-end communication

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.

Secure Shell
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.

Secure File Transfer
Just because you use a login ID and apassword to use the file transfer protocol (FTP), many think that thisis secure transfer. The truth is that even the password is sent acrossthe network in the clear. It is better to use the secure file transfer protocol (SFTP). SFTP is not about FTP running over TLS. Rather, as shown in Figure 4 , it is another special protocol for encrypted file transfer.

Figure4: SFTP is a new protocol which supports encrypted and authenticatedcommunication for file transfer replacing FTP which transmits all datain the clear.

Secure email
Traffic between mailservers is protected using TLS. But TLS only ensures that onlyauthorized and authenticated users can use the server and that anyonemonitoring network traffic cannot read the mail. For this reason if youare using SMTP to send notifications from an M2M sensor device based onan MCU, you also need TLS if you want to do it securely (Figure 5 ).

Ofcourse the security used on the servers does not apply to the contentsof the message in any given node. For this reason, the messages need tobe both signed and encrypted to ensure message security.

Figure5: SMTP transmission using TLS ensures that only authorized users usethe email server and that the data is sent privately. If the message isencrypted and signed before being sent, the message can be authenticatedand ensured to be private to those that have the correct keys for themessage.

Secure Web server access
To have security for web page access and data transfers use HTTP Secure . HTTPS support is required for the Web server (Figure 6 )in any M2M configuration. This is implemented using TLS along with HTTPprotocol. With it, the Web server itself gets decrypted packets toprocess and provides unencrypted pages which are encrypted beforetransmission.

Figure6: Browsers are intelligent enough to connect using http over TLS tosupport secure web access. The http server also accepts requests overTLS providing secure web page access and updates.

Secure Management
To manage remote devices, often the Secure Network Management Protocol (SNMP) is used. SNMP provides a means to look inside the device,reconfigure it, perform various commands, retrieve data, retrieve logs,and set variables. To do this the latest secure version (SNMP v3) isrequired (Figure 7 ). Many implementers try to do this with earlier versions of SNMP but these are not secure.

Figure7: SNMPv3 support is required in both the client and the server to havesecure management support. With only SNMPv1 and 2c support in theserver, there is no encryption or authentication. For complete securityboth encryption and authentication are required.

Secure boot
Whenperforming remote field updates on a system, a secure system todownload a new image, reflash the device, and make sure it is workingproperly is required but is often overlooked. Without a secure boot, newimages could be loaded on a device and control could be subverted oralgorithms modified with dire results.

System security Issues
Allof these security services need to work in conjunction with theoperating system. To think that this level of sophistication could bedone without an RTOS is just wishful thinking. Only with seamlessintegration of these components into the operating system followed byrigorous testing can security be guaranteed.

Some try to provideadd-on modules for these multiple security functions but without OSintegration and testing it is easy to leave security holes. Withseamless integration and factory-based testing, security is improved andrepairs – if needed – can be done on a system-wide level.

Kim Rowe is the founder of RoweBots, which offers the Unison RTOS along with complete one-stop product development to OEM developerstargeting the Internet of Everything. Kim has 30+ years of experience insystems engineering and holds both an MBA and an MEng. 

5 thoughts on “Adding M2M security to RTOS-enabled MCUs, MPUs or FPGAs

  1. I've been advised that it is also necessary for endpoint devices to be configured to allow outbound connections only, so that there is not an open port for hackers to find. This requires them to periodically poll their server to see if there are any messag

    Log in to Reply
  2. It is true that on all systems, filtering should be enabled to exclude incoming messages on any unused ports (think firewall features). One solution to the lack of filtering or firewall capabilities in the embedded stack is the elimination of any incomi

    Log in to Reply
  3. Yes, what about the overhead of having all this protection? What kind of memory resources are needed, what processing power, and how does the protocol overhead affect things like the time awake and transmit duration for systems trying to survive on really

    Log in to Reply
  4. The compute time goes up as the length of the key increases. There is hardware accelerators included in many chips today to reduce this costs. Typical costs for AES are: +20% for 128 bit to 192bit and +40% for 128 bit to 256 bit keys.

    Of course, some se

    Log in to Reply
  5. This is a great comment Rich because as engineers we ultimately trade off cost, features and performance. An experimental approach is required in this case.

    In terms of performance, for all these small connected devices, really all you can do is test the

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.