Blockchain in IoT: Verifiable Sensors and Signed Data

Conclusion First (TL;DR)

Establish Identity Before Discussing Data: Every usable “on-chain sensor data” must have provable device identity and measurement accountability.

Signature ≠ Trustworthy: Only when the signature is bound to hardware root of trust, attestation, immutable timeline, and anti-replay, does the signed data have audit significance.

“On-chain” is not just dumping raw data onto L1: It requires batch aggregation, verifiable summaries (Merkle/transparent logs), rolling commitments (rollup-style), to put proofs on-chain and hand over original data to inexpensive verifiable storage.

Privacy First: Do not collect personal sensitive original data by default; where possible, use **selective disclosure/zero-knowledge proofs (ZK)/verifiable credentials (VC/EAS)** instead of exposing plaintext.

Operational Closed Loop: Verifiable ≠ Operable. Make key rotation, certificate revocation, firmware OTA, anomaly alerts, audit reports a “top priority”; otherwise, scaling will definitely fail.

1. Issues and Threats: Why are “Verifiable Sensors” a Necessity?

Typical Application Scenarios:

Cold Chain/Pharmaceuticals: Temperature and humidity/vibration/opening records require non-repudiation;
Distributed Energy/Carbon Measurement: Power generation/consumption/carbon reduction metrics need trustworthy measurement for settlement;
Environmental Monitoring/Urban Governance: Air/noise/emission monitoring relates to compliance and subsidies;
Insurance/Warranty: Equipment operating conditions and lifespan models require verifiable original evidence;
Shared Devices/Machine Market: Computing power/bandwidth/map collection as the settlement basis for DePIN networks.

Core Threat Model:

Forgery/Replay: Copying old data and resubmitting (requires anti-replay and timestamps).
Tampering: Edge gateways or cloud altering data (requires device-side signatures + end-to-end verification).
Fake Devices/Fake Firmware: The same private key being cloned or firmware being replaced (requires hardware RoT + secure boot + remote attestation).
Link Hijacking: MITM injecting fake packets (requires session keys/OSCORE/DTLS etc.).
Privacy Leakage: Putting identifiable personal information on-chain leads to irreversible leaks (requires selective disclosure/ZK/minimal retention).

Summary: Only when who the device is, who the firmware is, and when, where, and how the data was measured can be verified, does the “data” on-chain become trustworthy.

2. Starting with Identity: Device DID, Certificates, and Hardware Root of Trust

2.1 Three Main Paths for Device Identity

X.509 Certificate Chain (PKI): Chip factory burned device key + manufacturer root certificate; the device uses the private key to sign data/handshake.
DID (Decentralized Identifier): did:method:<id> maps device public key to service endpoint; can combine with DID Document to publish verification keys and revocation lists.
Account Binding: Maps the device to an on-chain address (did:pkh/eip155), facilitating direct contract signature verification.

Common Engineering Practice: Use X.509 at the base layer to ensure factory integrity, and expose DID/VC at the outer layer for interoperability with multiple chains/systems.

2.2 Hardware Root of Trust (RoT)

Secure Elements/TPM/SE: Private keys cannot be exported; supports secure boot and attestation (PCR/hash).
Trusted Execution Environment (TEE): Completes sampling, signing, and timing within TEE;
Remote Attestation: Reports device metrics (firmware hash, configuration summary), allowing verifiers to know “who is running what“.

2.3 Sessions and Authorization

Long-term Identity Keys + Short-term Session Keys (to reduce long key exposure).
Permission Segmentation: Different keys/permissions for measurement, signing, updating, debugging.
Key Rotation/Revocation: CRL/OCSP/DID-Revocation lists, supporting rapid banning.

3. The Minimal Closed Loop for Data On-Chain: Collection → Signing → Aggregation → Commitment → Verification

3.1 Edge Data Structure (Recommended CBOR/COSE)

Format: CBOR (compact), COSE_Sign1 (signature container), or JSON + JWS (space for convenience).
Minimal Fields (Example):

{
  "ver": 1,
  "dev": "did:pkh:eip155:1:0xA1b2...c9",  // Device DID/address
  "sns": "temp_v3",                         // Sensor/version
  "ts":  1732310400123,                     // Edge monotonic clock/UTC milliseconds
  "seq": 102938,                            // Device local incrementing sequence
  "loc": { "lat": 1.3521, "lon": 103.8198, "acc": 12 }, // Optional/sanitized
  "val": { "t": 2.4, "h": 63.2 },          // Readings
  "meta": { "unit": "C,%", "fw": "1.2.7", "pcr": "0xabc..."} // Firmware metrics
} + COSE_Sign1(Ed25519/ECDSA)

Key Points: Timestamps, sequence numbers, anti-replay random salts (nonce), and firmware metrics must be signed.

3.2 Edge Gateway/Aggregator

Verify edge signatures → Write to **transparent logs (append-only)** or local Merkle tree;
Batch N records into a fixed window (e.g., every 1–5 minutes) → Generate Merkle Root;
Write Root, window time, count, topic tags on-chain (or submit to L2/DA layer).

3.3 On-Chain Commitment

