Flight Recorder Resilience

The Problem

Flight data recorders contain safety-critical evidence. But their centralized custody creates vulnerability.

Single Points of Failure

Flight Data Recorders (FDR) and Cockpit Voice Recorders (CVR) are the primary evidence source for accident investigation. Today, a single aircraft holds both recorders. If that aircraft is lost, recovers only one, or the investigators lose custody of the data, the entire accident reconstruction is compromised. One organization controls the complete recording.

Jurisdictional Blind Spots

International accidents involve multiple countries. The lead investigator (e.g., NTSB for US accidents) controls the full recording, determining what other countries see. If the lead investigator's systems are compromised, sabotaged, or politically motivated, the original data cannot be independently verified. There is no ground truth beyond their custody.

Reconstruction Bottlenecks

During active investigations, reconstruction of high-fidelity audio/telemetry requires reassembling the full recording. If systems fail, data is corrupted, or organizations disagree on interpretation, recovery is slow and contentious. No mechanism exists to distribute trust across authorities.

The Solution

Split recorder data across multiple aviation authorities at the source. No single authority holds the complete recording.

Distributed Custody via XorIDA

Flightsplit uses XorIDA threshold sharing to split flight recorder data into N shares across N aviation authorities (NTSB, BEA, AAIB, etc.). A configurable threshold K of authorities is required to reconstruct. For example, a 3-of-3 split means all three must cooperate. A 2-of-3 split means any two can reconstruct, providing fault tolerance while keeping the whole out of single hands.

Information-Theoretic Security

XorIDA operates over GF(2), the Galois field with two elements. Any subset of shares below the threshold reveals zero information about the original recording — not statistical leakage, not marginal information, but provably zero bits. A single authority with only K-1 shares cannot compute, guess, or correlate anything about the flight data. This is information-theoretic, not computational, security.

Automatic Chunking for Large Data

Flight recorders produce gigabytes of data over multi-hour flights. Flightsplit automatically chunks large recordings into 1 MB segments (configurable), splits each chunk independently, and indexes them in a manifest. Reconstruction joins chunks in order, producing the exact original bytes.

HMAC Integrity Before Reconstruction

Every share carries an HMAC-SHA256 signature computed over the padded chunk. During reconstruction, HMAC verification must complete before any data is reassembled. A single corrupted share is rejected immediately, protecting against tampering.

API Surface

Two primary functions: split and reconstruct. Async, type-safe, no surprises.

Type Hierarchy

FlightData — Input: flight ID, aircraft ID, recorder type (FDR/CVR), raw bytes, timestamp.
AviationAuthority — Authority: id, name, ISO country code.
FlightConfig — Configuration: authorities array, threshold K, optional chunk size.
FlightShare — Per-authority output: flight/authority IDs, share index, chunk index, base64 data, HMAC signature.
FlightManifest — Metadata: operation ID, flight/aircraft IDs, chunk count, data hash, config, timestamp.
FlightSplitResult — Success: manifest + 2D share array [chunkIndex][authorityIndex].

Error Handling

Complete Workflow

End-to-end: capture through authorities to reconstruction.

Phase 1: Recording & Preparation

1. Aircraft FDR/CVR continuously records flight parameters and audio.
2. On touchdown or incident, the recorder is recovered (or remotely downloaded if connectivity exists).
3. Raw binary data is read into a FlightData struct with flight ID, aircraft ID, recorder type, data bytes, and timestamp.

Phase 2: Splitting

4. Investigator calls splitFlightData(flightData, config) with a list of N aviation authorities and a threshold K.
5. For each authority, Flightsplit generates a share. Large data is chunked, each chunk independently split. HMAC-SHA256 is computed per chunk to verify integrity later.
6. A FlightManifest is produced describing the split operation (ID, flight info, chunk count, data hash, config, timestamp).
7. Shares are packaged as base64-encoded data with metadata (flight ID, authority ID, chunk index, HMAC).

Phase 3: Distribution

8. Each aviation authority receives its shares via secure transport (TLS, physical courier, airgapped handoff — implementation-dependent).
9. Authorities store shares in their evidence databases with access logs and chain-of-custody records.
10. The manifest is published to a shared registry or court filing system so all parties know the split parameters.

Phase 4: Reconstruction

11. During investigation, authorities cooperate to reconstruct. They provide shares for a specific chunk.
12. Investigator calls reconstructFlightData(shares, manifest).
13. For each chunk, Flightsplit validates HMAC signatures, checks share count ≥ threshold, verifies chunk indices match, and runs XorIDA reconstruction.
14. Chunks are joined in order, producing the exact original FDR/CVR bytes.
15. Investigator verifies the data hash matches the manifest to confirm no data corruption.

import { splitFlightData, reconstructFlightData } from '@private.me/flightsplit';

// Input flight data
const flightData = {
  flightId: 'UAL1234',
  aircraftId: 'N12345',
  recorderType: 'FDR',
  data: new Uint8Array([/* 500 MB of telemetry */]),
  recordedAt: '2026-04-10T08:30:00Z',
};

