## 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.