Independent Pi/OpenRouter review: mistralai/devstral-2512

Source: a10323dede4413fbf295916b8ad12e3dbad7514e. Status: completed.

Independent Security Review: Attested Relay v2 (Commit a10323d)

Reviewer: Independent (no affiliation with project owner) Scope: Confidentiality of request/response contents from intermediaries until ~1-week delayed disclosure via RandomX puzzles. Assumptions: AWS/Nitro trusted; all others (EC2 owner, parent host, Cloudflare, network, DNS, archive providers, other clients, external solvers) may collude. RandomX primitive assumed strong (no cryptanalytic shortcut).

Executive Summary

Property A: Confidentiality of Request/Response Contents Before Delay

Assessment: SUPPORTED CONDITIONALLY

• Supported: The design and implementation generally prevent intermediaries from recovering request/response contents before the intended delay, assuming:
  • RandomX’s sequential work assumption holds (no shortcuts).
  • No side-channel exploitation (e.g., timing, memory leaks, or speculative execution) is feasible against the enclave.
  • The enclave’s TLS stack, RandomX FFI, and record encryption are correctly implemented and free of exploitable bugs.
  • The parent host cannot observe or tamper with the enclave’s internal state (e.g., via memory introspection or side channels).
• Conditional: The confidentiality guarantee is not absolute due to:
  1. Metadata leakage: Parent host and network observers can see:
     • IP addresses, timing, request/response sizes, and TLS handshake metadata (e.g., SNI if ECH fails).
     • The enclave’s attestation documents (which include policy parameters but not request contents).
     • Record names (content-addressed hashes) and puzzle/attestation artifacts.
  2. Side-channel risks: No formal analysis or mitigations are provided for:
     • Microarchitectural attacks (e.g., Spectre, Meltdown) against the enclave.
     • Memory introspection via AWS Nitro hypervisor (if AWS is compromised).
     • Timing attacks on RandomX or TLS operations.
  3. Implementation risks: Bugs in the enclave’s TLS stack, RandomX binding, or record encryption could leak plaintext or keys.
  4. Trust in AWS: If AWS is malicious, all bets are off (e.g., they could serve a compromised enclave image or intercept NSM calls).

Property B: No Early Key/Plaintext Recovery or Puzzle Bypass

Assessment: SUPPORTED CONDITIONALLY

• Supported: The design prevents:
  • Early recovery of epoch keys or plaintext without solving the RandomX puzzle.
  • Reuse of epoch keys across puzzles (each epoch has a fresh key).
  • Substitution of pre-solved puzzles (puzzle publication is content-addressed and signed).
  • Bypassing the delay via checkpoint tampering (checkpoints are validated against the manifest).
• Conditional: The following gaps could enable early recovery:
  1. Checkpoint Replay Attacks:
     • Checkpoints are saved to disk (in solve()) and could be replayed by an attacker if they gain access to the solver’s filesystem.
     • Mitigation: Checkpoints are validated against the manifest (line 438–455 in timelock/src/lib.rs), but an attacker who controls the solver’s environment could pre-compute checkpoints and inject them.
     • Risk: If an attacker can pre-solve the puzzle and inject a checkpoint, they could recover the epoch key early. However, this requires solving the RandomX puzzle, which is assumed hard.
     • Verdict: Not a bypass of RandomX, but a potential optimization if the attacker has faster hardware.
  2. Puzzle Publication Race Conditions:
     • The enclave publishes the puzzle before activating it (lines 76–102 in v2_epoch.rs).
     • If the parent host delays or withholds the OK acknowledgement for the puzzle publication, the enclave blocks new requests (line 83–84 in v2_proxy.rs).
     • However, if the parent acknowledges the puzzle but then deletes it, the enclave would still accept requests, but solvers would have no puzzle to solve.
     • Mitigation: The enclave anchors the epoch before first possible disclosure (line 79–81 in v2_epoch.rs), and the watchdog expires the epoch monotonically (lines 40–52 in v2_epoch.rs).
     • Risk: If the parent lies about persistence, the enclave could accept requests for an epoch whose puzzle is never publicly available. This would extend confidentiality indefinitely (not a violation, but a denial of the intended disclosure).
     • Verdict: Not a confidentiality violation, but a liveness/availability risk.
  3. Epoch Key Leakage via Side Channels:
     • The epoch key is used to derive record encryption keys (line 81–91 in timelock/src/lib.rs).
     • If an attacker can observe the enclave’s memory (e.g., via a side channel), they could recover the epoch key.
     • Mitigation: The enclave zeroizes keys (e.g., Zeroizing<[u8; 32]>), but this does not protect against hardware-level side channels.
     • Verdict: Not mitigated in the current design.
  4. RandomX Mode Mismatch:
     • The enclave uses RandomXMode::Full in production (line 120 in v2_epoch.rs), but the solver must use the same mode (line 462 in timelock/src/lib.rs).
     • If a solver uses Light mode for a Full puzzle, it will fail to recover the key.
     • Mitigation: The manifest includes the randomx_algorithm field (line 33 in timelock/src/lib.rs), and the solver validates it (line 218–220 in timelock/src/lib.rs).
     • Verdict: Correctly enforced.
  5. Puzzle Generation Parallelism:
     • The enclave generates 7 segments in parallel (lines 327–350 in timelock/src/lib.rs), but each segment’s work is sequential (lines 336–338).
     • An attacker cannot parallelize across segments to reduce the total work, because each segment’s output is wrapped and chained (lines 365–387 in timelock/src/lib.rs).
     • Verdict: Correctly enforced.

