## Sequence Diagram: Secure Build Process ### Overview The image is a sequence diagram illustrating a secure build process involving multiple entities: Artifact Author, Verifier, RHP (Remote Hypervisor Provider), Build Server, Enclave, Sandbox, and Log. The diagram depicts the flow of information and actions between these entities, highlighting the use of trusted and untrusted networks and execution states. ### Components/Axes * **Entities (Top)**: * A (Artifact Author) * B (Verifier) * C (RHP) * D (Build Server) * E (Enclave) * F (Sandbox) * G (Log) * **Vertical Lines**: Represent the lifeline of each entity, indicating the passage of time. * **Arrows**: Indicate the direction of information flow between entities. * **Labels on Arrows**: Describe the action or data being transmitted. * **Legend (Right)**: * Red dashed line: Adversary Network * Black solid line: Trusted Network * Red dotted line: Untrusted Execution State ### Detailed Analysis Here's a breakdown of the sequence of events: 1. **(1) CommitA(code)**: The Artifact Author (A) commits code to the Verifier (B) over a trusted network (solid black line). 2. **(2) InitImage(pcr0)**: The Build Server (D) initializes an image with PCR0 (Platform Configuration Register 0) from the Adversary Network (red dashed line) to the Enclave (E). 3. **(3) InitBuild(code)**: The RHP (C) initiates a build with the code to the Build Server (D) over the Adversary Network (red dashed line). The Build Server (D) then forwards the InitBuild(code) to the Sandbox (F) over the Adversary Network (red dashed line). The Sandbox (F) then forwards the InitBuild(code) to the Enclave (E) over the Adversary Network (red dashed line). 4. **(4) VerifyCommit(h(code))**: The Enclave (E) verifies the commit using a hash of the code. This communication is internal to the Enclave (green arrow with a loop back to itself). 5. **(5) SecureCommit(h(code))**: The Enclave (E) secures the commit using a hash of the code. This communication is over a trusted network (black dashed line) to the Sandbox (F). 6. **(6) Build(code)**: The Sandbox (F) builds the code. This communication is internal to the Sandbox (black arrow with a loop back to itself). 7. **(7) SendHash(h(artifact))**: The Sandbox (F) sends the hash of the artifact to the Enclave (E) over the Adversary Network (red dashed line). 8. **(8) Attestation(commit, h(artifact), pcr0)**: The Enclave (E) sends an attestation containing the commit, hash of the artifact, and PCR0 to the Build Server (D) over the Adversary Network (red dashed line). 9. **(9) LogEntry(h(<commit, h(artifact), at>))**: The Build Server (D) logs an entry containing the hash of the commit, hash of the artifact, and attestation to the Log (G) over the Adversary Network (red dashed line). 10. **(10) Get(artifact, at, ip)**: The Build Server (D) retrieves the artifact, attestation, and IP address from the Log (G) over a trusted network (black dashed line). 11. **(11) Verify(ip, pcr0)**: The Verifier (B) verifies the IP address and PCR0. This communication is over a trusted network (black dashed line) to the Artifact Author (A) and loops back to itself (green arrow with a loop back to itself). ### Key Observations * The Enclave (E) plays a crucial role in verifying the commit and securing the build process. * The Sandbox (F) is used for building the code. * The Adversary Network (red dashed line) is used for communication between several entities, including the Build Server, Enclave, and Sandbox. * The Log (G) stores information about the build process. * The Verifier (B) verifies the IP address and PCR0. ### Interpretation The sequence diagram illustrates a secure build process designed to protect against potential attacks. The use of an enclave and sandboxing helps to isolate the build process from untrusted environments. The attestation process provides evidence of the integrity of the build. The logging of build information allows for auditing and verification. The diagram highlights the importance of using trusted networks for sensitive communications and untrusted execution states for potentially vulnerable processes. The process ensures that the artifact is built in a secure environment and that its integrity can be verified.

