WO2016102834A1 - Procédé d'authentification d'un utilisateur et d'un module sécurisé, appareil électronique et système associes - Google Patents

Procédé d'authentification d'un utilisateur et d'un module sécurisé, appareil électronique et système associes Download PDF

Info

Publication number
WO2016102834A1
WO2016102834A1 PCT/FR2015/053605 FR2015053605W WO2016102834A1 WO 2016102834 A1 WO2016102834 A1 WO 2016102834A1 FR 2015053605 W FR2015053605 W FR 2015053605W WO 2016102834 A1 WO2016102834 A1 WO 2016102834A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
module
secure
app
secure module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2015/053605
Other languages
English (en)
Inventor
Emmanuelle Dottax
Philippe Muresianu
Michele Sartori
Fabien Cordier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Idemia France SAS
Original Assignee
Oberthur Technologies SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oberthur Technologies SA filed Critical Oberthur Technologies SA
Priority to US15/538,841 priority Critical patent/US10984080B2/en
Publication of WO2016102834A1 publication Critical patent/WO2016102834A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3231—Biological data, e.g. fingerprint, voice or retina
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/82—Protecting input, output or interconnection devices
    • G06F21/83—Protecting input, output or interconnection devices input devices, e.g. keyboards, mice or controllers thereof
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response

