HW Security Modules

Hardware Security Modules

As the vehicle connectivity increase the need to have a more secured and powerful HW to handle the complexty in Security algorithms and the increasing in Security functionality

Here as we are in the market of HW we have two options the SHE is Secure Hardware Extension here we have a basic functionality where we have the ability to protect our keys do basic Symmetric encryption and Decryption as AES-128 functionality but share the same memory with the application domain also the Crypto SW run on the application core

On the other hand we have the full feature HSM where it is provide a full Security functionality and also the complex functionality like asymmetric encryption for example ECC or sha-256

SHE

provide the basic Security requirements for example protect the location where we save the Encryption and Decryption Keys but still the application core have access to this location it may have restriction access but we protect specific location the Flash memory also this have a weakness as the Main bus see this location we will sea the HSM how the HW implemented to fix this issue.

SHE also support Symmetric basic algorithms for encryption and Decryption and hashing used in message digest

but it on the other hand used in low cost controllers where the overall cost is matter in the developed project

SHE and HSM

we can map this to 80/20 method as the most and basic functionality of Cyber Security is provided by SHE and the remaining Functionality is provided by HSM the most powerful and cost tasks

Automotive Cyber security project Architecture

Application domain - Security domain - System interconnect

Application domain :

Is unsecured domain and handle all the basic functionality of the ECU

Secure Domain (HSM / SHE ) :

Is the security Hardware that run the cryptographic Software and protect and manage the Keys generation and Encryption and decryption Functionalities

System interconnect :

Firewall or API (ICPs) provided by HSM or security module to receive and perform specific Security actions

Trust boundary(enforcing isolation) :

Is the concept that physically isolate the secure HSM domain from the nonsecure application domain

It is not a SW convention but it is a immutable HW mechanisms

So now we need to know how to guarantee that this trust boundary is implemented and configured correctly

Dedicated CPU - MPU - Firewall interface

Dedicated CPU

Allow the activation of the security environment far from the untrusted environment

MPU :

To protect and restrict APP from access the HSM memory

Firewall interface :

Secured interface so The HSM will receive the requests through a mailbox from the app then the HSM will poll through these requests and perform it in a security way

Some of critical functionalities provided by the HSM

Secure boot and secure firmware update - cryptography acceleration (AES 128/256 - ECC - CMAC ) Secure key management

HSM

Secure BOOT

[ definition - needs - Types of the attacks - Purpose ]

Secure boot definition :

It is the process to protect the device at the booting stage itself against Authenticity and integrity of the SW it is a part of the what we called root of trust

Mechanism :

We need to ensure that the application code will not be loaded or executed until the boot loader is checked against Authenticity and integrity then after that the BL will started and then verify and do the remaining checks no the application code itself. So now we can address the importance of secure boot

Secure boot is used to perform the security checks that not addressed by the Application code it self as this stage is the first stage and executed before the app/BL code loaded or allowed to start the execution and take the control over the ECU . So we need that the BL stage to be protected from the hackers that may change the BL it self

Types of the attacks that prevented by Secure boot :

1 - malicious Firmware injection

(by give the HSM to control over the ECU to check that the BL code is verified ) then decide to give the BL the control or not so we can have the strong Security functionalities a the app code but if the BL code is tempered then the overall security will be Brocken.

2- tampering BL modification

Through checking the Authenticity and the integrity of the BL code before the BL code itself started

3- DOS denying of service

Attackers can try to corruption BL so the all ECU will stop Functionalities

So Secure boot is here to to ensure that only authorized and uncompromised firmware initiate the device

Chain Of Trust :

Which mean the Security Check is done sequentially one after another if one cycle is brocken then the all Security chain will be breaked

First Step of RoT (Root Of Trust) this step is done through HW component HSM

After the ECU is powered on the Vector Table will jump to SW stored in immutable memory inside HSM so that it will run some preconfigured Security Steps on the BL through stored Keys in Secured memory (Boot mac key)and if the step is verified then the BL will be start its functionalities to proceed with the chain functionalities

Also RoT help where we have an ota and dual bank application that we prevent the attacker from switch back to the old version app that may have a security bug or a vulnerability on it

MAC ( message Authentication codes )

But why we need to check the Authenticity if we checked the integrity of the SW

Ok buy integrity itself we can not gruntee 100% that this Our SW that we need to execute

As may any hacker can change the SW with its integrity as CRC or the Hash so we need to be grantee all the time we have an authorized SW and this is done only through encrypt the Calculated Hash with the shared Key with OEM so then with this key we can decrypt the message and then check that this is the public key

So using CMAC (Symmetric encryption ) or Message digest (Asymmetric encryption ) it depends on the needs and the required efficiency and security level

