> For the complete documentation index, see [llms.txt](https://docs.optivalux.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.optivalux.com/trust/physical-authentication.md). # Physical Authentication Physical authentication connects a product's digital identity to the object in someone's hands. Optivalux uses a **registered authenticator** in each product and treats every check as **evidence of recent access to that authenticator**. Optivalux supports two families of authenticator. They have **different trust models**, and neither is universally superior. ## What every check establishes A successful check establishes that: * the product's **registered authenticator** produced **fresh**, **valid** cryptographic evidence; * the evidence is **bound to a specific purpose** (a verification, a claim, a transfer, a recovery) and cannot be reused for a different purpose, a different recipient or a later request; * the evidence **matches the registered identity** of that product. Evidence is short-lived and single-use. A replayed or stale response is rejected. ## Symmetric model Used by secure NFC tags that share a secret key with the verifier. * On each tap, the tag produces a **new, dynamic cryptographic message** that includes a counter which only increases. The phone opens it as a link; no app is needed, on common iOS and Android phones. * Checking the message requires the tag's **secret key**. Putting that key in a public record or in phone software would let anyone forge taps, so it is never done. * Instead, the **Optivalux verification service** checks the message. It holds the keys only in **secure hardware**, rejects messages whose counter is not newer than the last one it accepted for that tag, and then issues a short-lived, purpose-bound confirmation that the protocol accepts. * Freshness comes from the counter, not from a challenge chosen by the verifier. A message captured from a tap and never used can therefore, in principle, be accepted once, until the tag produces a newer message that the service sees. Messages already used, or older than the latest accepted one, are rejected. **Trust implication:** the verification service is a **trust anchor** for this model. Optivalux states that symmetric verification relies on it, and never describes this model as trustless. What a compromised verification service could and could not do: * It **could** falsely report that a tag was verified. * It **could not** transfer an owned product, because transfers also require the owner's authorization and the recipient's acceptance. * It **could not** claim a product on its own, because claims also require the brand's separate claim authorization. * It **could** delay, but not permanently block, an owner's Recovery Authenticator recovery or Protection Mode (at most once per product every 30 days). ## Asymmetric model Used by secure elements that generate their own key pair. * The **private key never leaves the chip**. * The chip **signs a fresh challenge** bound to the specific request and to a recent reference point, so a signature cannot be prepared in advance or reused. * The signature is checked **directly** against the chip's registered public key. **No verification service is needed for the possession check.** **Trust implication:** the possession check does not depend on an operated service. Other parts of the system (applications, claim authorization, product details) are still operated services. Practical considerations: asking a chip to sign arbitrary data usually requires vendor tooling, an app or specific device support, which must be validated per device. ## Side by side | | Symmetric | Asymmetric | | -------------------- | ---------------------------------------------- | ------------------------------------------- | | Evidence | Dynamic message per tap | Signature over a fresh challenge | | Key location | Tag and verification service's secure hardware | Chip only | | Who checks it | Optivalux verification service | Directly, against the registered public key | | Service trust anchor | **Yes** | **No** (for the possession check) | | Phone support | Browser, no app | Vendor tooling; may need an app | | Typical fit | Broad, cost-sensitive ranges | High-value categories | Both models plug into the same protocol, so products using either can coexist, and hardware can evolve without changing existing certificates. The **Recovery Authenticator** used in the pilot profile is always asymmetric, so that recovery does not depend on a verification service. ## QR codes are locators only A QR code or static link can be copied at no cost. It **locates** a product's record and can display its public status. It is **never** evidence of possession, and it can never produce "Authenticator verified" or satisfy a claim, transfer or recovery. ## What physical authentication cannot establish * **Tag transplant.** An authenticator proves its own authenticity and recent access, not the identity of the object it is attached to. A real authenticator moved onto another item would still answer correctly. Mitigation is physical: embedded placement and tamper-evident or destructive-on-removal inlays. * **Relay.** Evidence shows **recent access**, not that the authenticator is physically next to the phone. An accomplice holding a real product could forward its responses. Mitigation: monitoring of unusual verification patterns; and transfers still require the owner's authorization. * **Stolen products.** A thief holding the product can produce valid evidence. That is why evidence alone never changes ownership. These are disclosed in [Claims & Limitations](/trust/claims-and-limitations.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.optivalux.com/trust/physical-authentication.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.