The security of user data is given the highest priority in MOSIP. Data is protected in flight and rest using strong cryptographic techniques. All operations on decrypted data are done in memory.
Various flows with encryption are illustrated below. Refer to Keys for all references of the type 'Kx' and 'KPx'.
Biometrics are signed by the private key of the device provider (PK2). The signature is verified by the Registration Client.
Registration Client signs the packet using the TPM key of the machine (K10) and encrypts the packet using MOSIP public key specific to (the registration centre, machine id) combination (K11).
Registration processor stores packets created in (2) "as is" in Object Store.
ID Repository encrypts biometrics, demographics and documents and stores them in Object Store. (K7.1,K7.2,K7.3)
The UINs are hashed, encrypted and stored in uin the table of mosip_idrepo DB. (K7.4)
Biometrics are shared and encrypted with the ABIS partner's key (PK1).
Registration processor stores encrypted demographic data in mosip_regprc DB. (K11)
Data shared with all partners like ABIS, Print, Adjudication, IDA etc. is encrypted using partners' public key. Note that IDA is also a partner, however, a special partner in the sense that data is additionally zero-knowledge encrypted before sending to IDA (see the section below).
The ID Authentication module (IDA) is an independent module and may be hosted by several providers. IDA hosts all the biometric templates and demographic data. Unique additional protection is provided here to make sure that mass decryption of user data is very difficult to achieve. The data can only be decrypted if the user's UIN is provided. Here is the encryption scheme:
Generate master symmetric encryption key K9.
Generate a 10,000 symmetric keys pool (ZKn). Encrypt each ZKn with K9 and store it in DB. (K12)
Randomly select one key from ZKn, and decrypt using K9.
Derive new key ZKn' = ZKn + UIN/VID/APPID.
Encrypt biometric templates and demographics.
BIO = encrypt(bio/demo with ZKn').
Encrypt ZKn (this is done to share ZKn with IDA).
ZKn-IDA = encrypt(ZKn with K22)
Share the following with IDA:
ZKn-IDA
BIO
Random index (0 - 9999)
SHA-256 hash of UIN/VID/APPID
Share data in step 7 via standard Datashare encryption (which encrypts entire data with PK8).
Generate master symmetric encryption key K18.
Decrypt data in Step 8 above using PK8.
Decrypt ZKn-IDA with K22 to get ZKn.
Encrypt ZKn with K18 and store it at a random index.
Bio-data is stored as is.
L1 devices contain FTM to encrypt (DE1, K21) and sign (FK1) biometrics at the source and send them to the authentication client.
The authentication client further encrypts the auth request with IDA-PARTNER public key.
IDA decrypts zero-knowledge data as given in Step 4 and then performs a demographic and/or biometric authentication.
The match result is returned to Auth client. In the case of KYC, the KYC attributes are encrypted with the Partner's public key (as in Datashare).
MOSIP's fundamental architecture and design incorporate the highest levels of privacy and security.
Key security features:
Encryption of data in-flight or rest. (See Data Protection)
Integration with trusted applications only.
Fraud avoidance - association of authentication only with specific transactions.
Misuse prevention - user can lock or unlock their authentication.
Virtual ID and Tokens to prevent identity theft.
All data sent out of MOSIP will be digitally signed.
All incoming data will be signed by the respective entity.
Any data sent to a relying party will be encrypted.
Protection against internal attacks with every record in DB protected with integrity.
Centralized key management.
All API's are protected with OAUTH 2.0.
Key privacy features:
Minimal data with selective disclosure on a need-to-know basis.
Sensitive data protected (not stored or logged in clear form).
Consent support – the user decides who can receive what credentials & what attributes.
No search on the database (You can find a record only if you know the ID).
Clear segregation of Biometric & Demographic data.
De-centralised ID usage and data (cannot profile based on usage).
Users are not limited to one permenant ID - Virtual ID.
All relying party gets a privacy enabled tokens to prevent profiling across transactions. Permenant ID is never shared.
Supports Wallet based decentralized ID issuance and usage.
Face data is not sent to ABIS for deduplication.
The right to privacy is a fundamental right in many contexts. Privacy protection or preservation can be ensured in an application by adopting a privacy friendly design stance.
Privacy takes many forms. From an identity system perspective, the confidentiality of identity information and anonymity when using the identity offers privacy.
MOSIP views the identity system as a custodian of the individual's data. This data has to be protected in order to protect the individual from privacy and security risks. Privacy protection measures include data protection, transparency, user control, confidentiality, selective disclosure, user anonymity and intrusion protection.
MOSIP addresses privacy design at four levels.
Functional privacy
Selective disclosure
Anonymization
Need to know
Encryption
Tokenization
Security
Trusted applications
Access control
User centricity
User control
Consent
Usability
Inclusion
Transparency
Openness
Verifiability
Governance
These design principles have resulted in features as well as development practices in MOSIP that enhance privacy protection. A typical example for a practice is how PII (Personally Identifiable Information) is dealt with when creating application or audit logs. An example of a feature is how our Datashare policies allow selective sharing of information.
