Patent Description:
Records or messages created by the invention may preferably be compliant to NDEF format standard. Alternatively, they may also be compliant to QR code, 2D or 3D code standards.

It relates also to the use of above method and system to make secure mobile application activations or for realizing a strong customer authentication, (notably in banking domain for mobile banking application), using said contactless device and an NFC reader such as an NFC mobile phone.

The involved activation or authentication may preferably use biometric (or fingerprint) data; Biometric data may be captured thanks to corresponding sensor preferably on said contactless devices or NFC reader.

Especially, the invention aims to provide a solution to secure mobile application activation or strong customer authentication by the simple use of NFC reader that supports only a reading mode of static NDEF records.

Smart cards (or electronic chip cards) are often used for card payments and also strong customer authentication. The underlying specifications used are ISO <NUM> (chip interface) and ISO <NUM> (contactless interface). In a nutshell, these standards use communications or data exchanges comprising a command-response based structure, where the terminal (or card reader) sends a command and the card returns a corresponding response.

For payments, the chip (or smart) cards uses a variant of the ISO specifications called EMV (Europay MasterCard Visa), and the terminal (or card reader) is mostly a Point-Of-Sale terminal (POS), but could also be a mobile device or an ATM.

In the case of strong customer authentication, one common standard is called "Chip Authentication Program" (CAP), which in turn relies on EMV Specifications, are using Personal Card Reader which uses a CAP Application.

Another method is Open Authentication HOTP/OCRA application on the card to generate One-Time-Passwords. As of today, most personal card readers are using the chip interface, but a mobile could use the contactless interface to generate the one-time-password. There are also other solutions based on the ISO standards, such as PKI-card, which allow to generate Digital Signature.

There exists another standard, based on the contactless interface, which is called NFC "Data Exchange Format" (NDEF), which is a read/write interface, allowing data records to be read and written to a card. When using the NDEF Type <NUM>, this application is authorized to co-exist on an EMV-card.

The NFC Forum approved four following tag types.

Type <NUM> Tag is based on ISO/IEC 14443A. This tag type is read and re-write capable. The memory of the tags can be write protected.

Type <NUM> Tag is based on the Japanese Industrial Standard (JIS) X <NUM>-<NUM>. This tag type is pre-configured at manufacture to be either read and re-writable, or read-only.

Type <NUM> is fully compatible with the ISO/IEC <NUM> (A \& B) standard series. It is pre-configured at manufacture to be either read and re-writable, or read-only. For the communication with tags APDUs according to ISO <NUM>-<NUM> can be used.

The NFC forum defined a structure for writing data to tags or exchanging data between two NFC devices. The format is called NDEF. An NDEF record can contain multiple different RTD. An RTD is an information set for a single application. An RTD can only contain a single information such as text, a URI, a business card or pairing information for other technologies.

Many mobiles today have contactless interface support, however, certain mobiles impose strict restrictions on what an application can do with the contactless interface, and certain of these mobiles only allow "READ" access using NFC Data Exchange Format (NDEF), meaning that it's not possible to use these mobiles for EMV, CAP or PKI (Digital Signatures), or any other transaction requiring the terminal to send specific APDU-commands to the card.

This puts a very tight restriction on what can be done with the card, since you can only read data using the NDEF protocol and that prevents a mobile application from accessing normal functions on the card that are used for payments and strong customer authentication.

One option would be to add a static signed data block onto a NDEF record, such as adding the EMV Offline static data authentication (SDA) block onto a NDEF record. Using this methods, it would allow the mobile to verify a static signed data block, and it would also possible to determine that the card number has been issued and haven't expired.

However, since this data format is static it can easily be skimmed and since there are no access conditions, anyone can read and copy this static data and this presents a security problem.

Today, when activating a mobile banking application, it is needed to ensure it is the legitimate user that activates the mobile banking application. Therefore, the bank need to apply a number of checks during the activation process. One such check is to ask customer for his username and password and some other knowledge he has in his possession such as Knowledge Based Authentication.

However, this creates a problem, since the information available to the user, may already be known by the attacker or easily stolen from the user and therefore, the mobile Bank application activation process for a user turns to be a weak link.

The wanted situation is that the bank can use information that is persistent and secure, which cannot easily be stolen and that could be used for mobile banking application activation.

Therefore, using today's technologies for EMV-transactions, one-time-passwords, challenge-response or digital signatures using cards are not suitable to be used, since there are no way for the proper interaction with the card with these certain mobiles.

Patent application <CIT> describes one method where a card is activated when a correct fingerprint is presented. This can be useful in POS scenarios. However in a mobile scenario, this cannot be used since the mobile application cannot control the commands required to do a contactless card payment or a strong customer authentication with the mobile using a contactless card.

Patent application <CIT> describes a method comprises the steps of: upon the OTP generating device being inserted into the RF field, generating a new OTP code; formatting the OTP code into a static message; responding to interrogation requests from an RFID/NFC reader; and responding to read requests from the RFID/NFC reader with the OTP code being part of a message as if it were a static message, using standardized methods.

Patent application <CIT> discloses a smart card with random temporary account number generation. An identical random number generator and a set of account numbers are included in the card and in a remote server to enable connection with a verified temporary account number. The card has a biometric sensor and the use of a fingerprint is disclosed for only actuate the card when user is authenticated.

Patent application <CIT> (A1) describes a system which relates to a temporary account number generation, which uses a biometric signal for activation and deactivation of a card. Secondly, the system can randomly select one account number from a plurality of account numbers. However, card numbers can only be retrieved electronically by sending commands to the EMV application and since certain mobiles only supports reading of NDEF records, which is not suitable method to be used with the mobile for payments or strong customer authentication.

