WO2020128203A1 - Procédé et système de sécurisation d'opérations, et poste utilisateur associé - Google Patents

Procédé et système de sécurisation d'opérations, et poste utilisateur associé Download PDF

Info

Publication number
WO2020128203A1
WO2020128203A1 PCT/FR2019/052926 FR2019052926W WO2020128203A1 WO 2020128203 A1 WO2020128203 A1 WO 2020128203A1 FR 2019052926 W FR2019052926 W FR 2019052926W WO 2020128203 A1 WO2020128203 A1 WO 2020128203A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
key
code
certification
dynamic code
Prior art date
Application number
PCT/FR2019/052926
Other languages
English (en)
Inventor
Ghislain Moncomble
Original Assignee
Orange
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 Orange filed Critical Orange
Priority to CN201980092192.4A priority Critical patent/CN113475047B/zh
Priority to EP19839364.7A priority patent/EP3900293A1/fr
Priority to US17/416,114 priority patent/US20220078183A1/en
Publication of WO2020128203A1 publication Critical patent/WO2020128203A1/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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4018—Transaction verification using the card verification value [CVV] associated with the card
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/067—Network architectures or network communication protocols for network security for supporting key management in a packet data network using one-time keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0846—Network architectures or network communication protocols for network security for authentication of entities using passwords using time-dependent-passwords, e.g. periodically changing passwords
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1483—Countermeasures against malicious traffic service impersonation, e.g. phishing, pharming or web spoofing

