RSS Feed

Embedded Systems Blog

News from iCC17 & EW17, CANcrypt released

March 20th, 2017 Olaf No comments

The last two weeks were very exciting for us: We held several papers at the International CAN Conference and Embedded World (both in Nuremberg, Germany), participated in the first CANopen FD demonstrator at both events – with the new NXP LPC54618 – and finally released our book “Implementing scalable CAN security with CANcrypt”.

The CANopen FD demonstrator at the CiA (CAN in Automation) booth showed one of the new features of CANopen FD: segmented broadcast of larger data blocks with “Universal Service Data Objects” (USDOs). This feature can be used to broadcast images, configuration tables or even firmware updates. Here, any participant could be commanded to broadcast an image to all other participants. Such use cases were almost unthinkable with classic CANopen communication.

At Embedded World, PHYTEC showed a Nano Dimension 3D printer for PCBs. Prototyping your printed circuit boards just became a lot easier and faster. The circuits are printed with a highly conductive ink. It looks like the machine can directly produce boards from Gerber files.

At the NXP booth, one of the demos featured the NXP LPC54618 microcontroller with two CAN FD interfaces. The “FD” (Flexible Data rate) allows the data portion of a CAN message to be transmitted at higher bit rates. So far, classical CAN was limited to 1 Mbps. With currently available transceivers the data rate can now be up to 5 Mbps. Also in CAN FD, the maximum payload for each message is 64 bytes compared to eight bytes in traditional CAN. The demo compared different firmware download speeds. Using CAN FD, updates can now be transferred multiple times faster than before.

The release of our book about CANcrypt (www.cancrypt.eu) stirred a lot of interest and we had many engaged discussions, also with some security experts. CANcrypt is a security framework and the security level actually used is configurable. As usually, there is a trade-off: the more security you require, the more resources both in CPU time as well as in memory space you need. For a configuration on the upper end of security, proven encryption methods like AES-128 can be used. It will be interesting to see if the lower-end lightweight “Speck” cipher reaches adequate security levels, too.

A first potential weak spot in one of the initial published configurations (user section, where user’s are setting up their own security configuration) was already discovered and is currently improved. The encryption of the secure heartbeat accidentally used only limited parts of the shared dynamic key, reducing the effective key to 32-bit. However, CANcrypt supports key sizes of up to 1024-bit. The next release will use a demo where a larger key is applied properly.

To learn about our bounty program, stay tuned by joining our mailing list or following us on twitter . Within the next few weeks we will start such a program to encourage others to search for possible flaws in the CANcrypt implementation.

CANcrypt technical functionality

February 26th, 2016 Olaf No comments

A summary of the technical features used by CANcrypt

By Olaf Pfeiffer, Embedded Systems Academy GmbH, 26th of February 2016

At the Embedded World 2016 in Nuremberg, Embedded Systems Academy GmbH announced their book “Implementing Scalable CAN Security with CANcrypt”. The corresponding CANcrypt demo code will be published using an open license. At the Embedded World we have seen a lot of interest in the technical details. For those who do not want to wait until the publication of the book this article summarizes the key technical features of CANcrypt (also see our CANcrypt.eu web page for more information).

Core Functionality of CANcrypt

CANcrypt provides the following services:

  • Pairing: dynamic generation of a random key that is only known by the paired devices; optionally, one device can enforce a preset key to the other.
    • generate and exchange keys
    • optional storing of keys in non-volatile memory for permanent pairing
    • support of a key hierarchy when multiple keys are stored
    • maintain dynamically changing key (pseudo one-time pad)
    • dynamic key updated using shared random bit
  • Grouping: multiple devices share a common dynamic key
    • originally assigned through pairing
    • maintain dynamically changing key (pseudo one-time pad)
    • dynamic key cyclically updated by all grouped devices
  • Safety communication: any secure communication uses a preamble message
    • messages received are only accepted and passed on to application if together with the preamble the authentication and decryption is verified successfully
    • preamble identifies message CAN ID, security features used, has a counter and a signature
    • secure messages must be received within 10ms after the preamble to be valid

CAN message IDs required:

  • one CAN ID for each participating device
  • used for preamble and control messages
  • a CAN ID pair used for the random bit generation cycle

Cipher methods used

CANcrypt keys are symmetrical and dynamic, they are continuously updated. From the dynamic key and a message counter a pseudo one-time pad is generated that is used for the simple, customizable encryption.

If the secure pairing is only active for two nodes, a random bit generation cycle is used continuously in the background to introduce new bits to the dynamic key. If multiple nodes are paired, then the dynamic key update information is sent via an encrypted message.

The system pairing process is started using a CANcrypt configurator device. This can be done by a system builder or integrator once the CAN system is installed. It must happen in a secure environment. The keys generated at that time are stored locally in the devices connected – there is no need to keep any further copy of this key outside the system, minimizing the effort placed on key management. The keys cannot be duplicated. If a new device is added (or one exchanged), all keys need to be erased and newly generated.

