Secure Boot

From DDCIDeos
Jump to navigationJump to search

Context

Product Features

Secure boot cost is managed and customization is supported via a Modular Boot architecture enabling the use of individually verified boot artifacts combined by a qualified boot packager. This ensures binary reusability of architecture specific, but board agnostic boot code elements and their associated verification artifacts, all while providing a single boot image to the board firmware's secure boot to load. Customer's can customize the boot activity via customer supplied boot modules, or as a customer supplied Deos application.

  1. DAL A verification artifacts.
  2. Supports secure boot.
  3. Can securely load "images" from:
    1. Linear mapped persistent RAM, e.g., FLASH.
    2. Any device with a Deos device driver, including SATA, ...
    3. Any Deos application supported protocol: TFTP, FTP, 615...
  4. Supports Image loading policies for "fallback" and alternate configurations
    1. Fallback means what to do when an image is unavailable/corrupted.
    2. Alternate configuration means, for example, changing personality of a board; i.e., which software it is running.
    3. Simple Fallback policies can be directly encoded via configuration files.
    4. Alternate configurations can be selected by user supplied code, either via Deos application or by bare metal code, e.g., reading discretes.
  5. Images can have arbitrary content; file system images, OS boot images, raw data, etc.
  6. Performance characteristics? Small, fast, etc.
  7. Standard company goo: trusted supplier, artifact defense, support, etc.
  8. List of supported signing algorithms, presumably utilizing standard tools and libraries.

Hmm list.

  1. Encryption? Lots if issues if we say "yes" to this.
  2. . Can boot OSes other than Deos? Even more questions if yes.

Keys

