Security & Trust
Evidence that survives being questioned
Forensic findings get challenged. This page describes the mechanisms that let a ForensicsGuard finding withstand that — how an appliance proves which appliance it is, how software proves it has not been altered, and how evidence proves it has not changed since collection.
Security here comes from verification, not from secrecy.
Everything below is designed so that you can check it yourself, offline, without trusting our word for it and without contacting us. Published signatures and public keys are meant to be public. The private keys that produce them are held outside every deployed system.
01 — Identity
Guardian Hardware Identity
An appliance that cannot demonstrate which appliance it is cannot properly attribute the evidence it produces. Identity is derived from the hardware itself rather than configured onto it.
Guardian ID
Each Guardian carries a stable identifier bound to its own hardware identity. It is the name evidence is attributed to, the identity a licence is issued against, and the identity it presents when enrolled to a Lab Station.
Bound, not assigned
Because the identity derives from the hardware, it is not something that can be copied onto another appliance by moving a configuration file or an image between machines.
02 — Entitlement
Signed, hardware-bound licensing
Licensing is asymmetric. We sign; your deployment verifies. Verification requires only a public key, so it works in an isolated environment.
-
The Guardian presents its ID
The appliance reports the identity derived from its own hardware.
-
An entitlement is approved
The commercial entitlement for that specific appliance is agreed.
-
A licence is signed
A licence naming that Guardian ID is signed with the vendor licensing key, on a system that is not part of any customer deployment.
-
The Guardian verifies it
The appliance checks the signature against the public key it already holds, and checks that the licence names its own ID. A licence for a different Guardian does not operate it.
No licensing server, no call home
There is no online activation step and no requirement to remain reachable. The whole exchange can be conducted by moving files, which is what deployments in isolated environments actually need.
03 — Software integrity
Signed integrity manifests
A forensic appliance should be able to establish that it is running the software it is supposed to be running. That is a signed manifest of the software components, which the appliance verifies itself against.
- What the manifest describes
- The release it belongs to, and a cryptographic hash for each software component covered.
- How it is signed
- With the vendor release key, over a canonical serialisation of the manifest so the signed bytes are unambiguous. Verification is a public-key signature check.
- Rollback is refused
- Manifests carry a monotonic sequence number. A manifest that is not newer than the last one accepted is refused — and refused as a distinct, separately recorded outcome from an invalid signature, because a replayed genuine manifest and a forged one are different events.
- Structure before trust
- The manifest's structure is validated before any of its contents are acted on, and no field is read as authoritative until the signature verifies.
- Verification runs both ways
- A component that has been altered is a mismatch — and so is a component that is present but which the manifest does not declare. An added file cannot hide by not being on the list.
- Unknown is reported as unknown
- A build with no release anchor cannot verify anything, and reports its integrity state as unknown rather than as verified. The system is built not to overstate its own assurance.
Integrity is a reported fact, never a gate on your evidence
An appliance that is unlicensed, whose licence has expired, or which is reporting an integrity mismatch still exports and verifies every case it holds. We will not hold evidence hostage to a commercial or diagnostic state — and there is no mechanism by which we could. This is enforced by tests, because it is the kind of property that erodes quietly if it is only a policy.
04 — Evidence
Sealing, provenance and custody
The point of forensic integrity is to be able to answer, later and under challenge, three questions: where did this come from, has it changed, and who has touched it.
Hashed on collection
Evidence is hashed as it is taken in, establishing the state it was in at the moment of collection.
Sealed
The hash is bound into a sealed record, so subsequent alteration is detectable rather than merely unlikely.
Provenance attached
Which sensor produced it, when, and under which engagement travels with the material rather than living in a separate note.
Checked on ingest
Integrity material accompanies every export. The Lab Station checks it before the material becomes part of a case, refuses a failed signature check outright, and records the outcome against the evidence either way.
Bounded engagements
Case acquisition has a defined start and end. Evidence does not silently absorb activity from outside the authorised boundary.
Audited handling
Actions taken against case material are recorded, so the handling of evidence is itself reviewable.
05 — Key custody
Three authorities, deliberately not merged
Collapsing these into a single key would make the whole scheme weaker than it looks. They are kept apart on purpose.
| Authority | What it signs | Where the private key lives |
|---|---|---|
| Vendor | Software releases, integrity manifests, licences | Outside every deployed system — no Guardian, no Lab Station, no customer installation, no installation medium |
| Deployment | Intelligence and trust material within your own fleet | On your own Lab Station, under your control |
| Device | The Guardian's own attestations of identity | On the appliance, bound to its hardware |
What this means for you
The deployment authority is yours. The root of trust for your own fleet's intelligence is a key held on your Lab Station, not a key we hold on your behalf.
06 — Independent verification
Check it yourself
None of the above is worth much if you have to take our word for it. Verification is performed by you, offline, with standard cryptographic tooling — the keys and the contract are published so a deployment, or an auditor reviewing one, can confirm signatures without any interaction with us.
Signature scheme
- Algorithm
- ECDSA over NIST P-256 with SHA-256
- Curve enforcement
- The curve is checked, not assumed
- Hashing
- SHA-256
- Signed bytes
- A canonical serialisation, so what was signed is unambiguous
- Verification
- Offline, against a published public key
Frameworks
What the design is traced against
The architecture is documented against recognised evidence-handling and security frameworks — principally ISO/IEC 27037 on the identification, collection and preservation of digital evidence, alongside ISO/IEC 27001 and the NIST SP 800-53 and SP 800-171 control families.
The traceability is real and documented, and it is available to organisations evaluating the platform. It is what lets an assessor see which control a given design decision answers to.
This is traceability, not certification
Being designed against a framework and being certified under it are different things, and only one of them has happened. No independent evaluation or certification has been carried out against any of these frameworks, and none is claimed. If your process requires a certified product, we would rather you knew that now than after a procurement round.
The limits
What we are not claiming
A trust page is exactly the wrong place to overstate. To be explicit about the boundaries of everything written above:
- No certification is claimed
- ForensicsGuard does not hold, and does not claim, any security certification, accreditation or government approval. The platform is designed against recognised evidence-handling principles, but no independent evaluation has been carried out against them. Where a formal evaluation is required for your procurement, that is a conversation to have directly.
- No hardware security module in the Guardian
- The Guardian's identity is bound to its hardware and its signing key is protected by the operating system, but it is not held in a secure element or a TPM, and we do not describe it as one. Mobile Sensor evidence signing on iOS does use the device's secure element — that is the exception, and we name it as such.
- No guarantee of detection
- No forensic platform can guarantee it will detect a given capability. The platform is built to observe, correlate and preserve — not to promise completeness. Every finding is bounded by what was observable, where, and during which period.
- Integrity is not interpretation
- These mechanisms establish that evidence has not changed and came from where it says it did. What the evidence means remains a matter for qualified analysis by a person who is accountable for the conclusion.
- Authorisation is yours to establish
- The platform is built for authorised observation of environments and devices you have the lawful right to examine. It does not, and cannot, establish that authorisation on your behalf.
Bring your own security reviewer
We would rather your security team examined this properly than took a web page at face value. Technical documentation for review is available to organisations evaluating the platform.