Challenges and solutions
CAN messages contain payloads of only a few bytes and need
to be processed in real-time by occasionally tiny microcontrollers with little
resources and that don’t have any security hardware features.
The CANcrypt system adds different levels of security
features to CAN. The basic functionality provided supports the grouping of
multiple devices and supports authenticated communication between them based on
a secure heartbeat. The required system resources are not only minimal in
comparison to traditional cryptography methods, they can also be scaled towards
the application’s security requirements. On the higher end, CANcrypt supports
AES-128 based encryption and authentication.
A key hierarchy allows the implementation of a smart,
simplified key management supporting manufacturers, system builders/integrators
The CANcrypt system is protocol independent and can be
used with CANopen or other higher-layer CAN protocols. Up to 15 devices can
participate in the secure communication. A manager / configurator is only
required for the generation and exchange of keys, but not during regular
Limitations and levels of CAN security
Looking at CAN/CANopen systems we can identify three
threat levels. These apply to most applications including automotive,
industrial, medical and other machinery. These are:
- Unlimited physical access
- Sniffer access
If an intruder has “unlimited physical access to
the entire network including device PCBs,” then security options available are very
limited. Having potential access to all debug ports of the microcontrollers of
a system provides many other attack vectors besides CAN. This aspect is not
covered by CANcrypt.
Once an intruder has direct bus access to a CAN/CANopen
system, he has read access to ALL communication on the network. If he has write
access, then “denial of service” style attacks (swamping the bus with messages
so that nothing else gets through) are easy and cannot be prevented.
The last attack vector becomes more and more popular:
remote access through some device that is a gateway to other networks. Remote
diagnostics or other kind of remote access becomes more and more common, also
increasing the security risk.
A manufacturer of a system using CAN/CANopen
might not be fully capable of prohibiting a remote access device. Maybe such a
remote access device is added by some technician or system integrator after
delivery and initial installation.
Choosing cipher algorithms
Since the security algorithms are required to perform in
real-time even on the smallest of microcontrollers, CANcrypt puts the emphasis
on using “one-time pads”. One time used random keys. True one-time pads provide
the highest level of security. They are more secure than any commonly used
encryption methods on the Internet.
However, how much security is really required?
In CANcrypt “pseudo one-time pads” are used. The quality of the one-time pad is
configurable. All parameters for performance and security can be finely tuned
in the CANcrypt configuration. The default demo implementation uses variations
of the Speck Cipher or AES-128.
CANcrypt key generation and shared dynamic keys
For key generation, CANcrypt uses a method that allows
two devices to exchange a bit not visible to other CAN devices. This allows
generating pairing keys that only the two participants know. This feature is
key (no pun intended) to make the approach work and exchange keys between
The base security functionality of CANcrypt is a
mechanism to maintain a symmetric dynamic key shared among the grouped or
paired devices. This key is initialized based on a permanent key from the key
hierarchy and then modified frequently. Depending on configuration this can
happen multiple times per second. In Pairing mode, update happens by introducing
single random bits, in grouping mode, encrypted random data is shared and added
via the secure heartbeat. The picture to the right illustrates how the shared
random data is used to update the shared key.
Key hierarchy and management
Secured embedded systems require some sort of a key
management system. When keys are installed, who installs which keys and how
much “authority” does each key have?
In CANcrypt, the suggested method is to keep the number
of key copies required outside the system to a minimum. At some point a pairing
process is started generating keys – and these are only stored locally.
If at a later point devices need to be added or
exchanged, a next higher authorized key is used to erase the existing pairing
information and start a new pairing process.
The secure CANcrypt Heartbeat
If authentication is the primary requirement, then the
secure Heartbeat functionality is all that is required. In this mode, all
CANcrypt devices continuously monitor the network for injected messages. As
long as a device can transmit it's messages OK and does not detect injection
activity, it produces a secure heartbeat. As long as the secure heartbeats are
present, the communication is authentic. Devices detect injected messages, by
monitoring the communication for their "own" used CAN transmit CAN
IDs. If a message is received that uses a CAN ID used by this node, then this
is considered an injected message.
The core of the secure heartbeat is a 32bit signature
containing three random bytes and a checksum byte. All 32bits are encrypted
based on the current shared dynamic key. Receivers decrypt the signature and
verify the checksum to verify authenticity.
All secure CANcrypt communication uses a preamble message
announcing the data message to follow. The data message may be partially or
fully encrypted. A signature in the preamble ensures authenticity. Messages
received are only accepted (passed on to application) if together with the
preamble the authentication and decryption is successful.
The CANcrypt functionality is mostly integrated into the
“driver” level like the CAN receive interrupt and the software transmit
mechanism (typically some FIFO).
During the initialization of CANcrypt, the application
passes a list of CAN message IDs that require protection. The CANcrypt driver
then “catches” all these messages coming in or out and applies the configured
security features. The messages are only passed on to other layers of the
communication protocol if the device is securely paired with its communication
partners and the configured ciphering and authentication mechanisms have been