METHOD FOR RECORDING BIOMETRIC DATA ON A CARD OF A CARD HOLDER

Abstract

According to one aspect, a method is proposed for recording a cardholder's biometric data on a card (CRT) comprising a microcontroller (MCU) configured to communicate via a secure communication channel with a remote server (SRV) containing an account linked to the cardholder. The method comprises: - authentication of the cardholder on a device application (APP) configured to communicate with said server and card; - authentication of the server by the card via the secure communication channel through the device application; and - recording of the cardholder's biometric data by a fingerprint reader (DR) on the card controlled by the card's microcontroller if the server is authenticated by the card. Figure 1 (for the abstract)

Description

Title of the invention: METHOD FOR RECORDING BIOMETRIC DATA ON A CARD OF A CARD HOLDER

[0001] Some embodiments and implementation methods relate to the recording of biometric data of a cardholder on his card, for example a payment card.

[0002] Cards, particularly payment cards, are known to require the entry of a confidential code (a "PIN," or Personal Identification Number) for use. This confidential code is known only to the cardholder. Entering the confidential code authenticates that the user is indeed the legal cardholder.

[0003] Biometric cards are also known which use biometric data, such as a user's fingerprints, to verify whether the card user is indeed the cardholder.

[0004] This biometric data makes it possible to replace the entry of a confidential code (“PIN code”) to verify if the card user is indeed the authorized cardholder.

[0005] In particular, a biometric card includes a fingerprint reader for acquiring biometric data relating to the user's fingerprints. The acquired biometric data is then compared to biometric data associated with the cardholder that is stored in the card.

[0006] The biometric data associated with the cardholder is known only to the card, and is therefore never transmitted outside the card.

[0007] It is therefore important to ensure that the biometric data stored in the card corresponds to that of the cardholder.

[0008] Thus, the recording in the card of the holder's biometric data requires verification of the identity of the cardholder, before this biometric data can be used during subsequent uses of the card.

[0009] Indeed, it is necessary to ensure that the biometric data stored on the card are properly associated with the fingerprint of the cardholder, when this biometric data is subsequently used to verify that the card user is indeed the cardholder.

[0010] Several methods can be implemented to securely record the cardholder's biometric data in the card.

[0011] In particular, a first solution consists of proceeding with an establishment The card issuer records biometric data onto the card. The cardholder's identity can then be verified using an identity document. The cardholder's biometric data can be acquired immediately after identity verification.

[0012] This solution has the disadvantage of requiring the cardholder to travel to the issuing institution of the card.

[0013] Another solution is to proceed with the recording of biometric data remotely (that is, without requiring the cardholder to travel to a card-issuing establishment).

[0014] It is then possible to record the biometric data of the cardholder firstly, and then to verify the identity of the cardholder only secondly in order to validate the recorded biometric data to make it usable.

[0015] Verification of the identity of the cardholder can be carried out by contacting the issuing institution of the cardholder's card or by entering a confidential code ("PIN code") associated with the card during a subsequent use of the card.

[0016] The entry of the PIN can be combined with a new acquisition of the card user's biometric data in order to verify whether this biometric data corresponds to the holder's biometric data previously recorded in the card.

[0017] Such a solution has the disadvantage of being implemented in two stages. This solution is therefore inconvenient for the cardholder.

[0018] Another solution may be to send a confidential code by mail or email to the cardholder. This confidential code can be used to initiate a session for registering the card's biometric data.

[0019] Such a solution has the disadvantage of requiring the use and management of an additional confidential code for the cardholder and for the issuing institution of the card.

[0020] There is therefore a need to propose a solution enabling the biometric data of the cardholder to be recorded in a biometric card in a simple, fast and secure manner.

[0021] According to one aspect, a method is proposed for recording biometric data of a cardholder on a card, for example a payment card, comprising a microcontroller configured to communicate via a secure communication channel with a remote server including an account linked to the cardholder, the method comprising: - authentication of the cardholder on an application on a device configured to communicate with said server and said card, then - server authentication via the card through the secure communication channel via the application of said device, then - a recording of the cardholder's biometric data by a fingerprint reader on the card controlled by the card's microcontroller if the server is authenticated with the card.

