Scradasplit: ICS/SCADA Sensor Security

Executive Summary

Scradasplit protects industrial control systems from sensor tampering by splitting each reading via XorIDA threshold sharing. No single node compromise can forge data.

Industrial facilities rely on sensor readings (temperature, pressure, flow rate) to control equipment, optimize processes, and trigger safety actions. If an attacker compromises a single sensor or its transmission path, they can forge readings — causing equipment damage, safety incidents, regulatory violations, or coordinated attacks across multiple sites.

Scradasplit uses XorIDA (threshold sharing over GF(2)) to split each sensor reading into K-of-N shares distributed across independent verifier nodes. HMAC-SHA256 integrity checks happen before reconstruction. A tampered share is immediately rejected. Information-theoretic security means fewer than K shares reveal zero information about the sensor reading — mathematically impossible to crack, not computationally hard.

Two functions cover all use cases: splitSensorReading() takes a sensor reading and configuration (verifier nodes, threshold) and returns shares to distribute. verifySensorReading() verifies HMAC on received shares, reconstructs the reading, and validates the hash. Configuration validation, error handling, and typed alerts all built in.

Developer Experience

Scradasplit provides structured error codes and type-safe Result patterns for reliable industrial software.

Result<T, E> Pattern

All functions return a Result type — either {ok: true, value: T} or {ok: false, error: E}. No thrown exceptions in library code.

const splitResult = await splitSensorReading(reading, config);
if (!splitResult.ok) {
  console.error('Split failed:', splitResult.error.code);
  return;
}
const { shares, readingHash } = splitResult.value;
// Distribute shares to verifier nodes...

Typed Integrity Alerts

Tampering is detected and reported with a typed IntegrityAlert — distinguishing between tampering (HMAC mismatch), data mismatches (reconstruction inconsistency), and missing shares.

Error Categories

Six error codes cover configuration, splitting, verification, and integrity scenarios:

The Problem

Industrial control systems face a critical trust problem: compromising a single sensor or its communication channel allows forging readings that control physical processes.

Attack Scenarios

Tampering via network interception. An attacker intercepts the sensor-to-gateway path and modifies a temperature reading upward. Equipment runs hotter, causing wear or damage.

Sensor unit compromise. A sensor is replaced or modified in the field. All subsequent readings are forged. Operator has no way to detect the swap until physical damage occurs.

Gateway backdoor. A compromised PLC or edge gateway can inject forged readings downstream. A single compromised node controls the entire facility's awareness of what's happening.

Supply chain attacks. Firmware of a sensor or gateway is modified before deployment. The device functions normally but injects readings tailored to a specific attack timeline.

Why Traditional Approaches Fall Short

Real-World Use Cases

Five critical infrastructure scenarios where sensor tampering detection prevents safety incidents and attacks.

Solution Architecture

Three composable layers: reading splitting, verification, and tamper detection.

XorIDA Splitting Pipeline

Step 1: Configuration Validation. Verify at least 2 verifiers, threshold ≥ 2, threshold ≤ verifier count.

Step 2: Padding. PKCS#7 pad the sensor value to a block size derived from nextOddPrime(n) - 1.

Step 3: XorIDA Split. Split padded value into N shares using threshold K. Ensures fewer than K shares reveal zero information.

Step 4: HMAC Generation. Compute HMAC-SHA256 over each share independently. Store both data (base64) and HMAC (base64).

Step 5: Share Wrapping. Attach metadata: sensorId, facilityId, verifierId, index, total, threshold, originalSize, timestamp.

Step 6: SHA-256 Hashing. Compute SHA-256 of original sensor value. Include in split result for later verification.

Verification and Reconstruction Pipeline

Step 1: Validation. Ensure threshold or more shares are provided. Extract metadata from first share.

Step 2: Index Extraction. Get share indices to know which shares were received (order-independent reconstruction).

Step 3: Base64 Decoding. Decode share data and HMAC from base64. Parse share header.

Step 4: XorIDA Reconstruction. Reconstruct padded plaintext using indices, share data, N, and K.

Step 5: PKCS#7 Unpadding. Remove padding. Validate padding structure to detect corruption.

Step 6: Hash Verification. Compute SHA-256 of reconstructed value. Compare to original readingHash. Reject if mismatch.

Integrity Assurance

Information-theoretic security through threshold sharing. No computational assumptions — mathematically impossible to crack.

XorIDA Security Properties

XorIDA threshold sharing over GF(2) provides information-theoretic security. Fewer than K shares reveal zero information about the plaintext — not because the math is hard to break, but because it's mathematically impossible to break. An attacker with unlimited computational power still cannot recover the reading from K-1 shares.

Each share is a random string of the same length as the original data (plus padding). Shares are XORed together during reconstruction. An attacker needs all K shares to XOR back to the original. Fewer shares give random noise.

HMAC Integrity Verification

Every share carries an HMAC-SHA256 signature computed over the share data. During verification, HMAC is checked before reconstruction. If a single byte of a share is modified (intentionally or due to corruption), the HMAC fails and the share is rejected.

HMAC happens before reconstruction. This prevents attackers from using malformed shares to corrupt the plaintext during reconstruction. Fail fast, fail safe.

Hash Validation