\n ## Diagram: Secure Build Process Flow ### Overview This diagram illustrates a secure build process involving multiple parties: an Artifact Author, a Verifier, a Remote Hardware Provider (RHP), a Build Server, an Enclave, a Sandbox (Log), and an Adversary Network. The diagram depicts the flow of messages and data between these parties, highlighting trusted and untrusted network segments and execution states. The process appears to focus on verifying the integrity of code and artifacts during a build process. ### Components/Axes The diagram consists of seven vertical columns representing the different parties involved: * **A (Artifact Author)** * **B (Verifier)** * **C (RHP)** * **D (Build Server)** * **E (Enclave)** * **F (Sandbox (Log))** * **G (Adversary Network)** Horizontal lines with numbered labels represent the sequence of interactions. Three types of lines are used to indicate trust levels: * Solid lines: Trusted Network * Dashed lines: Adversary Network * Dot-dashed lines: Untrusted Execution State A legend on the right side defines these line types. ### Detailed Analysis or Content Details The diagram shows the following sequence of events: 1. **(1) Commit_A(code)**: Artifact Author (A) commits code. A solid arrow indicates this is over a trusted network. 2. **(2) InitImage(pcr0)**: Build Server (D) initializes an image using pcr0. A dashed arrow indicates this is over an adversary network. 3. **(3) InitBuild(code)**: RHP (C) and Build Server (D) initiate the build process with the code. Solid and dashed arrows respectively. 4. **(4) VerifyCommit(h(code))**: Enclave (E) verifies the commit hash of the code. A solid arrow. 5. **(5) SecureCommit(h(code))**: Enclave (E) securely commits the hash of the code. A solid arrow. 6. **(6) Build(code)**: Enclave (E) builds the code. A solid arrow. 7. **(7) SendHash(h(artifact))**: Enclave (E) sends the hash of the artifact. A solid arrow. 8. **(8) Attestation(commit, h(artifact), pcr0)**: RHP (C) provides attestation with the commit, artifact hash, and pcr0. A solid arrow. 9. **(9) LogEntry(h(<commit, h(artifact),at>>))**: Sandbox (F) logs an entry containing the hash of the commit, artifact hash, and attestation. A dot-dashed arrow. 10. **(10) Get(artifact,at,ip)**: Verifier (B) retrieves the artifact, attestation, and IP. A dot-dashed arrow. 11. **(11) Verify(ip,pcr0)**: Verifier (B) verifies the IP and pcr0. A solid arrow. The diagram also indicates the following execution states: * **Adversary Network**: Represented by dashed lines. * **Trusted Network**: Represented by solid lines. * **Untrusted Execution State**: Represented by dot-dashed lines. ### Key Observations The diagram highlights a process where code integrity is verified at multiple stages, particularly within the Enclave (E). The use of hashes (h()) and attestation suggests a strong emphasis on preventing tampering and ensuring the authenticity of the build process. The separation of networks and execution states emphasizes the security boundaries. The Verifier (B) is the final point of verification, confirming the integrity of the artifact. ### Interpretation This diagram demonstrates a secure remote build process designed to mitigate risks associated with untrusted build environments. The Enclave acts as a trusted execution environment, protecting the build process from malicious interference. The use of cryptographic hashes and attestation provides verifiable proof of the code's integrity. The separation of concerns between the different parties (Author, Verifier, RHP, Build Server, Enclave, Sandbox) enhances security by limiting the potential impact of a compromise in any single component. The process appears to be designed to ensure that the final artifact is built from trusted code and can be verified by an independent party. The inclusion of the Adversary Network indicates an awareness of potential threats and a proactive approach to security. The flow suggests a remote attestation scheme is in place, allowing the Verifier to trust the build process based on the Enclave's attestation. The logging component (Sandbox) provides an audit trail for security analysis. The diagram illustrates a sophisticated security architecture aimed at establishing a high level of confidence in the integrity of the build process.

