Informational-Only
Component Authentication

Hardware component authentication in repairable electronic devices, specifically a system in which a replaceable component (battery, display, camera, sensor, input device, power adapter, or similar) can prove its manufacturer and model to a host device, where the result of that proof is surfaced to the user as information and is never used as a permission. The disclosed method is deliberately distinct from component serialization and device-binding schemes, in which a component's authenticity is cryptographically tied to a specific host and a failed or absent match disables functionality.

A growing class of devices implements "parts pairing" (also called component serialization or device binding). At the factory, a component's identifier is registered against a specific host device. When the component is later replaced, even with a genuine component of the identical model, and even by an authorized technician, the host detects that the new component's identifier is not the one it was paired with and responds by:

• disabling the component's features,
• displaying persistent "unknown part" or "unable to verify" warnings,
• degrading capability (e.g. disabling automatic brightness or battery health reporting), or
• refusing the component entirely.

This practice is presented as anti-counterfeiting and safety enforcement, but its operative effect is to convert authentication into a lockout: the gating of function on the outcome of an authenticity check. It obstructs independent repair, raises repair cost, strands functional refurbished parts, and creates strategic dependence on the original manufacturer's parts supply and authorization servers.

Authenticity verification, anti-counterfeiting, and safety enforcement are all legitimate aims. The harm is not verification: it is the use of verification as a gate. This disclosure describes a method that fully achieves verification, anti-counterfeiting signaling, and safety constraint without gating function on the authentication result.

3.1 Design Principle

The host may learn, with cryptographic confidence, that a component is a genuine manufacturer X, model Y part. It may show that fact to the user, log it, and surface it in diagnostics. It may not make any functional decision contingent on it. A component that fails authentication, carries no authentication data, or comes from an unrecognized manufacturer operates with the same full capability as a verified one. The only thing that varies across authentication outcomes is the label presented to the user and the record written to a provenance log.

A second principle follows from the first:

3.2 The Four Provenance States — All Fully Functional

Every installed component resolves to exactly one provenance state. In all four states the component receives full, unthrottled function. The state determines only the user-facing label and the log entry.

The "attestation failed" row is the load-bearing one. A device implementing this method, on detecting a likely counterfeit, informs the user and continues operating the part at full capability. It does not disable. The user is given the truth and the decision; the device does not make the decision for them by withholding function.

3.3 Device-Independent Attestation Protocol

Provenance is proven by challenge-response over a per-part key, with no host binding:

1. Part credential (factory-provisioned, host-independent). Each component optionally carries a per-part public/private keypair and a manufacturer-signed certificate asserting what the part is. It contains no host identifier and no per-device binding.
2. Challenge. On installation (and on demand), the host generates a random nonce and sends it to the component.
3. Response. The component signs the nonce with its per-part private key and returns the signature plus its certificate.
4. Verification. The host validates the signature and certificate chain against recognized manufacturer roots. Success establishes that the part is a genuine instance of the asserted class/model.
5. Result handling. The verified attributes are written to the provenance service and surfaced as a label. The result is not returned to the component's functional driver.

The protocol is offline by construction. Recognized manufacturer roots and revocation snapshots are cached locally; no network call to a manufacturer is required to install, verify, or use a part.

3.4 The Non-Gating Invariant (Architectural Enforcement)

Non-gating is not a policy promise; it is enforced by separation of subsystems so that it cannot be quietly violated later.

  Provenance Service          Component
  (attestation only)  <──>  (part)
        │                     │
        │ writes attributes   │ raw electrical /
        │ (read-only to UI)   │ data interface
        ▼                     ▼
  Provenance Registry    Subsystem Driver
  (user-visible only)   (charging/display/sensor/etc.)

The invariant, stated formally:

This is enforced by two architectural facts: the subsystem driver has no read access to the provenance result, and the provenance service has no control interface back to the subsystem driver.

3.5 Safety Without Brand-Gating

The honest hard case for any non-locking method is safety. This method preserves safety enforcement while refusing to use brand authentication as the safety mechanism.

Safety limits are derived from measured and self-declared electrical characteristics and the part's safety class, never from the attestation result. A counterfeit battery is made safe by physics the host can measure, not by a brand check it failed. This is the critical distinction: safety enforcement keys on what the part is electrically, which any honest part can satisfy and any counterfeit is physically bound by, rather than on who made it.

3.6 Anti-Counterfeit and Revocation Without Lockout

Legitimate anti-counterfeiting is preserved through a public, append-only transparency log of manufacturer certificates and a revocation feed of known-compromised or known-counterfeit part keys. When a host finds an installed part's key in the revocation feed, it surfaces the "provenance check failed" label and records it. It does not disable the part. Revocation informs; it never locks out.

4.1 Certificate Structure

PartCertificate := Sign_manufacturerKey {
    part_class       : enum
    model            : string
    manufacture_date : date
    safety_class     : enum
    electrical       : ElectricalEnvelope
    part_public_key  : pubkey
    // NO host identifier. NO device serial. NO pairing token.
}

4.2 Verification Sequence

on component_installed(part):
    nonce      = random()
    (sig, cert)= part.challenge(nonce)
    state      = UNATTESTED
    if cert present:
        if verify(cert.part_public_key, nonce, sig)
           and chain_valid(cert, recognized_roots_cache)
           and not revoked(cert.part_public_key, revocation_cache):
            state = ATTESTED_FIRST_PARTY or ATTESTED_INDEPENDENT
        else:
            state = ATTESTATION_FAILED
    provenance_service.record(part, state, cert.attributes if present)
    // state is never passed to the subsystem driver.
    subsystem_driver.operate(part)   // identical call in every branch

4.3 Safety Constraint (independent of 4.2)

on operate(part):
    declared    = part.descriptor.electrical
    measured    = host.measure(part)
    safe_envelope = intersect(declared, measured_safe_bounds(measured))
    apply_limits(part, safe_envelope)   // keys on physics, not on brand

4.4 Integration Surface

The provenance service exposes a read-only query interface so system Settings can display each component's provenance state and diagnostics tooling can read provenance and safety telemetry. There is deliberately no API by which an application or driver can request that a part be disabled on the basis of provenance.

This disclosure composes established building blocks; the novelty is the non-gating, device-independent composition, not the primitives.

• Public-key challenge-response authentication — well-established for decades; the basis of TLS client authentication, smartcards, and hardware tokens.
• FIDO/U2F attestation model (FIDO Alliance, 2014–present) — establishes the pattern of a device attesting to its make and model via a manufacturer-signed attestation key while deliberately avoiding per-device tracking.
• Certificate Transparency (RFC 6962, 2013) — establishes the append-only public log of certificates and the model for public revocation signaling.
• TPM / Secure Boot measured-attestation — establishes attestation as an observed and reported property; this disclosure deliberately diverges by forbidding that property from gating function.
• Right-to-repair regulatory record — the U.S. FTC "Nixing the Fix" report (2021) and subsequent state right-to-repair statutes document parts pairing as a repair obstruction.

This method is published for unrestricted use by any device manufacturer, component maker, operating system, firmware, repair organization, or refurbisher. It is not asserted as proprietary. The purpose of this disclosure is to ensure that non-locking component authentication remains in the public domain and cannot be exclusively claimed by any entity, and equally, that the gating variants cannot be dressed in this method's language while retaining the lockout.