Technical Whitepaper  ·  Open Publication

ZeroHawk

Confidential messaging with cryptographically verifiable expiry and a tamper-evident record — built so that the organisation running it cannot read what passes through it, and so that every claim in this document can be checked rather than believed.

Version
1.0 — October 2026
Status
Draft for review
Classification
Unclassified
Implementation
Working, adversarially tested
Certification
Not yet certified
01

Summary

Abstract

ZeroHawk encrypts a message to named holders, stores it on a server that cannot decrypt it, and destroys the decryption key at a set time. The ciphertext is deliberately kept after expiry, because keeping it is what makes the guarantee demonstrable: the bytes remain, and no one — including whoever operates the server, including whoever seizes it — can read them.

What survives expiry is a content-free proof: that a dispatch existed, who sent it, to whom, when, and that it was destroyed on schedule. Confidentiality and accountability are usually traded against each other. Here they are separated, so a deployment can have both.

The system is built in Africa, for institutions that have good reason not to assume their communications infrastructure is theirs alone. It is designed to be operated by the customer, not by the vendor.

02

Why this is needed

Problem

In January 2018, Le Monde reported that the African Union's headquarters in Addis Ababa — built and largely equipped with Chinese funding — had been transmitting data to servers in Shanghai every night between roughly midnight and 2am, for five years. The pattern was noticed by an AU computer scientist in January 2017. Listening devices were subsequently reported found in the building. China and Huawei denied the allegations.[1][2]

Whatever the final truth of that episode, it established the operating assumption under which African institutions now work: the infrastructure carrying your communications may not be yours, and the question of who else is reading may not be answerable.

The threat is also internal. The Pegasus disclosures implicated Morocco, Rwanda and Togo as clients of commercial spyware, with target lists running into the thousands and including heads of state, prime ministers, journalists and activists — in several cases, a government's own citizens and officials.[3][4][5]

Two conclusions follow, and they shape the entire design:

  • A system whose operator can read the traffic is not a solution, it is a relocation of the problem. If the guarantee depends on trusting whoever runs the server, it is a policy, and policies change with governments.
  • Endpoints get compromised, so exposure must be bounded and measurable. Pegasus does not break encryption. It reads the screen. Any honest system has to be designed around that rather than pretend otherwise.
03

What it guarantees, and what it does not

Claims

Every guarantee below is paired with its limit. This is not modesty. In secure communications the common failure is not weak cryptography but a claim that outruns it, relied on by someone whose safety depended on the difference.

Guarantee 01

The server cannot read dispatches. Not by policy — it holds no private key at all. Compromising it yields ciphertext, wrapped keys and metadata, and no way to read any of it.

Limit

It still sees who is corresponding with whom, and when. For government traffic that metadata is often as sensitive as content, and protecting it is a separate problem this system does not claim to solve.

Guarantee 02

After expiry, content is unrecoverable. Unreadable by anyone who did not already hold a key — including the operator, and including a node that quietly retained every byte.

Limit

It cannot stop a recipient who opened it beforehand from keeping what they read — a screenshot, a photograph, a memory. Signal and Snapchat share this limit. "Self-destructing" must never be said without it.

Guarantee 03

Tampering with the record is detectable by someone other than the operator. An append-only hash chain, with its head published to an external notary.

Limit

Detectable, not impossible. Anyone with root on the machine can rewrite its storage; what they cannot do is make the rewritten history agree with what was already published elsewhere.

Guarantee 04

After a device is lost, exposure is enumerable. The system reports precisely which dispatches that holder could have read, and which remain readable right now.

Limit

It cannot prove a seized device did not read something. A compromised device files no reports, so the assessment counts key material released to it — the conservative measure, deliberately.

Guarantee 05

Keys can live in hardware that will not surrender them. A key held in a Secure Enclave can be used for decryption and cannot be copied out of the chip.

Limit

It does not survive a compromised endpoint. Malware on an unlocked device reads what its holder reads. Hardware bounds the damage to the window of live access; it does not prevent it.

Stated plainly

This system is not certified. It has not completed FIPS 140-3 or Common Criteria evaluation. Section 08 sets out what that would require and in what order. Any claim of certification before a certificate exists would be false.

04

Architecture

Technical

4.1Expiry destroys the key, not the data

Deleting data is a policy promise. It fails the moment one node quietly keeps a copy — and in this threat model, that node is the adversary. Destroying the key is a mathematical promise: it holds even against the node that cheated, because ciphertext without a key is noise.

So the payload key is the only thing that must die. The system deliberately leaves the ciphertext in place after expiry. An operator can show the bytes are still on disk, unchanged and unreadable, which is a demonstration rather than an assurance.

A blockchain cannot forget

This is why no payload is ever written to a chain. Anything placed on a distributed ledger is replicated permanently; worse, publishing ciphertext hands an adversary a durable archive to decrypt retroactively once a key is recovered — precisely backwards for an anti-surveillance tool. A chain is used here only as a notary for hashes, which is the one job it does well.

