Hardware-Rooted Attestation Tokens for Electricity Generation

2.1. Terms

Attester:

A metering device, paired with a secure element, that produces attestation tokens. This aligns with the Attester role in the RATS architecture [RFC9334].¶

Verifier:

Any party that reconstructs and validates an attestation, including its Merkle inclusion proof and on-chain commitment.¶

Relying Party (RP):

An economic actor consuming an attestation as evidence of clean-energy generation: a producer, consumer, regulator, or integrator.¶

Endorser:

An entity that issues an endorsement linking a device's public key to a real-world identity, such as a manufacturer, a certification authority, or a self-attested operator.¶

Reference Values:

The expected device configuration, firmware hash, and certification status against which Verifiers may assess an Attester.¶

Attestation Token:

A CBOR-encoded COSE_Sign1 object carrying the signed measurement and ancillary claims.¶

Evidence Payload:

The CBOR claims map carried inside an Attestation Token, as defined in Section 4.1.¶

Settlement Layer:

A publicly accessible verifiable data structure on which Merkle roots of attestation batches are committed. In this version, the Settlement Layer is an EVM-compatible Layer 2 rollup; future revisions MAY broaden this.¶

Batch:

An ordered collection of attestation tokens whose hashes form the leaves of a single Merkle tree.¶

Epoch:

The sequence number identifying a batch in time. Epochs increase monotonically.¶

Challenge Window:

A configurable period following batch submission during which the batch can be challenged before finalization.¶

NOET:

The attestation accounting unit of the protocol. One NOET represents one verified kilowatt-hour. NOET is a unit of attestation, not a payment instrument, a currency, or a store of value; this document specifies no transfer, pricing, or settlement-of-value semantics for it.¶

3.1. Attester

The Attester is composed of two physical components: a kilowatt-hour meter (the measurer) and a secure element (the signer). The Attester:¶

• MUST generate the device's signing key inside the secure element using on-chip entropy.¶
• MUST NOT permit the signing key to leave the secure element under any operational condition.¶
• MUST sign each evidence payload with the device's private key, as a COSE_Sign1 structure (Section 5.1), before transmission.¶
• SHOULD include in each attestation a hash of the previous attestation produced by the same device, forming a per-device hash chain.¶
• MAY include firmware version, model identifier, and configuration claims in the attestation token.¶

3.2. Verifier

The Verifier is software, executed by any interested party, that:¶

• MUST validate the COSE_Sign1 signature of the attestation token, as specified in Section 5.1, using the Attester's endorsed public key, and MUST reject any token whose protected header names an algorithm the Verifier does not accept.¶
• MUST verify the Merkle inclusion proof against the on-chain committed root for the corresponding epoch.¶
• SHOULD check the endorsement chain of the Attester's public key against a trusted Endorser registry.¶
• MAY apply additional Reference Values checks (firmware version, model, certification status) where required.¶

3.3. Relying Party

The Relying Party consumes attestations and acts on them. A Relying Party:¶

• MUST independently invoke a Verifier, either as a library or as a service; it MUST NOT rely on an Attester's self-report alone.¶
• SHOULD apply use-case-specific validity criteria beyond signature verification, for example timestamp freshness or jurisdiction.¶

3.4. Endorser

An Endorser issues an endorsement binding a device public key to identity metadata such as manufacturer, model, and certification batch. Endorsers:¶

• MUST publish their own public key in a manner that is itself verifiable, such as an X.509 certificate, a well-known DNS record, or an on-chain registry.¶
• SHOULD specify the procedure by which they obtain assurance that a given public key originates from a tamper-evident secure element.¶

This document does not mandate a single Endorser hierarchy. A federation of Endorsers is expected to emerge in practice; relying parties choose which Endorsers to trust.¶

3.5. Validator

The Validator is an on-chain role responsible for confirming Merkle root submissions before they are finalized for claim. Validators extend the RATS architecture; they exist because the on-chain commitment layer requires a defined set of accountable parties whose signed actions are the basis of finalization. A Validator:¶