L1 (expensive) only stores periodic summaries (Merkle Root / KZG commitments) and submitter signatures/stakes;
Original data is placed in verifiable storage (IPFS/Filecoin/object storage + hash), or in L2/DA (Celestia/Avail/EigenDA);
Contracts expose proof verification interfaces: Input leaf + proof + root, contracts verify that this record indeed belongs to that window.

3.4 Evidence/Verification

Consumers (settlement/audit/compliance) provide records + proofs;
Contracts/off-chain verifiers replay signature verification, proof verification and metric verification (e.g., check if pcr is in the whitelist);
Anti-replay: Use seq/ts/window number for uniqueness checks, or contracts can record consumed hashes within.

4. Protocols and Stack: The “Alignment Checklist” from Link to Contract

4.1 Device Side/Edge Side

Link: LoRaWAN, NB-IoT, 4G/5G, Ethernet/Wi-Fi;
Application Layer: CoAP (lightweight, combined with OSCORE for end-to-end encryption), MQTT (publish/subscribe, combined with TLS/DTLS);
Security: DTLS/TLS or OSCORE (object security for CoAP);
Encoding: CBOR/COSE (COSE_Sign1/COSE_Mac);
Time: Local monotonic timing + periodic NTP/SNTP/ptp calibration, drift tolerance must be clearly defined.

4.2 Gateway/Service

Transparent Logs: Implement append-only using Merkle Tree + monotonic numbers (refer to RFC 6962);
Batcher: Time window aggregation and Root generation;
Signing Service: Sign the window Root by the operator, and attach window metadata;
Observability: All submission events sent to Kafka/queues, retaining audit trails.

4.3 On-Chain/Contract

Commitment Contract: commit(root, window, count, topic);
Verification Interface: verify(leaf, proof, root, devicePubkey);
Device Registry: registerDevice(device, pubkey, policy) / revokeDevice(device);
Policy: Threshold rules (e.g., temperature exceeding limits) trigger alerts/forfeits/compensations.

5. Contract Pseudocode (EVM Approach, Simplified)

contract SensorCommitment {
    struct WindowInfo { bytes32 root; uint64 start; uint64 end; uint32 count; }
    mapping(bytes32 =&gt; WindowInfo) public windows; // key = keccak(topic,start,end)
    mapping(address =&gt; bool)     public devices;   // Simplified: whether the device is allowed

    event Committed(bytes32 indexed key, bytes32 root, uint64 start, uint64 end, uint32 count);
    event DeviceUpdated(address indexed dev, bool allowed);

    function updateDevice(address dev, bool allowed) external onlyOwner {
        devices[dev] = allowed; emit DeviceUpdated(dev, allowed);
    }

    function commit(bytes32 key, bytes32 root, uint64 start, uint64 end, uint32 count) external onlyOperator {
        require(windows[key].root == bytes32(0), "dup window");
        windows[key] = WindowInfo(root, start, end, count);
        emit Committed(key, root, start, end, count);
    }

    // Verify if a single record belongs to a certain window's Merkle root
    function verify(bytes32 key, bytes32 leaf, bytes32[] calldata proof) public view returns (bool) {
        bytes32 h = leaf;
        for (uint i = 0; i &lt; proof.length; i++) {
            h = (h &lt; proof[i]) ? keccak256(abi.encodePacked(h, proof[i]))
                               : keccak256(abi.encodePacked(proof[i], h));
        }
        return h == windows[key].root;
    }
}

Off-chain, first hash the COSE package as agreed to form the leaf, and submit the device signature and certificate chain/attestation along with the “proof package” for legal/compliance or layer two verification services to review.

6. Privacy and Compliance: Default Minimal Disclosure

Selective Disclosure: Use VC (Verifiable Credentials)/Assertions to express “meeting thresholds” (e.g., “temperature compliant throughout”) instead of uploading raw values one by one.
Zero-Knowledge: Generate proofs for “threshold proofs/total range” using ZK, only putting boolean/range results and proofs on-chain;
Location Sanitization: Aggregate latitude and longitude by grid (H3/S2); or only upload ZK assertions of being “within a legal area”;
Privacy Policy and Residency: Personal data is only encrypted off-chain, with revocable access and auditing; only hashes/commitments are stored on-chain;
Compliance Boundaries: Adhere to local data laws (GDPR/PDPA, etc.), pre-setting data retention periods and deletion rights processes (off-chain deletions, on-chain commitments remain unreconstructable).

7. Costs and Scalability: Turning “On-Chain Costs/Delays” into Controllable Variables

Batching and Time Windows: Aggregate 10^3–10^6 records into one Root; choose window length based on “SLA/latency” (e.g., 1 minute/5 minutes/1 hour).
Hierarchical Commitment: Gateway → Regional Aggregation → Global Aggregation → L1 Submission; intermediate layers retain local proofs, minimizing L1.
L2/DA Combination: Store large data blocks in L2/DA + lightweight anchoring in L1;
Verifiable Storage: IPFS/Filecoin/S3+object lock + notarized hashes;
Gas Budget: Commitment frequency × gas per transaction; set dynamic thresholds if necessary (automatically extend window length when transaction fees are high).
Availability and Replay: During offline/congestion, gateways cache and retain order and timeline; after recovery, supplement transmission and notify.

