 AUTOSAR-Security Module und sicheres Flashen
Praktische Anwendung der Security und deren Module aus dem Bereich AUTOSAR
und der Flash Programmierung
29. VDI/VW-Gemeinschaftstagung Automotive Security, 2013-09-25 | Armin Happel
Agenda
> Introduction
CAL / CSM
Implementation Hints
Hardware Security
Examples
Secure Reprogramming
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 2
Introduction
Safety und Security
Safety or Security, or both?
Safety
Security

Ensure the right
mode of operation

Protection against external
access

Function protection
 … against malfunction
 … against external
interruption

Manipulation protection
Function and data access
Ensure originality


© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 3
Introduction
General Aims of Security
 Integrity
Message is complete, nothing left off or has
been added.
 Authenticity
The message comes really from the originator
 Confidentiality
The message is confidential and can be read
from authorized people only
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 4
Introduction
Crypto Basics: Hash function
Hash function - Aim
 Easy to calculate
 To split a message with any length to a hash
100110110001
101001001010
110011110011
000110011010
1110…
value with defined length
 Changes in length, order and content generally
lead to a new hash value
 Equal data packages which leads to the same
hash value, must be avoid. This is called
“collision avoidance” or “collision resistant”
H(x)
 Typical lengths of hash values are, depended
on hash function, between 16 – 32 Bytes
 Represents a fingerprint of a file
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 5
|10011011001101110|
Introduction
Crypto Basics: Symmetric encryption
Characteristics
 A function for decryption and one for encryption for inverse
operation.
 One common key for both operation
 Frequency distribution of plaintext is balanced in the cyphertext.
 Typically block cyphers are used, that means input and output
data operation is on block basis.
101101101..
101101101..
D(x)
D-1(x)
Q?“D/7L$§..
Q?“D/7L$§..
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 6
Introduction
Crypto Basics: Asymmetric encryption
Characteristics
 Generate two keys in relation to each other
(Kpriv, Kpub)
 One key is public, the other is private.
 Messages can be encrypted with the public key and the cypher
function M‘=E(M, Kpub).
 Messages can only be encrypted with the decryption function and
the private key M=D(M‘, Kpriv) 1.
 There is no way the private key can be calculated.
 Known asymmetric functions:
101101101..
 RSA
 ElGamal
kprivate
 Elliptical curves
D(M’)
Q?“D/7L$§..
1 Since for RSA the cypher and dec-cypher function is identically, messages can
also be encrypted with the private key and decrypted with the public key.
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 7
E(M)
kpublic
Introduction
Crypto Basics: Message-Authentication-Code (MAC) and Signatures
Aim
 Message is transmitted as plain text with authentication code.
 Receiver is able to verify authentication with the message and the
key.
Hashed Message-Authentication-Code (H-MAC)
 Hash value, that is calculated on the file and the secret
(symmetric) key.
Signature
 Asymmetric decryption of a (padded) hash value transmitted
together with the plain text and the signature.
 Verification at the receiver side using the public key
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 8
Introduction
Crypto Basics: Certificate
Certificates
 … contain private and personal characteristcs
 … used to exchange (secret) keys for further confidential
and symmetric communication.
 … can be restricted to a limited amount of time.
 … can be provided by a „Trusted Authority“ (TA) or
„Certificate Authority“ (CA)).
TA
C
T1
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 9
T2
Introduction
Security modules in AUTOSAR
 AUTOSAR 4 specifies two cryptographic modules
 CSM – Crypto Service Manager
 CAL – Crypto Abstraction Library
 Both modules…
 …do similar things
 …are wrapper modules
 The actual crypto algorithms are implemented in underlying
software or hardware modules.
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 10
Introduction
Vector Security Solution within MICROSAR 4.x Stack
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 11
Agenda
Introduction
> CAL / CSM
Implementation Hints
Hardware Security
Examples
Secure Reprogramming
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 12
CAL / CSM
Basic Architecture
 The architectural design of the CSM and the CAL consists of two