• MUST hold the validator role granted by the holder of the settlement contract's administrative role. Production deployments place that administrative role in a multi-signature wallet.¶
• MUST independently verify the Merkle root it is voting on against its own reconstruction of the underlying leaf set before broadcasting a batch proposal or a vote. A Validator that votes without independent verification is a single point of trust and defeats the m-of-n property the quorum is designed to provide.¶
• SHOULD publish its identity (operator, jurisdiction, and contact) so that fraud-proof challengers and relying parties can attribute votes.¶
• MAY be operated by the standards body, by a delegated operator, or by an independent third party. The m-of-n design treats Validators as Byzantine-tolerant peers, not as trusted authorities.¶

Validator accountability is enforced through two mechanisms whose details appear in Section 8.4:¶

1. Quorum. No single Validator can cause finalization on its own; the m-of-n threshold ensures that a minimum of "threshold" distinct Validators must independently agree. The threshold value is a deployment parameter; production deployments SHOULD select a threshold of at least ceil(2n/3) for Byzantine fault tolerance, where n is the size of the active Validator set.¶
2. Slashing. A Validator proven to have voted for a fraudulent batch loses the validator role and has the off-chain evidence hash recorded on-chain. A Validator that has been slashed for a prior epoch retains the vote it cast before the slash: historical votes are durable in order to preserve the audit trail.¶

The Validator role is distinct from the Attester (the on-device measurer and signer) and from the Verifier (the relying-party-side software). The Attester proves a measurement was taken on certified hardware; the Validator proves a quorum of independent parties agree the measurement appeared in a legitimate batch; the Verifier checks both layers when consuming an attestation.¶

4.1. Claim Set

The evidence payload is a CBOR map using the integer labels listed in Table 1. These labels are local to this profile and are scoped to the payload map only; they are independent of the COSE header labels used in the enveloping structure (Section 4.2).¶

The evidence payload carries no signature claim and no algorithm claim. The signature, the signature algorithm, and the key identifier are carried by the enveloping COSE_Sign1 structure as described in Section 4.2 and Section 5.1.¶

4.2. Algorithm and Key Identification

Algorithm agility in this protocol is provided exclusively by the COSE protected header of the enveloping COSE_Sign1 structure. Specifically:¶

• The "alg" header parameter (COSE header label 1) identifies the signature algorithm. It MUST be present in the protected header. For this version of the protocol its value MUST be -7 (ES256), as registered in [RFC9053].¶
• The "kid" header parameter (COSE header label 4) identifies the endorsed device key used to produce the signature. It SHOULD be present in the protected header. Where it is absent, a Verifier MUST resolve the key from the "iss" claim through the registry of Section 7.1.¶

An implementation MUST NOT convey the signature algorithm as a claim inside the evidence payload. A Verifier that encounters an algorithm indication inside the evidence payload MUST reject the token, because such an indication would create a second and possibly disagreeing source of truth for algorithm selection.¶

4.3. CDDL Definition

The following CDDL [RFC8610] defines the attestation token. It is normative for the structures it covers.¶

; A Noethrion attestation token is a tagged COSE_Sign1 structure.
Noethrion-Attestation = #6.18(Noethrion-Sign1)

Noethrion-Sign1 = [
  protected   : bstr .cbor Noethrion-Protected-Header,
  unprotected : Noethrion-Unprotected-Header,
  payload     : bstr .cbor Noethrion-Claims,
  signature   : bstr
]

Noethrion-Protected-Header = {
  1 => int,               ; alg; MUST be -7 (ES256) in this version
  ? 4 => bstr,            ; kid; endorsed device key identifier
  * cose-label => any
}

Noethrion-Unprotected-Header = {
  * cose-label => any
}