Definitions

  • the present invention relates to the authentication of a user by means of an electronic device.
  • It relates more particularly to a method of authenticating a user, as well as a secure module, an electronic device and an associated system.
  • the invention applies particularly advantageously in the case where a remote server requires the authentication of the user.
  • the authentication module performs a recognition (for example biometric) of the user and, when the result of the recognition is positive, the electronic device issues an authentication token to the requesting electronic entity authentication.
  • a recognition for example biometric
  • the present invention proposes a method of authenticating a user using an electronic device comprising an authentication module and a secure module, comprising the following steps:
  • the secure module is assured of the origin of the recognition result and the authentication token contains information relating to the authentication module that has actually generated this recognition result.
  • signing data is meant the application of a cryptographic signature algorithm to the data, using here the private key stored in the secure module.
  • the characteristic of the authentication module which thus forms part of the authentication token is, for example, an identifier of the authentication module, the type of authentication implemented by the authentication module, a cryptographic key protection method used. by the authentication module, or a communication method used by the authentication module.
  • the process for authentication of the authentication module by the secure module uses for example a private key of the authentication module.
  • the process for authenticating the authentication module by the secure module comprises the following steps:
  • the process for authenticating the authentication module by the secure module could include establishing a secure channel between the authentication module and issuing the recognition result of the authentication module to the secure module could then be done via this secure channel.
  • said public key is received by the secure module with an associated signature and the signature is verified by the secure module by means of a key stored in the secure module;
  • the recognition result is transmitted signed by means of the private key of the authentication module
  • the authentication method comprises a step of decrypting, by the authentication module, the private key of the authentication module from an encrypted version of the private key of the authentication module;
  • said encrypted version is stored in a non-volatile memory of the electronic apparatus
  • the private key of the authentication module obtained by the decryption step is stored in a random access memory of the electronic device;
  • the decryption step implements a decryption cryptographic algorithm using a key derived from data received (from a server requiring authentication or the secure module) and from data stored in the electronic device;
  • said representative data are received by the secure module from the authentication module with an associated signature and the signature is verified by means of a key stored in the secure module;
  • the authentication module comprises an authentication sensor
  • the recognition result is determined by the authentication module by comparison between data acquired by the authentication sensor and data stored by the authentication module;
  • the authentication module is implemented at least in part by an authentication application executed by a processor of the electronic device;
  • the electronic device is a mobile phone, or a digital tablet
  • the electronic apparatus comprises a holding element on a part of the body of the user (it may be for example a connected watch or glasses connected);
  • the secure module and the authentication module exchange data using an ISO 7816 or SPI or HCI / SWP type protocol.
  • the invention also proposes a secure module comprising at least a memory storing a private key and a processor programmed to implement the following steps (for example because of the execution by the processor of instructions stored in the aforementioned memory or another memory of the secure module):
  • the processor may be programmed to receive said signed representative data, that is to say with an associated signature, from the authentication module and to verify the signature of the representative data received by means of a key stored in the secure module.
  • the processor may also be programmed to implement the process for authentication of the authentication module by the secure module according to the following steps:
  • the processor can finally be programmed to check a signature of said public key by means of a key stored in the secure module.
  • the invention further provides an electronic apparatus comprising an authentication module, a secure module as proposed above, and a control unit storing an executable application by a processor of the control unit.
  • the application is for example a payment application or an access application.
  • the invention also proposes a system comprising a server and an electronic device as just mentioned, in which the electronic device is designed to transmit the generated authentication token at destination. of the server and wherein the server is adapted to receive the issued authentication token and to verify the received authentication token.
  • the server can also receive, for example during a previous step, data relating to the authentication module from another server.
  • the server may also issue an authorization or information message to the application in case of verification of the received authentication token.
  • FIG. 1 diagrammatically represents an example of context in which the invention can be implemented
  • FIG. 2 represents the main steps of an exemplary method of authenticating a user of an electronic device with a server
  • FIG. 3 represents the main steps of an alternative embodiment of the method of FIG. 2.
  • FIG. 1 schematically shows an example of context in which the invention can be implemented.
  • an electronic device 10 for example a mobile phone (or mobile phone), possibly of "intelligent” type, or “smartphone” according to the English name
  • a control unit 12 for example a mobile phone (or mobile phone), possibly of "intelligent” type, or “smartphone” according to the English name
  • the electronic device could be, for example, a digital tablet, a connected watch or connected glasses, in which case the electronic device comprises a holding element on a part of the body of the user (for example a bracelet in the case of a connected watch, or branches in the case of connected glasses).
  • the control unit 12 is for example a microcontroller which comprises a processor and memories, such as a random access memory and a rewritable non-volatile memory.
  • the control unit 12 stores, in at least one of the aforementioned memories, applications that allow, when they are executed by the processor, the implementation by the control unit 12 of processes such as those described above. low.
  • These applications include a client application 20, an authentication coordinator 22 and an authentication application 24.
  • the client application 20 is for example a payment application or an access application.
  • the authentication application 24 When executed by the processor of the control unit 12, the authentication application 24 cooperates with the authentication sensor 16 so as to form an authentication module 40 used as explained below.
  • an authentication module 40 or recognition module, is sometimes referred to by the English name "Recognition Factor" '. It can be a biometric recognition module (for example fingerprint recognition, iris recognition or face recognition), a voice recognition module or a personal code entry keyboard (or PIN). ).
  • the authentication module 40 could consist only of an application, interacting for example with a user interface (touch screen) for entering a personal code.
  • the secure module 30 and the authentication module 40 exchange data for example by means of an ISO 7816 type protocol, or SPI, or HCI / SWP
  • the client application 20 can exchange data, by means of the communication module 14 and via a telecommunication network 60, with a server 50 (for example a bank server when the client application 20 is a payment application).
  • a server for example a bank server when the client application 20 is a payment application.
  • a server is sometimes referred to as a "remote server” because it is accessible via a telecommunication network
  • the telecommunication network 60 comprises, for example, a mobile telephone network (including notably base stations designed to communicate by radio waves with the communication module 14) and a public computer network, such as the Internet.
  • the data can be exchanged using IP, GSM, http and / or https type protocols.
  • a server of an outside authority 70 is also connected to the telecommunication network 60 and can thus exchange data with the server 50 or with the electronic device 10.
  • some of the applications may be executed in a trusted execution environment (or TEE for "Trusted Execution Environment”), or even within another secure module (or secure element) present in the electronic device 10 and possibly associated with the authentication sensor 16.
  • TEE Trusted Execution Environment
  • the secure module 30 is for example an integrated secure element (or eSE for "embedded Secure Element”), for example welded in the electronic device 10.
  • eSE embedded Secure Element
  • it may be a microcircuit card, for example a subscriber card to a mobile network (or SIM card for "Subscriber Identity Module”), or a card type UICC (for "Universal Integrated Circuit Card”), or a secure micro-SD card.
  • the secure module 30 comprises a processor (for example a microprocessor) and memories, such as a random access memory and a rewritable non-volatile memory.
  • a processor for example a microprocessor
  • memories such as a random access memory and a rewritable non-volatile memory.
  • the server 50 stores the public key SE_Auth_PK associated with the private key authentication of the secure module SE_Auth_SK.
  • the private key for generating the authentication token SE_Auth_SK is not registered during a personalization phase as indicated above, but generated by the secure module 30 itself during a phase of authentication. registration (in English "registration") of the authentication module 40 to the server 50.
  • this recording phase it is possible for example to provide for the creation of a secure channel between the secure module 30 and the server 50 (for example after authentication of the identifier-password type, or "login / password" according to the English name), the generation of the key pair SE_Auth_SK / SE_Auth_PK by the secure module 30 and the transmission of the public key SE_Auth_PK to the server 50 via the secure channel.
  • the authentication application 24 has for its part access to the following data, stored for example in the rewritable non-volatile memory of the control unit 12:
  • a public key of the App_PK application and characteristic data C of the authentication module 40 signed by the private key of the external authority OT_SK (corresponding to the public key OT_PK mentioned above), that is to say accompanied a sign signature obtained by application, to the public key of the App_PK application and the characteristic data C, of a signature algorithm using the private key OT_SK;
  • Such data are for example written in the rewritable non-volatile memory during the installation of the authentication application 24 within the control unit 12. These data are not generally stored in a secure module, the sensitive data is stored in encrypted form, as indicated above.
  • the authentication application 24 is provided by (or in collaboration with) the external authority and the private key of the application App_SK can thus be encrypted by the secret key AEK derived (as explained more bottom) from the OT_Apps root key stored in the secure module 30 (also provided by the external authority). These data are used as explained below with reference to FIG.
  • FIG. 2 represents the main steps of a first exemplary method of authenticating a user of the electronic device 10 with the server 50.
  • This method is implemented when the server 50 which exchanges data with the client application 20 requires authentication of the user of the terminal 10.
  • the server of the external authority 70 transmits to the server 50 an identifier ID of the authentication module 40 as well as associated metadata, which for example represent characteristics of the authentication module 40.
  • step E2 the server 50 requires, as indicated above, a user authentication and thus sends an authentication request to the client application 20 with which it has previously exchanged data.
  • This authentication request is accompanied by the identifier ID of the authentication module to be used for this authentication and / or a set of criteria MC (for "Match Criteria") defining the possible characteristics of the required authentication and / or the authentication module allowing this authentication.
  • the set of criteria MC is for example a list of one or more element (s) each representing a combination of criteria accepted by the server 50 for the authentication of the user, each criterion corresponding to a possible characteristic of a authentication module, for example a type of authentication implemented by the authentication module (by facial recognition, by voice recognition, by iris recognition, by fingerprint recognition, by entering a personal code , etc.), a cryptographic key protection method used by the authentication module (use or not of a trusted execution environment, use or not of a secure module, etc.), a method of communication used by the authentication module.
  • the authentication request is received in step E4 by the client application 20, which transmits it (with the identifier ID and the set of criteria MC) to the authentication coordinator 22 (step E6).
  • the authentication coordinator 22 receives the authentication request with the identifier ID and the set of criteria MC and addresses in step E8 a request for recognition (or "Requesf recognition according to the Anglo-Saxon name) to the module 40 identified by the identifier ID, verifying that this authentication module 40 meets the criteria defined in the set of criteria MC received with the authentication request.
  • no identifier is transmitted and the authentication coordinator 22 then sends the recognition request to an authentication module verifying at least one of the combinations of criteria defined in the set of criteria MC.
  • the relevant authentication module 40 receives the recognition request in step E10.
  • the secure module 30 and the authentication module 40 use for example a Diffie-Hellman type schema, each generating an ephemeral key, by signing this ephemeral key with their secret key, verifying the signature. performed by the other module and, in the case of verification, deducing from these elements a common secret and session keys to be used to encrypt subsequent exchanges.
  • the authentication module 40 then generates an App_Ch challenge for the secure module 30, for example by random draw (step E12).
  • the authentication module 40 then transmits to the secure module 30 the challenge App_Ch, the derivation data App_Deriv and the public key of the application App_PK (accompanied by the characteristic data C of the authentication module), signed by the private key of the external authority OT_SK, that is to say with the signature Sign mentioned above (step E14).
  • the secure module 30 receives the challenge App_Ch, the derivation data App_Deriv, as well as the public key of the application App_PK and the characteristic data C of the authentication module 40, with the signature Sign, at the step E16 and verifies the Sign signature of the public key of the App_PK application and the characteristic data C of the authentication module 40 by means of a signature verification cryptographic algorithm and the public key of the external authority OT_PK (step E18).
  • the secure module 30 then generates in turn a SE_Ch challenge, for example by random draw, in step E20.
  • the secure module 30 then derives in step E22 a first derived key OT_App_K by applying a derivation function G to the root key OT_Apps and the derivation data App_Deriv:
  • OT_App_K G (OT_Apps, App_Deriv).
  • the secure module 30 generates a signature SIG1 by application to the challenge App_Ch generated in step E12 and received in step E16 of a signature cryptographic algorithm and the authentication private key of the secure module OT_Auth_SK (step E24).
  • the secure module 30 sends to the authentication module 40 the signature SIG1, the challenge SE_Ch generated in step E20 and the first key derived OT_App_K (step E26).
  • the authentication module 40 receives the signature SIG1, the challenge SE_Ch and the first key derived OT_App_K in step E28.
  • the authentication module 40 derives in step E30 a second derivative key AEK by applying a derivation function F to the first derived key OT_App_K and the derivation data App_AEK_Deriv (stored in non-volatile memory as already indicated) :
  • AEK F (OT_App_K, App_AEK_Deriv).
  • This second AEK derivation key is equal to the secret key with which the private key of the App_SK application stored in the control unit 12 has been encrypted in association with the authentication application 24.
  • the authentication application 24 has been provided by or in collaboration with the external authority which was able to calculate the secret key AEK and encrypt the private key of the application App_SK with this secret key AEK before installing the authentication application 24 in the device electronic 10).
  • the authentication module 40 can decrypt the private key of the application App_SK with the aid of this second derivation key AEK (step E32).
  • the private key of the App_SK application can then be momentarily stored in the RAM of the control unit 12.
  • the authentication module 40 then derives, in step E34, a third key derived from AIK by applying the derivation function F to the first derived key OT_App_K and to another derivation data, here the derivation data App_AIK_Deriv:
  • AIK F (OT_App_K, App_AIK_Deriv).
  • the authentication module 40 can thus verify in step E36 the integrity of the public key OT_Auth_PK by comparing a message authentication code obtained by application to the public key OT_Auth_PK of a cryptographic algorithm using a derived AIK key in step E34, and the message authentication code Mac stored in association with the public key OT_Auth_PK in the non-volatile memory of the control unit 12.
  • the authentication module 40 can verify the signature SIG1 using the public key OT_Auth_PK (step E38), for example by comparing the challenge App_Ch generated in step E12 and the result of the application to the received signature SIG1 of a signature verification cryptographic algorithm using the public key OT_Auth_PK.
  • the signature SIG1 can be verified by applying to the challenge App_Ch and to the received signature SIG1 a signature verification cryptographic algorithm using the public key OT_Auth_PK and producing (directly) a positive or negative result.
  • the authentication module 40 proceeds to the step E40 to the recognition of the user, for example by fingerprint recognition, which allows generate a recognition result R (positive or negative).
  • the recognition result R is generally determined by the authentication module by comparison between data acquired by the authentication sensor (for example biometric data representative of a suitable part of the body of the user placed facing the sensor of the user. authentication) and data stored by the authentication module 40, for example in the rewritable non-volatile memory of the control unit 12.
  • the latter data have for example been stored in advance by the authentication module 40 when a learning phase (sometimes referred to as the enrollment phase, the English name "enrollmenf").
  • step E40 and the challenge SE_Ch received in step E28 are signed by means of a cryptographic signature algorithm and the private key of the App_SK application momentarily stored in RAM (after which this private key App_SK can be erased from the RAM), which makes it possible to obtain a signature SIG2 (step E42).
  • the recognition result R and the signature SIG2 are sent from the authentication module 40 to the secure module 30 (step E44).
  • the secure module 30 thus receives in step E46 the recognition result R and the signature SIG2.
  • the secure module 30 can then check in step E48 the signature SIG2 using the public key of the App_PK application obtained in step E18, for example by applying this public key App_PK signature SIG2 by means of a signature verification cryptographic algorithm and comparing the result obtained to the received recognition result R and the challenge SE_Ch generated in step E20 (and sent to step E26).
  • the signature SIG2 can be verified by applying, to the recognition result R, to the challenge SE_Ch and to the received signature SIG2, a signature verification cryptographic algorithm using the public key App_PK and producing (directly) a positive result. or negative.
  • the secure module 30 can thus surely associate the characteristic data C of the authentication module 40 received in step E16 with the authenticated authentication module 40.
  • the signature SIG2 further makes it possible to ensure that the recognition result R is indeed that sent by the authentication module 40.
  • the secure module can therefore generate a TOK authentication token in step E50, by applying, to a set of data including at least part of the characteristic data C of the authentication module 40 , a cryptographic signature algorithm using the private authentication token generation key SE_Auth_SK.
  • the TOK authentication token may in particular include, in addition to this signature, the characteristic data C of the authentication module 40.
  • the aforementioned data set may also include a challenge (or "challenge" according to the English name) generated by the server 50 before step E2 and transmitted with the request for authentication of the server 50 to the server.
  • client application 20 step E2
  • the authentication coordinator 24 step E4
  • the authentication coordinator 24 to the authentication module 40 with the recognition request (step E8)
  • the authentication module 40 to the secure module 30 in step E14.
  • the characteristic data of the authentication module 40 included in the data signed by means of the private key SE_Auth_SK comprise for example an identifier of the authentication module and / or a type of authentication implemented by the authentication module and / or a cryptographic key protection method used by the authentication module and / or a communication method used by the authentication module.
  • the authentication token TOK is then sent by the secure module 30 to the authentication coordinator 22 (step E52), then from the authentication coordinator 22 to the client application 20 (step E54), then finally from the client application 20 to the server 50 (step E56).
  • the authentication token TOK is thus received by the server 50 at the step E58 and can be verified at the level of the server 50 by means of the public key SE_Auth_PK (possibly taking into account the challenge possibly generated by the server 50 before the step E2 as indicated above), which makes it possible to authenticate with the server 50 the user recognized by the authentication module 40.
  • the server 50 can also check on this occasion that the data set signed by the secure module 30 (step E50) includes the characteristics C of the authentication module 40 (for example included in the TOK authentication token) and that these comply with the defined criteria (before sending to step E2) in the set of MC criteria.
  • the validity of these characteristics C is guaranteed by their signature by means of the private key SE_Auth_SK stored in the secure module 30.
  • the server 50 can then send in step E60 a MOK authorization message (or authorization status information message) to the client application 20.
  • the client application 20 receives the MOK authorization message in step E62 and is thus informed of the success of the user authentication process.
  • the client application 20 can then command the display of a message indicative of successful authentication on a user interface (not shown) of the electronic device 10.
  • the server 50 stores a public key SE_Auth_PK for each authentication module-secure module module registered with the server 50.
  • the secure module 30 stores a certificate comprising the public key SE_Auth_PK (associated with its own private key SE_Auth_SK) and a signature of this public key SE_Auth_PK previously generated by a trusted authority (by means of a private key of this authority of confidence).
  • the secure module could then issue this certificate with the TOK authentication token (step E54) and the server could then first check the signature of the public key SE_Auth_PK contained in the certificate (by means of a public key of the trusted authority), then the TOK authentication token using the public key SE_Auth_PK (as in step E58).
  • FIG. 3 represents the main steps of an embodiment variant of the authentication method which has just been described with reference to FIG.
  • the root key OT_Apps is not stored in the secure module 30 but at the server 50;
  • the authentication application 24 stores (for example in the rewritable non-volatile memory of the control unit 12) the derivation data App_AEK_Deriv and App_AIK_Deriv, but the data of derivation App_Deriv visible in FIG. not used.
  • This variant is usable when the authentication application 24 has not been provided by (or in collaboration with) the external authority having provided the secure module 30.
  • the server 50 sends an authentication request to the client application 20.
  • This authentication request is accompanied by the identifier ID of the authentication module to be used for this authentication and / or a set of criteria MC (for "Match Criteria"), of the same type as described above with reference in Figure 2 and in which was introduced further the root key OT_Apps (for example within a dedicated specific field).
  • the authentication request accompanied by the identifier ID and the set of criteria MC integrating the root key OT_Apps is received by the client application 20 in step E102 and sent to the authentication coordinator 22.
  • the authentication coordinator 22 thus receives the identifier ID and the set of criteria MC integrating the root key OT_Apps in step E104.
  • the authentication coordinator 22 can thus transmit, to the authentication module 40 designated by the identifier ID and / or respecting the criteria defined in the set of criteria MC, a request for recognition accompanied by the set of criteria.
  • MC integrating the root key OT_Apps (step E106).
  • the authentication module 40 receives the recognition request in the step E108 and can thus extract from the set of criteria MC the root key OT_Apps in the step E1 10.
  • the authentication module 40 can thus calculate in step E1 12 the key derivative AEK, by applying a derivation function H to the root key OT_Apps (extracted in step E1 10) and the derivation data App_AEK_Deriv (stored in association with the authentication application 24, as indicated above ):
  • AEK H (OT_Apps, App_AEK_Deriv).
  • the AEK derived key was used beforehand (before installation of the authentication application 24 in the electronic device 10) to encrypt the private key App_SK application.
  • the authentication module 40 can therefore decrypt the private key of the App_SK application (stored in encrypted form in the non-volatile memory of the control unit 12) by applying a decryption algorithm using the derived key AEK (step E1 14) and store, temporarily, the private key of the application App_SK (not encrypted) in the RAM of the control unit 12.
  • the authentication module 40 then generates an App_Ch challenge, for example by random draw (step E1 16).
  • the authentication module 40 then transmits in step E1 18 the public key of the application App_PK and the characteristic data C of the authentication module 40, signed by the private key of the external authority OT_SK and therefore accompanied by the Sign signature, as well as the App_Ch challenge.
  • This data is received by the secure module 30 in step E120.
  • the secure module 30 verifies in step E122 the Sign signature of the public key of the App_PK application and the characteristic data C of the authentication module 40 by means of a cryptographic signature verification algorithm and the public key of the external authority OT_PK (stored as indicated in FIG. 1 in the non-volatile memory of the secure module 30).
  • the secure module 30 then generates a SE_Ch challenge, for example by random draw (step E124).
  • the secure module 30 generates a signature SIG1 by application to the challenge App_Ch, generated in step E1 16 and received in step E120, of a signature cryptographic algorithm using the authentication private key of the secure module OT_Auth_SK (step E126 ).
  • step E126 the secure module 30 transmits the signature SIG1 and the challenge SE_Ch generated in step E124 to the authentication module 40.
  • the authentication module 40 receives the signature SIG1 and the challenge SE_Ch in step E128.
  • the authentication module 40 then derives, in step E130, an AIK derived key by applying the derivation function H to the root key OT_Apps extracted in step E1 10 and to another derivation data, here the derivation data App_AIK_Deriv:
  • AIK H (OT_Apps, App_AIK_Deriv).
  • step E36 The method then continues as indicated above with reference to Figure 2 from step E36.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Telephone Function (AREA)

Abstract

L'invention concerne un procédé d'authentification d'un utilisateur à l'aide d'un appareil électronique (10) comprenant un module d'authentification (40) et un module sécurisé (30), comprenant les étapes suivantes : - émission par le module d'authentification (40) d'un résultat de reconnaissance à destination du module sécurisé (30) selon un processus permettant l'authentification du module d'authentification (40) par le module sécurisé (30); - génération d'un jeton d'authentification par le module sécurisé (30) par signature, au moyen d'une clé privée (SE_Auth_SK) mémorisée dans le module sécurisé (30), de données comprenant des données représentatives d'au moins une caractéristique du module d'authentification (40); - émission du jeton d'authentification généré. Un module sécurisé, un appareil électronique et un système associés sont également décrits.

Description

PROCEDE D'AUTHENTIFICATION D'UN UTILISATEUR ET D'UN MODULE
SECURISE, APPAREIL ELECTRONIQUE ET SYSTEME ASSOCIES
DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne l'authentification d'un utilisateur au moyen d'un appareil électronique.
Elle concerne plus particulièrement un procédé d'authentification d'un utilisateur, ainsi qu'un module sécurisé, un appareil électronique et un système associés.
L'invention s'applique particulièrement avantageusement dans le cas où un serveur distant requiert l'authentification de l'utilisateur.
ARRIERE-PLAN TECHNOLOGIQUE
Il est connu d'utiliser un appareil électronique équipé d'un module d'authentification afin d'authentifier un utilisateur de l'appareil électronique auprès d'une entité électronique requérant une telle authentification, par exemple un serveur distant en communication avec une application exécutée sur l'appareil électronique.
Pour ce faire, le module d'authentification effectue une reconnaissance (par exemple biométrique) de l'utilisateur et, lorsque le résultat de la reconnaissance est positif, l'appareil électronique émet un jeton d'authentification à destination de l'entité électronique requérant l'authentification.
OBJET DE L'INVENTION
Dans ce contexte, la présente invention propose un procédé d'authentification d'un utilisateur à l'aide d'un appareil électronique comprenant un module d'authentification et un module sécurisé, comprenant les étapes suivantes :
- émission par le module d'authentification d'un résultat de reconnaissance à destination du module sécurisé selon un processus permettant l'authentification du module d'authentification par le module sécurisé ;
- génération d'un jeton d'authentification par le module sécurisé par signature, au moyen d'une clé privée mémorisée dans le module sécurisé, de données comprenant des données représentatives d'au moins une caractéristique du module d'authentification ;
- émission du jeton d'authentification généré. Ainsi, le module sécurisé est assuré de la provenance du résultat de reconnaissance et le jeton d'authentification contient des informations relatives au module d'authentification qui a effectivement généré ce résultat de reconnaissance.
On entend par signature des données l'application d'un algorithme cryptographique de signature aux données, utilisant ici la clé privée mémorisée dans le module sécurisé.
La caractéristique du module d'authentification qui fait ainsi partie du jeton d'authentification est par exemple un identifiant du module d'authentification, le type d'authentification mise en œuvre par le module d'authentification, une méthode de protection des clés cryptographiques utilisée par le module d'authentification, ou une méthode de communication utilisée par le module d'authentification.
Le processus permettant l'authentification du module d'authentification par le module sécurisé utilise par exemple une clé privée du module d'authentification.
Selon un mode de réalisation envisageable, le processus permettant l'authentification du module d'authentification par le module sécurisé comprend les étapes suivantes :
transmission d'un défi du module sécurisé au module d'authentification ;
- génération d'une réponse par le module d'authentification par application au défi d'un algorithme de signature utilisant la clé privée du module d'authentification ;
- transmission de la réponse du module d'authentification au module sécurisé ;
- vérification de la réponse par le module sécurisé au moyen de la clé publique associée à la clé privée du module d'authentification.
En variante, le processus permettant l'authentification du module d'authentification par le module sécurisé pourrait comprendre l'établissement d'un canal sécurisé entre le module d'authentification et l'émission du résultat de reconnaissance du module d'authentification au module sécurisé pourrait alors être réalisée via ce canal sécurisé.
Selon des caractéristiques optionnelles, et donc non limitatives : - ladite clé publique est reçue par le module sécurisé avec une signature associée et la signature est vérifiée par le module sécurisé au moyen d'une clé mémorisée dans le module sécurisé ;
- le résultat de reconnaissance est émis signé au moyen de la clé privée du module d'authentification ;
- le procédé d'authentification comprend une étape de déchiffrement, par le module d'authentification, de la clé privée du module d'authentification à partir d'une version chiffrée de la clé privée du module d'authentification ;
- ladite version chiffrée est mémorisée dans une mémoire non-volatile de l'appareil électronique ;
- la clé privée du module d'authentification obtenue par l'étape de déchiffrement est mémorisée dans une mémoire vive de l'appareil électronique ;
- l'étape de déchiffrement met en œuvre un algorithme cryptographique de déchiffrement utilisant une clé dérivée à partir de données reçues (d'un serveur requérant l'authentification ou du module sécurisé) et de données mémorisées dans l'appareil électronique ;
- lesdites données représentatives sont reçues par le module sécurisé en provenance du module d'authentification avec une signature associée et la signature est vérifiée au moyen d'une clé mémorisée dans le module sécurisé ;
- le module d'authentification comprend un capteur d'authentification ;
- le résultat de reconnaissance est déterminé par le module d'authentification par comparaison entre des données acquises par le capteur d'authentification et des données mémorisées par le module d'authentification ;
- le module d'authentification est mis en œuvre au moins en partie par une application d'authentification exécutée par un processeur de l'appareil électronique ;
- l'appareil électronique est un téléphone mobile, ou une tablette numérique ;
- l'appareil électronique comprend un élément de maintien sur une partie du corps de l'utilisateur (il peut s'agir par exemple d'une montre connectée ou de lunettes connectées) ;
- le module sécurisé et le module d'authentification échangent des données au moyen d'un protocole de type ISO 7816 ou SPI ou HCI/SWP.
L'invention propose également un module sécurisé comprenant au moins une mémoire mémorisant une clé privée et un processeur programmé pour mettre en œuvre les étapes suivantes (par exemple du fait de l'exécution par le processeur d'instructions mémorisées dans la mémoire susmentionnée ou une autre mémoire du module sécurisé) :
- réception, en provenance d'un module d'authentification, d'un résultat de reconnaissance selon un processus permettant l'authentification du module d'authentification par le module sécurisé ;
- génération d'un jeton d'authentification par signature, au moyen de ladite clé privée, de données comprenant des données représentatives d'au moins une caractéristique du module d'authentification ;
- émission du jeton d'authentification généré.
Selon une possibilité de réalisation, le processeur peut être programmé pour recevoir lesdites données représentatives signées, c'est-à-dire avec une signature associée, en provenance du module d'authentification et pour vérifier la signature des données représentatives reçues au moyen d'une clé mémorisée dans le module sécurisé.
Le processeur peut par ailleurs être programmé pour mettre en œuvre le processus permettant l'authentification du module d'authentification par le module sécurisé selon les étapes suivantes :
- émission d'un défi à destination du module d'authentification ;
- réception d'une réponse en provenance du module d'authentification ;
- vérification de la réponse au moyen d'une clé publique associée à une clé privée du module d'authentification.
Le processeur peut enfin être programmé pour vérifier une signature de ladite clé publique au moyen d'une clé mémorisée dans le module sécurisé.
L'invention propose en outre un appareil électronique comprenant un module d'authentification, un module sécurisé tel que proposé ci-dessus, et une unité de commande mémorisant une application exécutable par un processeur de l'unité de commande.
L'application est par exemple une application de paiement ou une application d'accès.
L'invention propose aussi un système comprenant un serveur et un appareil électronique comme il vient d'être mentionné, dans lequel l'appareil électronique est conçu pour émettre le jeton d'authentification généré à destination du serveur et dans lequel le serveur est conçu pour recevoir le jeton d'authentification émis et pour vérifier le jeton d'authentification reçu.
Le serveur peut en outre recevoir, par exemple au cours d'une étape préalable, des données relatives au module d'authentification en provenance d'un autre serveur. Le serveur peut également émettre un message d'autorisation ou d'information à destination de l'application en cas de vérification du jeton d'authentification reçu.
DESCRIPTION DÉTAILLÉE D'UN EXEMPLE DE RÉALISATION
La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée.
Sur les dessins annexés :
- la figure 1 représente schématiquement un exemple de contexte dans lequel peut être mise en œuvre l'invention ;
- la figure 2 représente les étapes principales d'un exemple de procédé d'authentification d'un utilisateur d'un appareil électronique auprès d'un serveur ; et
- la figure 3 représente les étapes principales d'une variante de réalisation du procédé de la figure 2.
La figure 1 représente schématiquement un exemple de contexte dans lequel peut être mise en œuvre l'invention.
Dans cet exemple de contexte, un appareil électronique 10 (par exemple un téléphone portable (ou téléphone mobile), éventuellement de type "intelligent', ou "smartphone" selon l'appellation anglo-saxonne) comprend une unité de commande 12, un module de communication 14, un capteur d'authentification 16 et un module sécurisé 30. En variante, l'appareil électronique pourrait être par exemple une tablette numérique, une montre connectée ou des lunettes connectées. Dans ces derniers cas, l'appareil électronique comprend un élément de maintien sur une partie du corps de l'utilisateur (par exemple un bracelet dans le cas d'une montre connectée, ou des branches dans le cas de lunettes connectées).
L'unité de commande 12 est par exemple un microcontrôleur qui comprend un processeur et des mémoires, telles qu'une mémoire vive et une mémoire non-volatile réinscriptible. L'unité de commande 12 mémorise, dans l'une au moins des mémoires susmentionnées, des applications qui permettent, lorsqu'elles sont exécutées par le processeur, la mise en œuvre par l'unité de commande 12 de procédés tels que ceux décrits plus bas.
Ces applications comprennent notamment une application client 20, un coordinateur d'authentification 22 et une application d'authentification 24.
L'application client 20 est par exemple une application de paiement ou une application d'accès.
Lorsqu'elle est exécutée par le processeur de l'unité de commande 12, l'application d'authentification 24 coopère avec le capteur d'authentification 16 de manière à former un module d'authentification 40 utilisé comme expliqué dans la suite. Un tel module d'authentification 40, ou module de reconnaissance, est parfois désigné par l'appellation anglo-saxonne "Récognition Factor" '. Il peut s'agir d'un module de reconnaissance biométrique (par exemple reconnaissance d'empreinte digitale, reconnaissance d'iris ou reconnaissance faciale), d'un module de reconnaissance vocale ou d'un clavier de saisie de code personnel (ou PIN). Dans certains modes de réalisation, le module d'authentification 40 pourrait être constitué seulement d'une application, interagissant par exemple avec une interface utilisateur (écran tactile) pour la saisie d'un code personnel.
Au sein de l'appareil électronique 10, le module sécurisé 30 et le module d'authentification 40 échangent des données par exemple au moyen d'un protocole de type ISO 7816, ou SPI, ou encore HCI/SWP
L'application client 20 peut échanger des données, au moyen du module de communication 14 et via un réseau de télécommunication 60, avec un serveur 50 (par exemple un serveur bancaire lorsque l'application client 20 est une application de paiement). On dénomme parfois "serveur distant' un tel serveur du fait qu'il est accessible via un réseau de télécommunication. Lorsque l'appareil électronique 10 est un téléphone portable, le réseau de télécommunication 60 comprend par exemple un réseau de téléphonie mobile (comprenant notamment des stations de base conçues pour communiquer par ondes radio avec le module de communication 14) et un réseau informatique public, tel que le réseau Internet. Les données peuvent être échangées au moyen de protocoles de type IP, GSM, http et/ou https.
Un serveur d'une autorité extérieure 70 est également connecté au réseau de télécommunication 60 et peut ainsi échanger des données avec le serveur 50 ou avec l'appareil électronique 10.
Dans certains modes de réalisation envisageable, certaines des applications peuvent être exécutées dans un environnement d'exécution de confiance (ou TEE pour "Trusted Execution Environment'), voire au sein d'un autre module sécurisé (ou élément sécurisé) présent dans l'appareil électronique 10 et éventuellement associé au capteur d'authentification 16.
Le module sécurisé 30 est par exemple un élément sécurisé intégré (ou eSE pour "embedded Secure Elément"), par exemple soudé dans l'appareil électronique 10. En variante, il peut s'agir d'une carte à microcircuit, par exemple une carte d'abonnement à un réseau de téléphonie mobile (ou carte SIM pour "Subscriber Identity Module"), ou une carte de type UICC (pour "Universal Integrated Circuit Card'), ou encore une carte micro-SD sécurisée.
Le module sécurisé 30 comprend un processeur (par exemple un microprocesseur) et des mémoires, telles qu'une mémoire vive et une mémoire non volatile réinscriptible.
Une mémoire non volatile du module sécurisé 30, par exemple la mémoire non volatile réinscriptible, mémorise les clés cryptographiques suivantes, qui ont par exemple été inscrites dans cette mémoire lors d'une phase de personnalisation du module sécurisé 30 par l'autorité extérieure :
- une clé publique de l'autorité extérieure OT_PK ;
- une clé racine OT_Apps (utilisable pour toutes les applications d'authentification préparées par ou en collaboration avec l'autorité extérieure) ;
- une clé privée de génération de jeton d'authentification SE_Auth_SK ;
- une clé privée d'authentification du module sécurisé OT_Auth_SK.
On remarque que ces clés sont mémorisées chiffrées ou non au sein du module sécurisé rendu inaccessible du fait de son haut niveau de sécurité. Ainsi, le module sécurisé 30 assure la confidentialité et l'intégrité des clés stockées.
Le serveur 50 mémorise la clé publique SE_Auth_PK associée à la clé privée d'authentification du module sécurisé SE_Auth_SK.
Selon une variante envisageable, la clé privée de génération du jeton d'authentification SE_Auth_SK n'est pas inscrite lors d'une phase de personnalisation comme indiqué ci-dessus, mais générée par le module sécurisé 30 lui-même lors d'une phase d'enregistrement (en anglais "registration") du module d'authentification 40 auprès du serveur 50.
Lors de cette phase d'enregistrement, on peut par exemple prévoir la création d'un canal sécurisé entre le module sécurisé 30 et le serveur 50 (par exemple après une authentification de type identifiant - mot de passe, ou "login/password" selon l'appellation anglo-saxonne), la génération de la paire de clés SE_Auth_SK/SE_Auth_PK par le module sécurisé 30 et la transmission de la clé publique SE_Auth_PK au serveur 50 via le canal sécurisé.
L'application d'authentification 24 a quant à elle accès aux données suivantes, mémorisées par exemple dans la mémoire non volatile réinscriptible de l'unité de commande 12 :
- une clé privée de l'application App_SK, chiffrée par une clé secrète AEK (et notée de ce fait [App_SK]AEK sur les figures) ;
- une clé publique de l'application App_PK et des données caractéristiques C du module d'authentification 40, signées par la clé privée de l'autorité extérieure OT_SK (correspondant à la clé publique OT_PK susmentionnée), c'est-à-dire accompagnée d'une signature Sign obtenue par application, à la clé publique de l'application App_PK et aux données caractéristiques C, d'un algorithme de signature utilisant la clé privée OT_SK ;
- des données de dérivation de clé App_Deriv, App_AEK_Deriv, App_AIK_Deriv (spécifiques à l'application concernée) ;
- la clé publique OT_Auth_PK correspondant à la clé privée d'authentification du module sécurisé OT_Auth_SK et un code d'authentification de message Mac obtenu par application à la clé publique OT_Auth_PK d'un algorithme cryptographique utilisant une clé AIK.
De telles données sont par exemple inscrites dans la mémoire non volatile réinscriptible lors de l'installation de l'application d'authentification 24 au sein de l'unité de commande 12. Ces données n'étant en général pas mémorisées dans un module sécurisé, les données sensibles sont mémorisées sous forme chiffrée, comme indiqué ci-dessus.
Dans l'exemple décrit ici, l'application d'authentification 24 est fournie par (ou en collaboration avec) l'autorité extérieure et la clé privée de l'application App_SK peut ainsi être chiffrée par la clé secrète AEK dérivée (comme expliqué plus bas) à partir de la clé racine OT_Apps mémorisée dans le module sécurisé 30 (également fourni par l'autorité extérieure). Ces données sont utilisées comme expliqué ci-dessous en référence à la figure 2.
La figure 2 représente les étapes principales d'un premier exemple de procédé d'authentification d'un utilisateur de l'appareil électronique 10 auprès du serveur 50.
Ce procédé est mis en œuvre lorsque le serveur 50 qui échange des données avec l'application client 20 requiert une authentification de l'utilisateur du terminal 10.
Lors d'une étape préalable E0 (effectuée par exemple lors de l'installation de l'application d'authentification 24 au sein de l'appareil électronique 10), le serveur de l'autorité extérieure 70 transmet au serveur 50 un identifiant ID du module d'authentification 40 ainsi que des métadonnées associées, qui représentent par exemple des caractéristiques du module d'authentification 40.
À l'étape E2, le serveur 50 requiert comme indiqué ci-dessus une authentification de l'utilisateur et émet ainsi une requête d'authentification à destination de l'application client 20 avec laquelle il a préalablement échangé des données. Cette requête d'authentification est accompagnée de l'identifiant ID du module d'authentification à utiliser pour cette authentification et/ou d'un ensemble de critères MC (pour "Match Criteria") définissant les caractéristiques possibles de l'authentification requise et/ou du module d'authentification permettant cette authentification. L'ensemble de critères MC est par exemple une liste d'un ou plusieurs élément(s) représentant chacun une combinaison de critères acceptée par le serveur 50 pour l'authentification de l'utilisateur, chaque critère correspondant à une caractéristique possible d'un module d'authentification, par exemple un type d'authentification mise en œuvre par le module d'authentification (par reconnaissance faciale, par reconnaissance vocale, par reconnaissance d'iris, par reconnaissance d'empreinte digitale, par saisie d'un code personnel, etc.), une méthode de protection des clés cryptographiques utilisée par le module d'authentification (utilisation ou non d'un environnement d'exécution de confiance, utilisation ou non d'un module sécurisé, etc.), une méthode de communication utilisée par le module d'authentification.
La requête d'authentification est reçue à l'étape E4 par l'application client 20, qui la transmet (avec l'identifiant ID et l'ensemble de critères MC) au coordinateur d'authentification 22 (étape E6). Le coordinateur d'authentification 22 reçoit la requête d'authentification avec l'identifiant ID et l'ensemble de critères MC et adresse à l'étape E8 une demande de reconnaissance (ou "Récognition Requesf selon l'appellation anglo- saxonne) au module d'authentification 40 désigné par l'identifiant ID, en vérifiant que ce module d'authentification 40 respecte les critères définis dans l'ensemble de critères MC reçu avec la requête d'authentification. Dans certains modes de réalisation, aucun identifiant n'est transmis et le coordinateur d'authentification 22 envoie alors la demande de reconnaissance à un module d'authentification vérifiant l'une au moins des combinaisons de critères définie dans l'ensemble de critères MC.
Le module d'authentification concerné 40 (en pratique l'application d'authentification 24) reçoit la demande de reconnaissance à l'étape E10.
Selon une variante de réalisation différente de celle décrite ici, on peut alors établir un canal sécurisé entre le module d'authentification et le module de sécurisé, ce qui permet d'empêcher un attaquant passif d'avoir accès (par simple observation) aux données échangées.
Pour ce faire, le module sécurisé 30 et le module d'authentification 40 utilisent par exemple un schéma de type Diffie-Hellman, en générant chacun de leur côté une clé éphémère, en signant cette clé éphémère avec leur clé secrète, en vérifiant la signature effectuée par l'autre module et, en cas de vérification, en déduisant de ces éléments un secret commun et des clés de session à utiliser pour chiffrer les échanges ultérieurs.
Dans le mode de réalisation décrit ici, le module d'authentification 40 génère alors un défi App_Ch destiné au module sécurisé 30, par exemple par tirage aléatoire (étape E12).
Le module d'authentification 40 émet alors à destination du module sécurisé 30 le défi App_Ch, la donnée de dérivation App_Deriv et la clé publique de l'application App_PK (accompagnée des données caractéristiques C du module d'authentification), signée par la clé privée de l'autorité extérieure OT_SK, c'est-à-dire avec la signature Sign mentionnée plus haut (étape E14).
On remarque que les échanges de données sont ici réalisés directement entre le module d'authentification 40 et le module sécurisé 30, mais pourraient éventuellement être réalisés via le coordinateur d'authentification 22 (sans traitement des données par celui-ci). Le module sécurisé 30 reçoit le défi App_Ch, la donnée de dérivation App_Deriv, ainsi que la clé publique de l'application App_PK et les données caractéristiques C du module d'authentification 40, avec la signature Sign, à l'étape E16 et vérifie la signature Sign de la clé publique de l'application App_PK et des données caractéristiques C du module d'authentification 40 au moyen d'un algorithme cryptographique de vérification de signature et de la clé publique de l'autorité extérieure OT_PK (étape E18).
Le module sécurisé 30 génère alors à son tour un défi SE_Ch, par exemple par tirage aléatoire, à l'étape E20.
Le module sécurisé 30 dérive ensuite à l'étape E22 une première clé dérivée OT_App_K par application d'une fonction de dérivation G à la clé racine OT_Apps et à la donnée de dérivation App_Deriv :
OT_App_K=G(OT_Apps, App_Deriv).
Le module sécurisé 30 génère une signature SIG1 par application au défi App_Ch généré à l'étape E12 et reçu à l'étape E16 d'un algorithme cryptographique de signature et de la clé privée d'authentification du module sécurisé OT_Auth_SK (étape E24).
Le module sécurisé 30 émet à destination du module d'authentification 40 la signature SIG1 , le défi SE_Ch généré à l'étape E20 et la première clé dérivée OT_App_K (étape E26).
Le module d'authentification 40 reçoit la signature SIG1 , le défi SE_Ch et la première clé dérivée OT_App_K à l'étape E28.
Le module d'authentification 40 dérive à l'étape E30 une seconde clé dérivée AEK par application d'une fonction de dérivation F à la première clé dérivée OT_App_K et à la donnée de dérivation App_AEK_Deriv (mémorisée en mémoire non-volatile comme déjà indiqué) :
AEK = F(OT_App_K,App_AEK_Deriv).
Cette seconde clé de dérivation AEK est égale à la clé secrète avec laquelle a été chiffrée la clé privée de l'application App_SK mémorisée dans l'unité de commande 12 en association avec l'application d'authentification 24. (Comme déjà indiqué, dans le mode de réalisation décrit ici, l'application d'authentification 24 a été fournie par ou en collaboration avec l'autorité extérieure qui a pu calculer la clé secrète AEK et chiffrer la clé privée de l'application App_SK avec cette clé secrète AEK avant installation de l'application d'authentification 24 dans l'appareil électronique 10).
Ainsi, le module d'authentification 40 peut déchiffrer la clé privée de l'application App_SK à l'aide de cette seconde clé de dérivation AEK (étape E32). La clé privée de l'application App_SK peut alors être momentanément mémorisée dans la mémoire vive de l'unité de commande 12.
Le module d'authentification 40 dérive ensuite à l'étape E34 une troisième clé dérivée AIK par application de la fonction de dérivation F à la première clé dérivée OT_App_K et à une autre donnée de dérivation, ici la donnée de dérivation App_AIK_Deriv :
AIK = F(OT_App_K,App_AIK_Deriv).
Le module d'authentification 40 peut ainsi vérifier à l'étape E36 l'intégrité de la clé publique OT_Auth_PK en comparant un code d'authentification de message, obtenu par application à la clé publique OT_Auth_PK d'un algorithme cryptographique utilisant une clé AIK dérivée à l'étape E34, et le code d'authentification de message Mac mémorisé en association avec la clé publique OT_Auth_PK dans la mémoire non-volatile de l'unité de commande 12.
Si cette vérification est positive, le module d'authentification 40 peut vérifier la signature SIG1 à l'aide de la clé publique OT_Auth_PK (étape E38), en comparant par exemple le défi App_Ch généré à l'étape E12 et le résultat de l'application à la signature reçue SIG1 d'un algorithme cryptographique de vérification de signature utilisant la clé publique OT_Auth_PK. Selon une variante envisageable, la signature SIG1 peut être vérifiée en appliquant, au défi App_Ch et à la signature reçue SIG1 , un algorithme cryptographique de vérification de signature utilisant la clé publique OT_Auth_PK et produisant (directement) un résultat positif ou négatif.
Si la signature SIG1 est correctement vérifiée, ceci implique que le module sécurisé 30 s'est correctement authentifié auprès du module d'authentification 40.
Naturellement, dans le cas non représenté sur la figure 2 où l'une des deux vérifications précitées se solde par un échec, il est mis fin au processus d'authentification de l'utilisateur sans émission d'un jeton d'authentification.
Dans le cas où la signature SIG1 est correctement vérifiée à l'étape E38, le module d'authentification 40 procède à l'étape E40 à la reconnaissance de l'utilisateur, par exemple par reconnaissance d'empreinte digitale, ce qui permet de générer un résultat de reconnaissance R (positif ou négatif).
Le résultat de reconnaissance R est généralement déterminé par le module d'authentification par comparaison entre des données acquises par le capteur d'authentification (par exemple des données biométriques représentatives d'une partie adéquate du corps de l'utilisateur placée face au capteur d'authentification) et des données mémorisées par le module d'authentification 40, par exemple dans la mémoire non-volatile réinscriptible de l'unité de commande 12. Ces dernières données ont par exemple été mémorisées au préalable par le module d'authentification 40 lors d'une phase d'apprentissage (parfois dénommée phase d'enrôlement, de l'appellation anglo-saxonne "enrollmenf).
Le résultat de reconnaissance R obtenu à l'étape E40 et le défi SE_Ch reçu à l'étape E28 sont signés au moyen d'un algorithme cryptographique de signature et de la clé privée de l'application App_SK momentanément mémorisée en mémoire vive (après quoi cette clé privée App_SK peut être effacée de la mémoire vive), ce qui permet d'obtenir une signature SIG2 (étape E42).
Le résultat de reconnaissance R et la signature SIG2 sont envoyés du module d'authentification 40 au module sécurisé 30 (étape E44).
Le module sécurisé 30 reçoit ainsi à l'étape E46 le résultat de reconnaissance R et la signature SIG2.
Le module sécurisé 30 peut alors vérifier à l'étape E48 la signature SIG2 à l'aide de la clé publique de l'application App_PK obtenue à l'étape E18, par exemple en appliquant cette clé publique App_PK à la signature SIG2 au moyen d'un algorithme cryptographique de vérification de signature et en comparant le résultat obtenu au résultat de reconnaissance R reçu et au défi SE_Ch généré à l'étape E20 (et envoyé à l'étape E26). Selon une variante envisageable, la signature SIG2 peut être vérifiée en appliquant, au résultat de reconnaissance R, au défi SE_Ch et à la signature reçue SIG2, un algorithme cryptographique de vérification de signature utilisant la clé publique App_PK et produisant (directement) un résultat positif ou négatif.
Si la signature SIG2 est correctement vérifiée, cela signifie que le module d'authentification 40 s'est correctement authentifié auprès du module sécurisé 30.
Le module sécurisé 30 peut ainsi associer de manière certaine les données caractéristiques C du module d'authentification 40 reçues à l'étape E16 au module d'authentification 40 authentifié. La signature SIG2 permet en outre de s'assurer que le résultat de reconnaissance R est bien celui émis par le module d'authentification 40.
On remarque que, dans la variante mentionnée ci-dessus où un canal sécurisé est d'abord établi entre le module sécurisé 30 et le module sécurisé 40, il n'est pas nécessaire (mais toutefois possible) de procéder aux échanges de type défi-réponse (en anglais "challenge-response") qui visent l'authentification mutuelle du module sécurisé 30 et du module sécurisé 40, puisque l'utilisation du canal sécurisé permet déjà une telle authentification mutuelle.
Lorsque le résultat de reconnaissance est positif, le module sécurisé peut par conséquent générer un jeton d'authentification TOK à l'étape E50, en appliquant, à un ensemble de données incluant une partie au moins des données caractéristiques C du module d'authentification 40, un algorithme cryptographique de signature utilisant la clé privée de génération de jeton d'authentification SE_Auth_SK. Le jeton d'authentification TOK peut notamment inclure, outre cette signature, les données caractéristiques C du module d'authentification 40.
On remarque que l'ensemble de données précité peut également inclure un défi (ou "challenge" selon l'appellation anglo-saxonne) généré par le serveur 50 avant l'étape E2 et transmis avec la requête d'authentification du serveur 50 à l'application client 20 (étape E2), puis de l'application client 20 au coordinateur d'authentification 24 (étape E4), puis du coordinateur d'authentification 24 au module d'authentification 40 avec la demande de reconnaissance (étape E8), puis enfin du module d'authentification 40 au module sécurisé 30 à l'étape E14.
Les données caractéristiques du module d'authentification 40 incluses dans les données signées au moyen de la clé privée SE_Auth_SK comprennent par exemple un identifiant du module d'authentification et/ou un type d'authentification mise en œuvre par le module d'authentification et/ou une méthode de protection des clés cryptographiques utilisée par le module d'authentification et/ou une méthode de communication utilisée par le module d'authentification.
Le jeton d'authentification TOK est alors émis par le module sécurisé 30 à destination du coordinateur d'authentification 22 (étape E52), puis du coordinateur d'authentification 22 à l'application client 20 (étape E54), puis enfin de l'application client 20 au serveur 50 (étape E56).
Le jeton d'authentification TOK est ainsi reçu par le serveur 50 à l'étape E58 et peut être vérifié au niveau du serveur 50 au moyen de la clé publique SE_Auth_PK (en tenant compte éventuellement du défi possiblement généré par le serveur 50 avant l'étape E2 comme indiqué ci-dessus), ce qui permet d'authentifier auprès du serveur 50 l'utilisateur reconnu par le module d'authentification 40.
Le serveur 50 peut également vérifier à cette occasion que l'ensemble de données signé par le module sécurisé 30 (étape E50) inclut bien les caractéristiques C du module d'authentification 40 (par exemple incluses dans le jeton d'authentification TOK) et que celles-ci respectent les critères définis (avant envoi à l'étape E2) dans l'ensemble de critères MC. La validité de ces caractéristiques C est garantie par leur signature au moyen de la clé privée SE_Auth_SK mémorisée dans le module sécurisé 30.
Le serveur 50 peut alors émettre à l'étape E60 un message d'autorisation MOK (ou message d'information sur l'état d'autorisation) à destination de l'application client 20.
L'application client 20 reçoit le message d'autorisation MOK à l'étape E62 et est ainsi informée de la réussite du processus d'authentification de l'utilisateur. L'application client 20 peut alors commander l'affichage d'un message indicatif de la réussite de l'authentification sur une interface utilisateur (non représentée) de l'appareil électronique 10.
Dans l'exemple qui vient d'être décrit, le serveur 50 mémorise une clé publique SE_Auth_PK pour chaque ensemble module d'authentification - module sécurisé enregistré auprès du serveur 50. Pour éviter cette nécessité de mémorisation, on peut prévoir selon une autre possibilité de réalisation que le module sécurisé 30 mémorise un certificat comprenant la clé publique SE_Auth_PK (associée à sa propre clé privée SE_Auth_SK) et une signature de cette clé publique SE_Auth_PK générée au préalable par une autorité de confiance (au moyen d'une clé privée de cette autorité de confiance). Le module sécurisé pourrait alors émettre ce certificat avec le jeton d'authentification TOK (étape E54) et le serveur pourrait alors vérifier tout d'abord la signature de la clé publique SE_Auth_PK contenue dans le certificat (au moyen d'une clé publique de l'autorité de confiance), puis le jeton d'authentification TOK au moyen de la clé publique SE_Auth_PK (comme à l'étape E58).
La figure 3 représente les étapes principales d'une variante de réalisation du procédé d'authentification qui vient d'être décrit en référence à la figure 2.
Un tel procédé est mis en œuvre dans un contexte du même type que celui de la figure 1 décrit ci-dessus, mises à part les différences suivantes :
- la clé racine OT_Apps n'est pas mémorisée dans le module sécurisé 30 mais au niveau du serveur 50 ;
- l'application d'authentification 24 mémorise (par exemple dans la mémoire non-volatile réinscriptible de l'unité de commande 12) les données de dérivation App_AEK_Deriv et App_AIK_Deriv, mais la donnée de dérivation App_Deriv visible en figure 1 n'est en revanche pas utilisée.
Cette variante est utilisable lorsque l'application d'authentification 24 n'a pas été fournie par (ou en collaboration avec) l'autorité extérieure ayant fourni le module sécurisé 30.
Au cours d'une étape E100, le serveur 50 émet à destination de l'application client 20 une requête d'authentification. Cette requête d'authentification est accompagnée de l'identifiant ID du module d'authentification à utiliser pour cette authentification et/ou d'un ensemble de critères MC (pour "Match Criteria"), du même type que décrit ci-dessus en référence à la figure 2 et dans lequel a été introduite en outre la clé racine OT_Apps (par exemple au sein d'un champ spécifique dédié).
La requête d'authentification accompagnée de l'identifiant ID et de l'ensemble de critères MC intégrant la clé racine OT_Apps est reçue par l'application client 20 à l'étape E102 et transmise au coordinateur d'authentification 22.
Le coordinateur d'authentification 22 reçoit ainsi l'identifiant ID et l'ensemble de critères MC intégrant la clé racine OT_Apps à l'étape E104.
Le coordinateur d'authentification 22 peut ainsi émettre, à destination du module d'authentification 40 désigné par l'identifiant ID et/ou respectant les critères définis dans l'ensemble de critères MC, une demande de reconnaissance accompagnée de l'ensemble de critères MC intégrant la clé racine OT_Apps (étape E106).
Le module d'authentification 40 reçoit la demande de reconnaissance à l'étape E108 et peut ainsi extraire de l'ensemble de critères MC la clé racine OT_Apps à l'étape E1 10.
Le module d'authentification 40 peut ainsi calculer à l'étape E1 12 la clé dérivée AEK, par application d'une fonction de dérivation H à la clé racine OT_Apps (extraite à l'étape E1 10) et aux données de dérivation App_AEK_Deriv (mémorisées en association avec l'application d'authentification 24, comme indiqué ci-dessus) :
AEK=H(OT_Apps,App_AEK_Deriv).
Comme dans le cas de la figure 2, la clé dérivée AEK a été utilisée au préalable (avant installation de l'application d'authentification 24 dans l'appareil électronique 10) pour chiffrer la clé privée de l'application App_SK.
Le module d'authentification 40 peut donc déchiffrer la clé privée de l'application App_SK (mémorisée sous forme chiffrée dans la mémoire non-volatile de l'unité de commande 12) par application d'un algorithme de déchiffrement utilisant la clé dérivée AEK (étape E1 14) et mémoriser, de manière temporaire, la clé privée de l'application App_SK (non chiffrée) dans la mémoire vive de l'unité de commande 12.
Le module d'authentification 40 génère alors un défi App_Ch, par exemple par tirage aléatoire (étape E1 16).
Le module d'authentification 40 transmet ensuite à l'étape E1 18 la clé publique de l'application App_PK et les données caractéristiques C du module d'authentification 40, signées par la clé privée de l'autorité extérieure OT_SK et donc accompagnées de la signature Sign, ainsi que le défi App_Ch.
Ces données sont reçues par le module sécurisé 30 à l'étape E120.
Le module sécurisé 30 vérifie à l'étape E122 la signature Sign de la clé publique de l'application App_PK et des données caractéristiques C du module d'authentification 40 au moyen d'un algorithme cryptographique de vérification de signature et de la clé publique de l'autorité extérieure OT_PK (mémorisée comme indiqué en figure 1 dans la mémoire non-volatile du module sécurisé 30).
Le module sécurisé 30 génère alors un défi SE_Ch, par exemple par tirage aléatoire (étape E124).
Le module sécurisé 30 génère une signature SIG1 par application au défi App_Ch, généré à l'étape E1 16 et reçu à l'étape E120, d'un algorithme cryptographique de signature utilisant la clé privée d'authentification du module sécurisé OT_Auth_SK (étape E126).
À l'étape E126, le module sécurisé 30 émet à destination du module d'authentification 40 la signature SIG1 et le défi SE_Ch généré à l'étape E124. Le module d'authentification 40 reçoit la signature SIG1 et le défi SE_Ch à l'étape E128.
Le module d'authentification 40 dérive ensuite à l'étape E130 une clé dérivée AIK par application de la fonction de dérivation H à la clé racine OT_Apps extraite à l'étape E1 10 et à une autre donnée de dérivation, ici la donnée de dérivation App_AIK_Deriv :
AIK = H(OT_Apps,App_AIK_Deriv).
Le procédé se poursuit alors comme indiqué ci-dessus en référence à la figure 2 à partir de l'étape E36.

Claims

REVENDICATIONS
1 . Procédé d'authentification d'un utilisateur à l'aide d'un appareil électronique (10) comprenant un module d'authentification (40) et un module sécurisé (30), comprenant les étapes suivantes :
- émission (E44) par le module d'authentification (40) d'un résultat de reconnaissance (R) à destination du module sécurisé (30) selon un processus permettant l'authentification du module d'authentification (40) par le module sécurisé (30) ;
- génération (E50) d'un jeton d'authentification (TOK) par le module sécurisé (30) par signature, au moyen d'une clé privée (SE_Auth_SK) mémorisée dans le module sécurisé (30), de données comprenant des données représentatives d'au moins une caractéristique du module d'authentification (40) ;
- émission (E52) du jeton d'authentification généré (TOK).
2. Procédé d'authentification selon la revendication 1 , dans lequel lesdites données représentatives sont reçues (E16 ; E120) par le module sécurisé (30) en provenance du module d'authentification (40) avec une signature associée et dans lequel la signature est vérifiée (E18 ; E122) au moyen d'une clé (OT_PK) mémorisée dans le module sécurisé (30).
3. Procédé d'authentification selon la revendication 1 ou 2, dans lequel le processus permettant l'authentification du module d'authentification (40) par le module sécurisé (30) utilise une clé privée du module d'authentification (App_SK).
4. Procédé d'authentification selon la revendication 3, dans lequel le processus permettant l'authentification du module d'authentification (40) par le module sécurisé (30) comprend les étapes suivantes :
- transmission (E26 ; E126) d'un défi (SE_Ch) du module sécurisé (30) au module d'authentification (40) ;
- génération (E42) d'une réponse (SIG2) par le module d'authentification par application au défi (SE_Ch) d'un algorithme de signature utilisant la clé privée du module d'authentification (App_SK) ;
- transmission (E44) de la réponse (SIG2) du module d'authentification (40) au module sécurisé (30) ;
- vérification (E48) de la réponse (SIG2) par le module sécurisé (30) au moyen de la clé publique (App_PK) associée à la clé privée du module d'authentification (App_SK).
5. Procédé d'authentification selon la revendication 4, dans lequel ladite clé publique (App_PK) est reçue (E14 ; E1 18) par le module sécurisé (30) avec une signature associée et dans lequel la signature est vérifiée (E18 ; E122) par le module sécurisé (30) au moyen d'une clé (OT_PK) mémorisée dans le module sécurisé (30).
6. Procédé d'authentification selon l'une des revendications 3 à 5, dans lequel le résultat de reconnaissance (R) est émis (E44) signé au moyen de la clé privée du module d'authentification (App_SK).
7. Procédé d'authentification selon l'une des revendications 3 à 6, comprenant une étape de déchiffrement (E32 ; E1 14), par le module d'authentification (40), de la clé privée du module d'authentification (App_SK) à partir d'une version chiffrée de la clé privée du module d'authentification ([App_SK]AEK).
8. Procédé d'authentification selon la revendication 7, dans lequel ladite version chiffrée ([App_SK]AEK) est mémorisée dans une mémoire non-volatile de l'appareil électronique (10) et dans lequel la clé privée du module d'authentification (App_SK) obtenue par l'étape de déchiffrement (E32 ; E1 14) est mémorisée dans une mémoire vive de l'appareil électronique (10).
9. Procédé d'authentification selon l'une des revendications 7 ou 8, dans lequel l'étape de déchiffrement (E32 ; E1 14) met en œuvre un algorithme cryptographique de déchiffrement utilisant une clé (AEK) dérivée à partir de données reçues (OT_App_K ; OT_Apps) et de données (App_AEK_Deriv) mémorisées dans l'appareil électronique (10).
10. Procédé d'authentification selon l'une des revendications 1 à 9, dans lequel le module d'authentification (40) comprend un capteur d'authentification (16) et dans lequel le résultat de reconnaissance (R) est déterminé par le module d'authentification (40) par comparaison entre des données acquises par le capteur d'authentification (16) et des données mémorisées par le module d'authentification (40).
1 1 . Procédé d'authentification selon l'une des revendications 1 à 10, dans lequel le module d'authentification (40) est mis en œuvre au moins en partie par une application d'authentification (24) exécutée par un processeur (12) de l'appareil électronique (10).
12. Procédé d'authentification selon l'une des revendications 1 à 1 1 , dans lequel l'appareil électronique (10) est un téléphone mobile.
13. Procédé d'authentification selon l'une des revendications 1 à 1 1 , dans lequel l'appareil électronique (10) est une tablette numérique.
14. Procédé d'authentification selon l'une des revendications 1 à 1 1 , dans lequel l'appareil électronique (10) comprend un élément de maintien sur une partie du corps de l'utilisateur.
15. Procédé d'authentification selon l'une des revendications 1 à 14, dans lequel le module sécurisé (30) et le module d'authentification (40) échangent des données au moyen d'un protocole de type ISO 7816 ou SPI ou HCI/SWP.
16. Module sécurisé (30) comprenant au moins une mémoire mémorisant une clé privée (SE_Auth_SK) et un processeur programmé pour mettre en œuvre les étapes suivantes :
- réception (E46), en provenance d'un module d'authentification (40), d'un résultat de reconnaissance (R) selon un processus permettant l'authentification du module d'authentification (40) par le module sécurisé (30) ;
- génération (E50) d'un jeton d'authentification (TOK) par signature, au moyen de ladite clé privée (SE_Auth_SK), de données comprenant des données représentatives d'au moins une caractéristique du module d'authentification (40) ;
- émission (E52) du jeton d'authentification généré (TOK).
17. Module sécurisé selon la revendication 16, dans lequel le processeur est programmé pour recevoir (E16 ; E120) lesdites données représentatives en provenance du module d'authentification (40) avec une signature associée et pour vérifier la signature (E18 ; E122) au moyen d'une clé (OT_PK) mémorisée dans le module sécurisé (30).
18. Module sécurisé selon la revendication 16 ou 17, dans lequel le processeur est programmé pour mettre en œuvre le processus permettant l'authentification du module d'authentification (40) par le module sécurisé (30) selon les étapes suivantes :
- émission (E26 ; E126) d'un défi (SE_Ch) à destination du module d'authentification (40) ;
- réception (E46) d'une réponse (SIG2) en provenance du module d'authentification (40) ;
- vérification (E48) de la réponse au moyen d'une clé publique (App_PK) associée à une clé privée du module d'authentification (App_SK).
19. Module sécurisé selon la revendication 18, dans lequel le processeur est programmé pour vérifier une signature (E18 ; E122) de ladite clé publique (App_PK) au moyen d'une clé (OT_PK) mémorisée dans le module sécurisé (30).
20. Appareil électronique (10) comprenant un module d'authentification (40), un module sécurisé (30) selon l'une des revendications 16 à 19, et une unité de commande (12) mémorisant une application (20) exécutable par un processeur de l'unité de commande (12).
21 . Appareil électronique (10) selon la revendication 20, dans lequel l'application est une application de paiement ou une application d'accès.
22. Système comprenant un serveur (50) et un appareil électronique (10) selon la revendication 20 ou 21 , dans lequel l'appareil électronique (10) est conçu pour émettre le jeton d'authentification généré (TOK) à destination du serveur (50) et dans lequel le serveur (50) est conçu pour recevoir le jeton d'authentification émis (TOK) et pour vérifier le jeton d'authentification reçu (TOK).
23. Système selon la revendication 22, dans lequel le serveur (50) est conçu pour recevoir des données (ID) relatives au module d'authentification (40) en provenance d'un autre serveur (70).
24. Système selon la revendication 22 ou 23, dans lequel le serveur (50) est conçu pour émettre un message d'autorisation ou d'information (MOK) à destination de l'application (20) en cas de vérification du jeton d'authentification reçu.
PCT/FR2015/053605 2014-12-22 2015-12-17 Procédé d'authentification d'un utilisateur et d'un module sécurisé, appareil électronique et système associes Ceased WO2016102834A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/538,841 US10984080B2 (en) 2014-12-22 2015-12-17 Method for authenticating a user and a secure module, associated electronic apparatus and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1463168A FR3030817B1 (fr) 2014-12-22 2014-12-22 Procede d'authentification d'un utilisateur, module securise, appareil electronique et systeme associes
FR1463168 2014-12-22

Publications (1)

Publication Number Publication Date
WO2016102834A1 true WO2016102834A1 (fr) 2016-06-30

Family

ID=53269566

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2015/053605 Ceased WO2016102834A1 (fr) 2014-12-22 2015-12-17 Procédé d'authentification d'un utilisateur et d'un module sécurisé, appareil électronique et système associes

Country Status (3)

Country Link
US (1) US10984080B2 (fr)
FR (1) FR3030817B1 (fr)
WO (1) WO2016102834A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3087988B1 (fr) * 2018-10-30 2022-01-28 Idemia France Gestion de profils d'abonne simultanement actifs dans une carte euicc en utilisant plusieurs liaisons distinctes
JP6838260B2 (ja) * 2018-11-14 2021-03-03 カウリー株式会社 ブロックチェーン制御方法
US12200131B1 (en) * 2020-09-02 2025-01-14 Ouraring, Inc. Methods and apparatus facilitating high security transactions
EP4123539A1 (fr) * 2021-07-22 2023-01-25 Deutsche Telekom AG Procédé et système pour faire fonctionner une application mpos, à l'aide d'une carte sim

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2128783A1 (fr) * 2007-03-19 2009-12-02 Fujitsu Limited Système de commande de service, procédé de commande de service et programme de commande de service
US20140195815A1 (en) * 2013-01-04 2014-07-10 Synaptics Incorporated Methods and systems for fingerprint template enrollment and distribution process
US20140289833A1 (en) * 2013-03-22 2014-09-25 Marc Briceno Advanced authentication techniques and applications

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3389186B2 (ja) * 1999-04-27 2003-03-24 松下電器産業株式会社 半導体メモリカード及び読み出し装置
JP2001066989A (ja) * 1999-08-31 2001-03-16 Fuji Xerox Co Ltd 一方向性関数生成方法，一方向性関数値生成装置，証明装置，認証方法および認証装置
FR2822002B1 (fr) * 2001-03-12 2003-06-06 France Telecom Authentification cryptographique par modules ephemeres
US20040177369A1 (en) * 2003-03-06 2004-09-09 Akins Glendon L. Conditional access personal video recorder
US20100217975A1 (en) * 2009-02-25 2010-08-26 Garret Grajek Method and system for secure online transactions with message-level validation
WO2010115466A1 (fr) * 2009-04-09 2010-10-14 Nokia Siemens Networks Oy Procédé, appareil et produit-programme informatique permettant d'améliorer une réservation de ressources dans une ouverture de session
US20120102326A1 (en) * 2010-05-13 2012-04-26 Nikhil Sanjay Palekar Facilitating Secure Communications
KR101198120B1 (ko) * 2010-05-28 2012-11-12 남궁종 홍채정보를 이용한 양방향 상호 인증 전자금융거래시스템과 이에 따른 운영방법
US20130301830A1 (en) * 2012-05-08 2013-11-14 Hagai Bar-El Device, system, and method of secure entry and handling of passwords
US9589399B2 (en) 2012-07-02 2017-03-07 Synaptics Incorporated Credential quality assessment engine systems and methods
US8892904B2 (en) * 2012-09-13 2014-11-18 Intel Corporation Hardware enforced security governing access to an operating system
US8904186B2 (en) * 2012-09-28 2014-12-02 Intel Corporation Multi-factor authentication process
US9275212B2 (en) 2012-12-26 2016-03-01 Cellco Partnership Secure element biometric authentication system
US9306754B2 (en) * 2012-12-28 2016-04-05 Nok Nok Labs, Inc. System and method for implementing transaction signing within an authentication framework
US9853979B1 (en) * 2013-03-11 2017-12-26 Amazon Technologies, Inc. Immediate policy effectiveness in eventually consistent systems
WO2015016896A1 (fr) * 2013-07-31 2015-02-05 Hewlett-Packard Development Company, L.P. Authentification à distance d'un dispositif
US9100175B2 (en) * 2013-11-19 2015-08-04 M2M And Iot Technologies, Llc Embedded universal integrated circuit card supporting two-factor authentication
US9942043B2 (en) * 2014-04-23 2018-04-10 Visa International Service Association Token security on a communication device
US9875347B2 (en) * 2014-07-31 2018-01-23 Nok Nok Labs, Inc. System and method for performing authentication using data analytics
US9736154B2 (en) * 2014-09-16 2017-08-15 Nok Nok Labs, Inc. System and method for integrating an authentication service within a network architecture
GB201420496D0 (en) * 2014-10-01 2014-12-31 Continental Intelligent Transporation Systems Llc Package delivery to and pick-up from a vehicle
US11533297B2 (en) * 2014-10-24 2022-12-20 Netflix, Inc. Secure communication channel with token renewal mechanism
US20170364911A1 (en) * 2014-12-12 2017-12-21 Cryptomathic Ltd Systems and method for enabling secure transaction
US9300660B1 (en) * 2015-05-29 2016-03-29 Pure Storage, Inc. Providing authorization and authentication in a cloud for a user of a storage array

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2128783A1 (fr) * 2007-03-19 2009-12-02 Fujitsu Limited Système de commande de service, procédé de commande de service et programme de commande de service
US20140195815A1 (en) * 2013-01-04 2014-07-10 Synaptics Incorporated Methods and systems for fingerprint template enrollment and distribution process
US20140289833A1 (en) * 2013-03-22 2014-09-25 Marc Briceno Advanced authentication techniques and applications

Also Published As

Publication number Publication date
FR3030817A1 (fr) 2016-06-24
FR3030817B1 (fr) 2017-01-13
US10984080B2 (en) 2021-04-20
US20170351849A1 (en) 2017-12-07

Similar Documents

Publication Publication Date Title
EP3262860B1 (fr) Procédé de reconnaissance automatique entre un appareil mobile et un véhicule automobile aptes à fonctionner selon le protocole ble
FR3101167A1 (fr) Procede d'utilisation d'un dispositif pour le deverrouillage d'un autre dispositif
FR2989799A1 (fr) Procede de transfert d'un dispositif a un autre de droits d'acces a un service
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
FR3053203A1 (fr) Technique de telechargement d'un profil d'acces a un reseau
EP2912594A1 (fr) Procede de fourniture d'un service securise
EP3241137A1 (fr) Procede mis en oeuvre dans un document d'identite et document d'identite associe
EP3357212A1 (fr) Procede et dispositif d'authentification ameliores
EP3308564B1 (fr) Procédé de chargement d'une clé virtuelle et terminal utilisateur associé
WO2016102834A1 (fr) Procédé d'authentification d'un utilisateur et d'un module sécurisé, appareil électronique et système associes
EP3667530B1 (fr) Accès sécurise à des données chiffrées d'un terminal utilisateur
WO2016102832A1 (fr) Procédé d'authentification d'une application, appareil électronique et programme d'ordinateur associés
FR3082089A1 (fr) Procede et systeme de deverrouillage a distance d'un vehicule automobile
EP3899765B1 (fr) Réinitialisation d'un secret applicatif au moyen du terminal
FR3032292A1 (fr) Element securise et procede mis en œuvre dans un tel element securise
FR3145049A1 (fr) Procédé d’enregistrement sur une carte de données biométriques d’un détenteur de cette carte
WO2017005644A1 (fr) Procédé et système de contrôle d'accès à un service via un média mobile sans intermediaire de confiance
WO2024180049A1 (fr) Procede de delivrance d'une autorisation d'acces pour un individu et procede de verification
KR20160020314A (ko) 전자서명을 이용하여 대출서비스를 제공하기 위한 장치 및 그 방법
WO2025125562A1 (fr) Procédé d'authentification d'un individu pour la mise en œuvre d'une transaction sur un terminal marchand
FR3118225A1 (fr) Procédé et dispositif de génération d'informations d'authentification pour une entité sécurisée et procédé et dispositif de contrôle d'identité associés
WO2008081150A2 (fr) Procede et systeme d'autorisation d'acces a un serveur
FR3041841A1 (fr) Procede et dispositif pour acceder a une ressource a l’aide d’un jeton chiffre
FR2963526A1 (fr) Telephone mobile muni d'un systeme securise d'identification

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15825615

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 15538841

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 15825615

Country of ref document: EP

Kind code of ref document: A1