Patent application <CIT> relates to a method for reducing the power consumption on cards; doing power management; detecting a finger on the fingerprint sensor; presenting status of the fingerprint matching on a display; and to present a status if the fingerprint is present on the sensor. Therefore none of these features in this patent application make the transaction more secure, or make it functional over NDEF interface.

The document <CIT> describes a system where fingerprint is used to give access, and also that the fingerprint may be stored in a central database, wherein the card is dipped into a fingerprint sensing device, and which transmit the fingerprint, and if there is a match, it allows access to a memory where the fingerprint is stored.

Even though this method could be used as a way to give access to a NDEF record, it won't allow the user to be "strongly authenticated" remotely in a convenient and secure way using this method; In addition, storing fingerprints in a central database is problematic, since it is "sensitive Personally Identifiable Information" (PII) and some countries have strict restrictions on how to use this data.

Therefore, none of the above technology statements will help to solve the problem identified by the inventors.

The invention proposes a method that overcomes the drawbacks of the present art, in a more convenient and secure way. First of all, inventor's solution determines how to have a reliable or trusted information that is persistent and/or secure, and which cannot easily be stolen and that is usable for sensible operations locally or remotely namely for mobile banking application activation or authentication.

This lead to a method principle in which a trusted NDEF record (or message or information) is first of all generated an in a NFC (or contactless) portable (or wearable) device, such the smart card.

In a second step, the inventors found out how to use said trusted NDEF record notably in a method and a system that enables a bank-customer to perform secure mobile application activation or strong customer authentication using a contactless card, which uses the NDEF Tag, (preferably in read only mode for certain mobile).

Advantageously, this invention can be used for mobile activation by card (instead of calling IVR or using traditional web site with card credential manual entry);.

According to one particular aspect of a particular operation of the invention method, the contactless card (or NFC device) may be configured for creating (preferably in real-time or dynamically) a record that is compatible with NDEF record standard. This generation may be made for example upon receiving a read request of a record.

According to an aspect of the operation, an NDEF application in the NFC device may preferably insert dynamic data(s) into the payload(s) in at least one chosen NDEF record(s) among one or several memorized in the NFC device, and in real-time it may also recalculate the NDEF message or record and its associated lengths with the new dynamic (or variable) content.

The NFC device may also perform at least one internal cryptographic operation before returning a new NDEF record to the NFC reader.

One aspect or advantage of the invention, is that the response is non-replayable (since it change namely at each reader request). For example, a remote server may detect if a same or previous response is sent again, preferably using a counter (<NUM>) that changes for each invocation, either incrementing or adding or subtracting a value.

Further, the invention may use a number of different collected data, which allows the bank to establish a certain reliable or trusted context;.

A further embodiment of the system, may consist of a contactless card (or device) that have at least one first application, being able to manage NDEF protocol, an optional second application, an optional fingerprint sensor and fingerprint matching logic with at least one fingerprint template, said logic determining if there is a successful match of a fingerprint against at least one memorized fingerprint template, and consequently generating a positive fingerprint match signal.

Another possible interesting feature of this invention is that it allows to capture or collect data from a second application in the NFC device;
For example, here the data is exemplified with the Application Transaction Counter (ATC) data, located in the EMV Application, and this data may be advantageously inserted in the NDEF record, and it may also preferably, (but optionally), be an input data for the generation of a dynamic response to a NFC reader request.

The benefit of including the ATC into the dynamic response generation may afterward appear apparent to the person skilled in the art but is developed thereafter.

Therefore, a first object of the invention is a method to create a trusted NDEF record in an NFC device, comprising the steps of:.

characterized in that said NDEF application is configured to generate a second NDEF record different from a previous first one, based on data collected, as a result of a detection or upon a receipt of a request of a NFC reader or after collection of new data.

According to another features or embodiment of the method:.

Another object of the invention lies also in the use of above method for a method to trigger a trusted specific action in a NFC reader or a remote server, wherein an NFC reader reads an NDEF record in an NFC device, said NDEF record being interpreted or executed by a NDEF application (<NUM>) to trigger an action,
The method is characterized in that said NDEF record is created by a method to create a trusted NDEF record according to any one of above features or embodiments.

According to another preferred features or embodiments, of the method, said action is selected among:.

The invention object comprises also a system to create a trusted NDEF record in an NFC device, comprising:.

According to preferred features or embodiments, of the system:.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereafter with reference being made to the drawings in which:.

At <FIG>, according to one preferred embodiment of the invention, there is an overview of a system S1 to create a trusted record <NUM> in an NFC device <NUM>. The system comprises at least (or constitutes) an NFC device containing a first NDEF record (<NUM>) and an application (<NUM>) in said NFC device.

Here, The NFC device <NUM> is a contactless smart card <NUM>, but it may also be in the shape of an electronic smart watch, since many smart watches has contactless card emulation capability, and can contain intelligent software applications (or software interface), with nearly same or even identical functionality as NDEF application (<NUM>), and software service application such as an EMV Application <NUM> to be used as contactless credit card.

The NFC device may be also a wearable device, an IoT device, an electronic bracelet.

In another embodiment (not described) the device <NUM> (such a card) may comprise a display (notably with eInk, amoled, or bistable technology), and the trusted message may be generated and displayed in a QR code format (3d code) on a card.

