xPatch: IoT Firmware Split-Delivery

Executive Summary

xPatch gives every IoT device a way to receive firmware updates that are mathematically impossible to intercept or tamper with — even if attackers control the delivery infrastructure.

Over-the-air (OTA) firmware updates are high-value targets: a single intercepted update can reveal proprietary algorithms, enable counterfeiting, or allow malicious modification before installation. Traditional OTA systems send firmware over a single delivery channel — typically HTTPS to a CDN. An attacker who intercepts or compromises this channel can reverse-engineer proprietary firmware, inject malicious code, or replay old vulnerable versions.

xPatch splits firmware images across multiple independent delivery channels using XorIDA (threshold sharing over GF(2)) so that no single channel carries enough data to reconstruct or reverse-engineer the firmware. HMAC-SHA256 integrity verification on each chunk ensures tampered shares are rejected before the device applies any update.

Two functions cover most use cases: splitFirmware() takes a binary firmware image and configuration (channels, threshold, version, device type), splits it into N shares via XorIDA, generates HMAC for each chunk, and returns a manifest + shares ready for multi-channel delivery. reconstructFirmware() verifies HMAC on each received share, reconstructs the firmware from threshold shares, and returns the original binary — identical bit-for-bit to the source.

Zero npm dependencies. Works anywhere the Web Crypto API is available — Node.js, Deno, Bun, embedded environments. Default chunk size 512KB. Information-theoretic security: each share reveals zero information about the firmware.

The Problem

OTA firmware updates sent over single channels can be intercepted and reverse-engineered. Tampered firmware can brick devices or install persistent backdoors at scale.

IoT devices receive firmware updates over a single delivery channel — typically HTTPS to a CDN. An attacker who intercepts or compromises this channel can reverse-engineer proprietary firmware, inject malicious code, or replay old vulnerable versions.

Code signing helps detect tampering at the endpoint, but the firmware image itself travels in the clear. Supply chain attacks that compromise the build server or CDN can sign malicious firmware with legitimate keys, bypassing signature verification entirely.

Traditional encryption protects firmware in transit but requires key distribution to every device — a single compromised key exposes the entire fleet. Firmware versioning prevents rollback but doesn't stop attackers from analyzing current builds to find vulnerabilities.

Attack Scenarios

The PRIVATE.ME Solution

xPatch splits firmware binaries across multiple independent delivery channels using XorIDA. Each channel carries one share. HMAC-SHA256 integrity verification on every chunk prevents tampered installations.

The firmware image is split at the build server into N shares delivered via independent channels — different CDNs, different protocols, different network paths. An attacker intercepting any single channel gets zero information about the firmware.

The device collects K-of-N shares, verifies HMAC integrity on each chunk independently, reconstructs the firmware image, and only then proceeds with installation. Any tampered chunk causes immediate rejection.

@private.me/otadelivery implements this pattern with chunked splitting (default 512KB chunks), per-chunk HMAC-SHA256 verification, version binding (firmware version + device type in every share), and SHA-256 firmware hash in the manifest for end-to-end integrity verification after reconstruction.

Information-Theoretic Security

XorIDA threshold sharing over GF(2) provides unconditional security — not just computationally hard to break, but mathematically impossible. Each individual share reveals exactly zero bits of information about the original firmware, even with infinite computational power.

This is fundamentally different from encryption: AES-256-GCM protects against current attacks but assumes computational hardness. XorIDA protects against all possible attacks, including future quantum computers, because the security comes from information theory, not computational complexity.

Use Cases

Architecture

Firmware binaries are validated at the build server, split via XorIDA across N delivery channels, transmitted independently, HMAC-verified at the device, and reconstructed only after integrity confirmation.

Flow Steps

1. Validation: Build server hashes firmware binary (SHA-256), binds version + device type to manifest.

2. Chunking: Firmware divided into 512KB chunks (configurable). PKCS#7 padding applied to final chunk if needed.

3. XorIDA Split: Each chunk split into N shares (2-of-3 default). Each share contains: index, threshold, version, deviceType, chunkIndex, data (base64), HMAC-SHA256.

4. Multi-Channel Delivery: Shares routed to independent CDNs/protocols. Channel 1 gets share[i][0] for all chunks, Channel 2 gets share[i][1], etc.

5. Device Collection: Device fetches shares from K-of-N channels. Network failures tolerated: only K channels must succeed.

6. HMAC Verification: Device verifies HMAC-SHA256 on each chunk's shares before reconstruction. Tampered shares rejected immediately.

7. Reconstruction: XorIDA combines K-of-N shares per chunk. PKCS#7 padding removed. SHA-256 hash verified against manifest.

8. Installation: Firmware installed only after complete verification. No partial updates.

