DOCU 1196-Crypto SHE KeyUpdate
DOCU 1196-Crypto SHE KeyUpdate
Technical Reference
How to Persist SHE Key in MICROSAR and Functional Flow
Version 1.00.00
Document Information
History
Reference Documents
Caution
We have configured the programs in accordance with your specifications in the
questionnaire. Whereas the programs do support other configurations than the one
specified in your questionnaire, Vector´s release of the programs delivered to your
company is expressly restricted to the configuration you have specified in the
questionnaire.
Contents
7 Appendix .............................................................................................................................. 29
7.1 Appendix A................................................................................................................ 29
7.1.1 How to Get Stored Key Details .................................................................. 29
7.1.2 Crypto NVM Block Configuration ............................................................... 30
9 Contact ................................................................................................................................. 35
Illustrations
Figure 1-1 Simplified SHE Block Diagram ............................................................................. 6
Figure 3-1 One Typical Example, How the SHE Key Will be Updated by the Tester .............. 8
Figure 3-2 Structure of M1 .................................................................................................. 10
Figure 3-3 Structure of M2 .................................................................................................. 10
Figure 3-4 Structure of M3 .................................................................................................. 11
Figure 3-5 Structure of M4 .................................................................................................. 11
Figure 3-6 Structure of M5 .................................................................................................. 12
Figure 4-1 Master, Secret, Boot_Mac Keys & Boot_Mac Configuration ............................... 13
Figure 4-2 Example Configuration of Master Key Under Crypto Keys ................................. 13
Figure 4-3 Structure of Crypto_30_Libcv_SheKeys ............................................................ 14
Figure 4-4 Example Configuration of CID, FID .................................................................... 14
Figure 4-5 Key Elements of UID, Boot Protection, Debugger Protection Mapped to
the Key .............................................................................................................. 15
Figure 4-6 UID Key Element Configuration ......................................................................... 15
Figure 4-7 Configuration for Constants ............................................................................... 16
Figure 4-8 Normal SHE Key Configuration.......................................................................... 17
Figure 4-9 Normal SHE Key to Key Element Mapping ........................................................ 18
Figure 4-10 Actual SHE Key Element Configuration ............................................................. 19
Figure 4-11 SHE Key Proof (Key Element) Configuration ..................................................... 19
Figure 4-12 SHE Counter (Key Element) Configuration ........................................................ 20
Figure 5-1 Simple Flow Chart to Persist the SHE Key......................................................... 21
Figure 6-1 Prototype of Csm_KeyElementSet, Csm_KeySetValid ....................................... 23
Figure 6-2 Call Stack of the Csm_KeyElementSet Function................................................ 23
Figure 6-3 Structure of CryIf_CryptoFunctions .................................................................... 24
Figure 6-4 Prototype of Crypto_30_Libcv_KeyElementSet ................................................. 24
Figure 6-5 Crypto_30_LibCv_SheKeyUpdate Function ....................................................... 25
Figure 6-6 Crypto_30_LibCv_SheKeyUpdateVerifyAndExtract Function ............................. 26
Figure 6-7 Possible key Validity Functions in the Crypto Driver ........................................... 28
Figure 7-1 Crypto_30_LibCv_KeyElements Structure Format (Crypto SW) ........................ 29
Figure 7-2 Crypto_30_LibCv_KeyElements Structure Format (vHsm) ................................ 29
Figure 7-3 Calculation to Extract Valid Index, Start Index , End Index ( vHsm) .................... 30
Figure 7-4 Crypto NVM Block Configuration ....................................................................... 30
Figure 7-5 Call stack of MAC Generate .............................................................................. 31
Figure 7-6 Call Stack of MAC Verify .................................................................................... 32
Figure 7-7 Call Stack of 27 Service Decrypt Key (AES Decrypt) ......................................... 32
Figure 7-8 Call Stack of 27 Service Encrypt Seed (AES Encrypt) ....................................... 32
Figure 7-9 Call Stack of 27 Service Random Number Generation ...................................... 33
Tables
Table 3-1 Table Indicates Which Flags are Valid to Which Keys ........................................ 10
Table 4-1 Provides Fixed SHE IDs in SHE Page Zero ...................................................... 14
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.
As shown in the figure below, SHE provides secured storage to store keys. It also supports
basic symmetric primitive (AES).
Controller
Secure Zone
AES
Control
CPU
Logic
RAM + Flash + ROM
SHE provides several memory slots to store keys and provides a feasibility to update these
stored keys with additional checks through flags & counter values. See section 3.1 and 3.2.
OEM
Garage
3. DiagRequest(KeyUpdate, M1|M2|M3)
Diagnose
ECU
Tester
4. DiagResponse(KeyUpdate, M4’|M5’)
Figure 3-1 One Typical Example, How the SHE Key Will be Updated by the Tester
1. Step 1: OEM or User will provide the Kauth, Knew, CID, UID, FID to the Generator
2. Step 2: Generator Generates M1, M2, M3, M4 & M5 (Refer sections from 3.3 to 3.7)
values and provides to the Tester
3. Step 3: Tester sends the M1, M2, M3 values, which holds the actual key to be
persisted, as well as further Authentication key details.
ECU decrypts the data by using Authentication Key and other Generated keys (K1, K2
Refer section 3.4 & 3.5). Actual SHE key will extracted from the decrypted data.
ECU verifies the M3 value and SHE key be persisted after M3 verification successful.
4. Step 4: If user configures the proof, ECU calculates M4’ & M5’ and sends to the
Tester.
5. Step 5: Tester receives the M4’ & M5’ and compares with M4 & M5.
6. Step 6: If the M4 & M5 comparison (Step5) successful, Tester sends the success
result to the Generator
7. Step 7: Generator increments the CID (Counter Identifier value) and sends to the
OEM, where this incremented Counter value is being used for the next key persisting.
Reference
Please refer chapters below for more details of the M1, M2, M3, M4 & M5, UID, CID,
FID, Kauth, Knew.
> WRITE_PROTECTION: if this flag is set “1”, key slot can’t be overwritten.
> BOOT_PROTECTION: If this flag is set to “1”, key can’t be used if the Secured boot
process has not finished or failed.
> DEBUGGER_PROTECTION: If this flag is to “1”, key can’t be used if the debugger is
attached on device.
> KEY_USAGE: Determines if a key can be used for en/decryption or MAC. Flag set
means that it`ll be used for MAC generation/verification otherwise it can be used for
en/decryption.
> WILDCARD: UID can be replaced with Wild card value (Zeros) when this flag is
disabled.
> CMAC USAGE: This flag is only checked is KEY USAGE is “1” otherwise it shall be “0”,
If the flag is set the key can only be used for CMAC verification otherwise used for
Generation
CMAC USAGE
FID
PROTECTION
PROTECTION
PROTECTION
KEY USAGE
DEBUGGER
WILDCARD
Counter
WRITE
BOOT
SHE Key
SECRET_KEY * *
MASTER_ECU_KEY
BOOT_MAC_KEY
BOOT_MAC
KEY_{n}
RAM_KEY_{Page}
Table 3-1 Table Indicates Which Flags are Valid to Which Keys
3.3 Generation of M1
In the figure below, SHE ID (4bits) provides the respective key slot number from the ECU,
where the SHE key has to be persisted.
AuthID (4bits) provides the Authentication Key Slot number, where respective key be used
for Authentication.
If AuthID slot is same as ID slot: Previous persisted SHE key in the same ID slot be used as
Authentication Key. AuthID slot is “1” to use Master key as Authentication key.
3.4 Generation of M2
ENCCBC, K1, IV=0
M2 FID (Flag)
CID:Counter „0…0“ KEYID
(256 bits) WP BP DP KI WC CU
(28 bits) (94 bits) (128 bits)
(6 bits)
The Concatenated string of CID, FID, Zeros and KEYID will be given as input string for the
AES Algorithm, which follows CBC method. Input Vector is Zeros and another key is K1.
K1 = AESMP(K_auth ┤|KEY_UPDATE_ENC_C)
K_auth: Value of the authentification key used for the Key Update.
KEY_UPDATE_ENC_C: constant value.
AESMP is AES128 - Miyaguchi-Preneel construction.
3.5 Generation of M3
M3 is verification Message and is calculated as CMACK2 (M1|M2)
M3
CMACK2 (M1|M2)
(128 bits)
𝑀1 = 𝑈𝐼𝐷 | 𝐼𝐷 | 𝐴𝑢𝑡ℎ𝐼𝐷
𝑀2 =𝐸𝑁𝐶_ (𝐶𝐵𝐶, 𝐾1, 𝐼𝑉=0) (𝐶𝐼𝐷^′ ┤|𝐹𝐼𝐷^′ | 〖"\"0…0\""〗_ (95 ) |𝐾𝐼𝐷′)
𝐾2= 𝐴𝐸𝑆𝑀𝑃 (𝐾_𝑎𝑢𝑡ℎ |𝐾𝐸𝑌_𝑈𝑃𝐷𝐴𝑇𝐸_𝑀𝐴𝐶_𝐶)
𝐾_𝑎𝑢𝑡ℎ: Value of the authentication key used for the Key Update.
𝐾𝐸𝑌_𝑈𝑃𝐷𝐴𝑇𝐸_𝑀𝐴𝐶_𝐶: constant value.
3.6 Generation of M4
M4 is being used for verification
ENCECB,K3
M4 UID ID Auth ID
CID:Counter „1“ „0…0“
(256 bits) (120 bits) (4 bits) (4 bits)
(28 bits) (1 bit) (99 bits)
3.7 Generation of M5
M5
CMACK4 (M4)
(128 bits)
Refer 2.2 for details of these keys. Above configuration represents at ECU side, where
respective key elements should be mapped through the Crypto Keys.
Example
In the Figure 4-1 MASTER_ECU_Key has been mapped with the She_Master_Key,
which is from the Crypto Key (as shown in below Figure 4-2).
Key ID of the Master key is 6, which has been reflected in the below structure
Crypto_30_Libcv_SheKeys as shown in the Figure 4-2.
Note
For the Master Key the SHE page is fixed to Zero and SHE ID is also fixed to 1.
Hence during M1 calculation AUTHID slot and SHE ID slot should be the same, which should
be “1” (Refer section 3.3).
The table below shows that the keys are existing in the SHE page Zero and respective SHE
IDs are also fixed.
SHE Key SHE ID SHE Page
Security Key 0 0
Master ECU Key 1 0
Boot MAC Key 2 0
Boot MAC 3 0
Table 4-1 Provides Fixed SHE IDs in SHE Page Zero
> SHE Enable Counter (CID): This Parameter should be enabled, if user want to
consider the counter to be validated during persisting of SHE Keys. Reg the CID refer
section 3.1 & 3.4.
> SHE Enable FID: Refer section 3.2. If FID check is disabled all protection flag values
will be interpreted by the Software as Zero. (key usage will be used only for
En/Decryption and CMAC usage bit not being used)
> SHE Info Key Ref: Reference to the key which holds the UID Key, Boot Protection &
Debugger Protection Control Key Elements. Where Boot & Debugger Protection Key
elements are needed only, when SHE Enable FID has been enabled and its size is
limited to 1 byte. Boot & Debugger protections key elements are normal plain text keys
and hence Read Access & Write Access be configured as ALLOWED.
> Respective Key Ids of Boot Protection & Debugger protection are 3056 & 3057.
Figure 4-5 Key Elements of UID, Boot Protection, Debugger Protection Mapped to the Key
The screenshot above indicates the key element configuration for the UID (it is just a sample
configuration).
UID is used as ECU ID, which is a unique value for each hardware, This UID value should
be the same at both Sender & Receiver side. This can be used to generate encrypted key
information (M1|M2|M3) which is only valid for a specific ECU or FID wildcard support is
used.
Refer section from 3.4 to 3.7 for the Key Update Constant usage, where these constants
are being used to Generate Back ground keys K1, K2, K3 & K4. Same Constants be used
at both Sender & receiver side. These constants are configured at each Page level.
Note
Page 0 related keys (Master Key, Secret key, Boot MAC key & Boot Mac) uses
Constants which are configured to SHE page ID 1
SHE page Constants which have been used in M2, M3, M4 & M5, are selected through the
structures below in the software.
CONST (Crypto_30_LibCv_ShePageType, CRYPTO_30_LIBCV_CONST)
Crypto_30_LibCv_ShePage[x],
which provides the Start & End Indexes for both ENC, MAC constants.
Based on the Index from the above structure, the constants values are extracted from the
array Crypto_30_LibCv_SheConstants [x].
Note
All Normal SHE keys IDs start from 4.
The screenshot above shows the Key Type Configuration which abstracts key configuration
and respective key elements configuration.
It shows that the key mackey_Slot1 has three key elements.
> Key Element Init Value: These init values are being used by the software, in case a
key element was not persisted or issue during reading of persisted values occur.
> Key Element Persist: This option will be used by the Crypto SW Library, where
the keys are writing in the NVM. If this option is enabled, then only this key will
be written in the NVM during NVM_WriteAll function.
> For the SHE Key Read Access & Write Access is always WA_ENCRYPTED.
4.5.2 SHE Key Proof
Poof key element is being used to store the M4 & M5 values, which is of size 48 bytes. Refer
section 3.6 & 3.7. Generally proof (M4 & M5) won’t be persisted in the NVM. As mentioned
in the section 3 (Figure 3-1), these values are needed only for the verification, which will be
sent to the tester.
Note
As per the section 4.2, if the SHE enable counter is enabled then this key element value
needs to be stored. If user is using NVM option, then user has to enable Key Element
Persist.
Reference
Refer section 3 Step 7 & 3.1 for the CID Functionality.
5 Flow Chart
6 Code Flow
Note
To persist any SHE Key, the user has to call: Csm_KeyElementSet (keyId,
keyelementID, m1m2m3, 64). Once the key has been written, the user has to call
Csm_KeySetValid (keyId). Key can be used only after the above two functions
are successful.
Key Element ID is known from the respective key element configuration from the Crypto
Driver configuration. In this case key is the actual SHE key which has to be persisted. Refer
section 4.5.1.
This Crypto Driver function be selected from the below structure in the CryIf_Cfg.c file
CONST (CryIf_CryptoFunctionsType, CRYIF_CONST)
CryIf_CryptoFunctions[x] = {}
The function above checks for the write protection and returns
CRYPTO_E_KEY_NOT_AVAILABLE in case if the write protection has been configured
different from WA_ENCRYPTED for the SHE Key.
6.2 Crypto_30_LibCv_SheKeyUpdate
In both cases of vHsm & SW Crypto, function Crypto_30_LibCv_SheKeyUpdate will be
called, after write protection verifies.
6.3 Crypto_30_LibCv_SheKeyUpdateCheckM1Ids
> This function extracts the both, Authentication ID and SHE ID from the M1 value (Refer
section 3.3).
> SHE ID will be verified with configured SHE ID. Configured SHE ID is available in the
structure Crypto_30_LibCv_SheKeys.
> Send E_NOT_OK if the received SHE ID not identified in the configuration.
> Send E_NOT_OK if the SHE ID is SECRET Key ID.
> Send E_OK if the SHE ID is same as Authentication ID.
> If SHE ID is not same as Authentication ID, check the Authentication ID as MASTER
KEY ID, if yes extract the Authentication ID index details.
6.4 Crypto_30_LibCv_SheKeyUpdateVerifyAndExtract
6.5 Crypto_30_LibCv_SheKeyUpdateVerifyM3
Note
Only in vHsm checking for the Authentication key validity, in Crypto SW library this
check is not there.
6.6 Crypto_30_LibCv_SheKeyUpdateExtractKey
> After “M3 and UID” verification successful, need to extract the SHE Key, UID, CID from
M2.
> Update Key_Update_Enc_C from the structure Crypto_30_LibCv_SheConstants
> Calculate K1 by using AES-MP method
Crypto_30_LibCv_SheKeyUpdateMiyaguchiPreneel ()
> Decrypt the M2 Data, which is UID, FID and SHE Key Value.
> If Enable Counter is ON (CRYPTO_30_LIBCV_SHE_ENABLE_COUNTER ==
STD_ON, refer section 4.2 for the respective configuration parameter), received
counter value from M2 will be verified with the stored counter value, which is extracted
from the respective Key Element ID.
Note
If the user has enabled the Enable SHE Counter, the user has to configure one key
element for counter. Refer 4.2, 4.5, 4.5.3.
> New counter value from M2 should be greater than stored counter value
> Store the new SHE key in the respective buffer in the respective index of the array
Crypto_30_LibCv_KeyStorage
Note
To store the validity bit, one byte has been allocated for each key element. This validity
status (this byte) will be stored in the array Crypto_30_LibCv_KeyStorage, in the
respective Index.
Index details can be known through the Crypto_30_LibCv_KeyElements structure.
Refer appendix Figure 7-4 & Figure 7-5.
7 Appendix
7.1 Appendix A
7.1.1 How to Get Stored Key Details
> All key values will be stored in the variable VAR
(Crypto_30_LibCv_KeyStorageType, CRYPTO_30_LIBCV_VAR_NOINIT)
Crypto_30_LibCv_KeyStorage []
> This Array is available in the Crypto_Libcv_30_cfg.c file
> The index details of a particular key (representation of each byte in the
Crypto_30_LibCv_KeyStorage) will be known through the structure
CONST (Crypto_30_LibCv_KeyElementsType, CRYPTO_30_LIBCV_CONST)
Crypto_30_LibCv_KeyElements []
> In case of Crypto SW Library, below is the Crypto_30_LibCv_KeyElements
structure format
For the other elements (Valid Index, Length Start Index and End Index), it follows calculation
below.
Index information is extracted from the start index. Byte order is same as Crypto SW.
Figure 7-3 Calculation to Extract Valid Index, Start Index , End Index ( vHsm)
During NVM Write Crypto_30_Libcv_KeyStorage will be written into the NVM and during
NVM read all data from the NVM will be copied to the Crypto_30_Libcv_KeyStorage.
7.2 Appendix B
Note
Below stack flow for few uses cases, which would give idea about the function flow.
The flow will vary based on customer requirements and configuration.
Especially for the random number generation.
The flow would be same until dispatch service and further function calls may vary
based on the configuration.
8.1 Abbreviations
Abbreviation Description
AUTOSAR Automotive Open System Architecture
AES Advanced Encryption Standard
AES-MP Advanced Encryption Standard - Miyaguchi-Preneel
Auth ID Authentication Identifier
BP Boot Protection
CID Counter Identification
CMAC Cipher Based Message Authentication Code
Cry IF Crypto Interface
CSM Crypto Service Manager
CU CMAC Usage
DP Debug Protection
ECU Electronic Control Unit
ENC Encryption
FID Flag Identification (Protection Flags)
K1 Key “1” (numeric number may vary)
KU Key Usage (0=AES, 1=CMAC)
MAC Message Authentication Code
MICROSAR Microcontroller Open System Architecture (the Vector AUTOSAR solution)
NVM Non-Volatile Memory
RA_ Read Access
SHE Secure Hardware Extension
SWS Software Specification
UID Unique Identification Identifier
WA_ Write Access
WC Wild Card
WP Write Protection
9 Contact
> News
> Products
> Demo software
> Support
> Training data
> Addresses
www.vector.com