docs/2_Architecture_Guides/2.2_Security_Blueprint/1_Hardware/Abstract.md

   1 ---
   2 edit_link: ''
   3 title: Introduction
   4 origin_url: >-
   5   https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/security-blueprint/part-1/0_Abstract.md
   6 ---
   7
   8 <!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/architecture/master/security_blueprint-security-blueprint-book.yml -->
   9
  10 # Part 1 - Hardware
  11
  12 ## Abstract
  13
  14 The Automotive Grade Linux platform is a Linux distribution with **AGL** compliant applications and services.
  15 The platform includes the following hardware:
  16
  17 - SoC (System-on-Chip).
  18 - Memory (RAM, ROM, storage, etc.).
  19 - Peripherals.
  20
  21 You will find in this first part everything that concerns the hardware security.
  22 The goal is to protect system against all attacks that are trying to gain
  23 additional privileges by recovering and/or changing cryptographic keys in order
  24 to alter the integrity of the boot. We should also prevent hardware modifications
  25 in order to achieve this goal. We will expose below some examples of possible
  26 configurations.
  27
  28 --------------------------------------------------------------------------------
  29
  30 ## Acronyms and Abbreviations
  31
  32 The following table lists the terms utilized within this part of the document.
  33
  34 Acronyms or Abbreviations | Description
  35 ------------------------- | --------------------------------------
  36 _HSM_                     | **H**ardware **S**ecurity **M**odule
  37 _NVM_                     | **N**on-**V**olatile **M**emory
  38 _SHE_                     | **S**ecure **H**ardware **E**xtensions
  39
  40 --------------------------------------------------------------------------------
  41
  42 ## Integrity
  43
  44 The board must store hardcoded cryptographic keys in order to verify among others
  45 the _integrity_ of the _bootloader_. Manufacturers can use **HSM** and **SHE** to
  46 enhance the security of their board.
  47
  48 <!-- section-config -->
  49
  50 Domain               | Object     | Recommendations
  51 -------------------- | ---------- | ----------------------------------
  52 Hardware-Integrity-1 | Bootloader | Must control bootloader integrity.
  53 Hardware-Integrity-2 | Board      | Must use a HSM.
  54 Hardware-Integrity-3 | RTC        | Must not be alterable.
  55
  56 <!-- end-section-config -->
  57
  58 --------------------------------------------------------------------------------
  59
  60 <!-- pagebreak -->
  61
  62 ## Certificates
  63
  64 <!-- section-config -->
  65
  66 Domain                 | Object | Recommendations
  67 ---------------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------
  68 Hardware-Certificate-1 | System | Shall allow storing dedicated certificates.
  69 Hardware-Certificate-2 | ECU    | The ECU must verify the certification authority hierarchy.
  70 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.
  71
  72 <!-- end-section-config -->
  73
  74 --------------------------------------------------------------------------------
  75
  76 ## Memory
  77
  78 <!-- section-config -->
  79
  80 Domain            | Object     | Recommendations
  81 ----------------- | ---------- | ------------------------------------------------------------------------------------
  82 Hardware-Memory-1 | ECU        | The ECU shall never expose the unencrypted key in RAM when using cryptographic keys.
  83 Hardware-Memory-2 | Bootloader | Internal NVM only
  84 Hardware-Module-3 | -          | HSM must be used to secure keys.
  85
  86 <!-- end-section-config -->