Security
What protects the handover, and what it rests on.
Everything here is what the software actually does today. Where an assurance is missing, it says so on this page rather than in a footnote.
Where the boundary is
"No server" is easy to say and easy to abuse, so here is the precise version: file content never reaches us. For enterprise deployments, device enrolment and revocation do use our infrastructure. So do trusted timestamps when you switch them on: one receipt fingerprint, never the file, passes through to DigiCert.
Cryptography
Session
X25519 + HKDF
The two devices agree a key through the optical channel itself. Nothing is exchanged over a network, and the key exists only for that transfer.
Content
AES-256-GCM
The file is sealed before the first frame is displayed. A camera pointed at the wrong screen, or a photograph of it, yields ciphertext.
Evidence
Ed25519 / ES256
Dispatch and delivery are signed over a fixed byte layout, so a record cannot be re-interpreted later. The enterprise wire uses P-256 with canonical low-S signatures.
Two codes are derived from the session with separate labels: six digits and five drawn symbols. The operator compares them on both screens. That comparison is what defends against a screen or camera placed in the middle — and it only works if a person actually does it.
The evidence model
Dispatch record
The sender signs the content hash together with the work order, classification and target system.
Delivery receipt
The receiver verifies the content against the hash and signs that it arrived intact.
Approval chain
Optional. Produced, reviewed, released — each link signed over the previous one, so the order is provable and removing a link breaks the chain.
Audit ledger
Entries are hash-chained locally, so a deleted entry is visible as a gap.
Offline verification
An Apache-2.0 tool checks all of it without contacting us, with no account and no network.
Threat model
What each attack meets. The last two rows are outside what the software can defend, and the limits page explains why.
| Attack | What stops it |
|---|---|
| A photograph or recording of the sending screen | AES-256-GCM: the frames are ciphertext |
| A screen or camera placed between the two devices | The six digits and five symbols differ; the operator stops |
| Editing a dispatch or delivery record afterwards | Ed25519 signature no longer verifies |
| Swapping the file after delivery | Content hash no longer matches the signed record |
| Deleting an entry from the local audit log | The hash chain shows a gap |
| Operator skips the code comparison | Not defended — the protection depends on it |
| Malware already on either device | Not defended — no transfer tool can be |
Machine-checked protocol models
The three ways Kionel moves a file are modelled in ProVerif, a tool that searches for attacks by an adversary who controls every frame on the optical channel. Each model also runs with one assumption removed, and there the tool must find the attack — otherwise the model would not be measuring anything.
| Mode | File stays secret | Sender authenticated |
|---|---|---|
| Two-way, codes compared | Proved, including after both identity keys leak | Proved; receipts verified by an auditor are sound |
| Two-way, codes not compared | Attack found — this is why the comparison is required | Attack found |
| One-way, typed code | Proved while the code is unknown | Proved |
| One-way, receiver card installed over a trusted route | Proved | Proved |
| One-way card, long-term key leaks later | Not secret — no forward secrecy, as documented | Proved |
A symbolic model treats the cryptography as ideal and cannot count bits: it does not prove that the implementation is free of bugs, and it is not an audit. Download the models and rerun them: two-way, typed code, receiver card, assumptions and limits.
Current status — read this before procurement
| Assurance | Status |
|---|---|
| Symbolic protocol verification (ProVerif) | Published: 3 models, 6 checks, sanity variants included |
| Independent security audit of the implementation | Not completed |
| Published device matrix (speed, success rate on real hardware) | Not published |
| Hardware-backed device identity (TPM, StrongBox, App Attest) | Verifier implemented; production enrolment not shipped |
| Trusted timestamps (RFC 3161) | Optional on the receiving device: a DigiCert token attached to the receipt, verified in the browser and by the offline verifier against a pinned root |
| Formal certification (Common Criteria and similar) | None, and none claimed |
| Vulnerability disclosure channel | Published in security.txt |
If a procurement checklist requires a certified product, we are not it yet, and we would rather you learn that here than three meetings in.
Reporting a vulnerability
Write to the address published in security.txt. We do not run a bug bounty; we do answer.