Attacker Classes

Out-of-Scope Threats

The following attacks are explicitly outside the scope of this protocol:

• Supply-chain attacks that compromise the binding device before manufacture is complete. Trust framework governance (out-of-scope) addresses device supply chain.
• Attacks exploiting vulnerabilities in the DID method itself (e.g., key recovery from an insecure key management system). DID security is specified per method.
• Social engineering attacks on the Enrollment Authority.
• Quantum-computer attacks on the asymmetric cryptographic primitives used in BAL-2 through BAL-4. Post-quantum profile extensions are reserved for a future revision.

BAL-1: Passive Identifier with Tamper-Evident Carrier

Security objective. Demonstrate that a visual or machine-readable identifier has not been physically altered or transferred from the object it was applied to.

Mechanism. A machine-readable representation of the object's DID (QR code, Data Matrix, NFC NDEF record, or equivalent) is applied to a tamper-evident carrier. The carrier MUST exhibit an irreversible, visible change upon removal or attempted transfer. Suitable carrier classes include void-pattern adhesives, destructible polyester labels, and security holographic laminates. The carrier engineering MUST be documented at enrollment.

Assurance boundaries. BAL-1 does not provide cryptographic challenge-response. A BAL-1 binding is defeated by A1 attackers who succeed in carrier replication or who access the object before any carrier damage is detected. BAL-1 is appropriate for consumer-facing authentication where visual inspection at point-of-verification is feasible, and for batch-level supply chain tracking where individual object verification is not required.

No device certificate required. BAL-1 bindings do not require a device certificate or a binding device in the sense of this specification. The DID document need not contain a UORABindingVerification method.

BAL-2: Secure Element with Asymmetric Challenge-Response

Security objective. Cryptographically prove possession of a device-bound private key that cannot be extracted by A0 or A1 attackers, and resist A2 attackers via tamper detection and key zeroization.

Mechanism. The binding device contains a hardware secure element (compliant with Common Criteria EAL 4+ or equivalent) with an asymmetric keypair generated on-device. The private key MUST NOT leave the secure element boundary at any time. The public key is registered in the DID document as a verification method with type UORABindingVerification and relationship assertionMethod.

Key generation requirement. The keypair MUST be generated on-device after personalization, not pre-generated and loaded. Vendors claiming BAL-2 compliance SHALL provide attestation of on-device generation, auditable by the Enrollment Authority.

Replay protection. Replay protection is the responsibility of the verifier, not the binding device. This design accommodates constrained devices (NFC tags, RFID tokens) that cannot maintain reliable persistent state. The verifier enforces replay protection by: (a) generating a cryptographically random nonce (≥ 256 bits) per challenge; (b) enforcing a response timestamp skew tolerance; and (c) maintaining a short-lived nonce cache for the duration of the skew window. The binding device SHALL NOT be required to maintain nonce history. This is consistent with the FIDO2 authenticator model [[FIDO-CTAP2]].

Tamper response. The secure element MUST implement a hardware tamper detection mechanism (active shield, mesh, or equivalent). On tamper detection, the device SHOULD zeroize the private key. Key zeroization SHALL be documented in the device's security policy.

Minimum algorithm requirements. Implementations SHALL support at least one of the cryptographic profiles in Section 6.

Conformance. Passing the UORA BAL-2 Conformance Test Suite (CTS-BAL2) is REQUIRED. The CTS is available at w3id.org/uora/conformance/binding/v1.

BAL-3: PUF-Derived Key with Fuzzy Extraction

Security objective. Prove possession of a key that is physically unclonable and never persisted, eliminating the vendor key-retention threat present in BAL-2.

Mechanism. The binding device derives its private key from a Physically Unclonable Function using a fuzzy extractor [[Dodis2008]]. At enrollment, the PUF is queried with a defined challenge set, and the fuzzy extractor produces: (a) a stable derived key (the binding private key) and (b) public helper data required for re-derivation. The helper data is stored in the DID document or in a publicly accessible endpoint. The private key is never stored in non-volatile memory; it exists only transiently during device power-on and is recomputed on each challenge-response cycle.

Unclonability guarantee. The security of a PUF-based binding under the [[Armknecht2011]] framework requires that the PUF satisfy: (1) uniqueness — the inter-device Hamming distance between responses to the same challenge is approximately 50%; (2) reliability — the intra-device Hamming distance across conditions is below the fuzzy extractor's error-correction bound; and (3) unpredictability — an adversary observing polynomially many challenge-response pairs gains negligible advantage in predicting responses to unseen challenges. Implementations SHALL publish these statistics via the PUF Interface Descriptor (PID) as defined in Appendix A.

PUF Interface Descriptor (PID). BAL-3 and BAL-4 devices MUST include a PID in the DID document's binding verification method. The PID is a machine-readable JSON object that fully describes the PUF construction, the fuzzy extractor algorithm and parameters, the challenge construction mechanism, the helper data location and content hash, and the measured inter- and intra-device statistics. The PID schema is defined in Appendix A. A verifier SHALL use the PID to construct a challenge and to interpret the helper data. Conformance test C-07a requires that a clean-room verifier can construct a valid challenge from the PID alone, without vendor-proprietary knowledge.

