FR2988250A1 - Method for validating transaction between server and personal computer of user, involves transmitting digital code from server to personal computer and mobile phone, and validating transaction if there is match between returned information - Google Patents

Abstract

The method involves transmitting a digital code (OTP) from a server (SRV) to a personal computer (PC) and a mobile phone (MOB), and returning information about the personal computer and the mobile phone. A transaction is validated if there is a match between the returned information, where the digital code is transformed into multimedia contents based on an encryption algorithm prior to transmission of the digital code to the personal computer and the mobile phone, and the transformation is based on a part of a series of quantified bits of the digital code. Independent claims are also included for the following: (1) a computer system (2) a computer program for validating a transaction between a server and a personal computer of a user.

Description

Process for validating a transaction TECHNICAL FIELD The invention relates to a method of validating a transaction whose object is for example the delivery of a service from a first device, in which a service provider is hosted, to a second device, via a network Communication. The method is able to guarantee that the user of the second device who will be delivered the service is the legitimate user. The first device is typically a server capable of rendering a software service and the second device a computer. The devices involved in the invention are generally equipped with physical and software resources including a processor. The communication network in question is any, for example the Internet network.

State of the art More and more services are now accessible via a computer and the Internet. These services most often need to know (and check) the identity of the user. Thus, it is possible to connect to his bank via the Internet, to shop online, book trips or connect to the network of his company to work remotely. The authentication of the user is therefore essential. In many cases, this authentication is done by a couple of information identifying and password. However, this simple authentication has shown its limits: - Trivial password chosen by users - Password copied to a paper next to the computer; - Always the same password chosen for all services; - In some cases, passwords are transmitted in clear; - Etc.

A third party can hope to recover a password and use it for malicious purposes. All these limits therefore make the current authentication means insufficient. The invention offers a solution that does not have the drawbacks of the state of the art.

The invention For this purpose, according to a functional aspect, the subject of the invention is a method of validating a transaction between a first device and a second device of a user, the user having in addition a device, said third device, able to communicate with the first device, characterized in that it comprises the following steps: - a step of transmitting information from the first device to both the second device and the third device, - a step of restitution of the information on the devices, - a step of validation of the transaction if there is correspondence between the information returned. A validation of a transaction is therefore preceded by a validation of the existence of a correspondence between two information retrieved on devices of the same user or group of users. The existence of a correspondence ensures the user that he does not validate a fraudulent action on the second device. The method of the invention ensures that the user who performs a transaction using the second device is a legitimate user namely the carrier of the third device, preferably previously authenticated. According to a particular embodiment of the invention, the information is a digital code and the transmission step is preceded by a step of transforming the code into multimedia content. This mode facilitates the step during which is checked whether the two rendered codes correspond to each other. Indeed, if the code is a binary code, the verification would consist of comparing each bit one after the other.

According to a first variant of this mode, the transformation is based on an encryption algorithm. Thus, if two pieces of information include bits, and if the two pieces of information differ only in a limited number of bits, the code resulting from the encryption will reveal a multitude of different bits. The difference is therefore more visible.

According to this variant, if the code comprises a series of bits, the result of the encryption of said sequence of bits comprises a series of encrypted bits, and in that the transformation is based on a part of the series of encrypted bits. Since the number of bits used is reduced, the consumption of resources in the first device during the transformation is reduced accordingly.

According to this same variant, if the CBC encryption algorithm sequentially encrypts the bits in blocks, each encryption including the current block to be encrypted and all or part of the previously encrypted blocks, the part of the series of encrypted bits is part of last bits of said series of encrypted bits. Indeed, the use of the last bits of the series resulting from the encryption guarantees an immediate visibility of a possible modification of the code. According to this same variant, the order of the bits of the portion of encrypted bits is reversed. As the mode used is of type CBC, as we saw previously, if two information differs, the last ciphered bits have more chance to make appear the modification than the first ones, consequently a reversal of the order of the selected bits offers an even bigger guarantee. According to a second variant, which may be implemented alternately or cumulatively with the first variant, the information including a series of bits, encrypted or not, the transformation includes a step of executing at least one module having as a parameter least one bit of the series, the execution of a module resulting in the return of a multimedia content. The rendering on the screens can be achieved in different ways, including the following.

In a first way, the step of validating the transaction is preceded by a step of validating the correspondence on the third device and a step of transmitting, from the third device, the validation to the first device. This first way ensures that the valid user is the legitimate user.

