D3.10: Biometrics in identity management

Title: SYSTEM-ON-CARD

An even more secure solution for biometric verification is to include the biometric sensor on the card, on top of the previous match-on-card architecture - this is called system-on-card. This biometric system architecture currently is only an option for fingerprint and signature verification, thus a preference for the system-on-card architecture extremely limits the choice of biometric modality for integration in identity documents. 

Choosing a system-on-card architecture increases the cost of the token, but decreases the cost of the system external to the token. The system-on-card is a totally self-containing system, keeping the reference and sample template on card as well as the matching process and thereby leaving no opportunity to intervene maliciously, except in the communication between the card and the card reader, after matching is performed. Therefore, a secure communication channel remains imperative for any biometric recognition implementation, even for the system-on-card implementation.  

Similar to the previous architecture, performance might be an issue here. 

Hybrid Architectures

For many biometric modalities, it is not yet possible to perform biometric data collection, feature extraction and matching on a smart card. This leads to hybrid architectures based on the ones that were just explained.  

A first option is to do feature extraction and matching on the card reader’s side, but both the sensor and reference template storage remain on the smart card. A second option is similar, but only feature extraction is done off-card. These architectures are certainly not preferable, because both options require the transmission of raw biometric data from the card with the sensor on board to the card reader where extraction is done. Potential attacks that follow from this were indicated in section .

Besides this risk, we also note that fingerprint is the only biometric modality that currently has commercial implementations with a sensor-on-card architecture and that it is also possible to do fingerprint verification with a more secure system-on-card architecture. The requirement of transmission of raw biometric data has a negative impact on user’s (perception of) privacy and thus on their acceptance of the biometric recognition implemented with these last two architectures. 

Privacy-enhanced Biometrics

In the presented systems the reference data is used in the matching process which results in a yes or no answer. The problem is that this reference data is sensitive data that cannot be leaked which explains why the focus in the presented systems was on protecting the reference templates. 

Several mechanisms exist to extract random information from biometrics that can be used as cryptographic keys. These keys can be used later in the matching process without leaking information about the user’s biometrics or the key. The key not only serves to verify the user’s identity but can also be used in cryptographic applications.  

Due to the nature of biometrics, it is impossible to obtain two samples that are identical. Exact reconstruction of the key from a sample that is slightly different than the one used during enrolment requires some extra data that was derived from the original sample. A biometric verification architecture that uses public helper data was proposed by Linnartz and Tuyls. The public helper data does not reveal any information about the derived keys or any useful information about the biometrics of the user. Similar structures called fuzzy extractors have been defined by Dodis et al.

A cryptographic hash of the derived key and the helper data can be stored in a central database without compromising the user’s biometrics, without revealing the derived key and without violating the user’s privacy. This mechanism is easily applicable to each of the architectures presented earlier on. The helper data can be stored on the identity card and even on an insecure storage token.