Freescale PowerPoint Template - NXP Semiconductors€¦ · worked on by AUDI and BMW together with...

TM

Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, C-Ware, t

he Energy Efficient Solutions logo, mobileGT, PowerQUICC, QorIQ, StarCore and Symphony

are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. BeeKit, BeeStack,

ColdFire+, CoreNet, Flexis, Kinetis, MXC, Platform in a Package, Processor Expert, QorIQ

Qonverge, Qorivva, QUICC Engine, SMARTMOS, TurboLink, VortiQa and Xtrinsic are trademarks

of Freescale Semiconductor, Inc. All other product or service names are the property

of their respective owners. © 2011 Freescale Semiconductor, Inc.

23 June 2011

TM

Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, C-Ware, the Energy Efficient Solutions logo, mobileGT, PowerQUICC, QorIQ, StarCore

and Symphony are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. BeeKit, BeeStack, ColdFire+, CoreNet, Flexis, Kinetis, MXC, Platform in a

Package, Processor Expert, QorIQ Qonverge, Qorivva, QUICC Engine, SMARTMOS, TurboLink, VortiQa and Xtrinsic are trademarks of Freescale Semiconductor, Inc.

All other product or service names are the property of their respective owners. © 2011 Freescale Semiconductor, Inc.

2

Tweeting? Please use hashtag

#FTF2011

Freescale on FacebookTag yourself in photos

and upload your own!

• Motivation for implementing Cryptographic Services

Engine (CSE)

• Basic Cryptography implemented by CSE

• Basics of how CSE works and how it is integrated into

MPC564xB/C

• Automotive security use-cases

TM





3

• SHE - Secure Hardware Extension

− Is the functional specification for a peripheral module mainly

worked on by AUDI and BMW together with a company called

escrypt. It is now an official HIS Specification and is under

copyright of the AUDI AG and BMW AG ©, 2008.

“The Secure Hardware Extension (SHE) is an on-chip extension to

any given microcontroller. It is intended to move the control over

cryptographic keys from the software domain into the hardware

domain and therefore protect those keys from software attacks.”

• CSE Cryptographic Services Engine

− The Cryptographic Services Engine (CSE) is a peripheral

module that implements the security functions described in the

Secure Hardware Extension (SHE) Functional Specification

Version 1.1. It is first implemented on MPC564xB/C.

TM





4

• CSE module implements the official SHE Specification (Version 1.1)

• CSE module is open to further extensions (e.g. ECC, SHA-256 etc)

• CSE module is core based and includes an AES cipher and a random number generator

• CSE module interfaces:

− Crossbar master interface

CSE has access to the entire system memory space

− Configuration interface

• System flash blocks are assigned to the CSE module. Access from other masters is impossible

TM





5

• Secure Core

− 32bit Core (ColdFire V1)

− Up to 120 MHz clock frequency –runs on system clock

• AES (Advanced Encryption Standard)

− Bus Master / DMA programming model

− Supported crypto modes:

ECB (electronic codebook)

CBC (cipher-block chaining)

Minimal throughput 100 MBit/sec

− Latency 2µs per one en-/decoding operation

Ek

Ci

Pi

ECB

Ek Ek Ek

Ci-1 Ci+1Ci

Pi-1 Pi+1Pi

IV

CBC

TM





6

• Secure NVM

− NVM emulation on secure flash blocks (2x16k DataFlash)

− Up to ten generic keys, additional special purpose keys

− Protected by hard-coded connection with CSE, no access by

other master possible

• RNG (Random number generator)

− PRNG (Pseudo RNG) seed generation via TRNG (True RNG)

TM








TM





8

• In cryptography, a block cipher operates on blocks of fixed length, often 64 or 128 bits. Because messages may be of any length, and because encrypting the same plaintext under the same key always produces the same output several modes of operation have been invented which allow block ciphers to provide confidentiality for messages of arbitrary length. Well used modes are: Electronic codebook (ECB), Cipher-block chaining (CBC), Cipher feedback (CFB), Output feedback (OFB) and Counter (CTR) Counter (CTR)

• Electronic codebook (ECB)

− The simplest of the encryption modes is the electronic codebook (ECB) mode. The message is divided into blocks and each block is encrypted separately. The disadvantage of this method is that identical plaintext blocks are encrypted into identical ciphertext blocks; thus, it does not hide data patterns well. In some senses, it doesn't provide serious message confidentiality, and it is not recommended for use in cryptographic protocols at all.