[0022] Such a recording process makes it possible to record, on a card, biometric data of a cardholder in a simple, fast and secure manner.

[0023] In particular, registration can be carried out remotely via the application of said device. The cardholder therefore does not need to go to the establishment associated with the cardholder's account to have their biometric data registered on the card.

[0024] Furthermore, using a secure communication channel via the device application after user authentication on the device application eliminates the need for an additional PIN to initiate the recording of biometric data on the card. Moreover, the device application does not know the encryption key used for such secure communication.

[0025] In an advantageous implementation mode, the authentication of the holder on the device application includes an acquisition of confidential data entered by the holder to the application, and then a verification of the conformity of the confidential data by the server.

[0026] Preferably, server authentication via the card includes: - the transmission, via the card, of data to be encrypted to the server through the device's application, - encryption by the server of said data to be encrypted using an encryption key in order to generate initial encrypted data, - a transmission of said initial encrypted data from the server to the card via the device application, - encryption by the microcontroller of the card of said data to be encrypted using the same encryption key in order to generate second encrypted data, then - a verification by the card's microcontroller that the first data encrypted by the server and the second data encrypted by the card's microcontroller are identical.

[0027] For example, authentication can be carried out using a secure communication protocol such as "SCP" (acronym for "Secure Channel Protocol"), in particular version "SCP03" ("Secure Channel Protocol 03"), defined by the "GlobalPlatform" organization. The SCP03 protocol also allows for mutual authentication between the card and the server.

[0028] The data to be encrypted is a combination of server data designated by the English expression "Host challenge" and card data designated by the English expression "Card Challenge". The first encrypted data can be designated by the English expression "Host cryptogram".

[0029] Preferably, said device communicates with the card via near field communication or via a card reader.

[0030] According to another aspect, a card is proposed, for example a payment card, comprising: - a fingerprint reader, - a microcontroller configured to communicate with a remote server containing an account linked to a cardholder via a secure communication channel and to: To order the fingerprint reader in order to record biometric data of the cardholder, To perform, before recording biometric data of the cardholder, an authentication procedure of the remote server via an application on an external device through said secure communication channel.

[0031] According to another aspect, a device is proposed that includes an application configured to: - to communicate with a card, as described above, and a server that includes an account linked to a cardholder, - authenticate with the server that a card user is indeed the cardholder, - to act as an intermediary during server authentication via the card through a secure communication channel, - start a biometric data recording of the cardholder on the card by the card's fingerprint reader, if the server is authenticated by the card.

[0032] According to another aspect, a server is proposed comprising an account linked to a cardholder as described above, the server being configured to: - communicate with an application on a device as described above, - authenticate with the device application that a card user is indeed the cardholder, - perform an authentication procedure of this server via the card through said application of the device via a secure communication channel.

[0033] According to another aspect, a system comprising: is proposed - a card as described above, - a device as described above, and - a server as described above.

[0034] Other advantages and features of the invention will become apparent upon examination of the detailed description of embodiments, which are by no means limiting, and the accompanying drawings in which:

[0035] [Fig.1]

[0036] [Fig.2]

[0037] [Fig.3]

[0038] [Fig.4] illustrate embodiments and implementations of the invention.

[0039] Fig. 1 illustrates a diagram of an embodiment of a CRT card, in particular a payment card.

[0040] The CRT card includes a microcontroller (MCU) configured to communicate via near-field communication with an APP device, in particular a multifunction phone. Alternatively, the CRT card can communicate with the APP device using a card reader connected to the APP device, for example. The CRT card is issued by a BNK bank to a specific person referred to hereafter as the "cardholder".