Alternatively, the format of the created record structure may (or not) correspond to the standard NDEF and the payload (or variable record or message) at least may be displayed under 3D code format or other format (file or string of characters readable with reader having OCR application). This enables other communication possibilities namely with the mobile or other optical reader.

The display is changed according to the invention for each transaction (namely EMV) and is may be a stable visible output. The validity of the output message displayed may be time limited for any use namely as authentication or mobile banking transaction.

The mobile may read the displayed code with optical means (camera) by taking a photo.

The message included in the 3D code may be then used by the mobile as the response received by it when it is on NDEF format.

When displayed on a screen of a watch, (powered by battery), the 3D code may be displayed during a limited time corresponding to the limited time of validity.

Consequently, the device <NUM> (card, watch. ) may not use the NFC capabilities and NDEF records or application but uses instead 3D code capabilities with a corresponding software application 5bis similar to software application <NUM>.

The reader capabilities also may have corresponding interface or application to extract the message or data generated in the 3D code.

In this alternative embodiment (with display means 3D), the generation of the response of the device <NUM> may occur automatically, for example as soon as there is a change in the data to be collected (fingerprint, counter <NUM> value, ATC value) or as soon as a corresponding request of 3D code is emitted by the mobile by any interface corresponding to an communication interface of the device <NUM>.

The generation of the displayed variable response may occur also when a user activate the device by a direct prompt command (switch).

In contrast, the use of NDEF record is particularly interesting since the reader may bring its proper electromagnetic energy to power an NFC device (credit card do not need to have battery).

There could be a mixture of interface capabilities and communication means and software applications (NFC and a display) where the energy and request is brought using NFC interface and the record or response including the payload may be displayed on the NFC device. The realization of a transaction may require both reading of the message under two different format (NFC and 3D code).

In the example, the smart card <NUM> has an antenna interface <NUM> operating preferably according to ISO <NUM> standard, or any other contactless standard that allows short distance contactless communication.

The NFC device <NUM> (card, watch) may also contain optionally a biometric capturing unit, having near or even identical functionality as the fingerprint sensor <NUM>. Other biometric sensors may be used such as voice sensor, image sensor.

According to a characteristic of this preferred embodiment, the software application is an NDEF software application which is configured to generate a second NDEF record, (preferably but not exclusively different from a previous first one); the generation of the second NDEF record by the NDEF application <NUM> is based on data collected (or at least received) in the NFC device <NUM>. The generation and / or the collecting of the collected data may be preferably made as a result of a detection or upon a receipt of a request of a reader or after collection of new data.

