CAN AUTHENTICATION AND ENCRYPTION February 2017 CAN PROVIDES - - PowerPoint PPT Presentation

CAN AUTHENTICATION AND ENCRYPTION

Implementing scalable CAN Security with CANcrypt

by Olaf Pfeiffer

CAN PROVIDES MULTIPLE ATTACK VECTORS

 Record and re-play

messages

 Can trigger desired actions

 Re-engineering

 Monitor and analyse

 Inject messages

 Denial-Of-Service (DOS)

attack

 Generate selected

commands

February 2017 CANcrypt

CHALLENGES OF CAN SECURITY

 Small message size

 Single byte command  Sometimes „known“ data

 Limited resources

 Microcontrollers with

limitations on code and RAM size

 Can security be added to

existing communication?

February 2017 CANcrypt

 Popular security methods

 Require a minimum of

128bit block sizes, preferably larger

 Can not easily (real-time,

witin microseconds) be handled by microcontrollers without on-chip security

February 2017

″KEY″ ELEMENTS

CANcrypt base functions and protocols

CANcrypt

CANCRYPT SOFTWARE FRAMEWORK

 Customizable security

functions

 Simple bit mixup for lower

performance microcontroller

 Key Management

 Key Hierarchy

 Secure key transfers

 Slow but invisible CAN

communication

 Shared bit generation

 Grouping

 Based on inital shared key

 Permanent or last sessison

 Secure heartbeat

 Updates shared dynamic key

 Pairing

 Based on inital shared key

 From a key hierarchy

 Updated shared dynamic key

 By invisible shared bit generation

February 2017 CANcrypt

CANCRYPT‘S KEY HIERARCHY

 CANcrypt is based on

shared symmetric keys

 Configurable length  Multiple keys per device

provide a key hierarchy

 Key can be combined with

serial number

February 2017 CANcrypt

DYNAMIC KEY

 To prohibit record and replay

attacks

 Key must cyclically change

 Key must be synchronized  Key update based on

 Shared random values  Permanent key  Counters and or data

CANcrypt

ONE-TME PAD SECURITY LEVEL

 If a random key is as big as the data encrypted  and the key is only

used once,

 then a simple XOR  provides strongest

encryption / security level

February 2017 CANcrypt

CANCRYPT‘S ONE TIME PAD

 How close can we get to a

“true” one-time pad?

 Or: how close do we need to get

to a “true” one-time pad?

 Highest level not required

 Here: based on dynamic

key with input from

 Permanent key  Message counter  Optional: last data

February 2017 CANcrypt

February 2017

MINIMAL EFFORT AUTHENTICATION

Monitoring, grouping and secure heartbeats

CANcrypt

MINIMAL PRECAUTIONS

 All devices must monitor

network for injected / unexpected messages

 Look for CAN IDs used for

transmission

 Produce an alert / emergency

if such a message is detected

 NOTE: this is already done

by CiA 447 profile devices

February 2017 CANcrypt

SECURE HEARTBEAT GENERATION

 Uses dynamic one-time pad  Consists of

 3 random bytes  1 byte checksum

 Initializer from one-time pad

 All 4 bytes XOR encrypted

using one-time pad

February 2017 CANcrypt

SECURE HEARTBEAT CONSUMER

 Consumer decrypts the 4

bytes of secure heartbeat

 Calculates the checksum  On match, continue  All random bytes are used by

all participants to re-generate

• ne-time pad

February 2017 CANcrypt

GROUPING AND HEARTBEAT PROTOCOLS

 Initial pairing requests

include information about which key from hierarchy to use as a base

 Participants synchronize

themselves with the grouping / heartbeat cycles

February 2017 CANcrypt

SO FAR: AUTHENTICATED COMMUNICATION

 All producers

 Monitor network for

unexpected messages

 On detection

 Send alert

 Else

 Send secure heartbeat

 All consumers

 On receive of messages

handle them as not yet authenticated

 Authenticated by next

secure heartbeat cycle

 Depending on driver

implementation and FIFOs

• ne extra cycle might be

required

February 2017 CANcrypt

February 2017

SECURITY FOR PAIRED DEVICES

Pairing and secure messaging

CANcrypt

CAN SPECIFIC SECURITY: PAIRING

 If 2 nodes randomly select a

CAN ID to transmit

 Example: range 10h to 1Fh  No data

 and transmit these

synchronized,

 then an observer does not

know who transmitted which message

 Exception:

unless observer has signal level access

 advanced attack scenario

 The 2 nodes know who

sent what and can derive 1 bit from this information

February 2017 CANcrypt

GENERATE A SECRET RANDOM BIT

February 2017 CANcrypt IF I am the configurator device IF I transmitted lower bit generation message common bit is 0 ELSE IF I transmitted higher bit generation message common bit is 1 ELSE both used same message, no bit determined ELSE I am a device IF I transmitted lower bit generation message common bit is 1 ELSE IF I transmitted higher bit generation message common bit is 0 ELSE both used same message, no bit determined

PERFECT ONE-TIME PAD IS POSSIBLE

 The 2 pairing nodes need a

“good” random number generator

 Shared permanent key used

to selectively flip bits

 Ensures authentication,

shared bits are only identical if both have the same permanent key

 Performance not suitable

for larger data blocks

 But good enough to

securely transfer keys

 128 bit key, about 1.6s  256 bit key, about 3.2s

February 2017 CANcrypt

SECURE MESSAGING

 One-time pad security  Two messages  Unused bytes filled with

random data

 Ensures size of 128 bit  AES or other can be used

 16 bit checksum

February 2017 CANcrypt

SUMMARY

Implementing scalable CAN Security with CANcrypt

 Grouping

 Authentication by secure heartbeat

 Pairing

 Secure messaging between two devices  Configuration, key transfers

 Key management

 Key hierarchy

 Customizable security functions

www.esacademy.com/cancrypt