Noethrion-Claims = {
  1 => bstr,              ; iss:  secure element serial number
  2 => uint,              ; iat:  issued-at, UTC seconds
  3 => uint,              ; wh:   energy delta, watt-hours
  4 => uint,              ; seq:  per-device monotonic counter, >= 1
  5 => bstr / null,       ; prev: hash of previous token;
                          ;       null if and only if seq == 1
  ? 6 => tstr,            ; fwv:  firmware version
  ? 7 => tstr,            ; mdl:  device model identifier
  ? 8 => bstr,            ; cfg:  device configuration hash
}

cose-label = int / tstr

The Merkle aggregation layer of Section 6 and the claim-record encoding of Section 6.3.1 are not yet expressed in CDDL. [TBD: full CDDL covering the batch, inclusion-proof, and claim-record structures in -01]¶

4.4. Mapping to EAT

The claim set above is intentionally compatible with the Entity Attestation Token (EAT) format defined in [RFC9711]. EAT is itself carried in COSE, so the envelope chosen in Section 5.1 is the same one an EAT profile would use. Implementations MAY choose to additionally emit a fully EAT-conformant variant by mapping "iss", "iat", and "seq" to their CWT-registered claim numbers. A formal EAT profile for energy attestation will be specified in a follow-up document. [TBD: EAT profile claim mapping table in -01]¶

5.1. Signature Envelope

Attestation tokens MUST be signed as a COSE_Sign1 structure as defined in [RFC9052], Section 4.2, tagged with CBOR tag 18. COSE_Sign1 is chosen over a bare signature field for three reasons:¶

1. It is the envelope used by the Entity Attestation Token [RFC9711] and by the wider RATS ecosystem [RFC9334], so that evidence produced under this specification can be consumed by existing COSE and EAT tooling without a bespoke parser.¶
2. It provides integrity protection over the algorithm and key identifiers themselves, through the protected header, which a bare signature over a claims map does not.¶
3. It gives a single, already-specified path for algorithm rotation (Section 5.3).¶

The signature is computed over the Sig_structure defined in [RFC9052], Section 4.4, with:¶

• "context" set to the text string "Signature1";¶
• "body_protected" set to the serialized protected header;¶
• "external_aad" set to a zero-length byte string in this version;¶
• "payload" set to the deterministically encoded evidence payload of Section 4.1.¶

Implementations MUST NOT emit an attestation token as a bare claims map with an adjacent signature field. Pre-standard implementations of this protocol, including the genesis deployment of the reference implementation, used such a bare encoding. That encoding is historical, is not conformant with this document, and MUST NOT be used for new deployments. Verifiers MAY retain support for it solely in order to re-verify pre-standard historical records.¶

5.2. Rationale for P-256

P-256 is selected because:¶

1. It is the curve natively supported by widely available secure elements suitable for low-cost meter integration, including parts certified to Common Criteria EAL5+.¶
2. It is broadly understood, has mature implementations, and is acceptable to relying parties whose internal cryptographic policies typically permit NIST curves.¶
3. Performance on constrained microcontrollers is sufficient for the protocol's per-minute signing cadence.¶

5.3. Post-Quantum Migration

It is acknowledged that P-256 is not post-quantum secure. A migration path to a post-quantum signature scheme, anticipated to be ML-DSA as standardized in [FIPS204], is part of the protocol's long-term plan. No new format machinery is required for that migration: the "alg" and "kid" parameters of the COSE protected header (Section 4.2) are the algorithm and key rotation mechanism, and a future revision need only permit an additional "alg" value and specify the transition policy. Historical attestations remain verifiable because each token names, under integrity protection, the algorithm with which it was signed.¶

A future revision of this document SHALL specify the migration procedure, including dual-signing transitions and the policy under which historical P-256 attestations remain verifiable.¶

6.1. Off-Chain Aggregation

Attestation tokens are aggregated off-chain into Merkle trees. Each tree contains up to 2^16 (65,536) leaves, where each leaf is the SHA-256 hash of the complete deterministically encoded, tagged COSE_Sign1 attestation token of Section 4.¶

Interior nodes are computed with a commutative sorted-pair construction:¶

parent = keccak256(min(a, b) || max(a, b))