Detailed Findings

1. Confidentiality of Request/Response Contents (Property A)

Strengths

✅ End-to-End Encryption:

• Requests are encrypted inside the enclave using XChaCha20-Poly1305 with a per-record nonce (lines 102–124 in v2_proxy.rs).
• The epoch key is derived from the RandomX puzzle and is never exposed until the puzzle is solved.
• Records are content-addressed (SHA-256 hash of ciphertext) and signed by the enclave (via the manifest).

✅ TLS Isolation:

• The enclave terminates TLS (lines 180–196 in v2_main.rs), so the parent host only sees encrypted bytes.
• Upstream connections use TLS with certificate verification (lines 158–159 in net.rs), and the parent only sees IP addresses (not SNI, if ECH is used).

✅ No Plaintext Logging:

• The enclave never logs request/response contents (lines 26–27 in v2_diagnostics.rs).
• Diagnostics are bounded and static (lines 10–12 in v2_diagnostics.rs).

✅ Record Integrity:

• Records are AEAD-encrypted (XChaCha20-Poly1305) with authenticated context (lines 102–124 in v2_proxy.rs).
• The manifest is signed (Ed25519) and includes the epoch key commitment (SHA-256 hash of the epoch key).

Weaknesses & Risks

⚠️ Metadata Leakage:

• Parent host sees:
  • IP addresses and ports of upstream connections (via connect_ip in transport.rs).
  • TLS handshake metadata (e.g., SNI if ECH fails, cipher suites, ALPN).
  • Record names (content-addressed hashes) and puzzle/attestation artifacts.
• Network observers see:
  • Outer TLS metadata (e.g., SNI to the relay, IP addresses, timing).
  • Record names and puzzle/attestation artifacts (if fetched from the public archive).
• Mitigation: Use ECH (Encrypted Client Hello) to hide SNI (lines 77–92 in net.rs), but this is not always available (depends on upstream support).

⚠️ Side-Channel Risks:

• No mitigations for:
  • Timing attacks on RandomX or TLS operations.
  • Memory introspection (e.g., via AWS Nitro hypervisor if AWS is compromised).
  • Cache attacks (e.g., Spectre, Meltdown) against the enclave.
• Impact: An attacker with physical access or hypervisor control could potentially recover keys or plaintext.

⚠️ Record Provenance:

• Individual records are not signed by the enclave (only the manifest is signed).
• An attacker who recovers the epoch key can forge new records for that epoch.
• Mitigation: Clients must verify the record against the manifest and epoch key (lines 125–156 in timelock/src/lib.rs), but this does not prevent replay of legitimate records.
• Risk: If an attacker solves the puzzle early, they can decrypt all records for that epoch and forge new ones.

⚠️ Parent Host Can Delay/Withhold Records:

• The enclave waits for the parent to acknowledge record persistence (lines 107–108 in v2_proxy.rs).
• If the parent never acknowledges, the enclave blocks new requests (line 83–84 in v2_proxy.rs).
• Impact: The parent can deny service but cannot recover plaintext (since the record is encrypted).

⚠️ No Forward Secrecy for Records:

• All records for an epoch are encrypted with keys derived from the epoch key (lines 81–91 in timelock/src/lib.rs).
• If the epoch key is recovered, all records for that epoch are compromised.
• Mitigation: Epochs are short-lived (24 hours), limiting exposure.

