## System Diagram: Trusted Execution Environment (TEE) Build Process ### Overview The image is a system diagram illustrating a trusted build process within a Trusted Execution Environment (TEE), specifically using technologies like AWS Nitro Enclave. It outlines the steps involved in building and verifying an artifact using hardware-based attestation. ### Components/Axes The diagram includes the following components: 1. **Build Trigger:** Initiates the build process. 2. **Instance Manager:** Manages the host instance. 3. **Enclave Client:** A client within the TEE. 4. **Build Runner:** Executes the build process. 5. **Untrusted Build Process:** The actual build steps, isolated within a sandbox. 6. **Hardware Trust Anchor:** Provides hardware-based attestation (e.g., AWS Nitro Card). 7. **Log:** Stores the published attestation. 8. **RHP (Repository Hosting Provider):** Stores the source code (e.g., GitHub). 9. **Hypervisor:** Manages the virtual machine. 10. **TEE (Trusted Execution Environment):** (e.g., Nitro Enclave) 11. **Host Instance:** (e.g., AWS EC2) 12. **Sandbox:** (containerd/gVisor) The diagram also includes labels for data and control flow, such as "start," ".eif," "report commit hash CT," "report artifact hash A," "share AT," and "publish AT." ### Detailed Analysis or Content Details The process flow is as follows: 1. **Build Trigger (1):** The process starts with a build trigger. 2. **Instance Manager (2):** The instance manager starts the enclave client with a `.eif` file. 3. **Enclave Client (3):** The enclave client starts the build runner. 4. **RHP (4):** The build runner downloads the repository including build files from a repository hosting provider (e.g., GitHub). 5. **Build Runner (5):** The build runner reports the commit hash (CT) to the enclave client. 6. **Untrusted Build Process (6):** The untrusted build process reports the artifact hash (A) to the sandbox. 7. **Attestation (7):** Attestation over {PCR0-2, CT, A} resulting in document AT. 8. **Sharing Attestation (8):** The enclave client and sandbox share the attestation (AT). 9. **Publishing (9):** The artifact (A) and attestation (AT) are published to a log. 10. **Download and Claim (10):** A user downloads the artifact and claim: "A was built using PCR0-2 from CT". 11. **Request and Verify (11):** The user requests and verifies the proof for the claim, optionally checking for endorsements and revocations. ### Key Observations * The diagram highlights the isolation of the untrusted build process within a sandbox inside a TEE. * Hardware-based attestation is used to verify the integrity of the build process and the resulting artifact. * The process involves multiple components, including the instance manager, enclave client, build runner, and hardware trust anchor. ### Interpretation The diagram illustrates a secure build process that leverages a Trusted Execution Environment (TEE) and hardware-based attestation to ensure the integrity and trustworthiness of the built artifact. The TEE isolates the build process from the host environment, while attestation provides a verifiable record of the build process and the artifact's provenance. This approach is valuable for building and distributing software in environments where trust is critical, such as cloud computing and embedded systems. The process ensures that the artifact can be verified to have been built using a specific code commit and within a trusted environment, mitigating the risk of supply chain attacks and other security threats.

