Zero-Knowledge Security Brief

POPS Notebook is a mobile-first operational reference tool deployed to UK Public Order and Public Safety officers. Unlike traditional police information systems that rely on IP allow-listing, VPN tunnels, or MDM certificate pinning, this platform compensates for the absence of those controls by implementing a Zero-Knowledge encryption architecture in which the server is mathematically incapable of decrypting stored officer data.

All sensitive payloads — officer profiles, command broadcasts, and operational planning data — are encrypted on the officer's device before transmission. The server stores only ciphertext. Even in a full database compromise, the attacker obtains only opaque encrypted blobs with no corresponding decryption keys.

The architecture rests on a single principle: the server never possesses a decryption key. Keys are derived on the client device from values that are either (a) never transmitted to the server in plaintext, or (b) generated ephemerally and confined to browser session storage.

Three distinct encryption domains operate independently:

• Officer Profiles — encrypted with a force-derived key, synced to cloud as ciphertext only.
• Command Broadcasts — encrypted with the same force-derived key, retrievable by all same-force officers.
• Operational Planning Data — encrypted with an ephemeral per-session key, never leaves the device.

When an officer saves their local profile (name, collar number, mobile, rank, specialisms), the payload is JSON-serialised and encrypted client-side using the force-derived AES-GCM key before being upserted to theEncryptedOfficerProfile entity.

The server receives and stores only the EncryptedBlob(base64 IV + ciphertext). The entity is partitioned by TargetForceHashwith database-level RLS ensuring that only officers whoseHomeForceHash matches can even retrieve the record — and even then, they can only decrypt it if their device derives the same PBKDF2 key.

// Client-side flow (encryptedProfileSync.js):
const payload = JSON.stringify({ officerName, collarNumber, ... });
const blob    = await encryptMessage(HomeForceHash, payload, ForceSalt);
// → Server stores: { TargetForceHash, OwnerUserId, EncryptedBlob: blob }
// Server CANNOT decrypt — it has no ForceSalt (only the hash), no HomeForceHash
// plaintext, and no derived AES key.

Force admins and broadcast operators compose messages that are encrypted on their device with the force-derived key before transmission. TheForceBroadcast entity stores only:

• TargetForceHash — determines which officers can retrieve the blob.
• EncryptedBlob — the AES-GCM ciphertext.
• SenderRole / SenderRank — server-verified identity (never client-supplied).
• CreatedAt — for 24-hour TTL enforcement.

When an officer retrieves broadcasts, the server returns only the encrypted blobs for their force hash. The officer's device derives the same PBKDF2 key (using theirHomeForceHash and the force'sForceSalt) and decrypts locally. Broadcasts older than 24 hours are automatically purged server-side on each list request.

The Ops Planning module uses a separate encryption domain with a key that never leaves the device. A 256-bit AES-GCM key is generated once per browser session and stored in sessionStorage(not localStorage).

This creates a two-domain split on the device:

• localStorage contains only ciphertext (operational data blobs). A malware scraper reading localStorage sees only encrypted blobs.
• sessionStorage holds the decryption key. It survives page refreshes within the same tab but is automatically wiped when the tab or browser is closed.

To decrypt operational data, an attacker must compromise both storage domains — localStorage for the ciphertext and sessionStorage for the key. This raises the bar significantly over storing plaintext in localStorage, which is the common pattern.

On account suspension, the application'spurgeAllLocalData() function wipes all pops_-prefixed keys fromboth localStorage and sessionStorage, destroying both the ciphertext and the key simultaneously.

Cross-constabulary data leakage is prevented at three layers:

• Database layer (RLS): The ForceLicenseentity enforces Row-Level Security matchingdata.ForceHash against the user'sHomeForceHash. A force admin can only read/update their own force's license — the database query itself excludes all other forces' records.
• Encryption layer: Each force's broadcasts and profiles are encrypted with a force-specific key. Even if a query returned cross-force data, decryption would fail because the officer's device derives a key for a different salt.
• Backend function layer: Server-side functions perform salted-hash comparison before returning or modifying data, providing a third independent check.

POPS Notebook is designed as a Zero-Trust Tactical Edge Module that extends your existing Microsoft 365, MDM, and enterprise IT estate into connectivity-denied operational environments. Rather than replacing these controls, the platform complements them — maintaining security posture independently of network-level infrastructure that cannot reach officers in the field.

The platform achieves this through the following complementary controls:

• Work email OTP verification: Officers must verify a legitimate .police.uk email domain against a whitelist of all 43+ UK territorial forces, with strict single-@ parsing to prevent domain spoofing.
• Per-force license quotas: Each force has a finite license pool. Seats are consumed server-side on successful OTP verification and the cap is enforced — an officer verifying against a full pool is refused, and seats are released on suspension or account deletion.
• Backend kill-switch: The IsSuspended flag is checked server-side on every API call. A suspended officer's token is invalidated and all local data is purged, regardless of device state.
• Zero-knowledge encryption: Even if an unauthorised device gains network access, the server returns only ciphertext. Without the correct PBKDF2-derived key (which requires the officer's HomeForceHash and the force's ForceSalt), the data is unintelligible.
• 6-month re-verification TTL: Officers must re-verify their work email every 6 months, ensuring stale access is pruned.
• Serverless CSV audit exports: All administrative actions, suspended access attempts, and Secure Stand-Down initiations and data retrievals are logged to the ForceAdminAudit table with per-force hash isolation. Force admins can export a comprehensive 12-month CSV audit report directly from the interface — no database access or IT ticket required.

