Who should read this: Directors of Maintenance, safety managers, chief pilots, DOM/AE staff,
compliance officers, accountable executives, insurers, and engineers who need to understand the
architecture behind PlaneConnection’s audit defensibility. For step-by-step verification
procedures, see Verify Record Integrity. For technical
specifications, see the Record Integrity Anchors
Reference.
The Problem: Why Tamper-Evident Records Matter
Aviation regulatory records are the definitive evidence that an operator is compliant and an aircraft is airworthy. When an FAA inspector, insurance auditor, or accident investigator examines records, they need to trust that what they see is what was actually recorded — not a revised version. Several failure modes motivate tamper-evident design: Human error. A maintenance technician updates the wrong record, realizes the mistake, and corrects it — but the audit trail of the correction is not captured. From the outside, it looks like the record was changed without explanation. System error. A database migration, backup restoration, or software bug silently updates timestamps or field values. No one intends harm, but record accuracy is compromised. Fraud. In rare but documented cases, maintenance records have been falsified to conceal deferred work or extend inspection intervals. The consequences for air safety and operator liability are severe. Data migration. When operators move from one platform to another, records must transfer without loss. If the receiving system cannot verify that imported records match what was exported, the chain of custody is broken.The Regulatory Foundation
Six primary regulations drive the design:| Regulation | Requirement | How record integrity addresses it |
|---|---|---|
| 14 CFR 91.417 | Maintain maintenance records for the life of the aircraft. Records must accurately reflect all inspections, repairs, and alterations. | SHA-384 hash chains detect any modification to record content. External anchors prove records existed at the claimed time. |
| 14 CFR 43.9 | Maintenance records must include specific content (description of work, date, signature, certificate number). | Canonical serialization ensures all required fields are included in the hash. Missing fields produce a different hash. |
| 14 CFR 5.97 | SMS operators must maintain the integrity of safety data and safety information. | Cross-layer verification detects discrepancies between database records and external proofs. |
| 14 CFR 5.21 | Safety policy must include reporting systems with data integrity protections. | Safety reports, investigations, and CPAs are hash-chained and externally anchored at creation time. |
| 14 CFR 135.63 | Part 135 operators must maintain flight records including load manifests and dispatch releases. | Flight logs, weight & balance, and dispatch releases are protected by the same 5-layer integrity system. |
| AC 120-92D | SMS guidance recommends data integrity controls for safety records. | The 5-layer system exceeds AC 120-92D’s guidance by providing cryptographic proof, not just access controls. |
The Trust Model
PlaneConnection separates two distinct questions:- Has this record changed since it was saved? (local integrity)
- Did this record actually exist at the claimed time? (temporal proof)
The Five Layers
Why Five?
Multiple independent layers provide defense in depth — no single point of failure can compromise record integrity. The layers use complementary trust models (certificate authorities, proof-of-work, and programmable verification) so that records remain verifiable even if individual systems experience outages or deprecation.Layer 1: SHA-384 Record Hashing
Every regulatory record is hashed at the moment it is saved using SHA-384 via the Web Crypto API (zero external dependencies). SHA-384 was selected per the CNSA 2.0 mandate for cryptographic agility — it provides a 192-bit security level, above the 128-bit minimum recommended for long-term protection of sensitive data. The hash covers the record’s canonical content: field values sorted alphabetically, serialized as JSON, with undefined values omitted and null values preserved. This deterministic serialization means the same record always produces the same hash, regardless of the order in which fields were written to the database. Threat mitigated: Any modification to a record’s content — even a single character change in a technician note — produces a completely different hash. Verification immediately detects the alteration.Layer 2: Hash Chain (Per-Aircraft Linked List)
Each aircraft maintains its own hash chain where every record’s hash incorporates the previous record’s hash. This creates a tamper-evident linked list: altering any historical record invalidates not only that record’s hash but every subsequent hash in the chain. The chain is analogous to a tamper-evident seal on a physical document folder. The seal itself is not the document, but breaking the seal is visible evidence that someone opened the folder. Threat mitigated: An attacker who modifies a single historical record cannot simply recompute that record’s hash — they would need to recompute every subsequent hash in the chain. The chain break is visible to any auditor running a verification check.Layer 3: RFC 3161 Trusted Timestamping
Immediately after a record is saved, the system submits its hash (via a Merkle root) to three accredited Timestamping Authorities in parallel: DigiCert, Sectigo, and Apple. Each TSA signs a timestamp token that cryptographically binds the hash to a calendar time verified against the TSA’s trusted clock. RFC 3161 timestamps are accepted in legal and regulatory proceedings worldwide (including EU eIDAS and US federal courts). They are the fastest anchor layer, typically confirmed within seconds. Threat mitigated: An operator could theoretically delete all records and reconstruct a new chain backdated to the original dates. RFC 3161 timestamps prevent this because the TSA’s signature cannot be forged without access to the TSA’s private key. The token proves the hash existed at a specific time.Layer 4: OpenTimestamps (Bitcoin Anchoring)
The system batches record hashes into a Merkle tree and submits the root to the Bitcoin blockchain via the OpenTimestamps protocol. Bitcoin’s proof-of-work consensus makes it economically infeasible to rewrite blockchain history. An OpenTimestamps proof that a hash was anchored to block 850,000 (for example) provides independent confirmation that the record existed before that block was mined — a fact that requires no trust in PlaneConnection or any certificate authority. Threat mitigated: RFC 3161 relies on trusting the TSA (a certificate authority). OpenTimestamps provides an alternative trust model based on computational work rather than institutional trust. Even if all three TSAs were compromised, the Bitcoin anchor remains valid.OpenTimestamps anchoring is free and requires no account or API key. The protocol is open source,
and the calendar servers are operated by the community. This layer adds zero marginal cost to
PlaneConnection’s integrity system.
Layer 5: EVM Smart Contract Anchoring
The system publishes Merkle roots to a purpose-built smart contract on an EVM-compatible blockchain. This layer provides programmable verification — anyone with a blockchain client can query the contract to verify that a specific Merkle root was anchored at a specific time. The contract supports batch anchoring, allowing hundreds of records to be anchored in a single transaction at negligible cost. This is significant for operators with high record volumes — a busy Part 135 operation generating dozens of records per day can anchor them all efficiently. For contract addresses and technical details, see the Record Integrity Anchors Reference. Threat mitigated: EVM anchoring provides a third independent trust anchor (after TSA certificates and Bitcoin proof-of-work) based on blockchain consensus. It also enables future integration with emerging digital airworthiness frameworks that may require on-chain attestation.How Blockchain Anchoring Works
The term “blockchain anchoring” can be misleading — PlaneConnection does not store regulatory records on a blockchain. Instead, it stores a compact fingerprint (Merkle root) that represents a batch of records. Here is the precise sequence:When regulatory records are saved, each gets a SHA-384 hash that incorporates
the previous record’s hash (Layer 1 and 2).
Individual record hashes are combined into a binary Merkle tree. The root of
the tree is a single 48-byte value that represents all records in the batch.
The Merkle root is submitted in parallel to RFC 3161 TSAs, OpenTimestamps
calendar servers, and (optionally) the EVM RecordAnchor contract. Each layer
returns a proof or receipt.
The RFC 3161 token (DER bytes), OpenTimestamps proof file, and EVM transaction
hash are stored alongside the original records.
Part Passports and Back-to-Birth Traceability
Beyond individual record integrity, PlaneConnection maintains a part passport for each tracked component — a complete, hash-chained history from manufacture through every installation, inspection, repair, and removal. The part passport answers the question regulators and insurers increasingly ask: where has this component been, and what was done to it at every stage of its life? Under 14 CFR Part 45 and AC 20-62E, traceability to the component’s origin is required for certain life-limited parts. Back-to-birth traceability means:- The initial airworthiness certificate and manufacturer documentation are anchored in the passport at import time.
- Every maintenance action is cryptographically linked to the previous action.
- Transfers between aircraft are recorded and anchored.
- The passport travels with the component when it is sold or transferred to another operator.
What the System Cannot Guarantee
Tamper-evidence addresses integrity after a record is created. It does not guarantee that what was entered was accurate in the first place. If a technician enters incorrect data, that incorrect data is faithfully preserved and anchored. The system detects changes to records after they are saved; it does not validate the truth of the original content. This distinction matters for compliance. Record integrity is one element of a broader safety culture. Operators should maintain procedures for technical review of maintenance entries, not rely solely on cryptographic integrity checks.Design Decisions
Why SHA-384 instead of SHA-256?
Why SHA-384 instead of SHA-256?
SHA-384 provides a 192-bit security level compared to SHA-256’s 128-bit level. The CNSA 2.0
advisory recommends SHA-384 for data that needs to remain secure through the post-quantum
transition period. Since maintenance records are retained for the life of the aircraft
(potentially decades), the stronger algorithm provides margin against future cryptanalytic
advances. SHA-256 is supported for backward compatibility and for OpenTimestamps submission (which
requires exactly 32-byte digests).
Why three TSAs instead of one?
Why three TSAs instead of one?
A single TSA creates a single point of failure. If DigiCert’s timestamping service goes offline or
its certificate is revoked, records created during that period would lack RFC 3161 proof.
Submitting to three TSAs in parallel ensures at least one token is available even during outages.
The cost is negligible (requests are small and fast) and the redundancy is significant for records
that may be audited years later.
Why per-aircraft chains instead of a global chain?
Why per-aircraft chains instead of a global chain?
A global chain across all aircraft and workspaces would mean that verifying one aircraft’s records
requires downloading the entire chain — potentially millions of entries. Per-aircraft chains keep
verification focused and fast. A typical aircraft accumulates hundreds to low thousands of records
over its lifetime, which can be verified in seconds.
Why an EVM-compatible blockchain?
Why an EVM-compatible blockchain?
EVM-compatible networks provide programmable verification at low cost, enabling batch anchoring of
hundreds of records in a single transaction. The anchor contract is purpose-built for aviation
record anchoring and can be deployed across multiple EVM chains as needs evolve.
Why is EVM anchoring opt-in?
Why is EVM anchoring opt-in?
Most operators do not need on-chain attestation for day-to-day operations — RFC 3161 and
OpenTimestamps provide sufficient proof. EVM anchoring is enabled per-environment when operators
require blockchain-level attestation for high-value records or regulatory requirements.
How Verification Works in Practice
When an auditor or inspector requests evidence that a specific record has not been altered — whether a maintenance work order, safety report, flight log, or training record — the workflow in PlaneConnection produces a proof bundle: a PDF-format export containing the record’s content, its hash, the RFC 3161 timestamp token, the OpenTimestamps proof (once confirmed), and the EVM transaction reference if applicable. The auditor can verify this bundle using standard tools (OpenSSL for RFC 3161, the OpenTimestamps client, or any Polygon block explorer) without requiring access to PlaneConnection. This independence from the platform is a deliberate design goal. The value of external anchoring is precisely that it does not require the auditor to trust the operator’s own systems.Related
Verify Record Integrity
Step-by-step guide for running verification checks and exporting proof bundles.
Record Integrity Anchors Reference
Technical specifications for all five layers including contract ABI and TSA endpoints.
Flight Operations Data Model
How maintenance records relate to aircraft, trips, and the broader data model.
Tamper-Evident Aviation Records
Overview of tamper-evident records across all 19 protected record types.