## Sequence Diagram: Secure Build and Attestation Protocol ### Overview This image is a sequence diagram illustrating a multi-party protocol for securely building and attesting to software artifacts. It depicts the message flow between seven distinct entities, categorized into trusted, adversary, and untrusted execution states. The protocol involves committing code, initializing a secure build environment, performing the build, generating an attestation, logging the result, and finally verifying the artifact. ### Components/Axes **Participants (Vertical Lifelines, Left to Right):** * **A (Artifact Author):** The entity that initiates the process by committing code. * **B (Verifier):** The entity that ultimately verifies the final artifact and its attestation. * **C (RHP):** An intermediary component (likely a "Release Handling Platform" or similar). * **D (Build Server):** The server that orchestrates the build process. * **E (Enclave):** A secure, isolated execution environment (e.g., a TEE). * **F (Sandbox):** The environment where the actual build execution occurs. * **G (Log):** A logging service for recording the attestation. **Legend (Right Side):** * **Red Dashed Line (---):** Adversary Network * **Black Solid Line (—):** Trusted Network * **Red Dotted Line (······):** Untrusted Execution State * **Vertical Red Dotted Line:** Labeled "untrusted state," positioned between the Enclave (E) and Sandbox (F) lifelines, extending vertically through the diagram. ### Detailed Analysis The protocol proceeds through 11 numbered steps. The flow and message types are as follows: 1. **(1) `CommitA(code)`** * **From:** A (Artifact Author) * **To:** C (RHP) * **Line Style:** Black Solid (Trusted Network) * **Description:** The author commits source code to the RHP. 2. **(2) `InitImage(pcr0)`** * **From:** D (Build Server) * **To:** E (Enclave) * **Line Style:** Red Dashed (Adversary Network) * **Description:** The Build Server sends an initialization command to the Enclave, referencing a Platform Configuration Register (`pcr0`), which is a secure measurement of the enclave's initial state. 3. **(3) `InitBuild(code)`** * **From:** C (RHP) * **To:** D (Build Server) * **Line Style:** Red Dashed (Adversary Network) * **Description:** The RHP instructs the Build Server to start the build process with the committed code. 4. **(3) `InitBuild(code)`** (Repeated) * **From:** D (Build Server) * **To:** E (Enclave) * **Line Style:** Red Dashed (Adversary Network) * **Description:** The Build Server forwards the build initialization to the Enclave. 5. **(3) `InitBuild(code)`** (Repeated) * **From:** E (Enclave) * **To:** F (Sandbox) * **Line Style:** Red Dashed (Adversary Network) * **Description:** The Enclave forwards the build initialization to the Sandbox. This step crosses the vertical "untrusted state" boundary. 6. **(4) `VerifyCommit(h(code))`** * **From/To:** Self-loop on E (Enclave) * **Line Style:** Green Solid Arrow (Not in legend, but visually distinct) * **Description:** The Enclave performs an internal verification of the code's hash (`h(code)`). 7. **(5) `SecureCommit(h(code))`** * **From:** E (Enclave) * **To:** D (Build Server) * **Line Style:** Black Solid (Trusted Network) * **Description:** The Enclave securely sends the verified code hash back to the Build Server. 8. **(6) `Build(code)`** * **From/To:** Self-loop on F (Sandbox) * **Line Style:** Black Solid Arrow * **Description:** The Sandbox executes the build process on the code. 9. **(7) `SendHash(h(artifact))`** * **From:** F (Sandbox) * **To:** E (Enclave) * **Line Style:** Red Dashed (Adversary Network) * **Description:** The Sandbox sends the hash of the resulting build artifact (`h(artifact)`) back to the Enclave. This step crosses the "untrusted state" boundary. 10. **(8) `Attestation(commit, h(artifact), pcr0)`** * **From:** E (Enclave) * **To:** D (Build Server) * **Line Style:** Red Dashed (Adversary Network) * **Description:** The Enclave generates and sends a formal attestation. This attestation binds together: the original commit identifier, the hash of the final artifact, and the initial secure measurement (`pcr0`). The parameter `pcr0` is highlighted in red text. 11. **(9) `LogEntry(h(<commit, h(artifact), at>))`** * **From:** D (Build Server) * **To:** G (Log) * **Line Style:** Red Dashed (Adversary Network) * **Description:** The Build Server logs a hash of the attestation data (the commit, artifact hash, and attestation `at` itself) to the immutable Log service. 12. **(10) `Get(artifact, at, ip)`** * **From:** D (Build Server) * **To:** B (Verifier) * **Line Style:** Black Solid (Trusted Network) * **Description:** The Build Server delivers the final artifact, its attestation (`at`), and presumably an identity/proof (`ip`) to the Verifier. 13. **(11) `Verify(ip, pcr0)`** * **From/To:** Self-loop on B (Verifier) * **Line Style:** Green Solid Arrow * **Description:** The Verifier performs the final check, validating the provided proof (`ip`) against the initial enclave measurement (`pcr0`) that was included in the attestation. ### Key Observations 1. **Network Trust Boundaries:** The diagram meticulously distinguishes between trusted (solid black) and adversary-controlled (dashed red) network paths. Notably, the initial `InitImage` and all messages involving the Sandbox (F) traverse the adversary network. 2. **Untrusted Execution State:** A critical architectural boundary is marked by the vertical red dotted line. The Sandbox (F), where the build runs, is explicitly placed within an "untrusted state," while the Enclave (E) is outside it. This implies the build environment itself is not trusted, but its output is verified by the trusted enclave. 3. **Verification Points:** There are two key internal verification steps (green arrows): one by the Enclave (E) on the input code hash, and one by the Verifier (B) on the final attestation and proof. 4. **Attestation Composition:** The attestation (step 8) is the core trust artifact, cryptographically linking the initial state (`pcr0`), the input (commit), and the output (`h(artifact)`). 5. **Logging for Auditability:** The use of a Log service (G) creates an immutable record of the attestation, enabling independent audit and verification later. ### Interpretation This diagram details a **trusted execution environment (TEE) based secure build pipeline**. The core problem it solves is: "How can we trust the output of a build process (a software artifact) when the build server and environment might be compromised?" The protocol's logic is as follows: 1. **Isolate Trust:** The only components that must be inherently trusted are the **Enclave (E)** and the **Verifier (B)**. The Build Server (D), RHP (C), and especially the Sandbox (F) are treated as potentially adversarial. 2. **Establish a Root of Trust:** The process begins by measuring the Enclave's initial state (`pcr0`). This measurement becomes the root of trust for the entire chain. 3. **Verify Inputs:** Before building, the Enclave verifies the hash of the source code it receives (`h(code)`), ensuring no tampering occurred on the untrusted network path from the RHP. 4. **Execute in Distrust:** The actual build runs in an untrusted Sandbox. This is acceptable because the Enclave does not trust the Sandbox's execution; it only cares about verifiably measuring its output. 5. **Bind Input to Output:** The Enclave creates an attestation that cryptographically binds the initial trusted state (`pcr0`), the verified input (commit), and the hash of the output artifact (`h(artifact)`). This attestation is a signed statement from the trusted Enclave saying, "I started in a known-good state, I received this specific code, and the build process produced this specific artifact." 6. **Enable External Verification:** The final Verifier (B) can check the attestation. By verifying the signature and confirming that the `pcr0` in the attestation matches the expected value for a genuine Enclave, it can trust that the artifact (`h(artifact)`) is the legitimate result of building the claimed code (`commit`), even though the build itself happened on an untrusted machine. **Notable Anomaly/Design Choice:** The `InitImage(pcr0)` message (step 2) is sent over the adversary network. This suggests that while the *value* of `pcr0` is public or can be intercepted, its integrity is not compromised because `pcr0` is a measurement generated *within* the secure hardware of the Enclave itself. An adversary cannot forge a valid `pcr0` for a genuine Enclave running the correct code. The trust derives from the hardware's ability to generate and sign this measurement, not from the secrecy of its transmission.

