0% found this document useful (0 votes)
66 views39 pages

Dwf13 Amf Aut t0112 Detroit

The document summarizes security algorithms and standards used for automotive security applications. It discusses symmetric and asymmetric encryption algorithms like AES and RSA. It provides examples of common attacks on automotive systems like mileage manipulation and describes research studies on experimental security analysis of modern vehicles. The document also introduces Freescale's Qorivva security modules that provide hardware security modules to enable use cases like secure boot, immobilizer, and firmware updates.

Uploaded by

Curtis Lin
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
66 views39 pages

Dwf13 Amf Aut t0112 Detroit

The document summarizes security algorithms and standards used for automotive security applications. It discusses symmetric and asymmetric encryption algorithms like AES and RSA. It provides examples of common attacks on automotive systems like mileage manipulation and describes research studies on experimental security analysis of modern vehicles. The document also introduces Freescale's Qorivva security modules that provide hardware security modules to enable use cases like secure boot, immobilizer, and firmware updates.

Uploaded by

Curtis Lin
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

TM

Jürgen Frank
Automotive Sr. Systems Engineer

September 2013
• Introduction – Security, why?
− Use-case overview
− Attack examples
• In a nutshell: Security Algorithms
• Automotive Standards
• Freescale Qorivva Security Modules
− CSE & CSE2
− HSM

• Use-Cases
− Secure Boot

TM 2
• Immobilizer / Component Protection
− Detection of replacement or modification of components or ECUs
• Mileage Protection
− Disabling mileage manipulation
• Secure Boot and Chain of Trust
− Verification of authenticity and integrity of vehicle software
• Secure Communication
− Protection of the vehicle network from unauthorized access

TM 3
• Telematics and GPS
− Authentication of map data
− Enforcing permission limitations between open and safety critical
domains
• Android application download
− Ensuring permissions of apps are not exceeded
• DRM for content download/streaming
− Authentication that content is licensed
• Remote ECU firmware update
− Enforcing permission limitations between open and safety critical
domains

