## Sequence Diagram: Cryptographic Protocol between ProverTEE and VerifyTEE
### Overview
This image is a Unified Modeling Language (UML) style sequence diagram illustrating a secure communication and verification protocol between two Trusted Execution Environments (TEEs): **ProverTEE** (left) and **VerifyTEE** (right). The protocol involves cryptographic initialization, key derivation, data hashing, encryption, and a two-stage verification process to ensure data integrity and synchronization.
### Components/Axes
* **Entities:**
* **ProverTEE:** The entity initiating the data transmission.
* **VerifyTEE:** The entity receiving and validating the data.
* **Lifelines:** Vertical lines representing the passage of time for each entity.
* **Operations:** Rectangular boxes on the lifelines indicate local processing steps.
* **Messages:** Horizontal arrows indicate data transfer between the entities.
* **Solid Arrow:** Represents the transmission of the encrypted message `m`.
* **Dashed Arrow:** Represents the transmission of the encrypted response `Enc^Key_2 (BatchNo_v)`.
---
### Detailed Analysis
#### 1. Initialization Phase (Both Entities)
Both entities perform identical setup operations independently:
* **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`
#### 2. ProverTEE Processing & Transmission
* **Hashing:** ProverTEE updates the hash with two identifiers:
* `hash_p = SHA_Update(ID_1)`
* `hash_p = SHA_Update(ID_2)`
* **Encryption:** ProverTEE encrypts the identifiers and the hash using `Key_1`:
* `m = Enc^Key_1 (ID_1, ID_2, hash_p)`
* **State Update:**
* `Key_2 = KDF(Key_1)`
* `BatchNo_p++`
* **Transmission:** ProverTEE sends message `m` to VerifyTEE.
#### 3. VerifyTEE Processing & Verification
* **Decryption:** VerifyTEE receives `m` and decrypts it:
* `ID_1, ID_2, hash_p = Dec^Key_1 (m)`
* **State Update:**
* `Key_2 = KDF(Key_1)`
* `BatchNo_v++`
* **Hashing:** VerifyTEE updates its local hash using the decrypted identifiers:
* `hash_v = SHA_Update(ID_1)`
* `hash_v = SHA_Update(ID_2)`
* **Integrity Check:** VerifyTEE performs a comparison:
* `hash_p == hash_v?` (Checks if the hash received matches the hash calculated locally).
#### 4. Final Synchronization
* **Response:** VerifyTEE sends `Enc^Key_2 (BatchNo_v)` back to ProverTEE.
* **Final Verification:** ProverTEE performs the final check:
* `BatchNo_p == BatchNo_v?` (Ensures the batch numbers are synchronized).
---
### Key Observations
* **Symmetric Initialization:** Both TEEs start with the same secret and key derivation function (`KDF`), ensuring they are in a synchronized state before data exchange.
* **Key Evolution:** Both entities derive `Key_2` from `Key_1` locally, ensuring that the second message (the response) is encrypted with a different key than the first message.
* **Integrity vs. Synchronization:** The protocol separates concerns. The first verification (`hash_p == hash_v`) ensures the **data content** (ID1, ID2) was not tampered with. The second verification (`BatchNo_p == BatchNo_v`) ensures **session freshness** and synchronization.
### Interpretation
This diagram depicts a secure, stateful protocol designed to prevent replay attacks and ensure data integrity between two secure enclaves.
* **Peircean Investigative View:** The protocol relies on the assumption that both TEEs are trusted and possess the same initial `secret`. The flow is designed to be "self-healing" or "self-verifying." If the `hash` check fails, the protocol implies a data integrity breach. If the `BatchNo` check fails, it implies a desynchronization or a potential replay attack.
* **Reading Between the Lines:** The use of `SHA_Update` suggests that the data being verified is cumulative or part of a stream. By sending the hash of the IDs rather than just the IDs themselves, the Prover provides a compact proof of the data's integrity. The use of `Enc^Key_2` for the response indicates a two-way secure channel where the session keys evolve over time, a common practice to limit the impact of a compromised key.