Definitions

  • the invention relates to the general field of securing transactions (eg creation of an account with any service or access to this account or more particularly online access to an account, online payment, physical payment, and others) by computerized means.
  • NFC type for "Near Field Communication”
  • NFC type for "Near Field Communication”
  • the maximum price level per transaction and cumulative price per period is set at a low threshold.
  • the 3-digit confirmation code changes regularly (every hour for example).
  • the advantage is then to drastically reduce the interest of an online piracy, for example via a keylogger tool, or due to phishing during a transaction on a merchant site for example, of the number bank card (linked to the customer's account number) and this CW code since any hackers can only use it over a very short period of time.
  • This process is a real advance in terms of online transactions, even if it does not cover cases of theft of the bank card itself. It is also unsuitable for reimbursement issues by the e-merchant.
  • Another weak link is indeed even less well protected and relates to the creation by a user of an account on any service (a merchant service for example, or a classified ads service, ...), and to the connection of this user to this account by simple username and password, data that can be easily hacked by a hacker.
  • a merchant service for example, or a classified ads service
  • a slightly more secure approach consists of entering your password code using a dynamic table: display of an image on which the allowed numbers or letters are on boxes, instructs the client to click on the right boxes, the service retrieving the position of the clicks and deducing their correspondence.
  • Hacking is a little more difficult, but does not pose a problem for an expert in the field.
  • Another variant is the possibility by the service provider (eg the bank) to communicate a confirmation code by another means (eg another email), or alternatively by a technology close to the secure code (sending '' a confirmation SMS with the code on their mobile).
  • the service provider eg the bank
  • sending '' a confirmation SMS with the code on their mobile sending '' a confirmation SMS with the code on their mobile.
  • the latter protection case does not cover cases of theft of the mobile (or alternatively hacking of the email via the username and password to access his email).
  • the hacker already has the client's password identifier, and a wrong answer will only block the client's account, which will generate other problems.
  • the invention in particular overcomes the aforementioned drawbacks by proposing a method for securing operations implemented at the level of a user station, a global method for securing operations implemented at the level of a system comprising the user station as well than a service provider device and a certification device.
  • the invention therefore provides a process for securing operations, comprising:
  • a generation step by a dynamic code generator device associated with the user key, of a first version (CC1) of the dynamic code;
  • the invention also relates to a user station comprising:
  • a user interface configured to allow a user (U) associated with a key (CL) issued by a certification body to formulate a request for the implementation of an operation with a service provider device;
  • a first reception module intended to receive a request for a dynamic code, intended for the user associated with the key (CL), from a device of the certification body;
  • a transmission module to the device for certifying codes produced by a dynamic code generator device associated with the user's key (CL); and - a second reception module intended to receive, from the service provider device, a message confirming the completion of the requested operation.
  • the invention also provides a global method for securing operations, the method for securing operations comprising:
  • a step of generation by a device generating dynamic codes of the user, of a first version (CC1) of the dynamic code;
  • the invention also relates to a system for securing operations, this system for securing operations comprising a service provider apparatus and a certification apparatus, in which:
  • the service provider device includes:
  • the certification system includes:
  • CC1 a module for receiving a first version (CC1) of the dynamic code generated by the dynamic code generator device assigned to the user associated with said key
  • CC2 a module for acquiring a second version (CC2) of the dynamic code
  • the methods, the user station and the system according to the invention make it possible to avoid several drawbacks of the state of the art, in particular those linked to the connection of a user to an online account.
  • these processes, this station and this system make it possible to implement double authentication for online payments, thus ensuring a high level of security in accordance with the European directive DSP2.
  • the user station incorporates its own dynamic code generator device.
  • other solutions can be used, e.g. the use of an external dynamic code generator device.
  • the certification apparatus includes its own dynamic code generator device configured to generate the same codes as the device assigned to the user, at the same times.
  • the service provider device obtains an identifier from the user and, using said identifier, acquires the key (CL) associated with the user, in particular from one of its means of storage or from a secure external source. Securing the operation desired by the user becomes all the less expensive for the latter, who no longer needs to enter a password associated with his identifier.
  • the user can use the same identifier on their accounts with several service providers who implement this embodiment, without loss of security, since it is the CL key associated with their account, and not the identifier, which secures the connection.
  • the step of transmitting the operation validation request comprises the emission of a request comprising information relating to the requested operation; and the method comprises a step of recovering user data associated with the key (CL), this last step comprising:
  • This step of recovering control data can comprise recovering data defining at least one restriction as to the operations permitted in relation to the key CL.
  • These data are for example: a time period during which operations are allowed, a geographical area where, or from which operations are allowed, a service provider with which operations are allowed, and a price associated with the performance of the operation.
  • the restrictions defined by the control data can be configured by the user, for example according to the use he intends to make of his key CL.
  • control data make it possible to define limits for the use of the key assigned to the user, these limits being fixed by the certification body, by the user or by both.
  • the security of operations will be all the more increased since, among other things, a hacker will not know the restrictions that apply to the use of the CL key and will not be able to adopt the behavior necessary to satisfy the restrictions.
  • control data offers wide possibilities for parameterizing the process / system and makes it possible to define specific new secure applications. A great advantage of these parameters is their combinations.
  • these combinations allow without creating a new account and without requiring a new payment card, to transmit a payment key CL to a child as pocket money by limiting to certain stores, a list of online merchant sites and / or a specific amount per month.
  • These combinations also make it possible to give a CL key card with a precise amount to his child who is going to do an internship abroad, the key being valid in said country for the period of the internship.
  • control data makes it possible to carry out an anti-spam process, the overall security process being adapted as follows:
  • the request is made not by the user but by the service provider's device and includes a request to transmit a message to the user associated with the key (CL);
  • the step of recovering user data associated with the key (CL), by the certification apparatus includes recovering control data indicating anti-spam parameters of the user and recovering contact details for the user ;
  • the step of transmitting the validation signal of the requested operation consists of transmitting the message to the user according to the coordinates retrieved by the certification apparatus when the certification apparatus finds that the transmission of the message is compatible with the user's anti-spam settings.
  • the SQ service provider does not have the user's contact details
  • the certification device allows the transmission of the service provider's message to the user only when the message complies with the anti settings.
  • -spam defined in relation to this user.
  • the user can specify the number of messages per time slot that he accepts to receive from a specific service provider and / or the means of communication (eg SMS, email) by which he agrees to receive the messages.
  • the restrictions are configurable by the user. For example, a user interface allows him to modify the parameters associated with a given CL key during a prior step of the process or at any time, for example by logging into his account with the certification body and selecting the key. CL desired.
  • the user can thus modify a period of validity, usage authorizations, authorized amounts, etc.
  • the modification will have no effect on historical uses, but will be applicable for future uses of the CL key. . In this way, the user obtains an increased level of control over the sensitive operations that he performs.
  • the generation of the first version of the dynamic code by the dynamic code generator device associated with the user's CL key is triggered by an action by the user.
  • the predictability of the dynamic code that will be transmitted to the certification apparatus is further reduced, further reducing the probability of data piracy, since we have - in addition to the variability associated with dynamic generation of codes - d '' random variability at the initiative of the user.
  • the triggering by a user action, of the production of a new code by the dynamic code generator device assigned to the user implies a need to synchronize the dynamic code generator device on the certification device side with the generator generator device.
  • dynamic codes on the user side Various approaches are suitable for achieving this synchronization such as, for example, the exploitation of ordered sequences of codes.
  • the certification device is configured to try to remedy differences between the positioning in the code sequence when it finds that the first and second versions of the code do not correspond.
  • the certification apparatus can implement an iterative process which consists in acquiring a new version of the dynamic code, in comparing the new version with the first version (CC1) of the dynamic code, and in the event of a positive comparison with note the correspondence of the codes but in the event of a negative comparison, repeat the steps of the iterative process until a number n of versions of the code have been acquired and compared with the first version of the code.
  • This process can be used in an embodiment according to which the dynamic code comprises a sub-code (CCs) serving for these synchronization purposes and the evolution of the dynamic code involves the progressive change of each character of the synchronization sub-code according to a respective rule.
  • the characters of the synchronization sub-code are distributed among the other characters of the dynamic code.
  • the measures mentioned above ensure good synchronization between the dynamic code generator devices on both sides (user and certification body) while obtaining a high level of security.
  • the user station is provided with an actuation module, intended to be actuated by the user to trigger the generation of a code by the dynamic code generator device, and with a biometric data.
  • the biometric data sensor it is possible for the biometric data sensor to obtain biometric data from the user when the actuation module is actuated by the user. If the biometric data sensor does not validate the biometric data detected during said user action, the code transmission module does not transmit a valid code to the certification device (e.g. no signal is transmitted to the certification apparatus or a signal is transmitted indicating that incorrect biometric data has been detected).
  • the invention also relates to a user station comprising a dynamic code generator device, a transmission module to a device for certifying the codes produced by the dynamic code generator device, and a biometric data sensor.
  • the conditioning of the transmission of the first version of the code by the validity of the biometric data of the user introduces into the process a second level of authentication, thus making it possible to further increase security.
  • the step of transmitting the dynamic code request by the certification apparatus comprises the transmission to a station of the user of information concerning the requested operation. This allows the user to be warned that a third party is seeking to perform an operation using the user's CL key. The user can, therefore, use his / her station to transmit a rejection signal to the certification device and the certification device will therefore not issue a validation signal to the certification device. service provider (for example an operation signal not validated will be transmitted).
  • the step of issuing the dynamic code request by the certification apparatus comprises the transmission to a user station of a request for additional information, and the validation of the operation. by the certification device is conditioned by the additional information returned by the user station.
  • the certification device can request data concerning the geolocation of the user station, and the validation of the operation by the certification device is then conditioned by the geolocation information returned by the user station. .
  • the certification apparatus checks whether this information conforms to the control data associated with the user's CL key. It is thus possible to add a layer of security to the basic process / system.
  • the method and the system for securing operations according to the invention make it possible to secure several different types of sensitive operations, for example: creation or secure connection to an account, a financial transaction, a banking operation, a purchase on a physical or online site, a cash withdrawal from an ATM, or an innovative anti-spam service.
  • creation or secure connection to an account for example: creation or secure connection to an account, a financial transaction, a banking operation, a purchase on a physical or online site, a cash withdrawal from an ATM, or an innovative anti-spam service.
  • creation or secure connection to an account for example: creation or secure connection to an account, a financial transaction, a banking operation, a purchase on a physical or online site, a cash withdrawal from an ATM, or an innovative anti-spam service.
  • the process provides strong security when creating an account, both for the service provider and the user, since the validation of the account is linked to a process external to the service.
  • the process provides strong security when connecting to an account: the service provider only needs the user's identifier (no need for a password, or alternatively other personal information) and its CL key. This information is unusable for a possible pirate without the possession of the various dynamic code generating devices of the customers concerned, in particular if the service provider does not store the personal data which can be returned to him at the end of the process.
  • the user is content to enter his identifier, then to copy his CC code.
  • the e-merchant no longer fears the risk of piracy, since he stores a CL key unrelated to a bank card number next to the customer (and possibly valid only for this e- merchant for predefined amounts per period).
  • the user instead of entering a bank card number, then the expiry dates and the CW code, only enters the CC code generated by his dynamic code generator device.
  • this device is compatible with methods of the state of the art.
  • the different steps of the security method are determined by instructions from computer programs. Consequently, the invention also relates to computer programs on respective information carriers, these programs being capable of being implemented in the service provider apparatus, in the certification apparatus and in a station. user, or more generally in a computer, these programs comprising instructions adapted to the implementation of the steps of a computerized process for securing operations as described above.
  • These programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.
  • the invention also relates to information supports readable by a computer, and comprising instructions for computer programs as mentioned above.
  • the information medium can be any entity or device capable of storing the program.
  • the support may include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a floppy disk or a disc. hard.
  • the information medium can be a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can in particular be downloaded from a network of the Internet type.
  • the information medium can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question. It can also be envisaged, in other embodiments, that the security method, the security system, and the user station according to the invention have all or some of the above characteristics in combination.
  • Figure 1 shows, schematically, a security system according to the invention in a particular embodiment
  • FIG. 2 represents, in the form of a flowchart, the main steps of a global method for securing operations according to the invention
  • FIG 3 shows, schematically, the main interactions between the elements of the system during the course of the process of Figure 2;
  • FIG. 4 represents, in the form of a flowchart, the main steps of a process for securing operations according to an embodiment of the invention at a user station;
  • FIG. 5 represents the architecture of a user station according to the invention in a particular embodiment
  • FIG. 6 represents the architecture of a service provider apparatus according to the invention in a particular embodiment
  • FIG. 7 represents the architecture of a certification apparatus in accordance with the invention in a particular embodiment
  • FIG. 8 represents the hardware architecture of a user station according to the invention in a particular embodiment.
  • FIG. 9 represents, in the form of a flowchart, the main steps of an anti-spam method according to an embodiment of the invention.
  • Figure 1 shows, schematically, a security system according to the invention in a particular embodiment. It should be noted that the example shown in Figure 1 relates to a system comprising a user station as well as a service provider apparatus and a certification apparatus. As an alternative, the system does not include a user station and the user U introduced the necessary data (eg an identifier, the first version of the dynamically generated code and, possibly, the CL key) using means provided, for example, by the service provider.
  • necessary data eg an identifier, the first version of the dynamically generated code and, possibly, the CL key
  • the system 1 for securing operations comprises a user station 10, a service provider apparatus 20 and a certification apparatus 30 which communicate with each other via a network 40 (eg Internet, telephone network, WAN, LAN, wired or wireless network, etc.).
  • a network 40 eg Internet, telephone network, WAN, LAN, wired or wireless network, etc.
  • the user station 10 can be a mobile telephone, a tablet, a PC, or any other device of a user U.
  • the service provider apparatus 20 consists of a server or a group of servers operated by a service provider. SQ service, possibly associated with other equipment.
  • the SQ service provider can be a merchant, a bank, etc.
  • the certification device 30 consists of a server or a group of servers operated by a CERT certification body, possibly associated with other equipment.
  • the CERT certification body can be a bank, a mobile operator or any other type of body capable of issuing a CL key and offering SQ service providers a standardized means conforming to that described below.
  • FIG. 2 represents, in the form of a flowchart, the main steps of the process and FIG. 3 schematically represents the main interactions between the elements of the system during the course of the process.
  • the method represented in FIG. 2 can include a preliminary phase or step (EP) during which a key CL is assigned to the user U.
  • This preliminary step EP can, in particular, comprise a first sub-step F10 according to which the user formulates with the certification body a request tending to produce (generate) a key CL and the assignment to the user of this key CL.
  • the certification body CERT transmits the key CL to the user in a sub-step F20 and typically also transmits to the latter a DC device generating dynamic codes.
  • the user already has a dynamic code generator device and at this stage only obtains from the CERT certification body the CL key generated.
  • the user U wishes to undertake a transaction or other operation, in particular a sensitive operation, by using his key CL, the user formulates a request DEM_OP with the service provider SQ (F30) during a first step E1 of the method.
  • the service provider apparatus 20 transmits to the certification apparatus 30 a request REQ_VAL (CL) for validation of the requested operation, said request indicating the key CL associated with user U (F40).
  • the certification apparatus 30 identifies the user associated with the key CL, for example by carrying out a search in a database using the key CL.
  • the certification apparatus 30 retrieves (F50) control data, recorded during the prior phase EP, associated with the use of the key CL and performs certain checks, for example with respect to to information concerning the operation requested by the user U, this information having been transmitted to the certification apparatus 30 by the service provider apparatus 20 (eg in a message which includes the key CL).
  • the certification device 30 can already transmit to the service provider device a message indicating that the requested operation is outside the permitted uses for the CL key (F55).
  • the certification device 30 issues a REQ_CC request for dynamic code, intended for the user associated with the key (CL) (F60).
  • the process can stop at step F55.
  • the certification apparatus 30 can transmit the request REQ_CC to the user station 10, in the form of a form which will be displayed on the screen.
  • the device DC generating dynamic codes associated with the key CL of the user produces a first version CC1 of the dynamic code (F70).
  • the DC device generating dynamic codes is provided with a pulse means (or other means operable by the user) and the dynamic code is generated following the actuation of this means. impulse by the user.
  • the process ends with a fifth step E5 during which the certification apparatus (30) acquires a second version (CC2) of the dynamic code and compares it with the first version of the code and, provided that the first and second versions (CC1, CC2) of the dynamic code correspond, transmits to the apparatus 20 of the service provider a signal TX_RES indicating the validation of the operation requested by the user U (F100).
  • the certification apparatus 30 can transmit to the service provider SQ a message indicating that the requested operation has not been validated.
  • other information may be passed to the service provider device at the end of step E5.
  • the result of the comparison (F90) can provide the performance of other operations by the certification apparatus 30 (eg updating the amount of a credit associated with the CL code).
  • the body responsible for certifying the operations provides the user with a key CL associated with a device DC of codes with dynamic cryptogram CC (this device DC being either already owned by the user or provided to the user by the certification body during the EP stage).
  • said user must first of all register with said certification body CERT and provide him with various elements: his name, his first name, or the means of contacting him (such, email) , etc.
  • Registration can be done online (possibly using a process such as that of the invention) or in physics, as for a traditional banking agency. It can also be mixed: for example, a 1 st line registration phase and a second phase after delivery of a physical CD device to its pre-specified address (eg mailing address, in an agreed location such as a relay, ).
  • the data (user) associated with the key CL requests a CL key from his certification body and specifies different parameters, corresponding to different types of information that the certification body will link to said CL key in one way or another. , for example through a database, or any other means of managing the persistence of this data, dedicated to said certification body.
  • the list of types of information can be very variable, and we only cite here a non-exhaustive subset. Some of the information will be used as control data but others correspond to metadata associated with the user (of course certain information can fulfill both roles).
  • the types of information can be relative:
  • the link can be made with the name of the user U-lnit as indicated during registration (as indicated in the description of the start of the previous step).
  • the user can possibly specify several names, if the key is intended to be shared (a bit like a joint account).
  • the certification body will manage the association of the key CL with its owner U-lnit and the different complementary identity (s) U -Comp above.
  • At least one specific use given of the key CL can be specified. There are many examples of uses.
  • a CL key can thus be used only for registration and connection or online payment formalities, or both, possibly on a specific site ...
  • a key can therefore have several uses (not to be confused with usage authorizations): for example registration, connection to a site and online payment on said site.
  • the CL key can be used for all possible uses for the user concerned. These usage restrictions are indeed optional.
  • the user can use only one key to connect / register on different sites or services without specifying which ones, see paying on said sites if they are sites merchants. But he will not be able to benefit from the interests mentioned above and neither those which will be specified later.
  • At least one restriction can be defined in relation to the use of the CL key.
  • restrictions There are many examples of restrictions, and only a few are listed below:
  • a maximum amount, and possibly an amount per period can be specified.
  • the user can specify "subscription to a service", then select from a list of known services, or even manually add the name (and possibly the url corresponding to the domain name in the case of an Internet site) of said service or site if it is not in the list of known sites.
  • said service corresponding to SQ itself provides, before the prior step, the name or name code on which it is referenced by the certification bodies, in the case where a reference list of these services exists.
  • the parameters can also be presented in dependence on each other.
  • the user can formulate a restriction request in terms of payment amount in order to be able to specify said amounts and associated terms.
  • This option is automatically offered to the customer only if a payment method has been indicated for their CL key.
  • the user can not only modify the parameters associated with a given CL key during the step prior EP but also at any time.
  • the user can make the desired modification by logging into his account with the certification body, then by selecting the desired CL key, then by modifying said parameters.
  • the key CL is the number of a bank card, possibly coupled with an expiry date
  • the code CC is said code with dynamic cryptogram.
  • the entity holding the role of certification body is then a banking organization.
  • the key CL provided by the certification body does not necessarily correspond to the number of a bank card, but is a unique key intended for said user.
  • This key is made up of a predefined number of successive characters (eg numbers and / or letters). As a variant, this succession of symbols can also incorporate special characters.
  • This unique key can be provided electronically to the user, or in any other form. It can thus possibly be materialized on a plastic card like bank cards.
  • the key CL incorporates into the code of this key a means making it possible to identify the certification body, which makes it possible to standardize this succession of characters, and allows Standardized APIs independent of certification bodies.
  • Another advantage of this variant is of course that said keys CL are globally unique: no duplication possible on the market. For example, if the said key was made up of 16 characters, the first 12 can be dedicated to the specific key of the user and the last 4 to the identification of the issuing body. In which case, said list of certification bodies and their code is unique regardless of the CL key.
  • the key CL corresponds to a credit card number, possibly combined with an end date of validity
  • the dynamic cryptogram CC code DC device corresponds to that available on the dynamic cryptogram cards with 3-digit code (known as CW code) changing periodically, according to a method and with the means already explained above.
  • CW code 3-digit code
  • the key CL is not a card number and may include a succession of letters and or numbers, with certain sequences and positions standardized in particular in order to recognize the certification body as already indicated.
  • the key is for example communicated to the user, electronically or by any other means by the certification body.
  • it is affixed and visible on any support, such as a plastic card for example.
  • coding elements of the CL key can enable the certifying body issuing said CL key to be found with certainty.
  • coding elements of the key CL make it possible to specify restrictions of particular use of said key when there are: for example not exhaustive, a key having no restriction would have A in the n th character while a key which can only be used for a registration request would have I in 1 th character.
  • a DC device can be associated with several CL keys
  • the user can indicate data valid for a default use, then request the creation, by the certification body, of different keys with separate data (in particular if he intends one of said keys to a third party, such as a child for example) or partially separate.
  • DC device for all or some of their keys greatly simplifies the user's task (no need to have 5 cards (or rings, watches, ...) each with a of these DC devices).
  • it may have a limited number of DC devices: for example, a first intended for its accounts with different services and another intended for its means of payment.
  • a support such as a screen ring has 2 DC devices and a respective display screen, a 1 st screen intended for displaying the CC keys of the 1 st device corresponding for example to keys. access to various services, a second screen intended for displaying the CC keys of the 2nd device corresponding for example to access keys to online payments.
  • said support has only one display screen and a means such as, for example, not exhaustive, a push button makes it possible to switch from one type of display to another, this means being distinct a possibly present impulse means which the user uses to generate the next value of the dynamic code.
  • a visual clue ex. a symbol or a color, at the level of the display, makes it possible to distinguish each of the 2 DC devices.
  • said common device DC has a means for displaying the different keys that it supports, so that the user selects the desired key to obtain the corresponding current (or pulsed) CC code.
  • This variant however complicates the DC device and makes it more complex to use: If for example a CL key comprises a series of 16 numbers and or letters, the user must remember what use each of these suites corresponds to. not boring.
  • the device DC generates a CC code according to one of the implementations detailed above, independently of the choice of a key.
  • the link between this DC device and one or more CL keys of the user is then kept only at the level of the certification body's databases.
  • a user can have a ring provided with such a DC pulse device, generating on demand a cryptogrammic code CC, and use said code in the following steps of the method and device for
  • the user requests that an operation be carried out with an appliance of any SQ service.
  • the operations covered are very varied.
  • a request to create an account a request to initiate a transaction, a request to access a room or a physical or digital resource (e.g. request to open or start of a car, request to enter a private or company house), etc.
  • he indicates or associates his CL key and the certification body.
  • the key CL includes the code of the certification body, the user does not need to provide this information during this step E1.
  • the type of operation (account creation, connection to an account, start of a payment transaction, 7) can be determined implicitly during this step E1. If, for example, the user clicks or presses a "Create your account” button, the SQ service device will determine that it is an account creation, and this information will be used in the rest of the process. .
  • a standardized API is made available to the SQ service device by the certification body and allows the latter to select a type of operation, then to provide the additional information required according to this type of operation.
  • this same API will be used for the various data exchanges between the SQ device and the certification body during the later stages of the process.
  • 1st example the user selects an account creation type operation with the SQ service device.
  • the only useful information to be provided by the user is the CL key.
  • the CL key is either intended only for uses in the SQ service, or for more general uses including the SQ service.
  • limiting oneself to this single piece of information can be problematic for the user since it requires him to remember the composition of said key associated with its use on the SQ service.
  • the SQ service device can offer the user to fill out a form containing additional information, such as a connection identifier for example.
  • additional information such as a connection identifier for example.
  • said identifier is a personal telephone number or a personal email.
  • the registration form includes other information such as, for example, not exhaustive, the surname, first name and for example address or even other contact data of said user.
  • this additional information is provided during the subsequent steps by the certification body, if the user has authorized it, and not by the user.
  • 2nd example the user selects a type of operation Connecting to an account with the SQ service.
  • the user enters the personal connection identifier that he indicated during the creation of his account during a previous operation. Thanks to the implementation of the method and device, he does not have to enter a password at this stage.
  • the device of the SQ service retrieves the key CL associated with the user's account in one of its storage means such as a database at the level of said SQ service, key CL that said user has indicated opposite this identifier. connection when creating an account or during a subsequent update of your account on said service.
  • the storage means can be internal or external to the apparatus 20 of the SQ service.
  • the user selects an “Online payment” type operation after selecting an item or creating a basket with the SQ service.
  • the user can without any fear, in particular in the distinct cases of bank card numbers, have their payment key kept at the level of said SQ service, since as we we will see later that key will be unusable by possible hackers without having the associated DC device.
  • the solution provided here is compatible since the same card number can be used according to the routes of the state of the prior art to access merchant services not affiliated with our process (it will suffice for the user to enter his bank details in a conventional manner directly at this stage: bank card number, expiry date and CW code generated by the DC device), and to access affiliated SQ services to our process.
  • the apparatus 20 of the service provider SQ requests from the certification body the validation of the operation carried out in step E1.
  • This step here consists in communicating to said certification body, the key CL selected by the user in step E1, and concomitantly the contextual data corresponding to said operation.
  • said transmission of information is standardized and takes place through an interface (API) provided by a third-party organization OT to which affiliated the said SQ service for this API (this third body can also be a certification body, but the CL key is not necessarily managed by the latter, but by any certification body on the market), interface detailing the interaction procedures with the various certification services on the market as well as the type of data exchanged.
  • API interface
  • the apparatus of the SQ service provides in a standardized manner various information related to the type of operation requested by the user in step E1.
  • the SQ service device provides the certification body with the user's CL key and a code corresponding to the operation carried out. It can also provide a KSQ key, specific to the SQ service device.
  • the codification is for example a series of 3 letters.
  • This coding is for example CRE for an account creation, CNX for a connection to an account, "PA Y” for a payment in one go (called one shot payment), “PAYn” for a payment in several times (with data associated the number of times, ...), “PAYAb” for a payment by subscription with associated data the duration of the subscription, the periodic amount ...,
  • Each use is associated with a specific code and with one or more additional information linked to the type of transaction (for example for a transfer, in addition to the keyword "VIR", an amount, an account or a third-party key and an indication 'deadline).
  • the treatment of the PLC program implemented at the unit SQ Service also enhances the level of SQ 1 st commissioned a series of controls, such as for example check the conformity of the key CL (number of characters, determination of the certification body (depending on the corresponding code included in the key, %) and according to the variant detailed at the end of the previous step check whether said key is authorized for this type of operation (also in depending on the corresponding code included in the key at the predefined position for these checks ).
  • the key CL provided by the apparatus of the SQ service allows at the level of the certification body, or at the level of a third body OT to which said SQ service affiliated for this API, which will then transmit the information collected to the certification body, to recover the information necessary for the process according to the invention and relating to the SQ service, such as for example the name of the service SQ, the URL of the domain name concerned (or an application identifier on any store, such as the Apple Store or Play store, for example, not exhaustive).
  • Other information for example relating to the geographic coordinates of said SQ service if it is a physical store for example (information provided when SQ registers with the service provider of its API key) can be provided on this occasion .
  • a lookup table included in the treatments of the PLC program implemented at the device from the service allows SQ from the determination of the certification body corresponding to the CL key (via the series of dedicated codes within the CL key) to find the address (for example a non-exhaustive URL type) of the certification body to be questioned.
  • the device of the SQ service interrogates directly, preferably through a secure link (for example of the https type) said certification body at the address agreed according to this correspondence table by transmitting to it in a standardized manner the information described above.
  • This 1 st variant is faster, but requires frequent updating of the correspondence table used by the multiple SQ services.
  • the request for the SQ service is transmitted to the third party organization OT, which after having possibly retrieved the information associated with the KSQ API key from SQ in the storage means of said third party service OT, reroute the request from the SQ service, as well as all the associated data retrieved from the initial request or determined via the use of data from the API key, to the services of the corresponding certification body.
  • the apparatus 30 of the certification body CERT receives the key CL and, optionally, the associated information originating from steps E1 or E2, identifies the user corresponding to this key in its databases, and transmits to this user a request for the supply of dynamic code (for example by sending him a validation form).
  • This step E3 begins with the reception by a reception means designed for this purpose at the level of the certification body, of the request emanating from the SQ service, via the possible intermediary of the third party service OT.
  • Said reception means then collects and classifies the different information contained in the request:
  • this information is transmitted via an XML form or a json file, or in Post mode from the third-party organization OT to the certification body. Many other more or less secure methods are possible.
  • a means of interrogation of the apparatus 30 of the certification body is then implemented to determine by interrogation of its storage means (databases for example) to which user (or alias) belongs the key CL supplied .
  • the various associated information described above is retrieved by this interrogation means.
  • a control means is then implemented to control the data transmitted during steps E1 and E2 with respect to the data relating in particular to the uses and restrictions of uses accepted for said key CL.
  • the possible analyzes and comparisons are known and are not all detailed here.
  • this means of control makes it possible to verify that a transaction coding associated with the CL key conforms to the transaction or transactions authorized for this CL key in the storage means of the certification body.
  • this control means checks that the additional data associated with the CL key and relating to the SQ service correspond well to said SA site or application.
  • control means checks that the user payment limit associated with said key CL, possibly over a given period, is not exceeded.
  • a selection means makes it possible to select the communication coordinates associated with the user's CL key, and possibly an associated communication means, and generates the sending to the user of a validation form.
  • the means of communication to the user is via communication coordinates (email, number of user mobile, ...) indicated by the user at the SQ service level and transmitted by the latter during step E2.
  • additional data relating to the request transmitted by the SQ service are associated with said sending. It may for example be a series of information which during step E4 indicate to the user that the validation form is linked to a request to create an account for such a service, or to connect to such service, or payment of such amount for such service, to use the 3 examples already mentioned above.
  • additional data relating to restrictions of use linked in the storage bases of the certification body with the key CL are associated with said shipment. It may for example be non-exhaustive, if the key CL is linked to a restriction of use on a precise geographical area (for example linked to a physical store), of a request to control the geolocation of the user .
  • the user's station 10 receives the request to supply the dynamically generated code. For example, at the level of his workstation (mobile phone, tablet, etc.) the user receives and then completes a form with a cryptogrammic code generated by his DC device associated with his CL key.
  • the certification apparatus can formulate its request for dynamic code and to present this request at the user level, in particular on a user's workstation (eg mobile phone, PC, tablet).
  • the certification device transmits a validation form to the user station. It should be noted that the invention is not to be limited with respect to this manner of presenting the request for dynamic code.
  • a reception means makes it possible to receive the validation form and any additional data associated therewith, then to present the validation form to the user.
  • Many known methods allow this type of reception and display.
  • the user receives an email from the certification device, including email a relative link to the form.
  • the email itself may contain additional information relating to the transaction.
  • the user receives an SMS from the certification device, including email a relative link to the form.
  • the SMS can itself contain additional information relating to the operation.
  • the user receives a message incorporating the form on his instant messaging, and possibly the details related to the transaction.
  • the API between the SQ service and the certification apparatus possibly through the OT service already mentioned, cooperates so that the form validation is transmitted to the SQ service device and displayed following (a few seconds maximum) the user's request on the device through which the user made his request, without it having to open another application.
  • an integrated form a robot ( "bot" in English) merchant service is transmitted to the user.
  • the form may have only one input area and a validation button.
  • it may include a text zone recalling the context of the request (for example, request to create an account on such service, or request for payment in 3 installments of such amount on such service, ).
  • one of the advantages of a method according to the invention at least from the point of view of the user, is the elimination of the minimum response time of the known methods (duration of validity associated to a code ).
  • An implementation similar to that of the 4 th and 5 th examples is particularly suitable, for requests requiring a rapid response.
  • an implementation similar to that of examples 1 to 3 indicated above are possible (send by email, ).
  • the validation form is only displayed after acceptance of certain conditions by the user.
  • the display of said validation form is conditioned upon acceptance by the user to access their geographic position (activate the geolocation functionality if it is a mobile, ...) In the event of refusal, the process therefore stops at this stage .
  • the information thus collected is transmitted in parallel with the data entered on the validation form.
  • the certification device requests geolocation on a user terminal physically separate from the DC code generation device (this second terminal having been connected to the user during the prior phase EP (or updated later)
  • the certification body can randomly request the geolocation of the user's workstation or other proof of identity (fingerprint, etc.), all of this complying with DSP2 directives.
  • step E4 in the event of refusal, said form is displayed, but no associated data is sent at the end of step E4, which causes a refusal of the request during step E5.
  • the latter can fill it out using the CC code from their DC device associated with their CL key, according to the different implementation variants of said DC device detailed in 'previous step.
  • dynamic cryptogram refers for its definition of state of the art to the codes known as 3-digit cryptogram visible on the back of bank cards on the market. Said code is composed of data (3 digits in the case of bank cards) not incorporated in the magnetic strip of said cards and allowing, by providing them separately, to secure a transaction.
  • Dynamic code technology limits one of the main risks associated with online hacking of the card number and its cryptogram, by varying it by period (half-hours, hours, etc.): a possible hacker who has recovered the various information necessary for payment on the internet (card number, expiration date and visual cryptogram) will indeed have very little time to use this data before the cryptogram becomes obsolete.
  • the method making it possible to subsequently check the validity of said code is explained in step E5.
  • bank cards with dynamic cryptogram integrate an e-paper screen (electronic paper) inserted in the thickness of this card, a mini-battery that can last 3 years (lifetime of these cards ) and an NFC antenna.
  • the clock-driven microcontroller generates a cryptogram every half hour. The generated code is then sent to the LCD e-paper screen and remains displayed until the next code is generated so that it can be read by the user at any time.
  • the user requests the display of the CC1 code by pressing a push button on his DC device, or by scanning his fingerprint on said device, ... which triggers the calculation of said CC1 code by the DC device , and its consecutive display on the display area of said DC device.
  • the DC device can be implemented in various ways, not only in the form of a card with dynamic cryptogram, but also inserted in a device dedicated to the production of codes or else in a dematerialized manner, for example in the form of software, code or app downloaded from at least one personal device DP of the user such as his PC or his mobile phone, provided that said device has a 1 st sub means of generating CC cryptograms according to the desired specifications, and a 2 nd sub means presentation / display of said CC cryptograms to the user.
  • this device is a device separate from the conventional Internet connection means, and is supplied by the certification apparatus to the client.
  • the DC device incorporating means for generating cryptograms and for presentation / display can thus be incorporated into a support such as a plastic card, a watch, a ring, a bracelet ... these types of support then have a display device allowing to view the current cryptogram code.
  • the main interests of such objects are that they can always be available and accessible by the user, and this in a manner distinct from other means of interaction with online services.
  • the cryptogrammic code generated can be a series of letters and or numbers, or even include some special characters.
  • the display of the CC code requires a so-called triggering or impulse means (press a button for example) which launches the display of the code.
  • said triggering means in addition to this display, also controls (triggers) the generation of the CC code.
  • the advantage of this last variant is in addition to the periodic variability already mentioned above (the code changes every half hour for example, even in the presence of the trigger mechanism) to have a random variability on the initiative of the user.
  • This variant implies the need to ensure synchronization between the code CC1 generated by the device DC at this level and the second version CC2 of the code generated during step E5 at the servers of said certification device on a device DCC for this key CL.
  • the problem is therefore that for any action (eg pulse) triggering a generation of a new CC code, by the DC device, the DCC device must be synchronized, so that in step E5, the CC key can be validated at the level of the certification apparatus.
  • the method of generating the CC code is based on an ordered list of precalculated cryptograms integrated in the memory of the device DC opposite the key CL, with the same list of precalculated cryptograms available at the level of the device DCC opposite the CL key, an impulse at DC level switches to next cryptogram on the user-side list, and this advance must be communicated in some way to the DCC level to maintain synchronization.
  • the advancement in the CC codes is then made (in addition to the advanced by pulse) synchronously between DC and DCC for said key CL.
  • said DC device is connected in one way or another to the Internet according to one of the many known means, and for transmitting said information relating to the pulse (or other triggering act) to the servers hosting the DCC device.
  • This 1 st variant comprises, in addition to the costs and energy consumption of the communication means required at DC level, potential risks in terms of security, since a connection and authentication path is necessary between DC and DCC.
  • a return channel would also be necessary in order to verify the acknowledgment of the good reception of the pulse at the DCC level.
  • the synchronization is managed by means specific to step E5.
  • a series of characters included in the CC code is reserved for synchronization due to the pulses at the DC device.
  • the CC code is composed of 6 characters, the first four forming the cryptogrammic key CCv, and the last two forming a CCs code allowing during step E5 to the DCC device to find the number of pulses made since creation of the CL key. This variant will be described in more detail in relation to step E5.
  • a minimum time period between two pulses is imposed, for example not limited to maximum every 3 seconds, this interval can be completed by a maximum number of pulses per unit time, for example a non-exhaustive maximum of 5 pulses per minute and 40 pulses per hour.
  • a maximum number of pulses per unit time for example a non-exhaustive maximum of 5 pulses per minute and 40 pulses per hour.
  • the pulse is linked to a fingerprint sensor integrated into the DC device, which has the advantage of allowing our method and system to perform a double authentication, providing an increase in security and respecting the European directive DSP2, since in addition to re-entering the code, the user must authenticate via his fingerprint. In which case, the imprint should be recognized to generate an impulse.
  • a device including a fingerprint sensor ring a movement of the thumb towards the ring is enough to put the palm of the thumb on this ring. Even if the said ring is stolen, the DC device could not therefore be implemented ...
  • the problem in such a scenario stems from the necessary compatibility with the online payment methods already in place, which incorporate the entry of a CW code into 3 digits next to the other data on the bank card (key and expiration date).
  • the DC devices used according to the embodiments of the invention generate CC codes which are not necessarily composed of successions of 3 digits, but can be a succession of for example 6 or 8 numbers and or letters. In which case, by default, our CC codes would not be compatible with the 3-digit CW codes expected for a bank transaction.
  • the 1 st variant consists in imposing that the first 3 characters of said generated code are numbers. To do this, it suffices to adapt the generation methods at the DC device level and, on the certification device side, at the DCC device level.
  • the user during a standard banking transaction must limit himself to entering these first 3 digits, which may be displayed on the screen of the DC device in a different manner from the other characters in the series (another color for example).
  • the methods for generating said CC codes include the possibility of generating a 3-character code of the digit type according to a predetermined pulse interval, for example every 4 pulses. In which case, if the current CC code displayed is not 3 digits, the user launches a pulse (and this at most 3 consecutive times), before a 3 digit CC code is displayed.
  • a 3rd variant mixes the 2 proposals above: every n pulses, a CC code with n characters (6 or 8 for example) is generated, the first 3 characters of said code being a succession of 3 digits, compatible with the processes therefore using CW type codes.
  • the first version CC1 of the code is generated on the user side, it is then transmitted to the certification device.
  • the user copies the CC1 code to the validation form presented to him and validates the said form.
  • the validation generates the sending of the validation result, namely the communication of said copied CC1 code associated with the key CL, and possibly associated additional data, to the ad hoc means of the certification apparatus.
  • the form can be combined with third-party devices, such as for example a fingerprint reader, or iris analysis device, or any other user-specific information known to the device.
  • certification password, answer to a question, (7) whose collected information can be transmitted in parallel to that described above at the end of step E4.
  • the process then ends with a 5 th and last step, E5, during which the certification body recovers and then compares the first version CC1 of the CC code, received from the device DC of the user, to a second version CC2 generated at the servers of said certification body for said key CL of said user (or acquired by the certification body for example from an external DCC device).
  • the certifier compares the two versions of the code. If the two match (e.g. are identical), the certification body accepts the request, otherwise it refuses it. In all cases, information indicating the result of the comparison is returned to the SQ service, possibly coupled with additional information.
  • the main operation of this step E5 consists in checking whether the first version of the CC code supplied on the side of the user in step E4 is in conformity with that expected.
  • the server or system incorporating the servers of said certification body should be able to verify the accuracy of the cryptogram indicated by the alleged user in step E4.
  • this certification body it is appropriate at the level of this certification body to have, next to each key CL, a DCC means and device making it possible to produce said CCS code associated with CL (or to a set of keys CL according to the variant according to which a only one pair of DC and DCC devices is associated with several keys CL) at a given time.
  • a list of cryptograms precomputed with a selection ciphertext per time step (e.g. every hour passes to the next code in said list) is recorded in a relation to CL in memory, the same list of precalculated cryptograms must also be available at the DCC device next to CL.
  • a timestamp and a secret is shared between dynamic code generator device and the certification body.
  • the server hosting the DCC device for said CL code must then be perfectly synchronized with the server hosting the user's DC device (in order to retrieve the same timestamp).
  • the 2 DC and DCC devices must be synchronized.
  • this synchronization is carried out at the time of manufacture or programming of the two DC and DCC devices and does not vary any more.
  • the DCC device makes it possible to recalculate the code CC2 associated with CL, then compares it to the code CC1 communicated opposite the key CL at the end of step E4. The result of this comparison is kept for the end of step E5.
  • the synchronization problem is more complex in the case of a DC device generating a CC code using a pulse means (by pressing a button by example), in isolation or in addition to the evolution by time step or other (there is no particular problem of course if the impulse means only serves to display the current code (therefore s' it is only used to save the battery, or in the variants according to which the pulse is linked to a fingerprint or other biometric parameter, to secure the display).
  • step EP a 1 st variant to solve the problem of timing related to the generation in step E4 CC code using any pulse means at the level of the device DC consists of a specific management means GS on the occasion of step E5.
  • the implementation of said means GS consists in a 1 st sub-step to save the CC2-init code and its respective synchronization data.
  • This synchronization data depends on the method used to generate said code CC2-init relative to the key CL. To use the example of a method based on a scheduled list of precalculated cryptograms, it would be the position of the CC2-init code in said scheduled list.
  • the specific management means GS resynchronizes the device DCC for the key CL at the level of the code CC2-init.
  • the specific management means GS resynchronizes the DCC device for the CL key at the code level (CCS-init) + i for which a match was found. The result of this comparison is kept for the end of step E5.
  • the user side using a one pulse means at of the DC device consists of a CCs subcode integrated into the CC code.
  • This CCs code could for example consist of a sequence of 2, or alternatively of 3 characters numeric or alphanumeric (beyond, the code will take a long time to re-enter by the user in step E4 of the process).
  • the CCs code is a simple sequence of a predefined chronological order from a starting point when creating the CL key. For example, a sequence would have as its starting point the J8v code and the chronology would be:
  • this information is also implemented on the DC and DCC devices relative to the CL key when creating said key (or when creating the 1 st CL key if said DC and DCC devices are common to several keys ).
  • the resynchronization is carried out in a similar manner to that indicated for the 1 st variant above using a similar GS means, but relating to the CCs code.
  • said CCs code can, in exactly the same way as CCv code, be managed by one of the possible methods for generating the CCs code (two distinct methods can be implemented for the CCv code and the CCs code).
  • the resynchronization is carried out in a similar manner to that indicated for the 1 st variant above using a similar GS means, but relating to the CCs code.
  • the CCv and CCs codes can be mixed when displayed on DC and DCC devices. For example, for a global sequence of 6 characters, the CCv code is displayed on the 2 nd , 3 rd and 6 th characters, while the CCs code is displayed on the 1st, 4 th and 5 th characters. This information must of course be known at the DCC device in order to both perform the resynchronization and check the agreement between the code entered in step E4 and the expected code.
  • the CCs and CCv codes are kept on 2 separate servers, always relative to a respective CL key (or a set of CL keys).
  • the specific means GS is implemented at the level of the server housing the CCs code sequence coupled to CL, and once the synchronization has been carried out, the result is transmitted to the server retaining CCv to control CCv with regard to the same key CL . Once the comparison has been made, the result of said comparison is kept for the end of step E5.
  • an operation or transaction refusal information is returned to the requesting SQ service, which is responsible for possibly informing the user thereof.
  • an operation relating to an online purchase will be accepted if the amount of credit associated with the CL key, possibly over a time slot defined at the level of said CL key, is compatible with the amount of the purchase. If this is not the case, information of refusal of operation or transaction is returned to the requesting SQ service, the latter being responsible for possibly informing the user thereof. If so, the said amount of credit associated with CL is debited from the amount of the purchase.
  • dedicated means checks whether the geolocation data have indeed been communicated at the end of step E4 in addition to the code CC entered by the user, and if so if they correspond to the authorized geolocation zone. If this is not the case, information of refusal of operation or transaction is returned to the requesting SQ service, the latter being responsible for possibly informing the user thereof.
  • the means of verifying the geolocation (or of a footprint, ...) can be implemented on another terminal of the user.
  • additional information is communicated by the certification body CERT to the SQ service.
  • SQ For example, for an account creation and or an account connection, data associated with this account such as name or alias, first name, email, ... associated with CL are returned to SQ.
  • SQ service One of the advantages for the SQ service is that even if the databases are hacked, a possible hacker does not have access to these data if SQ has not stored them himself. It is not necessary for this SQ service to make declarations to organizations such as the CNIL (for "National Commission for Information Technology and Liberties") since this service does not store personal data. The requirements linked to the RGPD (for “General Regulation on Data Protection”.) are also greatly simplified because the SQ services concerned which do not store any personal data.
  • the amount of credit remaining in the user's account after the transaction is returned to the SQ service (for example if this SQ service is a financial service and the transaction was a transfer or other).
  • the user can log in to his account in the usual way (email + password for example), but he will always receive a validation request by crypto code: for this purpose, SQ searches for the key associated with said account in its database, then questions the certification body (succession of steps E2 to E4). Therefore, if the SQ service ensures the uniqueness of the user identifier, the user would no longer even need a password, entering the CC code associated with their key being then sufficient.
  • the user can use their CL key to log into the account (but they must remember this). The same procedures can be used for a payment.
  • the method comprises a first step E1a which, from the point of view of the user station, comprises a step (F30a) of formulating a request, by a user (U) associated with a key (CL) issued by a certification body, implementation of an operation with a service provider device.
  • the assignment of the key CL to the user can be done during a prior step EP similar to that described above.
  • step of generation by a device generating dynamic user codes, of a first version (CC1) of the dynamic code (F70) and a step of transmitting the first version (CC1) of the dynamic code to the certification device (F80).
  • reception step from the service provider device, of a message confirming the completion of the requested operation.
  • step F60a is part of a step E3a similar to step E3 described above, and that step F110 is part of a step E5a similar to step E5 described above. It is therefore understood that the remarks and variants set out above with regard to steps EP, E1 and E3 to E5 apply in general also to steps EP, E1a, E3a, E4 and E5a in FIG. 4.
  • FIGS. 5 to 7 represent functional modules adapted to construct the user station 10, the service provider apparatus 20 and the certification apparatus 30, knowing that in reality the functionality described is typically implemented using instructions from a computer program rather than using physical modules.
  • the person skilled in the art will understand that the number of functional modules can be different from those shown in FIGS. 5 to 7. In other words, the functions of certain modules can be distributed over an increased number of modules and / or a single module can combine the functions of several of the modules represented.
  • the user station 10 can include the functional modules shown in FIG. 5.
  • the user station 10 comprises a device 12 for generating dynamic codes, and a module 14 for transmitting to a device for certifying the codes produced by the device 12 for generating dynamic codes.
  • the station also includes a user interface 15 via which the user can formulate a request for the implementation of an operation with a service provider device, a first reception module 17a intended to receive a request for dynamic code from the apparatus 30 of the certification body, and a second reception module 17b intended to receive, from the service provider apparatus, a message confirming the completion of the requested operation.
  • the first and second reception modules 17a, 17b can be integrated into a single module as shown in FIG. 5.
  • the user station 10 may include an actuating means 15a and a sensor 16 for biometric data.
  • the actuating means 15a is part of the user interface 15.
  • the device 12 generator of dynamic codes is configured to generate a new code in response to an action of the user, in particular the actuation of the actuation means 15a integrated in the user interface 15.
  • the sensor 16 for biometric data is then arranged to obtain biometric data from the user during the action of the user which triggers generating new code.
  • the code transmission module 14 is then configured to transmit to the valid code certification device only if the biometric data sensor 16 validates the biometric data detected during said user action.
  • the service provider apparatus 20 may include the functional modules shown in FIG. 6.
  • the service provider apparatus 20 comprises a module 22 for receiving a request, by the user U, for implementing an operation, a module 24 for transmitting (to the certification apparatus) a request for validation of the requested operation, said request indicating the key CL associated with the user U, and a module 26 for implementing the requested operation following the reception of a validation signal from the certification apparatus.
  • the certification device 30 may include the functional modules shown in FIG. 7.
  • the device 30 of certification includes a module 34 for sending a dynamic code request, intended for a dynamic code generator device assigned to the user associated with said key (CL).
  • the certification apparatus 30 also includes a module 35 for receiving the first version CC1 of the dynamic code generated by the dynamic code generator device GC on the user side, a module 37 for acquiring the second version CC2 of the dynamic code, a module 38 for comparing the first and second versions CC1, CC2 of the dynamic code, and a module 39 for transmitting a validation signal to the apparatus 20 of the service provider when the first and second versions (CC1, CC2) of the dynamic code match.
  • the module 37 for acquiring the second version CC2 of the dynamic code can correspond to a GCC device generating dynamic codes.
  • the certification apparatus may also include a module 32 for recovering the user data associated with the key CL received from the service provider apparatus, intended for example to recover the control data mentioned above.
  • the different steps of the security method are determined by instructions of computer programs intended to be implemented in the service provider apparatus, in the certification apparatus and in a user station, or more generally in a computer.
  • computers include the elements represented in FIG. 8, that is to say a CPU processor, an I / O communication interface, a ROM read-only memory, a RAM random access memory and a DISP module managing the display at level of a screen (not shown), these components being conventionally connected via a bus.
  • a CPU processor an I / O communication interface
  • ROM read-only memory read-only memory
  • RAM random access memory a DISP module managing the display at level of a screen (not shown)
  • DISP module managing the display at level of a screen
  • step E1 of the method is not carried out.
  • SQ device initiates the process at the 2nd stage E2 requesting validation of a transaction.
  • This variant can be illustrated in many use cases, including for example not exhaustive that of an anti-spam system, whether SMS, email or telephone.
  • said SQ service does not have the customer's contact details, but only the CL key with which there are possibly different means of contacting the customer (for example the customer accepts to be contacted by email and SMS, but the corresponding contact details are not provided), and possibly, if the user has authorized the corresponding disclosures at the previous stage, for each means, slots and / or a number of contacts maximum per slot.
  • the service provider SQ initiates the process by requesting (F35) from the certification apparatus the transmission of a message to the user U associated with a key CL (for example a contact by mail).
  • the request SQ service provider REQ_OP is issued by the service provider apparatus 20 and identifies the key CL of the intended user.
  • this step F35 corresponds to a variant E2b of the step E2 described above.
  • the certification apparatus 30 recovers (F50b) data concerning the user associated with the key CL supplied by the service provider apparatus, for example data identifying the coordinates of the user and control data which can be characterized as anti-spam parameters.
  • the CERT certification body verifies whether the transmission of the message to the user at the request of the SQ service provider is or is not in accordance with the anti-spam parameters associated with the user associated with the CL key. For example, the certification body verifies whether the SQ service is one of the authorized services appearing in a list of broadcasting authorizations that the user indicated in the previous step with regard to the CL key concerned, as well as the conditions possibly linked (number of calls and or SMS / emails, ... per period, ). The process follows its course and goes directly from step E3b to step E5b, without distributing a validation form to the user at the end of step E3b. In the case of a positive determination by the certification body, the certification body accepts the broadcast, and an email / SMS ... TX_MES is sent / rerouted while respecting the anonymity of the user (F100b).
  • a minimum formatting of emails, SMS ..., can be carried out.
  • the service provider device can ask the certification service to start a message with the variables First name then Last name according to a predefined formulation at the level of the API concerned and, if the certification device agrees to transmit the message to the user of the certification device replaces the variables First name then Last name with the corresponding data (if they are held).
  • the certifying body CERT transmits a specific request to the user seeking the latter's agreement to add the SQ service provider to the list of services authorized to send him messages.
  • the certification device sends (F60b) a validation form TX_FRM at the end of step E3b and a variant E4b of step E4 is carried out.
  • the user during step E4b can either validate, on the form, the request to add the SQ service to the list of authorized services by entering a confidential code CC, or refuse it.
  • the user station transmits its response U_ REP to the certification device (F80b).
  • Step E5b takes place normally, with, according to the responses from step E4b, an addition of SQ in the broadcasting authorizations linked to CL and the corresponding broadcasting, ie a refusal of broadcasting.
  • the validation form in step E4b includes optional entry of additional information, of the type: permanent authorizations, on a predefined slot or slots, number of contacts accepted, etc.
  • additional information of the type: permanent authorizations, on a predefined slot or slots, number of contacts accepted, etc.
  • the user can, as already indicated for the previous step, at any time on his account on the certification body modify for his CL key the authorizations, including those of dissemination, whether or not given to the SQ service concerned.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

Un procédé de sécurisation d'opérations comprend une étape (F30) de demande, par un utilisateur (U), de mise en œuvre d'une opération auprès d'un appareil (20) de prestataire de service, ce dernier émettant (F40) à un appareil (30) de certification une requête de validation de l'opération demandée tout en indiquant une clé (CL) associée à l'utilisateur (U). L'appareil (30) de certification identifie l'utilisateur associée à la clé (CL) et lui transmets (F60) une demande de code dynamique. Un dispositif (12) générateur de codes dynamiques affecté à l'utilisateur génère (F70) une première version (CC1) du code dynamique et le transmet (F80) à l'appareil (30) de certification qui le compare (F90) avec une seconde version (CC2) du code pour décider s'il convient ou non d'informer l'appareil prestataire de la validation de l'opération demandée.

Description

Procédé et svstème de sécurisation d’opérations, et poste utilisateur associé
Domaine Technique
L’invention se rapporte au domaine général de la sécurisation d’opérations (ex. une création de compte à un service quelconque ou un accès à ce compte ou de façon plus particulière un accès en ligne à un compte, un paiement en ligne, un paiement physique, et autres) par des moyens informatisés.
Technique antérieure
La sécurisation de ces opérations est un enjeu important aujourd’hui compte tenu de la prolifération de pirates qui cherchent à s’emparer des données d’identification et des données financières des utilisateurs. Plusieurs solutions ont été mises au point ces dernières années, en relation avec des opérations de types différents, mais ces solutions présentent toutefois un certain nombre de limites.
En ce qui concerne des transactions de paiement direct, c’est-à-dire des transactions non en ligne (chez des commerçants ou pour des retraits en espèce) : ces transactions se distinguent dans leurs versions de base par l’introduction d’une carte bancaire dans un terminal ou une borne de paiement lisant les données de ladite carte, la sécurisation de l’ensemble étant assurée par la saisie d’un code secret complémentaire connu de l’utilisateur seul. Le principal problème de sécurité à ce niveau est relatif au vol du code secret (par l’intermédiaire de bornes factices, par exemple).
Une approche intéressante et en croissance rapide est relatif aux paiements sans contacts de type NFC (pour « Near Field Communication »), pour lesquels il suffit d’approcher sa carte bancaire d’un terminal de paiement pour valider une transaction. L’intérêt est la simplicité pour l’utilisateur (un seul geste suffit), couplé avec un certain niveau de sécurité, puisque l’utilisateur ne saisit ni son numéro, ni son code secret, et donc ne les dévoile pas. A contrario, en cas de vol de la carte, le voleur n’a plus besoin de code secret. Pour limiter les effets de ces vols de carte le niveau maximum de prix par transaction et en cumulé par période est fixer à un seuil bas.
Les solutions de paiement sans contact par smartphone s’adressent au même usage avec une technologie proche associée à une sécurité, en général l’empreinte du doigt préalablement scannée du client ou celle de son visage ou iris. Ces dernières données peuvent cependant être piratées. L’usage est d’ailleurs ici de remplacer la carte bancaire par un smartphone pour la commodité de l’utilisateur plutôt que de sécuriser le processus.
En ce qui concerne des transactions en ligne liées aux cartes bancaires ces transactions se caractérisent dans leurs versions de base par la fourniture du numéro de carte, ce dernier étant sécurisé par la saisie d’un code complémentaire à 3 chiffres dit code CW (les appellations varient selon les banques). La sécurité reste faible, puisqu’il suffit aux pirates de récupérer le numéro et le code CW, ou encore de voler la carte.
II existe des cartes à cryptogramme dynamique, telles celles incorporant la technologie de la société Idemia dont le code de confirmation à 3 chiffres, dit code CW, change régulièrement (toutes les heures par exemple). L’avantage est alors de réduire drastiquement l’intérêt d’un piratage en ligne, par exemple via un outil de keylogger, ou du fait d’un phishing à l’occasion d’une transaction sur un site marchand par exemple, du numéro de carte bancaire (lié au numéro de compte du client) et de ce code CW puisque les éventuels pirates ne pourront l’utiliser que sur un très bref laps de temps. Ce procédé est une réelle avancée côté transactions en ligne, même s’il ne couvre pas les cas de vol de la carte bancaire elle-même. Il est en outre inadapté aux problématiques de remboursement par le e-commerçant.
Le procédé dit "codes secure" des banques leur permet de demander une validation de transaction en ligne à leurs clients, après que ceux-ci aient saisi leurs données bancaires sur un site : à cet effet, elles leur envoient un code de validation sur leur mobile (lié au compte bancaire dans les bases de données internes des banques), charge au client de recopier ce code dans une interface dédiée s’affichant au niveau de l’interface de la transaction avant de retourner sur le site marchand.
Ce procédé est efficace mais plus onéreux que le précédent, et ne protège pas du cas de figure selon lequel le mobile et la carte bancaire sont volés, ces deux derniers étant souvent portés ensembles. Il n’empêche pas non plus le vol des données de la carte bancaire (numéro et code CW), et ce alors que la mise en œuvre du code sécure du fait de son coût n’est pas systématique. Enfin, des pirates aguerris arrivent à pirater le contenu du SMS reçu, quand le mobile est utilisé à la fois pour commander en ligne et recevoir le SMS avec le code sécure, usage qui tend à devenir majoritaire. La demande de brevet français publiée FR3044789 permet d’éviter cette dernière problématique, mais sa mise en œuvre est plus complexe et doit être réservée aux transactions de montant élevé ou aux process sécurisés.
Il y a aussi le cas des coordonnées bancaires stockées chez un commerçant en ligne. L'objectif est ici de simplifier l'expérience client lors d'une commande en ligne. Lors de la validation d'un panier, il suffit alors au client de sélectionner son moyen de paiement, et de confirmer la transaction par la saisie de son code CW. En termes de sécurité, il suffit donc au pirate de récupérer ce code CW, ou la carte bancaire / le mobile. Cette approche ouvre la porte aussi aux piratages des serveurs du e-commerçant, suivi de celui des codes CW des clients.
Dans tous les cas de figure précités, il reste donc des problématiques de sécurité.
Un autre maillon faible est en effet encore moins bien protégé et est relatif à la création par un utilisateur d'un compte sur un service quelconque (un service marchand par exemple, ou un service de petites annonces, ...), et à la connexion de cet utilisateur à ce compte par simple identifiant et mot de passe, données pouvant être aisément hacquées par un pirate.
* Une approche un peu plus sécurisée consiste en la saisie de son code mot de passe à l'aide d'un tableau dynamique : affichage d'une image sur laquelle les chiffres ou lettres permis sont sur des cases, charge au client de cliquer sur les bonnes cases, le service récupérant la position des clics et en déduisant leur correspondance. Le piratage est un peu plus difficile, mais ne pose pas de problème à un expert du domaine.
* Une autre variante est la possibilité par l'offreur du service (ex. la banque) de communiquer un code de confirmation par un autre biais (ex. un autre email), ou en variante par une technologie proche du code secure (envoi d'un SMS de confirmation avec le code sur son mobile). Ce dernier cas de protection ne couvre pas les cas de vol du mobile (ou en variante le piratage du mail via l'identifiant et mot de passe pour accéder à son mail). En outre, selon ce cas de figure, on présume que le pirate dispose déjà de l'identifiant mot de passe du client, et une mauvaise réponse ne permettra que de bloquer le compte du client, ce qui générera d'autres problèmes.
Ces failles sont d'autant plus dommages que les vols de données d'identité sur les services en ligne sont en explosion.
Exposé de l’invention L’invention pallie notamment les inconvénients précités en proposant un procédé de sécurisation d’opérations mis en œuvre au niveau d’un poste utilisateur, un procédé global de sécurisation d’opérations mis en œuvre au niveau d’un système comportant le poste utilisateur ainsi qu’un appareil de prestataire de service et un appareil de certification. On peut également appeler le procédé mis en œuvre au niveau du poste utilisateur « procédé de traitement d’une opération ».
L’invention prévoit, donc, un procédé de sécurisation d’opérations, comprenant :
- une étape de formulation d’une demande, par un utilisateur (U) associé à une clé (CL) émise par un organisme de certification, de mise en œuvre d’une opération auprès d’un appareil de prestataire de service ;
- une étape de réception, par un poste utilisateur, d’une demande de code dynamique, destinée à l’utilisateur associé à la clé (CL), depuis un appareil de l’organisme de certification ;
- une étape de génération, par un dispositif générateur de codes dynamiques associé à la clé de l’utilisateur, d’une première version (CC1 ) du code dynamique ;
- une étape de transmission de la première version (CC1 ) du code dynamique à l’appareil de certification ; et
- une étape de réception, en provenance de l’appareil de prestataire de service, d’un message confirmant la réalisation de l’opération demandée, à condition que la première version du code dynamique corresponde à une deuxième version du code dynamique générée au niveau de l’organisme de certification.
Corrélativement, l’invention vise aussi un poste utilisateur comprenant :
- une interface utilisateur configurée pour permettre à un utilisateur (U) associé à une clé (CL) émise par un organisme de certification de formuler une demande de mise en œuvre d’une opération auprès d’un appareil de prestataire de service ;
- un premier module de réception destiné à recevoir une demande de code dynamique, destinée à l’utilisateur associé à la clé (CL), depuis un appareil de l’organisme de certification ;
- un module de transmission à l’appareil de certification de codes produits par un dispositif générateur de codes dynamiques associé à la clé (CL) de l’utilisateur ; et - un deuxième module de réception destiné à recevoir, depuis l’appareil de prestataire de service, un message confirmant la réalisation de l’opération demandée.
L’invention prévoit également un procédé global de sécurisation d’opérations, le procédé de sécurisation d’opérations comprenant :
- une étape de demande, par un utilisateur, de mise en œuvre d’une opération auprès d’un appareil de prestataire de service ;
- une étape d’émission par l’appareil de prestataire de service à un appareil de certification d'une requête de validation de l'opération demandée, ladite requête indiquant une clé (CL) associée à l’utilisateur ;
- une étape d'émission d’une demande de code dynamique, destinée à l’utilisateur associé à la clé (CL), depuis l’appareil de certification ;
- une étape de génération, par un dispositif générateur de codes dynamiques de l’utilisateur, d’une première version (CC1 ) du code dynamique ;
- une étape de transmission de la première version (CC1 ) du code dynamique à l’appareil de certification ;
- une étape d’acquisition d’une seconde version (CC2) du code dynamique et de comparaison des première et seconde versions du code dynamique par l’appareil de certification ; et
- à condition que les première et seconde versions (CC1 ,CC2) du code dynamique correspondent, une étape de transmission par l’appareil de certification à l’appareil de prestataire de service d’un signal indiquant la validation de l’opération demandée par l’utilisateur.
Corrélativement, l’invention vise aussi un système de sécurisation d’opérations, ce système de sécurisation d’opérations comprenant un appareil de prestataire de service et un appareil de certification, dans lequel :
l’appareil de prestataire de service comprend :
- un module de réception d’une demande, par un utilisateur (U), de mise en œuvre d’une opération, - un module d’émission vers l’appareil de certification d’une requête de validation de l'opération demandée, ladite requête indiquant une clé (CL) associée à l’utilisateur, et
un module de mise en œuvre de l'opération demandée suite à la réception d’un signal de validation de la part de l’appareil de certification ; et
l’appareil de certification comprend :
- un module d’émission d’une demande de code dynamique, destinée à un dispositif générateur de codes dynamiques affecté à l’utilisateur associé à ladite clé (CL),
- un module de réception d’une première version (CC1 ) du code dynamique générée par le dispositif générateur de codes dynamiques affecté à l’utilisateur associé à ladite clé
(CL),
- un module d’acquisition d’une seconde version (CC2) du code dynamique,
- un module de comparaison des première et seconde versions (CC1 ,CC2) du code dynamique, et
un module de transmission d’un signal de validation à l’appareil (20) de prestataire de service lorsque les première et seconde versions (CC1 ,CC2) du code dynamique correspondent.
Les procédés, le poste utilisateur et le système selon l'invention permettent d'éviter plusieurs inconvénients de l'état de l'art, en particulier ceux liés à la connexion d’un utilisateur à un compte en ligne. Par ailleurs, ces procédés, ce poste et ce système permettent de mettre en œuvre une double authentification pour les paiements en ligne assurant ainsi un niveau élevé de sécurité conforme à la directive européenne DSP2.
Dans certains modes de réalisation de l’invention, le poste utilisateur intègre son propre dispositif générateur de codes dynamiques. Toutefois d’autres solutions peuvent être employées, ex. l’emploi d’un dispositif générateur de codes dynamiques externe.
Dans certains modes de réalisation de l’invention, l’appareil de certification comporte son propre dispositif générateur de codes dynamiques configuré pour générer les mêmes codes que le dispositif affecté à l’utilisateur, aux mêmes moments. Toutefois d’autres solutions peuvent être employées, ex. l’obtention de la seconde version du code depuis un dispositif externe. Dans un mode particulier de réalisation, l’appareil de prestataire de service obtient un identifiant de la part de l’utilisateur et, à l’aide dudit identifiant, acquiert la clé (CL) associée à l’utilisateur, notamment depuis un de ses moyens de stockage ou depuis une source externe sure. La sécurisation de l’opération voulue par l’utilisateur devient d’autant moins onéreuse pour ce dernier, qui n’a plus besoin d’introduire un mot de passe associé à son identifiant. Par ailleurs, l’utilisateur peut se servir du même identifiant sur ses comptes auprès de plusieurs prestataires de service qui mettent en œuvre ce mode de réalisation, sans perte de sécurité, puisque c’est la clé CL associée à son compte, et non pas l’identifiant, qui sécurise la connexion.
Dans un autre mode de réalisation, l’étape d’émission de la requête de validation d'opération comprend l’émission d’une requête comportant des informations concernant l’opération demandée ; et le procédé comprend une étape de récupération de données de l’utilisateur associée à la clé (CL), cette dernière étape comprenant :
■ la récupération de données de contrôle indiquant au moins une restriction par rapport aux opérations permises, et
■ l’analyse des informations reçues concernant l’opération demandée pour déterminer si cette opération est ou non permise par rapport aux données de contrôle.
Cette étape de récupération de données de contrôle peut comprendre la récupération de données définissant au moins une restriction quant aux opérations permises en relation avec la clé CL. Ces données sont par exemple : une période temporelle pendant laquelle des opérations sont permises, une zone géographique où, ou à partir de laquelle, des opérations sont permises, un prestataire de service auprès duquel des opérations sont permises, et un prix associé à la réalisation de l’opération. Selon un mode particulier de réalisation, les restrictions définies par les données de contrôle peuvent être paramétrées par l’utilisateur, par exemple en fonction de l’usage qu’il compte faire de sa clé CL.
Les données de contrôle permettent de définir des bornes à l’usage de la clé affectée à l’utilisateur, ces bornes étant fixés par l’organisme de certification, par l’utilisateur ou par les deux. La sécurisation des opérations sera d’autant accrue que, entre autres, un pirate ne saura pas les restrictions qui s’appliquent à l’usage de la clé CL et ne saura pas adopter le comportement nécessaire pour satisfaire aux restrictions. Par ailleurs, l’exploitation des données de contrôle offre des possibilités larges de paramétrisation du procédé / du système et permet de définir des applications spécifiques nouvelles sécurisées. Un grand avantage de ces paramètres tient à leurs combinaisons. Par exemple non exhaustif, outre leur intérêt pour la sécurisation des comptes, ces combinaisons permettent sans créer de nouveau compte et sans nécessiter une nouvelle carte de paiement, de transmettre une clé CL de paiement à un enfant en tant qu'argent de poche en le limitant à certains magasins, à une liste de sites marchand en ligne et/ou à un montant précis par mois. Ces combinaisons permettent également de donner une carte à clé CL avec un montant précis à son enfant qui va faire un stage à l'étranger, la clé étant valable dans ledit pays pour la période du stage.
L’exploitation des données de contrôle permet de réaliser un procédé anti-spam, le procédé global de sécurisation étant adapté comme suit :
- la demande est formulée non pas par l’utilisateur mais par l’appareil de prestataire de service et comprend une demande de transmission d’un message à l’utilisateur associé à la clé (CL) ;
- l’étape de récupération des données de l’utilisateur associée à la clé (CL), par l’appareil de certification, comprend la récupération de données de contrôle indiquant des paramètres anti-spam de l’utilisateur et la récupération des coordonnées de l’utilisateur ;
- les étapes d’émission de demande de code dynamique, et de génération des première et seconde versions du code dynamique sont omises ; et
- l’étape de transmission du signal de validation de l’opération demandée consiste en la transmission du message à l’utilisateur selon les coordonnées récupérées par l’appareil de certification lorsque l’appareil de certification constate que la transmission du message est compatible avec les paramètres anti-spam de l’utilisateur.
Selon ce procédé anti-spam, le prestataire de service SQ ne dispose pas des coordonnées de l’utilisateur, et l’appareil de certification permet la transmission à l’utilisateur du message du prestataire de service uniquement lorsque le message est conforme aux paramètres anti-spam définis en relation avec cet utilisateur. Ainsi, par exemple, l’utilisateur peut préciser le nombre de messages par tranche de temps qu’il accepte de recevoir de la part d’un prestataire de service spécifique et/ ou le moyen de communication (ex. SMS, courriel) par lequel il accepte de recevoir les messages. Selon un mode de réalisation, le restrictions sont paramétrables par l’utilisateur. Par exemple, une interface utilisateur lui permet de modifier les paramètres associés à une clé CL donnée pendant une étape préalable du procédé ou à tout moment, par exemple en se connectant à son compte auprès de l'organisme de certification et en en sélectionnant la clé CL voulue.. L’utilisateur peut ainsi modifier une période de validité, des autorisations d’usage, des montants autorisés ... La modification n'aura aucun effet sur les utilisations historiques, mais sera applicable pour les utilisations futures de la clé CL. De cette manière, l’utilisateur obtient un niveau accru de contrôle sur les opérations sensibles qu’il réalise.
Dans un autre mode de réalisation, la génération de la première version du code dynamique par le dispositif générateur de codes dynamiques associé à la clé CL de l’utilisateur est déclenchée par une action de l’utilisateur. De cette manière, on réduit davantage la prédictibilité du code dynamique qui sera transmis à l’appareil de certification, réduisant encore la probabilité de piratage des données, puisqu’on dispose - en plus de la variabilité associée à la génération dynamique des codes - d’une variabilité aléatoire à l’initiative de l’utilisateur.
Le déclenchement par une action de l’utilisateur, de la production d’un nouveau code par le dispositif générateur de codes dynamiques affecté à l’utilisateur implique un besoin de synchroniser le dispositif générateur de codes dynamiques côté appareil de certification avec le dispositif générateur de codes dynamiques côté utilisateur. Diverses approches conviennent pour réaliser cette synchronisation comme, par exemple, l’exploitation de séquences ordonnées de codes. Dans un mode particulier de réalisation, l’appareil de certification est configuré pour essayer de remédier à des écarts entre le positionnement dans la séquence de codes lorsqu’il constate que les première et seconde versions du code ne correspondent pas. A cette fin, l’appareil de certification peut mettre en oeuvre un processus itératif qui consiste à acquérir une nouvelle version du code dynamique, à comparer la nouvelle version avec la première version (CC1 ) du code dynamique, et en cas de comparaison positive à constater la correspondance des codes mais en cas de comparaison négative à répéter les étapes du processus itératif jusqu’à ce qu’un nombre n de versions du code aient été acquises et comparées avec la première version du code. Ce processus peut être employé dans un mode de réalisation selon lequel le code dynamique comporte un sous-code (CCs) servant à ces fins de synchronisation et l’évolution du code dynamique comporte le changement progressif de chaque caractère du sous-code de synchronisation selon une règle respective. Par ailleurs, selon certains modes particuliers de réalisation, les caractères du sous-code de synchronisation sont distribués parmi les autres caractères du code dynamique.
Les mesures évoquées ci-dessus permettent d’assurer la bonne synchronisation entre les dispositifs générateur de codes dynamiques des deux côtés (utilisateur et organisme de certification) tout en obtenant un niveau de sécurité élevé.
Selon un mode particulier de réalisation, le poste utilisateur est pourvu d’un module d’actionnement, destiné à être actionné par l’utilisateur pour déclencher la génération d’un code par le dispositif générateur de codes dynamiques, et d’un capteur de données biométriques. Dans ce poste utilisateur, il est possible de le capteur de données biométriques obtienne des données biométriques de l’utilisateur lors de l’actionnement du module d’actionnement par l’utilisateur. Si le capteur de données biométriques ne valide pas les données biométriques détectées lors de ladite action de l’utilisateur, le module de transmission de codes ne transmet pas de code valable à l’appareil de certification (ex. aucun signal n’est transmis à l’appareil de certification ou un signal est transmis indiquant que des données biométriques erronées ont été détectées).
Selon un autre aspect, l’invention vise aussi un poste utilisateur comprenant un dispositif générateur de codes dynamiques, un module de transmission à un appareil de certification des codes produits par le dispositif générateur de codes dynamiques, et un capteur de données biométriques.
Le conditionnement de la transmission de la première version du code par la validité des données biométriques de l’utilisateur introduit dans le procédé un deuxième niveau d’authentification, permettant ainsi d’augmenter davantage la sécurité.
Dans un mode particulier de réalisation, l’étape d’émission de la demande de code dynamique par l’appareil de certification comprend la transmission à un poste de l’utilisateur d’informations concernant l’opération demandée. Ceci permet d’avertir l’utilisateur qu’un tiers cherche à réaliser une opération en se servant de la clé CL de l’utilisateur. L’utilisateur peut, donc, se servir de son poste pour transmettre à l’appareil de certification un signal de rejet de l’opération et l’appareil de certification n’émettra, donc, pas de signal de validation vers l’appareil de prestataire de service (par exemple un signal d’opération non validée sera transmis). Dans un mode particulier de réalisation, l’étape d’émission de la demande de code dynamique par l’appareil de certification comprend la transmission à un poste de l’utilisateur d’une demande de renseignements complémentaires, et la validation de l’opération par l’appareil de certification est conditionnée par les renseignements complémentaires retournés par le poste utilisateur. En tant qu’exemple non limitatif, l’appareil de certification peut demander des données concernant la géolocalisation du poste utilisateur, et la validation de l’opération par l’appareil de certification est alors conditionnée par les renseignements de géolocalisation retournés par le poste utilisateur. Par exemple, l’appareil de certification vérifie si ces renseignements sont conformes aux données de contrôle associées à la clé CL de l’utilisateur. On peut ainsi ajouter une couche de sécurité au procédé / système de base.
Le procédé et le système de sécurisation d’opérations selon l’invention permettent la sécurisation de plusieurs types d’opérations sensibles différentes, par exemple : la création ou la connexion sécurisée à un compte, une transaction financière, une opération bancaire, un achat sur un site physique ou en ligne, un retrait d'espèces au niveau d’un automate, ou encore un service d'anti-spam innovant. Le grand intérêt du procédé et du système est la sécurisation accrue par rapport aux procédés de l’état de la technique, le tout avec une grande simplicité d'usage.
Le procédé permet une sécurisation forte lors de la création d'un compte, à la fois pour le prestataire de service et l'utilisateur, puisque la validation du compte est liée à un processus externe au service.
Le procédé permet selon un autre exemple une sécurisation forte lors de la connexion à un compte : le prestataire de service n'a en effet besoin que de l'identifiant de l'utilisateur (pas besoin de mot de passe, ni en variante d'autres informations personnelles) et de sa clé CL. Ces informations sont inexploitables pour un éventuel pirate sans la possession des différents dispositifs générateurs de codes dynamiques des clients concernés, en particulier si le prestataire de service ne stocke pas les données personnelles qui peuvent lui être retournées en fin de procédé.
Côté expérience utilisateur, selon divers modes de réalisation de l'invention celui-ci se contente de saisir son identifiant, puis de recopier ensuite son code CC.
Il en va de même pour les transactions financières en ligne. Le e-commerçant ne craint plus le risque de piratage, puisqu'il stocke en regard du client une clé CL sans rapport avec un numéro de carte bancaire (et éventuellement valable que pour cet e- commerçant pour des montants prédéfinis par période). L'utilisateur en lieu et place de la saisie d'un numéro de carte bancaire, puis des dates de fin de validité et du code CW, ne saisit que le code CC généré par son dispositif générateur de codes dynamiques. De plus, ce dispositif est compatible avec des procédés de l'état de la technique.
Dans un mode particulier de réalisation, les différentes étapes du procédé de sécurisation sont déterminées par des instructions de programmes d’ordinateurs. En conséquence, l’invention vise aussi des programmes d’ordinateur sur des support d’informations respectifs, ces programmes étant susceptibles d’être mis en œuvre dans l’appareil de prestataire de service, dans l’appareil de certification et dans un poste utilisateur, ou plus généralement dans un ordinateur, ces programmes comportant des instructions adaptées à la mise en œuvre des étapes d’un procédé informatisé de sécurisation d’opérations tel que décrit ci-dessus.
Ces programmes peuvent utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
L’invention vise aussi des supports d'informations lisibles par un ordinateur, et comportant des instructions des programmes d'ordinateur tels que mentionnés ci- dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. On peut en outre également envisager, dans d'autres modes de réalisation, que le procédé de sécurisation, le système de sécurisation, et le poste utilisateur selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
La figure 1 représente, de façon schématique, un système de sécurisation conforme à l’invention dans un mode particulier de réalisation ;
La figure 2 représente, sous forme d’ordinogramme, les principales étapes d’un procédé global de sécurisation d’opérations selon l’invention ;
La figure 3 représente, de manière schématique, les principales interactions entre les éléments du système lors du déroulement du procédé de la figure 2 ;
La figure 4 représente, sous forme d’ordinogramme, les principales étapes d’un procédé de sécurisation d’opérations selon un mode de réalisation de l’invention au niveau d’un poste utilisateur ;
La figure 5 représente l’architecture d’un poste utilisateur conforme à l’invention dans un mode particulier de réalisation ;
La figure 6 représente l’architecture d’un appareil de prestataire de service conforme à l’invention dans un mode particulier de réalisation ;
La figure 7 représente l’architecture d’un appareil de certification conforme à l’invention dans un mode particulier de réalisation ;
La figure 8 représente l’architecture matérielle d’un poste utilisateur conforme à l’invention dans un mode particulier de réalisation ; et
La figure 9 représente, sous forme d’ordinogramme, les principales étapes d’un procédé anti-spam selon un mode de réalisation de l’invention.
Description des modes de réalisation
La figure 1 représente, de façon schématique, un système de sécurisation conforme à l’invention dans un mode particulier de réalisation. Il convient de noter que l’exemple représenté sur la figure 1 se rapporte à un système comprenant un poste utilisateur ainsi qu’un appareil de prestataire de service et un appareil de certification. A titre d’alternative, le système ne comporte pas de poste utilisateur et l’utilisateur U introduit les données nécessaires (ex. un identifiant, la première version du code généré de manière dynamique et, éventuellement, la clé CL) en se servant de moyens fournis, par exemple, par le prestataire de service.
Dans l’exemple envisagé à la figure 1 , le système 1 de sécurisation d’opérations comprend un poste utilisateur 10, un appareil 20 de prestataire de service et un appareil 30 de certification qui communiquent entre eux via un réseau 40 (ex. Internet, réseau téléphonique, WAN, LAN, réseau filaire ou sans fils, etc..).
Le poste utilisateur 10 peut être un téléphone mobile, une tablette, un PC, ou tout autre dispositif d’un utilisateur U. Typiquement, l’appareil 20 de prestataire de service consiste en un serveur ou un groupe de serveurs opérés par un prestataire de service SQ, éventuellement associé à d’autres équipements. Le prestataire de service SQ peut être un marchand, une banque etc... Typiquement, l’appareil 30 de certification consiste en un serveur ou un groupe de serveurs opérés par un organisme de certification CERT, éventuellement associé à d’autres équipements. L'organisme de certification CERT peut être une banque, un opérateur mobile ou tout autre type d'organisme susceptible d'émettre une clé CL et de proposer aux prestataires de services SQ un moyen standardisé conforme à celui décrit ci-dessous.
Nous allons maintenant décrire, en référence aux figures 2 et 3, les principales étapes mises en œuvre lors du procédé de sécurisation d’opérations selon l’invention dans un mode particulier de réalisation. Ce procédé peut être mis en œuvre par le système représenté à la figure 1 . La figure 2 représente, sous forme d’ordinogramme, les principales étapes du procédé et la figure 3 représente, de manière schématique, les principales interactions entre les éléments du système lors du déroulement du procédé.
Selon certains modes particuliers de réalisation, le procédé représenté sur la figure 2 peut comporter une phase ou étape préalable (EP) au cours de laquelle une clé CL est affectée à l’utilisateur U. Cette étape préalable EP peut, notamment, comprendre une première sous-étape F10 selon laquelle l’utilisateur formule auprès de l’organisme de certification une requête tendant à produire (générer) une clé CL et l’affectation à l’utilisateur de cette clé CL. L’organisme de certification CERT transmet la clé CL à l’utilisateur dans une sous-étape F20 et typiquement transmet aussi à ce dernier un dispositif DC générateur de codes dynamiques. A titre alternative, l’utilisateur possède déjà un dispositif générateur de codes dynamiques et à ce stade n’obtient de l’organisme de certification CERT que la clé CL générée. Lorsque l’utilisateur U souhaite entreprendre une transaction ou autre opération, notamment une opération sensible, en employant sa clé CL, l’utilisateur formule une demande DEM_OP auprès du prestataire de services SQ (F30) lors d’une première étape E1 du procédé.
Ensuite, lors d’une deuxième étape E2 du procédé, l’appareil 20 de prestataire de service transmet à l’appareil 30 de certification une requête REQ_VAL(CL) de validation de l'opération demandée, ladite requête indiquant la clé CL associée à l’utilisateur U (F40).
Lors de la troisième étape E3 du procédé, l’appareil 30 de certification identifie l’utilisateur associée à la clé CL, par exemple en réalisant une recherche dans une base de données au moyen de la clé CL. Selon certains modes de réalisation de l’invention l’appareil 30 de certification récupère (F50) des données de contrôle, enregistrées lors de la phase préalable EP, associées à l’usage de la clé CL et effectue certains contrôles, par exemple par rapport à des informations concernant l’opération demandée par l’utilisateur U, ces informations ayant été transmises à l’appareil 30 de certification par l’appareil 20 de prestataire de service (ex. dans un message qui comporte la clé CL). Eventuellement, l’appareil 30 de certification peut d’ores et déjà transmettre à l’appareil de prestataire de service un message indiquant que l’opération demandée est en-dehors des usages permis pour la clé CL (F55). Ensuite, l'appareil 30 de certification émet une demande REQ_CC de code dynamique, destinée à l’utilisateur associé à la clé (CL) (F60). Bien entendu, si l’appareil de certification a déjà indiqué au prestataire de services SQ que l’opération demandée n’est pas valable le procédé peut s’arrêter à l’étape F55. Dans un système selon l’exemple représenté sur la figure 1 , l’appareil 30 de certification peut transmettre la demande REQ_CC au poste utilisateur 10, sous la forme d’un formulaire qui sera affiché à l’écran.
Suite à réception de la demande REQ_CC transmise par l’appareil 30 de certification, et lors de la quatrième étape E4 du procédé, le dispositif DC générateur de codes dynamiques associé à la clé CL de l’utilisateur produit une première version CC1 du code dynamique (F70). Selon certains modes de réalisation de l’invention, le dispositif DC générateur de codes dynamiques est doté d’un moyen d’impulsion (ou autre moyen actionnable par l’utilisateur) et le code dynamique est généré suite à l’actionnement de ce moyen d’impulsion par l’utilisateur. S’ensuit une étape (F80) de transmission d’un message TX_CC1 comprenant la première version CC1 du code dynamique à l’appareil 30 de certification.
Le procédé se termine avec une cinquième étape E5 au cours de laquelle l’appareil (30) de certification acquiert une seconde version (CC2) du code dynamique et compare celui-ci avec la première version du code et, à condition que les première et seconde versions (CC1 ,CC2) du code dynamique correspondent, transmet à l’appareil 20 de prestataire de service un signal TX_RES indiquant la validation de l’opération demandée par l’utilisateur U (F100). Bien entendu, en cas de résultat négatif de la comparaison, l’appareil 30 de certification peut transmettre au prestataire de services SQ un message indiquant que l’opération demandée n’a pas été validée. Eventuellement d’autres renseignements peuvent être transmis à l’appareil de prestataire de service à la fin de l’étape E5. Par ailleurs, le résultat de la comparaison (F90) peut procurer la réalisation d’autres opérations par l’appareil 30 de certification (ex. la mise à jour du montant d’un crédit associé au code CL).
Nous allons maintenant exposer plus en détails différentes manières de réaliser les étapes EP et E1 à E5 représentés sur les figures 2 et 3.
L’Etape Préalable (EP¾
Lors de l'étape préalable EP du procédé, l'organisme chargé de certifier les opérations (ex. les transactions ou les connexions) fournit à l'utilisateur une clé CL associée à un dispositif DC de codes à cryptogramme dynamique CC (ce dispositif DC étant soit déjà détenu par l’utilisateur soit fourni à l'utilisateur par l’organisme de certification lors de l’étape EP).
Moyens d’obtention de la clé CL associé à l’utilisateur
A cet effet, selon un mode de réalisation préféré, ledit utilisateur doit en premier lieu s'inscrire auprès dudit organisme de certification CERT et lui fournir différents éléments : son nom, son prénom, le ou les moyens de le contacter (tel, mail), etc.
L'inscription peut se faire en ligne (éventuellement à l'aide d'un procédé tel que celui de l’invention) ou en physique, comme pour une agence bancaire traditionnelle. Elle peut également être mixte : par exemple une 1ere phase d'inscription en ligne et une seconde phase après livraison d’un dispositif DC physique à son adresse pré-indiquée (par exemple son adresse postale, dans un lieu convenu tel qu'un relais, ...).
Les données (utilisateur) associées à la clé CL Selon un mode de réalisation, l'utilisateur demande une clé CL à son organisme de certification et précise différents paramètres, correspondant à différents types d'informations que l'organisme de certification liera à ladite clé CL d'une façon ou d'une autre, par exemple grâce à une base de données, ou tout autre moyen de gestion de la persistance de ces données, dédié dudit organisme de certification. La liste des types d'informations peut être très variable, et nous n'en citons ici qu'un sous ensemble non exhaustif. Certaines des informations serviront de données de contrôle mais d’autres correspondent à des métadonnées associées à l’utilisateur (bien entendu certaines informations peuvent remplir les deux rôles).
Par exemple, les types d'informations peuvent être relatifs :
• Aux utilisateurs de la clé CL :
* Si aucun nom n'est précisé, le lien peut être fait avec le nom de l'utilisateur U-lnit tel qu'indiqué lors de son inscription (tel qu'indiqué lors de la description du début de l'étape préalable).
* L'utilisateur peut préciser un autre nom tiers, ou un alias (nom qu'il souhaite lier à cette clé CL).
* L'utilisateur peut éventuellement préciser plusieurs noms, si la clé a vocation à être partagée (un peu à l'image d'un compte joint).
Pour ces différents cas, en reprenant l'exemple du lien à l'aide d'une base de données, l'organisme de certification gérera l'association de la clé CL avec son propriétaire U-lnit et la ou les différentes identités complémentaires U-Comp ci-dessus.
Il est possible d’ajouter des données complémentaires à chaque identité U-comp (facultatif), selon, par exemple la ou les législations en vigueur dans le pays concerné :
* L'âge de U-Comp (si la clé est par exemple attribuée à un enfant mineur de U-lnit) ou en variante le statut correspondant (mineur ou majeur, ...). Par défaut ce paramètre est initialisé par celui de U-lnit.
* S'il s'agit d'une personne morale ou physique (plus les précisions éventuelles : raison sociale ...).
* Le ou les identités de communication associées, éventuellement distinctes de celles de U-lnit (par exemple numéro de tél, identifiant de messagerie, email, ...), et en variante le moyen associé (envoi par SMS par exemple). • Aux autorisations de divulgation à SQ des informations liées à la clé CL :
En tant qu’exemples non exhaustifs, on peut citer l’autorisation ou non de divulgation du nom, prénom, âge, adresse, un moyen de communication, . Une autorisation par défaut peut être fournie sur tout ou partie de ces données en l'absence de précision. Ladite diffusion des données dont l'utilisateur accepte la divulgation peut par exemple non exhaustif être effective à l’étape E5 du procédé et dispositif.
• Aux autorisations d'usage (par SQ) liées à la clé CL
Autorisations données toujours à SQ. Par exemple non exhaustif, ces autorisations d'usage sont utilisées dans les cas d'usage d'antispam, décrits en fin du présent document.
• Aux opérations sécurisées / usages de la clé CL
De façon facultative, au moins un usage spécifique donné de la clé CL peut être précisé. Les exemples d'usages sont nombreux.
A titre d’exemple non exhaustifs, les usages sont :
* une inscription et/ou une connexion à un site Internet ou une application,
* un abonnement à un service quelconque (journaux ou magazine papier, ...),
* un paiement générique physique ou en ligne,
* un paiement dans au moins un magasin spécifique (tel magasin de telle chaîne de supermarchés par exemple).
* un paiement en ligne sur au moins un site marchand.
Selon les demandes de l'utilisateur, une clé CL peut ainsi voir son usage restreint à des formalités d'inscription et de connexion ou de paiement en ligne, ou les 2, éventuellement sur un site précis ...
Une clé peut donc avoir plusieurs usages (à ne pas confondre avec les autorisations d'usage) : par exemple inscription, connexion à un site et paiement en ligne sur ledit site.
En l'absence de restriction d'usage, la clé CL peut servir à tous les usages possibles pour l'utilisateur concerné. Ces restrictions d'usage sont en effet facultatives. L'utilisateur peut n'utiliser qu'une seule clé pour se connecter / s’inscrire sur différents sites ou services sans préciser lesquels, voir payer sur lesdits sites s'il s'agit de sites marchands. Mais il ne pourra pas alors bénéficier des intérêts cités ci-dessus et ni ceux qui seront précisés par la suite.
• Aux autres restrictions lors de l’usage de la clé CL
De façon facultative, au moins une restriction peut être définie en relation avec un usage de la clé CL. Les exemples de restrictions sont nombreux et seulement quelques-uns sont cités ci-après :
* restrictions en termes de durée, ou de période de validité de la clé CL.
Eventuellement, il peut y avoir plusieurs périodes de validité associées à ladite clé.
* restrictions en termes de zone de géolocalisation
Ces restrictions peuvent être apportées, par exemple pour limiter les utilisations d'une clé CL à une zone géographique donnée, par exemples non exhaustifs au niveau d'un pays ou au niveau de la localisation géographique d'un magasin précis.
* restrictions en termes de montant (en relation avec des usages de type paiement)
Par exemple, un montant maximum, et éventuellement un montant par période (avec éventuellement de montants distincts selon les périodes) peuvent être précisés.
A ce niveau également, il est possible de préciser si les paiements se font uniquement à l'acte ou si des abonnements sont acceptés (les restrictions en termes de durée et périodes décrites ci-avant permettent d'en limiter la portée).
Moyens pour réaliser le paramétrage des informations de contrôle associées à la clé CL
Des moyens classiques peuvent être employés pour permettre à l’utilisateur de préciser ses souhaits lors du paramétrage des informations de contrôle. Il n'entre pas dans le cadre de cette demande de brevet de préciser tous les moyens connus mais, par exemple non exhaustif, lors d'une demande de clé CL, et ce quel que soient les moyens mis en oeuvre pour ladite demande (physique dans une agence, par téléphone, en ligne via des formulaires de l'organisme de certification), l'utilisateur peut préciser les données relatives à ladite cible, éventuellement à l'aide de listes de références disponibles au niveau de l'organisme de certification.
En tant que d’autres exemples non exhaustifs : * Dans le cas d'une clé destinée à un paiement en ligne, l'utilisateur peut préciser l'option paiement en ligne.
* Dans le cas d'une clé destinée à un paiement pour une personne, l'utilisateur peut préciser l'option paiement générique.
Selon un autre exemple, lors d'une demande en ligne, l'utilisateur peut préciser "inscription à un service", puis sélectionner dans une liste de services connus, voire rajouter manuellement le nom (et éventuellement l'url correspondant au nom de domaine dans le cas d'un site Internet) dudit service ou site si celui-ci n'est pas dans la liste des sites connus.
En variante, ledit service correspondant à SQ fourni lui-même, préalablement à l'étape préalable, le nom ou code nom sur lequel il est référencé chez les organismes de certifications, dans le cas où une liste de référence de ces services existe.
Les paramètres peuvent aussi être présentés en dépendance les uns des autres.
Ainsi, sans restriction préalable, l'utilisateur peut formuler une demande de restriction en termes de montant de paiement pour pouvoir préciser lesdits montants et modalités associées. Cette option n’est automatiquement proposée au client que si pour sa clé CL un usage de paiement a été indiqué.
La combinaison de ces différents types de données de paramétrage liés à la clé CL peut nécessiter des contrôles aux étapes ultérieures: par exemple une clé CL permettant le paiement physique uniquement dans tel magasin peut nécessiter tout ou partie des contrôles suivants lors des étapes ultérieures: process de paiement non en ligne, transmission de données du vendeur pour vérifier leur concordance avec celles en regard de la clé, géolocalisation éventuelle du vendeur à contrôler par rapport à celle en regard de la clé, .... Un avantage du procédé et système selon ce mode de réalisation de l’invention, en dehors de son extrême paramétrabilité, est qu’à aucun moment le vendeur, ou le pirate ne connaît les données de contrôle associées à ladite clé.
Par ailleurs, comme nous l’avons évoqué ci-dessus, un avantage important de ces paramètres découle des combinaisons que l’on peut en faire.
Le moment du paramétrage des informations utilisateur associées à CL
A noter que, selon certains modes de réalisation de l’invention, l'utilisateur peut non seulement modifier les paramètres associés à une clé CL donnée au cours de l’étape préalable EP mais aussi à tout moment. L’utilisateur peut réaliser la modification voulue en se connectant à son compte auprès de l'organisme de certification, puis en sélectionnant la clé CL voulue, puis en modifiant lesdits paramètres.
La clé CL
Selon un mode particulier de réalisation de l’invention la clé CL est le numéro d’une carte bancaire, éventuellement couplé à une date de fin de validité, et le code CC est ledit code à cryptogramme dynamique. L'entité tenant le rôle d'organisme de certification est alors un organisme bancaire.
Pourtant, malgré tous ses intérêts (technologie mature, acteurs en place, identification automatique de l'organisme de certification (ici la banque) via le numéro de carte, ...), cette implémentation présente quelques inconvénients: les API (d’après l’anglais « application programming interface », ou interface de programmation applicative) entre les sites marchands et leur banque sont déjà en place et sont distinctes selon les organismes bancaires (qui s'échangent ensuite les données de transaction de façon normalisée), pas d'adaptation pour la validation de données tierces aux données marchandes, retour d'informations différentes de celles envisagées par le procédé et dispositif décrits ici ....
Selon un mode de réalisation, la clé CL fournie par l'organisme de certification ne correspond pas forcément au numéro d'une carte bancaire, mais est une clé unique destinée audit utilisateur. Cette clé est composée d'un nombre prédéfini de caractères successifs (ex. chiffres et/ou lettres). En variante, cette succession de symboles peut incorporer également des caractères spéciaux.
Cette clé unique peut être fournie électroniquement à l'utilisateur, ou sous toute autre forme. Elle peut ainsi éventuellement être matérialisée sur une carte plastique à l'image des cartes bancaires.
Selon un mode de réalisation particulièrement, à l'image des cartes bancaires, la clé CL incorpore dans le code de cette clé un moyen permettant d'identifier l'organisme de certification, ce qui permet de normaliser cette succession de caractères, et permet des APIs standardisées indépendantes des organismes de certifications. Un autre avantage de cette variante est bien entendu que lesdites clés CL sont globalement uniques : pas de doublon possible sur le marché. Par exemple, si ladite clé était composée de 16 caractères, les 12 premiers peuvent être dédiés à la clé spécifique de l'utilisateur et les 4 derniers à l'identification de l'organisme émetteur. Auquel cas, ladite liste des organismes de certifications et leur code est unique quel que soit la clé CL.
Le cas des organismes bancaires proposant des clés CL visualisables sur une carte bancaire et incorporant éventuellement un dispositif de cryptogrammes dynamiques étant connu, les explications suivantes sont positionnées par rapport à ces cas pour mieux expliquer les intérêts de la solution.
Selon une 1ère variante, la clé CL correspond à un numéro de carte bancaire, éventuellement combiné à une date de fin de validité, et le dispositif DC de codes à cryptogramme dynamique CC correspond à celui disponibles sur les cartes à cryptogramme dynamique, avec le code à 3 chiffres (dit code CW) changeant périodiquement, selon une méthode et avec des moyens déjà expliqués ci-avant. Nous avons toutefois déjà évoqué les inconvénients de cette 1ere variante, relativement en particulier à la rigidité des procédures déjà en place et à leur faible évolutivité.
Selon une autre variante, la clé CL n’est pas un numéro de carte et peut comporter une succession de lettres et ou de chiffres, avec certaines séquences et positions normalisées afin en particulier de reconnaître l'organisme de certification comme déjà indiqué. La clé est par exemple communiquée à l’utilisateur, électroniquement ou par tout autre voie par l'organisme de certification. En variante, elle est apposée et visible sur un support quelconque, tel qu'une carte plastifiée par exemple.
Comme exposé par la suite, selon un mode de réalisation, des éléments de codage de la clé CL peuvent permettre de retrouver de façon certaine l'organisme de certification émetteur de ladite clé CL.
Selon un des modes de réalisation, des éléments de codage de la clé CL (par exemple non exhaustif le neme et ou le 12ème caractère de la clé) permettent de préciser des restrictions d'usage particulières de ladite clé quand il y en a : par exemple non exhaustif, une clé n'ayant pas de restriction aurait A en nème caractère tandis qu'une clé ne pouvant être utilisée que pour une demande d'inscription aurait I en 1 1eme caractère.
Un dispositif DC peut être associé à plusieurs clés CL L'utilisateur peut indiquer des données valables pour un usage par défaut, puis demander la création, par l’organisme de certification, de différentes clés avec des données distinctes (en particulier s'il destine une desdites clés à un tiers, tel qu'un enfant par exemple) ou partiellement distinctes.
Disposer pour toutes ses clés, ou pour une partie d'entre elles, d'un seul dispositif DC simplifie grandement la tâche de l’utilisateur (pas besoin d'avoir 5 cartes (ou bagues, montres, ...) avec chacune un de ces dispositifs DC). En variante, il peut disposer d'un nombre limité de dispositifs DC : par exemple, un premier destiné à ses comptes auprès de différents services et un autre destiné à ses moyens de paiement.
Selon un autre mode de réalisation, plusieurs dispositifs DC de l'utilisateur sont combinés sur un même support. Par exemple non exhaustif, un support tel qu'une bague à écran dispose de 2 dispositifs DC et d’écran d'affichage respectif, un 1er écran destiné à l'affichage des clé CC du 1er dispositif correspondant par exemple à des clés d’accès à des services variés, un second écran destiné à l’affichage des clé CC du 2ème dispositif correspondant par exemple à des clés d’accès à des paiement en ligne.
Selon une autre implémentation possible, ledit support ne dispose que d’un seul écran d’affichage et un moyen tel que par exemple non exhaustif un bouton poussoir permet de passer d'un type d'affichage à l'autre, ce moyen étant distinct d’un moyen d'impulsion éventuellement présent dont se sert l’utilisateur pour générer la prochaine valeur du code dynamique. Auquel cas, un indice visuel, ex. un symbole ou une couleur, au niveau de l'affichage permet de distinguer chacun des 2 dispositifs DC.
Selon une 1ere variante, ledit dispositif commun DC dispose d'un moyen pour afficher les différentes clés qu'il supporte, afin que l'utilisateur sélectionne la clé voulue pour obtenir le code CC en cours (ou impulsé) correspondant. Cette variante complexifie toutefois le dispositif DC et en rend en outre l'usage complexe : Si par exemple une clé CL comprend une série de 16 chiffres et ou lettres, il faut que l'utilisateur se remémore à quel usage correspond chacune de ces suites un peu rébarbatives.
Dans un mode de réalisation préféré, le dispositif DC génère un code CC selon une des implémentations détaillées ci avant, indépendamment du choix d’une clé. Le lien entre ce dispositif DC et une ou plusieurs clés CL de l'utilisateur est alors conservé uniquement au niveau des bases de données de l'organisme de certification. Cette dernière variante, outre la suppression des inconvénients cités ci-avant, présente comme autre intérêt pour l'utilisateur de pouvoir à tout moment rajouter ou supprimer de nouvelles clés CL liées à ce dispositif DC, ceci sans avoir à modifier ledit dispositif (il suffit d'effectuer l'ajout ou la suppression dudit lien entre CL et DC dans les bases de l'organisme de certification).
Par exemple, par ce biais, un utilisateur peut disposer d'une bague dotée d'un tel dispositif DC à impulsion, générant à la demande un code cryptogrammique CC, et utiliser ledit code dans les étapes suivantes du procédé et dispositif pour
a) Sécuriser une inscription ou une connexion sur un site A auquel correspond une 1ere clé CL
b) Sécuriser une inscription ou une connexion sur un site A ou B auquel correspond une 2eme clé CL pour laquelle il diffuse d'autres données d'identité (un alias par exemple)
c) Un paiement en ligne en indiquant une 3eme clé CL (et en permettant au site considéré de la conserver pour les échanges suivants),
d) Un paiement en ligne avec le numéro de sa carte bancaire qui tient alors lieu de 4eme clé CL, le code CW n'ayant même plus besoin d'être inscrit au verso de ladite carte (puisqu'il est déporté dans notre exemple sur la bague de l’utilisateur (selon un autre exemple d'implémentation, le dispositif DC est incorporé dans la carte bancaire et est utilisé pour tous les exemples d’usages).
e) Sécuriser sa connexion au site de la banque ayant émis ladite carte, ce qui correspond à une 5eme clé CL
La Première Etape : E1
Au cours de la première étape, E1 , l'utilisateur demande la réalisation d’une opération auprès d’un appareil d’un service quelconque SQ. Les opérations visées sont très variées. En voici certains exemples données à titre non limitatif : une demande de création de compte, une demande d’initiation de transaction, une demande d’accès à un local ou à une ressource physique ou numérique (ex. demande d’ouverture ou de démarrage d’une voiture, demande d’entrée de maison particulière ou d’entreprise), etc.. A cette occasion il indique ou associe sa clé CL et l'organisme de certification. Selon la variante selon laquelle la clé CL inclut le code de l'organisme de certification, l’utilisateur n’a pas besoin de fournir cette information à l'occasion de cette étape E1.
Le type d'opération (création de compte, connexion à un compte, début d'une transaction de paiement, ...) peut être déterminé implicitement lors de cette étape E1. Si par exemple l'utilisateur clique ou appuie sur un bouton de type "Créez votre compte", l’appareil du service SQ déterminera qu'il s'agit d'une création de compte, et cette information sera utilisée dans la suite du procédé.
Selon un mode de réalisation, une API normalisée est mise à disposition de l’appareil du service SQ par l'organisme de certification et permet à celui-ci de sélectionner un type d'opération, puis de fournir les informations complémentaires requises en fonction de ce type d'opération. Selon cette variante, cette même API servira pour les différents échanges de données entre l’appareil de SQ et l'organisme de certification lors des étapes ultérieures du procédé.
1er exemple : l'utilisateur sélectionne une opération de type Création de compte auprès de l’appareil du service SQ.
La seule information utile à fournir par l'utilisateur est la clé CL. En fonction de la configuration effectuée à l'étape préalable, la clé CL est soit destinée uniquement à des usages au niveau du service SQ, soit à des usages plus généraux dont le service SQ. Mais comme on le verra plus loin à l'occasion de la description d'autres types d'opérations, se limiter à cette seule information peut être problématique pour l'utilisateur étant donné que cela lui impose de retenir la composition de ladite clé associée à son usage sur le service SQ.
De ce fait, en plus de la clé CL, l’appareil du service SQ peut proposer à l'utilisateur de remplir un formulaire comportant des informations complémentaires, telles qu'un identifiant de connexion par exemple. Par exemple non exhaustif, ledit identifiant est un numéro de téléphone personnel ou un email personnel. Selon une autre variante, le formulaire d'inscription inclut d'autres informations telles que par exemple non exhaustif le nom, prénom et par exemple adresse voire une autre donnée de contact dudit utilisateur.
Toutefois, selon un mode de réalisation, ces informations complémentaires sont fournies lors des étapes ultérieures par l'organisme de certification, si l'utilisateur l'a autorisé, et non par l'utilisateur.
2eme exemple : l'utilisateur sélectionne une opération de type Connexion à un compte auprès du service SQ.
A noter que la mise en oeuvre de ce 2eme exemple implique qu'auparavant l'utilisateur ait sélectionné une opération de type « Création de compte » auprès du service SQ, puis enchaîné de façon positive l'ensemble des étapes du procédé selon un mode de réalisation de l’invention relativement à cette création de compte auprès du service SQ à l'aide d'une clé CL appropriée. En clair, il dispose déjà d'un compte auprès de SQ, compte qui a été créé à l'aide du procédé et dispositif décrits.
En variante, si l'utilisateur s'est inscrit audit service SQ via un processus d'inscription classique, pour pouvoir par la suite se connecter à ce même service au moyen du procédé et dispositif décrits, il devra avoir préalablement complété son profil auprès dudit service SQ en rajoutant sa clé CL. Suite à cette mise à jour, l'utilisateur pourra par la suite se connecter à l'aide d’un procédé et système mettant en œuvre l’invention. Auquel(s) cas, pour se connecter audit compte auprès de SQ, l'utilisateur doit indiquer la clé CL liée à ce compte.
Comme nous l'avons vu ci-avant, une telle mise en œuvre nécessite que l'utilisateur se remémore la composition de la clé CL, ce qui si celle-ci se compose de par exemple non exhaustif 16 lettres ou chiffres, n'a rien d'évident. Selon un mode de réalisation, l'utilisateur saisit l'identifiant de connexion personnel qu'il a indiqué à l'occasion de la création de son compte lors d'une opération précédente. Grâce à la mise en œuvre du procédé et dispositif, il n'a pas à saisir de mot de passe à cette étape. L’appareil du service SQ récupère alors la clé CL associée au compte de l'utilisateur dans un de ses moyens de stockage tel qu'une base de données au niveau dudit service SQ, clé CL que ledit utilisateur a indiquée en regard de cet identifiant de connexion à l'occasion de la création de son compte ou lors d'une opération de mise à jour ultérieure de son compte sur ledit service. Les moyens de stockage peuvent être internes ou externes à l’appareil 20 du service SQ.
3eme exemple, l'utilisateur sélectionne une opération de type « Paiement en ligne » après avoir sélectionné un article ou constitué un panier auprès du service SQ.
Deux cas de figure sont à distinguer :
a) La clé CL que l'utilisateur a indiqué pour ledit service SQ sert à la fois pour s'inscrire, et ou se connecter et également au paiement en ligne. Auquel cas, une fois connecté à l’appareil du service SQ comme décrit ci-avant, l’utilisateur n'a rien à indiquer. Il lui suffit à cette étape de valider le montant de son panier ou le montant de la transaction, et d'attendre les interactions issues des étapes ultérieures du procédé. b) L'utilisateur utilise une autre clé CL en guise de moyen de paiement, que cette clé CL soit générique pour tous ses paiements ou ait été à l'étape initiale limitée aux usages sur le service SQ.
Dans le 1er cas, il peut s'agir par exemple non exhaustif du numéro indiqué au verso d'une carte bancaire compatible avec notre procédé et dispositif. Dans les autres cas distincts des cartes bancaires, il peut s’agir d'une clé CL quelconque. Auquel cas, il suffit à l'utilisateur d'indiquer le numéro ou ladite suite de sa clé CL de paiement, et d'attendre les interactions issues des étapes ultérieures.
Contrairement aux procédés et dispositifs de l'état de l'art, l'utilisateur peut sans aucune crainte, en particulier dans les cas distincts des numéros de carte bancaire, faire conserver sa clé de paiement au niveau dudit service SQ, puisque comme nous le verrons par la suite ladite clé sera inutilisable par d'éventuels pirates sans disposer du dispositif DC associé.
Sans compter la sécurisation renforcée de façon drastique, il en résulte aussi une expérience client sans équivalent côté paiement : en lieu et place de la validation d'un montant suivi de la saisie de ses coordonnées bancaires, l'utilisateur n'a à cette étape plus qu'à valider son montant de paiement.
Bien entendu, si le site marchand est limité aux APIs de paiement classique, la solution prévue ici est compatible puisque le même numéro de carte peut servir selon les voies de l'état de l'art antérieur pour accéder à des services marchands non affiliés à notre procédé (il suffira à l'utilisateur de saisir ses coordonnées bancaires de façon classique directement à cette étape: numéro de carte bancaire, date de fin de validité et code CW généré par le dispositif DC), et pour accéder à des services SQ affiliés à notre procédé.
La Deuxième Etape : E2
Au cours de G étape, E2 du procédé, l’appareil 20 du prestataire de service SQ demande à l'organisme de certification la validation de l'opération effectuée à l’étape E1. Cette étape consiste ici à communiquer audit organisme de certification, la clé CL sélectionnée par l'utilisateur à l’étape E1 , et de façon concomitante les données contextuelles correspondant à ladite opération.
Selon un mode de réalisation, ladite transmission des informations est normalisée et s'effectue au travers d'une interface (API) fournie par un organisme tiers OT auquel s'est affilié ledit service SQ pour cette API (cet organisme tiers peut aussi être un organisme de certification, mais la clé CL n'est pas forcément gérée par ce dernier, mais par un organisme de certification quelconque du marché), interface détaillant les procédures d'interactions avec les différents services de certification du marché ainsi que la typologie des données échangées.
Selon cette variante, outre la clé CL associée à l'utilisateur, l’appareil du service SQ fournit de façon normalisée différentes informations en relation avec le type d'opération demandé par l'utilisateur à l’étape E1.
Par exemple, l’appareil du service SQ fournit à l’organisme de certification, la clé CL de l’utilisateur et une codification correspondant à l'opération réalisée. Il peut également fournir une clé KSQ, propre à l’appareil du service SQ.
La codification est par exemple une suite des 3 lettres.
Cette codification est par exemple CRE pour une création de compte, CNX pour une connexion à un compte, "PA Y" pour un paiement en une fois (dit paiement one shot), "PAYn" pour un paiement en plusieurs fois (avec en données associées le nombre de fois, ...), "PAYAb" pour un paiement par abonnement avec en données associées la durée de l'abonnement, le montant périodique ...,
De multiples autres usages sont possibles (par exemple un virement sur un compte tiers ou vers une autre clé). Chaque usage est associé à un code spécifique et à une ou plusieurs informations complémentaires liées au type d'opération (par exemple pour un virement, outre le mot clé de type "VIR", un montant, un compte ou une clé tierce et une indication‘échéance).
A noter que les traitements du programme d'API implémentés au niveau de l’appareil du service SQ permettent également de faire au niveau du service SQ une 1ere série de contrôles, tels que par exemple vérifier la conformité de la clé CL (nombre de caractères, détermination de l'organisme de certification (en fonction du code correspondant inclus dans la clé, ...) et selon la variante détaillée en fin d'étape préalable vérifier si ladite clé est autorisée pour ce type d'opération (également en fonction du code correspondant inclus dans la clé à la position prédéfinie pour ces contrôles ...).
Selon une autre mode de réalisation, la clé CL fournie par l’appareil du service SQ permet au niveau de l'organisme de certification, ou au niveau d’un organisme tiers OT auquel s'est affilié ledit service SQ pour cette API, qui transmettra ensuite les informations recueillies à l'organisme de certification, de récupérer les informations nécessaires au procédé selon l’invention et concernant le service SQ, telles que par exemple le nom du service SQ, l'URL du nom de domaine concerné (ou un identifiant d'application sur un store quelconque, de type Apple Store ou Play store par exemple non exhaustif). D'autres informations par exemple relatives aux coordonnées géographiques dudit service SQ s'il s'agit d'un magasin physique par exemple (informations fournies lors de l'inscription de SQ au service fournisseur de sa clé API) peuvent être fournies à cette occasion.
La personne du métier comprendra que d'autres variantes d'implémentation sont possibles à ce niveau mais non détaillées ici par souci de concision. Par exemple, seule la clé est fournie, et l'organisme de certification demande à l’appareil du service SQ des informations complémentaires.
Selon une 1ere variante d'implémentation, une table de correspondance incluse au niveau des traitements du programme d'API implémentés au niveau de l’appareil du service SQ permet à partir de la détermination de l'organisme de certification correspondant à la clé CL (via la série de codes dédiés au sein de la clé CL) de trouver l'adresse (par exemple non exhaustif de type URL) de l'organisme de certification à interroger. Auquel cas, l'appareil du service SQ interroge directement, de préférence au travers d'un lien sécurisé (par exemple de type https) ledit organisme de certification à l'adresse convenue selon cette table de correspondance en lui transmettant de façon normalisée les informations décrites ci-dessus. Cette 1ere variante est plus rapide, mais nécessite une mise à jour fréquente, de la table de correspondance utilisée par les multiples services SQ.
Selon une autre variante d'implémentation, la demande du service SQ est transmise à l'organisme tiers OT, qui après avoir éventuellement récupéré les informations associées à la clé KSQ API de SQ dans les moyens de stockage dudit service tiers OT, reroute la demande du service SQ, ainsi que l'ensemble des données associées récupérées depuis la demande initiale ou déterminées via l'exploitation des données de la clé API, vers les services de l'organisme de certification correspondant.
La Troisième Etape : E3
Au cours de G étape, E3, du procédé, l’appareil 30 de l'organisme de certification CERT reçoit la clé CL et, éventuellement, les informations associées issues des étapes E1 ou E2, identifie l'utilisateur correspondant à cette clé dans ses bases de données, et transmet à cet utilisateur une demande de fourniture de code dynamique (par exemple en lui transmettant un formulaire de validation).
Cette étape E3 débute par la réception par un moyen de réception conçu à cet effet au niveau de l'organisme de certification, de la demande émanant du service SQ, par l'intermédiaire éventuel du service tiers OT.
Ledit moyen de réception récupère et classe alors les différentes informations contenues dans la requête :
a) Il détermine les données relatives à l'identification du service SQ, données fournies soit lors de l'inscription dudit service SQ au niveau du service OT, soit directement au niveau de l'organisme de certification.
b) Il détermine le type d'opération demandée par analyse du code correspondant (par exemple CRE pour création de compte).
c) En fonction du type d'opération demandée, il récupère également les données complémentaires nécessaires (par exemple non exhaustif, pour une demande de paiement, le montant de la demande) et les informations éventuellement associées (par exemple s'il s'agit d'un paiement en plusieurs fois, du nombre de fois et du montant à chaque échéance, ...).
d) il récupère également la clé CL.
La transmission de ces informations à l'organisme de certification peut se faire en exploitant diverses solutions connues qui ne sont pas toutes détaillées ici. Par exemple non exhaustif, ces informations sont transmises via un formulaire XML ou un fichier json, ou encore en mode Post depuis l'organisme tiers OT vers l'organisme de certification. De multiples autres méthodes plus ou moins sécurisées sont possibles. Un moyen d’interrogation de l’appareil 30 de l'organisme de certification est alors mis en œuvre pour déterminer par interrogation de ses moyens de stockage (des bases de données par exemple) à quel utilisateur (ou alias) appartient la clé CL fournie. Les différentes informations associées décrites plus haut, sont récupérées par ce moyen d’interrogation.
Sont en particulier récupérées à ce niveau l'ensemble des données particulières associées à l'utilisateur de la clé CL (le nom ou alias, le ou les moyens de communication associées, ...) indiquées pour cette clé CL à l'occasion de l'étape préalable. Sont également récupérées les informations relatives aux autorisations de divulgation ainsi que les restrictions diverses en termes d'usage en particulier.
Un moyen de contrôle est alors mis en œuvre pour contrôler les données transmises à l'occasion des étapes E1 et E2 par rapport aux données relatives en particulier aux usages et restrictions d'usages acceptées pour ladite clé CL. Les analyses et comparaisons possibles sont connues et ne sont pas toutes détaillées ici.
* Par exemple non exhaustif, ce moyen de contrôle permet de vérifier qu’une codification de transaction associée à la clé CL est conforme à ou aux transactions autorisées pour cette clé CL dans les moyens de stockage de l'organisme de certification.
* Selon un autre exemple, si la clé CL au niveau des moyens de stockage de l'organisme de certification est associée à un site ou à une application précise SA, ce moyen de contrôle vérifie que les données complémentaires associées à la clé CL et relatives au service SQ correspondent bien audit site ou application SA.
* Selon un autre exemple encore, le moyen de contrôle vérifie que le plafond de paiement de l'utilisateur associé à ladite clé CL, éventuellement sur une période donnée, n'est pas dépassé.
La personne du métier saura comment se servir de moyens connus pour implémenter les mesures indiquées ci-dessus et ils ne seront, donc, pas détaillés ici, y compris : la comparaison des libellés et / ou de montants, la référence des 2 côtés (du côté de GARI et du côté de l'organisme de certification) à une base de données centrale des services SQ possibles, etc....
Si les résultats des analyses et comparaisons effectuées par ce moyen de contrôle ne sont pas conformes à celles attendues, le procédé est stoppé et le service SQ est informé de l'échec de la transaction.
Dans le cas inverse, le procédé se poursuit et un moyen de sélection permet de sélectionner des coordonnées de communication associée à la clé CL de l'utilisateur, et éventuellement un moyen de communication associé, et génère l'envoi vers l'utilisateur d'un formulaire de validation.
Selon une autre variante possible mais moins sécuritaire, le moyen de communication vers l'utilisateur se fait via des coordonnées de communication (email, numéro de mobile de l'utilisateur, ...) indiquées par l'utilisateur au niveau du service SQ et transmis par ce dernier à l'occasion de la étape E2 .
Selon un mode de réalisation, des données complémentaires et relatives à la demande transmise par le service SQ sont associées audit envoi. Il peut par exemple s'agir d'une série d'informations qui permettent lors de l’étape E4 d'indiquer à l'utilisateur que le formulaire de validation est lié à une demande de création de compte de tel service, ou de connexion à tel service, ou encore de paiement de tel montant pour tel service, pour reprendre les 3 exemples déjà évoqués ci-avant.
Selon un autre mode de réalisation, des données complémentaires et relatives à des restrictions d'usage liées dans les bases de stockage de l'organisme de certification à la clé CL, sont associées audit envoi. Il peut par exemple non exhaustif s'agir, si la clé CL est liée à une restriction d'usage sur une zone géographique précise (par exemple lié à un magasin physique), d'une requête de contrôle de la géolocalisation de l'utilisateur.
La Quatrième Etape : E4
Lors de l’étape, E4, le poste 10 de l’utilisateur réceptionne la demande de fourniture du code généré de manière dynamique. Par exemple, au niveau de son poste (téléphone portable, tablette, etc.) l’utilisateur reçoit et puis complète un formulaire avec un code cryptogrammique généré par son dispositif DC associé à sa clé CL.
Comment l’utilisateur reçoit la demande de CC
Il y a plusieurs manières pour l’appareil de certification de formuler sa demande de code dynamique et pour présenter cette demande au niveau de l’utilisateur notamment sur un poste de l’utilisateur (ex. téléphone portable, PC, tablette). Dans l’exemple décrit ci-dessous, l’appareil de certification transmet au poste utilisateur un formulaire de validation. Il convient de noter que l’invention n'est pas être limitée par rapport à cette manière de présenter la demande de code dynamique.
Un moyen de réception permet de réceptionner le formulaire de validation et les données complémentaires éventuelles associées, puis de présenter à l’utilisateur ledit formulaire de validation. De nombreux procédés connus permettent ce type de réception et affichage. Selon un 1er exemple, l'utilisateur reçoit un email en provenance de l'appareil de certification, email incluant un lien relatif au formulaire. Le mail peut contenir lui-même les informations complémentaires relatives à la transaction.
Selon un 2eme exemple, l'utilisateur reçoit un SMS en provenance de l'appareil de certification, email incluant un lien relatif au formulaire. Le SMS peut contenir lui-même les informations complémentaires relatives à l’opération.
Selon un 3eme exemple, l'utilisateur reçoit sur sa messagerie instantanée un message incorporant le formulaire, et éventuellement les détails liés à la transaction.
Selon un 4eme exemple, à l'instar des formulaires de validation lors de certaines transactions financières, l'API entre le service SQ et l'appareil de certification, par l'intermédiaire éventuel du service OT déjà cité, coopère afin que le formulaire de validation soit transmis à l’appareil du service SQ et affiché à la suite (quelques secondes au maximum) de la demande de l'utilisateur au niveau du dispositif via lequel l’utilisateur a formulé sa demande, sans que celui-ci ait à ouvrir une autre application.
Selon un 5eme exemple un formulaire intégré à un robot (« bot » en anglais) de service marchand est transmis à l’utilisateur. Le formulaire peut ne comporter qu’une zone de saisie et un bouton de validation. En variante, il peut comporter une zone textuelle rappelant le contexte de la demande (par exemple, demande de création de compte sur tel service, ou demande de paiement en 3 fois de tel montant sur tel service, ...).
A noter que dans le cadre des paiements en ligne, un des avantages d’un procédé selon l’invention, au moins du point de vue de l'utilisateur, est la suppression du temps minimal de réponse des procédés connus (durée de validité associée à un code ...). Une implémentation similaire à celle des 4eme et 5eme exemples est particulièrement adaptée, pour des demandes nécessitant une réponse rapide. Par contre, si l’opération demandée accepte un délai conséquent, une implémentation similaire à celle des exemples 1 à 3 indiqués ci-dessus sont possibles (envoi par mail, ...).
Demande de CC accompagnée d’une demande de renseignements complémentaires
Selon une autre mode de réalisation, en dépendance de différents paramètres fournis conjointement à l'envoi du formulaire de validation en début de l’étape E4, le formulaire de validation n’est affiché qu’après acceptation de certaines conditions par l'utilisateur.
Par exemple non exhaustif, si une restriction d'usage de la clé CL est associée à une zone géographique particulière, l'affichage dudit formulaire de validation est conditionné à l'acceptation par l'utilisateur d'accéder à sa position géographique (activer la fonctionnalité de géolocalisation s'il s'agit d'un mobile, ...) En cas de refus, le procédé s'arrête donc à cette étape.
En cas d'acceptation, les informations ainsi recueillies sont transmises en parallèle des données saisies sur le formulaire de validation.
En variante, l'appareil de certification demande une géolocalisation sur un terminal de l'utilisateur distinct physiquement du dispositif DC de génération de codes (ce second terminal ayant été relié à l'utilisateur durant la phase préalable EP (ou mis à jour plus tard, auprès de l’organisme de certification). Selon une autre variante, l’organisme de certification peut demander de façon aléatoire la géolocalisation du poste de l’utilisateur ou une autre preuve d'identité (empreinte, ...), tout ceci étant conforme aux directives DSP2.
En variante, en cas de refus, ledit formulaire est affiché, mais aucune donnée associée n’est envoyée en fin de l’étape E4, ce qui provoque un refus de la demande au cours de l’étape E5.
Une fois le formulaire affiché à l'attention de l'utilisateur, ce dernier peut le remplir à l'aide du code CC issu de son dispositif DC associé à sa clé CL, selon les différentes variantes d'implémentations dudit dispositif DC détaillées à l'étape préalable.
Le code généré de manière dynamique
Le terme cryptogramme dynamique réfère pour sa définition de l'état de l'art aux codes dits cryptogramme à 3 chiffres visibles au dos des cartes bancaires du marché. Ledit code est composé de données (3 chiffres dans le cas des cartes bancaires) non incorporés dans la bande magnétique desdites cartes et permettant en les fournissant séparément de sécuriser une transaction.
La technologie des codes dynamiques limite un des principaux risques liés au piratage en ligne du numéro de carte et de son cryptogramme, en faisant varier celui-ci par période (demi-heures, heures ...) : un éventuel pirate ayant récupéré les différentes informations nécessaires au paiement sur internet (numéro de carte, date d’expiration et cryptogramme visuel) n'aura en effet que très peu de temps pour utiliser ces données avant que le cryptogramme ne devienne obsolète. Le procédé permettant de vérifier par la suite la validité dudit code est expliqué à l'étape E5.
Comment obtenir la 1ère version du code, CC1 Par exemple non exhaustif, selon l'implémentation la plus simple, l'utilisateur saisit le code CC actuellement affiché sur son dispositif DC.
Concrètement, dans l'état de la technique, des cartes bancaires à cryptogramme dynamique intègrent un écran e-paper (papier électronique) inséré dans l'épaisseur de cette carte, une mini-batterie pouvant durer 3 ans (durée de vie de ces cartes) et une antenne NFC. Le microcontrôleur impulsé par l’horloge, génère un cryptogramme toutes les demi-heures. Le code généré est ensuite envoyé vers l’écran LCD e-paper et reste affiché jusqu’au moment de la génération du prochain code afin de pouvoir être lu par l'utilisateur à tout moment.
Selon un autre exemple, l'utilisateur demande l'affichage du code CC1 en appuyant sur un bouton poussoir de son dispositif DC, ou en scannant son empreinte sur ledit dispositif, ... ce qui déclenche le calcul dudit code CC1 par le dispositif DC, et son affichage consécutif sur la zone d'affichage dudit dispositif DC.
Plusieurs méthodes de génération de code sont possibles et il n'entre pas dans la présente demande de brevet de décrire ces méthodes. Il peut par exemple non exhaustif s'agir d'un procédé cryptogrammique prenant en compte plusieurs données comme un numéro de carte, un timestamp et un secret partagé entre la carte et l’émetteur, ou encore une liste de cryptogrammes précalculés intégrée dans la mémoire afin diminuer le coût de revient du dispositif.
Le dispositif DC peut être implémenté de diverses manières, non seulement sous forme de carte à cryptogramme dynamique, mais aussi inséré dans un dispositif dédié à la production de codes ou bien de manière dématérialisé, par exemple sous forme de logiciel, code ou appli téléchargé sur au moins un dispositif personnel DP de l'utilisateur tel que son PC ou son téléphone mobile, à condition que ledit dispositif dispose d'un 1er sous moyen de génération des cryptogrammes CC selon les spécifications voulues, et d’un 2eme sous moyen de présentation / affichage desdits cryptogrammes CC à l'utilisateur.
Selon un mode de réalisation préféré toutefois, ce dispositif est un dispositif séparé des moyens de connexion à Internet classique, et est fourni par l'appareil de certification au client. Par exemple non exhaustif, le dispositif DC incorporant des moyens de génération des cryptogrammes et de présentation / affichage peut ainsi être incorporé dans un support tel qu'une carte plastifiée, une montre, une bague un bracelet... ces types de support devant alors disposer d'un dispositif d'affichage permettant de visualiser le code cryptogrammique en cours. De tels objets ont comme principaux intérêts de pouvoir être toujours disponibles et accessibles par l'utilisateur, et ce de façon distincte des autres moyens d'interactions avec les services en ligne.
Le principe de fonctionnement est conforme à ceux de l'état de l'art déjà présenté ci- avant.
Le code cryptogrammique généré peut être une suite de lettres et ou de chiffres, voire inclure quelques caractères spéciaux. Un des grands avantages de ce procédé, outre la sécurisation accrue des processus l'utilisant, consiste en la simplification côté utilisateur. Ce besoin de simplification favorise le choix de suites relativement courtes, par exemple entre 3 et 6 chiffres et/ou lettres successives, à l'instar des codes générés par les cartes bancaires à cryptogramme dynamique qui se limitent à une succession de 3 chiffres (cette limitation étant toutefois liée à la compatibilité avec les codes de confirmation à 3 chiffres des autres cartes bancaires).
Moyen de déclenchement
Selon une variante, l'affichage du code CC nécessite un moyen dit de déclenchement ou d'impulsion (appuyer sur un bouton par exemple) qui lance l'affichage du code.
Selon une autre variante, outre cet affichage, ledit moyen de déclenchement commande (déclenche) également la génération du code CC. L'intérêt de cette dernière variante est en plus de la variabilité périodique déjà évoquée ci avant (le code change toutes les demi-heures par exemple, même en présence du mécanisme de déclenchement) de disposer d'une variabilité aléatoire à l'initiative de l'utilisateur.
Cette variante implique le besoin d’assurer la synchronisation entre le code CC1 généré par le dispositif DC à ce niveau et la seconde version CC2 du code généré lors de l’étape E5 au niveau des serveurs dudit appareil de certification sur un dispositif DCC pour cette clé CL. La problématique est donc que pour toute action (ex. impulsion) déclenchant une génération d’un nouveau code CC, par le dispositif DC, le dispositif DCC doit être synchronisé, afin qu'à l’étape E5, la clé CC puisse être validée au niveau de l'appareil de certification.
Par exemple si la méthode de génération du code CC se base sur une liste ordonnée de cryptogrammes précalculés intégrée dans la mémoire du dispositif DC en regard de la clé CL, avec la même liste de cryptogrammes précalculés disponible au niveau du dispositif DCC en regard de la clé CL, une impulsion au niveau de DC fait passer au cryptogramme suivant de la liste côté utilisateur, et cette avancée doit être communiquée d'une façon ou d'une autre au niveau de DCC pour conserver la synchronisation. (Il n'y aurait, par contre, pas d'impact au niveau des autres changements de code CC selon la périodicité préprogrammée (toutes les demi-heures par exemple) : l'avancée dans les codes CC se fait alors (en complément des avancées par impulsion) de façon synchrone entre DC et DCC pour ladite clé CL.
Selon une 1ere variante, pour obtenir la synchronisation voulue, ledit dispositif DC est connecté d'une façon ou d'une autre au réseau Internet selon un des nombreux moyens connus, et ce afin de transmettre ladite information relative à l'impulsion (ou autre acte déclencheur) aux serveurs hébergeant le dispositif DCC. Cette 1ere variante comporte, outre les coûts et consommation en énergie des moyens de communication nécessaires au niveau de DC, des risques potentiels en termes de sécurité, puisqu'un chemin de connexion et d'authentification est nécessaire entre DC et DCC. En outre, un canal retour serait aussi nécessaire afin de vérifier l'acquittement de la bonne réception de l'impulsion au niveau de DCC.
Selon une 2ème variante, la synchronisation est gérée par un moyen spécifique à l'étape E5.
Selon une 3ème variante préférée plus évoluée, une suite de caractères inclus dans le code CC est réservée à la synchronisation due aux impulsions au niveau du dispositif DC. Par exemple non exhaustif, le code CC est composé de 6 caractères, les quatre premiers formant la clé cryptogrammique CCv, et les deux derniers formant un code CCs permettant lors de l’étape E5 au dispositif DCC de retrouver le nombre d'impulsions effectuées depuis la création de la clé CL. Cette variante sera décrite plus en détails en relation avec l’étape E5.
Ces deux dernières variantes permettent de s'affranchir d'impulsions non volontaires effectuées par l'utilisateur, ou d'impulsions non suivies de la mise en œuvre des étapes suivantes de notre procédé.
Selon une 4ème variante, un période de temps minimale entre 2 impulsions est imposée, par exemple non exhaustif au maximum toutes les 3 secondes, cet intervalle pouvant être complété par un nombre maximum d'impulsions par unité de temps, par exemple non exhaustif un maximum de 5 impulsions par minutes et de 40 impulsions par heure. Ces limitations ont comme intérêt de limiter les impulsions en séries non souhaitées (par exemple pour éviter les problématiques liées à un mécanisme d'impulsion resté actif par erreur : ledit mécanisme peut être un bouton qui doit être enfoncé pour générer une impulsion, ou un masque recouvrant le moyen d'affichage, qui une fois ôté génère l'impulsion, ...) Ces dernières données de limitation pourraient éventuellement être paramétrables par l'utilisateur pour une clé CL donnée.
Selon une 5eme variante préférée, plusieurs clés CL utilisent le même dispositif DC de génération de code CC. Cette dernière variante, outre la simplicité d'usage qu'elle apporterait, présente le grand intérêt de complexifier encore plus la problématique des éventuels pirates.
La simplicité est alors évidente, puisque pour toute ces clés CL, ou pour un sous- groupe de ses clés CL, l'utilisateur n'a alors besoin d'interagir avec un seul dispositif générant et affichant les codes CC. Cette variante est possible puisque nous avons vu ci-avant qu'un utilisateur disposant d'un compte auprès de l'appareil de certification peut demander une ou plusieurs clés CL différentes, chacune pouvant être associée avec différents types d'informations pouvant être distinctes d'une clé à l'autre.
De nombreuses variantes d'implémentation sont possibles pour les moyens de déclenchement. Selon une de nos variantes préférées, l'impulsion est liée à un capteur d'empreinte intégré au dispositif DC, ce qui a comme avantage de permettre à notre procédé et système de réaliser une double authentification, procurant une augmentation de la sécurité et respectant la directive européenne DSP2, puisqu’outre la ressaisie du code, l'utilisateur doit s'authentifier via son empreinte digitale. Auquel cas, l'empreinte devrait être reconnue pour générer une impulsion. On peut ainsi envisager un dispositif incluant une bague à capteur d’empreinte : il suffit d'un mouvement de pouce vers la bague pour mettre la paume du pouce sur cette bague. Même en cas de vol de ladite bague, le dispositif DC ne pourrait donc pas être mis en œuvre ... Ces variantes ne sont pas limitées aux seuls capteurs d’empreintes ; d’autres types de capteurs biométriques peuvent être employés (ex. capteurs d’empreinte vocale, des dispositifs de Scan d’iris).
La compatibilité du code CC avec les CW classiques
Remarque : Ces paragraphes se rapportent au cas particulier de l'usage de notre variante par rapport aux codes CW des cartes bancaires.
La problématique dans un tel cas de figure tient à la compatibilité nécessaire avec les procédés de paiement en ligne déjà en place, qui incorporent la saisie d'un code CW à 3 chiffres en regard des autres données de la carte bancaire (clé et date de péremption). Comme nous l'avons vu ci-dessus, les dispositifs DC utilisés selon les modes de réalisation de l’invention génèrent des codes CC qui ne sont pas nécessairement composés de successions de 3 chiffres, mais peuvent être une succession de par exemple 6 ou 8 chiffres et ou lettres. Auquel cas, par défaut, nos codes CC ne seraient pas compatibles avec les codes CW à 3 chiffres attendus pour une transaction bancaire.
Deux variantes permettent de résoudre cette problématique de compatibilité avec les systèmes normalisés déjà en place.
* La 1ere variante consiste à imposer que les 3 premiers caractères dudit code généré soient des chiffres. Il suffit pour cela d’adapter les méthodes de génération au niveau du dispositif DC et, côté appareil de certification, au niveau du dispositif DCC.
L'utilisateur lors d'une transaction bancaire classique doit se limiter à saisir ces 3 premiers chiffres, qui éventuellement sont affichés sur l’écran du dispositif DC de façon différenciés des autres caractères de la série (une autre couleur par exemple).
Bien que cette variante soit un peu plus compliquée à expliquer aux utilisateurs, et réduit le nombre de combinaisons disponibles, elle permet de répondre très simplement à la problématique.
* Une 2ème variante, limitée aux dispositifs DC à impulsions, supprime ces 2 inconvénients. Selon cette variante, les méthodes de génération desdits codes CC comportent la possibilité de générer un code à 3 caractères de type chiffre selon un intervalle d'impulsions prédéterminé, par exemple toutes les 4 impulsions. Auquel cas, si le code CC courant affiché n'est pas à 3 chiffres, l'utilisateur lance une impulsion (et ce au maximum 3 fois consécutives), avant que s'affiche un code CC à 3 chiffres.
* Une 3ème variante mixe les 2 propositions ci-dessus : toutes les n impulsions, un code CC à n caractères (6 ou 8 par exemple) est généré, les 3 premiers caractères dudit code étant une succession de 3 chiffres, compatible avec les procédés utilisant des codes types CW donc.
A noter que les 1ère et 3eme variantes peuvent nécessiter une adaptation au niveau de l’étape E5.
Quel que soit la manière dont la première version CC1 du code est générée côté utilisateur, elle est ensuite transmise à l’appareil de certification. Selon un exemple non limitatif, l’utilisateur recopie le code CC1 au niveau du formulaire de validation qui lui est présenté et valide ledit formulaire. La validation génère l’envoi du résultat de la validation, à savoir la communication dudit code CC1 recopié associé à la clé CL, et éventuellement des données complémentaires associées, vers les moyens ad hoc de l'appareil de certification.
Pour assurer une authentification, le formulaire peut être combiné à des dispositifs tiers, tel que par exemple un dispositif de lecture d'empreinte, ou d'analyse d'iris, ou tout autre information spécifique de l'utilisateur et connue de l'appareil de certification (mot de passe, réponse à une question, ...) dont les informations recueillies peuvent être transmises en parallèle à celles décrites ci-dessus en fin de l’étape E4.
La Cinquième Etape : E5
Le procédé s'achève alors par une 5eme et dernière étape, E5, au cours de laquelle l'organisme de certification récupère puis compare la première version CC1 du code CC, reçu du dispositif DC de l’utilisateur, à une seconde version CC2 générée au niveau des serveurs dudit organisme de certification pour ladite clé CL dudit utilisateur (ou acquise par l’organisme de certification par exemple depuis un dispositif DCC externe). L’appareil de certification compare les deux versions du code. Si les deux correspondent (ex. sont identiques), l’appareil de certification accepte la demande, sinon il la refuse. Dans tous les cas, une information indiquant le résultat de la comparaison est retournée au service SQ, éventuellement couplé aux informations complémentaires.
L'opération principale de cette étape E5 consiste à vérifier si la première version du code CC fourni du côté de l'utilisateur à la étape E4 est conforme à celui attendu. Il convient à cet effet que le serveur ou système incorporant les serveurs dudit organisme de certification soit en mesure de vérifier l'exactitude du cryptogramme indiqué par le présumé utilisateur à l'étape E4.
Pour cela, il convient au niveau de cet organisme de certification de disposer en regard de chaque clé CL d'un moyen et dispositif DCC permettant de produire ledit code CCS associé à CL (ou à un ensemble de clés CL selon la variante selon laquelle un seul couple de dispositifs DC et DCC est associé à plusieurs clés CL) à un instant donné.
Tout dépend à ce niveau de la méthode utilisée pour générer CC au niveau du dispositif DC de l'utilisateur, sachant que la même méthode devra alors être utilisée au niveau de DCC. Nous nous limitons ci-dessous aux deux exemples non exhaustifs de méthodes déjà citées lors de la description de l'étape EP :
Selon le 1er exemple, une liste de cryptogrammes précalculés, avec une sélection de cryptogramme par pas de temps (par exemple toutes les heures on passe au code suivant dans ladite liste) est enregistrée dans une mémoire en regard de CL, la même liste de cryptogrammes précalculés devant également être disponible au niveau du dispositif DCC en regard de CL.
Selon le 2eme exemple, un timestamp et un secret sont partagés entre le dispositif générateur de codes dynamiques et l’organisme de certification. Le serveur abritant le dispositif DCC pour ledit code CL doit alors être parfaitement synchronisé avec le serveur abritant le dispositif DC de l'utilisateur (afin de récupérer le même timestamp).
A noter que plusieurs méthodes peuvent être utilisées au niveau du dispositif de l'organisme de certification, sachant que seule une méthode sera implémentée pour une clé CL donnée.
Outre les méthodes, pour une clé CL donnée, les 2 dispositifs DC et DCC doivent être synchronisés.
Dans les cas d'implémentations simples du dispositif DC, cette synchronisation est effectuée au moment de la fabrication ou de la programmation des deux dispositifs DC et DCC et ne varie plus. Auquel cas, le dispositif DCC permet de recalculer le code CC2 associé à CL, puis le compare au code CC1 communiqué en regard de la clé CL en fin de l’étape E4. Le résultat de cette comparaison est conservé pour la fin de l’étape E5.
Comme nous l'avons évoqué à l'occasion de l'étape EP, la problématique de synchronisation est plus complexe en cas de dispositif DC générant un code CC à l'aide d'un moyen d'impulsion (en appuyant sur un bouton par exemple), de façon isolé ou en complément de l'évolution par pas de temps ou autre (il n'y a pas de problématique particulière bien entendu si le moyen d'impulsion ne sert qu'à afficher le code courant (donc s'il ne sert qu'à économiser la batterie, ou dans les variantes selon lesquelles l'impulsion est liée à une empreinte ou autre paramètre biométrique, à sécuriser l'affichage).
Comme nous l'avons évoqué lors de la description de l'étape EP, une 1ere variante pour résoudre la problématique de synchronisation liée à la génération lors de l’étape E4 du code CC à l'aide d'un moyen d'impulsion quelconque au niveau du dispositif DC consiste en un moyen de gestion spécifique GS à l'occasion de l'étape E5.
La mise en œuvre dudit moyen GS consiste dans une 1ere sous étape à sauvegarder le code CC2-init et ses données respectives de synchronisation. Ces données de synchronisation dépendent de la méthode employée pour générer ledit code CC2-init relativement à la clé CL. Pour reprendre l'exemple d'une méthode basée sur une liste ordonnancée de cryptogrammes précalculés, il s'agirait de la position du code CC2-init dans ladite liste ordonnancée.
Au cours d'une seconde sous étape, le moyen GS génère le code suivant (CC2-init)+1 pour ladite clé CL de façon classique à l'aide du dispositif DCC, puis compare ledit code (CC2-init)+1 à celui CC1 communiqué à l'issue de l'étape E4. Si lesdits code (CC2- init)+1 et CC1 ne correspondent pas, plutôt que de retourner directement une réponse négative à l'issue de l’étape E5, le moyen GS, lors de 3eme sous étapes successives n, génère un code (CC2-init)+i (i=2, 3, ... ,n) et le compare à celui CC1 communiqué à l'issue de l'étape E4, et ce jusqu'à ce qu'il trouve une correspondance.
Selon une variante, le nombre de sous étapes successives est limité, par exemple non exhaustif à la valeur 100. En conséquence, si au bout de n=100 3èmes sous-étapes successives aucune concordance avec CC1 n'est trouvée, la comparaison sera considérée comme négative (soit mauvais code CC1 , soit le dispositif DC est défaillant, ce qui du point de vue du traitement de la demande donne un résultat identique).
Au cours d'une 4eme sous étape, si la comparaison est jugée négative, le moyen de gestion spécifique GS resynchronise le dispositif DCC pour la clé CL au niveau du code CC2-init.
Si la comparaison est jugée positive au cours de la 2eme ou de l'une des 3eme sous étapes successives, le moyen de gestion spécifique GS resynchronise le dispositif DCC pour la clé CL au niveau du code (CCS-init)+i pour lequel une correspondance a été trouvée. Le résultat de cette comparaison est conservé pour la fin de l’étape E5.
Comme nous l'avons évoqué lors de la description de la quatrième étape, une 2eme variante pour résoudre la problématique de synchronisation liée à la génération du code CC, côté utilisateur, à l'aide d'un moyen d'impulsion quelconque au niveau du dispositif DC consiste en un sous code CCs intégré dans le code CC. Ce code CCs pourrait par exemple être constitué par une suite de 2, ou en variante de 3 caractères numériques ou alphanumériques (au-delà, le code deviendra long à ressaisir par l'utilisateur à l’étape E4 du procédé).
Selon une 1ere variante simplifiée, le code CCs est une simple suite d'un ordre chronologique prédéfini à partir d'un point de départ lors la création de la clé CL. Par exemple, une suite aurait comme point de départ le code J8v et la chronologie serait :
* Pour le 1er caractère : Ordre alphabétique à partir du J (1er caractère du point de départ) jusqu'à retour à I, puis ordre croissant à partir du 7 jusqu'à retour au 6, puis ordre alphabétique inverse à partir du s jusqu'à retour au t.
* Pour le 2eme caractère : ordre décroissant à partir du 8 jusqu'à retour au 9...
Et ainsi de suite pour le 3eme caractère.
Selon cette variante, ces informations sont également implémentées sur les dispositifs DC et DCC relativement à la clé CL lors de la création de ladite clé (ou lors de la création de la 1ere clé CL si lesdits dispositifs DC et DCC sont communs à plusieurs clés). Auquel cas, la resynchronisation est effectuée de façon similaire à celle indiquée pour la 1ere variante ci-avant à l'aide d'un moyen GS similaire, mais portant sur le code CCs.
Une telle implémentation permet de gérer environ 175 000 impulsions distinctes sur la base d'une suite de 3 caractères composée de chiffres ou de lettres, en excluant ceux pouvant prêter à confusion entre chiffres et lettres. Un contrôle permet toutefois de démultiplier cette capacité en détectant un retour au point de départ. Bien qu’il y ait une possibilité relativement élevée que l’utilisateur puisse aisément repérer la suite de codes CCs, le code CCv reste imprévisible.
En variante, ledit code CCs peut, de façon exactement similaire au code CCv, être géré par une des méthodes possibles pour générer le code CCs (deux méthodes distinctes peuvent être implémentées pour le code CCv et le code CCs). Auquel cas, la resynchronisation est effectuée de façon similaire à celle indiquée pour la 1ere variante ci-avant à l'aide d'un moyen GS similaire, mais portant sur le code CCs.
A noter que pour accroître la sécurité, les codes CCv et CCs peuvent être mixés lors de l'affichage sur les dispositifs DC et DCC. Par exemple pour une suite globale sur 6 caractères, le code CCv est affiché sur les 2eme, 3eme et 6eme caractères, tandis que le code CCs est affiché sur les 1ers, 4eme et 5eme caractères. Cette information devant bien entendu être connue au niveau du dispositif DCC pour à la fois effectuer la resynchronisation et vérifier la concordance entre le code saisi à l’étape E4 et le code attendu.
Toujours par souci de sécurisation accrue, selon certains modes de réalisation, les codes CCs et CCv sont conservés sur 2 serveurs distincts, toujours relativement à une clé CL (ou un ensemble de clés CL) respective. Auquel cas, le moyen spécifique GS est mis en œuvre au niveau du serveur abritant la suite de code CCs couplé à CL, et une fois la synchronisation effectuée, le résultat est transmis au serveur conservant CCv pour contrôler CCv en regard de la même clé CL. Une fois la comparaison effectuée, le résultat de ladite comparaison est conservé pour la fin de l’étape E5.
Dans le cas d'un résultat de comparaison négatif, une information de refus d'opération ou de transaction est retournée au service SQ demandeur, charge à ce dernier d'en informer éventuellement l'utilisateur.
Dans le cas d'un résultat de comparaison positif, de multiples traitements particuliers peuvent en outre être effectués pour valider ou non l'opération.
Par exemple non exhaustif, une opération relative à un achat en ligne sera acceptée si le montant du crédit associé à la clé CL, éventuellement sur un créneau temporel défini au niveau de ladite clé CL, est compatible avec le montant de l'achat. Si tel n'est pas le cas, une information de refus d'opération ou de transaction est retournée au service SQ demandeur, charge à ce dernier d'en informer éventuellement l'utilisateur. Dans l'affirmative, ledit montant du crédit associé à CL est débité du montant de l'achat.
Selon un autre exemple non exhaustif, si une restriction d'usage de la clé CL est associée à une zone géographique particulière, un moyen dédié vérifie si les données de géolocalisation ont bien été communiquées en fin de l’étape E4 en complément du code CC saisi par l'utilisateur, et dans l'affirmative si elles correspondent à la zone de géolocalisation autorisée. Si tel n'est pas le cas, une information de refus d'opération ou de transaction est retournée au service SQ demandeur, charge à ce dernier d'en informer éventuellement l'utilisateur. Le moyen de vérification de la géolocalisation (ou d'une empreinte, ...) peut être implémenté sur un autre terminal de l'utilisateur.
Comme la personne du métier le comprendra, de nombreux autres contrôles complémentaires sont possibles et ils ne sont pas tous détaillé ici par souci de concision. Si l'ensemble des contrôles sont positifs, une information de validation (ou d'acceptation) d'opération ou de transaction est retournée au service SQ demandeur, charge à ce dernier d'en informer éventuellement l'utilisateur.
Selon une variante, outre cette information d'acceptation de validation, et en dépendance du type d'opération et des autorisations de divulgation associées à la clé CL, des informations complémentaires sont être communiquées par l'organisme de certification CERT au service SQ.
Par exemple, pour une création de compte et ou une connexion de compte, des données associées à ce compte telles que le nom ou alias, un prénom, un email, ... associés à CL sont retournées à SQ. Un des avantages pour le service SQ est que même en cas de piratage des bases de données, un éventuel pirate n'a pas accès à ces données si SQ ne les a pas stockées lui-même. Il n’est pas nécessaire que ce service SQ fasse des déclarations auprès des organismes tels que le CNIL (pour « Commission Nationale de l’Informatique et des Libertés ») vu que ce service ne conserve pas de données personnelles. Les impératifs liés à la RGPD (pour « Règlement Général sur la Protection des Données ».) sont aussi grandement simplifiés car les services SQ concernés qui ne stockent aucune donnée personnelle.
Selon un autre exemple, le montant du crédit restant sur le compte de l'utilisateur après l'opération est retourné au service SQ (par exemple si ce service SQ est un service financier et que l'opération était un virement ou autre).
La variété des informations complémentaires pouvant être éventuellement diffusées est très variée en dépendance des types d'opérations effectuées avec une clé CL et des autorisations de divulgation.
Lors des connexions ultérieures, l'utilisateur peut se connecter de façon classique à son compte (mail + passe par exemple), mais il recevra toujours une demande de validation par code crypto : à cet effet, SQ recherche la clé associée audit compte dans sa base de données, puis interroge l'organisme de certification (succession des étapes E2 à E4). De ce fait, si le service SQ s'assure de l'unicité de l'identifiant de l'utilisateur, celui- ci n'aurait même plus besoin d'un mot de passe, la saisie du code CC associé à sa clé étant alors suffisante.
En variante, l'utilisateur peut utiliser sa clé CL pour se connecter au compte (mais il lui faut s'en souvenir). Les mêmes procédures peuvent être utilisées pour un paiement.
En référence à la figure 4, les étapes du procédé mis en œuvre au niveau d’un poste utilisateur selon un mode de réalisation de l’invention vont être décrites ci-dessous.
Le procédé comporte une première étape E1a qui, du point de vue du poste utilisateur, comporte une étape (F30a) de formulation d’une demande, par un utilisateur (U) associé à une clé (CL) émise par un organisme de certification, de mise en œuvre d’une opération auprès d’un appareil de prestataire de service. L’affectation de la clé CL à l’utilisateur peut se faire lors d’une étape préalable EP semblable à celle décrite ci-dessus. Ensuite, il y a une étape de réception (F60a), par le poste utilisateur, d’une demande de code dynamique, destinée à l’utilisateur associé à la clé (CL), cette demande étant transmise par l’appareil de l’organisme de certification. S’ensuit une étape de génération, par un dispositif générateur de codes dynamiques de l’utilisateur, d’une première version (CC1 ) du code dynamique (F70) et une étape de transmission de la première version (CC1 ) du code dynamique à l’appareil de certification (F80). En fin du procédé, il y a une étape de réception (F110), depuis l’appareil de prestataire de service, d’un message confirmant la réalisation de l’opération demandée.
On peut considérer que l’étape F60a fait partie d’une étape E3a semblable à l’étape E3 décrite ci-dessus, et que l’étape F110 fait partie d’une étape E5a semblable à l’étape E5 décrite ci-dessus. On comprend, donc, que les remarques et variantes exposés ci- dessus à propos des étapes EP, E1 et E3 à E5 s’appliquent en général aussi aux étapes EP, E1a, E3a, E4 et E5a de la figure 4.
En référence aux figures 5 à 7, des exemples des architectures des éléments principaux du système 1 de la figure 1 , sont présentés. Les figures 5 à 7 représentent des modules fonctionnels adaptés pour construire le poste utilisateur 10, l’appareil 20 de prestataire de service et l’appareil 30 de certification, sachant qu’en réalité la fonctionnalité décrite est typiquement mis en œuvre à l’aide d’instructions d’un programme d’ordinateur plutôt qu’à l’aide de modules physiques. Par ailleurs, la personne du métier comprendra que le nombre de modules fonctionnels peut être différent de ceux représentés sur les figures 5 à 7. En d’autres termes, les fonctions de certains modules peuvent être distribués sur un nombre accru de modules et/ou un module unique peut cumuler les fonctions de plusieurs des modules représentés.
Dans le mode de réalisation décrit ici, le poste utilisateur 10 peut comporter les modules fonctionnels représentés à la figure 5. Selon cet exemple le poste utilisateur 10 comprend un dispositif 12 générateur de codes dynamiques, et un module 14 de transmission à un appareil de certification des codes produits par le dispositif 12 générateur de codes dynamiques. Le poste comporte aussi une interface utilisateur 15 via laquelle l’utilisateur peut formuler une demande de mise en œuvre d’une opération auprès d’un appareil de prestataire de service, un premier module 17a de réception destiné à recevoir une demande de code dynamique depuis l’appareil 30 de l’organisme de certification, et un deuxième module 17b de réception destiné à recevoir, depuis l’appareil de prestataire de service, un message confirmant la réalisation de l’opération demandée. Les premier et deuxième modules de réception 17a, 17b peuvent être intégrés dans un seul module comme il est représenté sur la figure 5.
Eventuellement le poste utilisateur 10 peut comporter un moyen d’actionnement 15a et un capteur 16 de données biométriques. Dans l’exemple représenté à la figure 5 le moyen d’actionnement 15a fait partie de l’interface utilisateur 15. Selon certains modes de réalisation le dispositif 12 générateur de codes dynamiques est configuré pour générer un nouveau code en réponse à une action de l’utilisateur, notamment l’actionnement du moyen d’actionnement 15a intégré à l’interface utilisateur 15. Le capteur 16 de données biométriques est agencé alors pour obtenir des données biométriques de l’utilisateur lors de l’action de l’utilisateur qui déclenche la génération d’un nouveau code. Le module 14 de transmission de codes est alors configuré pour ne transmettre à l’appareil de certification de code valable que si le capteur 16 de données biométriques valident les données biométriques détectées lors de ladite action de l’utilisateur.
Dans le mode de réalisation décrit ici, l’appareil 20 de prestataire de service peut comporter les modules fonctionnels représentés à la figure 6. Selon cet exemple l’appareil 20 de prestataire de service comprend un module 22 de réception d’une demande, par l’utilisateur U, de mise en œuvre d’une opération, un module 24 d’émission (vers l’appareil de certification) d’une requête de validation de l'opération demandée, ladite requête indiquant la clé CL associée à l’utilisateur U, et un module 26 de mise en œuvre de l’opération demandée suite à la réception d’un signal de validation de la part de l’appareil de certification.
Dans le mode de réalisation décrit ici, l’appareil 30 de certification peut comporter les modules fonctionnels représentés à la figure 7. Selon cet exemple l’appareil 30 de certification comprend un module 34 d’émission d’une demande de code dynamique, destinée à un dispositif générateur de codes dynamiques affecté à l’utilisateur associé à ladite clé (CL). L’appareil 30 de certification comprend aussi un module 35 de réception de la première version CC1 du code dynamique générée par le dispositif générateur de codes dynamiques GC côté utilisateur, un module 37 d’acquisition de la seconde version CC2 du code dynamique, un module 38 de comparaison des première et seconde versions CC1 , CC2 du code dynamique, et un module 39 de transmission d’un signal de validation à l’appareil 20 de prestataire de service lorsque les première et seconde versions (CC1 ,CC2) du code dynamique correspondent. Le module 37 d’acquisition de la seconde version CC2 du code dynamique peut correspondre à un dispositif GCC générateur de codes dynamiques. L’appareil de certification peut comprendre aussi un module 32 de récupération des données de l’utilisateur associée à la clé CL reçu de l’appareil de prestataire de service, destiné par exemple à récupérer les données de contrôle évoquées ci-dessus.
Comme nous l’avons indiqué ci-dessus, dans un mode particulier de réalisation, les différentes étapes du procédé de sécurisation sont déterminées par des instructions de programmes d’ordinateurs destinés à être mis en œuvre dans l’appareil de prestataire de service, dans l’appareil de certification et dans un poste utilisateur, ou plus généralement dans un ordinateur. Typiquement de tels ordinateurs comprennent les éléments représentés à la figure 8, c’est-à-dire un processeur CPU, une interface de communication I/O, une mémoire morte ROM, une mémoire vive RAM et un module DISP gérant l’affichage au niveau d’un écran (non représenté), ces composants étant reliés classiquement via un bus. Bien entendu d’autres composants classiques peuvent également être présents.
On comprendra que diverses modifications peuvent être apportées aux modes de réalisation décrits ci-dessus sans sortir du cadre de l’invention.
Par exemple, selon un mode particulier de réalisation de l’invention, l'étape E1 du procédé n’est pas réalisée. Le dispositif SQ initie le procédé dès la 2eme étape E2 en demandant la validation d'une opération. Cette variante peut être illustrée dans de nombreux cas d'usage, dont par exemple non exhaustif celui d'un système anti-spam, qu'il soit SMS, mail, ou téléphonique. Auquel cas, ledit service SQ ne dispose pas des coordonnées du client, mais seulement de la clé CL à laquelle sont associées éventuellement différents moyens de contacter le client (par exemple le client accepte d'être contacté par mail et SMS, mais les coordonnées correspondantes ne sont pas fournies), et éventuellement, si l'utilisateur a autorisé les divulgations correspondantes à l'étape préalable, pour chaque moyen, des créneaux et/ou un nombre de contacts maximum par créneau.
Un exemple du procédé mis en œuvre par un système anti-spam selon un mode de réalisation de l’invention est maintenant décrit en référence à la figure 9.
Selon l’exemple de la figure 9, le prestataire de service SQ initie le procédé en demandant (F35) à l’appareil de certification la transmission d’un message à l’utilisateur U associé à une clé CL (par exemple un contact par mail). La demande REQ_OP du prestataire de service SQ est émise par l’appareil 20 de prestataire de service et identifie la clé CL de l’utilisateur visée. On peut considérer que cette étape F35 correspond à une variante E2b de l’étape E2 décrite ci-dessus. Lors d’une variante E3b de l’étape E3 décrite ci-dessus, l’appareil de certification 30 récupère (F50b) des données concernant l’utilisateur associé à la clé CL fourni par l’appareil de prestataire de service, par exemple des données identifiant les coordonnées de l’utilisateur et des données de contrôle que l’on peut caractériser de paramètres anti-spam.
L'organisme de certification CERT vérifie si la transmission du message à l’utilisateur selon la demande du prestataire de service SQ est ou non conforme aux paramètres anti-spam associés à l’utilisateur associé à la clé CL. Par exemple, l’organisme de certification vérifie si le service SQ fait partie des services autorisés figurant dans une liste d’autorisations de diffusion que l'utilisateur a indiqué à l'étape préalable en regard de la clé CL concernée, ainsi que les conditions éventuellement liées (nombre d'appels et ou de SMS / mails, ... par période, ...). Le procédé suit son cours et passe directement de l’étape E3b à une étape E5b, sans diffuser de formulaire de validation à l'utilisateur en fin de l’étape E3b. Dans le cas d’une détermination positive par l’appareil de certification, l'organisme de certification accepte la diffusion, et un mail / SMS ... TX_MES est envoyé / rerouté en respectant l'anonymat de l'utilisateur (F100b).
Une mise en forme minimale des mails, SMS ..., peut être réalisée. Par exemple l’appareil de prestataire de service peut demander au service de certification de commencer un message par les variables Prénom puis Nom selon une formulation prédéfinie au niveau de l'API concernée et, si l’appareil de certification accepte de transmettre le message à l’utilisateur l’appareil de certification remplace les variables Prénom puis Nom par les données correspondantes (si elles sont détenues). Selon une variante de ce mode de réalisation, si le service SQ n'est pas inclus dans la liste des autorisations de diffusion, l'organisme de certification CERT transmet une demande spécifique à l’utilisateur recherchant l’accord de celui-ci pour ajouter le prestataire de service SQ à la liste des services autorisés à lui envoyer des messages. A cette fin, l’appareil de certification envoie (F60b) un formulaire de validation TX_FRM en fin de l’étape E3b et une variante E4b de l’étape E4 est réalisée. Auquel cas, l'utilisateur lors de l’étape E4b, peut soit valider, sur le formulaire, la demande d'ajout du service SQ à la liste des services autorisés en saisissant un code confidentiel CC, soit la refuser. Le poste utilisateur transmet sa réponse U_ REP à l’appareil de certification (F80b). L’étape E5b se déroule normalement, avec selon les réponses de l’étape E4b un ajout de SQ dans les autorisations de diffusion liées à CL et la diffusion correspondante, soit un refus de diffusion.
En variante de ce mode de réalisation, le formulaire de validation à l’étape E4b inclut une saisie optionnelle d'informations complémentaires, du type : autorisations permanentes, sur un créneau ou des créneaux prédéfinis, nombres de contacts acceptés, .... En outre, l’utilisateur peut comme déjà indiqué pour l'étape préalable, à tout moment sur son compte sur l'organisme de certification modifier pour sa clé CL les autorisations, dont celles de diffusion, données ou non au service SQ concerné.
Dans la description ci-dessus de certains modes de réalisation de l’invention certains remarques se réfèrent à la transmission de la clé CL depuis l’appareil de prestataire de service à l’appareil de certification. Il convient de rappeler que le message de l’appareil de prestataire de service peut transiter via un organisme tiers OT.

