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

Implementing scalable CAN Security with CANcrypt by Olaf Pfeiffer CAN AUTHENTICATION AND ENCRYPTION

February 2017 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 CANcrypt

February 2017 CHALLENGES OF CAN SECURITY  Small message size  Popular security methods  Single byte command  Require a minimum of 128bit block sizes,  Sometimes „known“ data preferably larger  Limited resources  Can not easily (real-time,  Microcontrollers with witin microseconds) be limitations on code and RAM handled by microcontrollers size without on-chip security  Can security be added to existing communication? CANcrypt

February 2017 CANcrypt base functions and protocols ″KEY″ ELEMENTS CANcrypt

February 2017 CANCRYPT SOFTWARE FRAMEWORK  Customizable security  Grouping functions  Based on inital shared key  Simple bit mixup for lower  Permanent or last sessison performance microcontroller  Secure heartbeat  Updates shared dynamic key  Key Management  Pairing  Key Hierarchy  Based on inital shared key  Secure key transfers  From a key hierarchy  Slow but invisible CAN  Updated shared dynamic key communication  By invisible shared bit generation  Shared bit generation CANcrypt

February 2017 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 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

February 2017 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 CANcrypt

February 2017 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 CANcrypt  Message counter  Optional: last data

February 2017 Monitoring, grouping and secure heartbeats MINIMAL EFFORT AUTHENTICATION CANcrypt

February 2017 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 CANcrypt

February 2017 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 CANcrypt

February 2017 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 one-time pad CANcrypt

February 2017 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 CANcrypt

February 2017 SO FAR: AUTHENTICATED COMMUNICATION  All producers  All consumers  Monitor network for  On receive of messages unexpected messages handle them as not yet authenticated  On detection  Authenticated by next  Send alert secure heartbeat cycle  Else  Depending on driver  Send secure heartbeat implementation and FIFOs one extra cycle might be CANcrypt required

February 2017 Pairing and secure messaging SECURITY FOR PAIRED DEVICES CANcrypt

February 2017 CAN SPECIFIC SECURITY: PAIRING  If 2 nodes randomly select a  Exception: CAN ID to transmit unless observer has signal level access  Example: range 10h to 1Fh  No data  advanced attack scenario  and transmit these  The 2 nodes know who synchronized, sent what and can derive 1  then an observer does not bit from this information know who transmitted which message CANcrypt

February 2017 GENERATE A SECRET RANDOM BIT 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 CANcrypt

February 2017 PERFECT ONE-TIME PAD IS POSSIBLE  The 2 pairing nodes need a  Performance not suitable “good” random number for larger data blocks generator  But good enough to  Shared permanent key used securely transfer keys to selectively flip bits  128 bit key, about 1.6s  Ensures authentication,  256 bit key, about 3.2s shared bits are only identical if both have the same permanent key CANcrypt

February 2017 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 CANcrypt

 Grouping Implementing scalable CAN Security with CANcrypt  Authentication by secure heartbeat  Pairing  Secure messaging between two devices  Configuration, key transfers  Key management  Key hierarchy  Customizable security functions SUMMARY www.esacademy.com/cancrypt