where a and b are the two 32-byte child hashes and min and max denote lexicographic byte-wise ordering. Sorting each pair before hashing makes the construction order-independent: an inclusion proof carries only the sibling hashes, with no left/right position flags. This is the construction implemented by the widely used Merkle proof library employed by the on-chain reference contract and by the reference off-chain Verifier tooling. Off-chain builders MUST use this pair hash for any tree whose root is committed on-chain.¶

Note on leaf domain separation: this construction deliberately omits the per-level domain-separation prefixes (0x00 for leaves, 0x01 for interior nodes) defined by [RFC9162]. The second-preimage class those prefixes guard against, namely reinterpreting an interior node as a leaf or vice versa, is structurally closed here by preimage length: an interior-node preimage is exactly 64 bytes (two concatenated 32-byte hashes), whereas leaf preimages are never 64 bytes. The on-chain claim-record leaf (Section 6.3.1) hashes a 160-byte encoded payload, and the attestation-evidence leaf hashes a tagged COSE_Sign1 token, which is substantially longer than 64 bytes for any token carrying the required claims of Section 4.1 together with a 64-byte ECDSA P-256 signature. The attestation-evidence leaf additionally uses a different hash function, SHA-256, from the keccak256 node hash. [RFC9162] informed the design of this layer and is listed as an informative reference.¶

A batch is identified by a monotonically increasing epoch number. The aggregator MAY be operated by the device owner, by a service provider, or by the reference implementation; the choice does not affect verifiability.¶

6.2. On-Chain Commitment

For each batch, the Merkle root is committed to a public EVM-compatible Layer 2 settlement network through a reference smart contract. Note that the reference contract is named "Attester" for historical reasons unrelated to the RATS Attester role of Section 3.1; the two are distinct. The on-chain commitment record SHALL include, at minimum:¶

• the epoch number;¶
• the Merkle root (32 bytes);¶
• the total watt-hour sum claimed in the batch, for cross-check against grid-level dispatch records;¶
• the proposing validator's address, and, through separate vote events, the addresses of all validators who voted to reach quorum;¶
• the block timestamp at submission;¶
• the quorum threshold value active at the moment of submission. Snapshotting this at submission, rather than reading live storage at finalization, ensures that a subsequent administrative change to the global threshold cannot retroactively pass or block this specific batch;¶
• the challenge-window value active at the moment of submission. Snapshotting prevents retroactive shrinking, which would let an administrator finalize batches early, and retroactive extension, which would freeze finalization of legitimately voted batches.¶

The two snapshot fields close the symmetric retroactive-shift class of administrative abuses.¶

A challenge window, configurable and defaulting to one hour, follows submission. In the current reference contract the fraud-proof path during this window is off-chain: any party MAY report evidence of a fraudulent batch to the contract operators and validators, who can respond through the on-chain pause mechanism, blocking finalization, and administratively triggered slashing (Section 8.4). A dedicated on-chain challenge entry point, allowing any party to publish a fraud proof directly on-chain, is deferred to a future protocol extension, together with fraud-proof-verified slashing. After the challenge window expires without the batch being rejected, the batch is finalized; finalization is irreversible.¶

6.3. Verification Path

A Verifier resolves a single attestation as follows:¶

1. Receive the candidate attestation token and a Merkle inclusion proof, consisting of the sibling hashes along the tree path.¶
2. Compute the SHA-256 leaf hash over the deterministically encoded, tagged COSE_Sign1 token.¶
3. Apply the inclusion proof to derive the candidate Merkle root.¶
4. Look up the on-chain commitment for the corresponding epoch.¶
5. Confirm that the candidate root equals the committed root.¶
6. Confirm that the batch is finalized, that is, that the challenge window has elapsed without a successful challenge.¶
7. Validate the COSE_Sign1 signature (Section 5.1) against the device Attester's endorsed public key: the secure-element-bound key of Section 3.1, and not the on-chain contract of Section 6.2.¶