[0041] The MCU microcontroller is a secure element. In particular, the MCU microcontroller includes a JOS operating system. For example, the JOS operating system is a Java Card operating system. Java Card is a software technology that allows Java-based applications (applets) to run securely on an integrated circuit. Java Card technology combines a subset of the Java programming language with a runtime environment optimized for secure elements, including the MCU microcontroller.

[0042] The MCU microcontroller also includes a DR fingerprint reader for acquiring biometric data associated with a fingerprint read by the fingerprint reader.

[0043] The MCU microcontroller also includes a MEM memory for storing biometric data associated with the fingerprint read by the fingerprint reader.

[0044] The MCU microcontroller includes a BMNG biometric application configured to control the DR fingerprint reader and to implement a recording of biometric data of the CRT card holder in said MEM memory of the MCU microcontroller.

[0045] The MCU microcontroller may include a radio frequency (RFL) software library. The software library comprises a set of programs configured to implement functions enabling near-field communication with the APP device using an NFCT near-field communication circuit of the microcontroller.

[0046] The MCU microcontroller also includes a secure SD domain suitable for storing cryptographic keys that can be used to establish a secure communication channel between the CRT board and a server, in particular a banking SRV server. These cryptographic keys are stored in a secure MEM memory of the MCU microcontroller and are identified by a key version number (KVN). Figure 2 below illustrates an implementation for storing such cryptographic keys.

[0047] The device includes a banking application configured to communicate with said CRT card and a banking SRV server comprising an account linked to the CRT cardholder. In particular, the APP device may include a near-field communication circuit enabling near-field communication with the CRT card. Alternatively or in combination, the APP device may also be configured to communicate with the CRT card via a card reader.

[0048] This banking application is provided by the CRT cardholder's bank, BNK. The banking application is configured to allow the recording of biometric data on the CRT card, as described below in relation to [Fig. 3]. The banking application is configured to communicate with the SRV banking server.

[0049] The APP device can be configured to automatically open the banking application when the CRT card is detected by its near field communication circuit.

[0050] Figure 2 illustrates a diagram of a method for initializing a secure communication channel between a bank SRV server and a card, in particular the CRT card described above.

[0051] The secure communication channel may be a secure communication protocol such as "SCP" (acronym for the English "Secure Channel Protocol"), in particular according to version "SCP03", defined by the "GlobalPlatform" organization.

[0052] Such a procedure is implemented before handing the CRT card to the designated holder.

[0053] In particular, the banking SRV server includes an IMK master key.

[0054] The method includes a step 20 for generating an IccMK key. In this step 20, the SRV banking server generates an IccMK key from the IMK master key and the ICC key data. The ICC key data includes a cardholder identification number and a microcontroller serial number. Specifically, the IccMK key is obtained by AES (Advanced Encryption Standard) encryption from the IMK master key and the ICC key data.

[0055] The method includes a step 21 for generating static keys. In this step 21, the SRV banking server generates several static keys IccMK_ENC (for AES encryption / decryption), IccMK_MAC (for secure channel authentication and for verifying / generating the MAC message authentication code), and IccMK_DEK (for decrypting sensitive data) from the IccMK key. In particular, the SRV banking server generates a set of static keys as defined by the SCP03 protocol.

[0056] The method includes a step 22 of key transmission to the CRT card. In particular, in this step 22, the banking SRV server transmits the static keys, a KVN (Key Version Number) associated with the transmitted static keys, and the ICC key data to the CRT card. The static keys, the KVN, and the ICC key data are then stored in the SD secure domain of the CRT card (step 23).

[0057] In one embodiment, the sharing of static keys can be carried out using an intermediate personalization server (not shown) for steps 20, 21 and 22. Such an intermediate personalization server is then configured to share the static keys with the SRV banking server and the CRT card.

[0058] The CRT card can then be given to the designated CRT cardholder.

[0059] The SRV banking server and the CRT card microcontroller then know static keys allowing a secure communication channel to be established between the SRV banking server and the CRT card.

[0060] The device's banking application APP does not know these static keys but is subsequently used as a "proxy" between the banking server SRV and the CRT card to proceed with the registration of the holder's biometric data on the CRT card.