## Diagram: Secure Build Process Flow ### Overview This diagram illustrates a secure build process utilizing a Trusted Execution Environment (TEE) to ensure the integrity and provenance of software artifacts. The process begins with a build trigger and culminates in the verification of the built artifact. The diagram highlights the interaction between various components, including a Hardware Trust Anchor, Hypervisor, Instance Manager, Enclave Client, Build Runner, Sandbox, and external repositories. ### Components/Axes The diagram consists of several key components: * **Hardware Trust Anchor:** (e.g., AWS Nitro Card) - Provides a root of trust. * **Hypervisor:** Responsible for attestation. * **Host Instance:** (e.g., AWS EC2) - The underlying infrastructure. * **Instance Manager:** Manages instances within the host. * **Enclave Client:** Initiates and manages the secure build process within the TEE. * **Build Runner:** Executes the build process. * **Untrusted Build Process:** The actual build steps. * **Sandbox:** (containerd/gVisor) - Isolates the build process. * **RHP (Repository Host Provider):** (e.g., GitHub) - Source code repository. * **Log:** Stores build-related information. * **TEE (Trusted Execution Environment):** (e.g., Nitro Enclave) - Provides a secure environment for the build process. The diagram uses numbered arrows to indicate the flow of control and data. Key data elements include: * **CT:** Commit Hash * **A:** Artifact Hash * **AT:** Attestation Document ### Detailed Analysis / Content Details 1. **Build Trigger:** Initiates the build process. 2. **Instance Manager to Enclave Client:** The Instance Manager starts the Enclave Client, passing an `.eif` file. 3. **Enclave Client to Build Runner:** The Enclave Client starts the Build Runner. 4. **Build Runner to RHP:** The Build Runner downloads the repository, including build files, from the RHP (e.g., GitHub). 5. **Build Runner to Enclave Client:** The Build Runner reports the commit hash (CT) to the Enclave Client. 6. **Untrusted Build Process to Sandbox:** The untrusted build process executes within the Sandbox. 7. **Hypervisor Attestation:** The Hypervisor performs attestation over (PCR0-2, CT, A) resulting in the Attestation Document (AT). 8. **Sandbox to Enclave Client:** The Sandbox shares the Attestation Document (AT) with the Enclave Client. 9. **Publishing AT and Artifact:** The Attestation Document (AT) and the artifact (A) are published to a Log. 10. **Download and Claim Verification:** An external entity downloads the artifact and claims "A was built using PCR0-2 from CT". This is represented with a checkmark and an X, indicating successful and failed verification respectively. 11. **Request and Verify Proof:** A request is made to verify the proof of claim, optionally checking for endorsements and revocations. The arrows indicate the following flow: * A solid arrow indicates a direct flow of control or data. * A dashed arrow indicates an attestation or verification process. ### Key Observations * The process emphasizes attestation as a critical security measure. The Hypervisor attests to the integrity of the build environment. * The use of a TEE (Nitro Enclave) provides a secure environment for the build process, isolating it from the potentially compromised Host Instance. * The diagram highlights the importance of hashing (CT and A) for verifying the integrity of the source code and the resulting artifact. * The process includes a mechanism for publishing and verifying the Attestation Document (AT), providing transparency and accountability. * The diagram shows a clear separation between the trusted and untrusted components of the build process. ### Interpretation This diagram demonstrates a secure software build pipeline designed to mitigate supply chain attacks. By leveraging a Hardware Trust Anchor, TEE, and attestation mechanisms, the process aims to establish a strong chain of trust from the source code to the final artifact. The attestation process ensures that the build environment is in a known and trusted state, and the hashing of the source code and artifact provides a means to verify their integrity. The publishing of the Attestation Document allows external parties to independently verify the provenance of the artifact. The inclusion of PCR0-2 in the attestation process suggests that the integrity of the boot process and the initial system configuration are also considered part of the trust establishment. The optional check for endorsements and revocations indicates a potential mechanism for managing trust relationships and responding to security vulnerabilities. The diagram suggests a robust and comprehensive approach to secure software builds, addressing key concerns related to integrity, provenance, and transparency. The use of specific technologies like AWS Nitro Card and Nitro Enclave indicates a cloud-native security model.