Layers:
> Wrapper Layer – Acts as the Interface for BSWs, CDDs or as handle
for the RTE
> Implementation Layer – Provides either the algorithm of the service
or accesses the API of a cryptographic library
Wrapper Layer
RNG
Encrypt
AESSW
DESSW
The Implementation Layers are also
defined in the AUTOSAR SWSs:
>
The CPL (Cryptographic Primitive Library)
for the CAL.
>
The CRY (Cryptographic Library Module)
for the CSM.
XYZ
Implementation Layer
RNGSW

XYZ
Crypto Library
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 13
CAL / CSM
Implementation Layer
 CPL (CAL) and CRY (CSM) are very similar
 They both provide cryptographic primitives
 A cryptographic primitive is a crypto algorithm (e.g. MD5, SHA-1,
AES-128, DES etc.)
 Their interfaces are described in the specific SWS (CAL/CSM)
 AUTOSAR does not specify an explicit algorithm but the service
types
> E.g. Service type Cry_SymBlockEncrypt for AES-128
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 14
CAL / CSM
Service Types
 The following Cryptographically Service Types are defined in ASR
4.0.3:
> Encryption and Decryption – Services
>
Symmetric Encryption / Decryption
>
Symmetric Block Encryption / Decryption
>
Asymmetric Encryption / Decryption
> Message Verification – Services
>
Signature Generation / Verification
>
Hash Calculation
>
Checksum
>
MAC Generation / Verification
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 15
CAL / CSM
Service Types
> Random Number Generator (RNG)
> Key related Interfaces
>
Key Derivation
>
Key Calculation for Public / Secret / SymKey *
>
Key Wrapping and Extraction (sym/asym)
*= CSM only
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 16
CAL / CSM
Streaming and Non-Streaming Services
 The CSM and CAL provides two types of Services
> Non-Streaming Approach Services
> Function is called directly without initialization (e.g. RNG)
RNG #1
Generate
> Streaming Approach Services
> Start-, Update-, Finish-Functions (e.g. Sym.Encryption)
> Update can be called more than once
> Process larger segments
> Allocate time critical operations in more than one step
AES #1
Start
Update
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 17
Finish
CAL / CSM
CAL Architecture
 The CAL is specified as a library:
 Thus, it has no variables to save states or context. Therefore
the context buffer have to be provided by the caller.
 As a library, there is no need of an RTE
interface. Applications can access the
CAL APIs directly.
 The CAL has no development error
detection (DET)
 CAL does only provide a synchronous
mode
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 18
CAL / CSM
CSM Architecture

The CSM is a System Service:

Usage of the CSM in an
Application requires port
interfaces through the
RTE

CSM provides error
detection via DET and
DEM

Provides a MainFunction
for asynchronous mode
which is triggered by the
SchM
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 19
CAL / CSM
CSM Architecture

As the CSM provides an asynchronous mode it is possible to use
hardware-driven security algorithms.

The CSM SWS describes
explicit the usage of a
Hardware Security Module.
CSM


CSM provides callback
functions to gain advantage
of hardware implemented
algorithms.
A driver can be implemented
as a CRY-Module or the API
can be accessed by the CRY.
RNG
XYZ
CRY
RNGSW
AESSW
Crypto Lib
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 20
Encrypt
AESHW
HW DRV
SecurityHW
XYZ
CAL / CSM
Differences
CAL
CSM
Services
25
26 (Csm_KeyExchangeCalcSymKey)
Implementation
Library
System Service Module
Behavior
synchronous
synchronous/asynchronous
API
Cal_<Service>(cfgId,
ContextBuffer, … )
Csm_<Service>(cfgId, …)
Context Buffer
Provided by Application
Buffer has to be provided by CRY
Crypto
CPL (Crypto primitive
library)
CRY (Cryptographic library)
Reentrancy
Reentrant
Non reentrant
Usage
Following functions have to be called:
>
>
>
(Csm/Cal)_<Service>Start
(Csm/Cal)_<Service>Update (at least one time)
(Csm/Cal)_<Service>Finish
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 21
CAL / CSM
What should be used?
 The CSM supports everything the CAL does and more
 Possible use cases:
 SWCs use CSM
 Ethernet stack uses CAL (for TLS)
 Usage of CSM recommended if Security Hardware is used.
 Typically, the decision what to use comes from the OEMs
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 22
Agenda
Introduction
CAL / CSM
> Implementation Hints
Hardware Security
Examples
Secure Reprogramming
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 23
Implementation Hints
DaVinci Configurator 5
 Step 1: Configuration with DaVinci Configurator 5
