Identity and access

DigiFIR uses two layers of identity. Fabric identities, issued as X.509 certificates by each organisation's Fabric CA, identify machines: peers, orderers, administrators and the backend's gateways. DigiFIR signing keys, registered on the ledger in the identity-registry chaincode, identify people and services, and only these keys carry authority over case records.

Drawing diagram

Fabric identities

Identity	Issued by	Used for
Peer and orderer	The organisation's Fabric CA (NodeOU peer or orderer)	Endorsing, ordering and gossip, over mutual TLS
MSP administrator (Admin)	The organisation's Fabric CA (NodeOU admin)	Channel configuration, chaincode approval, and the system functions of the chaincodes
Gateway	The organisation's Fabric CA, client certificate with digifir.role=GATEWAY	The backend submits transactions through it

The chaincodes accept a transaction only when its creator is a gateway identity of the right institution whose key is also registered and active in identity-registry (as gw:<id>). A gateway can therefore be disabled at once with key.revoke, without waiting for a certificate revocation list. Human role attributes in certificates are not used by any DigiFIR chaincode.

The gateway carries actions and has no authority of its own. Every function that changes a record demands the signature of a registered person or service, so a stolen gateway key can withhold transactions but cannot forge one.

System functions and the administrators' signing tool

A few functions set up the network itself: InitNetwork, AddInstitution, BootstrapRegistrar, AdminRevokeKey and OnboardState. Only an MSP administrator of the organisation concerned can submit them. The backend never holds an administrator's key. It prepares the transaction, and the administrator signs it offline with admin-sign, a tool in the network repository. The tool decodes the proposal and the endorsed transaction, shows what the signature would authorise, checks the channel, creator, chaincode, function, payload and endorsements against pinned MSP roots, and has a smart card or HSM sign a digest it computes itself.

Officials' keys

Every official (officer, magistrate, laboratory scientist, registrar) acts with an ECDSA P-256 key made on their own phone, in Android Keystore or StrongBox or the iPhone Secure Enclave. The private key never leaves the phone. Using it needs the app PIN or a fingerprint.

The key is registered on the ledger by a registrar of the official's institution after an in-person check (key.register). The record holds:

• the key ID: key: and the first 32 hex characters of the SHA-256 of the public key;
• the public key and algorithm (ES256);
• the official ID, institution, one to four roles, designation and jurisdiction;
• the flags dspOrAbove (may approve a preliminary enquiry) and expert329 (may seal a laboratory report);
• validity dates and status.

Status	Set by	Effect
ACTIVE	key.register	Valid between its validity dates
SUPERSEDED	A new registration that replaces it, after a transfer, promotion or new phone	Valid only for actions signed before it was replaced
REVOKED	key.revoke by a registrar, or AdminRevokeKey by an MSP administrator	Invalid from the next block

Revocation takes effect at once because every action reads the signer's key record. A transaction endorsed before the revocation but committed after it fails Fabric's read-conflict check.

An official's device key may also register a session-only key. A session key can sign only read requests, never an action that changes a record, so the phone does not need the hardware key for every list screen.

The SIM check

During enrolment the app sends one SMS from the official's registered SIM. The backend compares the sender with the roster. The result is shown to the registrar as a risk signal and never grants or refuses anything by itself. On later unlocks the app checks that the SIM is still in the phone and locks if it was removed.

Registrars

Each institution has its own registrars. A registrar's key is created only by the institution's MSP administrator (BootstrapRegistrar), with proof that the registrar holds the key. A registrar key never holds another role, and a registrar cannot enrol their own phone or make another registrar.

Registrars register and revoke officials' and services' keys, keep reference data (districts, stations, station areas, courts, laboratories) and propose on-ledger configuration changes. A configuration change needs approval from registrars of three institutions.

Citizens

A citizen has no Fabric identity and no registrar. Instead:

1. The citizen proves their identity once, through DigiLocker or Meri Pehchaan, or in person at a police station. Aadhaar is never required. In development and testing only simulated identities are used.
2. The citizen app makes a P-256 key in the phone's secure hardware. The portal uses a WebCrypto key that the browser cannot export.
3. A police KYC_ATTESTOR service registers the citizen's decentralised identifier (did.register) with two signatures: the attestor's, and the citizen's proof that they hold the key.

The DID is did:digifir: followed by 26 base32 characters derived from the citizen's first public key. It carries no identity data. The citizen signs as <did>#k1, <did>#k2 and so on, with up to 10 keys for several phones. The ledger records only the DID, the public keys, the verification method and an assurance level from 1 to 3:

Method	Highest assurance level
Aadhaar through a licensed route (AUA/KUA, or the department's own offline verification)	3
DigiLocker	2
Verification at a police station desk	1

No Aadhaar number, e-KYC data, name or phone number goes on the ledger. The backend keeps the verified attributes a complaint needs in its encrypted identity vault, under a keyed reference (an HMAC with an HSM-held key), never under the Aadhaar number or a hash of it.

How a signature is checked

Every chaincode function that changes a record runs the same check, called Gate 1, before doing anything else. Chaincode overview lists its twelve steps. In short, the chaincode resolves the signer's key in identity-registry, verifies the ES256 signature over the action's canonical bytes, checks the time window, the creator, replay, the private payload, the role and the jurisdiction, and only then applies the action's own rules.

Sources: digifir-chaincode docs/SPEC.md sections 1.7.4, 1.7.7, 2.1, 2.3, 2.4.1, 2.4.3 and 2.4.10; digifir-backend docs/architecture/DECISIONS.md ADR-07, ADR-08 and ADR-09; digifir-network README.md (identities, admin-sign).