TECHNICAL VERIFICATION GUIDE¶
Institutional Proof of Integrity | OmniSentient v1.1.0¶
1. Objective¶
This document provides institutional security architects with the protocols required to independently verify OmniSentient’s claims regarding Tamper-Evidence, Asymmetric Provenance, and Database Isolation.
2. Forensic Chaining (SHA-256)¶
Claim: Every incident record is cryptographically anchored in a forward-only hash chain.
Verification Protocol:
1. Query Data: Retrieve the incidents ledger via the Forensic Control Plane API or DB direct access.
2. Recalculate Hash: For any record $N$, recompute the SHA-256 hash using the following canonical payload:
UUID | org_id | event_code | detected_at | prev_hash
3. Verify Continuity: Confirm that row_hash of record $N$ matches the prev_hash of record $N+1$.
4. Test for Rupture: Modify any field in a historical record. Recompute the chain. The verification will fail at the first point of modification and all subsequent nodes.
3. Asymmetric Provenance (Ed25519)¶
Claim: Evidence exports are signed and provide non-repudiable proof of authenticity.
Verification Protocol:
1. Extraction: Obtain the forensic_export.csv and the embedded Canonical JSON Manifest.
2. Canonicalization: Ensure the manifest is serialized exactly as generated: sort_keys=True, separators=(",", ":"), ensure_ascii=True.
3. Signature Check: Using the platform’s published Public Key (provenance_public_key) and an Ed25519-compatible tool (e.g., OpenSSL or Python cryptography), verify the signature against the canonical manifest string.
4. Independent Audit: Verification can be performed entirely offline, ensuring authenticity without dependency on OmniSentient infrastructure.
4. Database Isolation (RLS Force)¶
Claim: Access boundaries are enforced at the database kernel, preventing cross-tenant leakage.
Verification Protocol:
1. Policy Audit: Review the PostgreSQL schema to confirm FORCE ROW LEVEL SECURITY is enabled for the incidents and incident_events tables.
2. RBAC Boundary Test: Authenticate as a user with the auditor role.
3. Mutation Probe: Attempt an INSERT, UPDATE, or DELETE operation on any forensic table. The database must return a permission violation, even if attempted via a direct DB connection bypassing the application layer.
5. Terminology & Standards¶
| Term | OS Standard | Definition |
|---|---|---|
| Tamper-Evident | Yes | Any modification to historical records causes a detectable cryptographic rupture. |
| Tamper-Impossible | No | Standard boundary; administrative superusers retain theoretical access to infrastructure. |
| Non-Repudiation | Yes | Proved via Ed25519 asymmetric signatures tied to the OmniSentient identity. |
| Append-Only | Yes | Primary evidence ledgers reject all UPDATE and DELETE operations at the kernel level. |
Technical Support: security@omnisentient.dev