• Cipher-block chaining (CBC)

− CBC mode of operation was invented by IBM in 1976. In the cipher-block chaining (CBC) mode, each block of plaintext is XORed with the previous ciphertext block before being encrypted. This way, each ciphertext block is dependent on all plaintext blocks processed up to that point. Also, to make each message unique, an initialization vector (IV) must be used in the first block.

Block Cipher

Encryption

Ciphertext

Plaintext

Key

ECB

Block Cipher

Encryption

Ciphertext

Plaintext

Key

IV

Block Cipher

Encryption

Ciphertext

Plaintext

CBC

TM





9

• Cipher based Message Authentication Code (CMAC)

• A MAC (Message Authentication Code) algorithm accepts as input a secret key and an arbitrary-length message to be authenticated, and outputs a MAC. The MAC value protects both a message's data integrity as well as its authenticity, by allowing verifiers (who also possess the secret key) to detect any changes to the message content.

• Block cipher-based message authentication code algorithm.

• Used to provide assurance of the authenticity and, hence, the integrity of binary data

MAC algorithm

key

message

MAC

TM








TM





11

• CSE has its own Secure Flash area.

− This Flash is not accessible by any other master except CSE

− This is used to store both Firmware, Non-user keys and User Keys

Firmware and Keys are copied to the CSE by either

• SSCM issuing the SECURE_BOOT command

• OR by user software issuing INIT_CSE command

− User software is not allowed to issue SECURE_BOOT

• KEYS

− User Keys (all 128 bits)

− These are programmed by the user and are not present in devices from the factory

− There are 10 general purpose keys KEY1..KEY10 plus a volatile key RAM_KEY

− MASTER ECU KEY – has the authority to update all other keys

XBAR-IFIP SkyBlue-IF

CSE

Core

AES

XBARPeripheral

Bridge

BIUFLASH

RAM

SRAM

CSE Block

Sec. FLASH

INTC

Host

Inter.

Core eDMA FlexRay

MPU

MI

DEBUG

NEXUS

JTAG

UTI

ROMINTC

Masters

Slaves

Debugger

connected

Test Interface Array

Test Interface BIU

Host to CSE

Interrupt

on/

off

Secure „Firewall“

PB-IF

RNG

Secure Flash

UID SK SHE-FW

KEY_<2…10>

MK BMK BMAC

KEY1

TM





12

• User keys (continued)

− BOOT_MAC_KEY – a special key which is used to generate BOOT MAC

− BOOT_MAC is a CMAC generated or verified at boot time by the CSE in certain boot modes

• Non User Keys

− These cannot be updated by the user

SECRET_KEY -128 bits – a random number programmed in manufacturing and remains a secret forever.

UID – Unique Identification Item –120 bits ; a unique identifier programmed in manufacturing. Can be retrieved using the GET_UID CSE command.

Secure Flash

UID SK SHE-FW

KEY_<2…10>

MK BMK BMAC

KEY1

XBAR-IFIP SkyBlue-IF

CSE

Core

AES

XBARPeripheral

Bridge

BIUFLASH

RAM

SRAM

CSE Block

Sec. FLASH

INTC

Host

Inter.

Core eDMA FlexRay

MPU

MI

DEBUG

NEXUS

JTAG

UTI

ROMINTC

Masters

Slaves

Debugger

connected

Test Interface Array

Test Interface BIU

Host to CSE

Interrupt

on/

off

Secure „Firewall“

PB-IF

RNG

TM





13

• Key Attributes

− Each key has the following attributes which may be used to limit the use of a specific key

Write Protect (WP) – can be used to make a key so it can be updated or erased. Use with caution. Will render key unable to be updated.

Boot Protect (BP) – a key can be disabled if the BOOT_MAC calculation did not match what was previously stored in the BOOT_MAC key slot.

Debugger Protection (DP) – a key can be disabled if a debugger has been or is currently attached is currently attached

Wildcard Updates (WC) – a key can be protected from Wildcard Updates (UID’=0)

Key Usage (KU) – a key is assigned to be use for either encryption/decryption (KU=0) or for MAC generation/verification (KU=1)