Force-derived keys (for profiles and broadcasts) are derived on-demand from HomeForceHash +ForceSalt via PBKDF2. The derivedCryptoKey is held in JavaScript memory for the session and is non-extractable. It is never written to any persistent store.

Operational data keys are generated per browser session and stored insessionStorage as base64. They are wiped on tab close, on explicit logout, or on suspension detection.

Session termination: The auth context pollsIsSuspended every 5 minutes. On detection, the application immediately purges allpops_-prefixed data from localStorage and sessionStorage, clears the auth token, and hard-redirects to a suspension notice. Backend functions independently enforce the same check, so even a stale token cannot access data after suspension.

Public order deployments frequently occur in environments where cellular networks are saturated, deliberately jammed, or physically blocked. A spontaneous disorder incident at a city centre on a Saturday night can overwhelm local cell towers within minutes — leaving officers with no data connectivity whatsoever.

POPS Notebook is architected for this reality. Once the app is loaded, every operational tool functions entirely without network connectivity:

• Legislation & doctrine references — Public Order Act 2023 thresholds, NPCC tactical doctrine, and College of Policing APP are cached locally on first load.
• Deployment rosters & serial boards — Full hierarchical command structures, callsigns, and comms directories populated at briefing via QR scan, then available offline for the entire deployment.
• Tactical sketchpad — Freehand tactical diagrams and crowd movement sketches are saved locally, no upload required.
• NDM & Use of Force loggers — Decision logs and use-of-force records are captured offline and synced when connectivity is restored.
• Command broadcasts — Encrypted force broadcasts are cached on-device; the latest messages remain accessible even when the network drops.
• Decision Loggist module — Full CIAPOAR decision logging operates entirely on-device via IndexedDB, with QR-based transfer to force records systems when the duty ends.

This is a deliberate design choice, not a fallback. Officers operating in Code 1 kit in hostile crowd dynamics cannot afford a loading spinner. The infrastructure supports the full operational workflow — from initial briefing to post-incident debrief — in complete network isolation.

POPS Notebook is designed to make the Information Assurance team's job easier, not harder. The platform integrates with existing GRC workflows rather than creating additional burden:

• Serverless CSV audit exports: Force admins can export a comprehensive 12-month audit report covering user directory, license status, feature toggles, and admin actions — delivered as a CSV file directly from the ForceAdmin interface, no server access or database queries required.
• Per-force audit isolation: Audit logs are hash-partitioned by force, ensuring that IA teams see only their own force's data — no cross-force data leakage in exports or reports.
• Feature toggle governance: Force admins can enable or disable individual modules (Use of Force logger, NDM logger, sketchpad, ops planning, etc.) without engineering involvement, providing immediate control over the operational surface area.
• Configurable data lifecycle: The local data TTL and suspension polling interval are configurable per force, allowing IA teams to align the platform with their own data handling policies (e.g. 4-hour TTL for OFFICIAL-SENSITIVE deployments).
• Deployment PIN gate (soft control): A per-deployment session PIN deters casual access to a seized device in Faraday bag scenarios — three failed attempts trigger an automatic local data wipe, independent of network connectivity. It is a deterrent layer, not a cryptographic boundary; see Section 12.

During active deployments, officers may operate in environments where device seizure is a realistic threat. If an officer is detained and their device is placed in a Faraday bag or signal-blocking pouch, the backend suspension kill-switch becomes ineffective — the device cannot reach the server to receive suspension signals, and the configurable polling interval is irrelevant without network connectivity.

The Deployment PIN Gate provides an offline, device-local deterrent layer that does not depend on network reach:

• PIN setup: When a deployment is active, the officer sets a 4-digit session PIN. The PIN is never stored in plaintext — it is salted with a cryptographically random value and hashed using SHA-256. Only the salt and hash are persisted to localStorage.
• Inactivity and background lock: Any backgrounding during an active deployment locks the gate on resume, as does an offline or idle period longer than the per-force timeout (default 3 minutes via DutyPinTimeoutMinutes). The officer must re-enter their PIN to regain access to the deployment board.
• Burn protocol: Three failed PIN attempts trigger an immediate local data wipe — burnAll() purges all pops_-prefixed data from localStorage and sessionStorage, clears the auth token, and hard-redirects to login. All without any server-side signal.
• Offline resilience: The PIN hash, attempt counter, and timeout logic operate entirely on-device. No server call is needed to lock, verify, or burn.

This control is complementary to the backend kill-switch: the backend handles networked suspension scenarios (account suspended, force suspended, licence revoked), while the PIN gate handles offline seizure scenarios where the backend is unreachable. Together with zero-knowledge encryption and short data TTLs, they provide layered — not absolute — protection of operational data.