[0061] Figures 3 and 4 illustrate a diagram of an implementation method for recording biometric data in the CRT card described above.

[0062] In particular, as illustrated in [Fig. 3], the method includes a user authentication step 30. In this step 30, the user authenticates themselves on the banking application of said device. User authentication is performed using CRDT data entered on the user's application, which is then verified by the device's banking application, notably by communicating with the SRV banking server (step 31).

[0063] In particular, the user can enter an associated identifier and a personal code into the application. The user's personal code can be defined from a code provided by the user's bank, BNK, for example. In particular, the code provided by the BNK bank can be a code temporary used to enter the personal code defined by the user.

[0064] The personal code and identifier entered allow the BNK bank to authenticate the user via the application.

[0065] Once the user is authenticated, the process includes a step 32 for selecting the BMNG biometric application. In this step 32, the device's banking application APP selects the CRT card's BMNG biometric application via near-field communication between the device APP and the CRT card, or via a card reader.

[0066] The method then includes mutual authentication of the bank server SRV and the CRT card. This authentication can be carried out using a secure communication protocol via the device application APP. For example, the communication protocol used can be the "SCP" protocol (acronym for "Secure Channel Protocol"), in particular version "SCP03", defined by the "GlobalPlatform" organization.

[0067] In particular, the process then includes a step 33 of transmitting an authentication request R_REQ.

[0068] In this step 33, the device's banking application (APP) transmits an authentication request (R_REQ) to the CRT card. The authentication request (R_REQ) includes the KVN key version number, which indicates the static key set to be used by the CRT card. The authentication request (R_REQ) also includes host challenge (H_CHL) data from the server. This host challenge data is generated by the device's banking application (APP).

[0069] The authentication request R_REQ corresponds in particular to the INITIALIZE UPDATE command defined by the "SCP03" protocol. The server's challenge data H_CHL corresponds to data to be encrypted by the CRT card. This request also establishes a secure communication channel between the CRT card's biometric application BMNG and the device's banking application APP.

[0070] The authentication request can be prepared by the banking server SRV and transmitted by the latter to the banking application of the device APP or can be generated directly by the banking application of the device APP.

[0071] The method then includes a step 34 for generating a cryptographic value, called a card cryptogram. In this step 34, the CRT card's microcontroller (MCU) selects the static key set indicated by the key set number (KVN) and then generates different session keys. These session keys are then used to generate a card cryptogram from the bank server's SRV challenge data (H_CHL) and the card's C_CHL challenge data.

[0072] The method then includes a transmission step 35. In this step 35, the CRT card transmits the ICC key data, the KVN key version number, the card's C_CHL challenge data (referred to in English as "Card challenge") and the card cryptogram.

[0073] The method then includes a step 36 of requesting authentication of the CRT card from the bank server SRV. In this step 36, the device application APP transmits an authentication request AUT_REQ to the bank server using said secure communication protocol. The AUT_REQ request includes the server's H_CHL challenge data, the card's C_CRYPT cryptogram, the card's C_CHL challenge data, the KVN key version number, and the ICC key data. The ICC key data allows the bank server SRV to retrieve / regenerate the card's static keys from an IMK master key of the bank server SRV.

[0074] The process then includes a verification step 37. In this verification step 37, the SRV banking server retrieves static keys IccMK_ENC, IccMK_MAC, and IccMK_DEK of the card from the KVN key version number, the IMK master key, and card-specific derivation information received by the AUT_REQ authentication request. The SRV banking server then generates session keys S_ENC, S_MAC, and S_DEK (not shown). These session keys are generated from the static keys IccMK_ENC, IccMK_MAC, and IccMK_DEK of the card, which are associated with a given KVN key version number.

[0075] These session keys S_ENC, S_MAC, and S_DEK are then used to verify the card cryptogram C_CRYPT. Specifically, the session keys S_ENC and S_MAC are used to generate a cryptogram from the server's H_CHL challenge data and the card's C_CHL challenge data. The server then compares the generated cryptogram to the card's C_CRYPT cryptogram. If the two cryptograms are identical, the bank server SRV authenticates the CRT card.