4.2The server is excluded by construction

Private keys exist only on holder devices. The server stores public keys, ciphertext and wrapped key material — and wrapped key material is itself encrypted to a holder's public key, so releasing it costs nothing. When a holder asks for a dispatch, the server hands over a sealed envelope and the device decrypts it.

SENDER DEVICE            NODE                        HOLDER DEVICE
                         (cannot decrypt)            (holds the private key)

 seal ──────────────►   ciphertext
                        wrapped keys  ──envelope──►  decrypt here
                        metadata                     │
                        hash chain    ◄──reads the───┘
                             │          chain records
                        external          the release
                        anchor ──────►  notary
Figure 1 — Key material never reaches the node

One consequence is reported honestly rather than hidden: the node can no longer witness a decryption. It knows only that it released the material. Damage assessment therefore counts releases, not self-reported reads — a seized device files no reports.

4.3Hardware custody

A software keystore can be copied. Malware lifts the key file once and decrypts a captured archive offline, indefinitely, needing no further access to anything. A key generated inside an Apple Secure Enclave or Android StrongBox cannot leave the chip: software may ask the chip to perform a key agreement, and gets nothing it can take away.

That converts an unbounded compromise into one bounded by the window of live access — which is also what makes short expiry worth anything.

Both chips implement NIST P-256 and will not touch X25519. That constraint turns out to be fortunate; see section 08.

4.4Dual control

The payload key can be split into two shares, each wrapped to a different custodian, so no single holder can open the dispatch. The military two-person rule and a bank's four-eyes authorisation are the same mechanism under two names — which is why one engine serves both markets without a second design.

Shares are combined on a custodian's device. The server never sees one, so it cannot assemble the key even when both custodians act.

4.5A record that outlives the content

Every event — sealed, released, opened, refused, destroyed — is written to an append-only log in which each entry commits to its predecessor. Three layers defend it, each against a different adversary:

LayerDefeatsDoes not defeat
Database triggersCasual edits, ad-hoc toolingAnyone who can drop the triggers
Hash chainEditing or removing any entryA rebuild of the entire history
External anchorWhoever controls the machineNothing within the system's reach

Only the third constrains the operator, which is why the system reports its integrity as unverified until an anchor has been published — the honest default rather than the flattering one.

The record is content-free: a commitment, never the message. So it remains publishable to a notary, and remains meaningful after the content is gone.

4.6Cryptographic agility

The sealed header carries a format version and a named cipher suite. Without that, the first change to the format would make every archived dispatch unopenable. A post-quantum hybrid suite is reserved in the registry now, so that migration is additive later.

This matters more for a government archive than for most systems: harvest-now-decrypt-later is a real adversary behaviour. Traffic copied today can be stored until the mathematics catches up. Crypto-shredding is a genuine defence — a key destroyed today cannot be recovered by any future machine — but only for dispatches that have actually expired.

4.7Algorithms

OperationAlgorithmFIPS-approved
Content encryptionAES-256-GCMYes
Key agreementECDH P-256Yes
Key agreement (alt)X25519No
Key derivationHKDF-SHA-256Yes
Commitments, chainSHA-256Yes
Post-quantum (reserved)X25519 + ML-KEM-768Hybrid

Nothing here is invented. Every primitive is published, standardised and widely implemented — which is deliberate, and the subject of the next section.

05

What is actually differentiated

Position
Not a first

Secure communications for African governments is not a new category, and this document does not claim to open one. Pfortner has supplied sovereign secure communications from South Africa since 2008; COMSEC is owned by the South African state through its National Intelligence Agency; several foreign vendors sell into the continent.[6][7] A claim of being first would be checked, and would fail.

What is unusual is narrower, and defensible:

  • Expiry that is proven rather than promised. Most systems delete data and ask you to believe it. Here the ciphertext is kept on purpose so that its unreadability can be demonstrated — in a browser, in twenty seconds, in front of the person who needs convincing.
  • A record that survives the content. After destruction the system still proves a dispatch existed, its sender, its recipients, its classification and its destruction time, without revealing a byte of it. Confidentiality and non-repudiation usually trade off; here they are separated.
  • Operator powerlessness that can be checked live. The server has no private key. This is not a policy statement in a contract — it is a property an evaluator can test on your own hardware.
  • Damage assessment as a product feature. After a device is lost, the answer is a bounded list with timestamps, not "assume everything is burned".
  • Published adversarial testing, including what it fails. The repository ships an attack suite that reports the system's own outstanding weaknesses. A vendor documenting the attacks its product does not survive is making a credibility claim that is cheap to verify and expensive to imitate.
  • Sovereign operation. The customer holds the root of trust and operates the notary. The vendor is not a party to the deployment's security.
On secrecy

The cryptography is deliberately standard and fully published. A product claiming a proprietary cipher is not evaluated and rejected — it is usually not evaluated at all. Security here rests on keys, which can be rotated, never on design secrecy, which cannot.

