# Cryptographic Guarantees and Threat Model

### 1. What TaτsuOS Guarantees

**Authenticity of unlock.** A feature is enabled on a device only if a valid ECDSA signature over the canonical preimage is presented. The preimage binds `chainId` and `contractAddress`, so a receipt minted for one deployment cannot be reused on another.

**No replay.** The firmware maintains an append-only nonce log. A receipt with a previously consumed nonce is rejected.

**No silent revocation.** Once verified and persisted, an unlock cannot be remotely revoked by any party. The user has paid; the entitlement is theirs.

**Offline operability.** A receipt fetched once can be delivered to a device years later, in a context with no internet. Verification is fully local.

### 2. What TaτsuOS Does Not Guarantee

**Hardware security beyond firmware.** TaτsuOS is a software-layer system. Physical access to hardware introduces risks outside the scope of this architecture. We recommend enabling platform-level security features available on supported MCUs.

**Confidentiality of receipt contents.** Receipts are designed for integrity and authenticity, not secrecy. They are bound to a specific device, so possession alone does not grant access on any other device.

**Unconditional cloud availability.** New unlocks require the signing service to be reachable. This is acceptable given that unlock events are not time-critical, and the signing infrastructure is designed for high availability with redundancy.

### 3. Threat Model Summary

| Threat Category                         | System Response                                                                                                                       |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Unauthorized receipt issuance           | Receipts require a valid signature from the operator's private key. Without this key, no valid receipt can be produced.               |
| Receipt reuse across devices            | Every receipt is cryptographically bound to a specific device identifier. A receipt issued for one device is rejected by any other.   |
| Replay of a previously used receipt     | The firmware maintains a persistent nonce log. Any receipt presented a second time is rejected, regardless of its validity.           |
| Interception during delivery            | Receipts are integrity-protected by their signature. Interception during transit does not allow modification or forgery.              |
| Withholding of receipts by the operator | Users who require stronger independence guarantees may operate a compatible signing service against the same on-chain events.         |
| Physical device compromise              | TaτsuOS recommends enabling available platform security features. Physical attacks are considered out of scope for this threat model. |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://tatsu.gitbook.io/tatsu-whitepaper/cryptographic-guarantees-and-threat-model.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.