The system S1 (first electronic portable communication device (namely a NFC device <NUM> in the example) is intended to work or to cooperate with at least a second electronic portable communication device <NUM>, such as a smartphone (called thereafter mobile), having reading capabilities with the first one.

The reader <NUM> may be selected among a mobile phone, an IoT device, an electronic watch. The reader have preferably NFC capabilities.

The system S1 may comprise a remote server <NUM> cooperating with the mobile such a service provider server (described later).

The mobile <NUM> is equipped with a "mobile application" (<NUM>) (or computer program), preferably a banking application to do financial services. It may comprise a different applications depending the function of the device or the service provider.

The mobile <NUM> is configured to enable interaction or a communication (preferably without contact) with the first portable (or wearable) electronic device <NUM>, here embodied preferably in the example by a contactless smartcard. (The first portable device <NUM> is called thereafter "NFC card" <NUM> to simplify and for clarity).

The interaction (or communication) between the mobile <NUM> and the NFC card <NUM>, is made through an NFC (Near Field Communication) interface <NUM>. The first device may be also any device or wearable like a watch, a bracelet having communication interface capabilities with the mobile <NUM>. Preferably, the communication is of NFC type for security reason, but not exclude other like Bluetooth™, or optical or infrared communication or UHF tag communication.

The mobile <NUM> may also be in the shape of a smart watch, since those also have contactless card reading capability and can contain intelligent applications, with nearly the same or even identical functionality as a Mobile Application <NUM>.

The mobile <NUM> is configured also to connect or communicate or interact with a remote "service provider server" <NUM> through a communication network <NUM>, Wi-Fi, cellular telecommunication, internet.

The invention is advantageous namely because it is very simple enables the use of mobile having at least a read only mode. Mobile does not require to use other capabilities like write or other instructions.

In the example, the service provider server is a bank application server <NUM> but can be any other service. (For clarity and to simplify, the server <NUM> is called thereafter banking server <NUM> and any related server application <NUM> may be called bank server application).

The mobile may contain also an application key set <NUM>. It may also preferably contains credential <NUM>. Their use will be explain later in reference to the different use case embodiments.

Said contactless card <NUM> and mobile <NUM> may be handled by a user <NUM> to enable interaction between them. Advantageously, the invention enables in a convenient way to do sensitive operations namely using to portable device such as a smartphone and a trusted smart card (such as EMV credit card) having the invention capabilities. Invention may also provide alternatively the combination of a trusted smart card and an electronic watch (as a reader) having the described function included in the smart phone.

This is very convenient for user since it uses usual portable devices (card associated with a mobile, or a watch or wearable) to implement at least one or two or more security factors depending the security context involved.

The NFC card <NUM> contains here an NDEF Application <NUM> (or NDEF computer program <NUM>) and an optional EMV Application <NUM> (or EMV computer program <NUM>).

According to a preferred feature, the NFC device (<NUM>) performs at least one internal cryptographic operation (<NUM>, <NUM>) to generate a response before returning a record or a response. Alternatively, The record or response containing for example a payload may be prepared before receiving the read request (or other instruction) of the mobile.

The cryptographic operation may be symmetric and/or HMAC-SHA operation, where the response may be truncated or not, and/or be an asymmetric key operation where the response is a signature. Therefore, the record may be more trusted with such security operation.

The NDEF Application <NUM> of the NFC card, may interface with the mobile <NUM> through the contactless interface <NUM>. The card may have preferably a personalized secret <NUM> which could for example be a seed or key <NUM> or other generally used type of secret; The NFC device may preferably also have in the example, a counter <NUM> and an optional URL <NUM>. The NDEF application <NUM> is configured to generate a NDEF message, containing at least one NDEF record <NUM>, hereafter referred to as a record <NUM>.

Further, the NFC card <NUM> may comprise (as said before), a biometric sensor <NUM> for authenticating the user <NUM> by capturing <NUM> its fingerprint <NUM>. The sensor <NUM> may be any biometric sensor such as voice sensor, optical sensor.

Further, the NDEF application <NUM> is configured to gather data captured by the fingerprint sensor <NUM> or related to said captured data.

Further, the NDEF Application <NUM> may also gather data from the secondary EMV Application <NUM> or other software application. In particular, ATC counter value <NUM> may be accessed in a register with shared access to both application. A banking application alternatively, may memorize, duplicate, or transfer, at each banking transaction, the ATC counter value in a dedicated register accessible by the banking application at least in writing and the NDEF application at least in reading for the purpose of generation of a trusted NDEF record or response.

The sensor <NUM> (here fingerprint sensor) consists here of two internal part, the sensor (<NUM>-S) and the matcher sensor (<NUM>-M). The biometric data (fingerprint here) <NUM> which is captured by the sensor may be part of user's <NUM> credential <NUM>.

The sensor matcher (<NUM>-M) compares against a stored template (here fingerprint type) in an internal template database (<NUM>). The data base may contain multiple registered fingerprint templates <NUM> and associated indexes <NUM>.

If fingerprint <NUM> matches, the sensor <NUM> may raise a positive signal <NUM> (for example a high level of numeric signal) as long as the indicated valid fingerprint is present. The signal <NUM> (not shown) may also optionally provide the index (idx) <NUM> of the matched finger template <NUM>.

The user <NUM> is the one that is interacting with the Mobile Application <NUM>, and have a set of credentials <NUM>. These credentials may be entered <NUM> by the User <NUM> into the Mobile Application (<NUM>).

Once the mobile application <NUM> have been activated for use, the mobile application <NUM> may make use of an authenticator <NUM>.

The mobile application <NUM> may make use of authentication credentials <NUM> to authenticate the user, after the user have activated the mobile application <NUM>.

The secondary Banking Application <NUM> (or EMV application <NUM>), in the NFC device, may contains preferably an "application transaction counter", also named ATC <NUM> and a KEY <NUM> and a PAN <NUM> (Primary Account Number).

The banking server <NUM>, comprises a computer server with a server interface for interfacing with the network <NUM> to enable communication and access by the mobile <NUM>; the banking computer server contains a server application <NUM>, which provides the corresponding service to the user.

The banking server <NUM> also contains (or provides) a computed validation service <NUM>, which may performs validation response furnished via the mobile <NUM>; The response is preferably encrypted or of cryptographic type, wherein the encryption relies on PKI or comprises a certificate.

The banking server may comprise a server database <NUM> that may contains preferably information about the NFC device <NUM> (or card) details, such as value related to seeds <NUM> and counters <NUM>. The banking server may comprise transactional information, user credentials and information such as seeds and counters.

According to the preferred embodiment, the invention relates to a method and/or a system to create a trusted NDEF record <NUM> in an NFC electronic device <NUM>, in which an NDEF application <NUM> is provided in the NFC device;.

Said NDEF application is configured with computer executable code or steps to generate (preferably dynamically), a NDEF record based on data collected in the NDEF device and different for a previous generated one, as a result of the detection or on receipt of a request of an associated NDEF reader.

NDEF application <NUM> calculates at least one NDEF record <NUM> in response to a command or request (preferably during a same communication session but possibly during a previous session) including a command response communication between a communication of a contactless reader <NUM> and a contactless device <NUM>.

Said NDEF record (<NUM>-B) may be preferably created in real-time; It may be create advantageously at a format compatible with NDEF record standard. It may be read by a mobile having read only mode operation for read NDEF records.

The record (or message or response payload) may also be created in advance (because for example, there is not always banking transaction modifying ATC counter). Then, for example in a previous transaction, the ATC changes and upon this change a new record (<NUM>-B) is prepared (the energy of a POS or ATM or mobile may be used to power the operation of record creation).

Then, when user wants to use the trusted NDEF record, it may use it just by read it in a reading instruction of the mobile. The record (message) read is used or read like a static record tag but in fact it was updated few time before because it has dynamic capabilities. (In prior art, it seems that only static records in RFID tag devices currently read by NFC mobile).

Depending the operation or action to be made with the trusted record, the service provider (or server) may adapt the requirements or the security level of the trusted record. For example if the operation is not sensible, one may accept a record which have no ATC value change and was created not on real time during a session of command response.

The NDEF application (<NUM>) is configured to insert the data related to collected data (<NUM>, <NUM>, <NUM>, <NUM>) into payload(s) of selected NDEF record(s) and preferably recalculate, (preferably in same communication session (<NUM>) between NFC reader and NFC device), the length of said generated NDEF record and/or message. Alternatively, a new record <NUM>-B (<FIG>) may be calculated in advance (namely at the end of a communication session) to save time during a previous communication session between the device <NUM> and the mobile.

The new record <NUM>-B created in a session (one day for example) may be read during a next interaction with the mobile afterward (for example the day after).

This means that the read or capture record or payload by the mobile may be the one created during a previous request (or interaction with the mobile.

The advantage of creating the record in same communication session (mobile / card) is namely to have the last fresh data updated (such as ATC value) and to be more reliable (or trusted) record for sensitive operation. More the operation is sensitive more the read record must be fresh or updated.

A preferred embodiment or characteristic of the invention method will be described thereafter.

According to this embodiment, the method (and/or system) of the invention intends to create a trusted NDEF record <NUM> in an NFC electronic device <NUM>; To this purpose, the NFC device <NUM> is provided with an NDEF application <NUM> which is configured to generate, a NDEF record.

As yet explained a NDEF record is a record (or message or response) which is readable according to the NFC Data Exchange Format protocol.

<FIG> shows the structure of a NDEF record (<NUM>), where a first record (<NUM>) is read in a first session, represented as (<NUM>-A), and a second record (<NUM>) is read in a second session, represented as (<NUM>-B) by the mobile application <NUM>. The second record <NUM>-B may replace the first one in the NFC device. First one record may be erased or memorized aside in the NFC device for at least a period for historic.

The record (<NUM>) presented in <FIG> contains five separate protocol elements, where offset <NUM> contains control information, offset <NUM> is the length of the record type, offset <NUM> is the payload length, offset <NUM> is the record type, offset <NUM> is the identifier, and offset <NUM> is the payload.

We see that the payload of record <NUM>-A contains content "mybank. com/login?id=<NUM><NUM><NUM>9abcdef&counter=<NUM>&ATC=<NUM>&OTP = <NUM>". It represents a concatenation of captured data and dynamic response, consisting of URL (<NUM>) "mybank. com, that also may contain an action "login?", and may be included as part of the captured data, and then id blob (<NUM>) "Id=01234567abcdef", counter (<NUM>) "counter=<NUM>", ATC (<NUM>) "ATC=<NUM>", and then the cryptographically generated OTP "OTP=<NUM>", all being contained in record (<NUM>).

We see that the recalculation of length of payload between record <NUM>-A and <NUM>-B give same result since length does not change although counter changes.

This data, including the captured data are concatenated in a form that can easily be analyzed by the validator, and in the case of URI/URL NDEF format, these variables are concatenated as a query string.

Looking closer and comparing between the first captured record (<NUM>-A) in a first session and the second captured record (<NUM>-B) in a second session, and more specifically looking at Offset <NUM>, will now be detailed further.

The query name "id" also referred to as blob (<NUM>), represents the identity of the card and/or cardholder here exemplified with the value "0123456789abcdef", and this is same between both records.

Looking further, we see the query name "counter", and in the first record (<NUM>-A) has the value "<NUM>" and the second record (<NUM>-B) have the value "<NUM>", where the counter is incremented with one between the first and second session, and thereby creating a dynamic part in the record or message.

Then continuing and looking at the next query name "ATC" which has the value "<NUM>", captured from secondary application (<NUM>) are the same on both records (<NUM>). Indicating that no EMV Transaction have been performed in between first and second record generation. So here, ATC value in the generated response is here static (same than previous reading or generation of record) although it lead otherwise to a dynamic part of the record or message when there occur a transaction (namely banking transaction or payment. )with the card or NFC device) between two record captures or reading of NFC device.

Then continuing and looking at the next query name "OTP" which has the value "<NUM>"; and the second record (<NUM>-B) contains the value "<NUM>", constitutes a variable (or dynamic) a part of the NDEF record <NUM>-B, and which is included in the prepared response (Payload) to be read by the NFC reader. ) This dynamic response is preferably generated using a cryptographic calculation of the captured data, including a seed (<NUM>).

