Xbeam: Satellite Telemetry Protection

Executive Summary

Xbeam protects satellite telemetry by splitting sensor frames across multiple ground stations using XorIDA threshold sharing. No single station compromise reveals the full data.

Modern reconnaissance satellites downlink thermal imagery, radar data, and optical sensor feeds to ground stations scattered across continents. A single station compromise — whether through RF interception, insider threat, or foreign intelligence penetration — exposes the entire telemetry stream. Traditional encryption protects data in transit but requires every ground station to hold decryption keys, creating multiple points of catastrophic failure.

Xbeam takes a different approach. Each telemetry frame is split via XorIDA (threshold sharing over GF(2)) into N shares, one per ground station. Reconstruction requires any K-of-N shares. An adversary who compromises fewer than K stations learns mathematically zero information about the sensor data — not computationally hard, but information-theoretically impossible to break.

Two functions cover the full workflow: splitTelemetry() shards a frame and generates HMAC-SHA256 integrity tags for each share. reconstructTelemetry() validates HMACs, checks frame hash integrity, and rebuilds the original sensor data from any K shares. Orbital parameters, sensor type, and timestamp metadata preserved alongside shares for reconstruction context.

The Problem

Satellite reconnaissance data flows through ground stations scattered across allied and contested territories. A single station compromise exposes the entire intelligence stream.

Ground stations are semi-trusted. They're operated by allied nations, commercial providers, or host-country militaries. Political winds shift. Personnel turnover creates insider risk. RF downlinks can be intercepted by adversaries with nearby receivers. A single compromised station reveals every frame it processes.

Link-layer encryption isn't enough. TLS or AES-256 protect data in transit, but every ground station that receives telemetry must hold decryption keys. Compromise one station, gain access to all past and future frames that route through it. Key rotation helps, but the fundamental problem remains: keys are present at every endpoint.

Air-gapped processing is impractical. Real-time satellite telemetry feeds mission planning, threat detection, and time-sensitive intelligence products. You can't wait for a courier to physically transport encrypted drives from multiple stations to a secure facility for reconstruction.

Multi-path routing is expensive. Sending encrypted copies of the same frame to multiple stations and reconstructing at a central facility works, but wastes satellite downlink bandwidth — a scarce and expensive resource. Bandwidth is measured in MHz, not GB/s.

Use Cases

Xbeam applies wherever satellite telemetry flows through semi-trusted ground infrastructure across multiple jurisdictions.

How It Works

Xbeam splits telemetry frames via XorIDA threshold sharing, routes shares to independent ground stations, and reconstructs from any K-of-N stations at the analysis facility.

Split Process

The satellite's onboard processor receives a telemetry frame from thermal/radar/optical sensors. The frame contains raw sensor data (Uint8Array), orbital parameters (altitude, inclination), sensor type, timestamp, and unique frame ID.

const frame: TelemetryFrame = {
  frameId: 'FRM-00421',
  satelliteId: 'SAT-RECON-7',
  timestamp: '2026-04-10T14:23:17Z',
  sensorType: 'thermal',        // thermal | radar | optical
  data: new Uint8Array([/* sensor payload */]),
  orbit: { altitude: 550, inclination: 97.4 }
};

splitTelemetry() performs the following steps:

1. Padding: Pad sensor data to alignment boundary via PKCS#7
2. HMAC generation: Generate HMAC-SHA256 key and compute HMAC over padded data
3. XorIDA split: Split padded data into N shares (one per ground station) with K-of-N threshold
4. Share packaging: Encode each share as base64, attach HMAC (base64 key:signature), assign station ID
5. Frame hash: Compute SHA-256 hash of original unpadded data for end-to-end integrity

import { splitTelemetry } from '@private.me/sattelemetry';

const config = {
  stations: [
    { id: 'GS-SVB', name: 'Svalbard', location: 'Svalbard, Norway' },
    { id: 'GS-ALI', name: 'Alice Springs', location: 'Australia' },
    { id: 'GS-MAS', name: 'Maspalomas', location: 'Gran Canaria' }
  ],
  threshold: 2  // Any 2 stations can reconstruct
};

const result = await splitTelemetry(frame, config);
if (!result.ok) throw new Error(result.error.message);

// Result contains 3 shares + frame hash
const { shares, frameHash } = result.value;
// shares[0] → GS-SVB (Svalbard)
// shares[1] → GS-ALI (Alice Springs)
// shares[2] → GS-MAS (Maspalomas)

Reconstruction