06

Use cases

Application

Operational orders Defence

Movement orders, tasking and situational reports carry almost all their value inside a short window. A four-hour expiry means a device captured the next day yields nothing, and the command record still proves what was ordered and when — which is exactly what an inquiry needs and exactly what a captured phone must not give up.

Release authorisation Defence

Dual control means no single officer — and no single compromised device — can unseal an authorisation. The two-person rule stops being a procedure people are trusted to follow and becomes a property of the cryptography.

Diplomatic correspondence Foreign affairs

Cables between a ministry and its missions, with expiry matched to the negotiation rather than kept forever by default. The permanent record proves a position was communicated on a date without preserving the text for a future leak.

Supervisory instructions and settlement authorisation Central banking

Four-eyes authorisation is the same mechanism as the two-person rule. Where a regulator must retain access, it is granted by naming the regulator as a recipient, visible in the record — so "who can read this" is always answerable by looking, and never by a hidden key held in reserve.

Witness handling and sealed evidence Justice, anti-corruption

Identities and testimony that must be provably transmitted, provably limited in circulation, and provably destroyed — while the chain of custody remains intact and independently verifiable. A prosecution can show an item existed and moved lawfully without the item itself remaining exposed.

Results transmission Electoral administration

Returns sent from constituency to centre, where the requirement is non-repudiation more than secrecy: proof of what was sent, by whom, when, and that it was not altered in transit or afterwards. The anchored chain is the part that matters here.

Patient records with retention limits Health

Referrals and results where retention is legally bounded. Expiry becomes a technical control that can be evidenced to a regulator, rather than a deletion policy that must be trusted.

Correspondence between states Regional bodies

For the African Union, ECOWAS or a bilateral channel, the hardest problem is not encryption but trust in the operator. A system where the operator provably cannot read traffic, and where the record is anchored where no single member controls it, is one that parties who do not fully trust each other can still share. Given the history in section 02, this is arguably the strongest application of all.

07

Verification

Evidence

Nothing in this document asks to be taken on trust. The implementation ships with suites that an evaluator runs themselves:

SuiteEstablishesChecks
proofThe cryptographic guarantees, granting the attacker the full retained archive and the operator's position32
interopThat two independent implementations agree, in different cryptographic APIs15
enclaveHardware custody against real silicon: key not exportable, agreement performed in-chip8
attackThe system under an adversary holding root on the node — 19 held, 1 outstanding finding reported20

The attack suite is the one worth reading first. It grants the attacker root, the complete ciphertext archive and the operator's own position, then reports every finding — including the outstanding one. A test suite that always passes is not evidence of anything.

08

Deployment and certification

Path

A common and expensive misunderstanding: you do not certify an application. You certify a cryptographic module, or you use one already certified. FIPS 140-3 validation is a property of the boundary performing the operations.

Two facts make the path shorter than it looks, and they converge:

  • X25519 is not approved for key agreement under FIPS. Curve25519 appears in SP 800-186, which misleads many implementers, but the X25519 scheme is not in SP 800-56A Rev 3. P-256 is approved — and P-256 is the only curve the Secure Enclave and StrongBox will hold. The hardware path and the procurement path require the same suite.
  • Apple's Secure Key Store is already FIPS 140-3 validated at Overall Level 2 with Physical Security Level 3.[8][9] Key generation, storage and agreement occur inside that validated boundary — a validation inherited rather than pursued, for the most sensitive operation in the product.

Recommended order, by lead time rather than appeal:

  1. Ask the national accreditation authority what it actually requires. It costs nothing, it is fast, and it may not be Common Criteria at all.
  2. Enable hardware-backed identities on provisioned devices.
  3. Move the server runtime onto a FIPS-capable cryptographic provider.
  4. Establish the customer-held root of trust and the external notary.
  5. Native device builds as the accredited endpoints; the browser console remains an operator and demonstration surface, never an accredited one.
  6. Post-quantum hybrid, once an audited implementation is available.
  7. Common Criteria last — never begin while the product is still changing, since an evaluation describes one frozen configuration.
09

Threat model

Scope
AdversaryOutcome
Network interceptionDefeated — transport carries ciphertext only; no trusted network is assumed
Server compromise, including rootDefeated for content — no private keys are present
Operator acting in bad faithContent protected; record tampering detectable via the external anchor
Disk imaging after expiryDefeated — key material is securely erased, ciphertext is noise
Device seized after expiryDefeated — nothing readable remains
Device seized while dispatches are liveBounded — hardware keys and short expiry limit the window; exposure enumerable
Compromised endpoint (implant, Pegasus-class)Not defeated — reads what the holder reads
Recipient who keeps what they readNot defeated — outside the reach of any such system
Traffic analysis of who contacts whomNot addressed

The two lines marked as not defeated are the honest boundary of the category, not of this implementation. Signal's cryptography has never been broken, and Signal users are still compromised — through their devices, not their ciphers. Any vendor claiming otherwise is selling something that does not exist.