In a second way that can be implemented alternately or cumulatively with the first way, the information, said first information, is restored to the second device, the restitution further including at least a second information; then, the validation step further includes a step of selecting the first information on the second device; this validation step is followed by a step of transmitting, from the second device, the validation to the first device. This second way ensures that the valid user is in close proximity to the second device. According to a material aspect, the invention relates to a computer system comprising a first device able to communicate via a communication network with at least two devices, said second and third device, the second device being able to perform a transaction with the first device. device, characterized in that - the second device and the third comprise respective restitution means able to restore information from the first device, - and in that the third device comprises means for validating the correspondence between the information returned and transmission means capable of transmitting the validation of the correspondence to the first device. In this system, according to the method described above, the information retrieved is a multimedia content.

The invention also relates to a device, said first device, comprising communication means for communicating via a communication network with at least two devices, said second and third device, the second device being able to perform a transaction with the first device. device, characterized in that it comprises the following means: - means for transmitting information to the destination of both the second device and the third device, - means for validating the transaction if there is correspondence between the information returned. According to one variant, the information is a numerical code; The first device comprises for this purpose means for transforming the code into multimedia content. Finally, the invention relates to a computer program adapted to be implemented on the first device as defined above, the program comprising code instructions which, when executed by a processor performs the steps following of the method of the invention defined above - A step of transmitting information from the first device to both the second device and the third device, - a step of validating the transaction if there is a match The invention will be better understood on reading the description which follows, given by way of example and with reference to the appended drawings.

The figures: FIG. 1 represents a computer system on which an exemplary embodiment is illustrated. Figures 2 to 4 show the circuits of the devices involved in the method of the invention.

Figure 5 is a flowchart illustrating the various steps of the exemplary embodiment. Figure 6 is a screen view illustrating a variant of the exemplary embodiment. Figures 7a and 7b are two respective images illustrating a result of the transformation step described above. DETAILED DESCRIPTION OF AN EMBODIMENT EXPRESSING THE INVENTION FIG. 1 represents a SYS system comprising a first device able to communicate with a second device and a third device. This first device is illustrated by means of an SRV server. This server hosts a service that can be used by the second PC device. This service is any kind; this can be for example a service providing a weather report, or information. The second PC device is illustrated by means of a personal computer able to communicate with the outside via a first communication network RES for example an Internet network.

The system also comprises a third device illustrated by means of a MOB radio communication telephone capable of communicating via a second communication network, for example a so-called third generation 3G network.