Ground stations receive their shares via RF downlink and forward them to the analysis facility over secure networks. The facility collects shares and reconstructs when K or more arrive.

import { reconstructTelemetry } from '@private.me/sattelemetry';

// Received shares from Svalbard + Alice Springs
// (Maspalomas share not needed for 2-of-3 threshold)
const receivedShares = [shares[0], shares[1]];

const result = await reconstructTelemetry(receivedShares, frameHash);
if (!result.ok) throw new Error(result.error.message);

// result.value is the original sensor Uint8Array
const sensorData: Uint8Array = result.value;

reconstructTelemetry() performs the following steps:

1. Share validation: Check metadata consistency (frame ID, total, threshold)
2. Threshold check: Verify at least K shares provided
3. XorIDA reconstruction: Rebuild padded data from shares
4. HMAC verification: Verify HMAC-SHA256 over reconstructed padded data
5. Unpad: Remove PKCS#7 padding to recover original sensor data
6. Frame hash verification: Compute SHA-256 of unpadded data, verify against provided frame hash

Integration

Xbeam integrates into existing satellite ground systems via onboard split, downlink routing, and facility-side reconstruction.

Onboard Integration

Install @private.me/sattelemetry on the satellite's onboard processor. Call splitTelemetry() after sensor data acquisition and before downlink transmission. Route each share to its designated ground station via the satellite's RF transmitter.

import { splitTelemetry } from '@private.me/sattelemetry';

// Sensor acquisition (thermal camera, radar, etc.)
const sensorData = await acquireSensorFrame();

const frame = {
  frameId: generateFrameId(),
  satelliteId: SATELLITE_ID,
  timestamp: new Date().toISOString(),
  sensorType: 'thermal',
  data: sensorData,
  orbit: await getCurrentOrbit()
};

const result = await splitTelemetry(frame, GROUND_STATION_CONFIG);
if (!result.ok) {
  logError('Telemetry split failed', result.error);
  return;
}

// Downlink each share to its designated ground station
for (const share of result.value.shares) {
  await downlinkShare(share.stationId, share);
}

Ground Station Integration

Ground stations receive shares via RF downlink, store them temporarily, and forward to the analysis facility over encrypted networks (VPN, dedicated fiber, or satellite internet uplink). No reconstruction happens at ground stations — they handle routing only.

Analysis Facility Integration

The analysis facility collects shares from multiple ground stations, waits for K shares to arrive, then calls reconstructTelemetry(). Reconstructed sensor data flows into existing imagery analysis, GEOINT workflows, or mission planning systems.

import { reconstructTelemetry } from '@private.me/sattelemetry';

// ShareCollector waits for K shares to arrive from ground stations
const { shares, frameHash } = await shareCollector.waitForThreshold(frameId);

const result = await reconstructTelemetry(shares, frameHash);
if (!result.ok) {
  handleReconstructionError(result.error);
  return;
}

// Pass reconstructed data to imagery analysis pipeline
await imageryPipeline.process(result.value);

Security

Xbeam provides information-theoretic security via XorIDA threshold sharing, dual-layer integrity verification via HMAC and frame hash, and zero-knowledge share isolation.

Information-Theoretic Security

XorIDA threshold sharing over GF(2) guarantees that any subset of fewer than K shares reveals zero information about the plaintext. This is not a computational hardness assumption (like RSA or AES) — it's mathematically provable. An adversary with infinite computing power who compromises K-1 ground stations learns nothing.

Dual Integrity Verification

HMAC-SHA256 per-share integrity: Each share carries its own HMAC, computed over the padded plaintext before splitting. After XorIDA reconstruction, the HMAC is verified before unpadding. This catches share corruption, transmission errors, and tampering attempts.

SHA-256 frame hash: After unpadding, the reconstructed sensor data is hashed and compared against the frame hash transmitted with the shares. This provides end-to-end integrity verification independent of the HMAC layer.

Threat Resistance

Station Distribution Strategy

For maximum security, ground stations should be distributed across geopolitically independent jurisdictions. A 3-station configuration with Svalbard (Norway), Alice Springs (Australia), and Maspalomas (Spain) ensures no two stations share sovereignty or intelligence-sharing agreements that would allow coordinated compromise.

Benchmarks

Xbeam performance measured on Node.js 20 LTS, Intel i7-1185G7 (3.0 GHz base), 16GB RAM. Operations are CPU-bound via Web Crypto API.

Payload Size Scaling

Threshold Configuration Impact

