summaryrefslogtreecommitdiffstats
path: root/security-blueprint/part-1/0_Abstract.md
blob: 188c9115acf233f807b6a607e622d59de02f41fe (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
# Part 1 - Hardware

## Abstract

You will find in this first part everything that concerns the hardware security.
The goal is to protect system against all attacks that are trying to gain
additional privileges by recovering and/or changing cryptographic keys in order
to alter the integrity of the boot. We should also prevent hardware modifications
in order to achieve this goal. We will expose below some examples of possible
configurations.

--------------------------------------------------------------------------------

## Acronyms and Abbreviations

The following table lists the terms utilized within this part of the document.

Acronyms or Abbreviations | Description
------------------------- | --------------------------------------
_HSM_                     | **H**ardware **S**ecurity **M**odule
_NVM_                     | **N**on-**V**olatile **M**emory
_SHE_                     | **S**ecure **H**ardware **E**xtensions

--------------------------------------------------------------------------------

## Integrity

The board must store hardcoded cryptographic keys in order to verify among others
the _integrity_ of the _bootloader_. Manufacturers can use **HSM** and **SHE** to
enhance the security of their board.

<!-- config -->

Domain               | Object     | Recommendations
-------------------- | ---------- | ----------------------------------
Hardware-Integrity-1 | Bootloader | Must control bootloader integrity.
Hardware-Integrity-2 | Board      | Must use a HSM.
Hardware-Integrity-3 | RTC        | Must not be alterable.

<!-- endconfig -->

--------------------------------------------------------------------------------

<!-- pagebreak -->

## Certificates

<!-- config -->

Domain                 | Object | Recommendations
---------------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------
Hardware-Certificate-1 | System | Shall allow storing dedicated certificates.
Hardware-Certificate-2 | ECU    | The ECU must verify the certification authority hierarchy.
Hardware-Certificate-3 | System | Allow the modification of certificates only if the source can be authenticated by a certificate already stored or in the higher levels of the chain of trust.

<!-- endconfig -->

--------------------------------------------------------------------------------

## Memory

<!-- config -->

Domain            | Object     | Recommendations
----------------- | ---------- | ------------------------------------------------------------------------------------
Hardware-Memory-1 | ECU        | The ECU shall never expose the unencrypted key in RAM when using cryptographic keys.
Hardware-Memory-2 | Bootloader | Internal NVM only
Hardware-Module-3 | -          | HSM must be used to secure keys.

<!-- endconfig -->