IronIP

<1ms

Address Generation

89-bit

Security (Bitcoin PoW)

$0.00004

Per Anchor (32 devices)

700,000x

Faster than CGA

THE INSIGHT

Borrowing Bitcoin's Proof-of-Work for Device Identity

The problem: IPv6 devices need cryptographic addresses to prove their identity on the network. The existing standard — Cryptographically Generated Addresses (CGA) — requires each device to perform its own proof-of-work computation. At high security levels, this takes 696 seconds per address. For resource-constrained IoT devices, that's impractical. For large fleets, it's impossible.

The insight: Bitcoin miners already perform massive proof-of-work — every block header represents trillions of hash computations. What if devices could borrow that work instead of doing their own?

How it works: A device's public key is anchored to a Bitcoin transaction via OP_RETURN. The block header that mines that transaction contains the proof-of-work. The device's IPv6 address is derived from a hash of the block header, the transaction, and a modifier — binding the address to both the device's identity and Bitcoin's cumulative mining effort. Verification is just hash operations: check the Merkle proofs, check the block header's PoW, recompute the address. No certificates, no PKI, no online verification service.

The result: 89-bit security in under 1 millisecond, at a cost of $0.00004 per anchor — each anchor covers up to 32 devices. The security comes from the entire Bitcoin mining network — not from the device's own CPU. This is the core contribution of the Ducroux paper (2023).

PROBLEMS

What IronIP Solves for IoT Device Fleets

Auth Overhead

Current: Typical cloud IoT auth requires multiple round-trips — certificate validation, token exchange, authorization checks

IronIP: Verify source IPv6 with local hash check (<1ms, 0 external calls)

No Mesh Device-to-Device Auth

Current: Only device-to-cloud. Mesh networks have no peer-to-peer auth.

IronIP: Any device verifies any other device's address locally. No internet needed.

HSM Portability / Business Continuity

Current: Device identities tied to a specific cloud provider's infrastructure.

IronIP: Anchors on Bitcoin mainnet. Identities are provider-independent and portable.

Large-Scale Device Provisioning

Current: CGA takes 696 seconds per address. Impractical at scale.

IronIP: <1ms per address. Millions of devices at negligible cost. 89-bit security.

COMPARE

Current Cloud Auth vs IronIP

CURRENT: Typical Cloud IoT Authentication

1. Device → Auth Endpoint ~30ms 2. Validate credentials / certs ~50ms 3. Authorization service check ~60ms 4. Issue session token ~20ms ────────────────────────────────── Total: ~160ms | Multiple round trips | External dependencies Per-auth cost: Compute + key management + auth service Requires: internet, cloud availability

IRONIP: Network-Layer Identity Verification

1. Receive packet, read source IPv6 ~0ms 2. Look up BCA Parameters (local) <0.1ms 3. 8-step verification (hash ops) <0.5ms 4. VERIFIED ✓ ~0ms ────────────────────────────────── Total: <1ms | 0 round trips | 0 external calls Per-verify cost: $0 (local computation only) Works: offline, on-prem, mesh, any cloud

ARCHITECTURE

How It Works

🏭 Device
Token ID

→

₿ Bitcoin
Anchor TX

→

📦 BCA
Parameters

→

🔑 Hash1
Derivation

→

🌐 IPv6 on
Device NIC

→

✓ 8-Step
Verify

Registration (one anchor per batch of up to 32 devices): Batch of Token IDs → generate real device keypair → 32 modifiers → Merkle tree → OP_RETURN(SHA256(pubkey) || merkleRoot) → broadcast to Bitcoin mainnet → store BCA Parameters Address Generation (<1ms, unlimited): Hash1 = SHA-256(modifier || block_header || subnet_prefix || collision_count || transaction) Interface ID = leftmost 64 bits of Hash1, with sec bits set IPv6 = subnet_prefix : interface_id → assigned to device's NIC Verification (local, no cloud): Receive packet → read source IPv6 → look up BCA Parameters → 8-step verify → collision count ✓ → subnet ✓ → pubkey in OP_RETURN ✓ → block header ✓ → Merkle proof (tx) ✓ → Merkle proof (modifier) ✓ → PoW check ✓ → Hash1 match ✓ → VERIFIED: this device is Device HWT-XXXXXXXX

POSITIONING