Vendor cannot retain key. Because the private key is derived at power-on from silicon manufacturing variations, no manufacturing process can produce the key without the physical device. This property distinguishes BAL-3 from BAL-2 in the supply chain trust model.

Conformance. Passing CTS-BAL3 plus a valid and complete PID are REQUIRED.

BAL-4: Continuous Attestation with Environmental Monitoring

Security objective. Continuously prove that the bound physical object has not been tampered with, relocated without authorization, or subjected to conditions outside its permitted environmental envelope, even in the absence of an active verifier.

Mechanism. All BAL-3 requirements apply, including the PID. In addition, the binding device: (a) continuously monitors the object's physical state via onboard sensors (motion, temperature, tamper switches, or other sensors specified at enrollment); (b) generates signed attestations autonomously when monitored parameters cross defined thresholds or on a configured periodic interval; (c) maintains a trusted time source with documented drift bounds; and (d) SHALL implement the Proximity-Bound Authenticated Channel (PBAC) extension defined in Appendix C as its mandatory proximity verification mechanism. The response-time bounding of Section 4.3.6 serves as a fallback when PBAC is not available.

Maximum attestation interval. The maximum permitted interval between autonomous attestations MUST be declared at enrollment and recorded in the BEA. Verifiers SHALL treat a gap exceeding the declared interval (plus the documented clock drift) as a verification_inconclusive result requiring investigation.

Conformance. Passing CTS-BAL3 plus CTS-BAL4 (continuous attestation test vectors) are REQUIRED.

BAL Summary

Transport Model

The binding protocol is transport-agnostic. The ChallengeRequest and ChallengeResponse messages MAY be carried over any transport, including NFC (ISO/IEC 14443, ISO/IEC 15693), Bluetooth LE, USB, HTTP/S, or proprietary RF protocols. Implementations SHOULD use transport-layer security where available as defense-in-depth. Implementations MUST NOT assume transport-layer integrity or authenticity. All security properties derive from the application-layer message signatures.

Proximity enforcement. Some transports provide inherent proximity enforcement (NFC, RFID). For transports without inherent proximity enforcement, verifiers SHOULD apply maximum round-trip time thresholds calibrated to the expected transport medium (see Section 4.3.6). This does not eliminate relay attacks but raises the practical cost; see Section 8.2. BAL-4 devices and any deployment requiring strong relay-attack resistance SHALL implement the PBAC extension defined in Appendix C.

Enrollment

Challenge-Response Verification

Binding Revocation

Rebinding

Rebinding replaces one binding device with another while maintaining the object's DID and attestation chain continuity.

• The previous binding MUST be revoked (Section 4.4) before or simultaneously with new enrollment (Section 4.2). Simultaneous revocation and enrollment SHALL be implemented as an atomic DID document update where supported by the DID method.
• The rebinding event MUST be recorded as a UORA attestation referencing both the revocation attestation of the old binding and the BEA of the new binding.
• The object's DID SHALL NOT change during rebinding. The DID provides the stable identifier for the object's attestation history.
• The new binding MAY be at a different BAL. An upgrade in BAL SHOULD use reason code binding_upgraded. A downgrade in BAL MUST be explicitly authorized by the Trust Framework and logged.

Verification Result States

Trust Boundaries and Mitigations

Trust Framework Interface

This specification defines the cryptographic binding protocol. It does not define the governance framework that determines which EAs are trusted, which BALs are required for specific use cases, or how disputes are resolved. These questions are addressed by the applicable Trust Framework, which MUST:

• Define the CertificationCredential issuance and revocation process for EAs.
• Specify minimum BAL requirements for each protected use case.
• Define the binding revalidation procedure following EA compromise.
• Specify audit logging requirements and retention periods.
• Define dispute resolution procedures for contested verification outcomes.

Baseline Profile. Appendix B defines TFP-1, the minimal Trust Framework Profile. TFP-1 provides a fully specified, normative governance model suitable for closed supply chains and single-provider deployments. Conformant implementations that do not operate under a community-specific Trust Framework SHALL support TFP-1 as the default interoperability profile.

Profile A — Ed25519

Profile B — ECDSA P-256

Profile C — AES-128-CMAC (Constrained Symmetric) — DEPRECATED

Cloning Attacks

A cloning attack involves replicating the binding identifier on a counterfeit object such that the counterfeit passes verification.