All seven steps MUST succeed for the attestation to be accepted.¶

7.1. Public Key Registry

Endorsed device public keys are recorded in a registry. The registry MAY be:¶

• on-chain, as a smart-contract mapping from device serial number to public key and endorsement metadata, with role-based mutation rights restricted to Endorsers. This is the reference deployment;¶
• off-chain, distributed as signed JSON files at well-known URLs maintained by Endorsers;¶
• hybrid, with on-chain anchors and off-chain bulk distribution.¶

The choice is operational and does not affect the verification semantics: a Verifier MUST be able to obtain a device's endorsed public key, traceable to an Endorser whose own key is verifiable.¶

7.2. Endorser Revocation

An Endorser MAY revoke an endorsement, for example on discovery of a compromised provisioning batch. Revocations SHALL be timestamped; a Verifier evaluating an attestation MUST consider revocations issued before the attestation's "iat" timestamp.¶

7.3. Device-Level Revocation

A device's endorsement MAY be revoked individually, for example on suspicion of physical tampering reported through the protocol's challenge mechanism. Attestations from a revoked device with an "iat" value after the revocation timestamp MUST be rejected.¶

8.1. Compromised Host MCU

The host microcontroller adjacent to the secure element may be compromised. Because the signing key is generated on-chip and never leaves the secure element, a compromised host can lie about what to sign but cannot forge signatures under the device's public key.¶

The protocol mitigates this through Reference Values, namely the firmware hash and configuration hash included in the attestation claims. A Relying Party that knows the expected Reference Values can detect a tampered host.¶

8.2. Meter Substitution and Physical Tampering

The Attester is composed of a measurer and a signer (Section 3.1). Every cryptographic guarantee in this document applies to the signer: a valid attestation proves that a particular secure element signed a particular set of numbers. It does not, on its own, prove that those numbers came from the meter the Endorser expects, nor that they correspond to physical energy flow. The measurer-to-signer interface is consequently the weakest link in the chain of custody, and it is where the adversaries below operate.¶

Meter substitution. An adversary with physical access may replace the meter, or interpose on the measurer-to-signer interface, and present fabricated readings to the secure element. The secure element signs them faithfully and verification succeeds at every later stage: the signature is valid, the endorsement chain is intact, the hash chain is continuous, and the on-chain commitment is well formed. Where the measurer-to-signer interface is unauthenticated, as it is on a bare pulse output or an unauthenticated serial connection, no mechanism defined in this document detects this attack.¶

Substitution after verification. A measurer that is verified only once, at commissioning or at Attester power-on, provides no continuing guarantee: an adversary may satisfy the check with a genuine meter and substitute afterwards. Implementations MUST NOT treat a commissioning-time verification of the measurer as evidence about readings produced later.¶

Physical tampering of a genuine meter. The meter or its sealing may be tampered with in order to distort readings at the point of measurement. This protocol does not detect such tampering; the existing physical-seal and audit regime of revenue-grade metering, which predates this protocol, remains necessary. That regime is complementary to the mitigations below, not a substitute for them, because a seal constrains the meter itself and says nothing about what reaches the signer.¶

Secure-element substitution. This case is detected, because the device serial number changes and the new public key has no endorsement chain.¶

The following mitigations apply to the measurer-to-signer interface.¶

• Authenticated measurement. The Attester SHOULD be built on a meter whose metrology function authenticates each reading under a key held in the meter's own protected storage, and the secure element SHOULD verify that authentication before including a reading in the claim set.¶
• Continuous rather than one-time verification. Where the interface supports authentication, the Attester SHOULD verify it at every reporting interval rather than only at commissioning, so that no window exists in which a verified measurer can be exchanged for an unverified one without detection.¶
• Fail-closed behaviour. If the measurer cannot be authenticated, becomes unavailable, or returns readings inconsistent with the Attester's monotonic energy counter, the Attester MUST NOT emit an attestation covering the affected interval. Emitting an attestation over unauthenticated readings, or falling back to an unauthenticated interface, defeats the purpose of signing them. A Relying Party MUST treat the absence of an attestation as the absence of attested generation, and MUST NOT substitute an unattested reading in its place.¶

