## Sequence Diagram: TEE-Based Batch Verification Protocol ### Overview This image is a technical sequence diagram illustrating a cryptographic protocol between two Trusted Execution Environment (TEE) entities: **ProverTEE** and **VerifyTEE**. The protocol involves initializing secrets, deriving keys, updating hashes with identifiers, encrypting a batch of data, and performing verification checks. The diagram uses standard UML sequence diagram notation with vertical lifelines and horizontal message arrows. ### Components/Axes * **Entities (Lifelines):** * **ProverTEE** (Left vertical line): The entity that proves or generates the batch data. * **VerifyTEE** (Right vertical line): The entity that verifies the batch data. * **Message Flow:** Time progresses vertically from top to bottom. Solid arrows represent synchronous calls or messages. The dashed arrow represents a return message or data transmission. * **Key Functions & Variables:** * `SHA_Init(secret)`, `SHA_Update(data)`: Functions for initializing and updating a SHA hash state. * `KDF(Key)`: Key Derivation Function. * `EncKey(data)`, `DecKey(data)`: Encryption and Decryption using a specific key. * `hash_p`, `hash_v`: Hash states for Prover and Verifier, respectively. * `Key_1`, `Key_2`: Derived cryptographic keys. * `BatchNo_p`, `BatchNo_v`: Batch number counters for Prover and Verifier. * `ID_1`, `ID_2`: Identifiers included in the batch. * `m`: The encrypted message containing the batch data. ### Detailed Analysis The protocol proceeds in the following sequence: **1. Initialization (Top Section - Parallel Setup):** * **ProverTEE:** * `hash_p = SHA_Init(secret)` * `Key_1 = KDF(Key_init)` * `BatchNo_p = 0` * **VerifyTEE:** * `hash_v = SHA_Init(secret)` * `Key_1 = KDF(Key_init)` * `BatchNo_v = 0` * *Observation:* Both parties initialize identical hash states and keys from a shared secret and key_init, establishing a common starting point. **2. ProverTEE Batch Processing (Left Lifeline, Middle Section):** * `hash_p = SHA_Update(ID_1)` * `hash_p = SHA_Update(ID_2)` * *Trend:* The prover's hash state is sequentially updated with two identifiers. * `m = EncKey_1(ID_1, ID_2, hash_p)` * The prover encrypts the two identifiers and its current hash state using `Key_1` to create message `m`. * `Key_2 = KDF(Key_1)` * A second key is derived from the first. * `BatchNo_p++` * The prover's batch number is incremented (from 0 to 1). **3. Message Transmission (Center):** * A solid arrow labeled `m` points from ProverTEE to VerifyTEE, indicating the encrypted batch data is sent. **4. VerifyTEE Processing & Verification (Right Lifeline, Lower Section):** * `ID_1, ID_2, hash_p = DecKey_1(m)` * The verifier decrypts message `m` using its `Key_1` to recover the identifiers and the prover's hash state. * `Key_2 = KDF(Key_1)` * The verifier independently derives `Key_2`. * `BatchNo_v++` * The verifier's batch number is incremented (from 0 to 1). * `hash_v = SHA_Update(ID_1)` * `hash_v = SHA_Update(ID_2)` * *Trend:* The verifier updates its own hash state with the same identifiers in the same order. * **First Verification Check (Dashed Arrow):** * A dashed arrow labeled `EncKey_2(BatchNo_v)` points from VerifyTEE back to ProverTEE. The verifier sends its encrypted batch number. * **Second Verification Check (Bottom):** * `hash_p == hash_v?` * The prover (or a final check) compares the hash state it computed (`hash_p`) with the hash state the verifier computed (`hash_v`) and sent back (implied by the protocol logic, though the direct transmission of `hash_v` is not shown as a separate arrow). * `BatchNo_p == BatchNo_v?` * A final check compares the batch numbers from both parties. ### Key Observations 1. **Symmetry and Replication:** The protocol is designed for the verifier to replicate the prover's state. Both perform identical `SHA_Init`, `KDF`, and `SHA_Update` operations on the same inputs (`secret`, `Key_init`, `ID_1`, `ID_2`). 2. **Two-Key Structure:** The use of `Key_1` for encrypting the batch data (`m`) and `Key_2` for encrypting the verification response (`BatchNo_v`) suggests a layered security approach or separation of concerns. 3. **Implicit Trust in Shared Secrets:** The protocol's security fundamentally relies on the ProverTEE and VerifyTEE starting with identical, secret values (`secret` and `Key_init`). 4. **Final Consistency Checks:** The protocol concludes with two equality checks (`hash_p == hash_v?` and `BatchNo_p == BatchNo_v?`). These are the core verification steps to ensure both parties have processed the same data in the same way. ### Interpretation This diagram depicts a **remote attestation or batch verification protocol** designed for a Trusted Execution Environment (TEE) context. Its purpose is to allow a Verifier (VerifyTEE) to cryptographically confirm that a Prover (ProverTEE) has correctly processed a specific batch of data (identified by `ID_1`, `ID_2`) without the verifier needing to see the raw data or the prover's internal secret. * **How it works:** The prover commits to the batch by hashing the IDs and encrypting that commitment. The verifier, using a shared secret, independently reconstructs the same commitment. The final hash comparison proves the verifier's view matches the prover's. The batch number check ensures synchronization and prevents replay attacks. * **Why it matters:** This enables trust in distributed systems where one TEE must vouch for the correct execution of a task performed by another TEE. It's a building block for secure multi-party computation, confidential computing, or auditable logging within a hardware-rooted trust boundary. * **Notable Anomaly/Design Choice:** The diagram shows `hash_p` being sent inside the encrypted message `m` and then used in a final comparison. This implies the verifier must send its computed `hash_v` back to the prover (or a third party) for the check `hash_p == hash_v?` to occur, which is not explicitly drawn as a separate message arrow. The dashed arrow for `EncKey_2(BatchNo_v)` is the only return message shown. This suggests the diagram may be a simplified view, or the final hash check is performed by a component that receives both values through other means.