Security assessment

This page describes what DigiFIR protects, against whom, and the controls at each layer. Security reviews lists the findings of the reviews of each part and their outcomes. Data protection covers personal data.

What must be protected

Asset	Threat	Main answer
The integrity of case records: who filed, registered, seized, sealed or ordered what, and when	Forged, altered, backdated or deleted records, by an outsider or an insider of one institution	Every write is signed on the actor's own device, checked by the chaincode against a key registered on the ledger, and endorsed by peers of more than one institution. Nothing is deleted.
Personal data: narratives, complainants, victims, accused, statements, evidence	Disclosure to people with no right to read it	Private data collections per state, signed and audited reads, encryption of files on the device, no personal data in read views, events or logs
Evidence files	Substitution or tampering	Files hashed on the device; hashes on the ledger; two-party custody hops
Officials' authority	Someone acting as an officer or magistrate	Keys made in the phone's secure hardware and registered in person by a registrar; an app PIN; revocation effective at the next block
Availability of filing	Outages of outside systems	Adapters are asynchronous; apps keep encrypted offline outboxes

Trust model

The system is built so that no single party can rewrite the record on its own.

• The backend holds no person's key. If it were compromised it could delay or withhold actions, serve stale read views and read private values passing through it. It could not create, change or backdate a record, register an official, or decrypt evidence files. See System architecture.
• One institution cannot act alone. A case needs its state's police and the judiciary to endorse every change. An exhibit needs the forensic laboratories and its state's police. Channel-wide decisions need the judiciary and two of the other three founding members.
• Registrars cannot enrol themselves or create other registrars. Only the institution's MSP administrator can, and administrators sign system transactions offline with a smart card or HSM.
• Each institution can run its own verifier against its own peer and compare the ledger with the others.

Controls by layer

The phone

• Signing keys are ECDSA P-256 keys made in Android Keystore or StrongBox, or the iPhone Secure Enclave. They cannot be exported, and they sign only while the phone is unlocked and after the app PIN or fingerprint was given.
• A six-digit app PIN with auto-lock after 1, 5 or 15 minutes. Five wrong PINs sign the phone out; staff then enrol again in person, and new enrolments are held for a day.
• Data kept on the phone (drafts, the outbox, read caches, attachments) is encrypted and excluded from Google Drive and iCloud backups.
• Screenshots and screen recording are blocked in builds that run on the backend, and the app switcher shows the logo.
• App attestation (Play Integrity, App Attest, reCAPTCHA Enterprise on the web) before a session exists.
• "What you see is what you sign": every app shows what an action records before the sign button, and refuses text over a limit instead of cutting it. Invisible formatting characters are never signed.

Transport and API

• TLS 1.2 or later with HSTS. Mutual TLS on the internal ingress for operators. PostgreSQL with verify-full, Redis over TLS, and HTTPS or SMTPS for every channel that carries personal data out of the backend in the pilot.
• No passwords. Sessions open by signing a single-use challenge; access tokens last 15 minutes and are bound to the key and installation.
• Strict canonical JSON parsing on signed routes, OpenAPI schema validation of every request, and body limits enforced before parsing.
• Rate limits on every route class, charged before the body is read.
• CORS without credentials, a strict content security policy on HTML responses, and outbound calls that never follow redirects.

Backend

• Gateway, service, token-signing and vault keys in an HSM over PKCS#11 (FIPS 140-2 Level 3 in the pilot), on a separate token and PIN for each institution.
• Secrets only in Kubernetes secrets backed by an India-hosted KMS; none in images, logs, problems or metrics. Logs redact tokens, private payloads, OTPs and signatures.
• Key rotation: the token key every 30 days, webhook secrets every 90 days, service keys yearly.
• The container image refuses to start outside development unless every production guard is configured: no simulators, enforced attestation, no development keys.
• Every signed private read, download, refused action and admin change is written to a hash-chained audit log, exported nightly to write-once storage and the CERT-In log store.

Ledger and chaincode

• Gate 1 on every write: canonical bytes, a valid signature by a registered and active key, the right role and jurisdiction, a time window, the right submitting gateway and a single-use action ID.
• Gate 2: endorsement policies and key-level policies on each record, set when it is created; creation anchors stop an endorser from leaving out the owner.
• No deletes anywhere; erasure only through one audited function per chaincode, needing a court order or a statutory rule.
• Deterministic code enforced by seven static analysers; govulncheck in CI (no reachable vulnerability on Go 1.27.3).
• Strict decoding: older code refuses fields it does not know, so a rollback cannot silently drop a security field.

Network and infrastructure

• Every connection on the Fabric network uses mutual TLS, and each organisation has a separate TLS CA so a TLS key can never sign a transaction.
• The channel's governance rule names roles (admin, peer) so client keys cannot approve chaincode definitions; a checker with 61 rules verifies the live channel configuration.
• In Kubernetes: the restricted Pod Security profile, read-only root file systems, default-deny network policies with named egress, pinned image digests, admission policies, and the backend in a separate cluster from the Fabric nodes.
• An egress allow-list of every outside destination the backend may reach, through an SNI egress gateway.
• 44 monitoring alerts, including invalid transactions, endorsement refusals, certificate expiry and the integrity check's divergence alerts.

Residual risks

Risk	Status
Fabric CA root keys are generated in software by the Kubernetes operator	Open; a go-live blocker. CA keys must move into each institution's HSM.
Raft tolerates crashed orderers, not a dishonest operator of the ordering service	Accepted for the pilot; the configuration is prepared for Fabric 3.x SmartBFT once each institution runs its own orderer
A fingerprint added to a phone by someone who knows its screen lock can unlock the app	Documented; officers are advised to leave fingerprint unlock off if others know the phone's screen lock
Device signatures are attribution evidence, not IT Act electronic signatures	Documents that need a legal signature use Aadhaar eSign or a signature at the station
The HSM path is tested only with SoftHSM	A hardware HSM is needed for the pilot
No third-party security audit yet	An audit by a CERT-In-empanelled auditor is planned before go-live

Sources: digifir-backend docs/architecture/BACKEND.md section 15, DECISIONS.md ADR-07, ADR-09 and ADR-20, SECURITY_REVIEW.md, docs/PROJECT-STATUS.md; digifir-network docs/SECURITY_REVIEW.md, docs/EGRESS.md; digifir-chaincode docs/SPEC.md sections 1.7, 1.15 and 11.4; the apps' docs/app-lock.md and docs/SECURITY_REVIEW.md on the migration branch.