Attestation

Use attestation for the claim it can support

Hardware-backed key attestation can strengthen identity and key-protection claims. It does not establish that arbitrary storage, AI inference or bandwidth work ran inside a trusted execution environment. StrongBox primarily protects supported key operations; it is not a general-purpose place to execute a model and then declare its result unspoofable. EdgeORE should use attestation narrowly and explain its verifier dependencies.

Define the attested claim

A reasonable initial claim is that a signing key was created or protected under a particular device security level and policy, according to a validated attestation chain. The verifier must check trust roots, certificate chain, challenge freshness and relevant security properties. A copied certificate or old challenge should not qualify a new session. The exact platform behavior can differ across devices and provisioning generations.

A key signature over a result hash binds the key to that hash. It does not prove how the result was computed. The app could submit a fabricated hash if the key-use policy permits it. Even when extraction is difficult, use of the key by a compromised authorized process remains a separate concern. The product should never translate hardware-backed signature into independently verified work without an additional protocol.

Handle availability honestly

StrongBox support is optional and resource-constrained. Some devices use a trusted execution environment, some lack the requested algorithm or policy, and an emulator may not supply production-equivalent hardware backing. Show the observed security level and unsupported state. A fallback should be disclosed rather than labelled hardware-secured regardless of which provider actually performed the operation.

Do not make absence of StrongBox a hidden cause of generic connection failure. Wallet authentication is the wallet's own boundary, and a mock wallet's key-use issue needs typed diagnostics. Node identity and receipt provenance also need their own trust anchors. A single device badge should not stand in for every security relationship in the system.

Protect user privacy

Attestation data can contain stable or sensitive device context. Collect only what the verification protocol requires, explain retention and avoid exposing unnecessary identifiers in public receipts. A reputation system should not require publishing a device fingerprint everywhere unless that is an intentional and reviewed policy. Sybil resistance, privacy and recoverability often trade off, so document the chosen balance.

Run a bounded experiment

Generate a challenge, obtain an attestation for a test key, verify it under the intended rules and repeat with an expired or wrong challenge. Record the device, Android version and verifier configuration. Test unavailable hardware and a valid software fallback separately. The outcome can strengthen an identity signal, but compute acceptance still needs task-specific verification. The roadmap label remains attestation research until these observations and the protocol exist.

---

Wiki home · Qualification updates · Sources and credits