− A counter is stored with each key in secure flash and this must be incremented on every update (this helps prevent replay attacks).

− A checksum is stored with each key

TM





14

• SHE supports CBC (Cipher Block Chaining Mode) for encryption and decryption of data

• The key being used must have KU =0 (ENC)

• CBC uses an initial value (which must also be supplied for decryption)

• Example codewhile (CSE.SR.B.BSY ==1){}

/*wait until CSE is idle*/

CSE.P1.R CSE_KEY_1;

/* KEY_1 has KEY_USAGE=0 (encryption) */

CSE.P2.R = (vuint32_t)&initial_value_cbc;

CSE.P3.R = 16; /* number of 128 bit blocks = 64 * 32 /128) */

CSE.P4.R = (vuint32_t)&data_for_encryption;

CSE.P5.R = (vuint32_t)&encrypted_data;

CSE.CMD.R= CSE_ENC_CBC;

• The same initial value must be used for CBC decryption

AES

algorithm in

CBC modekey

Data to be

encrypted Encrypted

data

Initial value

TM





15

• The key being used must have KU =1 (MAC)

• Example code

unsigned long long length = 320; while (CSE.SR.B.BSY ==1){}

/*wait until CSE is idle*/

CSE.P1.R = CSE_KEY_7; /* KEY_7 has KU=1 (MAC) */

CSE.P2.R = (unsigned long long)&length; /* address of msg length in bits*/

CSE.P3.R = (vuint32_t)&CMAC_MSG; /* address of the message */

CSE.P4.R = (vuint32_t)&CMAC_OUTPUT; /* address where CSE will write CMAC */

CSE.CMD.R= CSE_GENERATE_MAC;

• CMAC output is 128 bits.

AES

algorithm in

CMAC modekey

message128 bit

CMAC

TM





16

• CSE has a mechanism which allows users to authenticate a section of boot code in flash.

• The part can be configured so that on every boot a section of code is authenticated and the generated MAC will be compared with a value previously stored in Secure Flash

− This is supported only for flash boot modes.

− Not supported for other boot modes (serial download, wakeup to RAM) as these may present a potential security issue

• The key used to authenticate the boot code is called BOOT_MAC_KEY

• The value compared against (in secure flash) is called BOOT_MAC

• Extra information is added to the start of the boot block after the Reset Configuration Half Word.

• If SECURE_BOOT fails (boot code is not authenticated) keys which are marked as BOOT_PROTECT cannot be used.

TM





17

• In this example the boot code starts at 0x10 and CSE will

authenticate 4Kbytes of code

• 0xC is skipped because CSE can authenticate code

significantly faster if authentication starts on a 64 bit

boundary.

Address Content Comment

0x0 0x15A RCHW

0x40x10 Start address for

BOOT_MAC calculation

0x80x1000 Length of code to be

authenticated in bytes

0xC This address is skipped

0x10 Code starts here

TM





18

AES algorithm in

CMAC mode

(within CSE)

BOOT_MAC_KEYCode to be

authenticated

BOOT_MACStart

address

