diff options
author | 2020-10-09 00:19:18 +0530 | |
---|---|---|
committer | 2020-10-14 11:19:53 +0000 | |
commit | eefc3ab6cbb8a5901632f46d99e13c8d90b2415d (patch) | |
tree | 90815d532ed7b2d0962a1468aee29f05a4404eef /docs/1_Architecture_Guides/1.2_Security_Blueprint/1_Hardware/Abstract.md | |
parent | 4aad369c9728061c97b3de792286e743ee884b09 (diff) |
rewrote quickstart, build-process
Revamped and updated documentation to install and build AGL images.
(removed whitespaces, added contribution guide, corrected rcar-gen3 section 7, added aglsetup.h flags to hardware support, some minor changes)
Bug-AGL: [SPEC-3633]
Signed-off-by: Shankho Boron Ghosh <shankhoghosh123@gmail.com>
Change-Id: Iedb6c7dc1661f4bc58b5f25ea5d188778c7ff908
Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/25407
Reviewed-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Tested-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Diffstat (limited to 'docs/1_Architecture_Guides/1.2_Security_Blueprint/1_Hardware/Abstract.md')
-rw-r--r-- | docs/1_Architecture_Guides/1.2_Security_Blueprint/1_Hardware/Abstract.md | 86 |
1 files changed, 0 insertions, 86 deletions
diff --git a/docs/1_Architecture_Guides/1.2_Security_Blueprint/1_Hardware/Abstract.md b/docs/1_Architecture_Guides/1.2_Security_Blueprint/1_Hardware/Abstract.md deleted file mode 100644 index d9aeefb..0000000 --- a/docs/1_Architecture_Guides/1.2_Security_Blueprint/1_Hardware/Abstract.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -edit_link: '' -title: Introduction -origin_url: >- - https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/security-blueprint/part-1/0_Abstract.md ---- - -<!-- 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 --> - -# Part 1 - Hardware - -## Abstract - -The Automotive Grade Linux platform is a Linux distribution with **AGL** compliant applications and services. -The platform includes the following hardware: - -- SoC (System-on-Chip). -- Memory (RAM, ROM, storage, etc.). -- Peripherals. - -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. - -<!-- section-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. - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## Certificates - -<!-- section-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. - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## Memory - -<!-- section-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. - -<!-- end-section-config --> |