Here the record <NUM>-B includes in the payload message two dynamic part of the response which are the counter value and the OTP value (ATC did not changed). When the record <NUM>-B is read, the payload included in it is also read as a global response or message returned to the mobile according to a command response communication scheme.

The value of the query name "OTP" may be generated using any of the previous mentioned methods, and one example of such specification is the Open Authentication OCRA (RFC <NUM>), where it performs a HmacSHA256, using the seed and the concatenation of the challenge data and OCRA parameters response = HmacSha256 (seed, input).

In one example, the generation of the code = HMAC-SHA-<NUM> (seed, OCRASuite | '0x00' | C | Q), wherein the C is the counter, and Q contains a concatenation of the captured data, or the hash of the concatenated captured data, wherein the OCRASuite explains the type of cryptographic options. The response or code may be then used at least as "OTP".

Preferably, the record is generated dynamically. Dynamically means that it is on the fly, or in a very short period (ex. within the timeout windows of the contactless protocol during an interaction or communication session with the mobile <NUM>, during a reading session of the mobile comprising a mobile request and response).

In some cases, the card or (device <NUM>) may be powered by itself and provide an active communication or generate regularly said NDEF record just before the interaction with the mobile <NUM> and that could be valid during a short time.

The NDEF record is based on data collected in the NDEF device <NUM> by it or using it.

The data may include at least part of collected biometric data or a result of authentication made with collected biometric data.

The data may also include (with or no biometric related data) internal data in the NFC device that may changes regularly or not, such as the value of a counter of banking transaction ATC. It may comprise also the value of a counter of interaction with the mobile <NUM>.

Preferably, the NDEF record may different for a previous generated one to improve the security.