(0x0 in our

example

Code length

(value stored

at 0x08 in our

example





19TM

SSCM Issues SECURE_BOOT

command

CSE ROM Downloads Firmware & valid

Keys from Secure Flash

Set CSE_SR[SB] (=1)

Clear CSE_SR[SB] (=0)

Is

BOOT_MAC_

KEY slot

empty?

STOPYes

No

CSE Calculates BOOT_MAC over

identified boot code

CSE Action

SSCM Action

Application

Action

KEY :





20TM

CSE compares value stored in

BOOT_MAC slot with the value it

calculated

Application Code Issues BOOT_OK

Set CSE_SR[BOK]=0

CSE stores calculated MAC

in BOOT_MAC slot

Is

BOOT_MAC

slot empty?STOP

Yes

No

CSE_SR[BOK]=1

CSE_SR[BIN]

=1

Do values

match?

No

Yes

CSE_SR[BFN]=1

CSE_SR[BFN]=1

CSE Action

SSCM Action

Application

Action

KEY :

TM








TM





22

• Assume the secure boot function was executed and the required keys are coupled to the customer application.

• The car key and the CSE based ECU share one crypto KEY.

• The ECU sends an random value to car key. The car key send this value encoded back to the ECU.

• The ECU verifies the return-value received from the car.

• As long as the result doesn’t match, the ECU will not start the engine.

• This system could be combined with component protection to increase security.

Steering lock

with antenna

Key with

Transponder

ECU

Fuel Ignition

CSE

Core

RAM

Public Flash

Secure Flash

UID SK

Peripheral

application code

SHE-FW

KEY_<2…10>

MK BMK BMAC

Random Encrypt

KEY1

KEY1

RNG

TM





23

• Assume Secure boot was executed, CSE keys are coupled to the application code.

• Mileage is decoded in non-volatile memory

• When the system starts, mileage will be copied from EEPROM (emulation) into the internal SRAM.

• Decoding of the encoded data by the CSE with one of the general purpose keys.

• Every time when the mileage value should be re-written into the NVM it must be encoded beforehand.

• Due to the fact that CSE can be disabled while a debugger is connected, modifications of the RAM copy during runtime isn’t possible.

• This example is re-usable for all dataset based use-cases

CSECSE will decode

& copy date from

flash into RAM

Core

RAM

Public

Flash

application

code

MileageA

(ciphertext)

MileageA

(plaintext)

MileageB

(ciphertext)

CSEEvery time before

the mileage will

be re-written into

the NVM, the

CSE will encode the

actual value

CoreWhen writes

back the

encoded data

into the NVM

Core triggers

decoding function

(e.g.

CMD_DEC_ECB)

triggers

encoding

function

READ

WRITE

TM





24

• Assume the secure boot function was executed and the used keys are coupled to the customer application on each ECU.

• One ECU of a group, will be assigned as security master.

• The security master will “poll” each ECU of the group and request his UID in encoded form. The key for the encoding is shared with the ECU and the security master. The crypto key is stored inside the CSE secure memory. The polling will happen multiple times (e.g. once per 10 minutes).

• The security masters compare all received UIDs with an internal database. This database includes all assembled ECUs.

• In case on ECU is disassembled and re-assembled in another car, the UID and crypto key doesn’t match and the component protection system could re-act on this issue (e.g. non comfort features).

ECU 1

CSE

Core

Secure Flash

UID KEY1

Peripheral

RAM Flash

Security Master

CSE

Core

Secure Flash

UID KEY1

Peripheral

RAM Flash

ECU 3

CSE

Core

Secure Flash

UID KEY1

Peripheral

RAM Flash

ECU 2

CSE

Core

Secure Flash

UID KEY1

Peripheral

RAM Flash

ECU n

CSE

Core

Secure Flash

UID KEY1

Peripheral

RAM Flash

…

car

database

Security Master (SM)

In case the SM is fix assigned by

the OEM it is additional

mechanical protected (e.g. part of

the motor block etc.). Alternatively

the SM will be assigned by an

algorithm during the startup phase.

OEM network

Connection to the OEM network

when the car is in the garage.

This gives the OEM the chance

to manage to database.

TM





25

• After every reset the CSE executes the secure boot (SB) function, initiated by the SSCM.

• The SSCM reads the SB parameters from public flash:

− application reset vector

− block size

• The CSE verified the first application code/data block 0 autonomously

• CSE support to setup a “Chain of trust”

• This system will detect every application modification by a hacker

Public Flash

application code/data

block 0


block 1


block 2


block n

SSCM

CSECore

Init with

reset-

vector and

size

Verified code could

check the following

block.

In case only one

verification step fails,

the CSE keys

KEY_<1…10> are

disabled and can’t be

used anymore.

.

.

.

TM





26

Session materials will be posted @

www.freescale.com/FTFLook for announcements in the FTF Group

on LinkedIn or follow Freescale on Twitter

• We have covered:

− Motivation for implementing Cryptographic Services Engine

− Basic Cryptography implemented by CSE

− Basics of how CSE works and how it is integrated into

MPC564xB/C

− Automotive security use-cases

• In addition there are 2 Application Notes available:

− AN4234 - Using the Cryptographic Services Engine

− AN4235 - Using CSE to protect your Application Code via a

Chain of Trust

• Questions?

http://www.freescale.com/FTF

Freescale PowerPoint Template - NXP Semiconductors€¦ · worked on by AUDI and BMW together with...

Documents

Transcript of Freescale PowerPoint Template - NXP Semiconductors€¦ · worked on by AUDI and BMW together with...