WO2011138558A2 - Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service - Google Patents

Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service Download PDF

Info

Publication number
WO2011138558A2
WO2011138558A2 PCT/FR2011/051008 FR2011051008W WO2011138558A2 WO 2011138558 A2 WO2011138558 A2 WO 2011138558A2 FR 2011051008 W FR2011051008 W FR 2011051008W WO 2011138558 A2 WO2011138558 A2 WO 2011138558A2
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
user
data
mobile terminal
server
Prior art date
Application number
PCT/FR2011/051008
Other languages
English (en)
Other versions
WO2011138558A3 (fr
Inventor
Johann Liberman
Panos Chatzikomninos
Jean Pascal Aubert
Benoit Delestre
Didier Hallepee
Original Assignee
4G Secure
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 4G Secure filed Critical 4G Secure
Priority to EP11723560A priority Critical patent/EP2567502A2/fr
Priority to US13/696,489 priority patent/US9038196B2/en
Priority to RU2012152466/08A priority patent/RU2012152466A/ru
Priority to CN2011800341284A priority patent/CN103109494A/zh
Priority to SG2012081857A priority patent/SG185449A1/en
Publication of WO2011138558A2 publication Critical patent/WO2011138558A2/fr
Publication of WO2011138558A3 publication Critical patent/WO2011138558A3/fr

Links

Classifications

    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C5/00—Ciphering apparatus or methods not provided for in the preceding groups, e.g. involving the concealment or deformation of graphic data such as designs, written or printed messages
    • 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/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • 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/3247—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 involving digital signatures
    • 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/3297—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 involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • the present invention relates to the field of authentication, particularly in a context of securing access and online services offered in the context of banking transactions.
  • authentication In the security of information systems, authentication is said to be “strong” when it uses an identification procedure requiring the concatenation of at least two authentication elements or "factors” chosen from among the entities to be authenticated. authenticate knows, what it holds or what it is.
  • Strong authentication is one of the essential foundations to guarantee the authorization or control of access to a service (ie who can access it), confidentiality (ie who can see the service), integrity (ie who can modify the service) and traceability (ie who accessed it).
  • the choice of an authentication method adapted to each need will be based on a certain level of contractualization defined by means of a risk analysis based on the cost of the means of authentication to be implemented, the cost related to the various risks (sensitivity of the application, data, etc.) and the expected benefits for the user (depending on his level of expertise).
  • This first level better than the identification by simple pair of identifier / password, is based on the implementation of a low level authentication solution, comparable to a strong pseudo authentication.
  • This level can be defined when organizational and technical means are implemented in order to better guarantee the identity of the different actors (for example, authorized users and / or third parties of an e-banking service or e-bank). - chest).
  • a third level of contracting may be set when one is within the perimeter of the strong authentication in which the authentication level (2nd degree) is legally admissible even if in case of dispute the proof of its reliability remains to be brought by the one who implements it.
  • An object of the present invention is to respond to the above problems.
  • the present invention aims to provide a user-friendly authentication system, intuitive, ergonomic, secure and usable by a maximum of customers.
  • the present invention also aims to create a secure transaction context capable of ensuring the transport, the encryption / decryption of dynamic data and the presentation of these data to a server for processing, validation, timestamping and legal archiving. This transaction in uses requiring a high level of trust.
  • the present invention aims in particular to allow uses and services requiring a high level of security, such as payment and electronic signature, with a non-repudiation option.
  • the present invention proposes for this purpose a method of authenticating a user requesting a transaction from a service provider, the method comprising the generation of a user-specific authorization code and the transaction required to from an authentication data read on a screen by means of a mobile terminal, the reading of the authorization code, displayed by the mobile terminal, by means of reading a digital device and sending, by this digital device to the service provider, read authorization code to authenticate the user.
  • the specific character of the authorization code thus generated prevents its reuse by a malicious user during a subsequent transaction. Moreover, reading both the authentication data and the resulting authorization code with means such as a mobile terminal or a computer makes it possible to make the authentication process more user-friendly and to avoid input errors that the user can make when entering codes that may be lengthy.
  • the authorization code is generated by signing the authentication data read by means of a secret code entered by the user on the mobile terminal, which makes it possible to authenticate the user requesting the transaction more reliably.
  • the authorization code is generated by signing the authentication data further by means of an identification data of the mobile terminal, which makes it possible to ensure strong authentication.
  • the authorization code generated is encoded in the form of an image, in particular of a two-dimensional barcode, before being displayed by the mobile terminal.
  • an image in particular of a two-dimensional barcode
  • reading of the authorization code is performed by means of a near-field communication wireless communication technology.
  • the method comprises transmitting the authentication data read from the mobile terminal to the authentication server (AS), generating the authorization code from the authentication data in the server. authentication, and the transmission of the generated authorization code to the terminal mobile.
  • AS authentication server
  • This embodiment alleviates the calculations to be performed at the mobile terminal.
  • the read authentication data is interpreted in the mobile terminal by means of a custom application specific to the user and downloaded from an authentication server, said personalized application generating the authorization code from the authentication data read.
  • the method further comprises a preliminary enrollment step, during which an activation code is transmitted to the mobile terminal, followed by an activation step during which the personalized application is downloaded to the mobile terminal.
  • this activation code being used during the activation step to activate the downloaded custom application, which allows the user to choose when he wants to activate the custom application.
  • the enrollment step comprises a step of verifying the identity of the user before transmitting the activation code, said transmission being performed only if said verification is performed in a positive manner.
  • the activation step comprises the transmission of at least one confidential data specific to the user of the mobile terminal, this confidential data used to encrypt the authentication data in the mobile terminal before transmission. the authentication server and / or decrypting the authorization code received by the mobile terminal. The transfers of the authentication data to the authentication server, on the one hand, and the authorization code to the mobile terminal, on the other hand, are thus secured.
  • the method comprises generating, during the preliminary enrollment step, the personalized application and / or the confidential data as a function of at least one internal identification data generated at from at least one personal identification data sent by the user to the service provider.
  • the authentication data is generated, by the service provider, based on data related to the transaction and personal data received from the user, which prevents the reuse of such data. authentication by a malicious user during a subsequent transaction.
  • the present invention provides a system for authenticating a user requesting a transaction from a service provider, the system comprising a screen arranged to display authentication data received from the service provider, a terminal mobile device comprising means for entering the authentication data displayed on the screen and display means arranged to display an authorization code specific to the user and the required transaction and a digital device comprising input means able to read the authorization code displayed by the mobile terminal and send this authorization code to the service provider in order to authenticate the user.
  • this authentication system further comprises an authentication server as described above.
  • the authentication system comprises a service server, used by the service provider to provide a service required by the user, the service server comprising a reception module arranged to receive at least one data item. of the user and the authorization code issued by the user, computing means arranged to generate at least one internal identification data from at least one of the personal data received, and a transmission module arranged to send the generated internal identification data to the authentication server.
  • FIG. 1A represents the steps of an authentication method according to the principle of the present invention
  • FIG. 1B illustrates a system according to a first embodiment of the "off-line" type implementing the authentication method of the present invention
  • FIG. 2A represents the substeps of the enrollment step of the authentication method according to the principle of the present invention
  • FIG. 2B represents a first embodiment of the system implementing the enrollment step of the authentication method according to the principle of the present invention
  • FIG. 2C represents a second embodiment of the system implementing the authentication method enrollment step according to the principle of the present invention
  • FIG. 3A illustrates the constituent substeps of the activation step of the personalized application according to an embodiment of the present invention
  • FIG. 3B illustrates a system implementing the activation step of the personalized application of the authentication method according to the principle of the present invention
  • FIG. 4A illustrates the constituent sub-steps of the step of generating the authorization code of an authentication method according to a second embodiment of the "on-line" type
  • FIG. 4B illustrates a first embodiment of the system implementing the authentication method according to the second embodiment of the "online" type, where the authorization code is generated in an authentication server AS distinct from the server of the service provider ;
  • FIG. 4C illustrates a second embodiment of the system implementing the authentication method according to the second embodiment of "on-line" type, where the authorization code is generated in the server of the service provider on which Authentication features have been installed.
  • FIG. 1A are illustrated the steps of an authentication method according to the principle of the present invention.
  • This method can start with a step A of enrolling a user Ui with a service provider with whom he wishes to perform a transaction.
  • the user Ui will send to this service provider (for example to an SP service server managed by this service provider) a certain number of personal identification data (here called "d id "), by example by entering them on his computer through a client application associated with the SP server of the service provider.
  • this service provider for example to an SP service server managed by this service provider
  • d id personal identification data
  • Such personal data d id is used to formally identify the user Ui when the one subscribes to a service. Once the SP server has received this personal data, it is controlled by the service provider, in order to subsequently guarantee that the user Ui is the real user.
  • Such a control can be done on the basis of already known data if the user is already known (thanks to data present on a bank statement, for example), by a telephone call from an operator, or by the request of the copy of the identity card of a new user.
  • this personal data is stored securely, for example in the SP server of the service provider or in another server delegated to this task.
  • a step B of activation of a personalized application, generated specifically for the user Ui, on a mobile terminal belonging to the user Ui can be made to at this stage, to allow the user Ui to use his mobile terminal in the authentication procedure with the service provider.
  • An example of such an activation step is described later.
  • the user Ui is ready to perform a transaction requiring authentication with the service provider.
  • the method comprises a step C of displaying an authentication data (referred to aut hr thereafter) on a screen to which access SNA user Ui.
  • a screen can naturally be the screen connected to the personal computer of the user Ui, in which case the authentication data aut h is transmitted beforehand from the SP server of the service provider to this personal computer to be displayed on this screen.
  • This screen can also be a television screen, or even a mobile phone screen.
  • the sending of this authentication data can be conditioned upon receipt by the server SP of a transaction request from the user's personal computer Ui.
  • the user Ui can use his personal computer to access a client application associated with the service provider (for example through the website of this provider) and indicate his intention to carry out a transaction.
  • the server SP generates and sends the authentication data to the personal computer of the user Ui.
  • the aut h of authentication data displayed in step C can take the form of a bar code in two dimensions, a tag, a password to a single use ( "One-Time Password Or OTP in English) or an NFC message (for Near-Field Communication), among others.
  • the graphic representation of this two-dimensional barcode or this tag complies with commonly used standards, such as QR-Code, Datamatrix, PDF 417 , Microsoft tag.
  • the authentication data aut h transmitted by the service provider is generated specifically for the required transaction, based on data related to the transaction and possibly personal data received from the user.
  • this authentication datum aut h is single-use and is generated at each transaction so as to be different for each required transaction.
  • the possible knowledge of this authentication data by interception of a malicious user does not allow him to use this information for subsequent transactions.
  • the user Ui uses his mobile terminal to enter this authentication data, during a step D of reading, so that it is interpreted by the custom application previously activated in step B.
  • this authentication data aut h is read by the user Ui, which manually entered on his mobile terminal.
  • This first embodiment is particularly suitable when the mobile terminal of the user does not have own reading means such as a camera.
  • the authentication datum aut h is read directly by the mobile terminal, which has its own reading means.
  • the user Ui can take a picture of the authentication data aut h displayed on the screen, and the application activated in the software will use the snapshot taken for find the relevant data in the authentication data and interpret them.
  • the mobile terminal when the mobile terminal has an NFC reader, the latter can read an authentication data aut h presented as an NFC message using a communication technology wireless communication type field near, referred to as "Near-Field Communication". This alternative avoids having to aim precisely SCN screen with the mobile terminal.
  • an authorization code cod is generated and then displayed by the mobile terminal, during a step E of code generation. This cod code is used to authenticate the user Ui with the service provider.
  • the authorization code cod is advantageously encoded in the form of an image, a two-dimensional bar code, a tag, a d a single-time password ("One-Time Password" or OTP) or an NFC message, among others.
  • This authorization code generation step E may be implemented according to different embodiments.
  • the authorization code cod is generated entirely by the personalized application installed on the mobile terminal, which makes it possible to use this mobile terminal without it being necessarily connected to the mobile network and limits the transfer of sensitive data that can be recovered by a malicious third party.
  • the personalized application interprets the authentication data aut h read and generates from the interpreted data a cod authorization code, which is displayed by the mobile terminal.
  • the personalized application in addition to the authentication data d aut h, can also use a secret code assigned to the user to generate the authorization code, which reinforces the character specifically related to the user of this code authorization.
  • the codi authorization code is generated, by the personalized application installed on the mobile terminal, from the authorization data aut h read by the mobile terminal and a secret code assigned to the user, this secret code can be used to sign the authorization data aut h to obtain a code of authorization cod, single use, which takes the form of a password to single use ("One-Time Password").
  • the authorization code cod can be generated by signing the authentication data aut h read by such a secret code entered by the user on the mobile terminal TEL, this secret code is also known on the side of the AS authentication server, to allow the decryption of this authorization code.
  • a such authorization code is then not only specific to the required transaction, but serves to authenticate the user requesting this transaction.
  • the cod authorization code is generated by signing the given authentication aut h using not only the secret code of the user, but also of the identification data mobile terminal (for example its IMEI number), which makes it possible to verify, during the subsequent verification step, that the transaction is indeed associated with this user Ui and that it is indeed the user Ui that has generated the code authorization.
  • a time stamp data can also be used to sign the authentication data of aut h, which further complicates the code authorization cod, and allows to date the authentication time of the transaction.
  • the authorization code cod is advantageously encoded in the form of an image, for example in the form of a two-dimensional barcode or tag.
  • the authorization code is then illegible directly by a human being, which allows on the one hand to prevent the authorization code is visually intercepted by a malicious user who can look at the screen of the mobile terminal, while allowing on the other hand its reading, when displayed by the mobile terminal, by optical reading means adapted to read this type of barcode.
  • This embodiment also makes it possible to use authorization codes of considerable length (for example of 256 characters), which are therefore very specific and safer than the authorization codes to be entered manually by a user, and therefore to be limited in length at the risk of causing user input errors.
  • Such an embodiment is particularly adapted to the encoding of a complex code authorization code generated by the signature of authentication data by means of the secret code of the user, a terminal identification data. mobile and time stamp data. Once this authorization code cod, generated, it is displayed on the mobile terminal so that it can be entered by a digital PC device of the user Ui, during a step F of reading this authorization code cod, .
  • the digital device PC used to read this authorization code cod may be a personal computer comprising reading means capable of reading this code (for example a webcam, a digital camera or an NFC reader), or even a mobile phone comprising reading means (e.g. digital camera type or NFC) capable of capturing an image of cod authorization code.
  • reading means capable of reading this code for example a webcam, a digital camera or an NFC reader
  • mobile phone comprising reading means (e.g. digital camera type or NFC) capable of capturing an image of cod authorization code.
  • the reading of the authorization code can be achieved by a near-field communication (NFC) type wireless communication technology, in order not to have to aim precisely the mobile terminal with the reading means of the PC digital device.
  • NFC near-field communication
  • the screen SCN on which is read the authentication data aut h during the reading step D, can belong to the same digital device PC that the reading means used to read the code d 'authorization cod.
  • the authorization code cod has been encoded as an image (in particular in the form of a two-dimensional barcode) before being displayed by the mobile terminal
  • the image is then read by the reading means of the digital device to then be transmitted to the SP server of the service provider.
  • this read image can be decoded at the level of the digital device PC, for example by means of pattern recognition, in order to retrieve the authorization code cod, and to transmit this code in decoded form rather only in the form of an image.
  • the authorization code generated is in the form of an image, that is to say when this authorization code is encoded as an image (for example a two-dimensional barcode), the user then presents this image in front of a webcam connected to his personal computer, so that this image can be automatically transferred to the server of the bank to allow or not its connection.
  • the authorization code cod is generated in a separate server of the mobile terminal, which is then content to interpret the authentication data read and possibly to format it. and encrypting it before transmitting it to this server, which generates the codi authorization code according to the auth authentication data it receives via the mobile terminal and returns this authorization code to the mobile terminal where it is posted.
  • the mobile can, depending on the case, directly transmit this authorization code, or translate and process it before transmitting it to the authentication server.
  • the transaction data and this authorization code cod are sent (step G) to the SP server of the service provider who will perform the verification (step H) of this code in order to authenticate the user Ui and allow the transaction if this authentication is correct.
  • FIG. 1B illustrates a system according to a first embodiment of the "off-line" type, implementing the authentication method of the present invention as previously described in FIG. 1A.
  • Such a system comprises an SP server belonging to the connected service provider, for example via the Internet, to the personal computer ("PC") of the user Ui.
  • PC personal computer
  • This personal computer has a screen ("SCN") which is used to display the authentication data d auth sent by the server SP, as well as reading means (for example a webcam or an optical reader) for reading a authorization code displayed by a mobile terminal.
  • SCN screen
  • reading means for example a webcam or an optical reader
  • the present invention uses a mobile terminal TEL such as a mobile phone, a smartphone, a digital music player, etc. owned by the user Ui, on which is installed an application capable of interpreting the data.
  • a mobile terminal TEL such as a mobile phone, a smartphone, a digital music player, etc. owned by the user Ui, on which is installed an application capable of interpreting the data.
  • authentication device and which has display means (such as an LCD screen) on which an authorization code can be displayed.
  • Figure 2A illustrates the substeps of enrollment step A according to an embodiment of the present invention using an AS authentication server.
  • the user Ui sends the service provider's SP server a certain number of personal identification data id , for example by entering them on his computer through a client application. associated with the SP server of the service provider.
  • This personal identification data id once received by the server SP, are stored in a substep A2 storage.
  • the service provider's SP server sends a request req to an authentication server AS so that it generates a number of elements for the authentication of the user. .
  • this authentication server AS may correspond to the SP server of the service provider on which additional authentication features have been installed.
  • this first embodiment where the authentication, identification and service provisioning functionalities are integrated within the same server, all the exchanges between authentication and service provisioning modules are done within a single server. the same secure environment, which enhances the security of the system.
  • this authentication server AS is a server separate from the SP server of the service provider, in which case the authentication functions are deliberately separated from the transaction and service provisioning functions, which allows a management authentication by an operator separate from the service provider, which does not necessarily have the technical skills or the ability to handle this authentication.
  • the request req is accompanied by a number of user internal identification data dim, based on the personal identification data received by the server SP but different from the latter, in order to enable the generation of the elements used for the authentication of the user in the authentication server AS, while guaranteeing the anonymity of this here from this server.
  • the authentication server AS Following reception of the request req, the authentication server AS generates (sub-step A4) on the one hand the personalized application APP, which will be used to interpret the authentication data d aut h and which is intended to to be installed on the mobile terminal TEL, of the user.
  • Such a personalized application APP may, for example, contain a number of custom elements to customize the application to make it specific to the user Ui.
  • this custom application may contain the user's password signature as well as an algorithm to verify the password.
  • this APP application also contains an algorithm for verifying an activation PIN code.
  • the duration of validity of the APP personalized application is also configurable by the operator of the AS authentication server according to the service provider concerned and according to the needs of this service provider.
  • the authentication server AS can also generate, again during this generation substep A4, a certain number of confidential data, designated by the abbreviation "serves,” in FIG. 2A, according to the identification data. received by the AS server:
  • This confidential data is used, is specific to the user Ui and is generated from the internal data dim which has itself been generated from the user's personal identification data id , for example at the same time as the APP custom application ,. These confidential data serves, are intended to be transmitted to the mobile terminal TEL of the user Ui.
  • Each separate user Ui enrolling with the service provider therefore has confidential data serves, distinct from other users.
  • the copy of the APP custom application, on another mobile terminal than that of the user Ui is useless without the confidential data serves, generated by the AS server.
  • this encryption key is composed of at least a first key for the encryption key. Ui user and a second key for the AS authentication server.
  • the method continues with a step A5 of downloading the personalized application APP, in the mobile terminal of the Ui user.
  • This APP personalized application can be activated later by means of an activation PIN code if this activation option is chosen later.
  • the step A5 then comprises, not the download, but sending a download link pointing to the APP custom application, to the mobile terminal of the user Ui, after generation of this custom application.
  • Such a download link for example a URL
  • SMS Short Streaming Service
  • WiFi Wireless Fidelity
  • Bluetooth Wireless Fidelity
  • NFC Wireless Fidelity
  • This alternative embodiment allows the user to decide when to download.
  • the provision of the link by SMS allows an immediate process without needing to know the availability of the user and does not require a network coverage, unlike the direct download.
  • step A7 sending an activation PIN (generated in step A4) to the mobile terminal is performed.
  • This activation PIN ensures end-to-end authentication, without any initial flaws, from registration to service until later use, to certify that only the user Ui was able to perform these operations.
  • the sending of this activation PIN can be conditioned upon the verification, by the authentication server AS, of the identity of the user during a verification step A6 preceding such sending.
  • a verification can consist, for example, in sending to the authentication server AS an image of the user's identity card Ui, via a webcam of the user's computer or the sound camera. mobile terminal TEL, and the verification by the AS server that the data displayed on this image correspond to the user Ui.
  • the mobile terminal TEL has a link to download a personalized application capable of managing the authentication of the user Ui as well. than an activation PIN to activate such a custom application.
  • the SP server of the service provider stores the personal data of the user Ui, which are only known from this server SP to guarantee their confidentiality and, conversely, the authentication server AS is aware that internal identification data transmitted with the request of the service provider. This separation of data between different servers makes it possible to guarantee better resistance to attacks.
  • FIG. 2B illustrates a first embodiment of a system implementing the enrollment step A according to the principle of the present invention, as described above.
  • Such a system in addition to the elements already described in FIG. 1B, furthermore comprises an AS authentication server which will generate the personalized application and certain confidential data associated with the Ui user on request received from the SP server of the service provider. services.
  • AS authentication server which will generate the personalized application and certain confidential data associated with the Ui user on request received from the SP server of the service provider. services.
  • FIG. 2B the various exchanges made during the enrollment step described in FIG. 2A are illustrated.
  • AS authentication, substep A5 sending the download link of the personalized application to the mobile terminal and sub-step A6 sending the activation PIN of the personalized application to the mobile terminal are indicated.
  • the AS authentication server is separate from the SP server of the service provider.
  • This embodiment is particularly suitable for applications for which the service provider does not wish to manage transaction authentication himself and prefers to delegate this function to a third party operator.
  • FIG. 2C illustrates a second embodiment of a system implementing the enrollment step A according to the principle of the present invention, as described above.
  • Such a system differs from the system according to the first embodiment of FIG. 2B in that the authentication server AS corresponds to the SP server of the service provider. In other words, the same server is used both to perform the authentication and to provide a service.
  • Such a server can take the form of an SP server capable of providing a service on which the authentication functions necessary for the authentication steps described in the present application are installed in the form of complementary modules, for example in the form of modules. complementary software.
  • the authentication server AS customized to the authentication server AS
  • substep A5 sending the download link from the personalized application to the mobile terminal
  • This second embodiment is particularly suitable for applications for which the service provider wishes to manage itself the authentication of transactions, for reasons of security. This can for example be the case when the service provider is a banking operator for online transactions.
  • Figure 3A illustrates the substeps of step B of activating the custom application according to one embodiment of the present invention.
  • a first substep B1 the user Ui downloads the personalized application in his mobile terminal by means of the download link sent to him beforehand during the enrollment step A.
  • activation of the personalized application can then be performed during a substep B2, and this advantageously by means of a PIN code received in advance during the step A enrollment.
  • confidential data generated during the enrollment step A are also downloaded during a substep B3.
  • these confidential data may also include one or more private key (s) encryption, these keys then being used to encrypt the data subsequently exchanged between the server AS and the mobile terminal TEL, for example by means of a asymmetric encryption method.
  • s private key
  • This confidential data is stored securely both in the mobile terminal TEL and in the server AS, for example encrypted.
  • the confidential data stored in the AS authentication server are stored in HSM (Hardware Security Module in English) to avoid possible internal compromise in the operator operating the AS server.
  • HSM Hardware Security Module in English
  • the confidential data is encrypted before being stored in secure areas of the mobile terminal.
  • a substep B4 registration of the initial authentication of the mobile terminal is performed.
  • This substep B4 registration of the initial authentication legally guarantees that the authentication can not be delivered later, which would then weaken the legal value of the entire authentication process.
  • This initial authentication step can be carried out by sending a number of initial authentication data dinit of the mobile terminal of the user Ui to the authentication server AS.
  • the user Ui may be required to present a piece of identification to the camera of his mobile terminal.
  • the snapshot of this piece of identification, taken by this camera, is then encrypted and transmitted to the AS server where it is stored.
  • Such a process may be completely dematerialized or require human intervention to verify the identity of the user Ui.
  • FIG. 3B illustrates the system implementing step B of activation of the personalized application according to the principle of the present invention, as described above.
  • FIG. 3B the various exchanges made during the activation step described in FIG. 3A are illustrated.
  • the data streams corresponding to the sub-step of sending B1 for downloading the personalized application in the mobile terminal TEL, the substep B3 for downloading the confidential data in the mobile terminal TEL and the substep B4 registration of the initial authentication with the AS authentication server are indicated.
  • the SP server of the service provider and the PC computer of the user Ui are not affected by this activation step.
  • FIG. 4A illustrates the substeps of a second embodiment of "on-line" type of step E of generating the authorization code.
  • the authentication data can be transmitted directly to the AS server, as read by the mobile terminal, which simplifies and speeds up the processing at the mobile terminal.
  • the mobile terminal has the function of only reading the authentication data and all other processing is performed on the authentication server AS.
  • the authentication data item can be interpreted and processed at least partly in the mobile terminal in view of its transfer to the AS server.
  • the authentication data can be encrypted, for example with a method asymmetric encryption, before being transmitted to the AS server to prevent anyone from accessing this authentication data.
  • the entire authorization code generation process can be performed in the mobile terminal, in which case the authentication server AS serves only to perform functions unrelated to the generation of the authorization code, such as the storage of this code or the management of the traceability of the transactions made by the user.
  • a substep E3 authentication of the transaction required by the user can then be performed.
  • the authorization code cod itself, is then generated in the authentication server AS during a generation step E4.
  • this authorization code is transmitted (step E5 of transmission of the code) of the authentication server AS to the mobile terminal TEL, possibly in encrypted form by means of one or more key (s) generated (s). ) during step B of activation of the personalized application, to be displayed therein, possibly after having been signed by means of a secret code (or even of an identification data of the mobile terminal) before being encoded as an image.
  • the value of the generated authorization code makes it possible to certify that the authentication data has been understood and used to authenticate the user.
  • step F the authorization code read by the digital device of the user Ui (step F) and once the transactional data transmitted, with the authorization code entered, from the personal computer to the server of the service provider (step G), it is advantageous to carry out, after the actual transaction, a step of timestamping the transaction in order to keep a proof of the time and date on which the transaction was made.
  • a time stamp can be performed by the authentication server AS, in a traceability logic of the transaction.
  • FIG. 4B illustrates the system implementing the authentication method according to a first embodiment of "on-line" type where the authorization code is generated in an authentication server AS distinct from the server of the service provider.
  • step A the data flows corresponding to the enrollment steps (step A), sending an authentication data item (step C), reading this authentication data item (step D), entering the code authorization by the user's computer (step E) and transmission of the transaction to the server of the service provider (step G) are similar to those described in the "off-line" embodiment and illustrated on the Figure 1 B.
  • This first embodiment "on-line” is characterized in that the mobile terminal transfers the authentication data to the authentication server AS during the substep E1, the different substeps of identification of the user , authentication of the transaction and generation of the authorization code cod (substeps E2 to E4) then being performed in this authentication server AS before the authorization code cod, is transmitted to the mobile terminal when of the transmission sub-step E5.
  • the transaction can be time stamped by the SP server of the service provider, to serve as evidence available to the service provider if necessary.
  • the history of timestamped transactions is thus kept within the SP server of the service provider.
  • FIG. 4C illustrates the system implementing the authentication method according to a second embodiment of the "on-line" type where the authorization code is generated in the SP server of the service provider on which the authentication functionalities previously described have been installed.
  • FIG. 4C the different data streams described are similar to those described with reference to FIG. 4B, with the only difference that the authentication server AS and the service provider's server SP form one and the same managed entity. by the service provider.
  • This embodiment is particularly suitable for applications requiring an increased level of security, and in particular in the banking field where strict data confidentiality criteria apply, particularly in terms of data exchange between the transaction module and the data module. 'authentication.
  • this transaction can be time stamped by both the authentication module and the SP server itself, in order to serve as proof for the service provider if applicable. .
  • the history of timestamped transactions is thus kept within the SP server of the service provider.
  • the server SP can also keep in memory other traceability data such as the content of the transaction or the identifier of the user.
  • the authentication method described above makes it possible to withstand most, if not all, known and listed attacks in the context of an authentication and / or signature transaction on the Internet, which are intended to compromise the establishment of a communication between a client and a server and / or altering its operation, the list of which is given below:
  • Malware is an application used for fraudulent purposes. They can access a computer through vulnerabilities of its protection through social engineering. When the malware is running, it can usually take full control of the computer and for example steal the user's information and personal data, enable remote control of the computer, or perform actions. in the name of the user.
  • the only sensitive personal data is stored in secure space, with the server of the service provider, they are out of range of malware.
  • Keylogging attacks are carried out using parasitic programs called “keyloggers” that often spread through viruses, worms or spyware.
  • a keylogger's main function is to spy on all actions performed on the user's computer (typing, opening applications, moving files, etc.). Traces of these actions are stored in a specific location and then sent to a mailbox or website. Some of the most confidential data can be extracted without the knowledge of the user.
  • Some keyloggers are overly sophisticated and are able to select the most important information. They manage, when the user is on his online banking site for example, to identify and retrieve his bank codes. They can also know the content entered in his messages or know precisely what programs are requested by the user.
  • the personal data of the user Ui are neither stored nor used by the personalized application and the data enabling authentication thereof are for single use. Keylogging is therefore inefficient.
  • phishing During a phishing attack, otherwise known as phishing, the attacker uses an email or an instant messenger to lead the user to a website that appears to be trustworthy but is actually a true copy of the site. original and under his control.
  • the e-mail message such as the website can be for example an exact replica of an online banking site commonly visited by the user. He then believes that he is on a trustworthy site (for example, that of his bank) and enters his personal identification data such as his password, a one-time password or his number. credit card.
  • a "phishing" type attack possibly makes it possible to know the unique response to a given authentication datum. However, such a response could not be reused since the authentication data transmitted by the service provider is generated and changes each time.
  • the authentication data enables mutual authentication, which leads to the unveiling of the "fishing" site.
  • a "pharming" attack is a hacking technique exploiting vulnerabilities in the DNS server. This technique operates so that, for a DNS query targeting a particular domain name, it is not the real IP address of the domain name that is given but that of a fraudulent site.
  • the first type is achieved by modifying a local DNS server. Internet users requesting a domain name are directed to the IP address of a fraudulent server.
  • the second type is achieved by means of a malware reconfiguring the network settings of the infected computer hardware, whether it is a workstation or a router. This reconfiguration acts in such a way that the user is redirected, for predetermined domain names, to the IP address of a fraudulent server.
  • attacks of the "pharming" or "whaling" type may make it possible to know the unique response to a given authentication datum.
  • a such a response could not be reused since the authentication data transmitted by the service provider is generated and changes each time.
  • the man-in-the-middle attack is an attack scenario in which an attacker (the "man in the middle” or “man-in-the-middle” attack) "attacker") listens to a communication between two interlocutors and falsifies the exchanges between the client and the host in order to pretend to be one of the parties.
  • This attack involves three protagonists: the client, the server and the attacker.
  • the goal of the attacker is to pretend to be the client with the server and pose as the server to the client. He becomes the man of the middle. This makes it possible to monitor all network traffic between the client and the server, and modify it as much as you like to obtain information such as passwords, system access, and so on.
  • a MiTM attack between the Ui user and the service provider's SP server may allow the authorization code to be intercepted, but the authorization code is single-use and therefore not reusable.
  • MitB intercepts act between the client and its browser.
  • MitB An attack by MitB is designed by installing malicious software (i.e. malware) on the client's computer.
  • malicious software i.e. malware
  • the goal is to allow the attacker to control all unsecured applications and devices connected to the user's computer.
  • the usurpers then use this information to perform one or more transactions by simulating the identity of the defrauded person. For example, a fraudster may make phone calls or make major purchases and direct charges to the defrauded person, and may also withdraw money from that person's bank account.
  • the personal data of the user is not used during the authentication process.
  • An attack of type "ID Theft" is therefore inoperative.
  • a attack of the type "ID Theft” is inoperative because the personal data of the user are not used during the authentication process.
  • the attacker could use personal data obtained on the online commerce channel to connect to the online bank. Therefore, it becomes necessary to proceed to a separation of domains to guard against this type of attack.
  • the confidential data is specific to the service provider, drastically reducing cross-channel attack capabilities.
  • this attack consists of a transaction during which the card is not present on the merchant's site. This includes so-called internet orders, telephone and e-mail, more commonly known as Mail Order / Telephone Order (MoTo).
  • MoTo Mail Order / Telephone Order
  • the present invention also relates to an authentication server AS comprises a receiving module arranged to receive the authentication data of the th and at least one internal identification data d in t from the server SP of the service provider, computing means arranged to generate a cod authorization code, based on the received authentication data and at least one of the received internal identification data, and a transmission module arranged to transmit the code authorization code, generated to the mobile terminal TEL.
  • Such an authentication server AS can be used in the "on-line" embodiment as described in FIG. 4B, in which the authentication functionality of the transaction, by means of the authentication data aut h , is performed in a separate server from the service provider.
  • the present invention also relates to a system for authenticating a user requesting a transaction from a service provider comprising an SCN screen arranged to display an authentication data item received from the service provider, a mobile terminal TEL having access control means. entering the authentication data displayed on the screen and arranged to return a specific authorization code to the user and the required transaction, and PC input means for sending the authorization code to the service provider; service to authenticate the user.
  • This system is for example described in Figure 1 B.
  • this system involves an authentication server as described above.
  • system further comprises the SP server of the service provider, the server being arranged to provide the service required by the user, and comprising a receiving module arranged to receive at least one personal data of the user and the authorization code issued by the user, computing means arranged to generate at least one internal identification data from at least one of the personal data received, and a transmission module arranged for send the generated internal identification data to the AS authentication server.
  • SP server of the service provider the server being arranged to provide the service required by the user, and comprising a receiving module arranged to receive at least one personal data of the user and the authorization code issued by the user, computing means arranged to generate at least one internal identification data from at least one of the personal data received, and a transmission module arranged for send the generated internal identification data to the AS authentication server.
  • Such a service providing server SP can be used in the "on-line" embodiment as described in FIG. 4B, in which the service provisioning functionality is performed in a server separate from that performing the authentication of the service provider. the transaction.
  • service provider previously used covers any operator capable of providing a service in which a transaction is performed.
  • a supplier may be, for example, purely illustrative, a banking operator, an online gaming operator, a telecommunications operator, a rental company for vehicles or bicycles, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

La présente invention concerne un procédé d'authentification d'un utilisateur (Ui) requérant une transaction auprès d'un fournisseur de service (SP), le procédé comportant la génération (E) d'un code d'autorisation (cod,) spécifique à l'utilisateur et à la transaction requise à partir d'une donnée d'authentification (dauth) lue sur un écran au moyen d'un terminal mobile (TEL), la lecture (F) du code d'autorisation, affiché par le terminal mobile, par des moyens de lecture d'un dispositif numérique (PC) et l'envoi (G) par ledit dispositif numérique vers le fournisseur de service du code d'autorisation lu afin d'authentifier l'utilisateur.

Description

PROCEDE D'AUTHENTIFICATION D'UN UTILISATEUR REQUERANT UNE
TRANSACTION AVEC UN FOURNISSEUR DE SERVICE
La présente invention concerne le domaine de l'authentification, en particulier dans un contexte de sécurisation des accès et de services en ligne proposés dans le cadre de transactions bancaires.
Le besoin d'identifier un utilisateur requérant un service, d'une part, et d'authentifier cet utilisateur, d'autre part, est vraiment apparu avec le développement de l'internet et des services mobiles. Alors que l'identification consiste à communiquer une identité, l'authentification consiste à apporter la preuve de cette identité.
En matière de sécurité des systèmes d'information, une authentification est dite « forte » lorsqu'elle utilise une procédure d'identification requérant la concaténation d'au moins deux éléments ou « facteurs » d'authentification choisis parmi ce que l'entité à authentifier connaît, ce qu'elle détient ou ce qu'elle est.
L'authentification forte est une des fondations essentielles permettant de garantir l'autorisation ou contrôle d'accès à un service (i.e. qui peut y avoir accès), la confidentialité (i.e. qui peut voir le service), l'intégrité (i.e. qui peut modifier le service) et la traçabilité (i.e. qui y a accédé).
Par ailleurs l'usage d'une véritable technologie d'authentification forte se doit de garantir la non-répudiation, à savoir l'élément primordial à l'imputabilité des actions à une entité, qu'elle soit un individu ou une organisation, et ce de manière unique. Une entité authentifiée de manière forte ne peut pas nier avoir eu accès à un système ou signé un document dans la mesure où elle est la seule à détenir le secret le permettant.
Les techniques basées sur un "secret partagé", lesquelles sont souvent assimilées abusivement à des techniques d'authentification forte de haut niveau, ne permettent pas d'assurer la non-répudiation.
En particulier, la méthode classique d'authentification unique symbolisée par un couple identifiant/mot de passe, qui est actuellement le système le plus couramment utilisé pour identifier un utilisateur, présente un certain nombre de faiblesses en matière de sécurisation.
Ces différents niveaux d'authentification (simple ou forte) doivent être choisis en fonction du niveau de contractualisation qu'une entité souhaite appliquer et des effets juridiques ainsi produits. En particulier, il est entendu ici par contractualisation de la procédure, le fait de conférer à une procédure électronique une valeur contractuelle assortie d'une capacité de gestion de la preuve en cas de conflit.
Eu égard aux exigences de sécurisation des accès exigés par différentes autorités de tutelles dans les différents domaines, les trois couches suivantes de service de confiance sont à considérer : l'authentification, la signature électronique et l'horodatage. Cependant, et comme indiqué précédemment, il n'est pas facile de pouvoir répondre à l'ensemble des exigences indispensables à la mise en œuvre de ces trois couches de confiance.
Dans le cadre de l'authentification, le choix d'une méthode d'authentification adaptée à chaque besoin (par exemple pour une clientèle particulier ou professionnelle, pour l'accès banque en ligne notamment et sécurisation des services financiers) sera basé sur un certain niveau de contractualisation défini au moyen d'une analyse de risque fonction du coût des moyens d'authentification à mettre en œuvre, du coût lié aux différents risques (sensibilité de l'application, des données, etc..) et des bénéfices attendus pour l'utilisateur (en fonction de son niveau d'expertise).
A titre d'exemple, on peut citer les différents niveaux de contractualisation suivants :
Niveau de contractualisation 1 :
Ce premier niveau, meilleur que l'identification par simple paire d'identifiant/mot de passe, repose sur l'implémentation d'une solution d'authentification de bas niveau, assimilable à une pseudo authentification forte.
Niveau de contractualisation 2 :
Ce niveau peut être définit lorsque des moyens organisationnels et techniques sont mis en œuvre afin de garantir au mieux l'identité des différents acteurs (il peut s'agir par exemple des utilisateurs et/ou tiers autorisés d'un service e-banque ou e- coffre).
Ce niveau nous permet d'entrer dans la sphère de l'authentification forte, mais de 1 er degré sans pour autant que l'on puisse parler de « preuve au sens juridique du terme »
Niveau de contractualisation 3 :
Un troisième niveau de contractualisation peut être défini lorsque l'on rentre dans le périmètre de l'authentification forte où le degré d'authentification (2eme degré) est recevable juridiquement même si en cas de contestation la preuve de sa fiabilité reste à apporter par celui qui le met en œuvre.
Niveau de contractualisation 4 :
Le dernier niveau de contractualisation, que l'on qualifiera de présumé fiable, permet, outre les exigences que se doit de remplir un système d'authentification forte, de garantir la non répudiation.
Avec ce niveau de contractualisation, les conditions techniques et organisationnelles devant êtres remplies sont nombreuses et difficiles à réunir, mais la valeur juridique d'un tel procédé est présumé fiable. C'est le niveau d'authentification forte le plus élevé. Ce niveau de contractualisation est celui que l'on rencontre lorsque l'on décide de mettre en œuvre un système de « signature électronique qualifiée » présumée fiable.
Il existe aujourd'hui une panoplie de moyens permettant de s'authentifier de manière sécurisée comme les clefs USB, les jetons (« Token » en anglais), les lecteurs de cartes, etc ..
Tous ces moyens, en plus d'être tous aussi coûteux les uns que les autres, ne permettent pas d'éviter toutes les attaques de pirates identifiées. De plus des moyens logistiques importants sont nécessaires pour livrer ces moyens et les rendre opérationnels chez l'utilisateur.
Un objet de la présente invention est de répondre aux problèmes ci-avant.
En particulier, la présente invention vise à fournir un système d'authentification convivial, intuitif, ergonomique, sécurisé et utilisable par un maximum de clients.
La présente invention vise également à créer un contexte transactionnel sécurisé à même d'assurer le transport, le chiffrement/déchiffrement de données dynamiques et la présentation de ces données à un serveur pour le traitement, la validation, l'horodatage et l'archivage légal de cette transaction dans des usages nécessitant un haut niveau de confiance.
La présente invention vise en particulier à permettre des usages et des services nécessitant un haut niveau de sécurité, comme le paiement et la signature électronique, assortis d'une option de non répudiation. La présente invention propose à cet effet un procédé d'authentification d'un utilisateur requérant une transaction auprès d'un fournisseur de service, le procédé comportant la génération d'un code d'autorisation spécifique à l'utilisateur et à la transaction requise à partir d'une donnée d'authentification lue sur un écran au moyen d'un terminal mobile, la lecture du code d'autorisation, affiché par le terminal mobile, par des moyens de lecture d'un dispositif numérique et l'envoi, par ce dispositif numérique vers le fournisseur de service, du code d'autorisation lu afin d'authentifier l'utilisateur.
Le caractère spécifique du code d'autorisation ainsi généré empêche sa réutilisation par un utilisateur malveillant au cours d'une transaction ultérieure. De plus, le fait de lire aussi bien la donnée d'authentification que le code d'autorisation qui en découle avec des moyens tels qu'un terminal mobile ou un ordinateur permet de rendre plus ergonomique le processus d'authentification et d'éviter les erreurs de saisie que l'utilisateur peut faire quand il est amené à saisir des codes dont la longueur peut être importante.
Avantageusement, le code d'autorisation est généré en signant la donnée d'authentification lue au moyen d'un code secret saisi par l'utilisateur sur le terminal mobile, ce qui permet d'authentifier de manière plus fiable l'utilisateur requérant la transaction.
Dans un mode de réalisation particulièrement avantageux, le code d'autorisation est généré en signant la donnée d'authentification en outre au moyen d'une donnée d'identification du terminal mobile, ce qui permet d'assurer une authentification forte
Dans un mode de réalisation particulièrement avantageux, le code d'autorisation généré est encodé sous la forme d'une image, en particulier d'un code-barres en deux dimensions, avant d'être affiché par le terminal mobile. L'utilisation d'une telle image évite notamment qu'un tiers malveillant puisse intercepter le code d'autorisation en observant le terminal mobile à l'insu de l'utilisateur.
Dans un autre mode de réalisation, la lecture du code d'autorisation est effectuée au moyen d'une technologie de communication sans-fil de type communication en champ proche.
Selon un autre mode de réalisation, le procédé comprend la transmission de la donnée d'authentification lue du terminal mobile au serveur d'authentification (AS), la génération du code d'autorisation à partir de la donnée d'authentification dans le serveur d'authentification, et la transmission du code d'autorisation généré au terminal mobile. Ce mode de réalisation permet d'alléger les calculs devant être effectués au niveau du terminal mobile.
Avantageusement, la donnée d'authentification lue est interprétée dans le terminal mobile au moyen d'une application personnalisée spécifique à l'utilisateur et téléchargée à partir d'un serveur d'authentification, ladite application personnalisée générant le code d'autorisation à partir de la donnée d'authentification lue.
Plus particulièrement, le procédé comprend en outre une étape préalable d'enrôlement, au cours de laquelle un code d'activation est transmis au terminal mobile, suivie d'une étape d'activation au cours de laquelle l'application personnalisée est téléchargée dans le terminal mobile, ce code d'activation étant utilisé lors de l'étape d'activation pour activer l'application personnalisée téléchargée, ce qui permet de laisser à l'utilisateur le choix du moment où il désire activer l'application personnalisée.
Dans un mode de réalisation, l'étape d'enrôlement comprend une étape de vérification de l'identité de l'utilisateur avant la transmission du code d'activation, ladite transmission n'étant effectuée que si ladite vérification est effectuée de façon positive.
Dans un autre mode de réalisation, l'étape d'activation comprend la transmission d'au moins une donnée confidentielle spécifique à l'utilisateur du terminal mobile, cette donnée confidentielle servant à chiffrer la donnée d'authentification dans le terminal mobile avant sa transmission au serveur d'authentification et/ou à déchiffrer le code d'autorisation reçu par le terminal mobile. Les transferts de la donnée d'authentification au serveur d'authentification, d'une part, et du code d'autorisation au terminal mobile, d'autre part, sont ainsi sécurisés.
Dans un autre mode de réalisation, le procédé comprend la génération, au cours de l'étape préalable d'enrôlement, de l'application personnalisée et/ou de la donnée confidentielle en fonction d'au moins une donnée interne d'identification générée à partir d'au moins une donnée personnelle d'identification envoyée par l'utilisateur au fournisseur de service.
Dans un mode de réalisation avantageux, la donnée d'authentification est générée, par le fournisseur de service, en fonction de données liées à la transaction et de données personnelles reçues de l'utilisateur, ce qui empêche la réutilisation d'un telle donnée d'authentification par un utilisateur malveillant au cours d'une transaction ultérieure. Suivant un deuxième aspect, la présente invention propose un système d'authentification d'un utilisateur requérant une transaction auprès d'un fournisseur de service, le système comprenant un écran arrangé pour afficher une donnée d'authentification reçue du fournisseur de service, un terminal mobile comprenant des moyens de saisie de la donnée d'authentification affichée sur l'écran et des moyens d'affichage arrangés pour afficher un code d'autorisation spécifique à l'utilisateur et à la transaction requise et un dispositif numérique comprenant des moyens de saisie aptes à lire le code d'autorisation affiché par le terminal mobile et envoyer ce code d'autorisation au fournisseur de service afin d'authentifier l'utilisateur.
Avantageusement, ce système d'authentification comprend en outre un serveur d'authentification tel que décrit ci-avant.
Dans un mode de réalisation particulier, le système d'authentification comprend un serveur de service, utilisé par le fournisseur de service pour fournir un service requis par l'utilisateur, ce serveur de service comprenant un module de réception arrangé pour recevoir au moins une donnée personnelle de l'utilisateur et le code d'autorisation émis par l'utilisateur, des moyens de calcul arrangé pour générer au moins une donnée interne d'identification à partir d'au moins une des données personnelles reçues, et un module d'émission arrangé pour envoyer la donnée interne d'identification générée au serveur d'authentification.
D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels :
la figure 1 A représente les étapes d'un procédé d'authentification selon le principe de la présente invention ;
la figure 1 B illustre un système selon un premier mode de réalisation de type « off-line » mettant en œuvre le procédé d'authentification de la présente invention ;
la figure 2A représente les sous-étapes de l'étape d'enrôlement du procédé d'authentification selon le principe de la présente invention ;
la figure 2B représente un premier mode de réalisation du système mettant en œuvre l'étape d'enrôlement du procédé d'authentification selon le principe de la présente invention ; la figure 2C représente un deuxième mode de réalisation du système mettant en œuvre l'étape d'enrôlement du procédé d'authentification selon le principe de la présente invention ;
la figure 3A illustre les sous-étapes constitutives de l'étape d'activation de l'application personnalisée selon un mode de réalisation de la présente invention ;
la figure 3B illustre un système mettant en œuvre l'étape d'activation de l'application personnalisée du procédé d'authentification selon le principe de la présente invention ;
la figure 4A illustre les sous-étapes constitutives de l'étape de génération du code d'autorisation d'un procédé d'authentification selon un deuxième mode de réalisation de type « on-line » ;
la figure 4B illustre un premier mode de réalisation du système mettant en œuvre le procédé d'authentification selon le deuxième mode de réalisation de type « online », où le code d'autorisation est généré dans un serveur d'authentification AS distinct du serveur du fournisseur de services ; et
la figure 4C illustre un deuxième mode de réalisation du système mettant en œuvre le procédé d'authentification selon le deuxième mode de réalisation de type « on-line », où le code d'autorisation est généré dans le serveur du fournisseur de services sur lequel des fonctionnalités d'authentification ont été installées.
Sur la figure 1A sont illustrées les étapes d'un procédé d'authentification selon le principe de la présente invention.
Ce procédé peut démarrer avec une étape A d'enrôlement d'un utilisateur Ui auprès d'un fournisseur de services avec lequel il désire effectuer une transaction.
A cette occasion, l'utilisateur Ui va envoyer à ce fournisseur de service (par exemple à un serveur de service SP géré par ce fournisseur de service) un certain nombre de données personnelles d'identification (dénommées ici « did»), par exemple en les saisissant sur son ordinateur par le biais d'une application client associée au serveur SP du fournisseur de services.
De telles données personnelles did servent à identifier formellement l'utilisateur Ui lorsque celui s'inscrit à un service. Une fois que le serveur SP a reçu ces données personnelles, celles-ci sont contrôlées par le fournisseur de service, afin de pouvoir garantir ultérieurement que l'utilisateur Ui est bien le véritable utilisateur.
Un tel contrôle peut être fait sur la base de données déjà connues si l'utilisateur est déjà connu (grâce à des données présentes sur un relevé bancaire, par exemple), par un appel téléphonique d'un opérateur, ou par la demande de la copie de la carte d'identité d'un nouvel utilisateur.
Une fois vérifiées, ces données personnelles sont stockées de manière sécurisée, par exemple dans le serveur SP du fournisseur de service ou dans un autre serveur délégué à cette tâche.
Suite à l'enrôlement de l'utilisateur Ui auprès du fournisseur de services, une étape B d'activation d'une application personnalisée, générée spécifiquement pour l'utilisateur Ui, sur un terminal mobile appartenant à l'utilisateur Ui peut être effectuée à ce stade, afin de permettre à l'utilisateur Ui d'utiliser son terminal mobile dans la procédure d'authentification auprès du fournisseur de services. Un exemple d'une telle étape d'activation est décrit plus loin.
Une fois l'utilisateur Ui enrôlé auprès du fournisseur de services et muni d'un terminal mobile disposant d'une application personnalisée utilisable pour permettre son authentification, l'utilisateur Ui est prêt à effectuer une transaction nécessitant une authentification avec le fournisseur de services.
Pour cela, le procédé comporte une étape C d'affichage d'une donnée d'authentification (dénommée dauth par la suite) sur un écran SCN auquel a accès l'utilisateur Ui. Un tel écran peut être naturellement l'écran connecté à l'ordinateur personnel de l'utilisateur Ui, auquel cas la donnée d'authentification dauth est transmise au préalable du serveur SP du fournisseur de services à cet ordinateur personnel pour être affichée sur cet écran. Cet écran peut également être un écran de télévision, voire un écran de téléphone mobile.
L'envoi de cette donnée d'authentification peut être conditionné à la réception, par le serveur SP, d'une requête en transaction émanant de l'ordinateur personnel de l'utilisateur Ui. Par exemple, l'utilisateur Ui peut utiliser son ordinateur personnel pour accéder à une application client associée au fournisseur de services (par exemple par le biais du site internet de ce fournisseur) et indiquer son intention d'effectuer une transaction. Suite à cette indication, le serveur SP génère et envoie la donnée d'authentification à l'ordinateur personnel de l'utilisateur Ui. La donnée d'authentification dauth affichée lors de l'étape C peut prendre la forme d'un code-barres en deux dimensions, d'un tag, d'un mot de passe à une seule utilisation (« One-Time Password » ou OTP en anglais) ou d'un message NFC (pour « Near-Field Communication »), entre autres.
De préférence, lorsqu'un code-barres en deux dimensions ou un tag est employé, la représentation graphique de ce code-barres en deux dimensions ou de ce tag respecte les standards couramment utilisés, comme par exemple QR-Code, Datamatrix, PDF 417, Microsoft tag.
Avantageusement, la donnée d'authentification dauth transmise par le fournisseur de services est générée spécifiquement pour la transaction requise, en fonction de données liées à la transaction et éventuellement de données personnelles reçues de l'utilisateur.
D'une manière avantageuse, cette donnée d'authentification dauth est à usage unique et est générée à chaque transaction de façon à être différente pour chaque transaction requise. Ainsi, la connaissance éventuelle de cette donnée d'authentification par interception d'un utilisateur malveillant ne lui permet pas d'utiliser cette information pour les transactions ultérieures.
A la suite de l'affichage de la donnée d'authentification dauth, l'utilisateur Ui utilise son terminal mobile pour y entrer cette donnée d'authentification, lors d'une étape D de lecture, afin qu'elle soit interprétée par l'application personnalisée préalablement activée lors de l'étape B.
Dans un premier mode de réalisation, cette donnée d'authentification dauth est lue par l'utilisateur Ui, lequel l'entre manuellement sur son terminal mobile. Ce premier mode de réalisation est en particulier adapté lorsque le terminal mobile de l'utilisateur ne dispose pas de moyens de lecture propres tels qu'un appareil photo.
Dans un autre mode de réalisation destiné à limiter l'interaction avec l'utilisateur, potentielle source d'erreur, la donnée d'authentification dauth est lue directement par le terminal mobile, lequel dispose de ses propres moyens de lecture.
Ainsi, lorsque le terminal mobile dispose d'un appareil photo, l'utilisateur Ui peut prendre une photo de la donnée d'authentification dauth affichée sur l'écran, et l'application activée dans le logiciel va utiliser le cliché pris pour retrouver les données pertinentes dans la donnée d'authentification et les interpréter.
Alternativement, lorsque le terminal mobile dispose d'un lecteur NFC, ce dernier peut lire une donnée d'authentification dauth présentée sous forme de message NFC en utilisant une technologie de communication sans-fil de type communication en champ proche, désignée par « Near-Field Communication » en anglais. Cette alternative permet d'éviter d'avoir à viser précisément l'écran SCN avec le terminal mobile.
Suite à la lecture de la donnée d'authentification dauth et son interprétation dans le terminal mobile de l'utilisateur Ui, un code d'autorisation cod, est généré, puis affiché par le terminal mobile, lors d'une étape E de génération de code. Ce code cod, sert à authentifier l'utilisateur Ui auprès du fournisseur de services.
Similairement à ce qui a été dit au sujet de la donnée d'authentification, le code d'autorisation cod, est avantageusement encodé sous la forme d'une image, d'un code- barres en deux dimensions, d'un tag, d'un mot de passe à une seule utilisation (« One- Time Password » ou OTP en anglais) ou d'un message NFC, entre autres.
Cette étape E de génération du code d'autorisation peut être implémentée selon différents mode de réalisation.
Dans un premier mode de réalisation dit « off-line », le code d'autorisation cod, est généré intégralement par l'application personnalisée installée sur le terminal mobile, ce qui permet d'utiliser ce terminal mobile sans que celui-ci ne soit forcément connecté au réseau mobile et limite les transferts de données sensibles pouvant être récupérées par un tiers malveillant.
Dans un tel mode, l'application personnalisée interprète la donnée d'authentification dauth lue et génère à partir de la donnée interprétée un code d'autorisation cod, qui est affiché par le terminal mobile.
L'application personnalisée, outre la donnée d'authentification dauth, peut également utiliser un code secret confié à l'utilisateur pour générer le code d'autorisation, ce qui permet de renforcer le caractère spécifiquement lié à l'utilisateur de ce code d'autorisation.
Ainsi, dans un mode particulier de réalisation avantageux, le code d'autorisation codi est généré, par l'application personnalisée installée sur le terminal mobile, à partir de la donnée d'autorisation dauth lue par le terminal mobile et d'un code secret affecté à l'utilisateur, ce code secret pouvant être utilisé pour signer la donnée d'autorisation dauth afin d'obtenir un code d'autorisation cod, à usage unique, lequel prend la forme d'un mot de passe à usage unique (« One-Time Password » en anglais).
En particulier, le code d'autorisation cod, peut être généré en signant la donnée d'authentification dauth lue au moyen d'un tel code secret saisi par l'utilisateur sur le terminal mobile TEL, ce code secret étant par ailleurs connu du côté du serveur d'authentification AS, afin de permettre le déchiffrement de ce code d'autorisation. Un tel code d'autorisation est alors non seulement spécifique à la transaction requise, mais sert à authentifier l'utilisateur requérant cette transaction.
Dans un autre mode de réalisation particulièrement avantageux, le code d'autorisation cod, est généré en signant la donnée d'authentification dauth au moyen non seulement du code secret de l'utilisateur, mais également d'une donnée d'identification du terminal mobile (par exemple son numéro IMEI), ce qui permet de vérifier, lors de l'étape de vérification ultérieure, que la transaction est bien associée à cet utilisateur Ui et que c'est bien l'utilisateur Ui qui a généré le code d'autorisation.
On peut ainsi effectuer une authentification forte avec double facteur d'authentification, utilisant aussi bien un code secret (qui authentifie ce que l'utilisateur Ui « sait », premier facteur d'authentification) qu'un identifiant du terminal mobile (qui authentifie ce que l'utilisateur « possède », deuxième facteur d'authentification).
Par ailleurs, outre le code secret de l'utilisateur et une donnée d'identification du terminal mobile, une donnée d'horodatage peut également être utilisée pour signer la donnée d'authentification dauth, ce qui complexifie encore plus le code d'autorisation cod, et permet de dater l'instant d'authentification de la transaction.
Dans un mode particulier de réalisation, le code d'autorisation cod, est avantageusement encodé sous forme d'image, par exemple sous la forme d'un code- barres en deux dimensions ou de tag. Le code d'autorisation est alors illisible directement par un être humain, ce qui permet d'une part d'éviter que le code d'autorisation soit visuellement intercepté par un utilisateur malveillant pouvant regarder l'écran du terminal mobile, tout en permettant d'autre part sa lecture, lorsqu'il est affiché par le terminal mobile, par des moyens de lecture optique aptes à lire ce type de code- barres.
Ce mode de réalisation permet en outre l'utilisation de codes d'autorisation de longueur importante (par exemple de 256 caractères), donc très spécifiques et plus sûr que les codes d'autorisation devant être rentrés manuellement par un utilisateur, et donc devant être limités en longueur sous peine d'entraîner des erreurs de saisie de l'utilisateur.
Un tel mode de réalisation est particulièrement adapté à l'encodage d'un code d'autorisation cod, complexe généré par la signature de données d'authentification au moyen du code secret de l'utilisateur, d'une donnée d'identification du terminal mobile et d'une donnée d'horodatage. Une fois ce code d'autorisation cod, généré, il est affiché sur le terminal mobile afin de pouvoir être saisi par un dispositif numérique PC de l'utilisateur Ui, lors d'une étape F de lecture de ce code d'autorisation cod,.
Le dispositif numérique PC utilisé pour lire ce code d'autorisation cod, peut être un ordinateur personnel comprenant des moyens de lecture aptes à lire ce code (par exemple une webcam, une caméra numérique ou un lecteur NFC), voire un téléphone mobile comprenant des moyens de lecture (par exemple de type appareil photo numérique ou lecteur NFC) aptes à capturer une image du code d'autorisation cod,.
Ici donc également, la lecture du code d'autorisation peut être réalisée grâce à une technologie de communication sans-fil de type communication en champ proche (NFC), afin de ne pas avoir à viser précisément le terminal mobile avec les moyens de lecture du dispositif numérique PC.
Dans un mode particulier de réalisation l'écran SCN, sur lequel est lue la donnée d'authentification dauth lors de l'étape D de lecture, peut appartenir au même dispositif numérique PC que les moyens de lecture utilisés pour lire le code d'autorisation cod,.
Avec de tels moyens de lecture, il est alors possible d'entrer directement le code d'autorisation cod, sur le dispositif numérique PC, par simple lecture du code d'autorisation affiché par le terminal mobile au moyen de ces moyens de lecture.
Dans le mode de réalisation où le code d'autorisation cod, a été encodé sous forme d'image (en particulier sous forme de code-barres en deux dimensions) avant d'être affiché par le terminal mobile, l'image est alors lue par les moyens de lecture du dispositif numérique pour pouvoir ensuite être transmise au serveur SP du fournisseur de services. Dans un mode de réalisation avantageux, cette image lue peut être décodée au niveau du dispositif numérique PC, par exemple au moyen d'une reconnaissance de formes, afin de retrouver le code d'autorisation cod, et de transmettre ce code sous forme décodée plutôt que sous la forme d'une image.
Ceci est avantageux par rapport à un mode de réalisation consistant en ce que l'utilisateur lise lui-même ce code d'autorisation et le rentre manuellement auprès de son ordinateur personnel, qui nécessite un code d'autorisation suffisamment lisible et mémorisable par un être humain, c'est-à-dire un code relativement simple comme un code constitué de caractères alphanumériques
Si l'on prend l'exemple d'un utilisateur ayant téléchargé l'application personnalisée auprès de son établissement financier et venant de se connecter à son site de banque en ligne, lorsque celui veut accéder à ses comptes personnels, il va lancer l'application personnalisée et rentrer son code secret, afin de générer un code d'autorisation à usage unique. Si le code d'autorisation généré se présente sous la forme d'une image, c'est-à-dire lorsque ce code d'autorisation est encodé sous forme d'une image (par exemple un code-barres en deux dimensions), l'utilisateur présente ensuite cette image devant une webcam connectée à son ordinateur personnel, afin que cette image puisse être automatiquement transférée au serveur de la banque pour permettre ou non sa connexion.
Dans un autre mode de réalisation dit « on-line », le code d'autorisation cod, est généré dans un serveur distinct du terminal mobile, lequel se contente alors d'interpréter la donnée d'authentification lue et éventuellement de la mettre en forme et de la chiffrer avant de la transmettre à ce serveur, lequel génère le code d'autorisation codi en fonction de la donnée d'authentification dauth qu'il reçoit via le terminal mobile et renvoie ce code d'autorisation au terminal mobile où il est affiché. Le mobile peut, selon les cas, directement transmettre ce code d'autorisation, ou le traduire et le traiter avant de le transmettre au serveur d'authentification.
Une fois le code d'autorisation cod, lu par le dispositif numérique de l'utilisateur Ui, les données transactionnelles ainsi que ce code d'autorisation cod, sont envoyés (étape G) vers le serveur SP du fournisseur de services qui va effectuer la vérification (étape H) de ce code afin d'authentifier l'utilisateur Ui et permettre la transaction si cette authentification est correcte.
La figure 1 B illustre un système selon un premier mode de réalisation de type « off-line », mettant en œuvre le procédé d'authentification de la présente invention tel que décrit précédemment sur la figure 1 A.
Un tel système comprend un serveur SP appartenant au fournisseur de services connecté, par exemple par le biais du réseau internet, à l'ordinateur personnel (« PC ») de l'utilisateur Ui.
Cet ordinateur personnel dispose d'un écran (« SCN ») qui sert à afficher la donnée d'authentification dauth envoyée par le serveur SP, ainsi que de moyens de lecture (par exemple une webcam ou un lecteur optique) permettant de lire un code d'autorisation affiché par un terminal mobile.
Outre les éléments précités, la présente invention utilise un terminal mobile TEL tel qu'un téléphone mobile, un smartphone, un baladeur numérique, etc .. appartenant à l'utilisateur Ui, sur lequel est installée une application capable d'interpréter la donnée d'authentification et qui présente des moyens d'affichage (comme un écran LCD) sur lequel peut être affiché un code d'autorisation.
Sur cette figure 1 B les différents échanges effectués lors du procédé décrit à la figure 1 A sont décrits. En particulier, les flux de données correspondant à l'étape préalable A d'enrôlement, l'étape C d'envoi d'une donnée d'authentification, l'étape D de lecture de cette donnée par le terminal mobile, l'étape F de lecture du code d'autorisation sur l'ordinateur personnel et l'étape G d'envoi du code saisi vers le serveur SP sont indiqués.
La figure 2A illustre les sous-étapes de l'étape A d'enrôlement selon un mode de réalisation de la présente invention utilisant un serveur d'authentification AS.
Lors d'une première sous-étape A1 , l'utilisateur Ui envoie au serveur SP du fournisseur de services un certain nombre de données personnelles d'identification did, par exemple en les saisissant sur son ordinateur par le biais d'une application client associée au serveur SP du fournisseur de services.
Ces données personnelles d'identification did, une fois reçues par le serveur SP, sont mémorisées lors d'une sous-étape A2 de mémorisation.
Ensuite, lors d'une sous-étape A3, le serveur SP du fournisseur de services envoie une requête req à un serveur d'authentification AS afin que celui-ci génère un certain nombre d'éléments servant à l'authentification de l'utilisateur.
Dans un premier mode de réalisation, ce serveur d'authentification AS peut correspondre au serveur SP du fournisseur de services sur lequel des fonctionnalités supplémentaires d'authentification ont été installées. Avec ce premier mode de réalisation où les fonctionnalités d'authentification, d'identification et de fourniture de services sont intégrées au sein d'un même serveur, tous les échanges entre modules d'authentification et de fourniture de services se font au sein d'un même environnement sécurisé, ce qui accentue la sécurisation du système.
Dans un deuxième mode de réalisation, ce serveur d'authentification AS est un serveur distinct du serveur SP du fournisseur de services, auquel cas les fonctionnalités d'authentification sont délibérément séparées des fonctionnalités de transaction et de fourniture de services, ce qui permet une gestion de l'authentification par un opérateur distinct du fournisseur de services, lequel n'a pas forcément les compétences techniques ni la capacité à gérer cette authentification.
Dans ce deuxième mode de réalisation, la requête req s'accompagne d'un certain nombre de données dim d'identification internes de l'utilisateur, basées sur les données personnelles d'identification reçues par le serveur SP mais différentes de celles-ci, afin de permettre la génération des éléments servant à l'authentification de l'utilisateur dans le serveur d'authentification AS, tout en garantissant l'anonymat de celui-ci auprès de ce serveur.
Ainsi, dans la mesure où les seules données personnelles sensibles de l'utilisateur sont stockées en espace sécurisé auprès du serveur SP du fournisseur de services, elles sont hors de portée des malwares qui pourraient avoir accès au serveur d'authentification AS.
Suite à la réception de la requête req, le serveur d'authentification AS génère (sous-étape A4) d'une part l'application personnalisée APP, qui va servir à interpréter la donnée d'authentification dauth et qui est destinée à être installée sur le terminal mobile TEL, de l'utilisateur.
Une telle application personnalisée APP, peut, par exemple, contenir un certain nombre d'éléments personnalisés permettant de personnaliser l'application afin de la rendre spécifique à l'utilisateur Ui. Par exemple, cette application personnalisée peut contenir la signature du mot de passe de l'utilisateur ainsi qu'un algorithme permettant de vérifier ce mot de passe.
Ces éléments personnalisés et spécifiques à l'utilisateur Ui sont implémentés « en dur » (i.e. ils ne sont pas modifiables) dans l'application personnalisées et sont propre à l'utilisateur.
Dans un mode avantageux de réalisation permettant l'activation différée de cette application personnalisée, cette application APP, contient également un algorithme de vérification d'un code PIN d'activation.
La durée de validité de l'application personnalisée APP, est par ailleurs configurable par l'opérateur du serveur d'authentification AS en fonction du fournisseur de services concerné et selon les besoins de ce fournisseur de services.
Le serveur d'authentification AS peut également générer, toujours lors de cette sous-étape A4 de génération, un certain nombre de données confidentielles suivantes, désignées par l'abréviation « sert, » dans la figure 2A, en fonction des données d'identification reçues par le serveur AS :
- identifiant et mot de passe de l'utilisateur ;
- code PIN d'activation de l'application personnalisée ;
- clé de stockage des informations à destination du terminal mobile ;
- une ou plusieurs clé(s) de chiffrement des échanges entre le terminal mobile TEL et le serveur d'authentification AS ; - une ou plusieurs clé(s) de signature de l'utilisateur, si nécessaire.
Ces données confidentielles sert, sont spécifiques à l'utilisateur Ui et sont générées à partir des données internes dim qui ont été elles-mêmes générées à partir des données personnelles d'identification did de l'utilisateur, par exemple en même temps que l'application personnalisée APP,. Ces données confidentielles sert, sont destinées à être transmises au terminal mobile TEL de l'utilisateur Ui.
Chaque utilisateur Ui distinct s'enrôlant auprès du fournisseur de services dispose donc de données confidentielles sert, distinctes des autres utilisateurs. Ainsi, la copie de l'application personnalisée APP, sur un autre terminal mobile que celui de l'utilisateur Ui est inutile sans les données confidentielles sert, générées par le serveur AS.
De même, la copie des données confidentielles sert, sur un autre terminal mobile que celui de l'utilisateur Ui rend ces données confidentielles sert, non interprétables par cet autre terminal mobile.
Dans un mode de réalisation avantageux où une donnée confidentielle sert, comprend une clé de chiffrement servant à chiffrer les échanges entre le terminal mobile TEL et le serveur d'authentification AS, cette clé de chiffrement est composé au moins d'une première clé pour l'utilisateur Ui et d'une deuxième clé pour le serveur d'authentification AS.
Dans un mode de réalisation particulier de l'enrôlement de l'utilisateur où l'application personnalisée APP, générée est directement téléchargée, le procédé se poursuit par une étape A5 de téléchargement de l'application personnalisée APP, dans le terminal mobile de l'utilisateur Ui. Cette application personnalisée APP, peut y être activée ultérieurement au moyen d'un code PIN d'activation si cette option d'activation ultérieure est choisie.
Dans un autre mode de réalisation alternatif où le téléchargement de l'application personnalisée APP, par le terminal mobile n'a pas lieu directement lors de l'enrôlement de l'utilisateur, l'étape A5 comprend alors, non plus le téléchargement, mais l'envoi d'un lien de téléchargement pointant vers l'application personnalisée APP, au le terminal mobile de l'utilisateur Ui, après la génération de cette application personnalisée.
Un tel lien de téléchargement, par exemple une URL, peut être envoyé par l'intermédiaire d'un SMS, d'un email ou d'une connexion locale de type WiFi, Bluetooth ou NFC. Ce mode de réalisation alternatif permet à l'utilisateur de décider du moment du téléchargement proprement dit. La mise à disposition du lien par SMS permet un processus immédiat sans avoir besoin de connaître la disponibilité de l'utilisateur et ne nécessite pas une couverture de réseau, contrairement au téléchargement direct.
Ensuite, dans un mode de réalisation avantageux présentant un niveau de sécurité accrue, une étape A7 d'envoi d'un code PIN d'activation (généré lors de l'étape A4) au terminal mobile est réalisée. Ce code PIN d'activation permet de garantir l'authentification de bout en bout, sans faille initiale, depuis l'inscription au service jusqu'à l'utilisation ultérieure, afin de certifier que seul l'utilisateur Ui a pu effectuer ces opérations.
L'envoi de ce code PIN d'activation peut être conditionné à la vérification, par le serveur d'authentification AS, de l'identité de l'utilisateur lors d'une étape A6 de vérification précédant un tel envoi. Une telle vérification peut consister par exemple en l'envoi au serveur d'authentification AS d'une image de la carte d'identité de l'utilisateur Ui, via une webcam de l'ordinateur de cet utilisateur ou l'appareil photo de son terminal mobile TEL, et la vérification par le serveur AS que les données affichées sur cette image correspondent bien à l'utilisateur Ui.
Ainsi, dans un mode de réalisation avantageux de l'invention, à l'issue de cette étape d'enrôlement, le terminal mobile TEL dispose d'un lien pour télécharger une application personnalisée capable de gérer l'authentification de l'utilisateur Ui ainsi que d'un code PIN d'activation permettant d'activer une telle application personnalisée.
Lorsque les serveurs SP et AS sont distincts, le serveur SP du fournisseur de services stocke les données personnelles de l'utilisateur Ui, qui ne sont connues que de ce serveur SP pour garantir leur confidentialité et, inversement, le serveur AS d'authentification n'a la connaissance que des données d'identifications internes transmises avec la requête du fournisseur de services. Cette séparation des données entre différents serveurs permet de garantir une meilleure résistance aux attaques.
La figure 2B illustre un premier mode de réalisation d'un système mettant en œuvre l'étape A d'enrôlement selon le principe de la présente invention, telle que décrite précédemment.
Un tel système, outre les éléments déjà décrits sur la figure 1 B, comprend en outre un serveur d'authentification AS qui va générer l'application personnalisée et certaines données confidentielles associés à l'utilisateur Ui sur requête reçu du serveur SP du fournisseur de services. Sur cette figure 2B, les différents échanges effectués lors de l'étape d'enrôlement décrite à la figure 2A sont illustré.
En particulier, les flux de données correspondant à la sous-étape d'envoi A1 des données personnelles au serveur SP du fournisseur de services, la sous-étape A3 d'envoi d'une requête en génération de l'application personnalisée au serveur d'authentification AS, la sous-étape A5 d'envoi du lien de téléchargement de l'application personnalisée au terminal mobile et la sous-étape A6 d'envoi du code PIN d'activation de l'application personnalisée au terminal mobile sont indiqués.
Dans ce premier mode de réalisation, le serveur d'authentification AS est distinct du serveur SP du fournisseur de service. Ce mode de réalisation est particulièrement adapté aux applications pour lesquelles le fournisseur de service ne souhaite pas gérer lui-même l'authentification des transactions et préfère déléguer cette fonction à un opérateur tiers.
La figure 2C illustre un deuxième mode de réalisation d'un système mettant en œuvre l'étape A d'enrôlement selon le principe de la présente invention, telle que décrite précédemment.
Un tel système se différencie du système selon le premier mode de réalisation de la figure 2B en ce que le serveur d'authentification AS correspond au serveur SP du fournisseur de service. En d'autres termes, un même serveur est utilisé aussi bien pour effectuer l'authentification que pour fournir un service.
Un tel serveur peut prendre la forme d'un serveur SP apte à fournir un service sur lequel sont installées les fonctionnalités d'authentification nécessaires aux étapes d'authentification décrites dans la présente demande sous forme de modules complémentaires, par exemple sous la forme de modules logiciels complémentaires.
Dans ce mode de réalisation, tous les flux de données correspondant à la sous- étape d'envoi A1 des données personnelles au serveur SP du fournisseur de services, la sous-étape A3 d'envoi d'une requête en génération de l'application personnalisée au serveur d'authentification AS, la sous-étape A5 d'envoi du lien de téléchargement de l'application personnalisée au terminal mobile et la sous-étape A6 d'envoi du code PIN d'activation de l'application personnalisée au terminal mobile transitent donc par un unique serveur (désigné par « SP=AS »).
Ce deuxième mode de réalisation est particulièrement adapté aux applications pour lesquelles le fournisseur de service souhaite gérer lui-même l'authentification des transactions, pour des raisons de sécurisation. Cela peut par exemple être le cas quand le fournisseur de service est un opérateur bancaire permettant des transactions en ligne.
La figure 3A illustre les sous-étapes de l'étape B d'activation de l'application personnalisée selon un mode de réalisation de la présente invention.
Lors d'une première sous-étape B1 , l'utilisateur Ui télécharge l'application personnalisée dans son terminal mobile au moyen du lien de téléchargement qui lui a été envoyé préalablement lors de l'étape A d'enrôlement.
Une fois cette application personnalisée téléchargée dans le terminal mobile TEL, l'activation de l'application personnalisée peut être effectuée ensuite lors d'une sous-étape B2, et ce avantageusement au moyen d'un code PIN reçu préalablement lors de l'étape A d'enrôlement.
Dans un mode de réalisation particulier, des données confidentielles générées lors de l'étape A d'enrôlement sont également téléchargées lors d'une sous-étape B3.
Parmi ces données confidentielles, des données spécifiques permettant l'identification et l'authentification des transactions de l'utilisateur Ui sont téléchargées.
Avantageusement, ces données confidentielles peuvent comprendre également une ou plusieurs clé(s) privée(s) de chiffrement, ces clés étant alors utilisées pour chiffrer les données échangées ensuite entre le serveur AS et le terminal mobile TEL, par exemple au moyen d'un procédé de chiffrement asymétrique.
Ces données confidentielles sont stockées de manière sécurisée aussi bien dans le terminal mobile TEL que dans le serveur AS, par exemple de manière cryptée.
Avantageusement, les données confidentielles stockées dans le serveur d'authentification AS sont stockées dans des boîtiers HSM (pour Hardware Security Module en anglais) permettant d'éviter d'éventuelles compromissions internes chez l'opérateur exploitant le serveur AS. Sur le terminal mobile, les données confidentielles sont cryptées avant d'être stockées dans des espaces sécurisés du terminal mobile.
Une fois l'activation de l'application personnalisée ainsi que l'éventuelle transmission de données confidentielles effectuées, une sous-étape B4 d'enregistrement de l'authentification initiale du terminal mobile est réalisée.
Cette sous-étape B4 d'enregistrement de l'authentification initiale permet de garantir légalement que l'authentification ne puisse pas être remise par la suite, ce qui affaiblirait alors la valeur légale de l'ensemble du procédé d'authentification. Cette étape d'authentification initiale peut être réalisée grâce à l'envoi d'un certain nombre de données d'authentification initiale dinit du terminal mobile de l'utilisateur Ui au serveur d'authentification AS.
Par exemple, l'utilisateur Ui peut être requis de présenter une pièce d'identité à la caméra de son terminal mobile. Le cliché de cette pièce d'identité, pris par cette caméra, est ensuite chiffré et transmis au serveur AS où il est stocké. Un tel processus peut être complètement dématérialisé ou nécessiter l'intervention humaine pour la vérification de l'identité de l'utilisateur Ui.
La figure 3B illustre le système mettant en œuvre l'étape B d'activation de l'application personnalisée selon le principe de la présente invention, telle que décrite précédemment.
Sur cette figure 3B, les différents échanges effectués lors de l'étape d'activation décrite à la figure 3A sont illustrés.
En particulier, les flux de données correspondant à la sous-étape d'envoi B1 de téléchargement de l'application personnalisée dans le terminal mobile TEL, la sous- étape B3 de téléchargement des données confidentielles dans le terminal mobile TEL et la sous-étape B4 d'enregistrement de l'authentification initiale auprès du serveur d'authentification AS sont indiqués.
Le serveur SP du fournisseur de services ainsi que l'ordinateur PC de l'utilisateur Ui ne sont pas concernés par cette étape d'activation.
La figure 4A illustre les sous-étapes d'un deuxième mode de réalisation de type « on-line » de l'étape E de génération du code d'autorisation.
Dans ce deuxième mode de réalisation « on-line », une fois que la donnée d'authentification dauth a été lue par le terminal mobile, elle est transmise au serveur d'authentification AS lors d'une étape E1 de transmission.
Dans un premier mode particulier de réalisation, la donnée d'authentification peut être transmise directement au serveur AS, telle qu'elle est lue par le terminal mobile, ce qui simplifie et accélère le traitement au niveau du terminal mobile. Dans ce premier mode de réalisation, le terminal mobile n'a pour fonction que de lire la donnée d'authentification et tous les autres traitements sont réalisés sur le serveur d'authentification AS.
Dans un deuxième mode particulier de réalisation, la donnée d'authentification peut être interprétée et traitée au moins en partie dans le terminal mobile en vue de son transfert vers le serveur AS. En particulier, lorsqu'une paire de clés privée et publique de chiffrement a été téléchargées à partir de ce serveur d'authentification AS lors de l'étape B d'activation, la donnée d'authentification peut être chiffrée, par exemple avec un procédé de chiffrement asymétrique, avant d'être transmise au serveur AS afin d'empêcher quiconque d'accéder à cette donnée d'authentification.
Dans un troisième mode particulier de réalisation, tout le processus de génération du code d'autorisation peut être effectué dans le terminal mobile, auquel cas le serveur d'authentification AS ne sert qu'à effectuer des fonctions n'ayant pas de rapport avec la génération du code d'autorisation, comme le stockage de ce code ou la gestion de la traçabilité des transactions faites par l'utilisateur.
Une fois effectuée la transmission de la donnée d'authentification dauth au serveur d'authentification AS, il est possible d'effectuer une étape d'identification de l'utilisateur Ui lors d'une étape optionnelle d'identification E2, afin de s'assurer que cette donnée d'authentification dauth est bien transmise par l'intermédiaire de cet utilisateur.
Une sous-étape E3 d'authentification de la transaction requise par l'utilisateur peut ensuite être réalisée.
Le code d'autorisation cod, proprement dit est alors généré dans le serveur d'authentification AS au cours d'une étape E4 de génération.
Une fois ce code d'autorisation généré, celui-ci est transmis (étape E5 de transmission du code) du serveur d'authentification AS au terminal mobile TEL, éventuellement sous une forme chiffrée grâce à une ou plusieurs clé(s) générée(s) durant l'étape B d'activation de l'application personnalisée, pour y être affiché, éventuellement après avoir été signé au moyen d'un code secret (voire également d'une donnée d'identification du terminal mobile) avant d'être encodé sous forme d'image.
La valeur du code d'autorisation générée permet de certifier que la donnée d'authentification a bien été comprise et sert à authentifier l'utilisateur.
Dans ce deuxième mode de réalisation de type « on-line » du procédé d'authentification, une fois le code d'autorisation lu par le dispositif numérique de l'utilisateur Ui (étape F) et une fois les données transactionnelles transmises, avec le code d'autorisation saisi, de l'ordinateur personnel vers le serveur du fournisseur de services (étape G), il est avantageux d'effectuer, après la transaction proprement dite, une étape d'horodatage de la transaction afin de conserver une preuve de l'heure et la date à laquelle a été effectuée la transaction. Dans le cas du mode de réalisation « on-line », un tel horodatage peut être effectué par le serveur d'authentification AS, dans une logique de traçabilité de la transaction.
La figure 4B illustre le système mettant en œuvre le procédé d'authentification selon un premier mode de réalisation de type « on-line » où le code d'autorisation est généré dans un serveur d'authentification AS distinct du serveur du fournisseur de services.
En particulier, les flux de données correspondant aux étapes d'enrôlement (étape A), d'envoi d'une donnée d'authentification (étape C), de lecture de cette donnée d'authentification (étape D), de saisie du code d'autorisation par l'ordinateur de l'utilisateur (étape E) et de transmission de la transaction au serveur du fournisseur de services (étape G) sont similaires à ceux décrits dans le mode de réalisation « off-line » et illustrés sur la figure 1 B.
Ce premier mode de réalisation « on-line » se caractérise en ce que le terminal mobile transfère la donnée d'authentification au serveur d'authentification AS lors de la sous-étape E1 , les différentes sous-étapes d'identification de l'utilisateur, d'authentification de la transaction et de génération du code d'autorisation cod, (sous- étapes E2 à E4) étant alors réalisées dans ce serveur d'authentification AS avant que le code d'autorisation cod, soit transmis au terminal mobile lors de la sous-étape de transmission E5.
Dans ce mode de réalisation particulier, une fois la transaction réalisée, elle peut être horodatée par le serveur SP du fournisseur de services, afin de servir de preuve à la disposition du fournisseur de services s'il y a lieu. L'historique des transactions horodatées est ainsi conservé au sein du serveur SP du fournisseur de services.
La figure 4C illustre le système mettant en œuvre le procédé d'authentification selon un deuxième mode de réalisation de type « on-line » où le code d'autorisation est généré dans le serveur SP du fournisseur de services sur lequel les fonctionnalités d'authentification décrites précédemment ont été installées.
Sur cette figure 4C, les différents flux de données décrits sont similaires que ceux décrits en référence à la figure 4B, à la seule différence près que le serveur d'authentification AS et le serveur SP du fournisseur de services forment une seule et même entité gérée par le fournisseur de services. Ce mode de réalisation est particulièrement adapté aux applications demandant un niveau de sécurisation accru, et en particulier au domaine bancaire où des critères stricts de confidentialité des données s'appliquent, notamment au niveau des échanges de données entre le module de transaction et le module d'authentification.
Dans ce mode de réalisation particulier, une fois réalisée, cette transaction peut être horodatée aussi bien par le module d'authentification que par le serveur SP proprement dit, afin de servir de preuve à la disposition du fournisseur de services s'il y a lieu. L'historique des transactions horodatées est ainsi conservé au sein du serveur SP du fournisseur de services.
Le serveur SP peut également conserver en mémoire d'autres données de traçabilité comme le contenu de la transaction ou l'identifiant de l'utilisateur.
Le procédé d'authentification décrit ci-avant permet de résister à la plupart, voire à toutes, des attaques connues et répertoriées dans un contexte de transaction d'authentification et/ou de signature sur internet, et qui visent à compromettre l'établissement d'une communication entre un client et un serveur et/ou en altérer le fonctionnement, dont la liste est donnée ci-dessous :
Attaque de type « Malware »
Il s'agit d'un nom générique pour les virus informatiques, les chevaux de Troyes, les logiciels espions, les keyloggers, etc .. Les logiciels malveillants sont des applications utilisées à des fins frauduleuses. Ils peuvent accéder à un ordinateur par des vulnérabilités de sa protection par l'ingénierie sociale. Quand le logiciel malveillant est en cours d'exécution, il peut généralement prendre le contrôle complet de l'ordinateur et par exemple dérober les informations et les données personnelles de l'utilisateur, activer le contrôle à distance de l'ordinateur ou exécuter des actions au nom de l'utilisateur.
Avec la présente invention, les seules données personnelles sensibles sont stockées en espace sécurisé, auprès du serveur du fournisseur de services, elles sont hors de portée des malwares.
Par ailleurs, la copie de l'application personnalisée sur un autre terminal mobile que celui de l'utilisateur Ui est inutile sans les données confidentielles générées par le serveur AS. De même, la copie des données confidentielles sur un autre terminal mobile rend ces données confidentielles non interprétables. Attaque de type « Keyloqqinq »
Les attaques de type « Keylogging » sont réalisées à l'aide de programmes parasites appelés « keyloggers » qui se propagent souvent grâce à des virus, des vers ou des spywares. Un « keylogger » a pour principale fonction d'espionner toutes les actions effectuées sur l'ordinateur de l'utilisateur (saisie au clavier, ouverture d'applications, déplacement de fichiers...). Les traces de ces actions sont stockées dans un emplacement précis, puis envoyées vers une boîte aux lettres ou sur un site web. Certaines des données les plus confidentielles peuvent ainsi être soutirées à l'insu de l'utilisateur.
Certains « keyloggers » sont excessivement perfectionnés et sont en mesure de sélectionner les informations les plus importantes. Ils parviennent, lorsque l'utilisateur est sur son site de banque en ligne par exemple, à identifier et récupérer ses codes bancaires. Ils peuvent aussi connaître le contenu saisi dans ses messages ou savoir précisément quels sont les programmes sollicités par l'utilisateur.
Avec la présente invention, encore une fois, les données personnelles de l'utilisateur Ui ne sont ni stockées ni utilisées par l'application personnalisée et les données permettant l'authentification de celui-ci sont à usage unique. Le « Keylogging » est donc inefficace.
Attaque de type « Phishinq »
Lors d'une attaque de type « Phishing », autrement appelée hameçonnage, l'attaquant utilise un e-mail ou une messagerie instantanée pour mener l'utilisateur à un site web paraissant digne de confiance mais qui est en réalité une copie conforme du site original et sous son contrôle. Le message e-mail comme le site web pouvant être par exemple une réplique exacte d'un site de banque en ligne couramment visité par l'utilisateur. Celui-ci croit alors qu'il est sur un site digne de confiance (par exemple, celui de sa banque) et saisit ses données personnelles d'identification telles que sont mot de passe, un mot de passe à usage unique, voire son numéro de carte bancaire.
L'attaquant peut ensuite utiliser ses informations pour accéder au compte de l'utilisateur ou effectuer des transactions frauduleuses à son insu (par exemple un virement bancaire ou un paiement en ligne s'il y a récupération du numéro de carte bancaire). Avec la présente invention, une attaque de type « phishing » permet éventuellement de connaître la réponse unique à une donnée d'authentification donnée. Cependant, une telle réponse ne pourrait pas être réutilisée puisque la donnée d'authentification transmise par le fournisseur de services est générée et change à chaque fois.
Par ailleurs, en mode de sécurité renforcée, la donnée d'authentification permet une authentification mutuelle, ce qui entraîne le dévoilement du site de « fishing ».
Attaque de type « Pharminq » ou « Whalinq »
Ces sous-catégories d'attaques de type « phishing » (hameçonnage) permet de voler des informations après avoir attiré la victime sur un site web maquillé, même si le nom de domaine est correctement saisi.
Une attaque de type « pharming » (ou dévoiement en français) est une technique de piratage informatique exploitant des vulnérabilités au niveau du serveur DNS. Cette technique opère de manière à ce que, pour une requête DNS visant un nom de domaine particulier, ce ne soit pas la véritable adresse IP du nom de domaine qui soit donnée mais celle d'un site frauduleux.
Il existe deux types d'attaques de type « pharming ».
Le premier est type est réalisé par la modification d'un server DNS local. Les internautes demandant un nom de domaine se font diriger vers l'adresse IP d'un serveur frauduleux.
Le second type est réalisé au moyen d'un malware reconfigurant les paramètres réseaux du matériel informatique infecté, que ce soit un poste de travail ou un routeur. Cette reconfiguration agit de manière à ce que l'internaute soit redirigé, pour des noms de domaines prédéterminés, vers l'adresse IP d'un serveur frauduleux.
Quant au « whaling », il s'agit d'une autre sous-catégorie d'attaque de type « phishing » (hameçonnage) ciblée sur des individus de haut niveau, pouvant être des cadres d'une entreprise ou des individus haut placés dans la hiérarchie d'un réseau dans l'attaque d'institutions financières. L'attaque visant un seul individu, est elle plus personnalisée et devient par conséquent plus convaincante mais aussi plus difficile à détecter.
Avec la présente invention, tout comme pour les attaque de type « phishing », des attaques de type « pharming » ou « whaling » permettent éventuellement de connaître la réponse unique à une donnée d'authentification donnée. Cependant, une telle réponse ne pourrait pas être réutilisée puisque la donnée d'authentification transmise par le fournisseur de services est générée et change à chaque fois.
Attaque de type "Man-in-the-Middle (MiTM)"
L'attaque de type « man in the middle » (littéralement « attaque de l'homme au milieu » ou « attaque de l'intercepteur » en français), parfois notée MiTM, est un scénario d'attaque dans lequel un pirate (l'attaquant) écoute une communication entre deux interlocuteurs et falsifie les échanges entre le client et l'hôte afin de se faire passer pour l'une des parties.
Cette attaque fait donc intervenir trois protagonistes : le client, le serveur et l'attaquant. Le but de l'attaquant est de se faire passer pour le client auprès du serveur et se faire passer pour le serveur auprès du client. Il devient ainsi l'homme du milieu. Cela permet de surveiller tout le trafic réseau entre le client et le serveur, et de le modifier à sa guise pour l'obtention d'informations telles que des mots de passe, un accès système, etc.
La plupart du temps, de telles attaques reposent sur l'utilisation les techniques de détournement de flux qui consistent à écouter le réseau à l'aide d'outils appelés « sniffer ».
Avec la présente invention, entre l'utilisateur Ui et le serveur d'authentification AS, toutes les transactions sont chiffrées, rendant inopérante une interception de type MiTM.
Une attaque de type MiTM entre l'utilisateur Ui et le serveur SP du fournisseur de services peut permettre d'intercepter le code d'autorisation, mais celui-ci est à usage unique donc non réutilisable
Une attaque de type « Man in the Middle » est donc sans effet avec la présente invention.
Man-in-the-Browser (MiTB)
Des outils, ainsi que la vigilance des utilisateurs, permettent désormais d'identifier les faux sites de type « Man-in-the-Middle », puisque leur adresse peut être incorrecte. Tandis que certains sont cryptés, l'inspection attentive de la certification de site Web peut prouver que le site n'appartient pas vraiment à qui il prétend. En outre, alors que les fraudeurs peuvent essayer de se relier au site Web (cible de l'attaque) à partir d'un ordinateur dans le même pays que le client, les systèmes de détection de fraude pourraient relever des caractéristiques soupçonneuses.
Pour ces raisons, les fraudeurs ont maintenant développé une variante plus sophistiquée de MitM - l'attaque de type « man in the browser » ou MitB.
Dans cette variante, au lieu d'intervenir entre l'ordinateur du client et le site Web de la banque, les interceptions de MitB agissent entre le client et son navigateur.
Une attaque de MitB est conçue en installant un logiciel malveillant (i.e. un malware) sur l'ordinateur du client. L'objectif est de permettre à l'attaquant de contrôler toutes les applications et tous les appareils non sécurisés connectés à l'ordinateur de l'utilisateur.
Ceci peut se produire lorsqu'un client ouvre un attachement d'email ou télécharge un dossier d'un site Web. Visiter un site Web, ou lire un email, peut être suffisant pour qu'un fraudeur puisse installer le malware sans permission du client. Dans certains cas les cybers criminels ont trifouillé des sites Web légitimes existants, de sorte qu'ils infectent leurs visiteurs. Le client est peu susceptible de noter que quelque chose est différent.
Les technologies d'authentification forte classiques, tels que l'e-Banking par exemple, ne peuvent pas protéger contre une attaque de type « Man-in-the-Browser ». En effet, qu'il s'agisse de "tokens" classique de type OTP (Securid, Vasco, Aladdin, etc.) ou la technologie PKI (Certificat numérique) utilisée sur des supports comme une SmartCard, un Token USB (eToken, etc.), ces technologies n'offrent pas un niveau de sécurité suffisant pour prévenir les attaques de type « Man in the Browser ».
Avec la présente invention, tout comme pour les attaques MiTM, toutes les transactions sont chiffrées entre l'utilisateur Ui et le serveur d'authentification AS, ce qui rend inopérante une interception de type MiTB. Par ailleurs, une attaque de type MiTB entre l'utilisateur Ui et le serveur SP du fournisseur de services peut certes permettre d'intercepter le code d'autorisation, mais celui-ci est à usage unique donc non réutilisable
Une attaque de type « Man in the Browser » est donc sans effet avec la présente invention.
Attaque de type « ID Theft »
Dans ce type d'attaque, l'attaquant prétend être quelqu'un d'autre pour accéder par exemple à un système ou effectuer des transactions financières frauduleuses. Cette technique repose donc sur le principe de l'usurpation d'identité. Celle-ci débute toujours par la collecte de renseignements personnels sur l'individu fraudé. Les renseignements personnels peuvent être le nom, le numéro de téléphone, la date de naissance, l'adresse, le numéro d'assurance sociale, le numéro de carte de crédit, le mot de passe de carte de crédit ou de débit ou toute autre information permettant d'identifier la personne.
A cet effet, la prolifération des réseaux sociaux tels que FaceBook, MySpace, Linked-in, Twitter, Xing, Viadeo, etc., et leur utilisation massive rend facile cette collecte des informations mais aussi problématique leur sécurisation.
Les usurpateurs utilisent ensuite ces informations pour effectuer une ou des transactions en simulant l'identité de la personne fraudée. Par exemple, un fraudeur peut effectuer des appels téléphoniques ou faire des achats importants et diriger les frais vers la personne fraudée, il peut aussi retirer de l'argent du compte de banque de cette personne.
Avec la présente invention, les données personnelles de l'utilisateur ne sont pas utilisées lors du processus d'authentification. Une attaque de type « ID Theft » est donc inopérante.
Attaque de type « Social Engineering »
Ce type d'attaque n'est autre que le fait de faire réaliser à une personne une action dont elle n'aurait pas pris l'initiative seule. Le « social engineering » est une technique qui fonctionne, car elle fait appel à des caractéristiques humaines telles l'entraide ou la confiance. Pour arriver à ses fins, l'attaquant soulève différents leviers d'attaque tels que :
- L'amitié et la coopération : l'empathie, la sympathie, la détresse, la culpabilité. Il faut pour cela connaître le contexte de la cible, ainsi que certains aspects personnels du sujet. Cette méthode est relativement discrète mais nécessite souvent plusieurs tentatives.
- L'usurpation d'identité et l'intimidation : pouvoir et soumission, diffusion de responsabilités. Cette méthode est un peu plus risquée que la précédente. Il faut disposer d'un annuaire bien renseigné sur la société, de son organigramme. Cette méthode est plus rapide puisque dans la mesure où cette méthode est agressive, un seul essai est possible. - Le sabotage : vise les administrateurs. Il s'agit de se faire connaître comme l'interlocuteur adéquat en cas de problème du SI. L'attaquant profite alors de la confiance instaurée. Cette méthode est peu discrète mais efficace.
- Diverses techniques associées : le « trash recovering » qui n'est autre que de la récupération de poubelles, le « shoulder surfing », qui pourrait se traduire par de la navigation au-dessus de l'épaule de la cible.
Le seul moyen de lutte reste ici la sensibilisation des utilisateurs. Elle est coûteuse en temps et en ressources mais peut cependant se réaliser. La meilleure parade consiste à retirer l'information à l'utilisateur, la classifier et la chiffrer à travers un système d'authentification physique et/ou logique (token, biométrie, code 2D).
Avec la présente invention, tout comme pour une attaque de type « ID Theft », une attaque de type « Social engineering » est inopérante car les données personnelles de l'utilisateur ne sont pas utilisées lors du processus d'authentification.
Attaque de type « Cross-Channel »
Dans ces attaques, une brèche ouverte dans la sécurité d'un canal est utilisée pour accéder à d'autres canaux. Les contraintes de sécurité différentes d'un canal à un autre expliquent qu'il est plus facile d'attaquer un canal et de procéder à la fraude sur un autre.
Par exemple, l'attaquant pourrait utiliser des données personnelles obtenues sur le canal de commerce en ligne pour se connecter à la banque en ligne. Dès lors, il devient nécessaire de procéder à une séparation des domaines pour se prémunir contre ce type d'attaque.
Avec la présente invention, les données confidentielles sont spécifiques au fournisseur de service, ce qui réduit drastiquement les possibilités d'attaque de type « cross-channel ».
En cas de faiblesse due à une trop forte mutualisation de services dans un groupe de fournisseurs donné, une attaque de type « cross-channel » reste sans effet, car elle ne permet d'intercepter que des données confidentielles à usage unique, donc non réutilisables.
Attaque de type « Card-Not-Present » Dans des environnements où une carte est requise (par exemple, une carte de paiement), cette attaque consiste en une transaction pendant laquelle la carte n'est pas présente sur le site du commerçant. Ceci comprend les commandes dite sur internet, le téléphone et le courrier électronique, plus communément appelées MoTo (Mail Order / Téléphone Order).
Contrairement à une transaction où la carte est présente et généralement assortie de la saisie d'un code personnel (Code PIN) dont l'utilisateur à seule la connaissance, la carte n'étant pas présente, le marchand ne peut pas vérifier que la transaction est réellement effectuée par le propriétaire de la carte. En effet un attaquant peut copier les informations de la carte auprès de son propriétaire et les utiliser ensuite pour procéder à des transactions de type « card-not-present ».Avec la présente invention dans le mode de réalisation « on-line », l'identification de l'utilisateur, l'authentification de la transaction et l'horodatage sont réalisés. L'ensemble de ces éléments est dont traçable. L'utilisation de réglementations éventuelles pour une répudiation technique ne permet que la répudiation du moyen et non de l'acte et permet un recours judiciaire indiscutable.
La présente invention concerne aussi un serveur d'authentification AS comprenant un module de réception arrangé pour recevoir la donnée d'authentification dauth ainsi qu'au moins une donnée interne d'identification dint provenant du serveur SP du fournisseur de service, des moyens de calcul arrangés pour générer un code d'autorisation cod, en fonction de la donnée d'authentification reçue et d'au moins une des donnée internes d'identification reçues, ainsi qu'un module d'émission arrangé pour émettre le code d'autorisation cod, généré vers le terminal mobile TEL.
Un tel serveur d'authentification AS peut être utilisé dans le mode de réalisation « on-line » tel que décrit à la figure 4B, dans lequel la fonctionnalité d'authentification de la transaction, au moyen de la donnée d'authentification dauth, est effectuée dans un serveur distinct du fournisseur de service.
La présente invention concerne également un système d'authentification d'un utilisateur requérant une transaction auprès d'un fournisseur de service comprenant un écran SCN arrangé pour afficher une donnée d'authentification reçue du fournisseur de service, un terminal mobile TEL disposant de moyens de saisie de la donnée d'authentification affichée sur l'écran et arrangé pour retourner un code d'autorisation spécifique à l'utilisateur et à la transaction requise, et des moyens de saisie PC permettant l'envoi du code d'autorisation au fournisseur de service afin d'authentifier l'utilisateur. Ce système est par exemple décrit à la figure 1 B. Dans un mode particulier de réalisation, ce système implique un serveur d'authentification tel que décrit précédemment.
Dans un autre mode particulier de réalisation, le système comprend en outre le serveur SP du fournisseur de service, ce serveur étant arrangé pour fournir le service requis par l'utilisateur, et comprenant un module de réception arrangé pour recevoir au moins une donnée personnelle de l'utilisateur et le code d'autorisation émis par l'utilisateur, des moyens de calcul arrangé pour générer au moins une donnée interne d'identification à partir d'au moins une des données personnelles reçues, et un module d'émission arrangé pour envoyer la donnée interne d'identification générée au serveur d'authentification AS.
Un tel serveur SP de fourniture de service peut être utilisé dans le mode de réalisation « on-line » tel que décrit à la figure 4B, dans lequel la fonctionnalité de fourniture de service est effectuée dans un serveur distinct de celui effectuant l'authentification de la transaction.
Bien entendu, l'invention n'est pas limitée aux exemples de réalisation ci- dessus décrits et représentés, à partir desquels on pourra prévoir d'autres modes et d'autres formes de réalisation, sans pour autant sortir du cadre de l'invention.
Ainsi, toutes ou partie des étapes mises en œuvre par le terminal mobile TEL sont effectuées dans un mode de réalisation suite à l'exécution d'instructions de programmes d'ordinateur sur des moyens de calcul du terminal mobile TEL. Similairement, tout ou partie des étapes mises en œuvre par le serveur d'authentification AS sont effectuées dans un mode de réalisation suite à l'exécution d'instructions de programmes d'ordinateur sur des moyens de calcul de ce serveur AS.
Par ailleurs, le terme de fournisseur de services utilisé précédemment recouvre tout opérateur apte à fournir un service dans lequel une transaction est effectuée. Un tel fournisseur peut être par exemple, à titre purement illustratif, un opérateur bancaire, un opérateur de jeux en ligne, un opérateur de télécommunications, un loueur de véhicules ou de vélos, etc.

Claims

REVENDICATIONS
1 . Procédé d'authentification d'un utilisateur (Ui) requérant une transaction auprès d'un fournisseur de service (SP), le procédé comportant :
la génération (E) d'un code d'autorisation (codi) spécifique à l'utilisateur et à la transaction requise à partir d'une donnée d'authentification (dauth) lue sur un écran au moyen d'un terminal mobile (TEL) ; la lecture (F) du code d'autorisation, affiché par le terminal mobile, par des moyens de lecture d'un dispositif numérique (PC) ; et
l'envoi (G) par ledit dispositif numérique vers le fournisseur de service du code d'autorisation lu afin d'authentifier l'utilisateur.
2. Procédé d'authentification selon la revendication 1 , caractérisé en ce que le code d'autorisation (cod,) est généré en signant la donnée d'authentification (dauth) au moyen d'un code secret saisi par l'utilisateur sur le terminal mobile.
3. Procédé d'authentification selon la revendication 2, caractérisé en ce que le code d'autorisation (cod,) est généré en signant la donnée d'authentification (dauth) en outre au moyen d'une donnée d'identification du terminal mobile.
4. Procédé d'authentification selon l'une des revendications 1 à 3, caractérisé en ce que le code d'autorisation (cod,) généré est encodé sous la forme d'une image, en particulier un code-barres en deux dimensions, avant d'être affiché par le terminal mobile.
5. Procédé d'authentification selon l'une des revendications 1 à 4, caractérisé en ce que la lecture (F) du code d'autorisation est effectuée au moyen d'une technologie de communication sans-fil de type communication en champ proche.
6. Procédé d'authentification selon l'une des revendications 1 à 5, caractérisé par la transmission (E1 ) de la donnée d'authentification lue du terminal mobile au serveur d'authentification (AS), la génération (E4) du code d'autorisation à partir de la donnée d'authentification dans le serveur d'authentification (AS), et la transmission (E5) du code d'autorisation généré au terminal mobile.
7. Procédé d'authentification selon l'une des revendications 1 à 6, caractérisé en ce que la donnée d'authentification lue est interprétée dans le terminal mobile au moyen d'une application personnalisée (APP,) spécifique à l'utilisateur et téléchargée (B1 ) à partir d'un serveur d'authentification (AS), ladite application personnalisée (APP,) générant (E) le code d'autorisation à partir de la donnée d'authentification lue.
8. Procédé d'authentification selon la revendication 7, caractérisé en ce qu'il comprend en outre une étape préalable d'enrôlement (A), au cours de laquelle un code d'activation (PIN) est transmis (A7) au terminal mobile, suivie d'une étape d'activation (B) au cours de laquelle l'application personnalisée est téléchargée (B1 ) dans le terminal mobile, ledit code d'activation étant utilisé lors de l'étape d'activation pour activer (B2) l'application personnalisée téléchargée.
9. Procédé d'authentification selon la revendication 8, caractérisé en ce que l'étape d'enrôlement (A) comprend une étape de vérification (A6) de l'identité de l'utilisateur avant la transmission du code d'activation, ladite transmission n'étant effectuée que si ladite vérification est effectuée de façon positive.
10. Procédé d'authentification selon l'une des revendications 8 ou 9, caractérisé en ce que l'étape d'activation (B) comprend la transmission (B3) d'au moins une donnée confidentielle (sert,) spécifique à l'utilisateur du terminal mobile, ladite donnée confidentielle servant à chiffrer la donnée d'authentification dans le terminal mobile avant sa transmission au serveur d'authentification et/ou à déchiffrer le code d'autorisation reçu par le terminal mobile.
1 1 . Procédé d'authentification selon l'une des revendications 8 à 10, caractérisé par la génération (A4), au cours de l'étape préalable d'enrôlement (A), de l'application personnalisée (APP,) et/ou de la donnée confidentielle (serti) en fonction d'au moins une donnée interne d'identification (dint) générée à partir d'au moins une donnée personnelle d'identification (did) envoyée par l'utilisateur au fournisseur de service.
12. Procédé d'authentification selon l'une des revendications 1 à 1 1 , caractérisé en ce que la donnée d'authentification (dauth) est générée par le fournisseur de service en fonction de données liées à la transaction et de données personnelles reçues de l'utilisateur.
13. Serveur d'authentification (AS) comprenant un module de réception arrangé pour recevoir une donnée d'authentification (dauth) transmise par un terminal mobile (TEL) et au moins une donnée interne d'identification (dint) transmise par un serveur (SP) d'un fournisseur de services, des moyens de calcul arrangés pour générer un code d'autorisation (cod,) en fonction de la donnée d'authentification reçue et d'au moins une des donnée internes d'identification reçues, et un module d'émission arrangé pour émettre le code d'autorisation généré vers le terminal mobile.
14. Système d'authentification d'un utilisateur (Ui) requérant une transaction auprès d'un fournisseur de service, le système comprenant :
un écran (SCN) arrangé pour afficher une donnée d'authentification (dauth) reçue du fournisseur de service ;
un terminal mobile (TEL) comprenant des moyens de saisie de la donnée d'authentification affichée sur l'écran et des moyens d'affichages arrangés pour afficher un code d'autorisation (cod,) spécifique à l'utilisateur et à la transaction requise ; et
un dispositif numérique (PC) comprenant des moyens de lecture aptes à lire le code d'autorisation affiché par le terminal mobile et adapté pour envoyer ledit code d'autorisation au fournisseur de service afin d'authentifier l'utilisateur.
15. Système d'authentification selon la revendication 14, caractérisé en ce qu'il comprend en outre un serveur d'authentification (AS) selon la revendication 13.
16. Système d'authentification selon la revendication 15, caractérisé en ce qu'il comprend un serveur de service (SP), utilisé par le fournisseur de service pour fournir un service requis par l'utilisateur, ledit serveur de service comprenant un module de réception arrangé pour recevoir au moins une donnée personnelle de l'utilisateur et le code d'autorisation émis par l'utilisateur, des moyens de calcul arrangés pour générer au moins une donnée interne d'identification à partir d'au moins une des données personnelles reçues, et un module d'émission arrangé pour envoyer la donnée interne d'identification générée au serveur d'authentification (AS) .
PCT/FR2011/051008 2010-05-06 2011-05-04 Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service WO2011138558A2 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP11723560A EP2567502A2 (fr) 2010-05-06 2011-05-04 Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
US13/696,489 US9038196B2 (en) 2010-05-06 2011-05-04 Method for authenticating a user requesting a transaction with a service provider
RU2012152466/08A RU2012152466A (ru) 2010-05-06 2011-05-04 Способ аутентификации пользователя, запрашивающего транзакцию у провайдера услуги
CN2011800341284A CN103109494A (zh) 2010-05-06 2011-05-04 用于授权需要服务提供商交易的用户方法
SG2012081857A SG185449A1 (en) 2010-05-06 2011-05-04 Method for authenticating a user requesting a transaction with a service provider

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1053523A FR2959896B1 (fr) 2010-05-06 2010-05-06 Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
FR1053523 2010-05-06

Publications (2)

Publication Number Publication Date
WO2011138558A2 true WO2011138558A2 (fr) 2011-11-10
WO2011138558A3 WO2011138558A3 (fr) 2012-07-12

Family

ID=43533165

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2011/051008 WO2011138558A2 (fr) 2010-05-06 2011-05-04 Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service

Country Status (7)

Country Link
US (1) US9038196B2 (fr)
EP (1) EP2567502A2 (fr)
CN (1) CN103109494A (fr)
FR (1) FR2959896B1 (fr)
RU (1) RU2012152466A (fr)
SG (1) SG185449A1 (fr)
WO (1) WO2011138558A2 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2495571A (en) * 2011-10-03 2013-04-17 Barclays Bank Plc Mobile device user authentication at a physical location using machine accessible codes or within a telephone call or messaging session
FR2996187A1 (fr) * 2012-10-02 2014-04-04 Renault Sa Systeme de gestion d'un vehicule et son procede associe
EP2792174A4 (fr) * 2011-12-16 2015-07-08 Intel Corp Connexion par communication en champ proche avec informations de connexion générées automatiquement
EP2998896A1 (fr) * 2014-09-17 2016-03-23 Gemalto Sa Procédé d'authentification d'un utilisateur, terminaux et système d'authentification correspondants
EP2619941B1 (fr) * 2011-08-05 2018-12-12 Oney Bank Procede, serveur et systeme d'authentification d'une personne
US10313126B2 (en) * 2015-06-10 2019-06-04 Feitian Technologies Co., Ltd. Barcode security authentication method
CN114898510A (zh) * 2022-05-11 2022-08-12 中国矿业大学 一种金融密码获取方法、***、金融设备及可存储介质

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8806592B2 (en) 2011-01-21 2014-08-12 Authentify, Inc. Method for secure user and transaction authentication and risk management
US10581834B2 (en) * 2009-11-02 2020-03-03 Early Warning Services, Llc Enhancing transaction authentication with privacy and security enhanced internet geolocation and proximity
US10587683B1 (en) 2012-11-05 2020-03-10 Early Warning Services, Llc Proximity in privacy and security enhanced internet geolocation
US9667823B2 (en) * 2011-05-12 2017-05-30 Moon J. Kim Time-varying barcode in an active display
US8869279B2 (en) 2011-05-13 2014-10-21 Imperva, Inc. Detecting web browser based attacks using browser response comparison tests launched from a remote source
US9106633B2 (en) * 2011-05-26 2015-08-11 First Data Corporation Systems and methods for authenticating mobile device communications
KR101137523B1 (ko) * 2011-09-26 2012-04-20 유승훈 인증매체, 인증단말, 인증서버 및 이들을 이용한 인증방법
US9210146B2 (en) * 2012-02-18 2015-12-08 Daniel S. Shimshoni Secure content transfer using dynamically generated optical machine readable codes
CN103379491A (zh) * 2012-04-12 2013-10-30 中兴通讯股份有限公司 用于密码验证的用户终端、密码交易终端、***和方法
CN104063789B (zh) * 2013-03-18 2016-04-20 财付通支付科技有限公司 一种对处理对象进行处理的方法、装置及***
TWI505128B (zh) * 2013-03-20 2015-10-21 Chunghwa Telecom Co Ltd Method and System of Intelligent Component Library Management
FR3007167A1 (fr) * 2013-06-14 2014-12-19 France Telecom Procede d'authentification d'un terminal par une passerelle d'un reseau interne protege par une entite de securisation des acces
WO2015015366A1 (fr) * 2013-07-28 2015-02-05 Eli Talmor Transaction et accès sécurisés au moyen d'un dispositif non sécurisé
US20150040203A1 (en) * 2013-08-01 2015-02-05 Huawei Technologies Co., Ltd. Authentication method of wearable device and wearable device
US9160742B1 (en) * 2013-09-27 2015-10-13 Emc Corporation Localized risk analytics for user authentication
US9734694B2 (en) * 2013-10-04 2017-08-15 Sol Mingso Li Systems and methods for programming, controlling and monitoring wireless networks
JP6170844B2 (ja) * 2014-02-14 2017-07-26 株式会社Ｎｔｔドコモ 認証情報管理システム
US10057240B2 (en) * 2014-08-25 2018-08-21 Sap Se Single sign-on to web applications from mobile devices
DE102014015814B4 (de) 2014-10-24 2016-05-04 Unify Gmbh & Co. Kg Verfahren zum Authentifizieren eines Benutzergeräts bei der Anmeldung an einem Server
CN104361267B (zh) * 2014-11-19 2017-11-07 厦门海迈科技股份有限公司 基于非对称加密算法的软件授权与保护装置及方法
US9619636B2 (en) 2015-02-06 2017-04-11 Qualcomm Incorporated Apparatuses and methods for secure display on secondary display device
US11526885B2 (en) * 2015-03-04 2022-12-13 Trusona, Inc. Systems and methods for user identification using graphical barcode and payment card authentication read data
SG11201708726PA (en) * 2015-03-26 2017-11-29 Einnovations Holdings Pte Ltd System and method for facilitating remittance
US9614845B2 (en) 2015-04-15 2017-04-04 Early Warning Services, Llc Anonymous authentication and remote wireless token access
FR3039948B1 (fr) * 2015-08-04 2017-08-11 Skeyecode Procede de securisation d’une transaction a partir d’un terminal non securise
TWI603222B (zh) * 2015-08-06 2017-10-21 Chunghwa Telecom Co Ltd Trusted service opening method, system, device and computer program product on the internet
US9602284B1 (en) * 2015-09-11 2017-03-21 Bank Of America Corporation Secure offline authentication
US10084782B2 (en) 2015-09-21 2018-09-25 Early Warning Services, Llc Authenticator centralization and protection
US9800580B2 (en) * 2015-11-16 2017-10-24 Mastercard International Incorporated Systems and methods for authenticating an online user using a secure authorization server
WO2017143078A1 (fr) * 2016-02-16 2017-08-24 Arizona Board Of Regents On Behalf Of Northern Arizona University Authentification d'image extraites d'objets non clonables
US10091007B2 (en) * 2016-04-04 2018-10-02 Mastercard International Incorporated Systems and methods for device to device authentication
US10771451B2 (en) 2016-09-13 2020-09-08 Queralt, Inc. Mobile authentication and registration for digital certificates
US11431509B2 (en) 2016-09-13 2022-08-30 Queralt, Inc. Bridging digital identity validation and verification with the FIDO authentication framework
US10887113B2 (en) 2016-09-13 2021-01-05 Queralt, Inc. Mobile authentication interoperability for digital certificates
US11093940B2 (en) 2016-10-13 2021-08-17 Mastercard International Incorporated Systems and methods for authenticating a user using private network credentials
FR3060818A1 (fr) * 2016-12-19 2018-06-22 Orange Securisation de transaction
US11233634B1 (en) 2017-06-23 2022-01-25 Wells Fargo Bank, N.A. Systems and methods for network authentication with a shared secret
SE542213C2 (en) 2017-07-21 2020-03-10 Identitrade Ab Method and system for creating a strong authentication for a user using a portable electronic device
NL2019698B1 (en) * 2017-10-10 2019-04-19 Morpho Bv Authentication of a person using a virtual identity card
US11844144B2 (en) * 2017-10-27 2023-12-12 Telefonaktiebolaget Lm Ericsson (Publ) Customized PIN/PUK remote provisioning
US20210204116A1 (en) 2019-12-31 2021-07-01 Payfone, Inc. Identity verification platform
CN111597539B (zh) * 2020-04-23 2023-04-25 维沃移动通信有限公司 一种身份认证方法、身份认证装置及电子设备
US11461754B2 (en) * 2020-08-26 2022-10-04 Ncr Corporation Isolated POS terminal connectivity

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1253564A3 (fr) * 2000-04-19 2002-12-11 Magicaxess Procédé et dispositif de paiement électronique
US7114178B2 (en) * 2001-05-22 2006-09-26 Ericsson Inc. Security system
FR2852471A1 (fr) * 2003-03-13 2004-09-17 France Telecom Dispositif d'authentification du type utilisant un mot de passe a usage unique et dispositif generateur de mot de passe associe
US7578436B1 (en) * 2004-11-08 2009-08-25 Pisafe, Inc. Method and apparatus for providing secure document distribution
US20090293112A1 (en) 2004-12-03 2009-11-26 Stephen James Moore On-line generation and authentication of items
JP4693171B2 (ja) * 2006-03-17 2011-06-01 株式会社日立ソリューションズ 認証システム
US8024576B2 (en) * 2008-03-31 2011-09-20 International Business Machines Corporation Method and system for authenticating users with a one time password using an image reader
WO2009134213A2 (fr) * 2008-05-02 2009-11-05 Radiantrust Pte Ltd Procédé et système pour une authentification à l'écran à l'aide d'un message visuel secret
CN101436280B (zh) 2008-12-15 2012-09-05 北京华大智宝电子***有限公司 实现移动终端电子支付的方法及***
FR2944400B1 (fr) * 2009-04-10 2013-01-18 Lynkware Procede d'authentification aupres d'un serveur par un utilisateur d'un appareil mobile

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2619941B1 (fr) * 2011-08-05 2018-12-12 Oney Bank Procede, serveur et systeme d'authentification d'une personne
GB2495474A (en) * 2011-10-03 2013-04-17 Barclays Bank Plc Mobile device user authentication within a telephone call, messaging session or at a physical location
GB2495571B (en) * 2011-10-03 2013-12-04 Barclays Bank Plc User Authentication
GB2495571A (en) * 2011-10-03 2013-04-17 Barclays Bank Plc Mobile device user authentication at a physical location using machine accessible codes or within a telephone call or messaging session
GB2495474B (en) * 2011-10-03 2015-07-08 Barclays Bank Plc User authentication
US9520918B2 (en) 2011-12-16 2016-12-13 Intel Corporation Login via near field communication with automatically generated login information
EP2792174A4 (fr) * 2011-12-16 2015-07-08 Intel Corp Connexion par communication en champ proche avec informations de connexion générées automatiquement
FR2996187A1 (fr) * 2012-10-02 2014-04-04 Renault Sa Systeme de gestion d'un vehicule et son procede associe
US9434332B2 (en) 2012-10-02 2016-09-06 Renault S.A.S. Vehicle management system and associated method
CN104768804A (zh) * 2012-10-02 2015-07-08 雷诺股份公司 车辆管理***和相关联的方法
WO2014053737A1 (fr) * 2012-10-02 2014-04-10 Renault S.A.S. Systeme de gestion d'un vehicule et son procede associe
EP2998896A1 (fr) * 2014-09-17 2016-03-23 Gemalto Sa Procédé d'authentification d'un utilisateur, terminaux et système d'authentification correspondants
WO2016041891A1 (fr) * 2014-09-17 2016-03-24 Gemalto Sa Procédé d'authentification d'un utilisateur, terminaux et système d'authentification correspondants
US10313126B2 (en) * 2015-06-10 2019-06-04 Feitian Technologies Co., Ltd. Barcode security authentication method
CN114898510A (zh) * 2022-05-11 2022-08-12 中国矿业大学 一种金融密码获取方法、***、金融设备及可存储介质

Also Published As

Publication number Publication date
CN103109494A (zh) 2013-05-15
WO2011138558A3 (fr) 2012-07-12
EP2567502A2 (fr) 2013-03-13
FR2959896A1 (fr) 2011-11-11
SG185449A1 (en) 2012-12-28
FR2959896B1 (fr) 2014-03-21
US9038196B2 (en) 2015-05-19
RU2012152466A (ru) 2014-06-20
US20130133086A1 (en) 2013-05-23

Similar Documents

Publication Publication Date Title
WO2011138558A2 (fr) Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
US20200404019A1 (en) Mutual authentication security system with detection and mitigation of active man-in-the-middle browser attacks, phishing, and malware and other security improvements
EP3138265B1 (fr) Sécurité améliorée pour un enregistrement de dispositifs d'authentification
EP2619941B1 (fr) Procede, serveur et systeme d'authentification d'une personne
EP2614458B1 (fr) Procede d'authentification pour l'acces a un site web
EP1253564A2 (fr) Procédé et dispositif de paiement électronique
EP1282288A1 (fr) Procédé et dispositif d'authentification
US20230091318A1 (en) System and method for pre-registration of fido authenticators
EP3923542A1 (fr) Dispositif informatique et procédé pour l'authentification d'un utilisateur
Herzberg et al. Protecting (even) Naive Web Users, or: preventing spoofing and establishing credentials of web sites
US20090177892A1 (en) Proximity authentication
EP2509025A1 (fr) Procédé d'accès à une ressource protégée d'un dispositif personnel sécurisé
EP2568406B1 (fr) Procédé de mise en oeuvre, a partir d'un terminal, de données cryptographiques d'un utilisateur stockées dans une base de données
US20090271629A1 (en) Wireless pairing ceremony
EP3350973B1 (fr) Procédé d'authentification de site de la toile et de sécurisation d'accès à un site de la toile
Drake et al. Designing a User-Experience-First, Privacy-Respectful, high-security mutual-multifactor authentication solution
WO2007113669A1 (fr) Securisation de transactions electroniques sur un reseau ouvert
EP3570518B1 (fr) Systeme et procede d'authentification utilisant un jeton a usage unique de duree limitee
Saini Comparative analysis of top 5, 2-factor authentication solutions
WO2017005644A1 (fr) Procédé et système de contrôle d'accès à un service via un média mobile sans intermediaire de confiance
Mannan Authentication and securing personal information in an untrusted internet
Solanki et al. Implementation of an anti-phishing technique for secure login using usb (iatslu)
Gurung Data Authentication Principles for Online Transactions
Janiszyn BCERT: Securing Electronic Commerce Using A Biometric Secured Token
FR2823929A1 (fr) Procede et dispositif d'authentification

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180034128.4

Country of ref document: CN

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

Ref document number: 11723560

Country of ref document: EP

Kind code of ref document: A2

REEP Request for entry into the european phase

Ref document number: 2011723560

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2011723560

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13696489

Country of ref document: US

Ref document number: 12012502192

Country of ref document: PH

WWE Wipo information: entry into national phase

Ref document number: 10154/CHENP/2012

Country of ref document: IN

ENP Entry into the national phase

Ref document number: 2012152466

Country of ref document: RU

Kind code of ref document: A