The NoCAN IoT platform created by OMZLO enables the creation of a very reliable wired network composed of Arduino-compatible nodes connected through CAN bus, targeting application domains where wireless approaches are not satisfactory. Each node features a 32-bit ARM cortex micro-controller (SAMD21G18) and the network is managed by a Raspberry Pi. The Raspberry Pi acts as a gateway, enabling connections between the CAN bus network and the outside world, through MQTT,, HTTP, and more.

This blog post describes a new security mechanism we introduced in version 0.3.1 of our tools in NoCAN. It breaks compatibility with previous versions of our platform, but we believe it is a necessary step forward.

A wrong assumption

As illustrated in the picture below, the NoCAN platform has three main types of networking interactions:

  1. Network exchanges taking place on the CAN bus, involving embedded nodes as well as the PiMAster HAT.
  2. Exchanges between nocand, the Raspberry-Pi node manager, and nocanc, a control interface designed to run on the Raspberry Pi or other devices in the local network.
  3. Exchanges between nocanc and the outside world, through MQTT, blynk, etc.

NoCAN security

When the NoCAN framework was created, we imagined a simple security model.

First, we made the assumption that communications on the CANbus are secure. If an adversary has physical access to your CAN bus network and is able to access the bus, listen to, or inject traffic, you probably have bigger problems than CAN-bus security.

Second, we assumed that most users would run nocanc, the control interface, on the Raspberry-Pi gateway or on another machine in the same local network. To this end, nocanc is designed to run not only on a Raspberry-Pi but also on Linux, macOS, and Windows. In terms of security, the connection between nocanc and nocand is protected by an authentication token but is not encrypted nor protected against alterations.

Third, when nocanc is used to connect to external services such as MQTT or blynk, the user can take advantage of the security mechanisms that are offered by these services, such as TLS.

While the first and third assumptions are largely still true today, we found out that the second one is less defensible. For many applications, communications between nocanc and nocand take place over a trusted network and the use of a simple authentication token, much like a password, is good enough. However, we saw applications where the assumption of having a trusted network was not valid. We decided that it was time to look at a mechanism to protect the confidentiality and integrity of communications between nocanc and nocand.

New security design decisions

As of version 0.3.1, all communications between nocanc and nocand are secured with a mutually agreed authenticated AES-128 key, which is then used to encrypt and authenticate communications using Gallois Counter Mode, in what technically constitutes 'AEAD' or authenticated encryption with associated data.

NoCAN offers the possibility of connecting a CAN-bus network to the outside world through MQTT,, HTTP, and more. But not all NoCAN applications take advantage of this connectivity and work instead in a closed environment isolated from the internet. As such, many NoCAN applications will not have access to public key infrastructures. Using SSL/TLS as a transport protocol securing communications between nocanc and nocand meant potentially requesting users to perform complex configuration tasks, and sometimes entering the murky business of self-signed certificates. The decision was to focus on simplicity and focus on a shared secret, rather than public-key cryptography and certificates.

As a consequence, users of nocanc and nocand are simply required to pick an authentication token, as they did already in previous versions. The syntax of the configuration file remains the same. The only difference is that users are required to pick an authentication token that is at least 24 characters long. Under the hood, however, things change dramatically, since the authentication token is not just used for authentication, but also to derive a session key that is then used to secure communications both in terms of confidentiality and integrity.

Another design decision was to make this new security mechanism mandatory. Experience shows that allowing the option of configuring less secure communications or "downgrading" security is usually a bad idea. Since we are only using symmetric cryptography, the added computational cost of securing the channel remains minimal.

The establishment of the secure channel is done in two steps:

  1. Authenticated key agreement: The security token is used to mutually authenticate the communicating parties (i.e. the nocanc and nocand tools) and establish a session key.
  2. Message encryption and authentication: The session key is used to encrypt and authenticate all messages exchanged between the communicating parties.

The authenticated key agreement is based on the work of Bellare and Rogaway on Entity Authentication and Key Distribution. The message encryption and authentication is provided through AES used in Gallois Counter Mode, as defined by NIST in SP800-38D.

Upgrading your system

To continue operating with the new security mechanism, most users will need to update their configuration files to select an authentication token that is at least 24 characters long. This means:

  • Upgrading the .nocand/config file on the Raspberry-Pi NoCAN gateway.
  • Upgrading the .nocanc.conf file on all machines that run nocanc (the file is called _nocanc.conf on Windows machines).

For example, consider the following nocanc configuration file:

event-server = ""
auth-token = "secretpassword"

The auth-token value is too short to provide any reasonable security. A better option might look like this:

event-server = ""
auth-token = "6NJfaCFwJhL79+b4TAclWyFpZZYKf8AmEdnvSsQr/tw"

In order to help users pick a good authentication token, a specific option was added to the nocand application. By typing the command nocand auth-token the user will get the following type of suggestion:

This is a randomly generated value for auth-token that you can safely use in your configuration files.

auth-token = "8XYFQmjLrHxqn7T8FIh6zb3STkG+jRZxDqvGyd/H4xU"

Copy and paste the line above into your nocand configuration file (e.g. '/home/pi/.nocand/config') on 
this machine as well as in the .nocanc.conf file(s) on hosts where you use the nocanc client. This will 
likely include the file '/home/pi/.nocanc.conf' here.

A bit of python

As a side effect of breaking compatibility with previous versions of nocanc and nocand, we were able to rework the communication protocol that takes place between nocanc clients and the nocand server. This protocol we call the the NoCAN event protocol over TCP/IP has been improved in many ways, and we will likely soon release a Python client for NoCAN: a very exciting development!

As a consequence, please note that the current documentation of the The NoCAN event protocol over TCP/IP is now obsolete and will need to be updated.

Let us know what you think of the new secure communication mechanism we introduce and if you find any bugs, please let us know in the forums!