## Flowchart: Artifact Verification and Build Process ### Overview This flowchart illustrates a multi-stage process for verifying and building software artifacts, emphasizing trust boundaries and execution states. The diagram uses color-coded edges to distinguish between trusted, untrusted, and secure network paths, with a focus on secure commit verification and sandboxed execution. ### Components/Axes **Nodes (Entities):** - **A (Artifact Author)**: Initiates the process by committing code. - **B (Verifier)**: Validates code integrity using PCR0 (Platform Configuration Register). - **C (RHP)**: Receives initial build instructions and code. - **D (Build Server)**: Executes code builds and attests to commit hashes. - **E (Enclave)**: Secure environment for commit verification and artifact retrieval. - **F (Sandbox)**: Untrusted execution environment for code. - **G (Log)**: Records system events and attestations. **Edges (Flow/Relationships):** - **Red Dashed Lines**: Untrusted network paths (e.g., adversary interactions). - **Green Lines**: Trusted network paths (secure communication). - **Black Lines**: Secure network paths (enclave-to-trusted network). - **Dotted Red Lines**: Untrusted execution state transitions. **Legend (Right Side):** - **Adversary Network**: Red dashed lines. - **Trusted Network**: Green lines. - **Secure Network**: Black lines. - **Untrusted Execution State**: Dotted red lines. ### Detailed Analysis 1. **Step 1**: Artifact Author (`A`) commits code (`Commit_A(code)`). 2. **Step 11**: Verifier (`B`) validates the commit using PCR0 (`Verify(ip,pcr0)`), creating a feedback loop to ensure integrity. 3. **Steps 2-3**: RHP (`C`) initializes build images (`InitImage(pcr0)`) and code (`InitBuild(code)`). 4. **Step 4**: Enclave (`E`) verifies commit hashes (`VerifyCommit(h(code))`) and secures them (`SecureCommit(h(code))`). 5. **Step 6**: Build Server (`D`) compiles code (`Build(code)`) and sends artifact hashes (`SendHash(h(artifact))`). 6. **Steps 8-9**: Build Server attests to commit hashes (`Attestation(commit, h(artifact), pcr0)`) and logs entries (`LogEntry(...)`). 7. **Step 10**: Enclave retrieves artifacts (`Get(artifact, at, ip)`). 8. **Flow to Sandbox/Log**: - Untrusted code flows to Sandbox (`F`) via dotted red lines. - Log entries (`G`) are secured via black lines to the Trusted Network. ### Key Observations - **Trust Boundaries**: - The Enclave (`E`) acts as a secure intermediary between untrusted and trusted networks. - Adversary Network (`F`) is isolated via red dashed lines, preventing direct access to secure components. - **Execution States**: - Code transitions to an "Untrusted Execution State" (dotted red) before sandbox execution. - SecureCommit (`E`) ensures hashes are cryptographically protected before network transmission. - **Feedback Loops**: - Verifier (`B`) continuously validates PCR0, creating a self-correcting integrity check. ### Interpretation This diagram models a **secure software supply chain** with layered trust assumptions: 1. **Author Trust**: Code is initially untrusted but validated by the Verifier (`B`) using hardware-backed PCR0. 2. **Build Integrity**: The Build Server (`D`) and Enclave (`E`) collaborate to ensure code authenticity via attestations and secure hashing. 3. **Execution Isolation**: Untrusted code is sandboxed (`F`), while logs (`G`) remain in the Trusted Network to prevent tampering. 4. **Adversary Mitigation**: Red dashed lines represent potential attack vectors, emphasizing the need for enclave-based verification to prevent compromise. The process highlights a **zero-trust architecture** where trust is earned through cryptographic proofs (e.g., PCR0, commit hashes) rather than implicit trust in network paths. The Enclave (`E`) serves as the critical trust anchor, ensuring secure execution and attestation even in untrusted environments.