IronIP + Cloud Auth = Complementary Layers

┌─────────────────────────────────────────────────────────────────┐ │ Layer 3 — Application Auth │ │ Cloud Auth: challenge/response, lifecycle management, │ │ revocation, analytics, compliance, multi-tenant management │ │ → "Is this device authorized to DO this specific thing?" │ ├─────────────────────────────────────────────────────────────────┤ │ Layer 2 — Transport │ │ CloudFront / API Gateway / IoT Core (unchanged) │ ├─────────────────────────────────────────────────────────────────┤ │ Layer 1 — Network Identity (NEW: IronIP) │ │ IPv6 address = cryptographic proof of hardware token identity │ │ Verified locally by any peer. No certificates, no PKI. │ │ → "IS this device who it claims to be?" │ ├─────────────────────────────────────────────────────────────────┤ │ Layer 0 — Hardware Root of Trust │ │ Hardware Security Token (immutable silicon, unique device ID) │ └─────────────────────────────────────────────────────────────────┘ IronIP doesn't replace cloud auth — it adds network-layer identity underneath. Hardware token becomes MORE valuable: root of a permanent, provider-independent identity.

Registers a token on Bitcoin mainnet, generates an address, verifies all 8 steps, provisions to a real EC2 device, pings between devices, and tests IoT Core auth. ~30 seconds.

STEP-BY-STEP Explore Each Stage Individually

STEP 1

Register Device Token → Bitcoin Anchor

Generates a real device keypair, creates 32 random modifiers, builds a Merkle tree, and anchors the device's public key hash + Merkle root to Bitcoin mainnet via OP_RETURN. One anchor covers up to 32 devices — cost: ~27 sats ($0.00004).

STEP 2

Generate BCA IPv6 Address

Derives a cryptographic IPv6 address for a specific VPC subnet. The last 64 bits (the interface identifier) are derived from Hash1 — a hash that binds the device's identity to Bitcoin's proof-of-work. Each registration supports 32 unique addresses x 3 collision counts = 96 addresses.

STEP 3

8-Step BCA Verification

Simulates receiving a packet and verifying the source IPv6 against BCA Parameters. All 8 steps from the paper including Merkle proofs and Bitcoin proof-of-work validation. Runs locally — no cloud call needed.

What are BCA Parameters? (~1.2KB per device)

BCA Parameters (stored on device or in local cache): modifier 16 bytes Random value, unique per address. public key 33 bytes Device's compressed public key (real secp256k1 keypair). transaction ~250 bytes The Bitcoin anchor tx containing OP_RETURN(SHA256(pubkey) || merkleRoot). block header 80 bytes The block that mined the anchor tx. Contains the proof-of-work. subnet prefix 8 bytes The /64 network prefix (e.g., 2001:db8:4a5f:2b00). collision count 1 byte 0-2. Allows regeneration if address conflicts. Merkle proof (tx) ~288 bytes Proves the anchor tx is in the block (max 9 nodes x 32 bytes). Merkle proof (mod) ~160 bytes Proves the modifier is in the registration's Merkle tree (5 nodes x 32 bytes). ────────────────────────────────────────────────────────────────── Total: ~836 bytes Everything needed to verify a device's identity. No network call required.

Verification uses these parameters in 8 steps: check collision count → match subnet prefix → verify public key hash in the Bitcoin transaction's OP_RETURN → validate block header format → verify Merkle proof that the tx is in the block → verify Merkle proof that the modifier is in the tx → check the block header's proof-of-work (this is where the 89-bit security comes from) → recompute Hash1 and compare to the address's interface identifier. All hash operations — runs in microseconds.

STEP 4

Provision to Real EC2 Devices

Assigns BCA IPv6 addresses to real EC2 instances in a private IPv6 VPC. No public IPs — SSM access only. The address appears on the NIC and becomes the device's source IP.

STEP 5

Network-Layer Identity Verification

Device A sends real IPv6 packets to Device B using its BCA source address. Device B verifies the source IP against BCA Parameters — all 8 steps. Zero cloud calls.

STEP 6

IoT Core Authentication via IronIP

A device connects to AWS IoT Core with its BCA IPv6 address as the auth token. The Custom Authorizer runs the 8-step verification and returns an IoT policy. Replaces traditional certificate-based or token-based auth.

SCALE

