The public key that signs the audit anchor
The CyberArmor platform audit trail is chained per client. Every 15 minutes in which the trail moves, an anchor summarizes all chains, is signed with Ed25519 and is published to separate storage, outside the database. This page is the second channel for the public key that checks that signature. The first channel is the versioned key registry in the platform repository.
Anchor signing keys
Field names in parentheses are the ones in the versioned registry, so both channels can be compared field by field.
| Field | sandbox |
|---|---|
| Key identifier (kid) | ancora-236d32c2977f62d1 |
| Environment (ambiente) | sandbox |
| Algorithm (alg) | Ed25519 |
| Public key in Base64 (chave_publica) | it2htylaKLJ/5Yxdp+7wzveoQGPUUNKb9P/SQBTXN6U= |
| Valid from (valida_desde) | |
| Revoked at (revogada_em) | Not revoked |
Only the sandbox key exists today. The production key will be added to this table when production starts. No key is ever removed: a retired key gets a revocation date, and an object signed after that date fails the check.
In the sandbox, the private key sits on the same server as the database. There the signature proves where the anchor came from, but it does not hold up against a compromised server.
How an auditor checks the anchor
The check runs on the auditor’s machine and needs no database access once the files are downloaded.
Compare the key across both channels
Check that the key on this page matches the one in the versioned key registry (docs/auditoria/chaves-da-ancora.json). If the two channels show different keys, stop and treat it as an incident.
Download the published anchor copy
The platform operator hands over a read-only credential for the anchor storage, or downloads the files in your presence. Download from the first anchor onward and do not open the files in an editor that reformats JSON: one extra space fails the check.
Run the verifier
The verifier is a short Python script whose only dependency is the cryptography package. For each anchor it checks shape, file name, signature, hash and chaining to the previous one, and exits with 0 when everything matches.
Compare with the database
Ask the DBA, in front of you, for the hash of the latest anchor stored in the database and pass that value to the verifier. This compares the external copy with what the database says today.
The platform repository is private. The verifier and the written procedure, with the failure codes and what to do for each, are delivered to auditors on request by email to dpo@cyberarmor.com.br, with a subject starting with [SECURITY].
Limits of the check
The procedure delivered to auditors states these limits, and they apply here as well.
Window before publication
Someone holding database superuser rights and the anchor private key can forge what has not been published yet, within a window of up to 15 minutes, and anything after it. The check flags any rewrite of what was already published.
Events outside the chain
An event that never entered the chained trail does not appear in any anchor.
Inclusion of a specific client
The current anchor (version 1) summarizes all chains in a single root. This verifier version does not check the root against the database or the presence of a specific client in it.
Third party timestamp
The RFC 3161 timestamp is not yet checked by the current verifier version.