Claims

Revendications
1. Procédé de sécurisation d’opérations, caractérisé en ce qu’il comprend :
- une étape (F30a) de formulation d’une demande, par un utilisateur (U) associé à une clé (CL) émise par un organisme de certification, de mise en œuvre d’une opération auprès d’un appareil (20) de prestataire de service ;
- une étape (F60a) de réception, par un poste utilisateur, d’une demande de code dynamique, destinée à l’utilisateur associé à la clé (CL), émise par un appareil (30) de l’organisme de certification ;
- une étape (F70) de génération, par un dispositif (12) générateur de codes dynamiques associé à la clé (CL) de l’utilisateur, d’une première version (CC1 ) du code dynamique
- une étape (F80) de transmission de la première version (CC1 ) du code dynamique à l’appareil (30) de certification ; et
- une étape (F110) de réception, en provenance de l’appareil de prestataire de service, d’un message confirmant la réalisation de l’opération demandée, à condition que la première version (CC1 ) du code dynamique corresponde à une deuxième version du code dynamique générée au niveau de l’organisme de certification.
2. Procédé de sécurisation d’opérations selon la revendication 1 , caractérisé en ce que la génération de la première version (CC1 ) du code dynamique par le dispositif générateur de codes dynamiques est déclenchée par une action de l’utilisateur.
3. Procédé de sécurisation d’opérations selon la revendication 2, caractérisé en ce que des données biométriques de l’utilisateur sont détectées lors de l’action de l’utilisateur qui déclenche la génération d’un code, et l’étape (F80) de transmission de la première version (CC1 ) du code dynamique à l’appareil (30) de certification n’a lieu que si les données biométriques détectées sont validées.
4. Procédé de sécurisation d’opérations selon l’une quelconque des revendications 1 à 3, caractérisé en ce que le code dynamique comporte un sous-code (CCs) et l’évolution du code dynamique comporte un changement progressif de chaque caractère du sous-code selon une règle respective.
5. Procédé de sécurisation d’opérations selon la revendication 4, caractérisé en ce que les caractères du sous-code sont distribués parmi les autres caractères du code dynamique.
6. Poste utilisateur (10) caractérisé en ce qu’il comprend :
- une interface utilisateur (15) configurée pour permettre à un utilisateur (U) associé à une clé (CL) émise par un organisme de certification de formuler une demande de mise en œuvre d’une opération auprès d’un appareil (20) de prestataire de service ;
- un premier module (17a) de réception destiné à recevoir une demande de code dynamique, destinée à l’utilisateur associé à la clé (CL), depuis un appareil (30) de l’organisme de certification ;
- un module (14) de transmission à l’appareil de certification d’une première version de code dynamique générée par un dispositif générateur de codes dynamiques associé à la clé (CL) de l’utilisateur ; et
- un deuxième module (17b) de réception destiné à recevoir, depuis l’appareil de prestataire de service, un message confirmant la réalisation de l’opération demandée à condition que la première version (CC1 ) du code dynamique corresponde à une deuxième version du code dynamique générée au niveau de l’organisme de certification.
7. Poste utilisateur selon la revendication 6, caractérisé en ce qu’il comprend :
- un module d’actionnement (15a) destiné à être actionné par l’utilisateur pour déclencher la génération d’un code par le dispositif générateur de codes dynamiques, et
- un capteur (16) de données biométriques ;
dans lequel
- le capteur (16) de données biométriques est agencé pour obtenir des données biométriques de l’utilisateur lors de l’actionnement du module d’actionnement (15a) par l’utilisateur, et
- le module (14) de transmission de codes est configuré pour ne transmettre à l’appareil de certification la première version de code que si les données biométriques détectées par le capteur (16) de données biométriques lors dudit actionnement du module d’actionnement (15a) par l’utilisateur sont valides.
8. Système de sécurisation d’opérations, caractérisé en ce qu’il comprend un appareil (20) de prestataire de service et un appareil (30) de certification, dans lequel :
l’appareil (20) de prestataire de service comprend :
- un module (22) de réception d’une demande, par un utilisateur (U), de mise en oeuvre d’une opération,
- un module (24) d’émission vers l’appareil de certification d’une requête de validation de l’opération demandée, ladite requête indiquant une clé (CL) associée à l’utilisateur (U), et
- un module (26) de mise en œuvre de l’opération demandée suite à la réception d’un signal de validation de la part de l’appareil de certification ; et
l’appareil (30) de certification comprend :
- un module (34) d’émission d’une demande de code dynamique, destinée à l’utilisateur associé à ladite clé (CL),
- un module (35) de réception d’une première version (CC1 ) du code dynamique générée par un dispositif générateur de codes dynamiques affecté à l’utilisateur associé à ladite clé (CL),
- un module (37) d’acquisition d’une seconde version (CC2) du code dynamique,
- un module (38) de comparaison des première et seconde versions (CC1 ,CC2) du code dynamique, et
- un module (39) de transmission d’un signal indiquant la validation de l’opération lorsque les première et seconde versions (CC1.CC2) du code dynamique correspondent.
9. Procédé de sécurisation d’opérations, caractérisé en ce qu’il comprend :
- une étape (F30) de demande, par un utilisateur (U), de mise en œuvre d’une opération auprès d’un appareil (20) de prestataire de service ;
- une étape (F40) d’émission par l’appareil (20) de prestataire de service à un appareil (30) de certification d’une requête de validation de l’opération demandée, ladite requête indiquant une clé (CL) associée à l’utilisateur (U) ;
- une étape (F60) d’émission d’une demande de code dynamique, destinée à l’utilisateur associé à la clé (CL), depuis l’appareil (30) de certification ; - une étape (F70) de génération, par un dispositif (12) générateur de codes dynamiques affecté à l’utilisateur associé à ladite clé (CL), d’une première version (CC1 ) du code dynamique ;
- une étape (F80) de transmission de la première version (CC1 ) du code dynamique à l’appareil (30) de certification ;
- une étape (F90) d’acquisition d’une seconde version (CC2) du code dynamique et de comparaison des première et seconde versions du code dynamique par l’appareil (30) de certification ; et
- à condition que les première et seconde versions (CC1 ,CC2) du code dynamique correspondent, une étape (F100) de transmission par l’appareil (30) de certification à l’appareil (20) de prestataire de service, d’un signal indiquant la validation de l’opération demandée par l’utilisateur (U).
10. Procédé de sécurisation d’opérations selon la revendication 9, caractérisé en ce que l’étape (F40) d’émission de la requête de validation d’opération comprend l’émission d’une requête comportant des informations concernant l’opération demandée, et le procédé comprend une étape (F50) de récupération des données de l’utilisateur associée à la clé (CL), cette étape de récupération de données comprenant :
- la récupération de données de contrôle indiquant au moins une restriction par rapport aux opérations permises, et
- l’analyse des informations reçues concernant l’opération demandée pour déterminer si cette opération est ou non permise par rapport aux données de contrôle.
11. Procédé de sécurisation d’opérations selon la revendication 10, caractérisé en ce que :
- l’étape de récupération de données de contrôle comprend la récupération de données définissant au moins une restriction choisie dans le groupe consistant en :
- le type d’opération permise,
- la période temporelle pendant laquelle des opérations sont permises,
- la zone géographique où, ou à partir de laquelle, des opérations sont permises,
- le prestataire de service auprès duquel des opérations sont permises, et
- le prix associé à la réalisation de l’opération.
12. Procédé de sécurisation d’opérations selon la revendication 11 , caractérisé en ce qu’il comprend en outre une étape de paramétrage par l’utilisateur des restrictions définies par les données de contrôle.
13. Procédé informatisé de sécurisation d’opérations selon l’une quelconque des revendications 9 à 12, caractérisé en ce qu’il comprend, si les première et seconde versions (CC1 ,CC2) du code dynamique ne correspondent pas l’appareil (30) de certification, une étape de mise en œuvre d’un processus itératif consistant à acquérir une nouvelle version du code dynamique, à comparer la nouvelle version avec la première version (CC1 ) du code dynamique, et à répéter les étapes du processus itératif tant que le résultat de la comparaison est négatif et jusqu’à ce qu’un nombre n de versions du code aient été acquises et comparées avec la première version du code.
14. Procédé de sécurisation d’opérations selon l’une quelconque des revendications 9 à 13, caractérisé en ce que l’étape (F60) d’émission d’une demande de code dynamique par l’appareil (30) de certification comprend la transmission à un poste de l’utilisateur d’une demande de renseignements complémentaires et la validation de l’opération par l’appareil (30) de certification est conditionnée par les renseignements complémentaires fournis par le poste utilisateur.
15. Procédé de sécurisation d’opérations selon la revendication 10, caractérisé en ce que :
- la demande (REQ_OP) de mise en œuvre d’une opération est formulée par l’appareil de prestataire de service et comprend une demande de transmission d’un message à l’utilisateur associé à la clé (CL) ;
- l’étape (F50b) de récupération des données de l’utilisateur associée à la clé (CL), par l’appareil (30) de certification, comprend la récupération de données de contrôle indiquant des paramètres anti-spam de l’utilisateur et la récupération de coordonnées de l’utilisateur ;
- les étapes d’émission de demande de code dynamique et de génération des première et seconde versions du code dynamique sont omises ; et
- l’étape (F100b) de transmission du signal de validation de l’opération demandée comprend la transmission du message (TX_ MES) à l’utilisateur selon les coordonnées récupérées par l’appareil de certification lorsque l’appareil de certification constate que la transmission du message est compatible avec les paramètres anti-spam de l’utilisateur.
PCT/FR2019/052926 2018-12-21 2019-12-04 Procédé et système de sécurisation d'opérations, et poste utilisateur associé WO2020128203A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201980092192.4A CN113475047B (zh) 2018-12-21 2019-12-04 用于保护操作的方法和系统以及相关联的用户站
EP19839364.7A EP3900293A1 (fr) 2018-12-21 2019-12-04 Procédé et système de sécurisation d'opérations, et poste utilisateur associé
US17/416,114 US20220078183A1 (en) 2018-12-21 2019-12-04 Method and system for securing operations and associated user station

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1874079 2018-12-21
FR1874079A FR3090934A1 (fr) 2018-12-21 2018-12-21 Procédé et système de sécurisation d’opérations, et poste utilisateur associé