## System Architecture Diagram: Secure Build Attestation Pipeline ### Overview This image is a technical system architecture diagram illustrating a secure, verifiable software build pipeline. The process uses a Trusted Execution Environment (TEE) and a hardware trust anchor to generate cryptographic attestations linking a built software artifact to its source code commit. The diagram details the flow of control, data, and cryptographic proofs between various components, from build initiation to final verification by an end-user. ### Components/Axes The diagram is organized into several key regions and components: **1. External Entities & Triggers (Outside the main dashed box):** * **Top-Left:** `build trigger` (icon of a person with a wrench). Arrow labeled **1** points to the Instance manager. * **Top-Right:** `Hardware Trust Anchor (e.g., AWS Nitro Card)` (green box). Receives attestation request (arrow **7**). * **Right Side:** `RHP (e.g., GitHub)` (cylinder icon). Source code repository. Arrow **4** shows download of repository. * **Bottom-Left:** `Log` (cylinder icon). Receives published attestation document `AT` (arrow **9**). * **Bottom-Right:** Artifact repository (cylinder icon). Receives published artifact `A` and attestation `AT` (arrow **9**). * **Bottom-Center:** End-user/verifier (icon of a person with checkmark/cross). Performs steps **10** and **11**. **2. Host Instance (Large dashed box labeled `Host instance (e.g., AWS EC2)`):** * **Left Component:** `Instance manager` (vertical rectangle). Orchestrates the build process. * **Central Component:** `TEE (e.g., Nitro Enclave)` (green shaded area). The secure environment where the build occurs. * **TEE Sub-component:** `Enclave client` (vertical rectangle). Manages the build runner. * **TEE Sub-component:** `Sandbox (containerd/gVisor)` (pink shaded area within the green TEE). Isolates the untrusted build process. * **Inside Sandbox:** `Build runner` (white box). Executes the trusted parts of the build. * **Inside Sandbox:** `Untrusted build process` (pink box containing three smaller white boxes connected by arrows). Performs the actual compilation/build steps. **3. Data Elements & Labels:** * **CT:** Commit Hash (reported by Build runner in step **5**). * **A:** Artifact Hash (reported by Untrusted build process in step **6**). * **AT:** Attestation Document (result of step **7**, shared in step **8**, published in step **9**). * **PCR0-2:** Platform Configuration Registers (part of the attestation in step **7**). * **.eif:** File format (likely Enclave Image Format) used to start the enclave (step **2**). ### Detailed Analysis The process flow is explicitly numbered from **1** to **11**: 1. **Build Trigger:** An external trigger initiates the process. 2. **Start Enclave:** The Instance manager starts the Enclave client within the TEE, providing a `.eif` file. 3. **Start Build Runner:** The Enclave client starts the Build runner inside the sandbox. 4. **Download Source:** The Build runner downloads the repository (including build files) from the RHP (e.g., GitHub). 5. **Report Commit Hash (CT):** The Build runner reports the commit hash `CT` back to the Enclave client. 6. **Report Artifact Hash (A):** The Untrusted build process, after completing its steps, reports the final artifact hash `A` to the Enclave client. 7. **Attestation:** The Enclave client requests an attestation from the Hardware Trust Anchor over the set `{PCR0-2, CT, A}`. This results in the creation of a signed attestation document `AT`. 8. **Share Attestation:** The attestation document `AT` is shared from the Enclave client back to the Instance manager and also to the Untrusted build process. 9. **Publish:** The Instance manager publishes `AT` to a Log. The Untrusted build process publishes the final artifact `A` along with its attestation `AT` to an artifact repository. 10. **Download & Claim:** An end-user downloads the artifact `A` and the associated claim: `"A was built using PCR0-2 from CT"`. 11. **Verify Proof:** The end-user requests and verifies the proof for the claim against the Log (and optionally checks for endorsements and revocations). ### Key Observations * **Trust Boundary:** A clear trust boundary is established by the green `TEE` box. The `Untrusted build process` is further isolated within a `Sandbox` inside the TEE. * **Critical Data Flow:** The Enclave client acts as a central hub, collecting `CT` and `A` before requesting the attestation `AT`. The attestation cryptographically binds the hardware state (`PCR0-2`), the source (`CT`), and the output (`A`). * **Dual Publishing:** The attestation `AT` is published to a separate, immutable Log (step **9**, left) for independent verification, while the artifact `A` and its attestation are published together for distribution (step **9**, right). * **Verification Loop:** The process concludes with an external verifier (steps **10 & 11**) who can independently check the claim by retrieving the proof from the Log, completing the chain of trust. ### Interpretation This diagram depicts a **verifiable build system** designed to provide strong cryptographic guarantees about software supply chain integrity. The core innovation is the use of a hardware-backed TEE to create an unforgeable link (`AT`) between the source code commit (`CT`) and the resulting binary (`A`). * **What it demonstrates:** It shows how to solve the "trusted build" problem. Even if the build environment is compromised, the attestation from the hardware trust anchor proves that the specific artifact `A` was generated from the specific source `CT` within a measured, known environment (`PCR0-2`). * **Relationships:** The flow is linear and causal. Each step depends on the successful completion of the previous one. The Instance manager orchestrates, the TEE executes securely, and the external repositories and logs provide persistence and verification points. * **Notable Design Choices:** The separation of the "Build runner" (trusted, reports `CT`) from the "Untrusted build process" (untrusted, reports `A`) within the sandbox is a key security pattern. It acknowledges that parts of the build toolchain may be untrustworthy but contains their impact. Publishing the attestation to a separate log enables transparency and third-party auditing. * **Implication:** This architecture is foundational for high-assurance software distribution, allowing users to verify that the software they are running matches the public source code and was built in a controlled manner, mitigating risks of supply chain attacks.

