Verification & updates
The public trust surface
This is where the material a ForensicsGuard deployment needs in order to verify itself is published: verification keys, the signing scheme, and the update-service contract. It is written for engineers and auditors, not for procurement.
Current status
The verification mechanisms described here are implemented in the platform and are what a deployment actually enforces. The public update service is not yet in operation — its contract is fixed and published below so that integrators can build against it, but no manifest is being served yet.
Until it is, software and intelligence updates are delivered out of band as part of a deployment. That is also the permanent path for isolated deployments, which are never expected to reach a public service.
Scheme
How signatures work
Everything the platform verifies uses the same primitive. Verification requires only a public key, so it works offline and without contacting us.
- Algorithm
- ECDSA over NIST P-256 (secp256r1) with SHA-256. The curve is checked, not assumed.
- Signature encoding
-
DER-encoded, never a raw
r‖spair. The textual encoding differs between document types and is specified per type rather than guessed. - Signed bytes
- A canonical JSON serialisation of the payload — keys sorted, no insignificant whitespace — so that what was signed is unambiguous and re-serialisation is byte-stable.
- Key identification
- Every signed document names the key that signed it, so verification does not depend on trying keys until one works, and key rotation does not require a flag day.
- Anti-rollback
- Signed documents carry a monotonic sequence number. A document that is not strictly newer than the last one accepted is refused — and recorded as a distinct outcome from an invalid signature, because a replayed genuine document and a forged one are different events.
- Order of operations
- Structure is validated before any content is acted on, and no field is treated as authoritative until the signature verifies.
Keys
Verification keys
Public verification keys are published here, as PEM-encoded SPKI, one file per key, named for the key identifier that signed documents refer to.
No key is published on this page yet. We would rather publish nothing than publish an anchor that later turns out to be the wrong one — a trust anchor that has to be retracted is worse than one that arrives late. Keys will appear here as each is generated under its final custody arrangement.
If you are evaluating or auditing a deployment and need to confirm a key now, request it directly at support@forensicsguard.org and verify the fingerprint through a second channel.
Private keys are never here
No release, licensing or intelligence private key exists on any Guardian, any Lab Station, any customer deployment, any installation medium, or on this website. This site distributes only already-signed artefacts and the public keys needed to check them. Signing happens elsewhere.
Verify out of band
When a key is published here, confirm its fingerprint through a channel that is not this website before you pin it. A trust anchor that is only ever confirmed by the same server that served it is not independently verified.
Document types
What gets signed
| Document | Describes | Verified by |
|---|---|---|
| Release integrity manifest | The software components of a release, each with a cryptographic hash, so a deployment can establish it is running what it should be | Guardian and Lab Station, against the vendor release key |
| Licence | The entitlement issued against a specific Guardian ID | The named Guardian, against the vendor licensing key |
| Intelligence manifest | The indicator sets and network-intelligence datasets available to a deployment, with a hash and version for each | Lab Station and Guardian, against the intelligence key |
| Sensor export | What a Mobile Sensor or Guardian observed, and under which engagement | The Lab Station, on ingest, before the material becomes case evidence |
Integrity state is reported honestly
A build carrying no release anchor cannot verify anything, and reports its integrity state as unknown — never as verified. This is deliberate: a system that reports success when it has not actually checked anything is worse than one that reports nothing at all.
Service contract
The update service, when it exists
The client side is already written against this contract, so it is published here as a fixed target rather than as a proposal.
- Host
-
updates.forensicsguard.org— matched exactly. The client's allowlist does not accept subdomains, suffixes, or a path on another host, so the service cannot be relocated onto the main site without a client change. - Transport
- HTTPS only, with certificate validation that cannot be disabled.
- Manifest endpoint
-
GET /v1/manifest— no query parameters, no request body. Supports conditional requests so an unchanged manifest costs nothing to re-check. - Package endpoint
-
GET /v1/packages/{package_id}— serves only material that may lawfully be redistributed. Anything else returns an explicit error naming the vendor host, and deliberately not a redirect, so that following aLocationheader can never carry a client across a licensing boundary. - Sequence durability
- The service must never decrease, reuse or reset the manifest sequence number, including across a rebuild or a change of signing key. Losing that counter is more damaging than losing the signing key: every deployed client would refuse every subsequent manifest.
Independence
This service is an enhancement, never a dependency
A forensic platform must not stop working because a website is unreachable. The separation is deliberate and is part of the architecture.
- Evidence integrity does not depend on this site Hashing, sealing and provenance are local operations. They neither call this service nor require it to be reachable.
- Local case operation does not depend on this site Collection, detection, correlation, analysis and reporting all run without it.
- Verification does not depend on this site Once a public key is held by a deployment, signature checking is local. The service distributes signed documents; it is not consulted to decide whether one is valid.
- Out-of-band delivery is fully supported Isolated deployments receive updates and intelligence as files. This is a first-class path, not a workaround.