Bulk Generation & On-Prem Verification

Generate 10 addresses from a single registration, or bulk-register 5 tokens in one batch.

Export BCA Parameters (~836 bytes) and verify without any cloud dependency. Zero AWS SDK, zero API calls.

FAQ

Questions & Answers

Does IronIP replace cloud authentication?

No. IronIP operates at the network layer — it answers "is this device who it claims to be?" by verifying the source IPv6 address. Cloud auth operates at the application layer — it answers "is this device authorized to do this specific thing?" and provides lifecycle management, revocation, analytics, and compliance reporting. Both layers are needed. This is analogous to how TLS proves server identity but you still need OAuth for authorization. IronIP makes the hardware token more valuable — it becomes the root of a permanent, provider-independent network identity.

What changes on the device hardware?

Minimal. The hardware security token already provides the Token ID and public key — that's the identity root IronIP needs. During manufacturing, a one-time registration call anchors the Token ID to Bitcoin (~$0.00004). The device stores ~1.2KB of additional data: one modifier (16 bytes), a block header (80 bytes), and Merkle proofs (~1KB). Address generation is a single SHA-256 hash — under 1ms on any microcontroller. No new silicon, no firmware rewrite.

How does this work for large-scale deployments?

Bulk registration is a batch of API calls — each takes under 3 seconds and costs ~$0.00004 in Bitcoin fees. Each registration yields 32 unique addresses. Devices verify each other's addresses locally — no internet, no cloud call, no round-trip for peer-to-peer identity. Cloud auth still handles application-level authorization, but network identity is settled at the IP layer.

What about on-prem customers who don't want cloud dependency?

IronIP verification requires zero cloud infrastructure. A device stores its BCA Parameters locally (~1.2KB). Any peer can verify the address using only hash operations and the block header — no AWS SDK, no API calls, no internet connection. The Bitcoin anchor is permanent and publicly verifiable. Device identities don't depend on any cloud provider.

Is this tied to Bitcoin SV specifically?

The approach is chain-agnostic — the algorithm works with any blockchain that uses proof-of-work. BSV is used here because of cost efficiency at scale: $0.00004 per device vs significantly higher on other chains. The security parameter (sec) adjusts automatically based on the chain's difficulty. Switching chains requires changing one configuration value.

Where does the 89-bit security claim come from?

From the Bitcoin network's proof-of-work. The address embeds a security parameter (sec=2 for BSV) derived from block difficulty. Step 7 of verification checks that the block header has at least 64 leading zero bits in its hash — which required the entire mining network's computational effort. An attacker would need to redo that work to forge an address. The paper provides the formal security analysis.

How does this affect Common Criteria certification?

IronIP strengthens the certification narrative. The cryptographic primitives (SHA-256, Merkle trees) are NIST-approved and widely certified. The 8-step verification is deterministic and formally specified. The security model is mathematically grounded in Bitcoin's proof-of-work. For CC level 4+, the security model would need independent review — but it provides a well-defined, auditable verification procedure with quantifiable security bounds (89 bits), which is exactly what evaluators want to see.

What's the business model?

New revenue line: "IronIP-enabled" tier. Bitcoin registration costs $0.00004 per device. Manufacturers can offer IronIP registration as a premium service at significantly higher margins. The hardware token becomes more valuable (root of provider-independent identity), cloud auth stays as application-layer auth, and the device SDK adds address generation. It's an upsell, not a replacement.

What's the maturity level of this approach?

Transparent assessment: the paper is a preprint by nChain AG — not yet peer-reviewed at a top security venue. No production deployments exist; this is a first implementation. However: the cryptographic primitives (SHA-256, Merkle trees, Bitcoin PoW) are individually battle-tested. The novel contribution is the specific combination for IPv6 address generation. This is a working proof-of-concept to evaluate the approach as a complementary layer to existing cloud authentication.

What does integration look like?

Three integration points: (1) Manufacturing — add an IronIP registration API call during Token provisioning. One HTTP POST per device, returns in <3 seconds. (2) Device SDK — add generateAddress(tokenId, subnetPrefix). One SHA-256 hash, <1ms. (3) Verification — any peer runs the 8-step check locally. ~1KB of BCA Parameters, standard hash operations. No changes to cloud auth, no changes to IoT Core beyond adding the optional Custom Authorizer.