// Configuration: split across 3 authorities, any 2 can reconstruct
const config = {
  authorities: [
    { id: 'NTSB', name: 'NTSB', country: 'US' },
    { id: 'BEA', name: 'BEA', country: 'FR' },
    { id: 'AAIB', name: 'AAIB', country: 'GB' },
  ],
  threshold: 2,
};

// Split
const splitResult = await splitFlightData(flightData, config);
if (!splitResult.ok) {
  console.error('Split failed:', splitResult.error.code);
  return;
}

// Distribute shares to authorities...

// Later: reconstruct from 2 authorities (meets threshold)
const reconstructResult = await reconstructFlightData(shares, splitResult.value.manifest);
if (reconstructResult.ok) {
  const original = reconstructResult.value;
  console.log('Reconstructed', original.length, 'bytes');
}

Use Cases

Four industries where split custody of flight data unlocks safety and trust.

Error Handling & Recovery

Flightsplit uses a discriminated union (Result<T, E>) for all operations. Errors are never thrown.

Design Philosophy

All sync and async functions return a Result type: { ok: true, value: T } | { ok: false, error: E }. This prevents unhandled exceptions and forces callers to reason about failure modes. Error codes are strings (e.g., 'HMAC_FAILURE'), paired with a human-readable message.

Failure Scenarios & Recovery

1. Configuration Validation. At entry to splitFlightData, config is validated: at least 2 authorities, 2 ≤ threshold ≤ N, chunk size > 0. If invalid, error is returned immediately without processing data.
2. Empty Data. If flightData.data.length === 0, return EMPTY_DATA error. This catches programmer errors early.
3. Chunk Alignment. During reconstruction, each chunk must have matching indices across all provided shares. If any share has a different chunkIndex, return CHUNK_MISMATCH.
4. HMAC Verification. Before XorIDA reconstruction, verify HMAC of padded chunk. If signature does not match, return HMAC_FAILURE and reject the share. This prevents tampered data from being reconstructed.
5. Threshold Validation. If the number of shares provided for a chunk is less than the configured threshold, return INSUFFICIENT_SHARES.
6. Reconstruction Failure. If XorIDA reconstruction produces invalid output (e.g., crypto library error), return RECONSTRUCTION_FAILED.

Performance & Benchmarks

Sub-millisecond split and reconstruct. Scales to gigabyte recordings.

Throughput by Payload Size

Key Insights

Sub-millisecond for typical chunks. A 1 MB FDR chunk (default) splits in ~1.8 ms on modern hardware. A 500 MB recording chunks into 500 segments, total time ~900 ms. Acceptable for post-accident workflows.
Throughput scales linearly. HMAC and XorIDA both operate at O(n) time relative to payload size. No quadratic penalties.
Chunk size tuning. Default 1 MB balances memory usage and chunking overhead. Networks with high latency may prefer larger chunks (e.g., 10 MB) to reduce round-trips during distribution.

Deployment & Integration

Node.js, browser, Deno, Bun. Works wherever Web Crypto API is available.

Package Installation

# npm
npm install @private.me/flightsplit

# pnpm
pnpm add @private.me/flightsplit

# yarn
yarn add @private.me/flightsplit

Runtime Requirements

Integration Patterns

Standalone Node.js (Post-Incident)

// recovery.mts
import { readFileSync } from 'fs';
import { splitFlightData } from '@private.me/flightsplit';

// Read binary FDR from recovered aircraft
const fdnData = readFileSync('/mnt/fdr/flight_data.bin');

const flightData = {
  flightId: 'UAL1234',
  aircraftId: 'N12345',
  recorderType: 'FDR',
  data: fdnData,
  recordedAt: new Date().toISOString(),
};

const result = await splitFlightData(flightData, config);
if (result.ok) {
  console.log('Manifest ID:', result.value.manifest.id);
  // Send shares to authorities via secure transport
}

Server-Side Evidence Store

import express from 'express';
import { reconstructFlightData } from '@private.me/flightsplit';

const app = express();

// POST /api/reconstruction — authorities provide shares
app.post('/api/reconstruction', async (req, res) => {
  const { shares, manifest } = req.body;
  const result = await reconstructFlightData(shares, manifest);
  if (result.ok) {
    res.send(result.value); // binary FDR/CVR data
  } else {
    res.status(400).json({ error: result.error.code });
  }
});

Security Properties

Information-theoretic confidentiality combined with cryptographic integrity.

Confidentiality: K-1 Shares = Zero Information

XorIDA operates over GF(2). An adversary holding K-1 shares (one fewer than threshold) cannot compute, guess, or correlate any bits of the original message. This is information-theoretic — it does not depend on computational hardness. Even an infinitely powerful adversary with K-1 shares learns nothing.

Integrity: HMAC-SHA256 Before Reconstruction