> Configuration of CAL and
CSM is nearly the same
> CSM has an additional
parameter: Callback Pointer
> Shortname: Handle for
increased readability
> Include File: Header of the
specific CRY/CPL Modul
> Init Configuration: Symbolic
name of init-configuration
structure
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 24
Implementation Hints
DaVinci Developer
 Step 2: Service Port mapping with DaVinci Developer
> As the CAL provides no
RTE port interface, this step
is only needed for the CSM
> Service Ports of the CSM
have to be mapped to the
corresponding Runnables
> After the generation of the
SWCs, macros for the usage
of the CSM are provided
within the template files
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 25
Implementation Hints
Implementation
 Step 3: Implementation

The Implementation take place in the generated SWC templates

CSM Macros and Types are listed in the comment block of the
Runnables and provided out of the box.
> E.g.:

For CAL usage it is necessary to include the Cal.h Header
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 26
Implementation Hints
Example Implementation
CAL Implementation
CSM Implementation
#include "Cal.h"
void TestApplCalHash ( void )
{
uint8
resultBuffer[32];
uint32
dataLength, resultLength;
Cal_HashCtxBufType contextBuffer;
void TestApplCsmHash ( void )
{
uint8
resultBuffer[32];
uint32
dataLength, resultLength=32;
/* Initialize Hash Service: CalHashConfig_01 */
Cal_HashStart(CalHashConfig_01,
contextBuffer);
/* Initialize Hash Service: */
Rte_Call_CsmHash_HashStart();
/* Processing of Block #1 */
Cal_HashUpdate(CalHashConfig_01,
contextBuffer,
plainText,
dataLength);
/* Processing of Block #1 */
Rte_Call_CsmHash_HashUpdate(plainText,
dataLength);
/* Finalize Result */
Cal_HashFinish(CalHashConfig_01,
contextBuffer,
resultBuffer,
&resultLength,
TRUNCATION_ALLOWED);
/* Finalize Result */
Rte_Call_CsmHash_HashFinish(resultBuffer,
&resultLength,
TRUNCATION_ALLOWED);
}
}
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 27
Implementation Hints
Service Primitive Context Buffer
 Each CRY/CPL function needs some temporary memory
(work spaces); e.g.:

Temporary used data

Current state of the algorithm

Checksum and/or length information
 The workspace for CAL/CPL has to be provided by the application

Buffer types are standardized by AUTOSAR, e.g.: Cal_HashCtxBufType

Base type is Cal_AlignType; e.g.: uint32

Buffer sizes are configured with DaVinci Configurator 5 and depending
on the implementation of CPL
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 28
Implementation Hints
Testing

Most cryptographic systems can be tested with test vectors
 Evaluation of the calculated output with given input parameter
 Provided by RfCs, algorithm specifications, published by the