XorIDA performance is dominated by HMAC and padding operations, not the split itself. Increasing N (total shares) has minimal impact. Threshold K does not affect split performance — it only changes reconstruction requirements.

Honest Limitations

Xbeam solves ground station compromise but does not address every threat in the satellite telemetry chain. Honest assessment of what it does and does not protect.

What Xbeam Does NOT Protect

1. Satellite Compromise

If the satellite itself is compromised (firmware backdoor, supply chain attack, insider sabotage during manufacturing), the adversary can exfiltrate plaintext sensor data before splitting. Xbeam protects downlink and ground infrastructure, not the spacecraft.

2. Metadata Visibility

Frame ID, satellite ID, sensor type, timestamp, and orbital parameters are transmitted in cleartext with each share. An adversary intercepting RF downlinks can perform traffic analysis: how many frames downlinked per pass, which ground stations received shares, timing patterns revealing collection priorities.

Why this matters: Even without plaintext access, knowing that a reconnaissance satellite is downlinking to certain stations at certain times reveals operational tempo and mission focus.

3. K-or-More Station Compromise

Information-theoretic security guarantees zero information leakage from K-1 shares. But if an adversary compromises K or more ground stations, they can reconstruct the full telemetry. This is not a cryptographic weakness — it's the fundamental tradeoff of threshold schemes.

Mitigation: Distribute stations across geopolitically independent jurisdictions. A 2-of-3 configuration with Norway, Australia, and Spain requires an adversary to simultaneously penetrate intelligence agencies in three non-aligned nations.

4. No Station Authentication

Xbeam does not verify ground station identity. A rogue station that successfully spoofs downlink protocols can receive shares. Satellite systems should implement station authentication at the RF layer (challenge-response, mutual TLS, or hardware security modules).

5. Frame Ordering and Deduplication

Xbeam does not enforce frame sequencing or prevent replay of old shares. Consumers must implement their own frame ordering (via timestamp + frame ID) and deduplication logic. A sophisticated adversary could replay old shares to inject stale telemetry.

6. Link-Layer Encryption

Shares are not encrypted for RF downlink. While individual shares reveal zero plaintext information, metadata is visible. For maximum operational security, use link-layer encryption (AES-256-GCM over the RF link) in addition to XorIDA splitting.

Regulatory Compliance

Xbeam addresses ITAR, FISMA, and international data sovereignty requirements for satellite telemetry systems.

ITAR (International Traffic in Arms Regulations)

Satellite imagery and sensor data often fall under ITAR export controls. Ground stations in allied nations (Australia, UK, Canada) may be authorized to receive shares, but the full telemetry data cannot be reconstructed on foreign soil without a Technical Assistance Agreement (TAA).

Xbeam compliance strategy: Use a 2-of-3 configuration where two stations are in ITAR-controlled jurisdictions (US, Five Eyes) and one station is allied-but-restricted. Reconstruction happens only at US facilities with proper export licenses. Allied stations handle routing but never reconstruct.

FISMA (Federal Information Security Management Act)

Defense and intelligence satellite systems must comply with FISMA Moderate or High controls. FISMA requires encryption at rest and in transit, plus integrity verification and access controls.

Xbeam addresses: Information-theoretic confidentiality (exceeds AES-256 for share protection), dual-layer integrity (HMAC + frame hash), and compartmentalized access (no single station holds plaintext).

Data Sovereignty (EU, Australia, Japan)

Commercial Earth observation providers must comply with data sovereignty laws. EU GDPR, Australian Privacy Act, and Japan APPI restrict cross-border transfer of certain telemetry data.

Xbeam compliance strategy: Place ground stations in jurisdictions where data sovereignty applies. Shares routed through EU/Australia/Japan ground stations never leave those jurisdictions in plaintext form. Reconstruction happens at the customer's facility within their legal jurisdiction.

Comparison to Alternatives

How Xbeam compares to traditional satellite telemetry protection approaches.

Why Not AES-256-GCM?

AES-256-GCM is computationally secure and widely deployed. But every ground station that receives telemetry must hold decryption keys. Key rotation helps, but the fundamental problem remains: compromise one station, decrypt all traffic that passes through it.

Why Not Homomorphic Encryption?

Fully homomorphic encryption (FHE) allows computation on encrypted data without decryption. But FHE is 10-100x slower than plaintext operations and adds massive bandwidth overhead (10-100x ciphertext expansion). Impractical for real-time satellite telemetry at current maturity levels.

Why Not Multi-Party Computation (MPC)?