According to a characteristic, the generation of the NDEF record <NUM> is made as a result of the detection of a request of an associated NDEF reader; The generation of NDEF record <NUM> may also be made (trigger) on receipt of said request.

For that, each time a reader <NUM> (mobile) activates the NFC controller (or capabilities) of the mobile <NUM> and is brought close to the card <NUM> for read it through a contactless communication. The mobile send a read request according to the NDEF standard to the card to read the NDEF record <NUM>. This read request instruction from the mobile <NUM> is detected or simply received by card.

The NDEF application <NUM> may have the function to detect each read instruction coming from the mobile <NUM>. The chip controller may be a contactless electronic chip or dual interface chip (contact and contactless).

Each read instruction received may be detected by the chip controller which compares to predetermined instruction stored in a register memory of the chip. If the received instruction (or received message from the mobile) is an expected read instruction (namely with identification IMEI of the mobile, password, secret or any else specific), then the microcontroller (not shown) of the card <NUM> starts executing the NDEF application <NUM> (or program).

The read request instruction of the mobile may be accompanied by an identification number of the mobile <NUM> or something equivalent which is taken in account by the card <NUM> to trigger the generation of a new record.

The new record is a trusted one namely because:.

The trust level may be adjusted by implementing part or all of these security functions or operating mode. Preferably in banking environment, all may be implemented.

The microcontroller of the card <NUM> is configured to execute computer executable code or steps corresponding to the method steps, including namely the NDEF software application <NUM>.

The service provider server <NUM> (here a banking server), contains an application server <NUM>, which provides the service to the user. The banking server <NUM> also contains a validation service <NUM>, which performs validation of the cryptographic response. T, and a database <NUM> that contains information about the card details, EMV transactional information, user credentials, and information such as seeds and counters.

The bank server may also have an enrolment and provisioning server <NUM> that makes secure generation of authentication credential <NUM> and takes care of the provisioning of these. The bank may contain an EMV issuer authorization host <NUM> that authorizes EMV card payments transactions, and capture the last-ATC of the EMV Transaction and stores this in the database <NUM>.

Example <NUM> of the process or system usage: activation of a mobile application.

At <FIG>, a first use of the system of <FIG> is described and applied to a secure mobile application activation with a contactless card. The card is used as one security factor during a secure mobile banking activation.

Generally speaking, the steps in all the following figures may correspond to code instruction of a computer program (or software application) loaded in NFC device <NUM>, or mobile <NUM>, or server <NUM> and configured to be executed by processing means (microcontrollers or computers, in each entity <NUM>, <NUM>, <NUM>).

Software application <NUM> may also capture optional data such as blob <NUM> and ATC <NUM> from an EMV Application <NUM>. Said blob may take any form of data, such as an identity of the user and/or card, the Primary Account Number (PAN) and Expiry Date (EXP) either in clear text or encrypted/obfuscated format.

The NDEF application <NUM> may also capture any other optional data and therefore the data being captured are not limited to the ones described. For example, the data may come or be captured from outside the card such as a biometric data or a value related to said biometric data of the user.

Optionally the process can request the EMV application to generate an application cryptogram.

The generation of the response, may be a One-Time-Password, challenge-response, and may be based on open standards such as Open Authentication HOTP/OCRA or be based on closed or proprietary specifications. It is also possible that certain or all data is included as the challenge in the challenge-response, either as a concatenation of the data into a challenge block, a data structure, or a hash of the concatenated data. In the case that the NDEF Application <NUM> captures the fingerprint status <NUM>, it's preferred that the cryptographic operation uses a challenge response mechanism to be able to secure the state of the fingerprint sensor <NUM>.

The seed <NUM> may be a shared random value, a symmetric key or an asymmetric key, or a diversified key. As long as the bank may be able to verify the response ensure it is non-repayable any of these options are satisfactory.

The data format of the record may be either a JSON data block, XML block, or an URL. In the case of URL, the NDEF application <NUM> may uses the URL <NUM> as a base, and adds the variables as extension to create a final URL;.

Then the Mobile Application (<NUM>) then sends (<NUM>) the Record including with the Credentials (<NUM>) entered (<NUM>) by the user (<NUM>) in the Mobile Application (<NUM>) to the Application Server (<NUM>) over the communication network (<NUM>), where the network may be the internet and preferably using a secure communication link such as TLS. In a preferred embodiment, the data transmitted to the Application Server (<NUM>) may also be wrapped using encryption and integrity checks of the data using the Application Key Set (<NUM>) that is known only by the Mobile Application (<NUM>) and the Banking Server (<NUM>). By using this key, it is possible for the bank to verify that the request comes from a legitimate application.

Since the application server <NUM> in this embodiment only acts as a communication proxy, and only forwards the data back and forth, it can easily be omitted, and Mobile Application <NUM> can instead communicate directly with Validation Server <NUM>, and the validation server <NUM> can simply notify the application server <NUM> when the secure mobile application activation process has completed. Similar to this, is the case, when the application server <NUM> initiates the request, but secure mobile application activation is performed between Mobile Application <NUM> and validation Server <NUM>.

Example <NUM> of the process or system usage: Biometric authentication.

The NDEF application may also capture other optional data and therefore the data being captured are not limited to the ones described. During this process the NDEF application <NUM> increments the counter <NUM>.

The seed may be a shared random value, a diversified seed or key, a symmetric key or an asymmetric key, as long as the bank may be able to verify the authenticity and integrity and preferably also that the response is non-repayable.

In this embodiment, the system relies on the strong customer authentication from the card, but as seen in previous embodiment, a variation to this embodiment, would be that the validation server also verify additional user credential <NUM> entered by the user <NUM>.