Publications (1)

Publication Number Publication Date
WO2020128203A1 true WO2020128203A1 (fr) 2020-06-25

Family

ID=66867312

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2019/052926 WO2020128203A1 (fr) 2018-12-21 2019-12-04 Procédé et système de sécurisation d'opérations, et poste utilisateur associé

Country Status (5)

Country Link
US (1) US20220078183A1 (fr)
EP (1) EP3900293A1 (fr)
CN (1) CN113475047B (fr)
FR (1) FR3090934A1 (fr)
WO (1) WO2020128203A1 (fr)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1295264A1 (fr) * 2000-06-09 2003-03-26 Sami Atig Procede de securisation de transactions effectuees au moyen de cartes pourvues d'un numero d'identification du proprietaire
WO2009032523A1 (fr) * 2007-08-29 2009-03-12 American Express Travel Related Services Company, Inc. Système et procédé pour faciliter une transaction financière avec un identifiant généré dynamiquement
US20110184867A1 (en) * 2010-01-27 2011-07-28 Arcot Systems, Inc. System and method for generating a dynamic card value
WO2012160318A1 (fr) * 2011-05-25 2012-11-29 France Telecom Procede de paiement a distance, a partir d'un dispositif utilisateur, d'un panier d'achat sur un serveur marchand et systeme associe
FR3044789A1 (fr) 2015-12-08 2017-06-09 Orange Procede d'autorisation d'une transaction
WO2017196468A1 (fr) * 2016-05-13 2017-11-16 Symantec Corporation Systèmes et procédés de restriction, selon l'emplacement, de mots de passe à usage unique
FR3067499A1 (fr) * 2017-06-26 2018-12-14 Orange Controle de validite d'une interface de paiement a distance

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100213188B1 (ko) * 1996-10-05 1999-08-02 윤종용 사용자 인증 장치 및 방법
TW355899B (en) * 1997-01-30 1999-04-11 Qualcomm Inc Method and apparatus for performing financial transactions using a mobile communication unit
GB0017044D0 (en) * 2000-07-11 2000-08-30 Newt Limited Improvements relating to electronic transactions
US7240036B1 (en) * 2000-07-13 2007-07-03 Gtech Global Services Corporation Method and system for facilitation of wireless e-commerce transactions
US20060031174A1 (en) * 2004-07-20 2006-02-09 Scribocel, Inc. Method of authentication and indentification for computerized and networked systems
US8234220B2 (en) * 2007-02-21 2012-07-31 Weiss Kenneth P Universal secure registry
US8662384B2 (en) * 2006-02-28 2014-03-04 Google Inc. Text message payment
US20080103984A1 (en) * 2006-10-30 2008-05-01 Mobilekash, Inc. System, Method, and Computer-Readable Medium for Mobile Payment Authentication and Authorization
CN101803272B (zh) * 2007-06-26 2013-08-14 豌豆制造技术有限公司 认证系统和方法
US20090307140A1 (en) * 2008-06-06 2009-12-10 Upendra Mardikar Mobile device over-the-air (ota) registration and point-of-sale (pos) payment
WO2010031142A1 (fr) * 2008-09-22 2010-03-25 Joseph Elie Tefaye Procédé et système d’authentification d’utilisateur
AU2012220669A1 (en) * 2011-02-22 2013-05-02 Visa International Service Association Universal electronic payment apparatuses, methods and systems
US9830622B1 (en) * 2011-04-28 2017-11-28 Boku, Inc. Systems and methods to process donations
US20130226799A1 (en) * 2011-08-23 2013-08-29 Thanigaivel Ashwin Raj Authentication process for value transfer machine
GB2501267B (en) * 2012-04-17 2016-10-26 Bango Net Ltd Payment authentication systems
US9143492B2 (en) * 2013-03-15 2015-09-22 Fortinet, Inc. Soft token system
US20140379575A1 (en) * 2013-06-24 2014-12-25 Blackberry Limited Controlling transactions using near field communications device
US20150348044A1 (en) * 2014-05-30 2015-12-03 Verizon Patent And Licensing Inc. Secure credit card transactions based on a mobile device
SG11201703335QA (en) * 2014-11-25 2017-06-29 Einnovations Holdings Pte Ltd Transaction system and method
WO2016092318A1 (fr) * 2014-12-12 2016-06-16 Cryptomathic Ltd Systèmes et procédé permettant de générer une transaction sécurisée
AU2016220072B2 (en) * 2015-02-17 2020-01-02 Visa International Service Association Secure authentication of user and mobile device
US10915891B1 (en) * 2015-03-16 2021-02-09 Winklevoss Ip, Llc Autonomous devices
CA2982326A1 (fr) * 2015-04-07 2016-10-13 Omnyway, Inc. Procedes et systemes pour l'utilisation d'un dispositif mobile pour effectuer une transaction electronique securisee
US9769157B2 (en) * 2015-09-21 2017-09-19 American Express Travel Related Services Company, Inc. Systems and methods for secure one-time password validation
US10009340B2 (en) * 2016-03-25 2018-06-26 Fortinet, Inc. Secure, automatic second factor user authentication using push services
US10552823B1 (en) * 2016-03-25 2020-02-04 Early Warning Services, Llc System and method for authentication of a mobile device
US20220129903A1 (en) * 2016-11-10 2022-04-28 Jpmorgan Chase Bank, N.A. System and method for authentication and fraud detection based on iot enabled devices
SG10201706070TA (en) * 2017-07-25 2019-02-27 Mastercard International Inc Offline Payment Using Virtual Card Account Number
US11017389B2 (en) * 2018-01-10 2021-05-25 Mastercard International Incorporated Systems, methods and computer program products for OTP based authorization of electronic payment transactions
US11551232B2 (en) * 2018-12-20 2023-01-10 Capital One Services, Llc Microtransaction detection and authorization systems and methods

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1295264A1 (fr) * 2000-06-09 2003-03-26 Sami Atig Procede de securisation de transactions effectuees au moyen de cartes pourvues d'un numero d'identification du proprietaire
WO2009032523A1 (fr) * 2007-08-29 2009-03-12 American Express Travel Related Services Company, Inc. Système et procédé pour faciliter une transaction financière avec un identifiant généré dynamiquement
US20110184867A1 (en) * 2010-01-27 2011-07-28 Arcot Systems, Inc. System and method for generating a dynamic card value
WO2012160318A1 (fr) * 2011-05-25 2012-11-29 France Telecom Procede de paiement a distance, a partir d'un dispositif utilisateur, d'un panier d'achat sur un serveur marchand et systeme associe
FR3044789A1 (fr) 2015-12-08 2017-06-09 Orange Procede d'autorisation d'une transaction
WO2017196468A1 (fr) * 2016-05-13 2017-11-16 Symantec Corporation Systèmes et procédés de restriction, selon l'emplacement, de mots de passe à usage unique
FR3067499A1 (fr) * 2017-06-26 2018-12-14 Orange Controle de validite d'une interface de paiement a distance