[0076] The session keys S_ENC, S_MAC are also used to generate a cryptographic value H_CRYPT, called the server cryptogram, from the challenge data C_CHL of the card and the challenge data H_CHL of the server.

[0077] The SRV banking server also generates a MAC message authentication code using the S_MAC session key.

[0078] The method also includes a step 38 of transmitting an AUT_MES authentication message from the SRV server to the banking application on the APP device. In this step, the banking server transmits the AUT_MES authentication message to the banking application on the APP device via the secure communication protocol established between the banking server SRV and the APP device. The AUT_MES authentication message includes the server's cryptogram and a code MAC message authentication.

[0079] The method then includes a step 39 of transmitting the AUT_MES authentication message from the device to the CRT card. The transmission of the AUT_MES authentication message corresponds in particular to the EXTERN AL AUTHENTICATE command defined by the "SCP03" protocol. In this step, the AUT_MES authentication message received in step 38 by the device is transmitted to the CRT card by the device via near-field communication or via a card reader.

[0080] The process then includes a verification step 40. In this step 40, the CRT board's microcontroller (MCU) first calculates the MAC message authentication code of the received message AUT_MES using its key S_MAC. It then compares the received MAC message authentication code with the calculated MAC message authentication code. If these two MAC message authentication codes are identical, the CRT board's microcontroller (MCU) generates a cryptogram from the board's challenge data C_CHL and the server's challenge data H_CHL using the session keys, and then compares this cryptogram to the server's cryptogram H_CRYPT.

[0081] If these two cryptograms match, then the process includes a step 41 in which the CRT card transmits a VAL_MES authentication validation message to the device's banking application. Thus, the device's banking application APP knows that the banking server SRV and the CRT card are mutually authenticated (AUT_OK).

[0082] Once mutual authentication of the SRV banking server and the CRT card has been completed, the method includes recording biometric data on the CRT card, as illustrated in [Fig. 4]. The recording of biometric data is performed immediately after mutual authentication of the SRV banking server and the CRT card. If authentication between the card and the server is unsuccessful, then the method of recording biometric data on the card is not performed.

[0083] In particular, the method includes at least one registration command step 42. In this step 42, the device's banking application (APP) generates a registration command that it transmits to the CRT card via wireless communication or a card reader. This registration command enables the biometric application (BMNG) of the CRT card to register the biometric data associated with a user's fingerprint. In the implementation illustrated in [Fig. 4], two registration commands, ENRL_C#1 and ENRL_C#2, are issued successively to register biometric data corresponding to two user fingerprints. The application can display a visual indication on the device screen to indicate to the user that the CRT card is ready to record biometric data.

[0084] Each registration command step is followed by a registration step 43. In this step 43, the CRT board's microcontroller (MCU) registers the user's biometric data. To do this, the user uses the CRT board's fingerprint reader (DR) by placing their fingerprint on the reader. The fingerprint reader (DR) acquires the user's fingerprint and generates biometric data TMPL#1 and TMPL#2 associated with the user's fingerprint for the respective commands ENRL_C#1 and ENRL_C#2. The biometric data can correspond to the data acquired by the fingerprint reader (DR), data obtained by compressing the acquired data, or information extracted from the acquired data. This biometric data is then stored in the CRT board's microcontroller's memory (MEM).

[0085] The method then includes a step 44 in which the device's banking application (APP) transmits an end-of-registration message (END_R) to the card's biometric application (BMNG) (CRT). This end-of-registration message (END_ENRL) completes the registration of the cardholder's biometric data.

[0086] The method then includes a step 45 for activating the biometric data TMPL#1, TMPL#2. In this step 45, the BMNG biometric application activates the recorded biometric data. Activation of the biometric data is made possible by the authentication of the SRV banking server by the CRT card.

