AUTOSAR-Security Module und sicheres Flashen...Hash value, that is calculated on the file and the...

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

© 2012 . Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.

Slide: 2

Agenda

> Introduction

CAL / CSM

Implementation Hints

Hardware Security

Examples

Secure Reprogramming


Slide: 3

Introduction

Safety und Security

Safety or Security, or both?

Safety Security

Ensure the right mode of operation

Function protection … against malfunction … against external

interruption

Protection against external access

Manipulation protection Function and data access Ensure originality


Slide: 4

Introduction

General Aims of Security

Confidentiality The message is confidential and can be read from authorized people only

Authenticity The message comes really from the originator

Integrity Message is complete, nothing left off or has been added.


Slide: 5

Hash function - Aim

Easy to calculate

To split a message with any length to a hash 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”

Typical lengths of hash values are, depended on hash function, between 16 – 32 Bytes

Represents a fingerprint of a file

Introduction

Crypto Basics: Hash function

|10011011001101110|

H(x)

1001101100011010010010101100111100110001100110101110…


Slide: 6

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.

Introduction

Crypto Basics: Symmetric encryption

D(x) D-1(x)

101101101..

Q?“D/7L$§..

101101101..

Q?“D/7L$§..


Slide: 7

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:

RSA

ElGamal

Elliptical curves

Introduction

Crypto Basics: Asymmetric encryption

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.

D(M’) E(M) kpublic

101101101..

Q?“D/7L$§..

kprivate


Slide: 8

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

Introduction

Crypto Basics: Message-Authentication-Code (MAC) and Signatures


Slide: 9

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)).

Introduction

Crypto Basics: Certificate

T1

TA

T2

C


Slide: 10

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.


Slide: 11

Introduction

Vector Security Solution within MICROSAR 4.x Stack


Slide: 12

Agenda

Introduction

> CAL / CSM


Hardware Security

Examples



Slide: 13

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

Implementation Layer

AESSW XYZ

Crypto Library

RNGSW

Encrypt XYZ RNG

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. DESSW


Slide: 14

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

CAL / CSM

Implementation Layer


Slide: 15

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

CAL / CSM

Service Types


Slide: 16

> Random Number Generator (RNG)

> Key related Interfaces

> Key Derivation

> Key Calculation for Public / Secret / SymKey *

> Key Wrapping and Extraction (sym/asym)

CAL / CSM

Service Types

*= CSM only


Slide: 17

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)

> 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

RNG #1 Generate

AES #1 Update Finish Start


Slide: 18

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

CAL / CSM

CAL Architecture


Slide: 19

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


Slide: 20

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 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.

CSM

CRY

HW DRV

AESSW AESHW XYZ

SecurityHW

Crypto Lib

RNGSW

Encrypt XYZ RNG


Slide: 21

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


Slide: 22

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

CAL / CSM

What should be used?


Slide: 23

Agenda

Introduction

CAL / CSM

> Implementation Hints

Hardware Security

Examples



Slide: 24

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


DaVinci Configurator 5


Slide: 25

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


DaVinci Developer


Slide: 26


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


Slide: 27


Example Implementation

CAL Implementation

#include "Cal.h"

void TestApplCalHash ( void )

{

uint8 resultBuffer[32];

uint32 dataLength, resultLength;

Cal_HashCtxBufType contextBuffer;

/* Initialize Hash Service: CalHashConfig_01 */

Cal_HashStart(CalHashConfig_01,

contextBuffer);

/* Processing of Block #1 */

Cal_HashUpdate(CalHashConfig_01,

contextBuffer,

plainText,

dataLength);

/* Finalize Result */

Cal_HashFinish(CalHashConfig_01,

contextBuffer,

resultBuffer,

&resultLength,

TRUNCATION_ALLOWED);

}

void TestApplCsmHash ( void )

{

uint8 resultBuffer[32];

uint32 dataLength, resultLength=32;

/* Initialize Hash Service: */

Rte_Call_CsmHash_HashStart();

/* Processing of Block #1 */

Rte_Call_CsmHash_HashUpdate(plainText,

dataLength);

/* Finalize Result */

Rte_Call_CsmHash_HashFinish(resultBuffer,

&resultLength,

TRUNCATION_ALLOWED);

}

CSM Implementation


Slide: 28

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


Service Primitive Context Buffer


Slide: 29

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


Testing


Slide: 30

Agenda

Introduction

CAL / CSM


> Hardware Security

Examples



Slide: 31

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


Slide: 32

Hardware Security

EVITA - Classification

EVITA classified 3 types of Hardware Security Modules (HSM)

The standardized Secure Hardware Extension (SHE) meets the EVITA light requirements

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, …


Slide: 33

Hardware Security

SHE - Introduction