In our example, the first and second devices belong to the same user UT, or even the same group of users. All the devices described above are equipped with physical and software resources. In the present case, with reference to FIGS. 2 to 4, the server comprises - a processor CPU1, said first processor, - storage means MEM1, said first storage means, - communication means COM1, said first means of communication to communicate with the outside via a communication network The computer PC comprises - a processor CPU2, said second processor, - storage means MEM2, said second storage means, - rendering means illustrated by an ECR2 screen, said second screen, - second communication means COM2 for communicating with the outside via the first communication network RES2 The MOB telephone comprises - a processor CPU3, said third processor, - storage means MEM3, said third storage means, - Restitution means illustrated by a screen ECR3, said third screen, - COM3 communication means, said third communication means, for communicating with the external In each device, the means are connected to the processor via a first bus BUS1, a second bus BUS2, and a third bus BUS3. Recall that a bus has the function of ensuring the transfer of digital data between the different circuits of a terminal. In our example, the bus in question includes a data bus and a control bus. It should also be noted that, in our example, the storage means described above are permanent memories, for example of ROM type (Read's acronym) and that the devices also include a respective RAM (not shown) serving unsustainably storing calculation data used in particular during the implementation of the method. One embodiment is described with reference to FIG. 5, in which an algorithm is represented which comprises the steps of an embodiment of the method of the invention. In our example, it is considered that initially the user UT is already authenticated for example with a telecommunication operator. It is also considered that the service provider hosted in the server is aware of the successful authentication of the second terminal with its operator, and that it maintains a trust relationship with this operator. In a first step, the user wishes to use the service. A request (REQ-> SRV) for access to the service is transmitted to the server SRV.

In a second step, in our example, strong authentication is performed. During this second step, the user provides parameters for authenticating for example - a pair (ID / PW) comprising an identifier, a password; - and a phone identifier for example the MSISDN phone number. A strong authentication is only an example of realization. This second step could have consisted simply in providing the identifier of the MSISDN phone only.

In a third step, once the authenticated user, the user accesses the service through the PC, and for example makes a purchase (ACHT) of a good online. In a fourth step, in our example, the SRV server generates a digital code (OTP), preferably single-use, and transmits it to both the computer and the MOB phone declared in the second step. Recall that the Anglo-Saxon term commonly used by the man to deserve for "single-use code" is "one time password". In a fifth step, after reception, the computer and the phone restores (RST-OTP-> ECR1, RST-OTP-> ECR2) on the screen the codes in question. In a sixth step, the user compares the codes. If they are identical, the user validates (VAL1) on his phone the fact that the codes are identical, guaranteeing the service provider that the user who has just validated is the legitimate user to know the one who carries out the transaction through the computer. For this purpose, with reference to FIG. 4, the telephone includes first MVAL1 validation means. In a seventh step, the SRV server receives the validation from the phone and validates (SRV-> VAL) the purchase of the good.

Note that the generated code can be a numeric code including any releasable character, especially on a screen when the code is a visual code. Note also that in the present description, it is necessary to distinguish a validation code made at the MOB phone, and possibly the PC, a transaction validation made at the SRV server. The embodiment described above may be subject to variants, including the following. The rendered numeric code can be long; the comparison step is therefore difficult to see error source because requires to compare each element of the code (bit by bit or character by character). For this purpose, according to a variant of the method, after the fourth step, after generation of the code, the latter is transformed into an image. In this way, in the fifth step, the images are rendered instead of the code. The sixth step is simplified because it is reduced to comparing two images instead of codes including several bits or characters. The transformation described above is advantageously based on an encryption algorithm known to those skilled in the art. In our example, the encryption algorithm is the AES algorithm (abbreviation of "Advanced Encryption Standard") preferably with a CBC (Cipher Block Chaining) known to those skilled in the art. According to the CBC mode, when encrypting information comprising several blocks of bits, an encryption of a block is based on the current block to be encrypted and on previously encrypted blocks. Thus, the least modification of a bit of a block has the consequence of making this modification appear at the end of the encryption of this modified block, but also of the following blocks. An image created based on the result of encryption as described below would therefore clearly show this change. We will see in the following description how the data blocks from the encryption are transformed into an image by means of MOD1-MODn software modules (n is an integer). The AES-256 algorithm - encrypts 128-bit multiple data blocks - with a 256-bit key. Accordingly, if the server-generated code is not a 128-bit multiple, bits are deleted or added to the generated code to form a 128-bit multiple code. Most often the addition is preferred in the current standards.

In our example, the code has a lower number of bits. The transformation module therefore adds a sufficient number of bits to arrive at a multiple of 128 bits. Consider that the generated code included K 128-bit blocks. The result of the encryption using the AES-256-CBC algorithm also includes K blocks of 128 bits. The method includes a step of creating an image from the resulting blocks of the encryption step. The server SRV stores in memory a plurality of MOD 1-MODn software modules that transforms the encrypted code into a geometrical figure to be rendered on the screens. The encrypted code is usually very long. If the block number of the generated code is K (K is an integer), the code length resulting from the encryption is K * 128bits. The algorithm used and the procedure used by the CBC are such that the last bits of the last blocks are enough to be sure that the initial generated code has been modified or not. Consider that the last bits corresponding to the result of the encryption are as follows: B1024B1023 .... B4B3B2B1 = 00100101 The last bits of the encrypted code being the most likely to provide an indication of a possible modification made by a malicious third party, an optional step consists in inverting the last bits and obtain the following order: B1B2B3B4B5 ... B1024 = 10100100 Consider the three (n = 3) software modules and the following respective parameters: - MOD1 (B2, B3, B4), - MOD2 ( B6, B7), - MOD3 (B9, B10) In order to reduce the number of module executions, a module executes if the first parameter is preceded by a bit equal to "1". Thus, for the first modulel module, the first bit B1 is 1; the modulel is thus executed. The modulel parameters are B2 = 0, B3 = 1, c = 0.

At this point, there are the following bits to process: 0100 The next digit is a 0, so the modulel will not be executed. At this point, there are the following bits to process: 100 The next digit is a 1, so module3 is executed. The parameters of module3 are B9 = 0 and B10 = 0.

The modules can be varied. The following list given as an example is not exhaustive. For example, a module provides: - a type of line and thickness of the frame of the image to be rendered - a background of the image to be rendered and its color - a type of line and a thickness of the line of a figure ( round, etc.) to render in the frame - a value, a color, a size, a style and a position of an alpha-numeric character to be rendered in the frame - a shape, a color, an amplitude and a frequency of a mathematical function to render in the frame. Figures 7a and 7b illustrate two images that could be created by the modules described above. According to another variant, the generated code is transformed into an image without an encryption algorithm using only the modules described above. The previous embodiment is based on the display of two images, hereinafter referred to as "first OTP code1" on two screens, one on the phone, the other on the computer, and a validation performed on the phone. According to a variant of the embodiment described above, the server generates several OTP1 and OTP2 codes, two in our example. In this configuration, the codes are transmitted to the computer, namely in the following form: o a first set of codes, represented for example in the form of a mosaic or matrix, including the first OTP code and other codes illustrated by letters A to K in FIG. 7b and represented in our example in the form of a matrix (or mosaic), and o a second OTP2 code. The codes are also transmitted to the telephone, namely: o the first OTP code1, o the second OTP2 code. In this configuration, with reference to the embodiment described above, the user validates the second code OTP2 from his phone if this code is the same on the phone and on the computer; In addition, the user selects the OTP1 code on the computer screen which he displays on his phone in the matrix and validates his selection on the computer by means of selection MSEL3. The computer is equipped with second MVAL2 validation means to validate the correspondence between codes. The selection is made by selection means MSEL2 and MSEL3 present on the PC and the phone, respectively, for example a computer mouse whose pointer is represented by an arrow in Figure 6. The selection means could also be a touch screen. Note that the validation order through the selection means is indifferent; indeed, the second code can be validated before the first code or vice versa. The server receives two validations, one from the phone and the other from the computer. This double action is an additional guarantee proving that the user is a legitimate user and not a malicious third party.20

Claims (14)

REVENDICATIONS1. A method of validating a transaction between a first device (SRV) and a second device (PC) of a user, the user further having a device (MOB), said third device, able to communicate with the first device ( SRV), characterized in that it comprises the following steps: a step of transmitting information (OTP1, OTP2) from the first device to both the second device and the third device; information on the devices, - A validation step of the transaction if there is correspondence between the information returned. 2. The communication method according to claim 1, characterized in that the information (OTP1, OTP2) is a code, and in that the transmission step is preceded by a step of transforming the code into multimedia content. 3. Method according to claim 2, characterized in that the transformation is based on an encryption algorithm. 4. Method according to claim 3, characterized in that the code comprises a series of bits, in that the result of the encryption of said sequence of bits comprises a series of encrypted bits, and in that the transformation is based on a part of the encrypted bit series. 5. Method according to claims 3 and 4, characterized in that the encryption algorithm (CBC) serializes the bits in blocks, each encryption including the current block to be encrypted and all or part of the previously encrypted blocks, in that the portion of the series of encrypted bits is one of the last bits of said series of encrypted bits. 6. Method according to claim 5, characterized in that the order of the bits of the encrypted bit part is reversed. 7. Method according to claim 4, characterized in that the information includes a series of bits and in that the transformation includes a step of executing at least one module having as parameter at least one bit of said series, execution of a module resulting in the reproduction of a multimedia content. 8. Method according to claim 1, characterized in that the information, said first information, is restored on the second device (PC), the restitution further including at least one second information (AK), in that the step validation method further includes a step of selecting the first information (OTP1) on the second device (PC), and in that it comprises a step of transmitting, from the second device (PC), the validation to the first device . 9. Method according to claim 1 or 8, characterized in that the step of validating the transaction is preceded by a step of validating the correspondence on the third device (MOB) and a transmission step, since the third device (MOB), from validation to the first device. A computer system comprising a first device (SRV) able to communicate via a communication network (RES) with at least two devices (PC, MOB), said second and third device, the second device being able to perform a transaction with the device. first device, characterized in that - the second device (PC) and the third device (MOB) comprise respective restitution means (ECR2, ECR3) able to restore information (IMG1, IMG2) from the first device, 2 9882 50 And in that the third device (MOB) comprises means for validating (MVAL1) the correspondence between the restored information and transmission means able to transmit the validation of the correspondence to the first device (SRV). 5 11. System according to claim 9, characterized in that the information retrieved is a multimedia content. 12. Device (SRV), said first device, comprising communication means (COM1) for communicating via a communication network with at least two devices, said second and third device, the second device being able to perform a transaction with the device. first device, characterized in that it comprises the following means: - means for transmitting information (IMG1, IMG2) to both the second device and the third device, - means for validating the transaction if there is correspondence between the information returned. 13. Device according to claim 12, characterized in that the information is a digital code, and in that it comprises means for transforming the code into multimedia content. 20 A computer program operable on a device as defined in claim 12, the program comprising code instructions which when executed by a processor performs the following steps defined in claim 1: A step of transmitting information (OTP1, OTP2) from the first device to the destination of both the second device and the third device; and a step of validating the transaction if there is correspondence between the information returned.