[0087] Once the biometric data is activated, the method includes a step 46 in which the card's biometric application BMNG transmits an ENRL_OK confirmation message to the device's banking application APP. This ENRL_OK confirmation message indicates to the banking application that the recorded biometric data has been successfully activated. The activated biometric data can then be used during subsequent use of the CRT card to verify that the CRT card user is indeed the actual CRT cardholder by comparing the user's biometric data acquired by the RD fingerprint reader with the biometric data recorded on the card.

[0088] As seen previously, before registering biometric data on the CRT card, the CRT cardholder simply needs to identify themselves on the device's banking application APP and then proceed with registration by placing at least one finger on the DR fingerprint reader.

[0089] Indeed, mutual authentication is performed invisibly to the user. Such a biometric data recording process is therefore simple and quick for the cardholder to implement.

[0090] In particular, the cardholder does not need to travel to an establishment Bank account to register biometric data. The cardholder also does not need to use a dedicated code to register their biometric data.

[0091] Of course, the present invention is susceptible to various variations and modifications which will become apparent to those skilled in the art. For example, the method of recording biometric data may simply include authentication of the server by the card, without authentication of the card by the server.

Claims

Demands

1. A method for recording biometric data of a cardholder on a card (CRT) comprising a microcontroller (MCU) configured to communicate via a secure communication channel with a remote server (SRV) comprising an account linked to the cardholder, the method comprising: - authentication of the cardholder on an application of a device (APP) configured to communicate with said server (SRV) and said card (CRT), then - authentication of the server (SRV) by the card (CRT) via the secure communication channel through the application of said device (APP), then - recording of biometric data of the cardholder by a fingerprint reader (DR) of the card (CRT) controlled by the microcontroller (MCU) of the card (CRT) if the server (SRV) is authenticated by the card (CRT).

2. A method according to claim 1 wherein the authentication of the holder on the device application (APP) includes an acquisition of confidential data entered by the holder to the application, and then a verification of the conformity of the confidential data by the server (SRV).

3. A method according to any one of claims 1 or 2, wherein the authentication of the server (SRV) by the card (CRT) comprises: - transmission, by the card (CRT), of data to be encrypted to the server (SRV) via the device application (APP), - encryption by the server (SRV) of said data to be encrypted using an encryption key so as to generate first encrypted data, - transmission of said first encrypted data by the server (SRV) to the card via the device application (APP), - encryption by the microcontroller (MCU) of the card (CRT) of said data to be encrypted using the same encryption key so as to generate second encrypted data, and then - verification by the microcontroller (MCU) of the card (CRT) that the first encrypted data by the server and the second encrypted data by the The microcontrollers on the board are identical.

4. A method according to any one of claims 1 to 3, wherein said apparatus (APP) communicates with the card via near field communication or via a card reader.

5. Card comprising: - a fingerprint reader (DR), - a microcontroller (MCU) configured to communicate with a remote server (SRV) containing an account linked to a cardholder via a secure communication channel and to: O control the fingerprint reader so as to record biometric data of the cardholder, O perform, before recording biometric data of the cardholder, an authentication procedure of the remote server via an application on an external device (APP) via said secure communication channel.

6. Device comprising an application configured to: - communicate with a card (CRT) according to claim 5 and a server (SRV) comprising an account linked to a cardholder, - authenticate with the server (SRV) that a user of the card (CRT) is indeed the cardholder, - act as an intermediary during server authentication by the card via a secure communication channel, - start recording the cardholder's biometric data on the card by the card's fingerprint reader, if the server is authenticated by the card.

7. Server comprising an account linked to a cardholder according to claim 5, the server being configured to: - communicate with a device application (APP) according to claim 6, - authenticate with the device application (APP) that a cardholder user (CRT) is indeed the cardholder, - perform an authentication procedure of this server by the card (CRT) through said device application (APP) via a secure communication channel.

8. System comprising: - a card (CRT) according to claim 5, - a device (APP) according to claim 6, and - a server (SRV) according to claim 7.

Images