As stored keys in each device make up a hierarchy, we can guarantee that erasing and regenerating keys can only happen when the configurator used is logged-in to the system based on a key high enough in the hierarchy to allow erasing and re-paring.

Operating principle for random bit generation

Bit generation cycle

Solely by monitoring CAN messages, one cannot identify the device that sent any individual message, because at that level, any device can transmit any message. As an example, let us allow two devices (named initiator and responder) to transmit messages with the CAN IDs 0010h and 0011h (and data length zero) within a “bit select time window”. Each node shall then randomly choose and send one of the two messages at a random time within the time window.

At the end of the bit select time window, a trace recording will show one of the following scenarios:

  1. One or two messages of CAN ID 0010h
  2. One each of CAN ID 0010h and 0011h
  3. One or two messages of CAN ID 0011h

Let us have a closer look at case 2 – one each. If these are transmitted randomly within the bit response time window, then an observer has no way to identify which device sent which message. However, the devices themselves know it and use this information to derive a bit from it.

Unfortunately we cannot use case 1 and 3, so if those happen, both nodes need to recognize it and re-try, using another next bit select time window.

Note 1: If one device wants to enforce a specific bit to the other, it may generate a “flip bit” message at the end of the cycle to indicate to the other device that this bit needs to be flipped.

Note 2: A variation of this scheme is to not use a random delay, but instead ensure that both devices transmit their message immediately after the trigger message. Then both messages arbitrate the bus at the same time and in a trace recording we will always see 0010h followed by 0011h.

Potential attacks: As usual, a denial-of-service kind of attack is always possible. By injecting messages an attacker can break the cycle, the devices would not be able to exchange a key in the first place. If an attacker has full physical access (oscilloscope, transceiver), he can determine which node sent which message. However, there is still some effort required to recognize which bits were actually generated (as participating devices can change interpretation). Last but not least anything “random” is always an attack vector. The participating devices need a reasonably good random number generator.

Book announcement: Implementing Scalable CAN Security with CANcrypt

February 22nd, 2016 Olaf 1 comment

Nuremberg, 22nd of February 2016: Embedded Systems Academy announces their new book “Implementing Scalable CAN Security with CANcrypt”. You can meet the authors at the Embedded World 2016 from February 23rd to 25th in hall 1, booth 620 – the booth of our partner PEAK-System.

The book covers authentication and encryption for CANopen and other Controller Area Network protocols and will be published in Q2/2016. The introduced CANcrypt system by ESAcademy adds multiple levels of security to CAN. CANcrypt supports the grouping of multiple devices and the encrypted and authenticated communication between them. The CANcrypt security layer sits between CAN driver and higher layers and is therefore independent of higher-layer protocols or applications used.

The required system resources are minimal compared to traditional cryptography methods and can be scaled to the application’s security requirements. A key hierarchy enables implementing of smart, simplified key management that supports manufacturers, system builders/integrators and owners.

Demo and example code will be published using the BSD license.
For more information see www.cancrypt.eu

Misc News as of February 2016

February 15th, 2016 Olaf No comments

It is a busy start into 2016 with several new products and the Embedded World 2016 coming up next week.

New product – CANopen Logxaminer
Last year, we spent a lot of time helping clients to evaluate long CAN trace recordings and searching for misbehaviour of CANopen devices as well as manually generating statistics about such behaviour. In order to simplify such trace evaluations we wrote a dedicated utility that evaluates CANopen trace recordings. It supports common file formats used by recording tools from PEAK, Vector and ESAcademy.

For more information about the CANopen Logxaminer, follow the link.

New book about CAN security
Within Q2/2016 we will publish a new book, this time about CAN security. Recent publicized hacks show that CAN/CANopen are quite vulnerable, once an intruder/attacker has access to the network. Our new book introduces a scalable method that addresses both authentication and encryption, is independent of the protocol used and free sample code will be provided. A more detailed announcement will be published in our blog at www.esacademy.com/blog next week.

New 2016 price list
Our new 2016 price list is now valid, for current prices visit our CANopen online stores in Europe or USA. Prices have been lowered for the low-level entry version of our CANopen Magic tool as well as for the CANopen Magic high-end version including DLL access for custom test tool developments.

Next week’s Embedded World 2016
This years show in Nuremberg from February 23rd to 25th has almost 1000 exhibitors. For a complete list see
www.embedded-world.de/en/ausstellerprodukte/exhibitorlist

You can meet Chris or me (Olaf) from ESAcademy at the PEAK system booth. Hall 1, booth 620.

If you can not make it to the show and are still interested in selected news and updates, follow Olaf at twitter.com/ESA_Olaf or re-visit our blog after the show for a summary of impressions.

Looking forward to seeing some of you in Nuremberg

Olaf Pfeiffer