Introduction & Background
The objective of this specification document is to establish the technical and compliance standards/ protocols that are necessary for a biometric device to be used in MOSIP solutions.
Target Audience
This is a biometric device specification document and aims to help the biometric device manufacturers, their developers, and their designers in building MOSIP-compliant devices. It is assumed that the readers are familiar with MOSIP registration and authentication services.
All devices that collect biometric data for MOSIP should operate within the specification of this document.
Revision History
Glossary of Terms
Device Provider - An entity that manufactures or imports the devices in their name. This entity should have legal rights to obtain an organization-level digital certificate from the respective authority in the country.
FTM Provider - An entity that manufactures or guarantees the trustworthiness of the foundational trust module. This can be the device provider as well.
Device - A hardware capable of capturing biometric information.
Device Specification
The MOSIP device specification provides compliance guidelines devices for that to work with MOSIP. The compliance is based on device capability, trust and communication protocols. A MOSIP-compliant device would follow the standards established in this document. It is expected that the devices are compliant with this specification and tested and validated. The details of each of these are outlined in the subsequent sections.
Device Capability
The MOSIP-compliant device is expected to perform the following,
Should have the ability to collect one or more biometric
Should have the ability to sign the captured biometric image or template.
Should have the ability to protect secret keys
Base Specifications for Devices
For details about biometric data specifications please view the page .
We recommend that countries look at ergonomics, accessibility, ease of usage, and common availability of devices while choosing devices for use in registration and authentication scenarios.
MOSIP-compliant devices provide a trusted environment for the devices to be used in registration, KYC and AUTH scenarios. The trust level is established based on the device support for trusted execution.
L1 - The trust is provided by a secure chip with a secure execution environment.
L0 - The trust is provided at the software level. No hardware-related trust exists. This type of compliance is used in controlled environments.
Foundational Trust Module (FTM)
The foundational trust module would be created using a secure microprocessor capable of performing all required biometric processing and secure storage of keys. The foundational device trust would satisfy the below requirements.
The module can securely generate, store and process cryptographic keys.
Generation of asymmetric keys and symmetric keys with TRNG.
The module can protect keys from extraction.
The foundational device trust derived from this module is used to enable trust-based computing for biometric capture. The foundational device trust module provides a trusted execution environment based on the following:
Secure Boot
Ability to cryptographically verify code before execution.
Ability to check for integrity violations of the module/device.
The FTM should have at least one of the following certifications in each category to meet the given requirement.
Category: Cryptographic Algorithm Implementation
CAVP (RSA, AES, SHA256, TRNG (DRBGVS), ECC)
Category: FTM Chip
(ONE of the following certifications)
PCI PTS 5 or above (Pre-certified)
PCI - PED 2.0 or above (Pre-Certified)
System/Device Level Tamper (optional)
System/Device Level Tamper Responsiveness is recommended (not mandatory). In this case, FTM should be capable of showcasing Tamper Responsiveness (keys must be erased) against a tamper at the system/device level.
Threats to Protect
The FTM should protect against the following threats.
Hardware cloning attacks - Ability to protect against attacks that could result in a duplicate with keys.
Hardware Tamper attacks
Physical tamper - No way to physically tamper and obtain its secrets.
Foundational Trust Module Identity
Upon FTM provider approval by the MOSIP adopters, the FTM provider would submit a self-signed public certificate to the adopter. Let us call this the FTM root. The adopter would use this certificate to seed their device's trust database. The FTM root and their key pairs should be generated and stored in FIPS 140-2 Level 3 or more compliant devices with no possible mechanism to extract the keys. The foundational module upon its first boot is expected to generate a random asymmetric key pair and provide the public part of the key to obtain a valid certificate. The FTM provider would validate to ensure that the chip is unique and would issue a certificate with the issuer set to an FTM certificate chain. The entire certificate issuance would be in a secured provisioning facility. Auditable upon notice by the adopters or its approved auditors. The certificate issued to the module will have a defined validity period as per the MOSIP certificate policy document defined by the MOSIP adopters. This certificate and private key within the FTM chip is expected to be in its permanent memory.
MOSIP devices are most often used to collect biometrics. The devices are expected to follow the specification for all levels of compliance and their usage. The MOSIP devices fall under the category of Trust Level 3 (TL3) as defined in MOSIP architecture. At TL3 device is expected to be whitelisted with a fully capable PKI and secure storage of keys at the hardware.
L0 - A device can obtain L0 certification when it uses a software-level cryptographic library with no secure boot or FTM. These devices will follow different device identities and the same would be mentioned as part of exception flows.
L1 - A device can obtain L1 certification when it is built in a secure facility with one of the certified FTM.
Device Identity
All devices that connect to MOSIP must be identifiable. MOSIP believes in cryptographic Identity as its basis for trust.
Physical ID
An identification mark that shows MOSIP compliance and a readable unique device serial number (minimum of 12 alphanumeric characters) make and model. The same information has to be available over a 2D QR Code or Barcode. This is to help field support and validation.
Digital ID
A digital device ID in MOSIP would be a signed JSON (RFC 7515) as follows:
Signed with the JSON Web Signature (RFC 7515) using the "Foundational Trust Module" Identity key, this data is the fundamental identity of the device. Every MOSIP-compliant device will need the foundational trust module.
The only exception to this rule is for the L0-compliant devices that have the purpose of "Registration". L0 devices would sign the Digital Id with the device key.
A signed digital ID would look as follows:
The header in the digital id would have:
MOSIP assumes that the first certificate in the x5c is the FTM's chip public certificate issued by the FTM root certificate.
An unsigned digital ID would look as follows:
Payload is the Digital ID JSON object.
Accepted Values for Digital ID
List of keys used in the device and their explanation.
Each biometric device would contain an authorized private key after the device registration. This key is rotated frequently based on the requirement of the respective adopter of MOSIP. By default, MOSIP recommends a 30-day key rotation policy for the device key. The device keys are created by the device providers inside the FTM during a successful registration. The device keys are used for signing the biometric. More details of the signing and its usage will be . This key is issued by the device provider and the certificate of the device key is issued by the device provider key which in turn is issued by the MOSIP adopter after approval of the device provider's specific model.
The FTM key is the root of the identity. This key is created by the FTM provider during the manufacturing/provisioning stage. This is a permanent key and would never be rotated. This key is used to sign the Digital ID.
The MOSIP key is the public key provided by the MOSIP adopter. This key is used to encrypt the biometric. Details of the encryption are listed below. We recommend rotating this key every 1 year.
Device Service - Communication Interfaces
The section explains the necessary details of the biometric device connectivity, accessibility, discover-ability and protocols used to build and communicate with the device.
The device should implement only the following set of APIs. All the APIs are independent of the physical layer and the operating system, with the invocation being different across operating systems. While the operating system names are defined in this spec a similar technology can be used for unspecified operating systems. It is expected that the device service ensures that the device is connected locally to the host.
Device Discovery
Device discovery would be used to identify MOSIP-compliant devices in a system by the applications. The protocol is designed as a simple plug-and-play with all the necessary abstractions to the specifics.
Device Discovery Request
Accepted Values for Device Discovery Request
type - "Biometric Device", "Finger", "Face", "Iris"
Device Discovery Response
Accepted Values for Device Discovery Response
All the device API will be based on the HTTP specification. The device always binds to any of the available ports ranging from 4501 - 4600. The IP address used for binding has to be 127.0.0.1 and not localhost.
The applications that require access to MOSIP devices could discover them by sending the HTTP request to the supported port range. We will call this port the device_service_port in the rest of the document.
HTTP Request:
HTTP Response:
For details on android specifications please view the section - .
The device information API would be used to identify the MOSIP-compliant devices and their status by the applications.
Device Info Request
NA
Accepted Values for Device Info Request
NA
Device Info Response
So the API would respond in the following format.
Allowed values for Device Info Response
The applications that require more details of the MOSIP devices could get them by sending the HTTP request to the supported port range. The device always binds to any of the available ports ranging from 4501 - 4600. The IP address used for binding has to be 127.0.0.1 and not localhost.
HTTP Request:
HTTP Response:
For details on android specifications please view the section - .
The capture request would be used to capture a biometric from MOSIP-compliant devices by the applications. The captured call will respond with success to only one call at a time. So, in case of a parallel call, the device info details are sent with the status "Busy".
Capture Request
Allowed Values for Capture Request
NFIQ v1.0 on a scale of 0-100 (quality score).
Capture Response
Accepted Values for Capture Response
The entire data object is sent in JWT format. So, the data object will look like this:
The applications that require capturing biometric data from a MOSIP device could do so by sending the HTTP request to the supported port range.
HTTP Request:
HTTP Response:
For details on android specifications please view the section - .
The device would open a stream channel to send live video streams. This would help when there is an assisted operation to collect biometrics. Please note the stream APIs are available only for the registration environment.
Used only for registration module-compatible devices. This API is visible only for the devices that are registered for the purpose of "Registration".
Device Stream Request
Allowed Values for device Stream Request
Device Stream Response
Live Video stream with a quality of 3 frames per second or more using .
Error Response for Device Stream
The applications that require more details of the MOSIP devices could get them by sending the HTTP request to the supported port range.
HTTP Request:
HTTP Response: HTTP Chunk of frames to be displayed. Minimum frames 3 per second.
For details on android specifications please view the section - .
Registration Capture
The registration client application will discover the device. Once the device is discovered the status of the device is obtained with the device info API. During the registration, the registration client sends the RCAPTURE API and the response will provide the actual biometric data in a digitally signed non-encrypted form. When the Device Registration Capture API is called the frames should not be added to the stream. The device is expected to send the images in ISO format.
The requestedScore is on a scale of 1-100 (NFIQ v2.0 for fingerprints). So, in cases where you have four fingers the average of all will be considered for the capture threshold. The device would always send the best frame during the capture time even if the requested score is not met.
The API is used by devices that are compatible with the registration module. This API should not be supported by devices that are compatible with authentication.
Registration Capture Request
Accepted Values for Registration Capture Request
Registration Capture Response
Allowed Values for Registration Capture Response
The applications that require more details of the MOSIP devices could get them by sending the HTTP request to the supported port range.
HTTP Request:
HTTP Response: HTTP response.
For details on android specifications please view the section - .
The MOSIP server would provide the following retrieve encryption certificate API which is white-listed to the management servers of the device provider or their partners.
Retrieve Encryption Certificate Request URL
POST https://{base_url}/v1/masterdata/device/encryptioncertficates
Version: v1
Retrieve Encryption Certificate Request
The request is sent in a JWT format. So the final request will look like this:
Accepted Values for Retrieve Certificate Request
Encryption Certificate Response
The entire response is sent in a JWT format. So the final response will look like this:
Management Server and Management Client
Management Server Functionalities and Interactions
The management server has the following objectives.
Validate the devices to ensure they genuine devices from the respective device provider. This can be achieved using the device info and the certificates for the Foundational Trust Module.
Register the genuine device with the MOSIP device server.
Manage/Sync time between the end device and the server. The time to be synced should be the only trusted time accepted by the device.
Management Client
The management client is the interface that connects the device with the respective management server. The communication between the management server and its clients must be designed with scalability, robustness, performance and security. The management server may add many more capabilities than what is described here, But the basic security objectives should be met at all times irrespective of the offerings.
For better and more efficient handling of the device at large volumes, we expect the devices to auto-register to the Management Server.
All communication to the server and from the server should follow the below properties.
All communication is digitally signed with the approved algorithms
L1 Certified Device / L1 Device - A device certified as capable of performing encryption on the device inside its trusted zone.
L0 Certified Device / L0 Device - A device certified as one where the encryption is done on the host inside its device driver or the MOSIP device service.
Secure Provisioning
Secure provisioning applies to both the FTM and the Device providers.
The devices and FTM should have a mechanism to protect against fraudulent attempts to create or replicate.
The device and FTM trust should be programmed in a secure facility that is certified by the respective MOSIP adopters.
The organization should have a mechanism to segregate the FTMs and Devices built for MOSIP using a cryptographically valid and repeatable process.
Compliance Level
Supported algorithms:
In all the above APIs, some of the requests and responses are signed with various keys to verify the requester's authenticity. Here we have detailed the key used for signing a particular block in a request or response body of various APIs.
Android SBI Specification
This section explains the mechanism for the SBI devices to communicate in the android operating system.
Draft document V 0.9
Discovery will return the appId of the discovered items. Users will be given a choice to choose one of the discovered SBI app. The selected app responds back to the intent using the default intent callback functionality.
Device Discovery
Request: io.sbi.device
action: io.sbi.device
data: no change
type: application/json
Request Schema: No change in the data structure. The serialized request data as byte array is set in the intent extras with the key as “input”.
Response Schema: No change in the data structure. The serialized response data (byte array) is set in the intent extras with the key as “response”.
callbackId should be set to the appId, and can not be empty in android.
Request: appId.Info
action: appId.Info
data: no change
type: application/json
Request Schema: No change in the data structure. The serialized request data as a byte array is set in the intent extras with the key as “input”.
Response Schema: No change in the data structure. The serialized response data as a byte array is set in the intent extras with the key as “response”.
deviceInfo: callbackId should be set to the appId, can not be empty in android.
Request: appId.Capture
action: appId.Capture
data: no change
type: application/json
flag: FLAG_GRANT_READ_URI_PERMISSION
Request Schema: No change in the data structure. The serialized request data as a byte array is set in the intent extras with the key as “input”.
Response Schema: No change in the data structure. The response content is set as content URI “content://authority/path/id” in the intent extras as a string with the key as “response”.
URI must be invalidated right after the read.
Request: appId.rCapture
action: appId.rCapture
data: no change
type: application/json
flag: FLAG_GRANT_READ_URI_PERMISSION
Request Schema: No change in the data structure. The serialized request data as a byte array is set in the intent extras with the key as “input”.
Response Schema: No change in the data structure. The response content is set as content URI “content://authority/path/id” in the intent extras as a string with the key as “response”.
The content provider should not support insert, update, delete
On receiving rCapture request MDS must show the stream within its UI in the foreground.
Ensure to set the correct authority in the manifest and set the android:exported as “False”
Android Tab Specs
Android 9 (API Level 28) and above with hardware-backed key store.