Integration

import { splitFirmware, reconstructFirmware } from '@private.me/otadelivery';
import type { OTAConfig } from '@private.me/otadelivery';

const firmware = new Uint8Array([/* firmware bytes */]);

const config: OTAConfig = {
  channels: 3,
  threshold: 2,
  version: '1.4.0',
  deviceType: 'sensor-v2',
};

// Split firmware across delivery channels
const result = await splitFirmware(firmware, config);
if (!result.ok) throw new Error(result.error.message);
const { manifest, shares } = result.value;

// Reconstruct on device from any 2-of-3 channels
const rebuilt = await reconstructFirmware(manifest, shares);
if (!rebuilt.ok) throw new Error(rebuilt.error.message);
// rebuilt.value is identical to original firmware

API Surface

Types

Security Properties

HMAC Verification Before Reconstruction

Every share includes an HMAC-SHA256 tag computed over (chunkIndex || shareIndex || data). The device verifies this HMAC before passing the share to XorIDA reconstruction. If HMAC fails, the share is rejected and the error is returned immediately. This prevents attackers from learning anything by submitting tampered shares and observing reconstruction behavior.

No Math.random()

All randomness via crypto.getRandomValues(). No use of Math.random() anywhere in the codebase. Cryptographically secure random number generation is critical for XorIDA threshold sharing.

Benchmarks

Performance Characteristics

Split overhead: Linear in firmware size. ~33ms per 1MB for 2-of-2 threshold (Node.js 20, M1 Mac). Dominated by HMAC computation and XorIDA operations.

Reconstruction overhead: Same as split. HMAC verification per chunk adds ~10-15% overhead vs. raw XorIDA reconstruction.

Network overhead: Each channel transmits approximately (firmware size / threshold) + metadata. For 2-of-3, each channel carries ~50% of firmware size. For 3-of-5, each channel carries ~33%.

Storage overhead: Device can delete shares after successful reconstruction. No persistent storage of shares required.

Honest Limitations

xPatch is not a complete OTA solution. It solves the distribution security problem. You still need to handle firmware signing, version management, rollback protection, and device provisioning.

What xPatch Does NOT Do

Code signing: xPatch does not sign firmware. You should still sign firmware at the build server and verify signatures at the device after reconstruction.

Rollback protection: xPatch binds version to every share but does not enforce monotonic version increases. Your device must track the current firmware version and reject downgrades.

Channel provisioning: xPatch does not provision delivery channels. You must configure CDN endpoints, authentication, and routing yourself.

Device identity: xPatch does not authenticate devices. Combine with @private.me/agent-sdk for cryptographic device identity and per-device update authorization.

Delta updates: xPatch operates on full firmware images. Binary delta updates (e.g., bsdiff) must be applied before splitting or after reconstruction.

Compression: xPatch does not compress firmware. Compress before splitting if needed. XorIDA-split data is not compressible (high entropy).

Deployment Considerations

Channel independence: Security depends on channels being truly independent. Using multiple CDNs from the same provider or the same network path defeats the security model.

HMAC key distribution: HMAC keys must be provisioned securely to devices. Consider using @private.me/agent-sdk for cryptographic device identity and secure key exchange.

Chunk size tuning: Larger chunks reduce metadata overhead but increase memory requirements on constrained devices. Default 512KB works well for most embedded systems.

Building Blocks

xPatch is built on foundational PRIVATE.ME cryptographic primitives. No custom crypto — all algorithms are audited, tested, and reused across the platform.

Security inheritance: xPatch inherits post-quantum protection when firmware shares are transmitted via @private.me/agent-sdk with postQuantumSig: true (X25519 + ML-KEM-768 key exchange, Ed25519 + ML-DSA-65 signatures).

Error Handling

All operations return Result<T, E> with typed error codes. Three error classes provide structured error handling with documentation links.

Full API Surface

Exports

// Core functions
export { splitFirmware, reconstructFirmware }

// Types
export type {
  OTAConfig,
  FirmwareManifest,
  FirmwareShare,
  OTASplitResult,
  OTAError
}

// Error classes
export {
  OTADeliveryError,
  OTAConfigError,
  OTAIntegrityError,
  OTAReconstructError,
  toOTADeliveryError
}

Documentation

Full SECURITY.md + threat-model.md + failure-modes.md available in package. See packages/otadelivery/docs/ in the repository.

Verifiable Firmware Protection

Every operation in this ACI produces a verifiable audit trail via xProve. HMAC-chained integrity proofs let auditors confirm that firmware was split, delivered, and reconstructed correctly — without accessing the firmware itself.

Ready to deploy xPatch?

Talk to Sol, our AI sales engineer, or book a live demo with our team.