After the BL software is flashed the HSM will start its process to calculate the encrypted message on the predefined memory area using Boot MAC Key then store this value is secured memory so it will be checked each time in the boot process

Secure lock feature

Encompasses three main functions

Capturing & reading incidents

Store it in secure memory in HSM

OEM then will decide the action based on these logs

So OEM will decide which secure feature will be logged in buffer runtime only or permanent in Secured flash

Types of logs ( Secure [ communication - access - unlock - boot ])

Secure Boot is done through two ways

( Symmetric - Asymmetric )

Symmetric Secure Boot process

Boot MAC Key : this key is important to check the BL Code integrity

Master Key is used to update the Boot Mac Key in secure flash so it used to check the Authority and add a protection layer to protect Boot MAC key through any Malicious SW

So the Boot Mac key and master kay used to make sure that the trusted and Authorized SW is executed

Pre-Boot Step - During development

We need to specify the flash area we will calculate the Mac key on it ( BL - App ) or both then this key will started in the secured flash through Master key so this secure flash is protected by HSM

So after a reboot the HSM will activated first so It will check the integrity of the Software through calculating the Boot MAC kay on the configured area then will compared with the stored Key if both matched the the BL SW is verified and can take the control to the ECU On the other hand Asymmetric secure boot process

Work with digital signature so both Authenticity and integrity of the BL code will be check in this phase using PKI Signature creating process

Hashing SW -> signing it -> distributing it

So this digital signature will be checked in the boot stage

So Secure flashing

Prevent unauthorized SW - restrict access to the authorized person

The Key Management Lifecycle: From Birth to Retirement

SHE

SHE use PRNG to generate random number then encrypted with what is called PRNG_KEY while this process produce members that may appear to be random but it generated through a predicted way if we use the same Kay and Counter value but it is sufficient for some simple application like generating challenges but failed to achieve the High quality Cryptographic key requirements

HSM

HSM on the other hand the SEED here is TRNG physical quantity where it will be seed a high quality Deterministic Random Bit Generators (DRBG ) so we generate a strong random key to be used in Symmetric encryption decryption processes

Secure Keys storage

SHE store the Keys in partitioned area in the main flash area access these locations by the main Core is prevented by the hardware implementation where there is a predefined steps need to achieved to access these areas

HSM : on the other hand HSM have its own core and Memory to run and store the generated keys and the Main CPU by hardware implementation not have any access to these memory locations even direct or indirect access so the main CPU will trigger the process then will be notified with the result so here HSM is more secure and powerful if compared with SHE modules

Key Distribution and provisioning : delivering the Keys

SHE : One of the biggest challenge in Cyber Security and automotive domain specially is the ways to inject the Keys into the ECUs so As we are in a layered architect and everything is managed and standardized by AUTOSAR here AUTOSAR provide to us a standard for the Key Update Protocol this is the standard way to update Keys through the OEMs tools or by PKI servers

The update process need to use 4 OEM shared keys (K1 , K2 , K3 , K4 ) these are embedded in the SHE by the Owner along with an authorized key like MASTER_ECU_KEY

The M1-M5 protocol acts as a standardized, cryptographically secure "handshake"

This allow the OEM to use the vendor’s root of trust to securely inject its own keys without the vendor needing to know the OEM’s secrets and without share the OEM;s secrets in a plain text

Let’s discuss the process in more details

1- M1 Key ( key update request )

Here we need to trigger that we need to initiate the update key request to the ECU we only send the first message in a plain text but the content is only (UID|IDKey1|IDMASTER_ECU_KEY)

2 - M2

here we send the actual key but here we encrypt this message using pre shared K1 this message also include encrypt_K1(CID |FID|Padding|NEW_KEY)

CID : class ID

FID : Function

NEW_KEY : that we need to update with

3 - M3 (MAC for integrity check )

ensure the integrity and authenticity of the request so we send CMAC using K2 over the present message M2 CMAC_K3(M2). Now ECU have the Key and the CMAC to ensure the integrity and authenticity of that key

4 - ECU verification and confirmation stage

M4 & M5 messages used to complete the handshake verification processes so if M3 match the CMAC calculated by the ECU over the M2 then The ECU will update the New Key and will send M4 with Key3 and generate the Mac over the M4 using Key4 and send the M5

HSM Methods: HSMs, with their greater computational power and flexible firmware, support more advanced and varied provisioning methods.

HSM work with Asymmetric algorithm where it generate the Keys internally then export the public key to a provisioning server the server then will sign this public key with the manufacture CA so this step will create a unique certificate for the ECU as discussed before for Asymmetric encryption we have a different process to share the keys that symmetric encryption used by SHE where we need to share the same key with each other.

Cyber Attacks Types

Page updated

Google Sites

Report abuse