2. No Early Key/Plaintext Recovery or Puzzle Bypass (Property B)

Strengths

✅ RandomX Puzzle Binding:

• The epoch key is derived from the RandomX puzzle (lines 315–350 in timelock/src/lib.rs).
• The puzzle is signed by the enclave (lines 388–393 in timelock/src/lib.rs), and the signature is verified by solvers (lines 216–225 in timelock/src/lib.rs).
• The manifest includes a commitment to the epoch key (SHA-256 hash), preventing substitution.

✅ Sequential Work Enforcement:

• Each segment’s output is wrapped and chained to the next (lines 365–387 in timelock/src/lib.rs).
• The final segment’s output is the epoch key, which is committed in the manifest.
• No parallelization across segments is possible (each segment depends on the previous one’s output).

✅ Checkpoint Validation:

• Checkpoints are validated against the manifest (lines 438–455 in timelock/src/lib.rs).
• Tampered checkpoints are rejected (lines 649–661 in timelock/src/main.rs).

✅ Epoch Key Isolation:

• The epoch key is never exposed until the puzzle is solved.
• The enclave zeroizes the epoch key after use (lines 131–132 in v2_epoch.rs).

✅ No Key Reuse:

• Each epoch has a fresh epoch key (lines 120–125 in v2_epoch.rs).
• The manifest includes the epoch number, preventing reuse of old keys.

Weaknesses & Risks

⚠️ Checkpoint Replay Attacks:

• Checkpoints are saved to disk (in solve()) and could be replayed by an attacker if they gain access to the solver’s filesystem.
• Mitigation: Checkpoints are validated against the manifest (lines 438–455 in timelock/src/lib.rs), but an attacker who pre-computes checkpoints could inject them.
• Risk: If an attacker can pre-solve the puzzle, they could recover the epoch key early. However, this requires solving the RandomX puzzle, which is assumed hard.

⚠️ Puzzle Publication Race Conditions:

• The enclave publishes the puzzle before activating it (lines 76–102 in v2_epoch.rs).
• If the parent host delays or withholds the OK acknowledgement, the enclave blocks new requests (line 83–84 in v2_proxy.rs).
• Mitigation: The enclave anchors the epoch before first possible disclosure (lines 79–81 in v2_epoch.rs).
• Risk: If the parent acknowledges the puzzle but then deletes it, the enclave would still accept requests, but solvers would have no puzzle to solve.
• Verdict: Not a confidentiality violation, but a liveness/availability risk.

⚠️ Epoch Key Leakage via Side Channels:

• The epoch key is used to derive record encryption keys (lines 81–91 in timelock/src/lib.rs).
• If an attacker can observe the enclave’s memory (e.g., via a side channel), they could recover the epoch key.
• Mitigation: The enclave zeroizes keys (e.g., Zeroizing<[u8; 32]>), but this does not protect against hardware-level side channels.
• Verdict: Not mitigated in the current design.

⚠️ RandomX Mode Mismatch:

• The enclave uses RandomXMode::Full in production (line 120 in v2_epoch.rs), but the solver must use the same mode (line 462 in timelock/src/lib.rs).
• If a solver uses Light mode for a Full puzzle, it will fail to recover the key.
• Mitigation: The manifest includes the randomx_algorithm field (line 33 in timelock/src/lib.rs), and the solver validates it (lines 218–220 in timelock/src/lib.rs).
• Verdict: Correctly enforced.

⚠️ Puzzle Generation Parallelism:

• The enclave generates 7 segments in parallel (lines 327–350 in timelock/src/lib.rs), but each segment’s work is sequential (lines 336–338).
• An attacker cannot parallelize across segments to reduce the total work, because each segment’s output is wrapped and chained (lines 365–387 in timelock/src/lib.rs).
• Verdict: Correctly enforced.

Critical Questions & Answers

A. Can an in-scope adversary recover or infer request/response contents before the intended delay?

Answer: SUPPORTED CONDITIONALLY

• No, if:
  • RandomX’s sequential work assumption holds (no cryptanalytic shortcuts).
  • No side-channel exploitation (e.g., timing, memory leaks) is feasible.
  • The enclave’s TLS stack, RandomX FFI, and record encryption are correctly implemented.
  • The parent host cannot observe or tamper with the enclave’s internal state.
