Counterfoil
Buying Counterfoil.
What you buy, where it runs, what leaves your network, what you keep if you stop, what is built today, and how to check it yourself before you write to us.
The terms
What you buy
An engagement, scoped in writing, and a licence to run Counterfoil for a year. You receive the software to run, not its source code. The checker that verifies what we deliver is public and free, so checking our work never needs our servers or our say-so.
Where it runs
Your choice, engagement by engagement, on your own machines or on ours against systems you authorise in writing. It has not yet run for a client, only on our own machines and in our lab.
What leaves your network
When it runs on your machines, nothing is sent to us. It connects to the hosts you authorise it to scan. For trusted time it sends a hash of each record, never the record, to DigiCert and FreeTSA, and one setting (COUNTERFOIL_TIME_SEAL=0) switches that off. A hash goes to the public Sigstore log only if you ask for it. When we run it from our machines, the proposal says what we collect, where it is kept and when it is deleted.
If you do not renew
The licence is yearly. If it lapses you stop running the software, and every receipt and evidence file you already hold stays checkable with the free checker, which needs no account and no contact with us.
Support
Written into each engagement’s proposal, with what it covers and for how long, so you know before you sign.
How it is scoped and quoted
You write to us, we agree the scope on a call, and you get a written proposal naming what we inspect, what access we need, how long it takes, what you receive, and what it costs. We do not publish prices.
What you receive
- An inventory of the cryptography in the code and hosts in scope, as a CycloneDX cryptographic bill of materials.
- Each finding ranked by how long its data or signatures must stay trusted against how long migrating takes.
- A migration plan in phases, hybrid first, with a way back at every phase.
- Every step sealed as a linked receipt, signed with Ed25519 and ML-DSA-65, with a TPM signature and trusted time when available.
- Fixes, when they are in scope, one at a time, each approved by a named person on your side, with a backup first and a way back, and each with its own receipt. Tested in our lab so far.
What is built today
Inventory from source code
Reads source as checked out. It recognises common libraries (OpenSSL, libsodium, PKCS #11, mbedTLS, PSA Crypto, wolfCrypt, AUTOSAR Csm) and lists what it does not.
Host scan
TLS and SSH settings of the hosts you authorise, read from the connection.
Exposure ranking and migration plan
From the inventory, with your own shelf-life and migration-time assumptions.
Sealed evidence
Linked receipts with two signatures, a TPM signature and trusted time, checkable offline and in a browser.
Your own policy and in-toto
Check evidence against a policy file you write, or receive it as signed in-toto links for your existing tooling.
Fixes
Approval, backup, apply and roll back, tested on nginx and OpenSSL hosts in our own lab, not yet on a client system.
Build output and running systems
The inventory reads source and connections. It does not read compiled binaries, linked libraries or what code loads at run time.
Key revocation list
The checker pins our keys and carries no revocation list. Publishing rotation and revocation is open work.
Independent review
No outside party has reviewed the checker or the format yet.
Client deployment
We have not yet deployed this for a client.
Check it yourself first
About ten minutes, on your own machine, before any call.
Download two files
The checker (one Python file) and a sample assessment of an open-source SSH library.
Run it
python verify_counterfoil.py sample-assessment.json, after pip install cryptography. It should print PASS for three linked steps.
Break it
Change any finding’s tier in the file and run it again. It fails and names the step you changed.
Remove it
Delete the two files. Nothing was installed beyond the cryptography package, and nothing was sent anywhere.
What the checker catches, and what it does not
A record is edited after sealing
Detected. Any change to any field fails the check.
Records are reordered or spliced
Detected. Each record names the one before it.
A chain is cut short
Detected. The chain must close onto its first record, and the seal covers the last.
A step is dropped from an evidence file
Detected. Every receipt carries the planned list of steps.
A whole receipt is deleted
Not detected by the receipt itself. Your own copies are what protect you.
A different history is signed with our key
Possible for whoever holds the key. Trusted time shows when each receipt existed, and a hash in the public Sigstore log, if you ask for one, makes a second version visible.
Our signing key is stolen
There is no revocation list. A receipt with trusted time shows it existed before the theft.
A malformed or hostile file
A plain failure with the reason, in every malformed case we test, among them text that is not JSON, a file that is not an object, records with fields missing, and the 59 named attacks in our public test vectors.
Whose key signed it
The checker requires our published keys by default, so a receipt signed by any other key fails.
Next
If it fits, write to us and say what you run. We can sign an NDA before you share anything.