After reconstruction, a SHA-256 hash of the plaintext is recomputed and compared to the original readingHash (which was stored with the split result). If reconstruction produced incorrect data due to tampering, the hash will not match. A TAMPERING_DETECTED error is raised.

Deployment

Scradasplit is a pure library — no server, no daemon, no external dependencies. Deploy to Node.js, Tauri, Deno, Bun, or browser.

Installation

pnpm add @private.me/scradasplit

Integration Points

At the sensor: Device firmware calls splitSensorReading() and sends each share to a different verifier. Shares are sent independently — no correlation required.

At the gateway: Gateway receives shares from multiple sources and calls verifySensorReading() once K shares are collected. Verification is instantaneous (<10ms for typical readings).

At the process controller: Controller trusts the reconstructed reading. No need to validate shares — the gateway has already done so.

Multi-Platform Support

Security

Information-theoretic security, HMAC integrity, no custom crypto, cryptographically random secrets.

Cryptographic Properties

No computational assumptions. XorIDA security does not depend on the difficulty of factoring, discrete log, or any computational problem. It is mathematically impossible for an attacker with unlimited computing power to recover the plaintext from fewer than K shares.

HMAC-SHA256 integrity. Each share is signed with HMAC-SHA256. The key is derived from the share data itself, preventing forgery without access to the original plaintext.

SHA-256 hash validation. A second layer of integrity checking via hash comparison after reconstruction. Detects tampering of the plaintext during reconstruction.

No custom crypto primitives. Scradasplit uses Web Crypto API (crypto.subtle) for all cryptographic operations. No home-grown encryption, no proprietary algorithms.

Cryptographically random padding. PKCS#7 padding is deterministic, but the shares themselves are random. Replays of the same reading produce different shares (due to randomness in share indices).

Known Limitations

No replay prevention. Scradasplit does not include nonce or timestamp validation. If a reading is intercepted and later replayed, Scradasplit will accept it as valid. Use timestamping at the gateway or controller level.

No forward secrecy. If a share is stored encrypted, and that encryption key is later compromised, the share plaintext is exposed. Use secure storage (e.g., encrypted filesystems) for share data at rest.

Assumption of independent verifier nodes. Security relies on verifier nodes being independent (different networks, different institutions, etc.). If all verifiers are compromised or colluding, security is lost.

Benchmarks

Scradasplit is fast: typical sensor readings split and verify in single-digit milliseconds.

Benchmarks are measured on Node.js 20 LTS (Apple M2). Times scale linearly with sensor value size (larger readings take longer to split, verify, and hash).

For typical ICS/SCADA use cases (sensor values <256 bytes, K-of-3 or K-of-5 splitting), the overhead is negligible — far less than the network latency to ship shares to verifiers.

Limitations & Honest Assessment

Scradasplit is production-ready for sensor reading verification but has design boundaries.

Replay Attacks

Scradasplit has no replay detection. If a valid reading (all K shares verified) is intercepted and later replayed (sent again to the controller), Scradasplit will accept it as valid. Mitigation: Add timestamp validation at the gateway or controller. Reject readings older than a configurable window (e.g., 30 seconds).

Verifier Node Trust

Security is only as strong as the weakest verifier node. If K or more verifiers are compromised or colluding, they can reconstruct and forge readings. Mitigation: Use geographically or organizationally independent verifiers. Audit verifier infrastructure regularly.

Share Storage

If shares are stored unencrypted, an attacker who gains file-system access can modify them. HMAC will catch the tampering, but the attacker might instead destroy shares (triggering a INSUFFICIENT_SHARES error). Mitigation: Use encrypted storage (e.g., ext4 encryption, BitLocker, encrypted NAS).

Configuration Immutability

Once a reading is split with a specific K-of-N threshold, changing the verifier configuration later will cause reconstruction to fail. Mitigation: Treat configuration as immutable per sensor. Versioning support not yet implemented.

Large Payloads

Sensor readings are expected to be small (100-1000 bytes). For larger values (>1MB), splitting and reconstruction will be slower. Mitigation: Compress sensor data before splitting, or use a dedicated file-sharing mechanism (e.g., Xgit) for large artifacts.

Error Classes

ScadaSplitError: Base class. All other errors inherit from it.

ScadaConfigError: Configuration validation errors (invalid threshold, verifier count, etc.).

ScadaIntegrityError: HMAC and tampering detection errors.

ScadaReconstructError: Reconstruction and share validation errors.

import {
  toScadaSplitError,
  isScadaSplitError,
  ScadaIntegrityError
} from '@private.me/scradasplit';

const result = await verifySensorReading(shares);
if (!result.ok) {
  const error = toScadaSplitError(result.error.code);
  if (error instanceof ScadaIntegrityError) {
    console.error('Tampering detected!', error.message);
  }
}

Functions

Types

Key Files

• src/index.ts — Public API exports
• src/types.ts — Type definitions
• src/errors.ts — Error classes
• src/sensor-splitter.ts — Splitting logic
• src/sensor-verifier.ts — Verification logic
• src/__tests__/sensor-splitter.test.ts — Split tests
• src/__tests__/abuse.test.ts — Abuse case tests
• docs/threat-model.md — Threat analysis
• docs/failure-modes.md — Failure mode analysis

Peer Dependencies

Scradasplit depends on @private.me/crypto (XorIDA, HMAC, padding) and @private.me/shared (Result pattern, types).