In yet another example (or embodiment), the card may generate a <NUM>-factor Response (preferably dynamic) contained in a first record in the NDEF response, and a second at least two factor of response (preferably dynamic), consisting of at least fingerprint matching status, a seed and a counter as input, and creating a second Response (preferably dynamic) contained in a second record of the NDEF response <NUM>.

The term "dynamic" may mean that the card may calculate (or aggregate) a new record <NUM> base on fresh new data rather than sending the previous memorized one.

The calculation may preferably be made upon reception of a read request of a record from a reader. A NDEF program in the card is directed toward additional steps according to the preferred embodiment of invention (collect data, capture fingerprint, ATC. ) instead of responding to the reader request (operating preferably in read only mode) as in the prior art by sending a current memorized record (which may be always the same as static record).

Calculation may be also made after collection of new data, namely <NUM> (ATC). Alternatively, as soon as a new value of ATC is memorized by a banking application, the system or method may activate a calculation namely at the end of a transaction (causing the ATC change) or before a new operation. This may have the advantage to prepare (or generate) in advance at least part of the generation of a new record and respond faster to a mobile request. The new data may be the new value of the counter <NUM>, which may trigger a generation of at least a part of the record <NUM> as soon as its value change.

In yet another embodiment, wherein the user have exceeded the maximum number of attempts to verify his fingerprint against a stored fingerprint template stored in the fingerprint database <NUM>, the NDEF application <NUM> may generate a response (preferably dynamic) with a FP_MATCH_EXCEEDED.

As a variation to previous embodiments, embodiment <NUM> and <FIG> exemplifies, where the fingerprint database <NUM> contains multiple fingerprint templates, and upon fingerprint matching, the fingerprint matcher (<NUM>-M) searches all the fingerprint templates stored in the fingerprint database <NUM>, and if a match is found, the fingerprint matcher (<NUM>-M) also provides a fingerprint identifier linked to the stored fingerprint template as part of the fingerprint matching signal <NUM>, either an index <NUM> or a unique identifier.

The NDEF Application uses this fingerprint identifier as part of the input of the response (preferably dynamic). This allows to distinguish between different fingerprints, where each fingerprint identifier may be associated to a certain action on the Banking server <NUM> side.

The server side can then distinguish user's consent, by analyzing the fingerprint index <NUM> contained as input data and as part of the NDEF Record. This unique identifier may be part of the URL.

In the case of URL that is presented will depend on the status returned by the fingerprint reader:.

The card cannot determine which physical finger is presented to the sensor (<NUM>-S) of a user <NUM>, therefore this is a high level notion, but a registration process or a self-service portal may manage these relationships, (not shown here).

<FIG> & <FIG>, shows an embodiment that is a variation of embodiment <NUM> and <FIG>. Steps <NUM> to <NUM> of <FIG> & <FIG> are identical or similar to steps <NUM> to <NUM> of <FIG> and therefore are not described.

At step <NUM>, the generation of the response may be any cryptographic function, advantageously a HOTP or an OCRA challenge response. In the case of an OCRA challenge response the ATC and other captured data are also included as challenge input, including the fingerprint status <NUM>.

Then in the optional steps <NUM> and <NUM>, the validation server <NUM> verifies that the ATC, wherein the validation server <NUM> retrieves last-ATC in step <NUM>, which represent the stored value of the last-ATC <NUM>, which relates to the most recent EMV card transaction recognized and received by the EMV Authorization Host <NUM> relating to the EMV application <NUM>, and stored in database <NUM>;.

Then at step <NUM> and <NUM> the authentication credential (<NUM>) or reference is returned to the Mobile Application <NUM>.

In the case a reference is returned in step <NUM>, alternative additional steps <NUM> to <NUM> are performed, in the case when there is a separate system responsible for creating authentication credential <NUM> and provision them.

In this alternative step, the reference is associated to the authentication credential <NUM>, where the mobile application <NUM> connects to the enrolment and provisioning server <NUM> over the network <NUM> and provides the reference, the enrolment and provisioning server <NUM> will look up (extract) the reference in the database <NUM>, and if successful return the associated authentication credential <NUM> to the Mobile Application <NUM>. The enrolment and provisioning server <NUM> then removes any data relating to the authentication credential and reference from the database <NUM>.

Next time the user want to access the bank, the user can then use the authentication credential <NUM> from within the Mobile Application <NUM> and use this to authenticate himself towards the Bank Server <NUM>, (this flow is not exemplified).

<FIG> & <FIG>, shows yet another embodiment that is a variation of embodiment <NUM> and <FIG>, where the mobile application <NUM> in step <NUM> generates a local authentication credential <NUM>, which may be preceded at step <NUM> by a challenge generation request from the banking server side <NUM> since the mobile application requests activation at step <NUM>.

This package of data received by the validation server <NUM> (in step <NUM>) may be encrypted and/or integrity protected by the mobile application in previous step <NUM> using application key set <NUM>, which is shared between the mobile application <NUM> and the banking server <NUM>.

In order to make use of this extra security feature, the banking server (in an optional step not shown here), verifies the integrity and/or decrypt the message received in step <NUM>. If the process completes correctly it continues, otherwise it may abort the process.

There are many known ways to protect the integrity and encrypt the data, and any of these methods may be used, such as random key generation using asymmetric key to exchange the session keys, AES key. To strengthen it with software protection mechanism such as White-Box-Crypto to secure the App Key Set <NUM> may advantageously be used.