• BAL-1. Susceptible to carrier replication if an A1 attacker can produce an identical carrier. Tamper-evident carrier engineering raises the practical cost but does not provide cryptographic guarantees.
• BAL-2. Resists cloning by A1 and A2 attackers where the secure element's tamper detection and key isolation are intact. An A2 attacker performing side-channel analysis on the secure element is mitigated by: Common Criteria-certified secure elements, key zeroization on tamper, and the ephemeral nature of cryptographic operations inside the SE boundary. A3 attackers (access to fab equipment) are not in scope for BAL-2.
• BAL-3/4. Resists cloning by A3 attackers because the PUF response is physically bound to manufacturing variations that cannot be reproduced even with semiconductor fabrication access. An A4 attacker who obtains one enrolled device and its helper data cannot derive the PUF response on a different device, because helper data reveals no information about the PUF's internal response beyond what a fuzzy extractor bound guarantees (see [[Dodis2008]], Theorem 3).

Relay Attacks

A relay attack intercepts a legitimate challenge and relays it to the genuine device from a remote location. The protocol provides tiered mitigations:

• Response time bounding (Section 4.3.6) raises the cost of relay attacks but does not cryptographically prevent them, consistent with the analysis in [[Hancke2005]]. An A5 attacker with a dedicated high-speed RF relay system can defeat time bounding alone.
• Proximity-Bound Authenticated Channel (PBAC) (Appendix C) provides cryptographic relay protection by binding the challenge-response to a distance-limited transport. Under PBAC, a relay attacker who intercepts the PBAC-blinded nonce and relays it to a distant device cannot produce a valid response because: (a) the distant device's response is encrypted under the Channel Key, which the local verifier does not possess; and (b) the Proximity Verifier Service will reject any attestation request where the latency exceeds the physical propagation limit of the transport.

Verifiers requiring strong relay prevention SHALL use PBAC or supplement with UWB distance bounding.

Replay Attacks

Replay attacks are mitigated by nonce freshness and timestamp skew enforcement. The verifier's short-lived nonce cache (maintained for the skew window) ensures that a captured challenge-response pair cannot be replayed within the skew window. After the skew window expires, the nonce is no longer valid and the response cannot be replayed, because a fresh nonce is required for each new challenge.

BAL Downgrade Attacks

A BAL downgrade attack presents a lower-assurance binding for an object that also has a higher-assurance binding. The BAL selection rules in Section 4.3.5 prevent this by requiring the verifier to select the highest available BAL that meets or exceeds minBal. Any permitted downgrade event MUST be logged and justified.

Enrollment Authority Compromise

Compromise of an EA's CertificationCredential key allows an attacker to issue fraudulent BEAs for non-genuine devices. Trust frameworks MUST implement EA revocation and binding revalidation per Section 4.2.3. The use of independent EAs (multiple CertificationCredential holders) limits the blast radius of a single EA compromise. Verifiers SHOULD validate that the EA's CertificationCredential is non-revoked as part of every binding verification.

PUF Modeling Attacks

PUF modeling attacks use machine learning classifiers trained on challenge-response pairs to predict unseen responses [[Ruhrmair2013]]. Arbiter PUFs with large challenge spaces are particularly vulnerable. Mitigations: (a) use of XOR-Arbiter PUFs or Ring Oscillator PUFs with controlled challenge sets; (b) challenge set restriction (the verifier's challenge set MUST be kept confidential and rotated); (c) fuzzy extractors that operate on a fixed enrollment challenge, limiting the exposed challenge-response space; (d) preferring SRAM PUFs for BAL-3 implementations where manufacturing access risks are high; and (e) PUF Interface Descriptors (Appendix A) that allow verifiers to evaluate the PUF's published susceptibility profile before issuing challenges. Vendors SHALL document their PUF construction's susceptibility to modeling attacks and the implemented mitigations in the PID.

Key Compromise

Evidence of binding private key compromise SHOULD trigger immediate revocation (reason code key_compromise) and rebinding. For BAL-3/4, key compromise in the cryptographic sense (not a physical break) is infeasible without device access, due to the non-persistence of the derived key. For BAL-2, compromise of the SE vendor's manufacturing process could theoretically enable key extraction; independent EA verification and BAL-3 preference for high-value bindings mitigate this.

Denial-of-Service on Binding Devices

Repeated challenge requests can exhaust processing capacity or battery reserves of constrained devices. Rate limiting per Section 4.3.7 is the primary mitigation. Trust frameworks SHOULD also define verifier authentication requirements so that only authorized verifiers can submit challenges to binding devices in high-value deployments.

PBAC Channel Key Compromise

A compromise of the Proximity Verifier Service (PVS) or its Channel Key shadow store would allow an attacker to forge PBAC attestations, defeating the relay-attack protection at BAL-4. Mitigations:

• The PVS SHALL store Channel Key shadows in a FIPS 140-2 Level 3 or higher Hardware Security Module.
• The PVS attestation signing key SHALL be distinct from the Channel Key store and rotated per the Trust Framework schedule (default: 90 days).
• Verifiers MAY query multiple independent PVS instances operated by different service providers. If responses from the PVS instances are inconsistent, the verifier SHALL return verification_inconclusive.
• Binding devices SHALL support on-device Channel Key rotation. The new Channel Key hash SHALL be published in an updated DID document, and the old Channel Key SHALL be purged from the PVS.