Also Published As

Publication number Publication date
CN113475047B (zh) 2023-12-12
CN113475047A (zh) 2021-10-01
FR3090934A1 (fr) 2020-06-26
US20220078183A1 (en) 2022-03-10
EP3900293A1 (fr) 2021-10-27

Similar Documents

Publication Publication Date Title
EP3113099B1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
WO2009019298A1 (fr) Système d'information et procédé d'identification par un serveur d'application d'un utilisateur
WO2013021107A1 (fr) Procede, serveur et systeme d'authentification d'une personne
EP2353269A1 (fr) Procédé d'accès d'un utilisateur d'un terminal mobile à une pluralité de services et dispositif sécurisé associé
FR3110984A1 (fr) Partage sécurisé d'informations de justificatif d'identité
EP1250689A2 (fr) Systeme et procede de securisation des transmissions d'informations
FR2944400A1 (fr) Procede d'authentification aupres d'un serveur par un utilisateur d'un appareil mobile
WO2020128203A1 (fr) Procédé et système de sécurisation d'opérations, et poste utilisateur associé
EP2795830B1 (fr) Procede d'echange de donnee chiffree entre un terminal et une machine
FR3117629A1 (fr) Procédé de gestion de l’authentification d’un utilisateur d’un dispositif sur un équipement par mot de passe
EP2529330B1 (fr) Procédé de fourniture d'un code dynamique par l'intermédiaire d'un téléphone
WO2018029564A1 (fr) Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central
EP3395042B1 (fr) Serveur d'authentification pour le contrôle d'accès a un service
FR3060171B1 (fr) Procede de securisation de saisie de donnees, terminal de communication et programme correspondant.
WO2021053300A1 (fr) Procede de transmission d'une information complementaire relative a une transaction financiere
EP4099249A1 (fr) Procédé et dispositif de transmission d'un identifiant d'un utilisateur lors d'un paiement électronique réalisépar l utilisateur
EP4348459A1 (fr) Procédé de traitement d'une transaction, dispositif et programme correspondant
EP4105798A1 (fr) Procédé d authentification, dispositif et programme correspondant
FR3095867A1 (fr) Gestion d’un transfert de responsabilite local entre transitaires pour l’acheminement d’un colis
BE1015630A6 (fr) Carte binaire de paiement internet et les cinq systemes modulables.
FR2823399A1 (fr) Procede de gestion d'acces securise a des ressources numeriques d'un serveur, et systeme associe
FR3111444A1 (fr) Procédé d'acquisition et de traitement sécurisé d'une information secrète acquise
OA19567A (fr) Gestion d'un transfert de responsabilité local entre transitaires pour l'acheminement d'un colis.
FR3067488A1 (fr) Procede de gestion d'identifiants de fidelite, procede de traitement de donnees de fidelite, serveur, dispositif de transaction et programmes correspondants
WO2018115641A1 (fr) Sécurisation de transaction

Legal Events

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

Ref document number: 19839364

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019839364

Country of ref document: EP

Effective date: 20210721