It is not clear which algorithms, key types, etc., must be supported. The PKI assumes the existence of a digital certificate (ref X.509) which defines a private key (used alogn with the document's secure hash to sign a document) and public keys (used to verify the signature of a received document). The digital signature verifies authenticity, integrity, and non-repudiation.

Key Generation

  1. Customer will probably want to control key generation
    1. Not only type of key, but also policy about granularity etc.
  2. Digital Signature Algorithm is obsolete
  3. EcDSA replaced DSA
  4. EdDSA is proposed as a replacement for EcDSA.

Key Storage

TODO:

Initially (probably) TPM only

Software loading

Field load (customer loading new images on target):

  1. Verify authenticity and integrity before commit to NVM
  2. Verify authenticity and integrity of secure boot/kernel/app image load
  3. Not sure what protocols; intent is that security modules are communications protocol agnostic.

Fault Response

Event Logging

  1. Customizable.
  2. Default set of procedures/capabilities TBD

TODO:

  1. Zeroizing
  2. Repudiation

Development

Standards compiance

  1. How DDCI develops, verifies, and delivers SW
  2. Post How DDCI delivers SW to our customers
  1. See [#Key Generation]]
  2. Signing

Software distribution

How does DDCI distribute software (DDS) to customers?

  1. Currently (2025-05):
    1. Distribution images are not signed
    2. Signature of images not verified between build and packaging
    3. Target resident files are CRC protected in release-notes but not signed and no automated means to verify CRC is provided.
      1. Packaging specific capabilities exist to verify DESK contents, e.g., dpkg --verify

Maintenance (post sales) support

  1. Incident Response and & Vulnerability Management
  2. CVE monitoring
  3. Vulnerability information must be handled securely.

Higher Level Issues

Development

Build vs buy vs open source?

  • What is evaluation criteria?
    • Genealogy of code base.
      • Are all authors known?
    • Response (quality and time) to CVE level issues
    • Is the code maintainable?
    • Is there widespread usage?

Potential Candidates

Throne Specific

Throne Program provided a spreadsheet of issues to resolve. Here is a summary of issues that DDCI intends to resolve.

  1. Will interoperate with customer PKI
    1. See #Key Generation
  2. IP/TCP/UDP ports and protocols are minimal by default.
    1. Probably should consider turning off NAK for attempts to access non-active ports
    2. Probably should have firewall to do UDP source filtering and default drop all non-approved UDP/TCP ports
    3. Need to investigate SYN cache and SYN cookies
  3. Need(?) to add ICMP type filtering, probably discard echo, destination unreachable, router, and timestamp types
    1. Ref wikipedia ICMP types
  4. NOTE: Throne HW (I210/Pro1000) has limited filtering capabilities
  5. Should use SSH/SFTP rather than telnet/FTP
  6. Should use TLS/HTTPS rather than HTTP

Secure Boot

Nowadays, it is common for embedded systems attackers to aim for the software that will be executed in the system to introduce erroneous behavior (e.g., take control of the execution and manipulate data at their will). Secure boot is a defensive strategy to prevent attackers from gaining control of the software that will be executed. To achieve this goal, embedded systems use a chain of trust. That is, the first software that runs is considered secure (the root of trust), and the following stages will be validated by the prior stage. In a very high level, the execution flow is described by overview of secureboot.

Generic Secure Boot Flow.
Generic Secure Boot Flow.

Hardware State Machine

The hardware component that executes at power-on. It is responsible for establishing a root of trust (RoT) and, at a MINIMUM, authenticating the first-stage boot loader prior to releasing execution of the boot processor. Current references indicate this stage is validated using a Trusted Platform Module (TPM) and/or the One-Time-Programmable memory to access the public key.

Secure Boot

Secure Boot encompasses all boot stages preceding Deos Boot. These stages are responsible for:

  • Extension of Trust to all future stages of execution
  • Performing Secure BIT (SBIT)
  • Establishing Key Ring Infrastructure

Deos Boot

Represents the platform independent(ish) aspects of Boot

Deos

At this point Deos has started executing in a secure environment.

Meeting notes

Nov 4

  • Agenda
    • Testing ptp driver
    • RSA on TPM: 4096 support seems limited
    • AES -> makes most practical sense to have in cryptolib, but separation required for export purposes
    • Software review checklist: what should we add?

Oct 28

  • Agenda
    • Testing ptp driver

Oct 21

  • Status
    • Export restrictions
    • Safe and secure - Confidentiality, Integrity, Availability - buffer, integer over/under flow, memory (use after free...), race conditions (TOCTOTOU), - asr, gcc options etc.
    • NIST SSDF -> SBOM
    • CRA EU

Oct 2

  • Status
    • TLS and next steps

Sept 30

  • Status
    • Honeywell request - possible slip to Jan 2026
    • MbedTLS

Sept 25

  • Status
    • BIF loader -> library loader policy engine part of Secure Loader app
    • Adding ECC + ECDSA + ECDH to Deos Crypto library progress
    • AES + GCM from MbedTLS? Seems OK. commit pristine copies to scm. Confirm reqs. wrt. nationality of authors, chat Gary.
    • Consider PSA-like API

Sept 23

  • Status
    • Honeywell meeting, strategy SFTP vs FTPS implementation implications for DDCI
    • TLS, general status update

Sept 18

  • Status
    • Added ECDH + ECDSA + ECC key generation functions using TPM.
    • tls discussion. lines of code estimation for aes (1000) + gcm (1000) + tls1.3 (10000).

Sept 16

  • Status
    • tooling, secure loader unrelease
    • package names: prepend "deos-xxx" - Action (KG + CC)
    • tls? ECDH + AES should be seperable from crypto lib, but can start adding it now. To be removed if verf effort is to big.

Sept 11

  • Status
    • Tooling update
    • bifdump
    • naming convention for hw layer - tcti-tis -> ptp-fifo?
    • loadhyp.cpp: checkBootImageIntegrity()

Sept 9

  • Status
    • Tooling update: Sign interface + configuration, signbif->signarchive, mkarchive cli options added
    • bifdump: Reconstitute RSA pub+exponent from signature block into SSL PEM public key. Adding new python pip libraries to desk? package file from deos2cygwin
    • naming convention for hw layer - tcti-tis -> ptp-fifo?
    • loadhyp.cpp: checkBootImageIntegrity() - not discussed, time

Sept 4

  • Status
    • Secure loader + BIF Sign tool PoC working
    • TIS driver timing (max 180s)
    • BIFH_integrityKeyType_t update (PCR on kernel/kernel)
    • TODO lists + next steps?
    • Image loader -> vfile

Sept 2

  • Status
    • Components created
    • Started work on secure loader - config tool (qualified) for trusted public key hashes and loaded image location

Aug 28

  • Status
    • Integration test works
    • Documentation -> no need for numbers to be consecutive
    • Debugging through vfile
    • Dependencies

Aug 26

  • Status
    • Crypto experiment - split into components, moved to mainline, PCRs created, documentation, API, hmac
    • Verification App -> how to structure in source tree? How will this DeosBoot be built.

Aug 21

  • Status
    • CryptoLib architecture/CAPI RSA api
    • Components created/architecture -> still need some info on best architecture to use for layer below vfile
    • Action KG: setup meeting/training with Chris

Aug 19

  • Status
    • CryptoLib architecture/CAPI RSA api
    • Move from experimental/ components layout
    • Locality -> needs to be enforced in kernel mode - Do we need to implement different locality levels?

Aug 14

  • Status
    • VFS driver/configuration
    • CryptoLib architecture/CAPI

Aug 12

  • Status
    • CryptoLib - working on COMe 1 with TPM. COMe 2, NAIint86?
    • Headers installed as per example from AL.
    • Crypto bit banging to get TPM key import test case working without OpenSSL
    • CryptoLib architecture
    • Action KG: Chris Pow wrt. VFS driver/configuration
    • Action KG: modular boot team discussion

Aug 7

  • Status
    • TPM Driver and integration - headers? crypto /aes/sha/tpm/util.h xxx.h -> /desk/include/util.h
    • Farm access/bottleneck - monitor - check with Richard if a problem
    • Waiting for the TPM/real time use? Chat with Chris Pow/driver support lib
    • Action item response from Adina: Info on image loader in Deos app
    • Action AL: check on image loader with Adina
    • Action AL: Aaron link to example nested header use

Aug 5

  • Status
    • IFWI with Boot Guard built
    • TPM Driver
    • Runtime Verification new design - slide 6 (agreement)
    • BIF header - should we support multiple signatures (i.e. from different signers)?
    • Presigned, verified secure BL as IFWI?
    • Action (KG): check if image loader is re-usable from Deos app

Jul 31

  • Status
    • FIT, IFWI tools yay! Correct version of tiger lake H/U (U version) Can we ship this with OA - No. End customer should get it. Should we consider providing a presigned, verified secure BL as IFWI (no, maybe more discussion)
    • mkarchive, bifdump, bifh.py - CRC -> SHA256_RSA2048 How to parameterize keys, signing - config.py files (invoke external process with hash as parameter + expected algo [RSA2048, HASH, PSS] and expect signature back + public key)
    • Runtime Verification (link to crypto lib) [some discussion needed on implementation] Require sig param and only accept RSA+ signatures (deny CRC)
    • BIF header - support for multiple signatures (from different signers)?
    • TPM Driver - memory mapped TIS interface on COMe board

Jul 29

  • Status
    • PCH TPM Driver - for TPM its memory mapped
    • makeboot -> Signing interface example (KG)
    • bifh.py - CRC -> SHA256
    • Drivers in modular boot - no - IFWI[Boot Guard Signature][init module, ..., Boot Deos(kernel + drivers)] {flight Deos KFS - verified by Boot Deos}

Jul 22

  • Status
    • TPM on production HW
    • SPI Driver - slimboot contains code to access SPI over PCH
    • Boot Guard + Modular Boot Loader + Slimboot bits -> location and xFS's
    • Boot Guard boot process + keys
    • makeboot ext -> sign + package IFWI?
  • TPM Key Usage
  • Verify size of FLASH and TPM MFG (KG)

Jul 10

  • Feedback
    • -> Create high level TPM key usage doc/diagram (KG)
  • SPI Driver -> (Carlos)
    • Its now on Kelly's radar
    • Driver team has no bw - secure boot team to create SPI driver/lib (but not VFS initially)
  • Planning
    • Kelly has a fixed amount of hours allocated for secure boot. We just need to reach stable by 2nd Feb. within the amount of hours allocated. Submit time under "research" until we start officially working on it.
  • Intel application pending approval
    • -> Modular Boot (KG) - Verification Module research

Jul 8

  • Import key api
  • TCTI as a shared lib/component? Yes
  • SPI Driver
    • Talk to Kelly
    • Talk with Driver team
  • Target Data loader
    • how does that work? Security implications -> risk modelling
    • DDCI provides 615 TDL (over Ether and 45)
  • Unintentional modification BL mem
    • (Boot address space both boot and kernel r/w. PIG/Boot IG should address this - need to revisit . Boot has traps for fatal errors. Tooling should prevent r/w of BL mem)
  • Review Checklist
    -> https://deos.ddci.com/scm/Deos/docs/howto/review-process-user-howto/ReviewProcessGame.htm

Tasks

Committed Stable date is Feb-2026

Tasks to reach minimum customer requirement in dependency order

ID Task Who Estimate Status Comments
1 [ CryptoLib ] Develop a crypto library KG 0 In progress
2 [Sign Tool] Script tool to drive openssl in order to sign binaries and output in required format KG 0 Done
3 [DeosBoot ] Update KFS/DeosImage header to support signatures 0 Done
4 [Packaging Tool] Use output from Sign Tool to package signature for binary (kfs-cvt) 0 Not needed
5 [Verification Module] Verify binary using CryptoLib KG 0 Done
6 [Deos Configuration] DeosBoot to add Verification Module 0 Not needed - in verification app
7 [Deos Configuration] Add trusted public key info using configuration file 0 pending
8 [DeosBoot ] Verify bif using secure loader 0 Done
9 [DeosBoot ] Add verification profiling information 0 pending
10 [Sign Tool] Integrate with customer KMS - extension point provived KG 0 Done
11 [1st Stage BL ] CryptoLib linking -> .elf ? 0 pending
12 [1st Stage BL ] Configuration and storage HAL 0 pending
13 [1st Stage BL ] DeosBoot image verification 0 pending
14 [1st Stage BL ] A/B selection and boot code 0 pending
15 [1st Stage BL ] Bootloader binary packing creation (embed PuKs etc) 0 pending
16 [0 Stage BL] Decide on applicable 0 stage bootloader to use for target platform 0 pending
17 [0 Stage BL] Configure CPU/SoC for secure boot 0 stage bootloader. 0 pending
18 [1st Stage BL ] Sign 1st stage for 0 stage BL 0 pending
19 [BL Tool] Prepare target keys as needed by task 27 0 pending
20 [Documentation] Documentation and examples 0 pending
Total @sum(column)

Tasks to have generic portable cryptolib

ID Task Who Estimate Status Comments
1 [Signed Executables] Embed signatures into .elf 0 pending
2 [Signed Executables / kvs-cvt] Verify .elf sig before packaging into image 0 pending
3 [Packaging Tool] Verify DDCi generated binaries before packing into KFS 0 pending
4 [CryptoLib] implement MbedTLS/soft crypto based backend 0 pending
Total @sum(column)

Research tasks

ID Task Who Estimate Status Comments
1 Get Intel documentation 0 pending
2 Get ARM documentation 0 pending
3 Get NXP documentation 0 pending
4 Inspect/Build mbed TLS Crypto Library 0 pending https://github.com/Mbed-TLS/mbedtls
5 Inspect/Build slimboot Crypto Library 0 pending https://github.com/intel/cryptography-primitives/tree/develop/sources/ippcp
6 Figure out how TPM works 0 pending https://superuser.com/questions/1463364/accessing-trusted-platform-moduletpm-without-root-permission
https://github.com/tpm2-software/tpm2-tss/blob/master/doc/tcti.md?plain=1
https://wiki.archlinux.org/title/Trusted_Platform_Module
7 Identify post quantum requirements 0 pending
Total @sum(column)


ID Task Who Estimate Status Comments
1 SHA256 Research 80 pending
2 SHA256 Implementation 40 pending
3 SHA512 Research 60 pending
4 SHA512 Implementation 40 pending
5 SHAxxx Benchmark 40 pending #Benchmark
6 ECC Research 120 pending
7 ECC Implementation 240 pending
8 Build Library 40 pending
9 Library UG 80 pending
10 TPM Research 80 pending https://github.com/TrustedComputingGroup/TPM
https://superuser.com/questions/1463364/accessing-trusted-platform-moduletpm-without-root-permission
https://github.com/tpm2-software/tpm2-tss/blob/master/doc/tcti.md?plain=1
https://wiki.archlinux.org/title/Trusted_Platform_Module
11 TPM Driver 100 pending https://github.com/intel/cryptography-primitives/tree/develop/sources/ippcp
12 TPM Driver UG 80 pending https://github.com/intel/cryptography-primitives/tree/develop/sources/ippcp
13 Security tooling 80 pending
14 Inspect/Build mbed TLS Crypto Library 0 pending https://github.com/Mbed-TLS/mbedtls
15 Inspect/Build slimboot Crypto Library 0 pending https://github.com/intel/cryptography-primitives/tree/develop/sources/ippcp
16 Identify post quantum requirements 0 pending
17 Get ALL tech doc 0 pending
Total @sum(column)


Secure Boot Plan
Secure Boot Plan

Random Notes

This is an ARM reference, but reading seems to indicate the approach is similar for Intel in a high level.

Notes derived from Secure Boot

Cryptographic signature protocol: Use RSA-PSS. 

Private key (PrK):
 - Confidential.
 - Owned by the provider.
 - Will be part of the binary. Not clear on how.

Public key (PuK):
 - Stored somewhere that cannot be easily replaced.
 - Used to validate the signed binary.

Chain of trust: 

- Starts with a trusted component.
- Every other component will be authenticated before running.
- The Public key can change.
  * Start using the OEM PuK.
  * Use the software provider PuK once the software has been validated.
- Root of trust must be in the on-SoC ROM. OTP memory.

*** Storing the PuK in the on-SoC ROM is problematic, because all devices (all instances of the SoC) would use
    the same PuK --> susceptible to class-break attacks: If the PrK is discovered, all devices are compromised.

- There is one-time-programmable memory that can be used to store unique values in each SoC during manufacturing.
*** A RSA Puk is over 1024-bits long. This might be too large to fit in the OTP storage. One option is to store the PuK
    off-SoC and use the OTP to keep a SHA256 or so. Later, validate the off-SoC key with the on-SoC SHA256.

- Simplest defense against a shack is to keep all the secure software in on-SoC memory.
- Copy code to on-SoC memory before authenticating anything.

This is a video that presents the state of the art (by the time it was published) on secure Boot implementation.

Notes for Intel

Similar approach to ARM. 

- Authorized signature DB (DB): Database with all the allowed keys.
- Forbidden signature DB (DBX): Database with the blocked keys.

- Platform Key (PK): enrolled by the platform owner.
- Key exchange Key (KEK): Defines who is authorized to update the DB and DBX.

UEFI provides a secure boot: UEFI Secure Boot. See MOK Secure Boot. Adds a shim loader to chainload the second-stage loader. Useful to load Deos Boot?

Intel Boot Guard establishes the Root of Trust. Per a discussion DDC-I had with Intel contacts, Intel Boot Guard also validates the firmware that initializes RAM and configures the processor.

Slimbootloader implements secure boot. This might be acceptable for a Reference BSP.

Retrieved from "https://ddci.zapto.org/ddciWiki/index.php?title=Secure_Boot&oldid=75246"