8. Operational Closed Loop: Full Lifecycle from Factory to Decommissioning

Factory: Burn device private keys, write certificate chains and DID documents;
Network Entry: Register in the device registry (contract/directory), bind policies and permissions;
Online: Heartbeat/health, firmware OTA (signature + secure rollback);
Key Rotation: Routine rotation; immediate revocation and alerts in case of anomalies;
Audit: Transparent logs/window commitments + reconciliation reports;
Decommissioning: Erase keys, revoke certificates, update registry status.

KPI Metrics (Operational Dashboard):

Devices: Online rate, time synchronization drift, signature failure rate, firmware consistency;
Data: Window submission rate, verification success rate, replay hits/rejections;
Costs: On-chain cost per 10^6 records, DA costs, storage costs;
Risk Control: Forgery/replay/blacklist hits, anomaly device disposal time;
Business: SLA achievement, compliance report issuance time, dispute closure time.

9. Reference “Minimum Viable Solution (MVP)” Blueprint

Device Side

MCU + SE/TEE; sampling period 1–10s; COSE_Sign1/Ed25519; local sequence/timestamp; offline caching (circular buffer).

Edge Side

MQTT over TLS or CoAP+OSCORE;
Batcher aggregates every 60s; generates Merkle Root;
Transparent logs (LevelDB/RocksDB) store leaves and paths;

On-Chain

L2 (low fee) commitments; daily L1 anchoring;
Contracts: Device registry + submission window + verification interface;
Auditor: Reconciliation (window→leaf→device instance), export PDF/CSV reports.

Privacy

By default, only “compliance assertions” and commitments are put on-chain, not raw data;
Location is blockified by H3; sensitive fields are encrypted off-chain + access auditing.

10. End-to-End “Verification Package” Example (Textual Representation)

ProofBundle {
  raw:   COSE_Sign1(payload={ver,dev,sns,ts,seq,loc?,val,meta}, sig=dev_sk),
  cert:  device_cert_chain (X.509 or public key material pointed to by DID Doc),
  att:   remote_attestation { pcr_hashes, fw_hash, sig=chip_attest_key },
  leaf:  keccak256(raw || window_id),
  proof: [sibling1, sibling2, ...], // Merkle path
  root:  0xR.., window: {start,end,count,topic}, operator_sig: sig(root)
}

Consumers call:

Verify the certificate chain/or parse the DID document to obtain the device public key;
Verify COSE signature and attestation;
Verify Merkle proof against root;
Query the contract windows[key] to check if root exists and is not revoked;
Check if seq/ts are monotonic and within the window to prevent replay.

11. 30 / 60 / 90 Day Implementation Roadmap

D1–D30: Minimum Closed Loop for Verifiable Data

Select 1 type of sensor (e.g., temperature/humidity/electric meter/energy consumption), embed SE/TEE or simulate a secure zone
Edge side produces COSE signed packages (including ts/seq/pcr), gateway batches out Merkle Root
Deploy commitment contract in L2, complete commit/verify
Issue the first version of audit report (window→leaf→device)

D31–D60: Metrics and Privacy Enhancements

Launch remote attestation (firmware hash whitelist) and device registry
Integrate OSCORE/DTLS for end-to-end protection and replay protection
Introduce VC/assertions: Make “compliance/exceeding limits” selective disclosures
Complete anomaly alerts and revocation/rotation closed loops

D61–D90: Scaling and Compliance

Multi-region/multi-gateway hierarchical commitments + daily L1 anchoring
Data retention and deletion policies (off-chain privacy data can be deleted, on-chain commitments remain)
End-to-end SLA dashboard and compliance report templates
Channel/customer pilot: Directly bind compliance/compensation/subsidies to “verifiable assertions”

12. Common Pitfalls and Corrections

Only doing TLS, not end-side signing → Gateway can alter data unnoticed. Must sign on the device and report metrics.
On-chain everything → Cost explosion and privacy leaks. Should batch commitments + verifiable storage.
No timestamps/sequences → Replay cannot be checked. Must ts/seq/nonce and perform “uniqueness checks”.
Private keys in software → Easily exported and cloned. Use SE/TPM/TEE.
No revocation and rotation → Once leaked, long-term loss of control. Must have CRL/Revocation and rapid banning.
Directly writing privacy on-chain → Irreversible risks. Default to hashing/commitments + assertions/ZK.

Conclusion: Turning “Trustworthy Measurement” into “Verifiable Assets”

Putting IoT on-chain is not about “sticking data onto the blockchain”, but about creating a reusable trust pipeline for “measurement—signing—proof—commitment—verification”. When every reading can be traced, verified, and audited, and when privacy and costs are controlled through batch commitments/zero-knowledge/assertions, and when operational closed loops (rotation, revocation, OTA, reports) become routine, IoT data will leap from “reference information” to settleable, insurable, and compliant production factors. This is the true value of “putting IoT on-chain”.