Every share includes an HMAC-SHA256 computed over the padded chunk. During reconstruction, HMAC verification must succeed before XorIDA begins. A single corrupted or tampered share is rejected immediately. This is unconditional — no collision resistance assumption. If HMAC fails, the share is discarded.

No Random Biases

All randomness is sourced from crypto.getRandomValues(), the Web Crypto API's CSPRNG. Never Math.random(). This ensures uniform share distribution.

Threat Model

Honest Majority Assumption

Flightsplit requires at least K of N authorities to cooperate for reconstruction. If K authorities are dishonest, they can collude to forge shares. For maximum security, set K = N (all must agree). For fault tolerance, set K < N, accepting that any K authorities are trusted not to collude against the remaining N-K.

Standards & Compliance

Alignment with aviation, cryptography, and data protection standards.

Aviation Regulations

ICAO Annex 13 — Aircraft Accident and Incident Investigation. Requires preservation of evidence and cooperation among States. Flightsplit's multi-authority split aligns with these principles by distributing custody and preventing single-point suppression.
NTSB Part 830 — Rules of Conduct and Organization. Requires that "all evidence be handled with care to ensure preservation." Flightsplit adds cryptographic assurance of preservation.
EU Regulation 996/2010 — Aircraft Accident Investigation. Requires "appropriate investigation methodologies" and "accident prevention." Multi-authority custody supports confidence in investigation outcome.

Cryptography Standards

FIPS 180-4 (SHA-256). HMAC uses SHA-256 from the Federal Information Processing Standards. Web Crypto API implements FIPS-approved algorithms.
XorIDA (GF(2) threshold sharing). Proprietary PRIVATE.ME algorithm, information-theoretically secure, no standard body approval required. Patent-protected.

Data Protection

GDPR, Annex 13 Safeguards. Distributed custody across independent authorities, combined with encryption and integrity checking, provides high assurance of data protection and audit trails.
EU Digital Resilience Act (NIS2). Critical infrastructure (aviation) must implement "advanced cryptography" and "multi-party controls." Flightsplit meets both requirements.

Alternatives & Comparison

How Flightsplit compares to other split-custody and evidence preservation approaches.

Replicated Custody (e.g., Multiple Backups)

Shamir's Secret Sharing (Alternative)

Shamir's Secret Sharing (SSS) over prime fields is another K-of-N scheme. It offers similar information-theoretic security to XorIDA. However, SSS is 500–2000x slower than XorIDA over GF(2) due to polynomial arithmetic over large primes. For gigabyte flight recordings, Shamir's becomes impractical. Flightsplit uses XorIDA specifically for speed and simplicity.

Symmetric Encryption + Key Escrow

Encrypt flight data with a master key, then split the master key via Shamir/XorIDA among authorities. Advantages: simple, uses industry-standard encryption (AES-256). Disadvantages: requires secure key escrow infrastructure, adds cryptographic complexity, and the escrow itself becomes a target. Flightsplit achieves the same goal (distributed custody) by splitting the data directly, avoiding key management entirely.

Blockchain / Distributed Ledger

Some have proposed flight data on blockchain for immutability. Disadvantages: blockchains are slow (seconds per block), do not provide confidentiality (all validators see the data), and require external consensus rules. Flightsplit is orders of magnitude faster and provides information-theoretic confidentiality. Blockchains are better suited to audit logs (who accessed the data, when), not the flight data itself.

Honest Limitations

Flightsplit is powerful. It is not a silver bullet.

Honest Majority Required

If K authorities (the threshold) collude, they can reconstruct and falsify data. Flightsplit assumes at least K authorities are honest. In practice, aviation authorities are politically independent and have reputational incentives not to collude. But the assumption is not cryptographic — it is institutional. Choose K conservatively (e.g., 3-of-3 for maximum caution, 2-of-3 if fault tolerance is critical).

No Retroactive Immutability

Once data is split and distributed, it is hard to alter (HMAC prevents tampering per chunk). But if an authority modifies its shares before distribution (before others see them), the modification is not detectible until reconstruction. Flightsplit assumes shares are stored with access logs and chain-of-custody records.

Network & Availability

Reconstruction requires the threshold number of authorities to cooperate and deliver shares. If authorities are offline, disconnected, or politically uncooperative, reconstruction may not be possible. This is a feature (distributed custody) and a limitation (requires quorum).

Large Data is Chunked

Flightsplit chunks large recordings to manage memory. If an authority loses one chunk, the entire recording cannot be reconstructed (individual chunks are not independently sufficient). For true resilience to partial loss, use a lower threshold (e.g., 2-of-3 per chunk) and accept the need to collect shares from different authorities for different chunks.

Cryptography is Necessary, Not Sufficient

Flightsplit protects data confidentiality and integrity. It does not protect against organizational conflicts of interest, political pressure, or misinterpretation of data. Even with perfect cryptography, human investigators can bias the story they tell from flight data.