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)

Applications Claiming Priority (2)

Publications (1)

Family

ID=66867312

Family Applications (1)

Country Status (5)

Family Cites Families (37)

• 2018
  • 2018-12-21 FR FR1874079A patent/FR3090934A1/fr active Pending
• 2019
  • 2019-12-04 EP EP19839364.7A patent/EP3900293A1/de active Pending
  • 2019-12-04 US US17/416,114 patent/US20220078183A1/en active Pending
  • 2019-12-04 WO PCT/FR2019/052926 patent/WO2020128203A1/fr unknown
  • 2019-12-04 CN CN201980092192.4A patent/CN113475047B/zh active Active

Also Published As

Similar Documents

Legal Events