Residual risk. Deployments whose measurer-to-signer interface is unauthenticated retain the full meter-substitution risk described above. For those deployments the assurance offered by this protocol degrades from "this quantity of energy was generated" to "this secure element reported this quantity", and the binding to physical generation rests entirely on out-of-band procedures. Deployments supporting regulatory or financial settlement SHOULD use an authenticated measurement interface for this reason. A claim conveying the class of measurer-to-signer protection, so that a Relying Party can apply policy to it rather than assuming it, is [TBD in -01].¶

8.3. Secure-Element Key Extraction

Extraction of the signing key from a Common Criteria EAL5+ secure element is currently considered infeasible against the design assumptions of state-of-the-art parts. If such an extraction becomes feasible, the affected device family's endorsements SHALL be revoked. The protocol's per-device hash chain, carried in the "prev" claim, limits the value of an extracted key for back-dating, because all historical attestations are anchored on-chain.¶

8.4. Validator Collusion

A validator could withhold attestations or propose a batch with a Merkle root that does not correspond to the claimed leaves. Three mechanisms address this in combination:¶

1. m-of-n threshold quorum. Finalization requires a threshold number of distinct validator votes through the propose, vote, and finalize sequence. A single party cannot cause a batch to be finalized. The threshold MUST be selected such that coalition cost exceeds expected fraud value; analogous systems typically use ceil(2n/3) for Byzantine fault tolerance.¶
2. Challenge window. Independently of the threshold mechanism, between submission and earliest finalization any party MAY report evidence of fraud. In the current reference implementation this path is off-chain: evidence is reported to operators and validators, who block finalization through the pause mechanism and apply slashing. An on-chain challenge entry point is deferred to a future revision (Section 6.2). A batch successfully challenged within the window is never finalized.¶
3. Slashing. Validators proven to have voted for fraudulent batches MAY be slashed: the validator role is revoked and the off-chain evidence hash is recorded on-chain. The current reference contract implements administratively triggered slashing; on-chain fraud-proof verification feeding slashing automatically is deferred to a future revision.¶

A coalition of threshold-many validators colluding within the challenge window can still finalize a fraudulent batch. This is the residual risk; it shrinks but does not disappear with the threshold mechanism. Production deployments SHOULD treat the challenge-window fraud-proof path as load-bearing.¶

8.5. Replay Attacks

The combination of the per-device monotonic "seq" claim and the previous-attestation hash chain, carried in "prev", prevents replay of an old attestation as a new one. A Verifier that observes a "seq" value that is not strictly greater than the highest previously observed value for the same device MUST reject the attestation.¶

8.6. Side-Channel Observation

Side-channel attacks against the secure element, including power analysis, electromagnetic analysis, and fault injection, are mitigated by the Common Criteria certification regime governing the part. Operators SHOULD follow vendor guidance on physical deployment in order to reduce exposure.¶

9.1. Inferences from Attestations

A continuous record of per-device generation timestamps can be correlated with consumption patterns in order to infer the occupancy and behavior of a household. Aggregation and timestamp rounding mitigate but do not eliminate this risk.¶

9.2. Mitigations

• Timestamp rounding. Producers MAY round "iat" to a coarser resolution, for example ten-minute buckets, at the cost of reduced verification granularity.¶
• Batch padding. Aggregators SHOULD pad batches with dummy leaves so that a small-scale producer's contribution count is not distinguishable.¶
• Optional zero-knowledge extensions. A future revision will specify an optional zero-knowledge-friendly attestation variant in which the per-device identifier is replaced by a commitment, with selective-disclosure proofs available to authorized auditors.¶

9.3. Right to Opt Out

Participation in the protocol is, by design, voluntary. Operators are not required to publish attestations; the protocol's value derives from voluntary adoption by parties that wish to be cryptographically credible.¶