• Yes, if:
  • The adversary solves the RandomX puzzle early (e.g., with faster hardware or a cryptanalytic breakthrough).
  • The adversary exploits a side channel (e.g., memory introspection, timing attacks).
  • The adversary compromises the enclave’s TLS stack or RandomX binding (e.g., via a bug in aws-lc-rs or randomx-sys).

B. Can an adversary obtain epoch keys, private seeds/intermediates, or equivalent decryption capability early?

Answer: SUPPORTED CONDITIONALLY

• No, if:
  • The RandomX puzzle is not solved early.
  • Checkpoints are not tampered with or replayed.
  • The epoch key is not leaked via side channels.
  • The manifest and puzzle are correctly signed and validated.
• Yes, if:
  • The adversary solves the puzzle early (e.g., with faster hardware).
  • The adversary injects a pre-computed checkpoint (requires solving the puzzle).
  • The adversary exploits a side channel to recover the epoch key.
  • The adversary compromises the enclave’s memory (e.g., via AWS Nitro hypervisor if AWS is malicious).

Unresolved Questions & Missing Evidence

1. Side-Channel Resistance:

   • Question: Has the enclave been audited for side-channel resistance (e.g., Spectre, Meltdown, cache attacks)?
   • Status: No evidence provided. The threat model explicitly does not assume resistance to side channels (line 20 in threatmodel.md).
   • Risk: An attacker with physical access or hypervisor control could potentially recover keys or plaintext.

2. RandomX FFI Safety:

   • Question: Is the RandomX FFI binding (in timelock/src/randomx.rs) memory-safe and free of buffer overflows?
   • Status: The FFI uses raw pointers (lines 15–37 in randomx.rs) and no bounds checking.
   • Risk: A bug in the FFI could corrupt memory or leak secrets.

3. TLS Stack Security:

   • Question: Is the TLS stack (aws-lc-rs, rustls) free of vulnerabilities?
   • Status: The enclave uses aws-lc-rs (AWS’s fork of ring) and rustls with AWS-LC-RS provider.
   • Risk: A vulnerability in aws-lc-rs or rustls could leak plaintext or keys.

4. Record Encryption Key Derivation:

   • Question: Is the record encryption key derivation (HKDF-SHA256) secure?
   • Status: The derivation uses HKDF with a fixed domain separator (lines 81–91 in timelock/src/lib.rs).
   • Risk: If the epoch key is recovered, all records for that epoch are compromised.

5. Parent Host Persistence Guarantees:

   • Question: Does the parent host durably store records before acknowledging?
   • Status: The host writes records to disk (lines 67–123 in crates/host/src/artifacts.rs) and syncs the directory (lines 61–65).
   • Risk: The parent could lie about persistence, but the enclave blocks new requests if persistence fails (line 83–84 in v2_proxy.rs).

6. Epoch Key Zeroization:

   • Question: Are epoch keys fully zeroized after use?
   • Status: The enclave uses Zeroizing<[u8; 32]> (lines 12–13 in v2_epoch.rs), but this does not guarantee hardware-level erasure.
   • Risk: Memory remnants could leak the epoch key.

7. RandomX Calibration:

   • Question: Is the RandomX calibration (43,768,124 iterations) sufficient to ensure ~1 week delay?
   • Status: The calibration assumes ~506.5755 hashes/s per CPU (line 3 in config/relay-v2.toml).
   • Risk: If faster hardware (e.g., GPUs, ASICs) is available, the delay could be shorter.

Recommendations

High Priority

1. Audit RandomX FFI for Memory Safety:

   • The FFI uses raw pointers and no bounds checking. A fuzzing campaign should be conducted to ensure no memory corruption is possible.
   • Action: Add bounds checks in the FFI or use a safer binding (e.g., librandomx via cdylib).

2. Hardware Side-Channel Mitigations:

   • Enable Nitro Enclave’s side-channel protections (e.g., CPU isolation, memory encryption).
   • Action: Configure the enclave with --cpu-unbound and --memory-mb to limit exposure.

3. Record Provenance Signatures:

   • Sign each record (not just the manifest) to prevent forgery by epoch key holders.
   • Action: Modify encrypt_record to include a per-record signature (e.g., using the enclave’s signing key).

4. Checkpoint Encryption:

   • Encrypt checkpoints to prevent replay attacks by attackers who gain access to the solver’s filesystem.
   • Action: Store checkpoints encrypted with a solver-specific key.

Medium Priority