authors or ministries, e.g.: NIST Test Vector for AES 128 Bit:
>
PLAINTEXT: 00112233445566778899aabbccddeeff
>
KEY: 000102030405060708090a0b0c0d0e0f
>
RESULT: 69c4e0d86a7b0430d8cdb78070b4c55a
 Some algorithms can`t be validated with test vectors those
require other test methods, e.g.: Random Number Generator;
two test methods are common:
 Variable Seed Test
 Monte Carlo Test
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 29
Agenda
Introduction
CAL / CSM
Implementation Hints
> Hardware Security
Examples
Secure Reprogramming
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 30
Hardware Security
EVITA - Overview
 EVITA: E-Safety Vehicle Intrusion Protected Applications
 Members: BMW, Bosch, Infineon, Fujitsu..
 Goal: Securing the in-vehicular system infrastructure
 Distributed security
 Real-time capability
 Cost-efficient architectures
 Key Features:
 Hardware cryptographic engine(s)
 Secure storage (keys, certificates, firmware, etc.)
 Secure CPU core
 Scalable security architectures
 Further information: www.evita-project.org
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 31
Hardware Security
EVITA - Classification
 EVITA classified 3 types of Hardware Security Modules (HSM)
HSM
EVITA full
EVITA medium
EVITA light
Internal NVM
Yes
Yes
Optional
Internal CPU
Programmable
Programmable
None
HW crypto
algorithms (incl.
key generation)
ECDSA, ECDH,
AES/MAC,
WHIRLPOOL/HMAC
ECDSA, ECDH,
AES/MAC,
WHIRLPOOL/HMAC
AES/MAC
HW crypto
acceleration
ECC, AES,
WHIRLPOOL
AES
AES
RNG
TRNG
TRNG
PRNG w/ ext. seed
Counter
16x64bit
16x64bit
None
Intended use-case
C2x,…
Gateway, engine
control, head
unit,…
Sensors, actuators,
…
 The standardized Secure Hardware Extension (SHE) meets the
EVITA light requirements
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 32
Hardware Security
SHE - Introduction
 The “Hersteller Initiative Software
Controller
(HIS)” (BMW, Daimler, VW..) specified
the “Secure Hardware Extension
(SHE)”
 SHE is a on-chip extension to any
Secure Zone
SHE – Secure Hardware Extension
AES
CPU
Control
Logic
RAM + Flash + ROM
given µC
 Main Goals of the SHE
 Move the cryptographic keys into
hardware domain
 Fast processing, high flexibility
and low costs
 Distributed key ownership
 Provide an authentic software
environment
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 33
Peripherals (CAN, UART, external memory interface
Hardware Security
SHE - Introduction
 SHE provides AES and AES based algorithms
 HIS provides a specification which describes what is
expected by the hardware
 User-accessible algorithms provided by the SHE:
 AES Encryption/Decryption in ECB or CBC mode
 MAC generation/verification
 Random Number Generater (Pseudo-RNG and True-RNG)
 Secure Boot (Chain-of-Trust approach)
 SHE has to provide a Secure Zone…
 … that is only accessible by the SHE control logic.
 … where the keys, Boot-MAC, PRNG seed and the unique
device ID are stored.
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 34
Hardware Security
SHE - Features
 SHE is a generic name. Depending on the Semiconductor another
abbreviation is used
(Freescale: CSE – Cryptographics Service Engine)
 Example: MPC5646C SHE supports the following features
 AES 128-Bit De-/Encryption
 MAC Generation/Verification
 Random Number Generator (Pseudo and True RNG)
 Secure Boot (Chain of Trust)
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 35
Hardware Security
SHE - Chain of Trust
 Secure Boot Feature can be used to prevent code from being
altered

A specified section of boot code is being validated at start up by a
cipher based MAC

The boot code may contain an address of a second section of
memory which may be authenticated

And so on..

This scheme is called “Chain of Trust”
SHE
Verification on
startup.
CMAC Check
Bootloader
Addr
CMAC Check
Data to be verified
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 36
Addr
…
Hardware Security
SHE - Performance


Test setup

Freescale MPC5646C w/ CSE

MICROSAR Demo Stack with CSM and SHE driver

AUTORSAR Measurement and Debugging (AMD) Runtime Measurement
(RTM)
Results


AES throughput rates (unoptimized)
>
Theoretical throughput >7.6Mb/s
>
Realistic throughput (pure) ~2.48Mb/s
>
MSR Stack, CSM, CRY, Driver <1.22Mb/s
Comparison to software based AES. She is …
>
… ~17x faster on a single block
>
… ~42x faster on two (chained) blocks
>
… ~82x faster on 768bit
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 37
Hardware Security
SHE - Performance
 AES ECB Encryption: SHE vs. Software Library
µs
2000
128 Bit
2002.5µs
1800
384 Bit
1600
768 Bit
1400
1200
1111.6µs
1000
800
600
400
200
24,94µs
13.5µs
0
SHE 64 Mhz
SW 64 Mhz
SHE 120 Mhz
SW 120 Mhz
Measured on a Freescale MPC5646C (w/ CSE), MICROSAR Stack with CSM and SHE Driver with the Vector
‘AUTOSAR Measurement and Debugging (AMD) Runtime Measurement (RTM)’ Tool.
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 38
Hardware Security
Use Cases


Component Protection

Validation of the ECUs

Prevention of exchanging one ECU. A flag can be set to..
.. stop operation of the ECUs on next start up
>
.. indicate that the garage service that there are changes to the ECU
Secured Communication


>
Critical data can be encrypted/decrypted with the SHE very fast
>
E.g. Pump pressure to prevent motor tuning
>
E.g. Signals and messages for the Car2x communication
Immobilizer

Disable ignition

Prevent unauthorized operation of vehicle
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 39
Agenda
Introduction
CAL / CSM
Implementation Hints
Hardware Security
> Examples
Secure Reprogramming
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 40
Examples
Secret storage
 Sensitive data are stored within an ECU (e.g. Odometer)
 Storage device is external
 Secret key can be used for en- and decryption
 Symmetric decryption can be used
 Secret key must be kept in a safe place.
 Calibration data which can be updated from external
 Symmetric encryption, if the secret key can be kept safe.
Recommended if it is used locally.
 Asymmetric encryption provides higher security if keys
are used on different locations (source / destination).
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 41
Examples
Anti-Theft protection of ECUs
 Immobilizer provides protection against
car theft
 To prevent cannibalizing cars,
introduction of new control units to a
car is restricted
 Central control unit contains a list of
present ECUs. Checks cyclically unique
Ids of the ECUs and enables the
communication
 Unauthorized ECUs have restricted or
no communication
 Used service primitives:
 Random number generator
 Message authentication code
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 42
Examples
Secured communication
 Encrypted communication channel
Sender
Receiver
(AES)
TFactor
replay attacks
 Encrypted signals tunneled
 Authenticity
 Integrity
 Confidentiality
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 43
TNewIdKey
TFactor
 Provides
TOffset
through ISO-TP
TNewIdKey
TFactor
 Identification key (PUN) against
TOffset
 Dedicated sender and receiver
Power up
TResentTResentTResent
 1:1 communication relation
Power up
Examples
Smart charging
 TLS client for a secured
Smart charging
communication channel
 Signature verification
 RSA based
 Client certificates
 Signature verification /
generation
TLS Client
Signature
verification
RSA
RNG
 ECC based
 Key generation
 Symmetric encryption
 AES based
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 44
Signature verification/generation
AES
SHA-256
SHA-1
ECC
(elliptical curves)
MD5
CRC16/
CRC32
Examples
C2x communication
 C2x offers wireless communication for various applications.
 Authenticity and integrity is important to prevent attacks
 Realized with certificates managed through PKI infrastructure to
sign C2x messages.
 Divided into car specific long-term certificates and (time-limited)
pseudonym certificates to keep privacy.
*From: ETSI Security Workshop
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 45
Agenda
Introduction
CAL / CSM
Implementation Hints
Hardware Security
Examples
> Secure Reprogramming
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 46
Secure Reprogramming
Introduction
 Reprogramming of an ECU is a convenient way for software
updates during development, production and after-sales
 Car access over diagnostic is used for re-programming
 Prevent unauthorized manipulation
 Hardware attacks
 Software attacks
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 47
Secure Reprogramming
Physical presence of ECU
 Physical access to an ECU is possible
 Provides possibility to read out information:
Debugging
interface
Probes from
external
devices
 Debugging interface (JTAG, etc.)
must be disabled for production!!
 Critical data (e.g. keys) must not be
stored in external devices.
 No backdoor features available to
read out memory.
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 48
Secure Reprogramming
Software download
 Software download over Diagnostics
uses a sequence of services.
 Approved methods to provide:
 Authorisation
> SecurityAccess to grant access to
the flash process
 Integrity
> CheckRoutine with CRC calculation
 Authentication (optional)
> CheckRoutine with signature
 Confidentiality (optional)
> Data decryption during download
 Usage depends on resources,
performance, criticality
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 49
Enter Programming Session
Security Access
WriteDataByLocalId
Request Download
TransferData
TransferDataExit
StartRoutineByLocalId (Check Routine)
StartRoutineByLocalId (Erase)
RequestDownload
TransferData
TransferDataExit
StartRoutineByLocalId (CheckRoutine)
EcuReset
Secure Reprogramming
Security Access: Principle
 Challenge-response used to gain access control
 ECU generates a random seed
 ECU calculates a key according to a determined function.
 Tester calculates the key with seed and the same function and
parameters
 Tester sends this key to the ECU. If the key matches, the ECU is
unlocked.
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 50
Secure Reprogramming
Security Access: Vulnerability
 After unsuccessful accesses, a penalty time is added to complicate
brute-force attacks.
 Requires access counts stored in NV-RAM (Reset safe!).
 An alternative is
a penalty time at cold-start of the Bootloader.
 Requires a good random number generator
(P-RNG or T-RNG).
 RSA, AES, H-MAC or proprietary functions with secret keys are used.
 Beware of chosen plaintext attacks (snippet of successful unlock).
 Potential tester theft if the key calculation is done in the tester.
Instead, secure communication to a trusted platform could be used,
which requires on-line access.
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 51
Secure Reprogramming
Integrity
 CRC checksum is used for integrity check using IEEE CRC32.
 Explicit service request is preferred (RoutineControl-CheckMemory)
 CRC is sent to the ECU through diagnostics where the calculation and
validation takes place -> Bootloader knows the result.
 CRC verification directly on the data in the memory.
 Must be calculated before data processing (compress, encrypt)
 Provides end-to-end protection.
Application
<HEX>
Data
Processing
Linker
Application
Application‘
<HEX>
CRC
Software
Download
Bootloader
(Data Processing)
CRC
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 52
Verify
Secure Reprogramming
Authentication
 Implements a mechanism to ensure, that the data itself was
provided by the originator and has not been manipulated
 No one else than the originator is able to create the
authentication data
 Application is only started if the authentication was successful.
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 53
Secure Reprogramming
Authentication
Why could additional authentication be needed?

Unauthorized access to the OEM software data base

Prevent manipulation of operational software,
parameters, etc. (Tuning)

Warranties due to manipulated and damaged devices

The car maker ensures, that this software comes from
the TIER-1 and has been approved


The car maker signs the data to provide authenticity of the software

No further change can be made to the software without notification
Accidents due to software manipulation

Which evidences for manipulation are available?

Which precautions has a car maker made for prevention?
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 54
Secure Reprogramming
Authentication
How can authentication be achieved?

There is no change to the operational software

A signature must be created for each downloadable software module

The signature is based on standardized cryptographic algorithms and a key

Not the algorithm is the secret, but the key

The key must be kept in a secret place

The bootloader implements the same algorithm
and verifies the signature after the download

Each signature is an fingerprint to the software module

It is impossible to re-build the signature by 3rd parties
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 55
Secure Reprogramming
Creating the digital Signature
Data from
software
module X
Software module x
Hash function
y=h(x)
Signature z
Create signature
s=sign(y,key)
y (fixed length)
s (fixed length)
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 56
Fingerprint
x (arbitrary length)
Secure Reprogramming
Security Classes
We distinguish two different security classes (HIS*)


Security Class C:

Uses symmetric, secret key.

The same key is used to create the signature and to verify it in the
bootloader

Signature and key length is typically 16 bytes
Security Class CCC:

Uses asymmetric keys (public and private key)

The private key is used to create the signature

The public key is used to verify the signature in the bootloader

Typical length of key and signature is 128 bytes
* HIS: Hersteller Initiative Software
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 57
Secure Reprogramming
Security Class C
HMAC
Flashfile
Verify
H
H
ksecret
HMAC
H
Hash function
ksecret
Flashfile
ksecret: Secret key
HMAC
Boot
HMAC
HMAC
Keyed-Hash Message Authentication Code
(FIPS PUB 198)
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 58
Flashdownload
Flash data
Secure Reprogramming
Security Class C – Advantage and Disadvantage
 Advantage
 Requires less resources (RAM/ROM) within the ECU
 Problems with symmetric key
 Distribution of the key: How can we ensure, that the key gets not
to the hold of the wrong person?
 Authentication: Everyone who has this key can create the H-MAC
 Smartcards could be used for distribution
 Solution to this problem is the usage of asymmetric keys
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 59
Secure Reprogramming
Security class CCC – Goal and Solution
 Goal
 Unique signature can be created only in the trust center
 Verification can easily made within the bootloader
 Signature generation and verification uses different keys
 Solution
 Generation of a private and public key (requires PKI*)
 The private key is used to create the signature
 The public key is used to verify the correct signature
 Calculation is based on the RSA algorithm
(well-known from „PGP“)
*PKI: Public Key Infrastructure
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 60
Secure Reprogramming
Security class CCC
kprivate
Flashfile
H
PKCS#1
kprivate
MAC-E
Code
RSA
RSA
SIGN
MAC-I
PKCS#1
kpublic
H
Flash data
Flashfile
SIGN
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 61
Verify
Flashdownload
Boot
kpublic
Secure Reprogramming
Vulnerability to start conditions
 Presence of data required to calculate
the hash value.
 Malware is already downloaded to the
ECU.
 Check the conditions to start this
software
> Pattern in (external) EEPROM?
> “Presence pattern” downloadable?
> Who controls the startup of the
application?
> Keep in mind that physical access to the
device is possible.
 Any backdoors enabled like Read
Memory over Diagnostics or XCP?
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 62
Secure Reprogramming
Confidentiality
 Global data deployment in After-Sales market
 Reverse engineering of the software is possible
 Data encryption desired to keep intellectual property
 Typically, symmetric encryption is used (AES)
 Bootloader decrypts incoming data before programming
 Data Format Identifier (DFI) used to mark
encrypted/compressed data.
 Order of data processing is important:
 Compression must be done before encryption!
 Assumption: signature is calculated in the trust center.
> Are the data encrypted there as well?
> Is the signature calculated before or after encryption/compression?
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 63
Secure Reprogramming
ODX-F

Comprehensive data required for flash download

Enhance flash data by process relevant data
>
>
Container of data plus all relevant information (“Self-contained”)
>
Identification: Hardware/software versions, part numbers, …
>
Dependencies: Compatibility
>
Data integrity: Checksums, …
>
Data authenticity: Signatures, …
>
Confidentially: Encrypt data or container
Establish process-safe (also partial) flashing

Establish a flash data exchange format

Enable data driven reprogramming tools
data, start address, length
version, part number
signature, checksum
compressed, encoded
>
Enable automated flashing (data driven, without user interaction), considering
dependencies based on identification
>
Enable minimal flashing
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 64
ODX-F
Flashcontainer
Thank you for your attention.
For detailed information about Vector
and our products please visit
www.vector.com
Author:
Armin Happel, Jörn Herwig, Patrick Markl, Markus Schneider
Vector Informatik GmbH
Ingersheimer Str. 24
70499 Stuttgart
© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
Slide: 65