## Flowchart: Secure Build Process with Attestation ### Overview This flowchart illustrates a secure build process involving hardware-based attestation, enclave computing, and artifact verification. It outlines steps from code commit to final artifact validation, emphasizing trust anchors, secure execution environments, and cryptographic verification. ### Components/Axes 1. **Key Components**: - **Build Trigger**: Initiates the process (Step 1) - **Hypervisor**: Manages virtualization (Step 2) - **Hardware Trust Anchor**: Includes PCR0-2, CT, A (Step 7) - **Instance Manager**: Coordinates build instances (Step 2) - **Enclave Client**: Manages secure enclave operations (Step 3) - **Build Runner**: Executes build process (Step 4) - **Untrusted Build Process**: Non-secure build components (Step 6) - **Sandbox**: Isolated execution environment (Step 8) - **TEE (Trusted Execution Environment)**: e.g., Nitro Enclave (Step 8) - **Host Instance**: Physical/cloud infrastructure (Step 8) - **Log**: Central repository for attestation documents (Step 9) - **RHP (Repository Hosting Platform)**: e.g., GitHub (Step 4) - **User Interaction**: Final verification step (Step 11) 2. **Flow Direction**: - Left-to-right progression from code commit to artifact validation - Vertical connections between components (e.g., build runner → sandbox) - Feedback loops for attestation and verification ### Detailed Analysis 1. **Build Process Flow**: - **Step 1-3**: Code commit (CT) triggers build instance creation - **Step 4-5**: Build runner executes in sandbox, reporting commit hash - **Step 6-7**: Untrusted build process generates artifact hash (A) - **Step 8**: TEE sandbox executes in host instance (AWS EC2) - **Step 9**: Attestation document (AT) published to log - **Step 10-11**: Artifact and AT published to RHP - **Step 12**: User verifies claim: "A was built using PCR0-2 from CT" 2. **Security Mechanisms**: - Hardware Trust Anchor (green box) anchors PCR measurements - Enclave client (Step 3) manages secure enclave operations - Sandbox (Step 8) isolates untrusted build process - TEE (Step 8) provides memory encryption and integrity 3. **Artifact Verification**: - Commit hash (CT) and artifact hash (A) cryptographically linked - Attestation document (AT) combines PCR0-2, CT, and A - Final verification checks PCR0-2 against CT ### Key Observations 1. **Trust Chain**: - Hardware Trust Anchor (Step 7) provides root of trust - PCR0-2 measurements anchor build environment state - CT (commit hash) anchors source code integrity 2. **Isolation Layers**: - Sandbox (Step 8) isolates untrusted build process - TEE (Step 8) provides additional memory protection - Enclave client (Step 3) manages secure communication 3. **Verification Flow**: - Attestation document (Step 9) combines multiple trust elements - Final verification (Step 12) checks cryptographic proof - Optional endorsement/revocation checks (Step 11) ### Interpretation This diagram demonstrates a multi-layered security approach for build artifact verification: 1. **Hardware Root of Trust**: PCR0-2 measurements from the Hardware Trust Anchor (e.g., AWS Nitro Card) provide foundational trust. 2. **Secure Execution**: The build process occurs in isolated environments (sandbox/TEE) to prevent tampering. 3. **Cryptographic Verification**: The attestation document (AT) combines hardware measurements, commit hashes, and artifact hashes for end-to-end verification. 4. **User Validation**: Final step allows users to verify claims about build provenance, ensuring artifacts were built using specific hardware configurations. The process emphasizes defense-in-depth security, combining hardware isolation, cryptographic attestation, and secure execution environments to prevent supply chain attacks and ensure build integrity.