TM 4
Research Study 1: Experimental Security Analysis of a Modern Automobile,
Karl Koscher, Alexei Czeskis, Franziska Roesner, Shwetak Patel, Tadayoshi Kohno,
Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham,
Stefan Savage
IEEE Symposium on Security and Privacy, Oakland, CA, May 16–19, 2010
Center For Automotive Embedded System Security
[ http://www.autosec.org/pubs/cars-oakland2010.pdf ]

Research Study 2: Security and Privacy Vulnerabilities of In-Car Wireless Networks:


A Tire Pressure Monitoring System Case Study
Ishtiaq Rouf, Rob Miller, Hossen Mustafa, Travis Taylor, Sangho Oh, Wenyuan Xu,
Marco Gruteser, Wade Trappe, and Ivan Seskar
in Proceedings of the 19th USENIX Security Symposium, Washington DC, Aug. 11-13, 2010
[ http://www.cse.sc.edu/~wyxu/papers/TPMS2010.pdf ]

Mileage manipulation (in Germany)


• 2 million manipulated cars per year
• Average increases in value per car ~3000€
• Total loss 6 billion euro

TM 5
• Transportation Department Warns Against Counterfeit Air Bags
• October 10, 2012, NHTSA estimates it affects 0.1% of US Fleet,
availability of such replacement systems traces back to 2003 (!)

Video created & owned by National Highway Traffic Safety Administration


(NHTSA) [http://www.nhtsa.gov/]

• DARPA Funded Researchers Take Control Of two Cars


• Dr. Charlie Miller and Chris Valasek.
• July, 2013, Defcon: Adventures in Automotive Networks and Control
Units [http://illmatics.com/car_hacking.pdf]

TM 6
TM
• Symmetric
− DES, AES
− Cipher Modes
• Asymmetric
− RSA, ECC
• Secure Hashes
− SHA-1 and CMAC

TM 8
Symmetric Asymmetric
Scheme One
One key
key for
for encoding
encoding and
and Key
Key pair
pair (public/non-public)
(public/non-public)
decoding
decoding encoding
encoding and
and decoding
decoding
Bob Alice Bob Alice

Symmetric Alice’s Alice’s


Key public key private key

Pro 
 Compact
Compact implementation
implementation 
 No
No key
key exchange
exchange problem
problem

 High
High performance
performance 
 Supports
Supports verification
verification

 Key
Key length
lenght (<512-bits)
(<512 bits)
Contra  Key
 Key exchange
exchange problem
problem 
 Long
Long calculation
calculation time
time

 No
No message
message broadcasting
broadcasting
Algorithm DES,
DES, AES
AES RSA,
RSA, ECC
ECC

TM 9
DES AES
Developed by IBM Vincent Rijmen
Joan Daemen
Standardized since 1977 2002
Block size [bits] 64 128
Key size [bits] 64 128, 192 or 256
(reduced to 56 bits)
Rounds 16 10,12 or 14
DES is now considered insecure for many applications!

TM 10
Plaintext
main key

AddRoundKey
Initial Step

The main encoding


1-SubBytes
transformations are:
1-SubBytes
2-ShiftRows Iteration Steps
3-MixColumns
sub-keys 0
9
8
7
6
5
4
3
2
1 1…9
2-ShiftRows
4-AddRoundKey
3-MixColumns
Step
4-AddRoundKey
0
10
9
8
7
6
5
4
3
2
1
SubBytes
sub-key 10 Final Step
ShiftRows

AddRoundKey

Ciphertext

TM 11
1-SubBytes

input:
y
hex
19 a0 9a e9 0 1 2 3 4 5 6 7 8 9 a b c d e f
3d f4 c6 f8 0 63 7c 77 7b f2 6b 6f c5 30 1 67 2b fe d7 ab 76

e3 e2 8d 48 1 ca 82 c9 7d fa 59 47 f0 ad d4 a2 af 9c a4 72 c0

be 2b 2a 08 2 b7 fd 93 26 36 3f f7 cc 34 a5 e5 f1 71 d8 31 15

3 04 c7 23 c3 18 96 5 9a 7 12 80 e2 eb 27 b2 75

4 09 83 2c 1a 1b 6e 5a a0 52 3b d6 b3 29 e3 2f 84

output: 5 53 d1 0 ed 20 fc b1 5b 6a cb be 39 4a 4c 58 cf

6 d0 ef aa fb 43 4d 33 85 45 f9 2 7f 50 3c 9f a8
d4 e0 b8 1e
7 51 a3 40 8f 92 9d 38 f5 bc b6 da 21 10 ff f3 d2
27 bf b4 41 x
8 cd 0c 13 ec 5f 97 44 17 c4 a7 7e 3d 64 5d 19 73
11 98 5d 52
9 60 81 4f dc 22 2a 90 88 46 ee b8 14 de 5e 0b db
ae f1 e5 30
a e0 32 3a 0a 49 6 24 5c c2 d3 ac 62 91 95 e4 79

b e7 c8 37 6d 8d d5 4e a9 6c 56 f4 ea 65 7a ae 8

c ba 78 25 2e 1c a6 b4 c6 e8 dd 74 1f 4b bd 8b 8a

d 70 3e b5 66 48 3 f6 0e 61 35 57 b9 86 c1 1d 9e

e e1 f8 98 11 69 d9 8e 94 9b 1e 87 e9 ce 55 28 df
x = high-nibble f 8c a1 89 0d bf e6 42 68 41 99 2d 0f b0 54 bb 16
y = low-nibble
S-Box

TM 12
2-ShiftRows

d4 e0 b8 1e d4 e0 b8 1e


27 bf b4 41 ← rotation by 1 byte bf b4 41 27
11 98 5d 52 ← rotation by 2 byte 5d 52 11 98
ae f1 e5 30 ← rotation by 3 byte 30 ae f1 e5

3-MixColumns

02 03 01 01 d4 04 04 e0 48 28 Every column will be modulo


 multiplied with a given matrix.
01 02 03 01 bf 66 66 cb f8 06

01 01 02 03 5d = 81 81 19 d3 26

03 01 01 02 30 e5 e5 9a 7a 4c

4-AddRoundKey

04 e0 48 28 a0 88 23 2a a4 68 6b 02 Every column will be xor-ed with the


same column of the actual iteration

66 cb f8 06 fa 54 a3 6c 9c 9f 5b 6a
81 19 d3 26 fe 2c 39 76 7f 35 ea 50 sub-key.
e5 9a 7a 4c 17 b1 39 05 f2 2b 43 49

TM 13
Electronic codebook (ECB) Cipher-block chaining (CBC)

Each
Each block
block is
is encoded/decoded
encoded/decoded Previous
Previousresult
resultisisXORed
XORedwith
withactual
actual
Scheme independantly
indecently fromfrom
the the others
others plaintext
plaintext
Plaintext Plaintext
Ciphertext

IV
Block Cipher
Key
Encryption
Diagram Key
Block Cipher
Encryption
Block Cipher
Encryption

Plaintext

Ciphertext Ciphertext

Pro Random
Random access
access possible
possible Secure
Securefor
formessages
messageslonger
longerthan blocksize
as block size

Insecure for message longer than the No


Norandom
randomaccess
accesspossible,
possible, (before
(beforethe
the
Insecure for message longer as the block
Contra block size (statistical analysis)
size (statistical analysis)
last
lastblock
blockcan
canbe
bedecoded othersmust
decode all other mustbe
be decoded)
decode)

Example TM
ECB TM
CBC

TM 14
• Facts
− Developed in1978 by Ron Rivest, Adi Shamir and Leonard Adleman
at MIT
− Key size: ≥ 1024-bits (CAN-Message offers 8 data bytes )
− Algorithm based on very big numbers  optimized libraries (e.g.
GMP)
− Expectations: RSA-1024 will be insecure by 2014
• The RSA algorithm involves three steps
− Key generation
− Encryption
− Decryption

TM 15
• 1985: Victor Miller and Neil Koblitz use elliptic
curves for cryptography
• It’s an alternative asymmetric crypto algorithm
• ECC relies upon the difficulty of the Elliptic
Curve Discrete Logarithm Problem (ECDLP)
ax ≡ m mod p
− it‘s easy to calculate m, when a, x and p is known
− it‘s hard to find x when a, m and p is known
• ECC offers smaller key size than RSA

Security Level(*) NIST Recommended y²=x³+ax+b


Restricted  Confidential
SecretTop secret Key Sizes [bits]

AES RSA ECC


Secret 128 3072 256
192 7680 384
Top Secret
256 15360 512

TM 16
DES AES RSA ECC

Secure for the next


few years    
Key size > 2048
Type symmetric symmetric asymmetric asymmetric

Typical 180, 224, 256,320,


56 128, 192, 256 1024, 2048, 3072
key size [bits] 512

Execution time short short long long

Authentication
/ verification    
Could combine into one module,
HW – good
Implementation HW / SW - good req. big number math functions (e.g.
SW – lot of bit ops
GMP)

Comments Message broadcasting isn‘t an issue Message broadcasting is an issue

TM 17
TM
Hashe:
• Integrity check
• Public known algorithm Input Digest
The red fox
• Input: data blocks humps over
HASH 0086 46BB FB7D CBE2 823C
Algorithm ACC7 6CD1 90B1 EE6E 3ABC
the blue dog
• Output: HASH value
(e.g 256-512bits)

CMAC:
• Integrity & authenticity check Input Digest
• Public known algorithm The red fox
0086 46BB FB7D CBE2 823C
humps over Cipher ACC7 6CD1 90B1 EE6E 3ABC
• Input: data blocks & key value the blue dog

• Output: CMAC value Key

(e.g 128-256 bits)

TM 19
Audi, BMW and
Escrypt HIS - SHE
Body device with
CSE, the first SHE MPC564x - CSE
implementation

EVITA - NEC, IFX,


Bosch, Escrypt ... EVITA - Low/Medium/High Sec. Modules

Hardware Security
Module (HSM) MPC5746M - HSM
PRESERVE
Escrypt, Renault, V2X Sec.System
Fraunhofer

HIS – HSM
Specification HIS - HSM
ARAMiS 3year –
FSL,IFX, Bosch, MultiCore HSM
Conti

Enhanced CSE CSE2


Module

2008 2009 2010 2011 2012

[email protected]

TM 20
• Created by Audi (main driver), BMW and Escrypt
• Published as a official HIS standard
(HIS => Herstellerinitiative Software, German for 'OEM software initiative')

• Re-view of the Spec. by Freescale in an early phase


• Key features of the SHE specification:
−A secure storage for crypto keys
− Crypto algorithm acceleration (AES-128)
− Secure Boot mechanism to verify custom firmware after reset
− Offers 19 security specific functions
− Up to 10 general and 5 special purpose crypto keys

[email protected]

TM 21
http://www.evita-project.org
EVITA a project co-funded by the European Union.
The objective of EVITA is to design, verify, and prototype an
architecture for automotive on-board networks where security-relevant
components are protected against tampering and sensitive data are
protected against compromise.

EVITA Security Modules


High-Level

Medium-Level

Low-Level

UTC Clock AES-128 Internal RAM Internal Core ECC-256


64 KBytes 50-250 MHz NIST FIPS GF(p)

AES-PRNG EVITA HW-IF Internal NVM Sec. Counter WHIRLPOOL


32+10 KBytes AES based HASH

[email protected]

TM 22
TM
• CSE module implements the official HIS SHE-
Specification
• 32-bit secure core working at 120 MHz CSE
CSE Block INTC ROM RAM
Core

• AES-128 Host to CSE


Interrupt

− Supported crypto modes: ECB & CBC AES RNG


Debugger

− Throughput 100 Mbit/sec connected


IP SkyBlue-IF Host XBAR-IF
Inter.

− Latency 2μs per one encoding/decoding ops DEBUG INTC Core eDMA FlexRay
JTAG
Masters
• CSE module interfaces: NEXUS
XBAR
Peripheral
MPU
Bridge
− Crossbar master interface Slaves

Secure „Firewall“

− Configuration interface FLASH


PB-IF
MI BIU
SRAM

Sec. FLASH UTI

• Secure flash blocks assigned to the CSE module. on/ Test Interface Array
off Test Interface BIU
Accesses from other masters are impossible.
• PRNG seed generation via TRNG
• CSE Core not programmable by customer

[email protected]

TM 24
In future designs CSE2 will only be used

• Introduce new security flag per GPR-keys


• Increased number of GPR-keys from 10 to 20
• Secure Boot result storage in NVM
(configurable by customer)
• Reset Generation on Secure Boot Fail
(configurable by customer)

[email protected]

TM 25
HSM is free programmable by the customer,
additional security algorithm could implemented in software
Features:
• e200z0h core (v1: 100MHz / v2: 80 MHz)
• 4Kbytes Instruction cache
• Secure Debugger Interface
• Cryptographic Modules with AES-128,
Random Number Generator, DMA
• Sensor Interface – monitor for voltage,
temperature and clock (v1 only)
• Memory
− SRAM (v1: 40 Kbytes / v2: 32 Kbytes)
− Flash
code: 2 x 64 Kbytes + 1 x 16KBytes
data : 2 x 16 Kbytes

[email protected]

TM 26
• Cryptographic keys
−2 x read-only keys (programmed by FSL)
−8 x GPR-keys
−1 x PRNG-key
• Cipher Modes: ECB, CBC, OFB, CFB, CTR, XTS, CMAC,
GCM and OFB for PRNG
• Multiple contexts; context swapping performed by hardware
• Programming interfaces:
− Register based mode
− SmartDMA mode

TM 27
Features:
• Device life cycle scheme
• Unique ID for each device
• Debugger restrictions
• Flash Protection
− OTP
− read / write & erase
− diary to log erasing-steps

Freescale Customer OEM


SSCM: System Status Configuration Module
Production Delivery Production
PASS: Password And Device Security Module
TDM: Tamper Detection Module
HSM: Hardware Security Module
MPU: Memory Protection Unit Failure
In-Field
DCF: Device Configuration Format Analysis

TM 28
Freescale Security Solution for Automotive products

Device Platform Module

MPC564xB/C CSE
( internal flash)

MPC5746M HSMv1
MCU

PowerPC

Automotive
MPC5777M e200 HSMv1

MPC5748G HSMv2

Vybrid Controller Solutions

Consumer
(flash-

Trust Zone
MPU
less)

ARM Cortex-Ax/Mx
+ Sahara /
& ARM9/11
i.Mx 2x / 3x / 5x / 6x / 7x CAAM

no automotive standards

[email protected]

TM 29
Security EVITA-Medium
EVITA- Low HIS-SHE EVITA-High
Standards (HIS-Medium)

UID NVM is mandatory Programmable by Public Key


Main features
Crypto engine Fix function set customer HASH

CSE / CSE2 supported by MPC564xB/C

HSM (v1/v2) supported by MPC5746M & Calypso

[email protected]

TM 30
TM
MPC5646C
Step 1: After power on: CSE module reads
bootloader via its bus master interface.
CSE module MAC value
3a
Step 2: CSE module uses the boot key to Unique ID 2c Keys
calculates the MAC value of the bootloader.
Random
Boot MAC
number
Boot key
generator AES-128 2b
Step 3: CSE module compares calculated
MAC with stored boot MAC. If identical:
successful secure boot  set respective bit
in host interface and unlock keys Bus master 2a Host Interface

Step 4: MCU always starts bootloader. 1 3b

Bit for successful 3c


Bootloader:
Part of flash memory Flash secure boot
Keys unlocked
4 Start bootloader

• MAC protects against modification of bootloader and depends on the


(secret) boot key  integrity and authenticity of bootloader.
• Only if calculated MAC value matches stored boot MAC value:
successful secure boot  set respective bit in host interface and unlock
keys for further usage (see next demos)
[email protected]

TM 32
Step 1: Successful secure boot to verify
bootloader and to unlock keys. Then the MPC5646C
bootloader configures the MCU for full speed,
best memory timing, etc.
MAC CSE module
Unique ID Keys
Step 2: Bootloader asks CSE module to verify Random 3c
MAC for part #1 of flash memory using key #x number
Key #x
Step 3: CSE module reads part of flash, uses 3d generator AES-128 3b

key #x to calculate MAC, and compares


calculated MAC with MAC for part #1 as stored
in bootloader. If identical, CSE module sets Bus master 3a Host Interface
corresponding bit in host interface. 1

3a 3e
Step 4: Bootloader checks bit.
If set: Part #1 of flash ok  execute part #1. Bit for valid MAC
Part
Flash
#1
#2 ...
Step 5 etc: Similar to bootloader vs. part #1 of
flash: Part #n of flash verifies part #n+1 
chain of trust. Stored MAC for part #2
Stored MAC for part #1
Bootloader
• MACs stored in bootloader provide integrity and authenticity of the related parts in flash
memory.
• Bootloader protected by secure boot (see previous demo).
• Part-by-part checking of flash to execute critical parts of flash (e.g., MCU configuration/IRQ
table) as soon as possible. [email protected]

TM 33
Central ECU with MPC5646C Sensor ECU
CSE module CSE module

Random Unique ID Keys Random Unique ID Keys


number E.g. number
generators CAN generators
AES-128 Key #x AES-128 Key #x

RND
Encrypted Sensor value
(sensor value;RND)
Decrypted
(sensor value;RND)

Step 3: Sensor ECU sends


Step 2: Sensor ECU reads encrypted message to
Step 1: Central ECU obtains central ECU. Step 5: Central ECU checks
sensor value and asks CSE
random number and sends sent random number vs.
module to encrypt it and the Step 4: Central ECU asks
it to sensors ECU (e.g., after received/decrypted random
received random number CSE module to decrypt
power-on of car) number.
(using key #x) received message (using
key #x).

• Random number: protects against replay attacks.


• Encryption: protects against eavesdropping.
• Random number and encryption: ensures data integrity and authenticity.
[email protected]

TM 34
Master ECU with MPC5646C ECU <n> with MPC5646C
CSE module CSE module

Random Unique ID Keys Random Unique ID Keys


number E.g. number
generators CAN generators
AES-128 Key #x AES-128 Key #x

RND

Flash Encrypted(RND;ID)
ID <n> Decrypted(RND;ID)

Step 2: ECU <n>


Step 1: Master ECU Step 4: Master ECU
appends its unique ID to
obtains random number Step 3: Master ECU checks decrypted RND
received RND, encrypts
and sends it to ECU decrypts received and ID with sent RND
this message with key
<n>. message with key #x. and with stored ID <n>.
#x, and sends encrypted
If match: ECU <n> is ok.
message to master ECU

• Replacement or modification of ECU <n> will change its unique ID and/or


keys. Both will be detected with this proposal for component protection.

TM 35
TM
• Automotive Security: Protection and Enablement
• Automotive Security: A global concern, a requirement and a new
trend.
• Two types: In-vehicle Security and Connected Vehicle Security
• Freescale offers a variety of solutions today
Freescale Security Solution for Automotive products
Device Platform Module
( internal flash)

MPC564xB/C CSE
MPC5746M HSMv1
MCU

PowerPC
MPC5777M e200 HSMv1

MPC5748G HSMv2

Vybrid Controller Solutions


(flash-

Trust Zone
MPU
less)

ARM Cortex-Ax/Mx
+ Sahara /
i.Mx 2x / 3x / 5x / 6x / 7x & ARM9/11
CAAM

TM 37
• Jürgen Frank
− Senior Systems Engineer, FSL Munich
− Phone: +49 - 89 - 92 103 429
[email protected]

TM 38
TM

You might also like