MPC allows N parties to jointly compute a function without revealing inputs. But MPC protocols require interactivity — ground stations must communicate with each other during reconstruction. Xbeam reconstruction is non-interactive: collect K shares, reconstruct locally, no inter-station coordination needed.

API Surface

Complete TypeScript API reference for @private.me/sattelemetry.

Core Functions

Types

interface TelemetryFrame {
  frameId: string;              // Unique frame identifier
  satelliteId: string;          // Satellite identifier
  timestamp: string;            // ISO 8601 timestamp
  sensorType: string;           // thermal | radar | optical
  data: Uint8Array;             // Raw sensor data
  orbit: OrbitParams;           // Orbital parameters
}

interface OrbitParams {
  altitude: number;             // Altitude in km
  inclination: number;          // Inclination in degrees
}

interface SatTelemetryConfig {
  stations: GroundStationConfig[];  // Ground station array
  threshold: number;                // K (minimum shares for reconstruction)
  chunkSize?: number;               // Optional XorIDA chunk size
}

interface GroundStationConfig {
  id: string;                   // Station identifier (e.g., GS-SVB)
  name: string;                 // Human-readable name
  location: string;             // Geographic location
}

interface TelemetryShare {
  frameId: string;
  satelliteId: string;
  stationId: string;            // Assigned ground station ID
  index: number;                // Share index (1-based)
  total: number;                // Total shares (N)
  threshold: number;            // Reconstruction threshold (K)
  data: string;                 // Base64-encoded share data
  hmac: string;                 // Base64 "key:signature"
  originalSize: number;         // Original unpadded data size
}

interface TelemetrySplitResult {
  frameId: string;
  shares: TelemetryShare[];
  frameHash: string;            // SHA-256 hex (64 chars)
}

Error Codes

Exhaustive error taxonomy for @private.me/sattelemetry operations.

Error Detail Structure

type SatTelemetryError = {
  code: 'INVALID_CONFIG' | 'SPLIT_FAILED' | 'HMAC_FAILED'
      | 'RECONSTRUCT_FAILED' | 'INSUFFICIENT_SHARES';
  message: string;
};

Threat Model

Detailed threat analysis and residual risk assessment for satellite telemetry splitting.

Trust Boundaries

Trusted: Satellite onboard processor, analysis facility reconstruction environment.

Semi-trusted: Ground stations (authorized to receive shares, but compromisable by adversaries or insider threats).

Untrusted: RF downlink medium, network paths between ground stations and analysis facility.

Threat Scenarios

T1: Ground Station Compromise

Threat: Adversary compromises a ground station and obtains its telemetry share.
Mitigation: XorIDA information-theoretic security — single share reveals zero information.
Residual Risk: If adversary compromises ≥K stations, full frame reconstruction is possible. Distribute stations across geopolitically independent locations.

T2: Telemetry Frame Tampering

Threat: Attacker modifies shares to alter telemetry data.
Mitigation: HMAC-SHA256 verification after reconstruction (before unpadding). Frame SHA-256 hash verified after unpadding. Double integrity check.
Residual Risk: None from share tampering — both HMAC and frame hash verification catch all modifications.

T3: RF Downlink Interception

Threat: Adversary intercepts satellite-to-ground RF transmissions.
Mitigation: Each downlink carries only one share. XorIDA guarantees zero information leakage from fewer than threshold shares.
Residual Risk: Metadata (frame ID, satellite ID, station assignment) is in cleartext on shares. Traffic analysis reveals communication patterns even without data access.

T4: Frame Replay

Threat: Adversary replays old telemetry shares to inject stale data.
Mitigation: Each frame has a unique frameId and timestamp. Consumers should validate frame recency and reject duplicates.
Residual Risk: Xbeam does not enforce frame recency or deduplication. Consumers must implement their own replay detection.

T5: Inconsistent Share Metadata

Threat: Attacker provides shares with mismatched frame IDs or threshold values to cause reconstruction errors.
Mitigation: Share validation checks frameId, total, and threshold consistency across all shares. Mismatches return RECONSTRUCT_FAILED.
Residual Risk: None — metadata consistency checks reject all mismatched shares.

Accepted Residual Risks

1. No RF link encryption: Shares are not encrypted for downlink. Use link-layer encryption.
2. No station authentication: Xbeam does not verify ground station identity.
3. No frame ordering: Consumers must handle frame sequencing.
4. Metadata visible: Frame ID, satellite ID, and station assignments are cleartext.