5. TLS Stack Hardening:

   • Audit aws-lc-rs and rustls for vulnerabilities.
   • Action: Use rustls with ring (instead of aws-lc-rs) for broader scrutiny.

6. Epoch Key Forward Secrecy:

   • Derive record keys from a per-record nonce + epoch key (instead of just epoch key) to limit exposure if the epoch key is recovered.
   • Action: Modify record_key to include a per-record nonce.

7. Parent Host Persistence Verification:

   • Require multiple acknowledgements (e.g., from independent storage providers) before accepting a record as persisted.
   • Action: Modify publish to write to multiple hosts (lines 57–74 in v2_epoch.rs).

8. Side-Channel Testing:

   • Test the enclave for side-channel leaks (e.g., Flush+Reload, Prime+Probe).
   • Action: Run side-channel detection tools (e.g., ct-grind, cache-audit).

Low Priority

9. RandomX Calibration Revalidation:

   • Revalidate the RandomX calibration on newer hardware (e.g., Graviton4, AMD EPYC).
   • Action: Run benchmarking on modern CPUs and adjust iterations if needed.

10. Document Side-Channel Assumptions:

    • Explicitly document that the enclave does not protect against side channels.
    • Action: Update threatmodel.md to clarify side-channel risks.

Final Verdict

Would I rely on this for sensitive content?

Yes, but with caveats:

• For short-lived, non-catastrophic secrets (e.g., API keys, session tokens), the design provides strong confidentiality against network and parent host adversaries.
• For long-lived, high-value secrets (e.g., private keys, passwords), the side-channel risks and metadata leakage are significant concerns.
• The trust in AWS is absolute: If AWS is malicious, all protections fail.
• The RandomX assumption is critical: If a cryptanalytic breakthrough or faster hardware emerges, the delay could be shorter than intended.

Critical Missing Evidence

1. Side-channel resistance testing (e.g., Spectre, Meltdown, cache attacks).
2. RandomX FFI memory safety audit (fuzzing, static analysis).
3. TLS stack (aws-lc-rs, rustls) vulnerability assessment.
4. Independent verification of RandomX calibration (is 43M iterations really ~1 week on modern hardware?).

Strongest Code-Grounded Reasons Attacks Are Blocked

1. Epoch keys are derived from RandomX puzzles (lines 315–350 in timelock/src/lib.rs), which are assumed hard to solve early.
2. Records are AEAD-encrypted with per-record nonces (lines 102–124 in v2_proxy.rs), preventing replay or forgery without the epoch key.
3. Manifests are signed with Ed25519 (lines 388–393 in timelock/src/lib.rs), preventing tampering with puzzle parameters.
4. Checkpoints are validated against the manifest (lines 438–455 in timelock/src/lib.rs), preventing checkpoint replay attacks.
5. Epoch keys are zeroized after use (lines 131–132 in v2_epoch.rs), limiting memory exposure.

Most Concerning Gaps

1. No side-channel mitigations (e.g., for Spectre, Meltdown, or memory introspection).
2. RandomX FFI uses unsafe raw pointers (potential for memory corruption).
3. Checkpoints are not encrypted (replay attacks possible if solver filesystem is compromised).
4. Parent host can delay/withhold records (liveness risk, but not a confidentiality violation).
5. No forward secrecy for records (if epoch key is recovered, all records for that epoch are compromised).

Appendix: File/Line References for Key Findings

Conclusion

The attested relay v2 design and implementation largely achieve their stated goals of confidentiality until ~1-week delay, assuming:

• RandomX’s sequential work assumption holds.
• No side-channel exploitation is feasible.
• The enclave’s implementation (TLS, RandomX FFI, record encryption) is correct.

However, the following risks remain:

1. Side-channel attacks (not mitigated).
2. RandomX FFI memory safety (unaudited).
3. Checkpoint replay attacks (if solver filesystem is compromised).
4. Parent host persistence lies (liveness risk, not confidentiality).
5. No forward secrecy for records (epoch key compromise = all records compromised).

For sensitive content, I would rely on this system only if:

• The side-channel risks are acceptable (or mitigated via hardware protections).
• The RandomX calibration is revalidated on modern hardware.
• The RandomX FFI and TLS stack are audited for memory safety.

Final Answer:

• Property A (Confidentiality before delay): SUPPORTED CONDITIONALLY
• Property B (No early key/plaintext recovery): SUPPORTED CONDITIONALLY