Then after the validation server <NUM> have executed correctly without any errors all steps from steps <NUM> to <NUM>, (indicating that a user credentials are authenticated, the card response has been correctly validated, the authentication credentials are validated), then the validation server <NUM> continues at step <NUM> and stores the authentication credential <NUM> with an association to the user <NUM> in the database <NUM>.

The authentication credential <NUM> (that the mobile application <NUM> shares with the banking server <NUM>), may either be a symmetric key such as DSKPP (RFC <NUM>), or an asymmetric key such as FIDO, but not limited to this.

In the case of FIDO key, the authentication credential <NUM> is partially split between the mobile application <NUM> and the banking server <NUM>, in order to increase security, where the public portion is shared with the banking server <NUM>, while the private part is kept either in the mobile application <NUM> or in the authenticator <NUM>.

The portion shared with the banking server <NUM> may also contain attestation details, e.g. in case when the authenticator <NUM> is a FIDO Authenticator. In the case of FIDO, this Authentication Credential contains at least a asymmetric key that is shared between the client and server, where the private part may be derived or diversified, allowing the bank server to validate future request using this key-pair.

In the case of DSKPP, the challenge may be omitted from the server, and the Authentication Credential <NUM> is a shared secret is exchanged between the Client and the Server.

Next time the user want to access the bank, the user can then use the authentication credential <NUM> from within the mobile application <NUM> and use this to authenticate himself towards the bank, this flow is not exemplified.

As it is well understood, the invention encompasses the following important features or advantages:
Namely it may relate to a method for a secure activation of a mobile application or for authenticating a customer, said method comprising the following step of:.

Thanks to the invention, the method is particularly useful to confirm or ascertain or determine the card or NFC device <NUM> presence with the user or customer during a sensitive operation. The user or customer is using the card or NFC device to determine that the user has both card and NFC reader <NUM> to access namely to a remote server.

Concerning identity or authentication, the server <NUM> may decrypts a blob emitted / generated from the NFC device, to retrieve an identity, representing the card, cardholder or the user.

Concerning banking or electronic transaction, the invention enables the ATC to be checked, during a normal EMV transaction, against a last or previous ATC, processed by the issuer authorization system, then stored in a database wherein the ATC represent the last EMV transaction.

The invention may include in any of embodiments the following steps:.

Concerning the activation, the invention may provide that:.

In yet another embodiment, the URL (<NUM>) is also part of the data collected, wherein the URL contains at least one portion that relates to an action. This collected data is input to the dynamic response, wherein captured data and response is included in record (<NUM>), and thereby be able to create a Record with trusted data. This Record (<NUM>) with the dynamic response can be tested for authenticity, either by the Mobile Application (<NUM>), or by the remote Validation Server (<NUM>). The verification step is to assemble the data in the same manner as assembled by the NDEF Application (<NUM>), and the use the seed (<NUM>) or a corresponding public key, and perform the cryptographic operation to verify that the input content, together with the seed (<NUM>) generates a result that compares with generated Dynamic Response.

The NDEF application <NUM> (or another software application according to the communication or coding technology used: 3D, OCR,. ) may be configured to generate or simulate a static information (record or NDEF format or 3D code information) before, during or after the implementation of a reading by the terminal (or reader).

Information may have the character or the format of a static information (record) or a file as a standardized NDEF information, but it can be real-time generated or simulated dynamically.

Information may be determined (trigged) or developed in function (or in response or through) all or part of actions performed (or even not conducted) by the user during a communication session on the device or the terminal. Triggering may be made upon detection or upon a receipt of a request of a NFC reader or after collection or capture (<NUM> of new data. It may also include for example detection of an action like submitting the card to the field of the terminal, placing a finger on a fingerprint, typing a pin code on a keyboard of the reader (or the card).

The NDEF application (alone or with another cooperating application) in the card (device) may preferably take care of instructions defined in the NDEF specification (for example at least instructions SELECT Application, SELECT File, and/or READ file).

The NDEF standard (specification) is generally designed to provide static information (tag or registration NDEF) stored or memorized by NFC devices in simple or basic RFID labels (tags), such as static URLs addresses, geographical data, etc. This information is static and unchanged until it is reprogrammed again or changed or replaced by new information namely by an NFC terminal (reader) containing also a corresponding NDEF application.

Claim 1:
A method to manage a trusted NDEF record (<NUM>, <NUM>-B) in an NFC device (<NUM>) comprising an NDEF application (<NUM>), said method comprising a step of generating a NDEF record (<NUM>) by said NDEF application,
characterized in that said NFC device comprises both a fingerprint reader (<NUM>) and a plurality of fingerprint templates having their own identifiers,
in that the identifier of each fingerprint template of said plurality of fingerprint templates is associated to a corresponding action to be performed on a remote server (<NUM>),
and in that the method comprises the following steps:
- capturing a captured fingerprint (<NUM>) read by the fingerprint reader,
- performing, by the NFC device, a detection or a receipt of a request (<NUM>) of a NFC reader,
- as a result of said detection or upon said receipt of the request (<NUM>) generating, by the NFC device, said NDEF record based on data collected (<NUM>, <NUM>, <NUM>, <NUM>) in the NFC device, said collected data including both an information related to the captured fingerprint (<NUM>) and the identifier (<NUM>) of the fingerprint template matching the captured fingerprint,
- reading, by the NFC reader, said NDEF record and forwarding, by the NFC reader, the NDEF record to the remote server (<NUM>), and
- triggering, by the remote server, the corresponding action associated to the identifier (<NUM>) of the fingerprint template comprised in the received NDEF record.