The “Hersteller Initiative Software (HIS)” (BMW, Daimler, VW..) specified the “Secure Hardware Extension (SHE)”

SHE is a on-chip extension to any 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

Controller

CPU

Peripherals (CAN, UART, external memory interface

SHE – Secure Hardware Extension

Control Logic

AES

RAM + Flash + ROM

Secure Zone


Slide: 34

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.


Slide: 35

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)


Slide: 36

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”

Bootloader Addr Addr Data to be verified

CMAC Check CMAC Check

SHE Verification on startup.

…


Slide: 37

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


Slide: 38

Hardware Security

SHE - Performance

AES ECB Encryption: SHE vs. Software Library

0

200

400

600

800

1000

1200

1400

1600

1800

2000

SHE 64 Mhz SW 64 Mhz SHE 120 Mhz SW 120 Mhz

µs

128 Bit

384 Bit

768 Bit

24,94µs

2002.5µs

1111.6µs

13.5µs

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.


Slide: 39

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


Slide: 40

Agenda

Introduction

CAL / CSM


Hardware Security

> Examples



Slide: 41

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).

Examples

Secret storage


Slide: 42

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

Examples

Anti-Theft protection of ECUs


Slide: 43

Examples

Secured communication

Encrypted communication channel (AES)

1:1 communication relation

Dedicated sender and receiver

Identification key (PUN) against replay attacks

Encrypted signals tunneled through ISO-TP

Provides

Authenticity

Integrity

Confidentiality

Sender Receiver

TResent

TN

ew

IdKey

TO

ffset

TFacto

r

TN

ew

IdKey

TFacto

r T

Facto

r

TO

ffset

TResent T

Resent

Power up

Power up


Slide: 44

Examples

Smart charging

Smart charging

TLS Client

AES RSA

MD5 SHA-1 SHA-256 RNG

ECC (elliptical curves)

CRC16/ CRC32

Signature verification

TLS client for a secured communication channel

Signature verification

RSA based

Client certificates

Signature verification / generation

ECC based

Key generation

Symmetric encryption

AES based

Signature verification/generation


Slide: 45

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.

Examples

C2x communication

*From: ETSI Security Workshop


Slide: 46

Agenda

Introduction

CAL / CSM


Hardware Security

Examples

> Secure Reprogramming


Slide: 47

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


Introduction


Slide: 48

Physical access to an ECU is possible

Provides possibility to read out information:

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.


Physical presence of ECU

Debugging interface

Probes from external devices


Slide: 49

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


Software download

Enter Programming Session

Security Access

WriteDataByLocalId

Request Download

TransferData

TransferDataExit

StartRoutineByLocalId (Check Routine)

RequestDownload

StartRoutineByLocalId (Erase)

TransferData

TransferDataExit

StartRoutineByLocalId (CheckRoutine)

EcuReset


Slide: 50

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.


Security Access: Principle


Slide: 51

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.


Security Access: Vulnerability


Slide: 52

Application <HEX>

Application‘ <HEX>

Application

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.


Integrity

Linker Data

Processing

Bootloader (Data Processing)

Software Download

CRC

Verify

CRC


Slide: 53

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.


Authentication


Slide: 54


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?

Authentication


Slide: 55


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

Authentication


Slide: 56


Creating the digital Signature

Software module x

Signature z

Hash function y=h(x)

Data from software module X

x (arbitrary length)

y (fixed length)

s (fixed length)

Create signature s=sign(y,key)

Fin

gerp

rint


Slide: 57


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

Security Classes


Slide: 58


H

ksecret

Flashfile

Hash function ksecret: Secret key HMAC Keyed-Hash Message Authentication Code (FIPS PUB 198)

Flashfile

HMAC

H

Security Class C

Flash- download

Flash data

HMAC

Verify

HMAC Boot

ksecret

H HMAC


Slide: 59


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

Security Class C – Advantage and Disadvantage


Slide: 60


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“)

Security class CCC – Goal and Solution

*PKI: Public Key Infrastructure


Slide: 61


Flashfile

SIGN

H

Security class CCC

Flash- download

Flash data

MAC-I Verify

RSA

PKCS#1

kprivate

kprivate RSA kpublic

kpublic

PKCS#1

MAC-E

Flashfile SIGN Boot

H Code


Slide: 62

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?


Vulnerability to start conditions


Slide: 63

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?


Confidentiality


Slide: 64


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

> Enable automated flashing (data driven, without user interaction), considering dependencies based on identification

> Enable minimal flashing

ODX-F

data, start address, length

version, part number signature, checksum compressed, encoded

ODX-F Flashcontainer


Slide: 65

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

Date post:	12-Jul-2020
Category:	Documents
Upload:	others
View:	22 times
Download:	1 times

AUTOSAR-Security Module und sicheres Flashen...Hash value, that is calculated on the file and the...

Documents