WO2014135526A1 - Système et procédé de gestion d'au moins une application en ligne, objet portable utilisateur usb et dispositif distant du système - Google Patents

Système et procédé de gestion d'au moins une application en ligne, objet portable utilisateur usb et dispositif distant du système Download PDF

Info

Publication number
WO2014135526A1
WO2014135526A1 PCT/EP2014/054158 EP2014054158W WO2014135526A1 WO 2014135526 A1 WO2014135526 A1 WO 2014135526A1 EP 2014054158 W EP2014054158 W EP 2014054158W WO 2014135526 A1 WO2014135526 A1 WO 2014135526A1
Authority
WO
WIPO (PCT)
Prior art keywords
client device
memory area
terminal
algorithm
host device
Prior art date
Application number
PCT/EP2014/054158
Other languages
English (en)
Inventor
Emmanuel Thibaudeau
Original Assignee
Plug-Up International
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Plug-Up International filed Critical Plug-Up International
Publication of WO2014135526A1 publication Critical patent/WO2014135526A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards

Definitions

  • the present invention relates to the field of securing the exchange of data between a host and a client, for example between a server and a portable and connectable electronic object. More specifically, the invention relates to a system comprising a portable USB device that can manage online applications.
  • One possible application is in the context of online games, for example, an online football game, handball, basketball, Formula 1, etc. to allow users to play by selecting using an interface displayed on a terminal a known player or sportsman stored on the server in the application and being represented in the game by this player.
  • a portable device comprising a marker such as a bar code read by a server-specific reader makes it possible to authenticate a user, but does not make it possible to ensure that the terminal also connected to the server is used by the user who authenticated. Finally even if the reader is integrated in the terminal this requires the addition of hardware and software.
  • the present invention therefore aims to overcome one or more of the disadvantages of the prior art by providing a simple system for controlling the physical connection of a portable device to the terminal without the addition of hardware or software and physical possession of the device portable by a user, while controlling the use of the portable device on a terminal for the installation of objects on an Internet page.
  • the invention relates to a system for managing at least one online application.
  • the system is characterized in that it comprises at least two devices acting as host or client, of which at least the client device is portable, a terminal communicating with a network via connection or communication means of the terminal, the client device connecting to the terminal via a terminal interface as a keyboard device, each device comprising at least one programmable non-volatile permanent memory zone and data processing means,
  • the terminal comprising a memory zone and data processing means
  • the system comprising an authentication algorithm
  • the memory area of the client device comprising a unique identifier and messages recorded in keyboard code and processed as such by the terminal
  • the memory area of the host device comprising at least one user identification algorithm, a validity verification algorithm the client device and an application execution algorithm
  • the memory zone of the host device further comprising a database comprising at least one file or table ID-MDP associating the user identifiers with the passwords of each user, a file or table EDU-IDCL associating at least one state of use of the client device with the unique identifier of a client device, an AURL-IDAPP file or table associating the URL address of the host device with an identifier of the application, a file or table IDUT-IDAPP associating the identifiers users with at least one identifier of the application,
  • the host device being identified by a URL
  • the memory area of the host device further comprising at least one application.
  • the interface of the terminal is USB type.
  • the memory area of the client device comprising a first counter incremented by the generation of a password and a shared secret key used by a module of the authentication algorithm in the client device,
  • the memory area of the client device further comprising at least the URL of the host device and an indication of the identification of the application in code interpreted by the terminal as a keyboard code
  • the memory area of the host device further comprising the secret key shared with the client device associated with a user and a file or table 2CMP-IDCL associating a second counter with the unique identifier of each client device.
  • the authentication algorithm comprises: a first module implemented by the processing means of the client device generating a first password from the shared secret key and the first counter to a rank n, the first module incrementing the first counter to a rank n + 1 when the first password is generated, the first module being stored in the memory area of the client device,
  • a second module implemented by the processing means of the host device generating a second password from the secret key shared and the second counter at a rank p, the second counter being that associated with the identifier of the client device from file or table 2CMP-IDCL, the second module being stored in the memory area of the host device,
  • a third module implemented by the processing means of the host device comparing the first password generated by the processing means of the client device and the second password generated by the processing means of the host device, the first password having been sent to the host device by the client device, the third module incrementing the second counter to rank p + 1 when the second password is generated, the third module being stored in the memory area of the host device.
  • the client device includes a usage file stored in a secret memory area of the client device, the usage file including a usage state information of the client device: a state corresponding to a usage state "Used" of the client device and a state corresponding to an "unused" usage state, the secret memory area of the memory area being accessible to the host device by a secure channel between the client device and the host device, the secure channel being opened by an algorithm for opening a secure channel.
  • the memory zone of the host device comprises an algorithm for opening a secure channel, an application for installing an algorithm for opening a secure channel between the client device and the host device and a game of three secret keys, the installation application being intended to be sent to the client device to install the opening algorithm on the terminal to control, by messages sent to the client device via the interface, the modification of the information of the usage file stored in the secret memory area of the client device, the memory area of the host device also comprising an algorithm for changing the information contained in the usage file.
  • the memory zone of the client device comprises a set of three secret keys identical to the set of three secret keys of the host device, the terminal comprising the algorithm for opening a secure channel.
  • the application sends commands or messages to the terminal for displaying an image stored in the memory area of the host device by the display means of the terminal according to image placement coordinates in the device. display of an Internet page.
  • the application sends commands or messages to the terminal for displaying an animation stored in the memory area of the host device by the display means of the terminal according to placement coordinates of the animation in the device. display of an Internet page.
  • the invention also relates to a method for managing at least one application implemented by the system according to the invention, the terminal comprising at least one connection to an Internet network, a means of capture and a means display device characterized in that the method comprises at least:
  • the method further comprising a user identification step implemented by the user identification algorithm
  • the method further comprising a step of verifying the validity of the client device,
  • the method further comprising a step of executing the application.
  • the step of connecting to the URL of the host device includes:
  • a step of sending by the client device to the host device the unique identifier of the client device a step of sending by the client device to the host device the unique identifier of the client device.
  • the authentication step implemented by the authentication algorithm comprises:
  • the second counter being incremented to a rank p + 1 and the client device being authenticated.
  • the identification step implemented by the user identification algorithm comprises the following substeps:
  • a decryption step by the processing means of the host device and verification of the identifier and the password by the identification algorithm from the file or table ID-MDP of the database stored in the zone; memory of the client device;
  • the file or table ID-MDP of the database includes the identifier of the user associated with the password entered by the user, the user being identified.
  • the step of verifying the validity of the client device implemented by the validity verification algorithm comprises:
  • the client device validity check step implemented by the validity check algorithm includes;
  • the method comprising:
  • the client device being validated.
  • the execution step of the application implemented by the application execution algorithm comprises:
  • the method comprises an execution step by the processing means of the terminal or the processing means of the host device the application or applications associated with another or other client devices without running the application associated with the client device;
  • the method comprising:
  • the authentication step is followed by an installation step by the terminal processing means of an algorithm for opening a secure channel, an installation application of the algorithm of opening a secure channel that has been sent by the host device.
  • the step of modifying the information of use of the state "not used” in "used” state corresponds to the modification of the information of the usage file stored in the secret memory zone of the client device after a step of opening a secure channel by an opening algorithm of a secure channel implemented by the processing means of the host device and the terminal.
  • the algorithm for opening a secure channel is performed via a triple DES algorithm and a set of three secret keys according to a specified security protocol of the GlobalPIatform type, the triple DES algorithm and the set of three secret keys being stored in the memory area of the host device and the client device,
  • the algorithm for opening a secure channel comprises:
  • a logon step by the host device processing means followed by the generation of a session counter by the client device sent to the host device, the session counter being incremented each time a new one is opened; session,
  • h a step of generation by the processing means of the host device (H) of a host cryptogram, via the triple DES algorithm using the derived key S-ENC, the random host number and the client random number,
  • the step of modifying the information of use of the "unused" state in "used” state of use means the state change associated with the unique identifier of the client device on the EDU-IDCL file or table.
  • the invention also relates to a portable user device forming a client device of the system according to the invention and comprising a non-volatile secure memory area, connection means to a terminal interface and data processing means, the memory zone comprising at least one unique identifier and messages recorded in keyboard code and processed as such by the terminal.
  • connection means are of the type
  • the memory zone of the portable device comprises a first counter incremented by the generation of a password and a shared secret key
  • the memory area of the portable device further comprising at least the URL of the host device and an indication of the identification of the application and the unique identifier of the portable device in code interpreted by the terminal as a keyboard code.
  • the memory zone of the portable device comprises a first module implemented by the processing means of the portable device generating a first password from the shared secret key and the first counter to a rank n, the first module incrementing the first counter to a rank n + 1 when the first password is generated.
  • the portable device comprises a usage file stored in a secret memory area of the portable device, the usage file including a state of use information of the portable device; a state corresponding to a "used" state of use of the portable device and a state corresponding to an "unused" usage state, the secret memory zone comprising the utilization file being accessible to the server by a secure channel between the portable device and the remote device, the secure channel being opened by an algorithm for opening a secure channel.
  • the memory zone of the portable device comprises an algorithm for opening a secure channel and a set of three secret keys identical to the set of three secret keys of the remote device.
  • the invention also relates to a remote device forming a host device of the system according to the invention, comprising a non-volatile secure memory area, communication means and data processing means, the remote device being characterized in that
  • the remote device is identified by a URL
  • the remote device memory zone comprising at least one user identification algorithm, a portable device validity verification algorithm, an application execution algorithm,
  • the memory zone of the remote device further comprising a database comprising at least one file or table ID-MDP associating the user identifiers with the passwords of each user of the client devices, an EDU-IDCL file or table associating with the minus a state of use of the portable device with the unique identifier of a portable device, an AURL-IDAPP file or table associating the URL of the remote device with an identifier of the application, a file or table IDUT-IDAPP associating the user identifiers with at least one identifier of the application,
  • the memory zone of the remote device further comprising at least one application.
  • the memory zone of the remote device comprises:
  • a second module implemented by the processing means of the remote device generating a second password from the shared secret key and the second counter at a rank p
  • a third module comparing the first password generated by the processing means of the portable device and the second password generated by the processing means of the remote device, the first password having been sent to the remote device by the portable device , the third module incrementing the second counter to a rank p + 1 when the second password is generated,
  • the memory zone of the host device comprises an algorithm for opening a secure channel, an application for installing an algorithm for opening a secure channel between the secret memory zone of the client device and the client.
  • host device and a set of three secret keys the installation application being intended to be sent to the client device to install the opening algorithm on the terminal to control, by messages sent to the client device via the interface, modifying the usage file information stored in the secret memory area of the client device.
  • FIG. 1 illustrates the portable device in one embodiment.
  • FIG. 2 illustrates the management system in one embodiment.
  • Figure 3 shows a flowchart illustrating the first part of the process.
  • Figure 4 shows the continuation of the flowchart of Figure 3 illustrating the method.
  • Figure 5 illustrates an example of an internet page representing a football field on which no player image has been installed.
  • Figure 6 illustrates the example of Figure 5 in which a player image has been installed.
  • Figure 7 illustrates the steps of opening a secure channel with GlobalPIatform specifications.
  • the management system of at least one online application comprises at least two devices acting as host (H) or client (Cl), of which at least the client device (Cl) is portable
  • the system may comprise a terminal (2) which communicates with a network (22) via means of connection or communication of the terminal (2)
  • the terminal (2) is a personal computer means which can be a laptop PC or desktop computer, a tablet, a smartphone or other equivalent means.
  • This computer means is connectable to a network (22) such as the Internet by means of connection or communication and comprising at least one interface, for example USB, for connecting a device or any other device connectable to the Internet, a means of display (21) and input means (23).
  • the input means (23) is connected by a bus to the processing means of the computer means and to a connector or connection means according to the same standard.
  • the processing means such as a processor, allow the execution of command lines sent to the computer means.
  • the input means (23) can be for example a computer keyboard.
  • the display means may be a touch screen or non-touch screen. In the case of a touch screen, the input means may be displayed on the screen.
  • the terminal (2) may also include a memory zone comprising at least one operating system and programs such as an Internet browser.
  • Each system device, client (C1) and host (H), comprises at least one programmable nonvolatile permanent memory zone and data processing means.
  • the system includes an authentication algorithm that, for example, ensures that the user uses the client device (C1).
  • the memory area of the client device (C1) includes a unique identifier.
  • the unique identifier may be the serial number of the client device.
  • the memory area of the client device (Cl) furthermore comprises messages stored in keyboard type HID code and processed as such by the terminal (2).
  • the memory area of the host device comprises at least one user identification algorithm, a client device validity checking algorithm (Cl) and an application execution algorithm.
  • the memory zone of the host device (H) furthermore comprises a database comprising at least one file or table ID-MDP associating the user identifiers with the passwords of each user, an EDU-IDCL file or table associating with the user's password.
  • a state of use of the client device (Cl) with the unique identifier of a client device (Cl) a file or table AURL-IDAPP associating the URL address of the host device (H) with an identifier of the application, an IDUT-IDAPP file or table associating the user identifiers with at least one identifier of the application.
  • the word table is to be understood as being a file or a table.
  • the host device (H) can be identified by a URL.
  • This address can be associated with an indication identifying the application to be executed.
  • the URL may include the indication identifying the application to be executed on the web page.
  • the URL may be in the form "http://server.directory.com/ADFR" where "server.address.com” is a line of characters representing the address of the host device (H ) and "ADFR" is a line of characters giving an indication of the object to be installed on the Internet page.
  • the memory area of the host device (H) further comprises at least one application to be executed.
  • the application may be sending command lines or messages to the terminal (2) for displaying an image stored in the memory area of the host device (H) by the display means of the terminal (2) according to placement coordinates of the image in the display of an Internet page.
  • the application may be sending command lines or messages to the terminal (2) for displaying an animation stored in the memory zone of the host device (H) by the display means of the terminal (2) according to placement coordinates of the animation in the display of an Internet page.
  • the client device (CI) or otherwise called portable device may be connectable to the terminal (2), for example a personal computer, connected to the local or wide area network.
  • portable device is meant a device that can be put for example in a pocket of clothing.
  • the portable client device (CI) is for example included in a chip card (1) comprising a body made of conventional synthetic material, for example ABS (acrylonitrile butadiene styrene) or PVC (polyvinyl chloride), according to an embodiment variant.
  • the body of the card (1) can be made of biodegradable material.
  • the client device (CI) may be a paper tag or a sticker.
  • the card (1) comprises a pre-cut detachable part intended to form a portable user object.
  • the detachable part of the card (1) is delimited by a linear recess (D) and is attached to the rest of the body. of the card (1) thanks to means of frangible connection thus interrupting (obviously linear.
  • the client device (C1) communicates with the host device (H) via the terminal (2).
  • the portable user object can be connected to a computer host via a USB type interface. or any other equivalent interface.
  • the computer host is in a non-limiting manner the terminal (2) of a user.
  • the portable device (Cl) user comprises in particular an electronic device secured to the body of the object for example with a conventional adhesive during a step of integration of the electronic device.
  • the electronic device comprises connection means (30) of the serial transmission computer bus type.
  • the electronic device is an electronic chip electrically connected according to the Universal Serial Bus (USB) standard to a vignette with electrically disjointed contact pads, manufactured according to a method known to those skilled in the art. ; the electronic chip is placed under the thumb pads with contact pads, then the electrical contacts of the chip are then connected to the contact pads of said sticker.
  • USB Universal Serial Bus
  • the electronic chip may comprise, for example and without limitation, at least one microcontroller, such as for example and without limitation a microprocessor comprising a volatile memory, a USB controller, one or more memory spaces, for example programmable permanent nonvolatile programmable memories integrated or not in the microcontroller.
  • a microcontroller such as for example and without limitation a microprocessor comprising a volatile memory, a USB controller, one or more memory spaces, for example programmable permanent nonvolatile programmable memories integrated or not in the microcontroller.
  • the clock signals, USB type devices are not transmitted by the USB connector, the chip will therefore include its integrated clock circuit or not in a microcontroller.
  • This clock circuit may, for example and without limitation, include a resonator or a quartz.
  • the contact pads are formed by an eight-button sticker. Unlike the ISO 7816 thumbnails conventionally used on a smart card (1), the contact areas corresponding to ISO contacts C1 to C4 have been lengthened to match the dimensions of the thumbnail contact pads with those of a USB connector while complying with the 7816-2 standard for contact dimensions and location. For this, the length of the contact pads corresponding to the ISO contacts C5 to C8 has been shortened. Since a USB connector has only four tracks, the contact areas corresponding to the ISO contacts C5 to C8 will not be used. According to a first embodiment, these contact pads will each be isolated from each other but will not be wired to the microcircuit. According to another embodiment, the contact pads corresponding to the ISO contacts C5 to C8 may be isolated from the ISO contacts C2 to C4 but will not be isolated from each other and will be connected to the ISO contact C1 so as to form only one range of contacts.
  • the portable user object forms a computer component connectable according to the USB standard, a microcontroller of the electronic chip being programmed by programming means so that said portable object behaves as a human / machine interface, for example of the type keyboard, once connected, for example to a terminal (2).
  • the application management system therefore comprises at least two devices acting as host or client, at least the client device (C1) of which is portable, communicating via a terminal (2) with a network ( 22) via connection or communication means of the terminal (2) ⁇
  • the memory area of the client device (C1) may comprise at least one URL address of the host device (H) and an indication identifying the application to be executed.
  • the URL may include the indication identifying the application to be executed.
  • the memory area of the client device (C1) also comprises a first counter incremented by the generation of a password, a key shared between the client device and the host device and a unique identifier of the client device. client device (CI).
  • the first counter and the shared key are used by the authentication algorithm.
  • the memory zone of the host device (H) may also comprise a 2CMP-IDCL file or table associating a second counter with the unique identifier of each client device for implementing the authentication algorithm and the shared secret key between the device client (CI) and the host device (H).
  • the fifth file comprises a plurality of second counters each of which is associated with a client device (Cl).
  • the file or table 2CMP-IDCL can associate each client device with a second counter and a secret key shared between the host device (H) and a client device (C1).
  • the system authentication algorithm may be of the one-time password or one-time password type. This algorithm can be based, for the generation of passwords, on the HOTP (HMAC-based One-Time Password) algorithm published by the Internet Engineering Task Force (IETF) in accordance with RFC 4226.
  • the HOTP algorithm is itself based on the Hashed Message Authentication Code (HMAC) function and the SHA-1 (Se cure Hash Algorithm) algorithm.
  • the authentication algorithm may comprise a first module implemented by the client device processing means (C1) generating a first password from the shared secret key and the first counter to a rank n. The first module increments the first counter to a rank n + 1 when the first password is generated. This first module is stored in the memory area of the client device (Ci),
  • the authentication algorithm may furthermore comprise a second module implemented by the processing means of the host device (H) generating a second password from the shared secret key and the second counter at a rank p.
  • the second counter is the one associated with the unique identifier of the client device (Cl) from the file or table 2CMP- IDCL.
  • the shared secret key can also be associated with the unique identifier of the client device (Cl).
  • the second module is stored in the memory area of the host device (H).
  • the authentication algorithm may furthermore comprise a third module comparing the first password generated by the processing means of the client device (C1) and the second password generated by the processing means of the host device (H).
  • the first password is sent to the host device (H) by the client device (C1).
  • the third module increments the second counter to a rank p + 1 when the second password is generated.
  • the third module is stored in the memory area of the host device (H).
  • the client device (C1) comprises a usage file stored in a secret memory zone of the client device (C1).
  • This secret memory zone may be included in the memory area of the client device or may be a memory area that is independent of the client device (C1).
  • This secret memory zone is only accessible via a secure channel.
  • the usage file includes a usage state information of the client device (C1): a state corresponding to a usage state "used” of the client device (C1) and a state corresponding to a usage state " Not used ".
  • the file is accessible to the host device (H) through a secure channel between the client device (C1) and the host device (H). This secure channel is opened by an algorithm for opening a secure channel.
  • the memory zone of the host device (H) comprises the algorithm for opening a secure channel. Its memory area also includes an application for installing this algorithm for opening a secure channel between the client device (C1) and the host device (H) and a set of three secret keys.
  • the installation application is intended to be sent to the client device (Cl) to install the opening algorithm on the terminal (2) in order to control, by sent messages to the client device (Cl) via the interface, modifying the usage file information stored in the memory area of the client device (Cl).
  • the memory area of the client device (C1) may already comprise a set of three secret keys identical to the set of three secret keys of the host device (H).
  • the memory area of the terminal may already include an algorithm for opening a secure channel. This case can be encountered when, for example, the client device (Cl) has already been connected to the host device (H) via the same terminal (2).
  • the invention also relates to a method for managing at least one application. This method is implemented by the system according to the invention.
  • the method includes a step of connecting to the URL address of the host device (H) provided by a client device (C1) read by the terminal.
  • a program of the client device (C1) commands the sending of a message including codes by the client device processing means so that the client device behaves as a keyboard-type human / machine interface and the memory area of the terminal (2) comprises at least one identifier for identifying the client device (C1) connected as a human-machine interface keyboard.
  • the program also orders the sending of a message including codes (HID generic) by the processing means of the client device so that the client device behaves as a man / machine control interface managing the information coming from the terminal .
  • the operating system of the terminal (2) can automatically execute a connection of the client device (C1) to the URL stored in the memory area of the client device (Cl).
  • an autorun.inf file is included at the root of the memory area of the client device (Cl).
  • This program makes it possible, for example, to open an Internet browser program included, for example, in the memory area of the terminal (2) on the page corresponding to the URL address stored in the memory area of the client device (Cl).
  • the user searches in the memory area of the client device (C1) for a file allowing the opening of an Internet browser program included in the memory area of the terminal (2) on the page corresponding to the URL address stored in the memory area of the client device (Cl).
  • the method also comprises a step of authentication of the client device (C1) implemented by the authentication algorithm. If the client device (C1) is authenticated, the method further comprises a user identification step. implemented by the user identification algorithm.
  • the method further comprises a step of verifying the validity of the client device (Cl). If the client device (C1) is validated, the method further comprises a step of executing the application.
  • the client device (C1) is connected to the URL (100a) of the host device (H) stored in the memory area of the client device (Cl) via a connection to the terminal (2).
  • the operating system of the terminal (2) can identify (100b) the client device (C1) which sends a unique identifier of the client device (C1) to host device (H).
  • the following step is a step (101) of authentication of the client device (Cl) by the authentication algorithm. This step can be triggered by the host device (H) when the client device (C1) is connected to the host device (H).
  • This algorithm comprises at least one step (101 1) of generation, by the first module which is implemented by the client device processing means (C1), of a first password from the shared secret key and from the first counter to a rank n.
  • the algorithm executes a step (1012) of incrementing the first counter to a rank n + 1.
  • the second counter is the one associated with the unique identifier of the client device (C1) connected from the file or table 2CMP-IDCL.
  • the algorithm executes a step (1016) of sending by the client device (C1) to the host device (H) of the first password.
  • a comparison step (1015) by the third module implemented by the processing means of the host device (H), the first password is compared with the second password.
  • the second counter is incremented (1020) to a rank p + 1.
  • the processing means of the host device then modify the fifth file by modifying the rank of the second counter of rank p at rank p + 1.
  • the client device (Cl) is then authenticated (1021).
  • the process is stopped and the connection to the host device (H) is rejected (1018).
  • This authentication step (101) therefore makes it possible to control that a client device (C1) is physically connected to the terminal (2). Indeed, so that the client device (C1) can connect to the host device (H), the URL of the host device (H) is not sufficient.
  • the first password is required for the connection to be effective. For example, if a user enters the URL of the host device (H) in an internet browser program without a client device (Cl) being connected, no password is sent to the host device (H), the connection is rejected.
  • the generation of passwords can be based on the HOTP (HMAC-based One-Time Password) algorithm published by the Internet Engineering Task Force (IETF) in accordance with RFC Specification 4226 .
  • HOTP HMAC-based One-Time Password
  • IETF Internet Engineering Task Force
  • the method further comprises a user identification step (1022) by the user identification algorithm.
  • the algorithm sends commands to the terminal to perform the following steps by the terminal processing means.
  • a display step by means of display (21) of the terminal (2) of at least two input areas, the display being controlled by the identification algorithm.
  • a cursor displayed on the first input area makes it possible to perform the step (1023) of inputting an identifier of the user by the input means of the terminal (2) in the first input area.
  • the cursor is displayed in the second input area to perform the step of entering (1023) a password associated with the user's identifier by the input means of the terminal (2) in the second input area.
  • the user validates the identifier and the password using the input means (23) by pressing for example a validation key input means (23).
  • the password and / or the identifier can be encrypted (1024) by the processing means of the client device (C1). After the encryption (1024), the encrypted identifier and / or password are sent (1025) to the host device (H). If the identifier and / or the password are encrypted, a decryption step (1026) is performed by the processing means of the host device (H).
  • the identifier and the password are then verified by the identification algorithm from the ID-MDP table of the database stored in the memory area of the client device (C1). If the database includes the identifier of the user associated with the password entered by the user, the user is identified (1029).
  • the identification algorithm can also provide the ability to add a user account by commands sent to the terminal to perform the following steps.
  • the display means (21) of the terminal (2) display at least two input zones
  • the display may also include the possibility of adding an account.
  • the display may, for example, present a link that leads to an Internet page displaying a registration form requesting at least one user identifier and the password of the user.
  • the identification algorithm can also give the possibility of not identifying. In this case, the user is not identified and the connection is rejected.
  • the method further comprises a step of verifying the validity of the client device (Cl).
  • This verification step is performed by the client device validity verification algorithm (C1) implemented by the processing means of the host device (H).
  • the verification step (1030) of validity of the client device (C1) makes it possible to know whether the application has already been executed or not. Thus, the same client device (Cl) does not allow the application associated with the client device (Cl) to be executed from other user identifiers.
  • the verification step may comprise at least one step of sending by the client device (C1) to the host device (H) the unique identifier of the client device (C1). This sending step can also be performed before the authentication step (101) or before the identification step (1022) of the user.
  • the processing means of the host device (H) then perform a check, from the EDU-IDCL table, of the state of use of the client device (C1) from the unique identifier of the client device (C1).
  • This EDU-IDCL table associates the unique identifiers of the client devices with their usage status or usage information.
  • the usage state is that the application associated with the client device (CI) has already been executed or not. If the application associated with the client device (C1) has already been executed "the state associated with the unique identifier of the client device (Ci) indicated in the EDU-IDCL table is the" used "state, for example” 0 ". On the other hand, if the application has never been executed, the state associated with the unique identifier of the client device (CI) indicated in the EDU-IDCL table is the "unused" state, for example "1",
  • This step may be followed by a step (1033) of possible execution of the eventual or possible other applications by the processing means of the host device or the terminal.
  • the application associated with a client device can not be executed on another user account if it has already been executed once.
  • the number of executions can be greater than one time by adding in the table IDUT-IDAPP information indicating the number of times for which the application can be executed.
  • the client device (CI) is validated.
  • the verification step (1030a) consists in verifying, in the utilization file stored in the secret memory zone of the client device (C1), the information of the state of use of the client device (C1) after a step of opening (1030b) a secure channel by an algorithm for opening a secure channel.
  • the opening of a secure channel is described below.
  • the application is executed by the application execution algorithm according to the following steps.
  • the method comprises a step of execution by the terminal processing means or the means for processing the host device of the one or more applications associated with another or other client devices without executing the application associated with the client device (C1).
  • the method comprises:
  • a step (1038, 1039) of modifying the usage information from the "unused” state to pass the usage information to the "used” state can also precede the display step.
  • the method may also include the following steps.
  • the step (1038) to change the "unused" usage state in the "used” usage state is the change the usage information from the "unused” state is changed to the "used” state of use corresponding to the state change in association with the unique identifier of the client device (CI) on the file or EDU-IDCL table.
  • the authentication step may be followed by an installation step (100d) by the terminal processing means (2) of a algorithm for opening a secure channel in the memory area of the terminal (2), the opening algorithm having been sent (100c) by the host device (H).
  • This algorithm can be a Java programmed app or a plugin-type application or software installed directly on the terminal's memory area (2) and implemented by the terminal processing means (2).
  • the step of modifying the usage information from the "unused" state to the "used” state corresponds to the modification (1039) of the usage file information stored in the memory area of the client device (Cl) by an algorithm for changing the information contained in the usage file after a step of opening (1039) a secure channel by an algorithm for opening a secure channel implemented by the means of processing of the host device (H) and the terminal (2). This is done to know if the application associated with the client device (Cl) has already been executed or not.
  • the host (H) and client (Cl) devices comprise at least one encryption / decryption algorithm and at least one set of encryption keys stored in the secret memory area of the client device (Cl), this area being inaccessible from the outside.
  • the keys of each game are symmetrical.
  • the encryption / decryption algorithm used is a so-called triple DES algorithm (3-DES, 20 DES coming from the English "Data Encryption stantard").
  • Each set of secret keys includes, for example, three secret 3-DES keys, denoted ENC, MAC and DEK.
  • the ENC key is a secret encryption key for the data, ensuring the confidentiality of the exchanged data.
  • the secret key MAC is a key to integrity.
  • the 3-DES algorithm using the secret key MAC on a data generates a digital signature accompanying each data encrypted by the algorithm and the key MAC. This digital signature ensures that data transferred from one device to another is not corrupted.
  • the DEK key is a secret key for encrypting confidential data, and provides additional protection for sensitive data, for example and without limitation, containing information concerning user data.
  • the host (H) and client (Cl) devices may comprise an operating system, implemented by the processing means, including the algorithms and the commands necessary for opening a channel.
  • secure having the GlobalPiatform specifications allowing the secure exchange of data between the client, for example a portable user object (Cl), and the host (H), for example a server.
  • the method of opening a secure channel having GlobalPiatform specifications between the client device (C1) and the host device (H) will now be described.
  • the opening of this channel is performed via a 3-DES algorithm stored in a non-volatile secure memory area of the host device and the client device, and a set of three secret keys ENC, MAC and DEK stored in a secret memory area of each device (H, Cl), not accessible from the outside.
  • the processing means of the host device (H) control the opening of a new session.
  • Information indicating the opening of the session is sent to the client device (CI) by the processing means of the host device (H).
  • the client device processing means Upon receipt of this information, the client device processing means generates (60) a session counter (SC) incremented each time a new session is opened. This session counter is stored in a memory area of the client device (CI).
  • the processing means of the client device (C1) perform a derivation operation (501) of the three secret keys ENC, MAC and DEK, via the 3-DES algorithm using the session counter (SC) and a host random number (HC) generated by the processing means of the host device (H), said random number (HC) being sent (61) to the client device (C1) and stored in the memory of the client device.
  • a derivation operation (501) of the three secret keys ENC, MAC and DEK via the 3-DES algorithm using the session counter (SC) and a host random number (HC) generated by the processing means of the host device (H), said random number (HC) being sent (61) to the client device (C1) and stored in the memory of the client device.
  • five secret derived keys are generated (90) by the processing means of the client device (C1), and stored in a memory area of the device (C1).
  • the first key named S-ENC
  • S-ENC makes it possible to encrypt the commands sent to one device (H, Cl) by the other device (H, Cl).
  • R-ENC is used to encrypt the responses sent to one device by the other device.
  • the two keys named C-MAC and R-MAC respectively allow to generate a signature for each command and for each answer sent, thus ensuring the integrity of the transferred data.
  • the fifth key is used to encrypt confidential data, whether commands or responses.
  • the client device processing means (C1) generates (504) a client cryptogram (Ccryptoc), via the algorithm 3- DES using the derived key S-ENC and the host random number (HC ) and a client random number (CC) generated by the processing means of the client device (C1).
  • a client cryptogram Ccryptoc
  • HC host random number
  • CC client random number
  • this client cryptogram (Ccryptoc), the session counter (SC) and the client random number (CC) are sent to the host device (H) by the processing means of the client device (Cl).
  • the client cryptogram (Ccryptoc), the session counter (SC) and the number random client (CC) are saved in a memory area of the host device (H).
  • the host device processing means (H) calculate (500, 80) the five derived keys S-ENC, R-ENC, C-MAC, R-MAK and S-DEK via the triple DES algorithm using the counter. session (SC) and the host random number (HC).
  • the processing means of the host device (H) compute (503) the client cryptogram (CcryptoH) via the triple DES algorithm using the derived key S-ENC, the host random number (HC ) and the client random number (CC).
  • the processing means of the host device (H) compare the client cryptograms (Ccryptoc, CcryptoH) respectively calculated by the client device (Cl) and the host device (H). If the two client cryptograms (Ccryptoc, CcryptoH) are identical, then the client device (C1) is authenticated by the processing means of the host device (H).
  • the processing means of the host device (H) calculates (502) a host cryptogram (HcryptoH), via the algorithm 3- DES using the derived key S-ENC, the random host number (HC) and the client random number (CC).
  • This host cryptogram (HcryptoH) is stored in a memory area of the host device (H).
  • this host cryptogram (HcryptoH) is sent (62) to the client device (C1) by the processing means of the host device (H).
  • the host cryptogram (HcryptoH) is stored in a memory area of the client device (Cl).
  • the processing means of the client device (C1) compute (505) the host cryptogram (Hcryptoc) via the 3-DES algorithm using the derived key S-ENC, the host random number (HC ) and the client random number (CC).
  • the client device processing means (Cl) compare the host cryptograms (HcryptoH, Hcryptoc) respectively calculated by the client device (CI) and the host device (H), If the two host cryptograms (HcryptoH, Hcryptoc) are identical, then the host device (H) is authenticated by the client device processing means (Cl) .
  • This process concludes with the confirmation of the opening of a secure channel (OSCS), through which the next commands and / or response generated by the host (H) and client (Cl) devices can be realized.
  • OSCS secure channel
  • This security channel makes it possible, for example, for the processing means of the host device (H) to modify the usage file stored in the memory of the client device (C1).
  • the unique identifier of the client device is associated with the state of use of the client device in the EDU-IDCL file or table stored in the memory area of the host device.
  • a usage file stored in the memory area of the client device includes client device usage status information (C1): a state corresponding to a "used” state of use of the client device (C1) and a state corresponding to a usage state " Not used ".
  • the usage state information is modified by the algorithm for changing the information contained in the usage file installed in the memory area of the terminal (2).
  • FIGS 5 and 6 show embodiments of the method.
  • the application is an application for installing an object such as an image on an Internet page (2000, 2001).
  • Figure 5 shows a football field on which player images can be installed.
  • the client device may have the form or an image of the player whose image can be installed on the football field shown on the web page.
  • Figure 6 shows the web page (2001) with an image (2002) of a player installed thanks to his client device. Subsequently, if this user reconnects his client device on his terminal, it will no longer have the ability to install another image of the player already installed through this client device, or the image of another player. But, the connection of his already used client device will allow him to go directly to the Internet page with his player images already installed with the use of eg password.
  • the application may give the possibility of choosing the player to add on the web page.
  • the application sends commands to the terminal processing means for displaying a window representing several choices of selectable players with information for designating the position of the player selected field displayed by the terminal display means.
  • the player may be selected by selection means.
  • These selection means may be at least one virtual key corresponding to the player of the terminal input means or at least one virtual key corresponding to the player of the display means of the terminal if the display means is, for example, a touch screen.
  • a file or a table can associate the name of the player with the user's name, last name or first name.

Abstract

L'invention concerne un système de gestion d'au moins une application en ligne caractérisé en ce qu'il comprend au moins deux dispositifs jouant le rôle d'hôte (H) ou de client (Cl), dont au moins te dispositif client (Cl) est portable USB, un terminal (2) communiquant avec un réseau (22) via des moyens de connexion ou de communication du terminal (2), le dispositif client (Cl) se connectant au terminal (2) par une interface du terminal du type USB comme périphérique clavier, chaque dispositif (H, Cl) comportant au moins une zone mémoire permanente non volatile programmable et des moyens de traitements des données, le terminal comprenant une zone mémoire et des moyens de traitement des données, le système comprenant un algorithme d'authentification, la zone mémoire du dispositif client (Cl) comprenant un identifiant unique et des messages enregistrés en code clavier et traités comme tel par le terminal (2), la zone mémoire du dispositif hôte (H) comprenant au moins un algorithme d'identification de l'utilisateur, un algorithme de vérification de validité du dispositif client (Cl) et un algorithme d'exécution d'application, la zone mémoire du dispositif hôte (H) comprenant en outre une base de données comprenant au moins un fichier ou tableau ID-MDP associant les identifiants d'utilisateurs avec les mots de passe de chaque utilisateur, un fichier ou tableau EDU-IDCL associant au moins un état d'utilisation du dispositif client (Cl) avec l'identifiant unique d'un dispositif client (Cl), un fichier ou tableau AURL-IDAPP associant l'adresse URL du dispositif hôte (H) avec un identifiant de l'application, un fichier ou tableau IDUT-IDAPP associant les identifiants d'utilisateurs avec au moins un identifiant de l'application, le dispositif hôte (H) étant identifié par une adresse URL, la zone mémoire du dispositif hôte (H) comprenant en outre au moins une application.

Description

Système et procédé de gestion d'au moins une application en ligne, objet portable utilisateur USB et dispositif distant du système
DOMAINE TECHNIQUE DE L'INVENTION
La présente invention se rapporte au domaine de la sécurisation des échanges de données entre un hôte et un client, par exemple entre un serveur et un objet électronique portable et connectable. Plus précisément, l'invention se rapporte à un système comprenant un dispositif portable USB pouvant gérer des applications en ligne.
Une application possible se situe dans le cadre de jeux en ligne, par exemple, un jeu de football en ligne, de handball, de basketball, de Formule 1 , etc. pour permettre à des utilisateurs de jouer en sélectionnant à l'aide d'une interface affichée sur un terminal un joueur ou un sportif connu mémorisé sur te serveur dans l'application et en se faisant représenter dans le jeu par ce joueur.
ARRIÈRE-PLAN TECHNOLOGIQUE DE L'INVENTION
L'échange de données numériques réalisé entre différents dispositifs connectés via un réseau local ou étendu pose un véritable problème de sécurité par une utilisation frauduleuse du dispositif portable, par exemple. En effet, plusieurs problèmes peuvent se poser.
Par exemple, il existe le problème de savoir comment être sûr que le dispositif portable est connecté ou permet une connexion d'un terminal au serveur distant. En effet, un utilisateur pourrait utiliser un terminal dans lequel il entre l'adresse URL du serveur pour se connecter au serveur distant et, ainsi, utiliser frauduleusement des applications dédiés au propriétaire du dispositif portable physique.
D'autre part un dispositif portable comprenant un marqueur tel qu'un code à barres lu par un lecteur spécifique à un serveur permet d'authentifier un utilisateur, mais ne permet pas de s'assurer que le terminal également connecté au serveur est utilisé par l'utilisateur qui s'est authentifié. Enfin même si le lecteur est intégré au terminal ceci nécessite l'adjonction de matériel et logiciel.
Il existe également le problème de savoir comment contrôler le nombre de fois pour lesquelles le dispositif portable est utilisé pour obtenir les applications auxquelles le dispositif portable donne droit.
DESCRIPTION GÉNÉRALE DE L'INVENTION
La présente invention a donc pour objet de pallier un ou plusieurs des inconvénients de l'art antérieur en proposant un système simple permettant de contrôler la connexion physique d'un dispositif portable au terminal sans adjonction de matériel ou de logiciel et la possession physique du dispositif portable par un utilisateur, tout en permettant de contrôler l'utilisation du dispositif portable sur un terminal pour l'installation d'objets sur une page Internet.
À cet effet, l'invention concerne un système de gestion d'au moins une application en ligne. Le système est caractérisé en ce qu'il comprend au moins deux dispositifs jouant le rôle d'hôte ou de client, dont au moins le dispositif client est portable, un terminal communiquant avec un réseau via des moyens de connexion ou de communication du terminal, le dispositif client se connectant au terminal par une interface du terminal comme périphérique clavier, chaque dispositif comportant au moins une zone mémoire permanente non volatile programmable et des moyens de traitements des données,
le terminal comprenant une zone mémoire et des moyens de traitement des données,
le système comprenant un algorithme d'authentification,
la zone mémoire du dispositif client comprenant un identifiant unique et des messages enregistrés en code clavier et traités comme tel par le terminal, la zone mémoire du dispositif hôte comprenant au moins un algorithme d'identification de l'utilisateur, un algorithme de vérification de validité du dispositif client et un algorithme d'exécution d'application, la zone mémoire du dispositif hôte comprenant en outre une base de données comprenant au moins un fichier ou tableau ID-MDP associant les identifiants d'utilisateurs avec les mots de passe de chaque utilisateur, un fichier ou tableau EDU-IDCL associant au moins un état d'utilisation du dispositif client avec l'identifiant unique d'un dispositif client, un fichier ou tableau AURL-IDAPP associant l'adresse URL du dispositif hôte avec un identifiant de l'application, un fichier ou tableau IDUT-IDAPP associant les identifiants d'utilisateurs avec au moins un identifiant de l'application,
le dispositif hôte étant identifié par une adresse URL,
la zone mémoire du dispositif hôte comprenant en outre au moins une application.
Selon une autre particularité, l'interface du terminal est de type USB.
Selon une autre particularité, la zone mémoire du dispositif client comprenant un premier compteur incrémenté par la génération d'un mot de passe et une clef secrète partagée utilisés par un module de l'algorithme d'authentification dans le dispositif client,
la zone mémoire du dispositif client comprenant en outre au moins l'adresse URL du dispositif hôte ainsi qu'une indication de l'identification de l'application en code interprété par le terminal comme un code clavier,
la zone mémoire du dispositif hôte comprenant en outre la clef secrète partagée avec le dispositif client associé à un utilisateur et un fichier ou tableau 2CMP-IDCL associant un deuxième compteur avec l'identifiant unique de chaque dispositif client.
Selon une autre particularité, l'algorithme d'authentification comprend : un premier module mis en œuvre par les moyens de traitement du dispositif client générant un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n, le premier module incrémentant le premier compteur à un rang n+1 lorsque le premier mot de passe est généré, le premier module étant stocké dans la zone mémoire du dispositif client,
un deuxième module mis en oeuvre par les moyens de traitement du dispositif hôte générant un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p, le deuxième compteur étant celui associé à l'identifiant du dispositif client à partir fichier ou tableau 2CMP- IDCL, le deuxième module étant stocké dans la zone mémoire du dispositif hôte,
un troisième module mis en œuvre par les moyens de traitement du dispositif hôte comparant le premier mot de passe généré par les moyens de traitement du dispositif client et le deuxième mot de passe généré par les moyens de traitement du dispositif hôte, le premier mot de passe ayant été envoyé au dispositif hôte par le dispositif client, le troisième module incrémentant le deuxième compteur à un rang p+1 lorsque le deuxième mot de passe est généré, le troisième module étant stocké dans la zone mémoire du dispositif hôte.
Selon une autre particularité, le dispositif client comprend un fichier d'utilisation stocké dans une zone mémoire secrète du dispositif client, le fichier d'utilisation comprenant une information d état d'utilisation du dispositif client : un état correspondant à un état d'utilisation « utilisé » du dispositif client et un état correspondant à un état d'utilisation « non utilisé », la zone mémoire secrète de la zone mémoire étant accessible au dispositif hôte par un canal sécurisé entre le dispositif client et le dispositif hôte, le canal sécurisé étant ouvert par un algorithme d'ouverture d'un canal sécurisé.
Selon une autre particularité, la zone mémoire du dispositif hôte comprend un algorithme d'ouverture d'un canal sécurisé, une application d'installation d'un algorithme d ouverture d'un canal sécurisé entre le dispositif client et le dispositif hôte et un jeu de trois clefs secrètes, l'application d'installation étant destinée à être envoyée au dispositif client pour installer l'algorithme d'ouverture sur le terminal pour commander, par des messages envoyés au dispositif client via l'interface, la modification de l'information du fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client, la zone mémoire du dispositif hôte comprenant également un algorithme de changement de l'information contenue dans le fichier d'utilisation. Selon une autre particularité, la zone mémoire du dispositif client comprend un jeu de trois clefs secrètes identique au jeu de trois clefs secrètes du dispositif hôte, le terminal comprenant l'algorithme d'ouverture d'un canal sécurisé.
Selon une autre particularité, l'application envoie des commandes ou messages au terminal permettant l'affichage d'une image stockée dans la zone mémoire du dispositif hôte par les moyens d'affichage du terminal selon des coordonnées de placement de l'image dans l'affichage d'une page Internet.
Selon une autre particularité, l'application envoie des commandes ou messages au terminal permettant l'affichage d'une animation stockée dans la zone mémoire du dispositif hôte par les moyens d'affichage du terminal selon des coordonnées de placement de l'animation dans l'affichage d'une page Internet.
Selon une autre particularité, l'invention concerne également un procédé de gestion d'au moins une application mis en œuvre par le système selon l'invention, le terminal comprenant au moins une connexion à un réseau Internet, un moyen de saisie et un moyen d'affichage caractérisé en ce que procédé comprend au moins :
une étape de connexion à l'adresse URL du dispositif hôte (H) fournie par un dispositif client lu par le terminal,
une étape d'authentification du dispositif client mise en œuvre par l'algorithme d'authentification,
si le dispositif client est authentifié, le procédé comprenant en outre une étape d'identification de l'utilisateur mise en œuvre par l'algorithme d'identification de l'utilisateur,
si l'utilisateur est identifié, le procédé comprenant en outre une étape de vérification de validité du dispositif client,
si le dispositif client est validé, le procédé comprenant en outre une étape d'exécution de l'application. Selon une autre particularité, l'étape de connexion à l'adresse URL du dispositif hôte comprend :
- une étape de connexion du dispositif client à l'adresse URL du dispositif hôte fournie par l'information stockée dans la zone mémoire du dispositif client par l'intermédiaire d'une connexion au terminal,
- une étape d'envoi par le dispositif client vers le dispositif hôte de l'identifiant unique du dispositif client.
Selon une autre particularité, l'étape d'authentification mise en œuvre par l'algorithme d'authentification comprend :
- une étape de génération, par le premier module mis en œuvre par les moyens de traitement du dispositif client, d'un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n,
- une étape d'incrémentation du premier compteur à un rang n+1 ,
- une étape de génération, par le deuxième module mis en œuvre par les moyens de traitement du dispositif hôte, d'un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p le deuxième compteur étant celui associé à l'identifiant unique du dispositif client à partir du fichier ou tableau 2CMP-IDCL,
- une étape d'envoi par le dispositif client au dispositif hôte du premier mot de passe via le terminal,
- une étape de comparaison, par le troisième module, du premier mot de passe et du deuxième mot de passe ;
si le premier mot de passe est identique au deuxième mot de passe, le deuxième compteur étant incrémenté à un rang p+1 et le dispositif client étant authentifié.
Selon une autre particularité, l'étape d'identification mise en œuvre par l'algorithme d'identification de l'utilisateur comprend les sous-étapes suivantes :
- une étape d'affichage par le moyen d'affichage du terminal d'au moins deux zones de saisie, l'affichage étant commandé par l'algorithme d'identification, - une étape de saisie d'un identifiant de l'utilisateur par les moyens de saisie du terminal dans la première zone de saisie,
- une étape de saisie d'un mot de passe associé à l'identifiant par les moyens de saisie du terminal dans la deuxième zone de saisie,
- une étape de cryptage par les moyens de traitement du terminal et d'envoi de l'identifiant et du mot de passe au dispositif hôte,
- une étape de décryptage par les moyens de traitement du dispositif hôte et de vérification de l'identifiant et du mot de passe par l'algorithme d'identification à partir du fichier ou tableau ID-MDP de la base de données stockée dans la zone mémoire du dispositif client ;
si le fichier ou tableau ID-MDP de la base de données comprend l'identifiant de l'utilisateur associé avec le mot de passe saisi par l'utilisateur, l'utilisateur étant identifié.
Selon une autre particularité, l'étape de vérification de validité du dispositif client mise en œuvre par l'algorithme de vérification de validité comprend :
- une étape de vérification, dans le tableau EDU-IDCL, de l'état d'utilisation du dispositif client à partir de l'identifiant unique du dispositif client ; si l'état d'utilisation correspond à un état « utilisé », le procédé comprenant :
- une étape de vérification d'une ou plusieurs applications associées à un autre ou d'autres dispositifs client à partir de l'identifiant de l'utilisateur d'après le tableau IDUT-IDAPP,
- une étape d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de la ou des autres applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client ;
si l'état d'utilisation correspond à un état « non utilisé », le dispositif client étant validé. Selon une autre particularité, l'étape de vérification de validité du dispositif client mise en œuvre par l'algorithme de vérification de validité comprend ;
- une étape de vérification, dans le fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client, de l'information de l'état d'utilisation du dispositif client après une étape d'ouverture d'un canal sécurisé par un algorithme d'ouverture d'un canal sécurisé ;
si l'état d'utilisation correspond à un état « utilisé », le procédé comprenant :
- une étape de vérification d'une ou plusieurs applications associées à un autre ou d'autres dispositifs client à partir de l'identifiant de l'utilisateur d'après le tableau IDUT-IDAPP,
- une étape d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de la ou des autres applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client ;
si l'état d'utilisation correspond à un état « non utilisé », le dispositif client étant validé.
Selon une autre particularité, l'étape d'exécution de l'application mise en œuvre par l'algorithme d'exécution d'application comprend :
- une étape de vérification de l'application à exécuter à partir de l'indication comprise dans ou associé à l'adresse URL stockée dans la zone mémoire du dispositif client d'après le tableau AURL-IDAPP,
- une étape d'envoi de commande par le dispositif hôte pour permettre l'affichage sur le moyen d'affichage du terminal d'une fenêtre présentant un choix d'exécution ou non de l'application à exécuter, la fenêtre représentant au moins une touche matérielle ou virtuelle permettant l'exécution de l'application et une touche matérielle ou virtuelle permettant le refus d'exécution de l'application,
- une étape de choix par les moyens de saisie du terminal par l'utilisateur, si l'utilisateur actionne le moyen de saisie de telle manière que la touche matérielle ou virtuelle permettant le refus d'exécution est validée, le procédé comprend une étape d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de la ou des applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client ;
si l'utilisateur actionne le moyen de saisie de telle manière que la touche matérielle ou virtuelle permettant l'exécution est validée, le procédé comprenant :
- une étape d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de la ou des applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client,
- une étape d'exécution de l'application par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de l'application associée au dispositif client,
- une étape de modification de l'information d'utilisation de l'état « non utilisé » pour passer l'information d'utilisation à l'état « utilisé »,
Selon une autre particularité, l'étape d'authentification est suivie d'une étape d'installation par les moyens de traitement du terminal d'un algorithme d'ouverture d'un canal sécurisé, une application d'installation de l'algorithme d'ouverture d'un canal sécurisé ayant été envoyée par le dispositif hôte.
Selon une autre particularité, lors de l'étape de choix, si l'utilisateur actionne le moyen de saisie de telle manière que la touche permettant l'exécution est validée, l'étape de modification de l'information d'utilisation de l'état « non utilisé » en état « utilisé » correspond à la modification de l'information du fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client après une étape d'ouverture d'un canal sécurisé par un algorithme d'ouverture d'un canal sécurisé mis en œuvre par les moyens de traitement du dispositif hôte et du terminal. Selon une autre particularité, l'algorithme d'ouverture d'un canal sécurisé est réalisée via un algorithme triple DES et un jeu de trois clefs secrètes selon un protocole de sécurité spécifié du type GlobalPIatform, l'algorithme triple DES et le jeu de trois clefs secrètes étant enregistrés dans la zone mémoire du dispositif hôte et du dispositif client,
l'algorithme d'ouverture d'un canal sécurisé comprend :
a) une étape d'ouverture de session par tes moyens de traitement du dispositif hôte, suivi de la génération d'un compteur de session par le dispositif client envoyé au dispositif hôte, le compteur de session étant incrémenté à chaque ouverture d'une nouvelle session,
b) une étape de dérivation des clefs secrètes enregistrées dans la mémoire du dispositif client, réalisé par les moyens de traitement dudit dispositif via l'algorithme triple DES utilisant le compteur de session et un nombre aléatoire hôte généré et envoyé au dispositif client par les moyens de traitement du dispositif hôte,
c) une étape de génération de cinq clefs dérivées S-ENC, R-ENC, C- MAC, R-MAC et S-DEK qui utilisées avec l'algorithme triple DES, permettent respectivement de chiffrer tes commandes envoyées à un dispositif, de chiffrer les réponses du dispositif, de générer une signature pour chaque commande, de générer une signature pour chaque réponse, et de chiffrer des données confidentielles,
d) une étape de génération par les moyens de traitement du dispositif client d'un cryptogramme client, via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte et un nombre aléatoire client généré par les moyens de traitement du dispositif client,
e) une étape d'envoi par les moyens de traitement du dispositif client vers le dispositif hôte, du compteur de session, du nombre aléatoire client et du cryptogramme client calculé à l'étape précédente, suivi du calcul et de la génération des cinq clefs dérivées par les moyens de traitement du dispositif hôte,
f) une étape de génération, par les moyens de traitement du dispositif hôte, du cryptogramme client via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte et le nombre aléatoire client généré par les moyens de traitement du dispositif client,
g) une étape de comparaison par les moyens de traitement du dispositif hôte des cryptogrammes client respectivement calculés par le dispositif client et le dispositif hôte, suivi de l'authentification du dispositif client si les deux calculs du cryptogramme client sont identiques,
h) une étape de génération par les moyens de traitement du dispositif hôte (H) d'un cryptogramme hôte, via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte et le nombre aléatoire client,
i) une étape d'envoi par les moyens de traitement du dispositif hôte vers le dispositif client, du cryptogramme hôte calculé à l'étape précédente, j) une étape de génération, par les moyens de traitement du dispositif client, du cryptogramme hôte via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte et le nombre aléatoire client,
k) une étape de comparaison par les moyens de traitement du dispositif client des cryptogrammes hôte respectivement calculés par le dispositif hôte et le dispositif client, suivi de l'authentification du dispositif hôte si les deux calculs du cryptogramme hôte sont identiques,
I) une étape de confirmation de l'ouverture d'une session et du canal sécurisé à travers lequel les prochaines commandes et/ou réponse générées par les dispositifs hôte et client seront réalisées.
Selon une autre particularité, lors de l'étape de choix, si l'utilisateur actionne le moyen de saisie de telle manière que la touche permettant l'exécution est validée, l'étape de modification de l'information d'utilisation de l'état « non utilisé » en état d'utilisation « utilisé » correspond à la modification de l'état en association avec l'identifiant unique du dispositif client sur le fichier ou tableau EDU-IDCL.
L'invention concerne également un dispositif portable utilisateur formant un dispositif client du système selon l'invention et comprenant une zone mémoire sécurisée non volatile, des moyens de connexion à une interface terminal et des moyens de traitement de données, la zone mémoire comprenant au moins un identifiant unique et des messages enregistrés en code clavier et traités comme tel par le terminal.
Selon une autre particularité, les moyens de connexion sont de type
USB. Selon une autre particularité, la zone mémoire du dispositif portable comprend un premier compteur incrémenté par la génération d'un mot de passe et une clef secrète partagée,
la zone mémoire du dispositif portable comprenant en outre au moins l'adresse URL du dispositif hôte ainsi qu'une indication de l'identification de l'application et l'identifiant unique du dispositif portable en code interprété par le terminal comme un code clavier.
Selon une autre particularité, la zone mémoire du dispositif portable comprend un premier module mis en œuvre par les moyens de traitement du dispositif portable générant un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n, le premier module incrémentant le premier compteur à un rang n+1 lorsque le premier mot de passe est généré.
Selon une autre particularité, le dispositif portable comprend un fichier d'utilisation stocké dans une zone mémoire secrète du dispositif portable, le fichier d'utilisation comprenant une information d'état d'utilisation du dispositif portable ; un état correspondant à un état d'utilisation « utilisé » du dispositif portable et un état correspondant à un état d'utilisation « non utilisé », la zone mémoire secrète comprenant le fichier d'utilisation étant accessible au serveur par un canal sécurisé entre le dispositif portable et le dispositif distant, le canal sécurisé étant ouvert par un algorithme d'ouverture d'un canal sécurisé. Selon une autre particularité, la zone mémoire du dispositif portable comprend un algorithme d'ouverture d'un canal sécurisé et un jeu de trois clefs secrètes identique au jeu de trois clefs secrètes du dispositif distant. L'invention concerne également un dispositif distant formant un dispositif hôte du système selon l'invention, comprenant une zone mémoire sécurisée non volatile, des moyens de communication et des moyens de traitement de données, le dispositif distant étant caractérisé en ce que
le dispositif distant est identifié par une adresse URL,
la zone mémoire du dispositif distant comprenant au moins un algorithme d'identification de l'utilisateur, un algorithme de vérification de validité du dispositif portable, un algorithme d'exécution d'application,
la zone mémoire du dispositif distant comprenant en outre une base de données comprenant au moins un fichier ou tableau ID-MDP associant les identifiants d'utilisateurs avec les mots de passe de chaque utilisateur des dispositifs client, un fichier ou tableau EDU-IDCL associant au moins un état d'utilisation du dispositif portable avec l'identifiant unique d'un dispositif portable, un fichier ou tableau AURL-IDAPP associant l'adresse URL du dispositif distant avec un identifiant de l'application, un fichier ou tableau IDUT- IDAPP associant les identifiants d'utilisateurs avec au moins un identifiant de l'application,
la zone mémoire du dispositif distant comprenant en outre au moins une application.
Selon une autre particularité, la zone mémoire du dispositif distant comprend :
un fichier ou tableau 2CMP-IDCL associant un deuxième compteur avec l'identifiant unique de chaque dispositif client,
un deuxième module mise en œuvre par les moyens de traitement du dispositif distant générant un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p,
un troisième module comparant le premier mot de passe généré par les moyens de traitement du dispositif portable et le deuxième mot de passe généré par les moyens de traitement du dispositif distant, le premier mot de passe ayant été étant envoyé au dispositif distant par le dispositif portable, le troisième module incrémentant le deuxième compteur à un rang p+1 lorsque le deuxième mot de passe est généré,
Selon une autre particularité, la zone mémoire du dispositif hôte comprend un algorithme d'ouverture d'un canal sécurisé, une application d'installation d'un algorithme d'ouverture d'un canal sécurisé entre la zone mémoire secrète du dispositif client et le dispositif hôte et un jeu de trois clefs secrètes, l'application d'installation étant destinée à être envoyée au dispositif client pour installer l'algorithme d'ouverture sur le terminal pour commander, par des messages envoyés au dispositif client via l'interface, la modification de l'information du fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client.
L'invention, avec ses caractéristiques et avantages, ressortira plus clairement à la lecture de la description faite en référence aux dessins annexés dans lesquels : La figure 1 illustre le dispositif portable dans un mode de réalisation.
La figure 2 illustre le système de gestion dans un mode de réalisation.
La figure 3 représente un organigramme illustrant la première partie du procédé.
La figure 4 représente la suite de l'organigramme de la figure 3 illustrant le procédé.
La figure 5 illustre un exemple de page internet représentant un terrain de football sur laquelle aucune image de joueur n'a été installée.
La figure 6 illustre l'exemple de la figure 5 dans lequel une image de joueur a été installée. La figure 7 illustre les étapes d'ouverture d'un canal sécurisé ayant les spécifications GlobalPIatform.
DESCRIPTION DES MODES DE RÉALISATION PRÉFÉRÉS DE
L'INVENTION L'invention va être décrite en référence aux figures énumérées ci- dessus.
Le système de gestion d'au moins une application en ligne comprend au moins deux dispositifs jouant le rôle d'hôte (H) ou de client (Cl), dont au moins le dispositif client (Cl) est portable
Le système peut comprendre un terminal (2) qui communique avec un réseau (22) via des moyens de connexion ou de communication du terminal (2)
On comprendra que le terminal (2) est un moyen informatique personnel qui peut être un ordinateur PC portable ou de bureau, une tablette, un smartphone ou autre moyen équivalent. Ce moyen informatique est connectable à un réseau (22) tel qu'Internet par des moyens de connexion ou communication et comprenant au moins une interface, par exemple USB, permettant de connecter un périphérique ou tout autre dispositif connectable à Internet, un moyen d'affichage (21 ) et un moyen de saisie (23). Le moyen de saisie (23) est connecté par un bus aux moyens de traitement du moyen informatique et à un connecteur ou moyen de connexion selon la même norme. Les moyens de traitement, tel qu'un processeur, permettent l'exécution de lignes de commande envoyées au moyen informatique. On comprendra que le moyen de saisie (23) peut être par exemple un clavier d'ordinateur. Le moyen d'affichage peut être un écran tactile ou non tactile. Dans le cas d'un écran tactile, le moyen de saisie peut être affiché sur l'écran. Le terminal (2) peut également comprendre une zone mémoire comprenant au moins un système d'exploitation et des programmes tel qu'un navigateur Internet.
Chaque dispositif du système, client (Cl) et hôte (H), comporte au moins une zone mémoire permanente non volatile programmable et des moyens de traitements des données.
Le système comprend un algorithme d'authentification permettant, par exemple, de s'assurer que l'utilisateur utilise le dispositif client (Cl). La zone mémoire du dispositif client (Cl) comprend un identifiant unique. L'identifiant unique peut être le numéro de série du dispositif client.
La zone mémoire du dispositif client (Cl) comprend en outre des messages enregistrés en code HID de type clavier et traités comme tel par le terminal (2).
La zone mémoire du dispositif hôte (H) comprend au moins un algorithme d'identification de l'utilisateur, un algorithme de vérification de validité du dispositif client (Cl) et un algorithme d'exécution d'application.
La zone mémoire du dispositif hôte (H) comprend en outre une base de données comprenant au moins un fichier ou tableau ID-MDP associant les identifiants d'utilisateurs avec les mots de passe de chaque utilisateur, un fichier ou tableau EDU-IDCL associant au moins un état d'utilisation du dispositif client (Cl) avec l'identifiant unique d'un dispositif client (Cl), un fichier ou tableau AURL-IDAPP associant l'adresse URL du dispositif hôte (H) avec un identifiant de l'application, un fichier ou tableau IDUT-IDAPP associant les identifiants d'utilisateurs avec au moins un identifiant de l'application.
Dans la suite de la description, le mot tableau est à comprendre comme étant un fichier ou un tableau.
Le dispositif hôte (H) peut être identifié par une adresse URL. Cette adresse peut être associée à une indication identifiant l'application à exécuter. Par exemple, l'adresse URL peut comprendre l'indication identifiant l'application à exécuter sur la page internet. Par exemple, l'adresse URL peut être de la forme « http://adresse.du.serveur.com/ADFR » où « adresse.du.serveur.com » une ligne de caractères représentant l'adresse du dispositif hôte (H) et « ADFR » est une ligne de caractères donnant une indication de l'objet à installer sur la page Internet. La zone mémoire du dispositif hôte (H) comprend en outre au moins une application à exécuter.
L'application peut être l'envoi de lignes de commandes ou messages au terminal (2) permettant l'affichage d'une image stockée dans la zone mémoire du dispositif hôte (H) par tes moyens d'affichage du terminal (2) selon des coordonnées de placement de l'image dans l'affichage d'une page Internet.
L'application peut être l'envoi de lignes de commandes ou messages au terminal (2) permettant l'affichage d'une animation stockée dans la zone mémoire du dispositif hôte (H) par les moyens d'affichage du terminal (2) selon des coordonnées de placement de l'animation dans l'affichage d'une page Internet.
D'autres types d'applications peuvent être stockées dans la zone mémoire du dispositif hôte.
Le dispositif client (CI) ou autrement appelé dispositif portable peut être connectable au terminal (2), par exemple un ordinateur personnel, relié au réseau local ou étendu. Par dispositif portable on entend un dispositif pouvant être mis par exemple dans une poche de vêtement. Le dispositif client (CI) portable est par exemple compris dans une carte à puce (1 ) comprenant un corps en matériau synthétique classique, par exemple en ABS (Acrylonitrile Butadiène Styrène) ou en PVC (Polychlorure de Vinyle), Selon une variante de réalisation, le corps de la carte (1 ) peut être réalisé en matière biodégradable. Dans un mode de réalisation, le dispositif client (CI) peut être une étiquette en papier ou un autocollant. Dans un mode de réalisation, la carte (1 ) comprend une partie détachable prédécoupée destinée à former un objet portable utilisateur, La partie détachable de la carte (1 ) est délimitée par un évidemment linéaire (D), et est accrochée au reste du corps de la carte (1 ) grâce à des moyens de liaison frangible interrompant donc ( évidemment linéaire. Le dispositif client (Cl) communique avec le dispositif hôte (H) par le terminal (2).
L'objet portable utilisateur peut être connecté à un hôte informatique via une interface de type USB. ou toute autre interface équivalente. L'hôte informatique est de façon non limitative le terminal (2) d'un utilisateur.
Selon un mode de réalisation, le dispositif portable (Cl) utilisateur comprend notamment un dispositif électronique solidarisé au corps de l'objet par exemple à l'aide d'un adhésif classique pendant une étape d'intégration du dispositif électronique. Le dispositif électronique comprend des moyens de connexion (30) de type bus informatique à transmission série. Dans certains modes de réalisation, le dispositif électronique est une puce électronique reliée électriquement selon la norme USB (de l'anglais, Universal Sériai Bus) à une vignette à plages de contact électriquement disjointes, fabriqué selon un procédé connu de l'homme du métier ; la puce électronique est placée sous la vignettes à plages de contact, puis les contacts électriques de la puce sont ensuite reliés aux plages de contact de ladite vignette.
Selon un mode de réalisation, la puce électronique peut comprendre, par exemple et de façon non limitative, au moins un microcontrôleur, comme par exemple et de façon non limitative un microprocesseur comprenant une mémoire volatile, un contrôleur USB, un ou plusieurs espaces mémoires, par exemple des mémoires sécurisées permanente non volatiles programmables intégrées ou non dans le microcontrôleur. Contrairement au cas des puces réalisées selon la norme ISO 7816, les signaux d'horloge, des périphériques de type USB, ne sont pas transmis par le connecteur USB, la puce comportera donc son circuit d'horloge intégré ou non dans un microcontrôleur. Ce circuit d'horloge pourra, par exemple et de façon non restrictive, comporter un résonateur ou un quartz.
Dans un mode de réalisation, les plages de contact sont réalisées par une vignette à huit contacts. Contrairement aux vignettes au format ISO 7816 classiquement utilisées sur une carte (1 ) à puce, les plages de contact correspondant aux contacts ISO C1 à C4 ont été rallongées de façon à faire correspondre les dimensions des plages de contact de fa vignette avec ceux d'un connecteur USB tout en respectant la norme 7816-2 relative aux dimensions et emplacement des contacts. Pour cela, la longueur des plages de contact correspondant aux contacts ISO C5 à C8 a été raccourcie. Un connecteur USB ne comprenant que quatre pistes, les plages de contact correspondant aux contacts ISO C5 à C8 ne seront donc pas utilisées. Suivant un premier mode de réalisation, ces plages de contact seront chacune isolées entre elles mais ne seront pas câblées au microcircuit. Suivant un autre mode de réalisation, les plages de contact correspondant aux contacts ISO C5 à C8 pourront être isolées des contacts ISO C2 à C4 mais ne seront pas isolées entre elles et seront reliées au contact ISO C1 de façon à ne former qu'une seule plage de contacts.
Ainsi, l'objet portable utilisateur forme un organe informatique connectable selon la norme USB, un microcontrôleur de la puce électronique étant programmé par des moyens de programmation de telle sorte que ledit objet portable se comporte comme une interface homme/machine, par exemple de type clavier, une fois connecté, par exemple à un terminal (2).
Le système de gestion d'application selon l'invention comprend donc au moins deux dispositifs jouant le rôle d'hôte ou de client, dont au moins le dispositif client (Cl) est portable, communiquant par un terminal (2) avec un réseau (22) via des moyens de connexion ou de communication du terminal (2)·
La zone mémoire du dispositif client (Cl) peut comprendre au moins une adresse URL du dispositif hôte (H) ainsi qu'une indication identifiant l'application à exécuter. Comme vu précédemment, l'adresse URL peut comprend l'indication identifiant l'application à exécuter.
La zone mémoire du dispositif client (Cl) comprend également un premier compteur incrémenté par la génération d'un mot de passe, une clef partagée entre le dispositif client et le dispositif hôte et un identifiant unique du dispositif client (CI). Le premier compteur et la clef partagée sont utilisés par l'algorithme d'authentification.
La zone mémoire du dispositif hôte (H) peut comprendre également un fichier ou tableau 2CMP-IDCL associant un deuxième compteur avec l'identifiant unique de chaque dispositif client pour mettre en œuvre l'algorithme d'authentification et la clef secrète partagée entre le dispositif client (CI) et le dispositif hôte (H).
Ainsi, le cinquième fichier comprend une pluralité de deuxièmes compteurs dont chacun est associé à un dispositif client (Cl). Selon un mode de réalisation, le fichier ou tableau 2CMP-IDCL peut associer chaque dispositif client à un deuxième compteur et une clef secrète partagée entre le dispositif hôte (H) et un dispositif client (Cl).
L'algorithme d'authentification du système peut être du type à mot de passe à usage unique ou « One -Time Password ». Cet algorithme peut être basé, pour la génération des mots de passe, sur l'algorithme HOTP (HMAC- based One-Time Password) publié par l'IETF (Internet Engineering Task Force) conforme à la spécification RFC 4226. L'algorithme HOTP est lui-même basé sur la fonction d'HMAC (Hashed Message Authentification Code) et l'algorithme SHA-1 (Se cure Hash Algorithm). L'algorithme d'authentification peut comprendre un premier module mis en œuvre par les moyens de traitement du dispositif client (Cl) générant un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n. Le premier module incrémente le premier compteur à un rang n+1 lorsque le premier mot de passe est généré. Ce premier module est stocké dans la zone mémoire du dispositif client (Ci),
L'algorithme d'authentification peut comprendre en outre un deuxième module mise en œuvre par les moyens de traitement du dispositif hôte (H) générant un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p. Le deuxième compteur est celui associé à l'identifiant unique du dispositif client (Cl) à partir du fichier ou tableau 2CMP- IDCL. Selon un mode de réalisation, la clef secrète partagée peut être aussi associée à l'identifiant unique du dispositif client (Cl). Le deuxième module est stocké dans la zone mémoire du dispositif hôte (H).
L'algorithme d'authentification peut comprendre en outre un troisième module comparant le premier mot de passe généré par les moyens de traitement du dispositif client (Cl) et le deuxième mot de passe généré par les moyens de traitement du dispositif hôte (H). Pour pouvoir être comparé, le premier mot de passe est envoyé au dispositif hôte (H) par le dispositif client (Cl). Le troisième module incrémente le deuxième compteur à un rang p+1 lorsque le deuxième mot de passe est généré. Le troisième module est stocké dans la zone mémoire du dispositif hôte (H).
Les mots de passe sont créés à partir de l'algorithme HOTP.
Dans un mode de réalisation particulier, le dispositif client (Cl) comprend un fichier d'utilisation stocké dans une zone mémoire secrète du dispositif client (Cl). Cette zone mémoire secrète peut être comprise dans la zone mémoire du dispositif client ou être une zone mémoire indépendante du dispositif client (Cl). Cette zone mémoire secrète n'est accessible que par un canal sécurisé. Le fichier d'utilisation comprend portant une information d'état d'utilisation du dispositif client (Cl) : un état correspondant à un état d'utilisation « utilisé » du dispositif client (Cl) et un état correspondant à un état d'utilisation « non utilisé ». Le fichier est accessible au dispositif hôte (H) par un canal sécurisé entre le dispositif client (Cl) et le dispositif hôte (H). Ce canal sécurisé est ouvert par un algorithme d'ouverture d'un canal sécurisé.
Dans ce mode de réalisation particulier, la zone mémoire du dispositif hôte (H) comprend l'algorithme d'ouverture d'un canal sécurisé. Sa zone mémoire comprend également une application permettant l'installation de cet algorithme d'ouverture d'un canal sécurisé entre le dispositif client (Cl) et le dispositif hôte (H) et un jeu de trois clefs secrètes. L'application d'installation est destinée à être envoyée au dispositif client (Cl) pour installer l'algorithme d'ouverture sur le terminal (2) afin de commander, par des messages envoyés au dispositif client (Cl) via l'interface, la modification de l'information du fichier d'utilisation stocké dans la zone mémoire du dispositif client (Cl).
Dans ce mode de réalisation particulier, la zone mémoire du dispositif client (Cl) peut déjà comprendre un jeu de trois clefs secrètes identiques au jeu de trois clefs secrètes du dispositif hôte (H). De même, la zone mémoire du terminal peut déjà comprendre un algorithme d'ouverture d'un canal sécurisé. Ce cas de figure peut se rencontré quand, par exemple, le dispositif client (Cl) a déjà été connecté au dispositif hôte (H) via le même terminal (2).
L'invention concerne également un procédé de gestion d'au moins une application. Ce procédé est mis en œuvre par le système selon l'invention.
Le procédé comprend une étape de connexion à l'adresse URL du dispositif hôte (H) fournie par un dispositif client (Cl) lu par le terminal.
Selon un mode de réalisation, après l'insertion du dispositif client (Cl) dans l'interface du terminal, un programme du dispositif client (Cl) commande l'envoi d'un message incluant des codes par les moyens de traitement du dispositif client de telle sorte que le dispositif client se comporte comme une interface homme/machine de type clavier et que la zone mémoire du terminal (2) comprend au moins un identifiant destiné à identifier le dispositif client (Cl) connecté comme étant une interface homme/machine clavier. Le programme commande aussi l'envoi d'un message incluant des codes (HID generic) par les moyens de traitement du dispositif client de telle sorte que le dispositif client se comporte comme une interface homme/machine de contrôle gérant les informations en provenance du terminal.
Selon un mode de réalisation, après que le dispositif client (Cl) est relié au terminal (2), le système d'exploitation du terminal (2) peut exécuter automatiquement une connexion du dispositif client (Cl) à l'adresse URL stockée dans la zone mémoire du dispositif client (Cl). Par exemple, dans un système d'exploitation tel que Windows, un fichier autorun.inf est compris à la racine de la zone mémoire du dispositif client (Cl). Ce programme permet, par exemple, d'ouvrir un programme navigateur Internet compris, par exemple, dans la zone mémoire du terminal (2) sur la page correspondant à l'adresse URL stockée dans la zone mémoire du dispositif client (Cl).
Selon un mode de réalisation, après que le dispositif client (Cl) est relié au terminal (2), l'utilisateur recherche dans la zone mémoire du dispositif client (Cl) un fichier permettant l'ouverture d'un programme navigateur Internet compris dans la zone mémoire du terminal (2) sur la page correspondant à l'adresse URL stockée dans la zone mémoire du dispositif client (Cl).
D'autres modes de réalisation sont envisageables.
Le procédé comprend également une étape d'authentification du dispositif client (Cl) mise en œuvre par l'algorithme d'authentification, Si le dispositif client (Cl) est authentifié, le procédé comprend en outre une étape d'identification de l'utilisateur mise en œuvre par l'algorithme d'identification de l'utilisateur.
Si l'utilisateur est identifié, le procédé comprend en outre une étape de vérification de validité du dispositif client (Cl). Si le dispositif client (Cl) est validé, le procédé comprend en outre une étape d'exécution de l'application.
Lors de l'étape (100) de connexion, le dispositif client (Cl) est connecté à l'adresse URL (100a) du dispositif hôte (H) stockée dans la zone mémoire du dispositif client (Cl) par l'intermédiaire d'une connexion au terminal (2).
Ainsi, lorsque le dispositif client (Cl) est relié au terminal (2), le système d'exploitation du terminal (2) peut identifier (100b) le dispositif client (Cl) qui envoie un identifiant unique du dispositif client (Cl) au dispositif hôte (H). L'étape qui suit est une étape (101 ) d'authentification du dispositif client (Cl) par l'algorithme d'authentification. Cette étape peut être déclenchée par le dispositif hôte (H) lorsque le dispositif client (Cl) est connecté au dispositif hôte (H).
Cet algorithme comprend au moins une étape (101 1 ) de génération, par le premier module qui est mis en œuvre par les moyens de traitement du dispositif client (Cl), d'un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n.
Lorsque le premier mot de passe a été généré, l'algorithme exécute une étape (1012) d'incrémentation du premier compteur à un rang n+1.
Parallèlement, une étape (1013) de génération, par le deuxième module qui est mis en œuvre par les moyens de traitement du dispositif hôte (H), d'un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p. Le deuxième compteur est celui associé à l'identifiant unique du dispositif client (Cl) connecté à partir du fichier ou tableau 2CMP- IDCL.
Lorsque le premier mot de passe a été généré, l'algorithme exécute une étape (1016) d'envoi par le dispositif client (Cl) au dispositif hôte (H) du premier mot de passe. Dans une étape (1015) de comparaison, par le troisième module mis en œuvre par les moyens de traitement du dispositif hôte (H), le premier mot de passe est comparé avec le deuxième mot de passe.
Si le premier mot de passe est identique au deuxième mot de passe (1019), le deuxième compteur étant incrémenté (1020) à un rang p+1 . Les moyens de traitement du dispositif hôte modifient alors le cinquième fichier en modifiant le rang du deuxième compteur du rang p au rang p+1 . Le dispositif client (Cl) est alors authentifié (1021 ).
En revanche, si le premier mot de passe est différent du deuxième mot de passe (1017) ou si aucun mot de passe n'est fourni par le dispositif client (Cl), le procédé est arrêté et la connexion au dispositif hôte (H) est rejetée (1018).
Cette étape (101 ) d'authentification permet donc de contrôler qu'un dispositif client (Cl) est relié physiquement au terminal (2), En effet, pour que le dispositif client (Cl) puisse se connecter au dispositif hôte (H), l'adresse URL du dispositif hôte (H) n'est pas suffisante. Le premier mot de passe est nécessaire pour que la connexion soit effective. Par exemple, si un utilisateur entre l'adresse URL du dispositif hôte (H) dans un programme navigateur internet sans qu'un dispositif client (Cl) ne soit connecté, aucun mot de passe n'est envoyé au dispositif hôte (H), la connexion est rejetée.
Comme il a déjà été décrit ci-avant, la génération des mots de passe peut être basée sur l'algorithme HOTP (HMAC-based One-Time Password) publié par l'IETF (internet Engineering Task Force) conforme à la spécification RFC 4226.
Si le dispositif client (Cl) est authentifié (1021 ), le procédé comprend en outre une étape d'identification (1022) de l'utilisateur par l'algorithme d'identification de l'utilisateur. L'algorithme envoie des commandes au terminal pour exécuter les étapes suivantes par les moyens de traitement du terminal. Une étape d'affichage par te moyen d'affichage (21) du terminal (2) d'au moins deux zones de saisie, l'affichage étant commandé par l'algorithme d'identification.
Un curseur affiché sur la première zones de saisie permet de réaliser l'étape (1023) de saisie d'un identifiant de l'utilisateur par les moyens de saisie du terminal (2) dans la première zone de saisie.
Après que l'identifiant est saisi dans la première zone de saisie, le curseur est affiché dans la deuxième zone de saisie pour réaliser l'étape de saisie (1023) d'un mot de passe associé à l'identifiant de l'utilisateur par les moyens de saisie du terminal (2) dans la deuxième zone de saisie. Après que l'identifiant est saisi dans la première zone de saisie et que le mot de passe associé à l'identifiant est saisi dans la deuxième zone de saisie, l'utilisateur valide l'identifiant et le mot de passe à l'aide du moyen de saisie (23) en appuyant par exemple sur une touche de validation du moyen de saisie (23).
Avant d'être envoyé au dispositif hôte (H), le mot de passe et/ou l'identifiant peuvent être cryptés (1024) par les moyens de traitement du dispositif client (Cl). Après le cryptage (1024), l'identifiant et/ou le mot de passe cryptés sont envoyés (1025) au dispositif hôte (H). Si l'identifiant et/ou le mot de passe sont cryptés, une étape (1026) de décryptage est exécutée par les moyens de traitement du dispositif hôte (H).
L'identifiant et le mot de passe sont alors vérifiés par l'algorithme d'identification à partir du tableau ID-MDP de la base de données stockée dans la zone mémoire du dispositif client (Cl). Si la base de données comprend l'identifiant de l'utilisateur associé avec le mot de passe saisi par l'utilisateur, l'utilisateur est identifié (1029).
Sinon, l'utilisateur n'est pas identifié (1027) et la connexion est rejetée (1028).
L'algorithme d'identification peut également donner la possibilité d'ajouter un compte d'utilisateur par des commandes envoyées au terminal permettant d'exécuter les étapes suivantes. Lors de l'affichage par le moyen d'affichage (21 ) du terminal (2) d'au moins deux zones de saisie, l'affichage peut comprendre aussi la possibilité d'ajouter un compte. L'affichage peut, par exemple, présenté un lien qui amène à une page Internet affichant un formulaire d'inscription demandant au moins un identifiant de l'utilisateur ainsi que le mot de passe de l'utilisateur. Après avoir rempli le formulaire d'inscription par les moyens de saisie du terminal (2) et après la validation du formulaire d'inscription par les moyens de saisie du terminal (2), les informations entrées par l'utilisateur sont stockées dans la zone mémoire du dispositif client (Ci). L'identifiant et le mot de passe de l'utilisateur sont stockés dans le tableau ID-MDP de la base de données du dispositif hôte (H).
L'algorithme d'identification peut également donner la possibilité de ne pas s'identifier. Dans ce cas, l'utilisateur n'est pas identifié et la connexion est rejetée.
Si l'utilisateur est identifié (1029), le procédé comprend en outre une étape de vérification de validité du dispositif client (Cl).
Cette étape de vérification est exécutée par l'algorithme de vérification de validité du dispositif client (Cl) mise en œuvre par les moyens de traitement du dispositif hôte (H).
L'étape de vérification (1030) de validité du dispositif client (Cl) permet de savoir si l'application a déjà été exécutée ou non. Ainsi, un même dispositif client (Cl) ne permet pas d'exécuter l'application associée au dispositif client (Cl) à partir d'autres identifiants d'utilisateur. L'étape de vérification peut comprendre au moins une étape d'envoi par le dispositif client (Cl) vers le dispositif hôte (H) de l'identifiant unique du dispositif client (Cl). Cette étape d'envoi peut être également réalisée avant l'étape d'authentification (101) ou avant l'étape d'identification (1022) de l'utilisateur. Les moyens de traitement du dispositif hôte (H) exécutent ensuite une vérification, à partir du tableau EDU-IDCL, de l'état d'utilisation du dispositif client (Cl) à partir de l'identifiant unique du dispositif client (Cl).
Ce tableau EDU-IDCL associe les identifiant uniques des dispositifs clients à leur état d'utilisation ou information d'utilisation. L'état d'utilisation correspond au fait que l'application associée au dispositif client (CI) a été déjà exécutée ou non. Si l'application associé au dispositif client (Cl) a déjà été exécutée» l'état associé à l'identifiant unique du dispositif client (Ci) indiqué dans le tableau EDU-IDCL est l'état « utilisé », par exempte « 0 ». En revanche, si l'application n'a jamais été exécutée, l'état associé à l'identifiant unique du dispositif client (CI) indiqué dans le tableau EDU-IDCL est l'état « non utilisé », par exemple « 1 »,
Si l'état d'utilisation correspond à un état « utilisé » (1031 ), une étape de vérification (1032) pour vérifier que l'identifiant de l'utilisateur est associé dans te tableau IDUT-IDAPP à l'identifiant ou les identifiants d'une autre ou d'autres applications associées à un ou d'autres dispositifs client. Cette étape peut être suivie d'une étape (1033) d'exécution éventuelle de l'éventuelle ou des éventuelles autres applications par les moyens de traitement du dispositif hôte ou du terminal. Ainsi, l'application associée à un dispositif client ne peut pas être exécutée sur un autre compte d'utilisateur si elle a déjà été exécutée une fois. Le nombre d'exécutions peut être supérieur à une fois en ajoutant dans le tableau IDUT-IDAPP une information indiquant le nombre de fois pour lequel l'application peut être exécutée.
Si l'état d'utilisation correspond à un état « non utilisé » (1034), le dispositif client (CI) est validé.
Selon le mode de réalisation particulier, l'étape de vérification (1030a) consiste en la vérification, dans le fichier d'utilisation stocké dans zone mémoire secrète du dispositif client (Cl), de l'information de l'état d'utilisation du dispositif client (Cl) après une étape d'ouverture (1030b) d'un canal sécurisé par un algorithme d'ouverture d'un canal sécurisé. L'ouverture d'un canal sécurisé est décrite ci-après.
Après avoir vérifié que le dispositif client (Cl) est validé, l'application est exécutée par l'algorithme d'exécution d'application suivant les étapes suivantes.
- une étape de vérification de l'application à exécuter à partir de l'indication dans l'adresse URL du dispositif hôte (H) stockée dans la zone mémoire du dispositif client (Cl) d'après le tableau AURL-IDAPP,
- une étape (1036) d'affichage sur le moyen d'affichage (21 ) du terminal (2) d'une fenêtre présentant un choix d'exécution ou non de l'application à exécuter, la fenêtre représentant au moins une touche matérielle ou virtuelle permettant l'exécution de l'application et une touche matérielle ou virtuelle permettant le refus d'exécution de l'application,
- une étape (1035) de choix par les moyens de saisie du terminal (2) par l'utilisateur.
Si l'utilisateur actionne le moyen de saisie (23) de telle manière que la touche matérielle ou virtuelle permettant le refus d'exécution est validée (1036b), le procédé comprend une étape d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de la ou des applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client (Cl).
Si l'utilisateur actionne le moyen de saisie (23) de telle manière que la touche matérielle ou virtuelle permettant l'exécution est validée (1036a), le procédé comprend :
- une étape (1037a) d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de la ou des applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client (Cl),
- une étape (1037b) d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de l'application associée au dispositif client (Cl)
- une étape (1038, 1039) de modification de l'information d'utilisation de l'état « non utilisé » pour passer l'information d'utilisation à l'état « utilisé ». Cette étape peut aussi précéder l'étape d'affichage.
Le procédé peut également comprendre les étapes suivantes.
Lors de l'étape de choix pendant l'étape d'exécution de l'application, si l'utilisateur actionne le moyen de saisie (23) de telle manière que la touche permettant l'exécution est validée (1036a), l'étape (1038) de modification de l'état d'utilisation « non utilisé » en état d'utilisation « utilisé » correspond à la modification de l'information d'utilisation de l'état « non utilisé » est modifié en état d'utilisation « utilisé » correspondant à la modification de l'état en association avec l'identifiant unique du dispositif client (CI) sur le fichier ou tableau EDU-IDCL.
Selon le mode de réalisation particulier représenté par les blocs en pointillés des figure 3 et 4, l'étape d'authentificatton peut être suivie d'une étape d'installation (100d) par les moyen de traitement du terminal (2) d'un algorithme d'ouverture d'un canal sécurisé dans la zone mémoire du terminal (2), l'algorithme d'ouverture ayant été envoyé (100c) par le dispositif hôte (H). Cet algorithme peut être une appiet programmée en Java ou une application de type Plugin ou bien un logiciel installé directement sur la zone mémoire du terminal (2) et lis en œuvre par les moyens de traitement du terminal (2).
Selon le mode de réalisation particulier, lors de l'étape de choix pendant l'étape d'exécution de l'application, si l'utilisateur actionne le moyen de saisie (23) de telle manière que la touche permettant l'exécution est validée, l'étape de modification de l'information d'utilisation de l'état « non utilisé » en état « utilisé » correspond à la modification (1039) de l'information du fichier d'utilisation stocké dans la zone mémoire du dispositif client (Cl) par un algorithme de changement de l'information contenue dans le fichier d'utilisation après une étape d'ouverture (1039) d'un canal sécurisé par un algorithme d ouverture d'un canal sécurisé mis en œuvre par les moyens de traitement du dispositif hôte (H) et du terminal (2). Ceci est réalisé pour savoir si l'application associée au dispositif client (Cl) a déjà été exécutée ou non. Dans ce mode de réalisation particulier, pour permettre l'ouverture de ce canal sécurisé, les dispositifs hôte (H) et client (Cl) comprennent au moins un algorithme de chiffrement/déchiffrement des données et au moins un jeu de clefs de chiffrements enregistrées dans la zone mémoire secrète du dispositif client (Cl), cette zone étant non accessible de l'extérieur. Par exemple et de façon non limitative, les clefs de chaque jeu sont symétriques. Par exemple, l'algorithme de chiffrement/déchiffrement utilisé est un algorithme dit triple DES (3-DES, 20 DES venant de l'anglais « Data Encryption stantard »). Chaque jeu de clefs secrètes comprend par exempte trois clefs secrètes 3-DES, notées ENC, MAC et DEK, La clef ENC est une clef secrète de chiffrement des données, assurant la confidentialité des données échangées. La clef secrète MAC est une clef d'intégrité. L'algorithme 3-DES utilisant la clef secrète MAC sur une donnée génère une signature numérique accompagnant chaque donnée chiffrée par l'algorithme et la clef MAC. Cette signature numérique garanti que les données transférées d'un dispositif à l'autre ne sont pas corrompues. Enfin, la clef DEK est une clef secrète de chiffrement de données confidentielles, et apporte une protection supplémentaire à des données sensibles, par exemple et de façon non limitative contenant des informations concernant des données utilisateur.
Dans ce mode de réalisation particulier, les dispositifs hôte (H) et client (Cl) peuvent comprendre un système d'exploitation, mise en œuvre par les moyens de traitement, comportant tes algorithmes et les commandes nécessaires à l'ouverture d'un canal sécurisé ayant les spécifications GlobalPiatform permettant l'échange sécurisé de données entre le client, par exemple un objet portable utilisateur (Cl), et l'hôte (H), par exemple un serveur.
Dans ce mode de réalisation particulier et en référence à la figure 7, le procédé d'ouverture d'un canal sécurisé ayant les spécifications GlobalPiatform entre le dispositif client (Cl) et le dispositif hôte (H) va maintenant être décrit. L'ouverture de ce canal est réalisé via un algorithme 3-DES enregistré dans une zone mémoire sécurisée non volatile du dispositif hôte et du dispositif client, et un jeu de trois clefs secrètes ENC, MAC ET DEK enregistrées dans une zone mémoire secrète de chaque dispositif (H, Cl), non accessible de l'extérieur.
Au cours de la première étape, les moyens de traitement du dispositif hôte (H) commandent l'ouverture d'une nouvelle session. Une information indiquant l'ouverture de la session est envoyé au dispositif client (CI) par les moyens de traitement du dispositif hôte (H). À réception de cette information, les moyens de traitement du dispositif client, génèrent (60) un compteur de session (SC) incrémenté à chaque ouverture d'une nouvelle session. Ce compteur de session est stocké dans une zone mémoire du dispositif client (CI). Au cours de la deuxième étape, les moyens de traitements du dispositif client (Cl) réalisent une opération de dérivation (501 ) des trois clefs secrètes ENC, MAC ET DEK, via l'algorithme 3-DES utilisant le compteur de session (SC) et un nombre aléatoire hôte (HC) généré par les moyens de traitement du dispositif hôte (H), ledit nombre aléatoire (HC) étant envoyé (61 ) au dispositif client (Cl) et enregistré dans la mémoire du dispositif client.
Suite à cette étape de dérivation, cinq clefs dérivées secrètes sont générées (90) par les moyens de traitement du dispositif client (Cl), et enregistrées dans une zone mémoire du dispositif (Cl). La première clef, nommée S-ENC, permet de chiffrer les commandes envoyées à un dispositif (H, Cl) par l'autre dispositif (H, Cl). La deuxième clef, nommée R-ENC, permet de chiffrer les réponses envoyées à un dispositif par l'autre dispositif. Les deux clefs nommées C-MAC et R-MAC permettent respectivement de générer une signature pour chaque commande et pour chaque réponse envoyée, assurant ainsi l'intégrité des données transférées. Enfin, la cinquième clef, nommée S- DEK, permet de chiffrer les données confidentielles, qu'il s'agisse de commandes ou de réponses.
Au cours de la quatrième étape, les moyens de traitement du dispositif client (Cl) génèrent (504) un cryptogramme client (Ccryptoc), via l'algorithme 3- DES utilisant la clef dérivée S-ENC ainsi que le nombre aléatoire hôte (HC) et un nombre aléatoire client (CC) généré par les moyens de traitement du dispositif client (Cl).
Au cours de la cinquième étape, ce cryptogramme client (Ccryptoc), le compteur de session (SC) et le nombre aléatoire client (CC) sont envoyés au dispositif hôte (H) par les moyens de traitement du dispositif client (Cl). Le cryptogramme client (Ccryptoc), le compteur de session (SC) et le nombre aléatoire client (CC) sont enregistrés dans une zone mémoire du dispositif hôte (H). Parallèlement, tes moyens de traitement du dispositif hôte (H) calculent (500, 80) les cinq clefs dérivées S-ENC, R-ENC, C-MAC, R-MAK et S-DEK via l'algorithme triple DES utilisant le compteur de session (SC) et le nombre aléatoire hôte (HC).
Avec les données reçues à la cinquième étape, les moyens de traitement du dispositif hôte (H) calculent (503) le cryptogramme client 25 (CcryptoH) via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte (HC) et le nombre aléatoire client (CC). Au cours de la septième étape, les moyens de traitement du dispositif hôte (H) comparent les cryptogrammes client (Ccryptoc, CcryptoH) respectivement calculés par le dispositif client (Cl) et le dispositif hôte (H). Si les deux cryptogrammes client (Ccryptoc, CcryptoH) sont identiques, alors le dispositif client (Cl) est authentifié par les moyens de traitement du dispositif hôte (H).
Au cours de la huitième étape, les moyens de traitement du dispositif hôte (H) calcule (502) un cryptogramme hôte (HcryptoH), via l'algorithme 3- DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte (HC) et le nombre aléatoire client (CC). Ce cryptogramme hôte (HcryptoH) est enregistré dans une zone mémoire du dispositif hôte (H).
Au cours de la neuvième étape, ce cryptogramme hôte (HcryptoH) est envoyé (62) au dispositif client (Cl) par les moyens de traitement du dispositif hôte (H). Le cryptogramme hôte (HcryptoH) est enregistré dans une zone mémoire du dispositif client (Cl). Avec les données reçues à la neuvième étape, les moyens de traitement du dispositif client (Cl) calculent (505) le cryptogramme hôte (Hcryptoc) via l'algorithme 3-DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte (HC) et le nombre aléatoire client (CC).
Au cours de la onzième étape, les moyens de traitement du dispositif client (Cl) comparent les cryptogrammes hôte (HcryptoH, Hcryptoc) respectivement calculés par le dispositif client (CI) et le dispositif hôte (H), Si les deux cryptogrammes hôte (HcryptoH, Hcryptoc) sont identiques, alors le dispositif hôte (H) est authentifié par les moyens de traitement du dispositif client (Cl).
Ce procédé se conclut par la confirmation de l'ouverture d'un canal sécurisé (OSCS), à travers lequel les prochaines commandes et/ou réponse générées par les dispositifs hôte (H) et client (Cl) peuvent être réalisées. Ce canal de sécurité permet, par exemple, aux moyens de traitement du dispositif hôte (H) de modifier le fichier d'utilisation stocké dans la mémoire du dispositif client (Cl).
Ainsi, il est possible de connaître l'état d'utilisation du dispositif client d'au moins deux modes différents qui peuvent être mis en œuvre ensemble ou seul.
Selon un mode de réalisation, l'identifiant unique du dispositif client est associé à l'état d'utilisation du dispositif client dans le fichier ou tableau EDU- IDCL stocké dans la zone mémoire du dispositif hôte.
Selon le mode de réalisation particulier, un fichier d'utilisation stocké dans la zone mémoire du dispositif client (Cl). Le fichier d'utilisation comprend une information d'état d'utilisation du dispositif client (Cl) : un état correspondant à un état d'utilisation « utilisé » du dispositif client (Cl) et un état correspondant à un état d'utilisation « non utilisé ». L'information d'état d'utilisation est modifiée par l'algorithme de changement de l'information contenue dans le fichier d'utilisation installée dans la zone mémoire du terminal (2).
Les figures 5 et 6 représentent des exemples de réalisation du procédé.
L'application est une application permettant d'installer un objet telle qu'une image sur une page Internet (2000, 2001 ). La figure 5 représente un terrain de football sur lequel des images de joueurs peuvent être installées. Dans la page Internet (2000) de la figure 5, aucun joueur n'a été installé. Seuls sont représentés les emplacements (2003) des images des joueurs.
Lorsqu'un utilisateur connecte un dispositif client sur son terminal et que ce dispositif client n'a jamais été utilisé pour installer une image de joueur, il a la possibilité ou non d'installer une image de joueur associée à son dispositif client. Par exempte, le dispositif client peut avoir la forme ou représenté une image du joueur dont l'image peut être installée sur le terrain de football représenté sur la page Internet. La figure 6 représente la page internet (2001 ) avec une image (2002) de joueur installée grâce à son dispositif client. Par la suite, si cet utilisateur reconnecte son dispositif client sur son terminal, il n'aura plus la possibilité d'installer une autre image du joueur déjà installée grâce à ce dispositif client, ni l'image d'un autre joueur. Mais, la connexion de son dispositif client déjà utilisé lui permettra d'aller directement sur la page Internet avec ses images de joueur déjà installées avec l'utilisation par exemple de sont mot de passe.
Selon un autre mode de réalisation, l'application peut donner la possibilité de choisir le joueur à ajouter sur la page internet. Ainsi, l'application envoie aux moyens de traitement du terminal des commandes permettant d'afficher une fenêtre représentant plusieurs choix de joueurs sélectionnables avec des informations permettant de désigner la position du joueur sélectionné sur le terrain affiché par les moyens d'affichage du terminal. Le joueur peut être sélectionné par des moyens de sélection. Ces moyens de sélection peuvent être au moins une touche virtuelle correspondant au joueur du moyen de saisie du terminal ou au moins touche virtuelle correspondant au joueur des moyens d'affichages du terminal si le moyen d'affichage est, par exemple, un écran tactile. Un fichier ou un tableau peut associer le nom du joueur avec l'identifiant, le nom ou le prénom de l'utilisateur.
La présente demande décrit diverses caractéristiques techniques et avantages en référence aux figures et/ou à divers modes de réalisation. L'homme de métier comprendra que les caractéristiques techniques d'un mode de réalisation donné peuvent en fait être combinées avec des caractéristiques d'un autre mode de réalisation à moins que l'inverse ne soit explicitement mentionné ou qu'il ne soit évident que ces caractéristiques sont incompatibles. De plus, tes caractéristiques techniques décrites dans un mode de réalisation donné peuvent être isolées des autres caractéristiques de ce mode à moins que l'inverse ne soit explicitement mentionné.
Il doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la portée des revendications jointes, et l'invention ne doit pas être limitée aux détails donnés ci-dessus.

Claims

REVENDICATIONS
1 . Système de gestion d'au moins une application en ligne comprenant un dispositif hôte (H) et un dispositif client (Cl) portable, le dispositif hôte (H) comportant un terminal (2) communiquant avec un réseau (22) via des moyens de connexion ou de communication du terminal (2), le dispositif client (Cl) se connectant au terminal (2) par une interface du terminal du type USB comme périphérique clavier, chaque dispositif (H, Cl) comportant au moins une zone mémoire permanente non volatile programmable et des moyens de traitements des données,
le terminal comprenant une zone mémoire et des moyens de traitement de données,
caractérisé en ce que
le système comprend un algorithme d'authentification incluant des modules stockés dans la zone mémoire du dispositif client pour certains et dans la zone mémoire du dispositif hôte pour d'autres.
la zone mémoire du dispositif client (Cl) comprenant un identifiant unique fourni à la connexion au terminal et des messages enregistrés en code clavier et traités comme tel par le terminal (2),
la zone mémoire du dispositif hôte (H) comprenant au moins un algorithme d'identification d'un utilisateur, un algorithme de vérification de validité du dispositif client (Cl) et un algorithme d'exécution d'application,
la zone mémoire du dispositif hôte (H) comprenant en outre une base de données comprenant au moins un fichier ou tableau ID-MDP associant des identifiants d'utilisateurs avec des mots de passe de chaque utilisateur, un fichier AURL-IDAPP ou tableau associant l'adresse URL du dispositif hôte (H) avec un identifiant de l'application,
le dispositif hôte (H) étant identifié par une adresse URL fournie au terminal par le dispositif client,
la zone mémoire du dispositif hôte (H) comprenant en outre au moins une application à exécuter identifiée par un identifiant, la zone mémoire du dispositif client comprenant au moins l'adresse URL du dispositif hôte associée à l'identifiant de l'application à exécuter et envoyée par le dispositif client,
l'algorithme d'identification étant mis en œuvre par les moyens de traitement du dispositif hôte pour identifier l'utilisateur du dispositif client par comparaison avec le tableau ID-MDP de l'identifiant de l'utilisateur et du mot de passe fournis par l'utilisateur par des moyens de saisie du terminal, après que l'algorithme d'authentification a authentifié le dispositif client,
l'algorithme de validité du dispositif client (Cl) étant mis en œuvre par les moyens de traitement du dispositif hôte pour vérifier la validité du dispositif client en consultant une information d'état représentative de l'utilisation du dispositif client,
l'information d'état correspondant à un état « non utilisé », si l'application à exécuter n'a pas déjà été exécutée, l'information d'état correspondant à un état « utilisé », si l'application à exécuter a déjà été exécutée,
lorsque l'information d'état représentative de l'utilisation du dispositif client correspond à un état « non utilisé », l'identifiant de l'application à exécuter étant déterminé avec les moyens de traitement du dispositif hôte par comparaison avec le tableau AURL-IDAPP à partir de l'adresse URL du dispositif hôte stockée dans la zone mémoire du dispositif client.
2. Système selon la revendication 1 , caractérisé en ce que la base de données du dispositif hôte comprenant un fichier ou tableau IDUT-IDAPP associant les identifiants d'utilisateurs avec au moins un identifiant d'application,
lorsque l'information d'état représentative de l'utilisation du dispositif client correspond à un état « utilisé », l'identifiant de la ou des applications à exécuter étant déterminé avec les moyens de traitement du dispositif hôte par comparaison avec le tableau AURL-IDAPP à partir de l'identifiant de l'utilisateur.
3. Système selon la revendication 1 , caractérisé en ce que la zone mémoire du dispositif client (CI) comprenant un premier compteur incrémenté par une génération d'un mot de passe et une clef secrète partagée utilisés par un module de l'algorithme d'authentification dans le dispositif client (Cl),
la zone mémoire du dispositif client (Cl) comprenant en outre au moins l'adresse URL du dispositif hôte (H) ainsi qu'une indication de l'identification de l'application en code interprété par le terminal comme un code clavier,
la zone mémoire du dispositif hôte (H) comprenant en outre la clef secrète partagée avec le dispositif client associé à un utilisateur et un fichier ou tableau 2CMP-IDCL associant un deuxième compteur avec l'identifiant unique de chaque dispositif client (Cl).
4. Système selon les revendications 1 et 3, caractérisé en ce que l'algorithme d'authentification comprend :
un premier module mis en œuvre par les moyens de traitement du dispositif client (Cl) générant un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n, le premier module incrémentant le premier compteur à un rang n+1 lorsque le premier mot de passe est généré, le premier module étant stocké dans la zone mémoire du dispositif client (Cl), un deuxième module mis en œuvre par les moyens de traitement du dispositif hôte (H) générant un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p, le deuxième compteur étant celui associé à l'identifiant du dispositif client (Cl) à partir fichier ou tableau 2CMP-IDCL, le deuxième module étant stocké dans la zone mémoire du dispositif hôte (H),
un troisième module mis en oeuvre par les moyens de traitement du dispositif hôte (H) comparant le premier mot de passe généré par les moyens de traitement du dispositif client (Cl) et le deuxième mot de passe généré par les moyens de traitement du dispositif hôte (H), le premier mot de passe ayant été envoyé au dispositif hôte (H) par le dispositif client (Cl), le troisième module incrémentant le deuxième compteur à un rang p+1 lorsque le deuxième mot de passe est généré, le troisième module étant stocké dans la zone mémoire du dispositif hôte (H).
5. Système selon au moins une des revendications 1 à 4, caractérisé en ce que la zone mémoire du dispositif hôte comprenant en outre un fichier ou tableau EDU-IDCL associant au moins l'information d'état représentative de l'utilisation du dispositif client avec l'identifiant unique du dispositif client.
6. Système selon la revendication 1 , caractérisé en ce que l'information d'état représentative de l'utilisation du dispositif client est comprise dans un fichier d'utilisation stocké dans une zone mémoire secrète du dispositif client (Cl), la zone mémoire secrète étant accessible au dispositif hôte (H) par un canal sécurisé entre le dispositif client (Cl) et le dispositif hôte (H), le canal sécurisé étant ouvert par un algorithme d'ouverture d'un canal sécurisé.
7. Système selon les revendications 1 et 6, caractérisé en ce que la zone mémoire du dispositif hôte (H) comprend un algorithme d'ouverture d'un canal sécurisé, une application d'installation d'un algorithme d'ouverture d'un canal sécurisé entre le dispositif client (Cl) et le dispositif hôte (H) et un jeu de trois clefs secrètes, l'application d'installation étant destinée à être envoyée au dispositif client (Cl) pour installer l'algorithme d'ouverture sur le terminal (2) pour commander, par des messages envoyés au dispositif client (Cl) via l'interface, une modification de l'information du fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client (Cl), la zone mémoire du dispositif hôte (H) comprenant également un algorithme de changement de l'information contenue dans le fichier d'utilisation.
8. Système selon les revendications 1 , 6 et 7, caractérisé en ce que la zone mémoire du dispositif client (Cl) comprend un jeu de trois clefs secrètes identique au jeu de trois clefs secrètes du dispositif hôte (H), le terminal (2) comprenant l'algorithme d'ouverture d'un canal sécurisé.
9. Système selon la revendication 1 , caractérisé en ce que l'application à exécuter envoie des commandes ou messages au terminal permettant un affichage d'une image stockée dans la zone mémoire du dispositif hôte (H) par des moyens d'affichage du terminal (2) selon des coordonnées de placement de l'image dans l'affichage d'une page Internet.
10. Système selon la revendication 1 , caractérisé en ce que l'application à exécuter envoie des commandes ou messages au terminal permettant un affichage d'une animation stockée dans la zone mémoire du dispositif hôte (H) par des moyens d'affichage du terminal (2) selon des coordonnées de placement de l'animation dans l'affichage d'une page Internet.
1 1 . Procédé de gestion d'au moins une application mis en œuvre par le système de gestion d'au moins une application en ligne comprenant un dispositif hôte (H) et un dispositif client (Cl) portable, le dispositif hôte (H) comportant un termina! (2) communiquant avec un réseau (22) via des moyens de connexion ou de communication du terminal (2), le dispositif client (Cl) se connectant au terminal (2) par une interface du terminal du type USB comme périphérique clavier, chaque dispositif (H, Cl) comportant au moins une zone mémoire permanente non volatile programmable et des moyens de traitements des données,
le terminal comprenant une zone mémoire et des moyens de traitement de données,
le système comprenant un algorithme d'authentification incluant des modules stockés dans la zone mémoire du dispositif client pour certains et dans la zone mémoire du dispositif hôte pour d'autres,
la zone mémoire du dispositif client (Cl) comprenant un identifiant unique fourni à la connexion au terminal et des messages enregistrés en code clavier et traités comme tel par le terminal (2),
la zone mémoire du dispositif hôte (H) comprenant au moins un algorithme d'identification d'un utilisateur, un algorithme de vérification de validité du dispositif client (Cl) et un algorithme d'exécution d'application, le dispositif hôte (H) étant identifié par une adresse URL fournie au terminal par le dispositif client,
la zone mémoire du dispositif hôte (H) comprenant en outre au moins une application à exécuter identifiée par un identifiant, le terminal (2) comprenant au moins une connexion à un réseau (22) Internet, un moyen de saisie (23) et un moyen d'affichage (21 ) caractérisé en ce que procédé comprend au moins :
une étape (100) de connexion à l'adresse URL du dispositif hôte (H), l'adresse URL du dispositif hôte (H) étant fournie par un dispositif client (Cl) lu par le terminal (2),
une étape (101 ) d'authentification du dispositif client (CI) mise en œuvre par l'algorithme d'authentification,
si le dispositif client (Cl) est authentifié (1021 ), le procédé comprenant en outre une étape (1022, 1023, 1024, 1025, 1026, 1027, 1028, 1029) d'identification de l'utilisateur mise en œuvre par l'algorithme d'identification de l'utilisateur,
si l'utilisateur est identifié (1029), le procédé comprenant en outre une étape (1030) de vérification de validité du dispositif client (Cl),
si le dispositif client (Cl) est validé (1034), le procédé comprenant en outre une étape (1037b) d'exécution de l'application,
l'étape (1030) de vérification de validité du dispositif client (Cl) mise en œuvre par l'algorithme de vérification de validité comprend :
- une étape de vérification, dans le tableau EDU-IDCL, de l'état d'utilisation du dispositif client (Cl) à partir de l'identifiant unique du dispositif client (Cl) ou bien une étape de vérification (1030a), dans le fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client (Cl), de l'information de l'état d'utilisation du dispositif client (Cl) après une étape (1030b) d'ouverture d'un canal sécurisé par un algorithme d'ouverture d'un canal sécurisé ;
si l'état d'utilisation correspond à un état « non utilisé » (1034), le dispositif client (Cl) étant validé.
12. Procédé selon la revendication 11 , caractérisé en ce que l'étape (100) de connexion à l'adresse URL (100a) du dispositif hôte (H) comprend :
- une étape (100) de connexion du dispositif client (Cl) à l'adresse URL du dispositif hôte fournie par l'information stockée dans la zone mémoire du dispositif client (Cl) par l'intermédiaire d'une connexion au terminal (2), - une étape (100b) d'envoi par le dispositif client (Cl) vers le dispositif hôte (H) de l'identifiant unique du dispositif client (Cl),
13, Procédé selon la revendication 1 1 , caractérisé en ce que l'étape (101 ) d'authentification mise en œuvre par l'algorithme d'authentification comprend ;
- une étape (101 1 ) de génération, par le premier module mis en œuvre par les moyens de traitement du dispositif client (Cl), d'un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n,
- une étape (1012) d'incrémentation du premier compteur à un rang n+1 ,
- une étape (1013) de génération, par le deuxième module mis en œuvre par les moyens de traitement du dispositif hôte (H), d'un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p le deuxième compteur étant celui associé à l'identifiant unique du dispositif client (Cl) à partir du fichier ou tableau 2CMP-IDCL,
- une étape (1016) d'envoi par le dispositif client (Cl) au dispositif hôte (H) du premier mot de passe via le terminal (2),
- une étape (1015) de comparaison, par le troisième module, du premier mot de passe et du deuxième mot de passe ;
si le premier mot de passe est identique au deuxième mot de passe (1019), le deuxième compteur étant incrémenté à un rang p+1 (1020) et le dispositif client (Cl) étant authentifié (1021 ).
14. Procédé selon la revendication 1 1 , caractérisé en ce que l'étape (1022) d'identification mise en œuvre par l'algorithme d'identification de l'utilisateur comprend les sous-étapes suivantes :
- une étape d'affichage par le moyen d'affichage (21 ) du terminal d'au moins deux zones de saisie, l'affichage étant commandé par l'algorithme d'identification,
- une étape (1023) de saisie d'un identifiant de l'utilisateur par le moyen de saisie du terminal (2) dans la première zone de saisie,
- une étape (1023) de saisie d'un mot de passe associé à l'identifiant par le moyen de saisie du terminal (2) dans la deuxième zone de saisie, - une étape (1024) de cryptage par les moyens de traitement du terminal (2) et d'envoi (1025) de l'identifiant et du mot de passe au dispositif hôte (H),
- une étape (1026) de décryptage par les moyens de traitement du dispositif hôte (H) et de vérification de l'identifiant et du mot de passe par l'algorithme d'identification à partir du premier fichier ou tableau de la base de données stockée dans la zone mémoire du dispositif hôte (H) ;
si le premier fichier ou tableau de la base de donnée comprend l'identifiant de l'utilisateur associé avec le mot de passe saisi par l'utilisateur, l'utilisateur étant identifié (1029).
15. Procédé selon la revendication 1 1 , caractérisé en ce que l'étape (1030) de vérification de validité du dispositif client (Cl) mise en œuvre par l'algorithme de vérification de validité comprend :
- une étape de vérification, dans le tableau EDU-IDCL, de l'état d'utilisation du dispositif client (CI) à partir de l'identifiant unique du dispositif client (Cl) ;
si l'état d'utilisation correspond à un état « utilisé » (1031 ), le procédé comprenant :
- une étape (1032) de vérification d'une ou plusieurs applications associées à un autre ou d'autres dispositifs client à partir de l'identifiant de l'utilisateur d'après le tableau AURL-IDAPP,
- une étape (1033) d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte (H) de la ou des autres applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client (Cl).
16. Procédé selon la revendication 1 1 , caractérisé en ce que l'étape (1030) de vérification de validité du dispositif client (Cl) mise en œuvre par l'algorithme de vérification de validité comprend :
- une étape de vérification (1030a), dans le fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client (Cl), de l'information de l'état d'utilisation du dispositif client (Cl) après une étape (1030b) d'ouverture d'un canal sécurisé par un algorithme d'ouverture d'un canal sécurisé ;
si l'état d'utilisation correspond à un état « utilisé », le procédé comprenant :
- une étape (1032) de vérification d'une ou plusieurs applications associées à un autre ou d'autres dispositifs client à partir de l'identifiant de l'utilisateur d'après le tableau AURL-IDAPP,
- une étape (1033) d'exécution par les moyens de traitement du terminal ou tes moyens de traitement du dispositif hôte (H) de la ou des autres applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client (Cl).
17. Procédé selon la revendication 1 1 , caractérisé en ce que l'étape d'exécution de l'application mise en œuvre par l'algorithme d'exécution d'application comprend ;
- une étape de vérification de l'application à exécuter à partir de l'indication comprise dans ou associé à l'adresse URL stockée dans la zone mémoire du dispositif client (Cl) d'après le tableau AURL-IDAPP,
- une étape d'envoi de commande par le dispositif hôte (H) pour permettre l'affichage sur le moyen d'affichage (21 ) du terminal (2) d'une fenêtre présentant un choix d'exécution ou non de l'application à exécuter, la fenêtre représentant au moins une touche matérielle ou virtuelle permettant l'exécution de l'application et une touche matérielle ou virtuelle permettant le refus d'exécution de l'application,
- une étape (1036) de choix par le moyen de saisie du terminal (2) par l'utilisateur,
si l'utilisateur actionne le moyen de saisie (23) de telle manière que la touche matérielle ou virtuelle permettant le refus d'exécution est validée (1036b), le procédé comprend une étape d'exécution par les moyens de traitement du terminal (2) ou les moyens de traitement du dispositif hôte (H) de la ou des applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client (Cl) ; si l'utilisateur actionne le moyen de saisie (23) de telle manière que la touche matérielle ou virtuelle permettant l'exécution est validée (1036a), le procédé comprenant :
- une étape (1037a) d'exécution par les moyens de traitement du terminal ou tes moyens de traitement du dispositif hôte (H) de la ou des applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client (Cl),
- une étape (1037b) d'exécution de l'application par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de l'application associée au dispositif client (Cl)
- une étape (1038) de modification de l'information d'utilisation de l'état « non utilisé » pour passer l'information d'utilisation à l'état « utilisé »,
18. Procédé selon les revendications 1 1 et 13 caractérisé en ce que l'étape d'authentifi cation est suivie d'une étape d'installation (100d) par les moyen de traitement du terminal (2) d'un algorithme d'ouverture d'un canal sécurisé, une application d'installation de l'algorithme d'ouverture d'un canal sécurisé ayant été envoyée (100c) par le dispositif hôte (H).
19. Procédé selon la revendication 16 et 17, caractérisé en ce que, lors de l'étape (1036) de choix, si l'utilisateur actionne le moyen de saisie (23) de telle manière que la touche permettant l'exécution est validée, l'étape (1039) de modification de l'information d'utilisation de l'état « non utilisé » en état « utilisé » correspond à la modification de l'information du fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client (Cl) après une étape (1040) d'ouverture d'un canal sécurisé par un algorithme d'ouverture d'un canal sécurisé mis en œuvre par les moyens de traitement du dispositif hôte (H) et du terminal (2).
20. Procédé selon les revendications 16 et 19, caractérisé en ce que l'algorithme d'ouverture d'un canal sécurisé est réalisée via un algorithme triple DES et un jeu de trois clefs secrètes (ENC, MAC, DEC) selon un protocole de sécurité spécifié du type GlobalPIatform, l'algorithme triple DES et le jeu de trois clefs secrètes (ENC, MAC, DEC) étant enregistrés dans la zone mémoire du dispositif hôte et du dispositif client (Cl),
l'algorithme d'ouverture d'un canal sécurisé comprend :
a) une étape d'ouverture de session par les moyens de traitement du dispositif hôte (H), suivi (60) de la génération d'un compteur de session (SC) par 1e dispositif client (CI) envoyé (70) au dispositif hôte (H), le compteur de session étant incrémenté à chaque ouverture d'une nouvelle session,
b) une étape de dérivation (501 ) des clefs secrètes (ENC, MAC, DEK) enregistrées dans la mémoire du dispositif client (Cl), réalisé par les moyens de traitement dudit dispositif via l'algorithme triple DES utilisant le compteur de session (SC) et un nombre aléatoire hôte (HC) généré et envoyé (81 ) au dispositif client (Cl) par les moyens de traitement du dispositif hôte (H),
c) une étape de génération (90) de cinq clefs dérivées S-ENC, R-ENC, C-MAC, R-MAC et S-DEK qui utilisées avec l'algorithme triple DES, permettent respectivement de chiffrer (S-ENC) les commandes envoyées à un dispositif, de chiffrer (R-ENC) les réponses du dispositif, de générer une signature (C- MAC) pour chaque commande, de générer une signature (R-MAC) pour chaque réponse, et de chiffrer (S-DEK) des données confidentielles,
d) une étape de génération (504) par les moyens de traitement du dispositif client (Cl) d'un cryptogramme client (Ccryptoc), via l'algorithme triple
DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte (HC) et un nombre aléatoire client (CC) généré par les moyens de traitement du dispositif client (Cl),
e) une étape d'envoi (70, 71 , 72) par les moyens de traitement du dispositif client (Cl) vers le dispositif hôte (H), du compteur de session (SC), du nombre aléatoire client (CC) et du cryptogramme client (Ccryptoc) calculé à l'étape précédente, suivi du calcul (500) et de la génération (80) des cinq clefs dérivées (S-ENC, R-ENC, C-MAC, R-MAC, S-DEK) par les moyens de traitement du dispositif hôte (H),
f) une étape de génération (503), par les moyens de traitement du dispositif hôte (H), du cryptogramme client (CcryptoH) via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte (HC) et le nombre aléatoire client (CC) généré par les moyens de traitement du dispositif client (Cl),
g) une étape de comparaison par les moyens de traitement du dispositif hôte (H) des cryptogrammes client (Ccryptoc, CcryptoH) respectivement calculés par le dispositif client (Cl) et te dispositif hôte (H), suivi de l'authentification du dispositif client (Cl) si les deux calculs du cryptogramme client (Ccryptoc, CcryptoH) sont identiques,
h) une étape de génération (502) par les moyens de traitement du dispositif hôte (H) d'un cryptogramme hôte (HcryptoH), via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte (HC) et le nombre aléatoire client (CC),
i) une étape d'envoi (62) par les moyens de traitement du dispositif hôte (H) vers le dispositif client (Cl), du cryptogramme hôte (HcryptoH) calculé à l'étape précédente,
j) une étape de génération (505), par les moyens de traitement du dispositif client (Cl), du cryptogramme hôte (Hcryptoc) via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte (HC) et le nombre aléatoire client (CC),
k) une étape de comparaison par les moyens de traitement du dispositif client (Cl) des cryptogrammes hôte (HcryptoH, Hcryptoc) respectivement calculés par le dispositif hôte (H) et le dispositif client (Cl), suivi de l'authentification du dispositif hôte (H) si les deux calculs du cryptogramme hôte (HcryptoH, Hcryptoc) sont identiques.
I) une étape de confirmation de l'ouverture d'une session et du canal sécurisé (OSCS) à travers lequel les prochaines commandes et/ou réponse générées par les dispositifs hôte et client seront réalisées.
21 . Procédé selon la revendication 17, caractérisé en ce que, lors de l'étape de choix, si l'utilisateur actionne le moyen de saisie (23) de telle manière que la touche permettant l'exécution est validée, l'étape de modification de l'information d'utilisation de l'état « non utilisé » en état d'utilisation « utilisé » correspond à la modification de l'état en association avec l'identifiant unique du dispositif client (CI) sur le deuxième fichier ou tableau.
22. Dispositif portable (Cl) utilisateur formant un dispositif client (Cl) du système selon au moins une des revendications 1 à 10 et comprenant une zone mémoire sécurisée non volatile, des moyens de connexion à une interface terminal et des moyens de traitement de données,
la zone mémoire comprenant au moins un identifiant unique et des messages enregistrés en code clavier et traités comme tel par le terminal.
23. Dispositif portable (Cl) utilisateur selon la revendication 22, caractérisé en ce que les moyens de connexion sont de type USB.
24. Dispositif portable (Cl) utilisateur selon les revendications 22 et 23, caractérisé en ce que
la zone mémoire du dispositif portable (Cl) comprend un premier compteur incrémenté par la génération d'un mot de passe et une clef secrète partagée,
la zone mémoire du dispositif portable (Cl) comprenant en outre au moins l'adresse URL du dispositif hôte (H) ainsi qu'une indication de l'identification de l'application et l'identifiant unique du dispositif portable (Cl) en code interprété par le terminal comme un code clavier.
25. Dispositif portable (Cl) selon les revendications 22 à 24, caractérisé en ce que la zone mémoire du dispositif portable (Cl) comprend un premier module mis en œuvre par les moyens de traitement du dispositif portable (Cl) générant un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n, le premier module incrémentant le premier compteur à un rang n+1 lorsque le premier mot de passe est généré.
26. Dispositif portable (Cl) utilisateur selon la revendication 22, caractérisé en ce que le dispositif portable (Cl) comprend un fichier d'utilisation stocké dans une zone mémoire secrète du dispositif portable (Cl), le fichier d'utilisation comprenant une information d'état d'utilisation du dispositif portable (Cl) : un état correspondant à un état d'utilisation « utilisé » du dispositif portable (Cl) et un état correspondant à un état d'utilisation « non utilisé », la zone mémoire secrète comprenant le fichier d'utilisation étant accessible au dispositif distant (H) par un canal sécurisé entre le dispositif portable (Cl) et le dispositif distant (H), le canal sécurisé étant ouvert par un algorithme d'ouverture d'un canal sécurisé.
27. Dispositif portable (Cl) utilisateur selon les revendications 22 et 28, caractérisé en ce que la zone mémoire du dispositif portable (Cl) comprend un algorithme d'ouverture d'un canal sécurisé et un jeu de trois clefs secrètes identique au jeu de trois clefs secrètes du dispositif distant (H).
28. Dispositif distant (H) formant un dispositif hôte (H) du système selon au moins une des revendications 1 à 10, comprenant une zone mémoire sécurisée non volatile, des moyens de communication et des moyens de traitement de données, le dispositif distant (H) étant caractérisé en ce que
le dispositif distant (H) est identifié par une adresse URL,
la zone mémoire du dispositif distant (H) comprenant au moins un algorithme d'identification de l'utilisateur, un algorithme de vérification de validité du dispositif portable (Cl), un algorithme d'exécution d'application,
(a zone mémoire du dispositif distant (H) comprenant en outre une base de données comprenant au moins un premier fichier ou tableau associant les identifiants d'utilisateurs avec les mots de passe de chaque utilisateur des dispositifs client, un deuxième fichier ou tableau associant au moins un état d'utilisation du dispositif portable (Cl) avec l'identifiant unique d'un dispositif portable (Cl), un troisième fichier ou tableau associant l'adresse URL du dispositif distant (H) avec un identifiant de l'application, un quatrième fichier ou tableau associant les identifiants d'utilisateurs avec au moins un identifiant de l'application,
la zone mémoire du dispositif distant (H) comprenant en outre au moins une application.
29. Dispositif distant (H) selon la revendication 28, caractérisé en ce que la zone mémoire du dispositif distant (H) comprend : un fichier ou tableau 2CMP-IDCL associant un deuxième compteur avec l'identifiant unique de chaque dispositif client (Cl),
un deuxième module mise en œuvre par les moyens de traitement du dispositif distant (H) générant un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p,
un troisième module comparant le premier mot de passe généré par les moyens de traitement du dispositif portable (Cl) et le deuxième mot de passe généré par les moyens de traitement du dispositif distant (H), le premier mot de passe ayant été étant envoyé au dispositif distant (H) par le dispositif portable (Cl), le troisième module incrémentant le deuxième compteur à un rang p+1 lorsque le deuxième mot de passe est généré.
30. Dispositif distant (H) selon les revendications 28 et 29, caractérisé en ce que la zone mémoire du dispositif hôte (H) comprend un algorithme d'ouverture d'un canal sécurisé, une application d'installation d'un algorithme d'ouverture d'un canal sécurisé entre la zone mémoire secrète du dispositif client (Cl) et le dispositif hôte (H) et un jeu de trois clefs secrètes, l'application d'installation étant destinée à être envoyée au dispositif client (Cl) pour installer l'algorithme d'ouverture sur le terminal (2) pour commander, par des messages envoyés au dispositif client (Cl) via l'interface, la modification de l'information du fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client (Cl).
PCT/EP2014/054158 2013-03-05 2014-03-04 Système et procédé de gestion d'au moins une application en ligne, objet portable utilisateur usb et dispositif distant du système WO2014135526A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1351957 2013-03-05
FR1351957A FR3003058A1 (fr) 2013-03-05 2013-03-05 Systeme et procede de gestion d’au moins une application en ligne, objet portable utilisateur usb et dispositif distant du systeme

Publications (1)

Publication Number Publication Date
WO2014135526A1 true WO2014135526A1 (fr) 2014-09-12

Family

ID=48856754

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2014/054158 WO2014135526A1 (fr) 2013-03-05 2014-03-04 Système et procédé de gestion d'au moins une application en ligne, objet portable utilisateur usb et dispositif distant du système

Country Status (2)

Country Link
FR (1) FR3003058A1 (fr)
WO (1) WO2014135526A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108629207A (zh) * 2017-03-22 2018-10-09 温科尼克斯多夫国际有限公司 基于外围设备的信息生成加密密钥的系统和方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060167763A1 (en) * 2003-07-07 2006-07-27 Fujitsu Limited Service providing device and service providing method
US20070234064A1 (en) * 2006-03-29 2007-10-04 Casio Computer Co., Ltd. Identification information output device
FR2910149A1 (fr) * 2006-12-14 2008-06-20 Sagem Defense Securite Dispositif peripherique de securite
US7930554B2 (en) * 2007-05-31 2011-04-19 Vasco Data Security,Inc. Remote authentication and transaction signatures

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060167763A1 (en) * 2003-07-07 2006-07-27 Fujitsu Limited Service providing device and service providing method
US20070234064A1 (en) * 2006-03-29 2007-10-04 Casio Computer Co., Ltd. Identification information output device
FR2910149A1 (fr) * 2006-12-14 2008-06-20 Sagem Defense Securite Dispositif peripherique de securite
US7930554B2 (en) * 2007-05-31 2011-04-19 Vasco Data Security,Inc. Remote authentication and transaction signatures

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108629207A (zh) * 2017-03-22 2018-10-09 温科尼克斯多夫国际有限公司 基于外围设备的信息生成加密密钥的系统和方法
CN108629207B (zh) * 2017-03-22 2024-02-20 温科尼克斯多夫国际有限公司 基于外围设备的信息生成加密密钥的系统和方法

Also Published As

Publication number Publication date
FR3003058A1 (fr) 2014-09-12

Similar Documents

Publication Publication Date Title
EP1004100B1 (fr) Dispositif portable electronique pour systeme de communication securisee, et procede d'initialisation de ses parametres
EP1964307B1 (fr) Procédé pour la réalisation d'un compteur sécurisé sur un système informatique embarqué disposant d'une carte a puce.
EP2619941B1 (fr) Procede, serveur et systeme d'authentification d'une personne
FR2802666A1 (fr) Systeme informatique pour application a acces par accreditation
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
FR2779018A1 (fr) Terminal et systeme pour la mise en oeuvre de transactions electroniques securisees
WO2019233951A1 (fr) Une application logicielle et un serveur informatique pour authentifier l'identité d'un créateur de contenu numérique et l'intégrité du contenu du créateur publié
EP3022867A1 (fr) Procéde d'authentification forte
EP1238340A2 (fr) Dispositif informatique pour l'application de donnees accreditives a un logiciel ou a un service
CA2888662A1 (fr) Systeme et procede de securisation des echanges de donnees, objet portable utilisateur et dispositif distant de telechargement de donnees
WO2014135526A1 (fr) Système et procédé de gestion d'au moins une application en ligne, objet portable utilisateur usb et dispositif distant du système
FR2950768A1 (fr) Systeme et procede de transaction securisee en ligne
FR3032292B1 (fr) Element securise et procede mis en œuvre dans un tel element securise
WO2014135519A1 (fr) Système et procédé de gestion d'au moins une application en ligne, objet portable utilisateur communiquant par un protocole radioélectrique et dispositif distant du système
EP2795830B1 (fr) Procede d'echange de donnee chiffree entre un terminal et une machine
FR2817067A1 (fr) Procede et dispositif d'authentification de documents electroniques au moyen d'une signature numerique
FR2730076A1 (fr) Procede d'authentification par un serveur du porteur d'un objet portatif a microprocesseur, serveur et objet portatif correspondants
EP3842970B1 (fr) Procédé de vérification du mot de passe d'un dongle, programme d'ordinateur, dongle et terminal utilisateur associés
EP3391265A1 (fr) Procede d'elaboration d'un mot challenge, dispositif electronique, peripherique de consigne et systeme mettant en oeuvre ledit procede
EP3032450B1 (fr) Procédé de contrôle d'une authenticité d'un terminal de paiement et terminal ainsi sécurisé
EP1502234B1 (fr) Procede de transmission de donnees entre une carte a puce et un utilisateur, lecteur de carte et carte pour la mise en oeuvre de ce procede
FR2927750A1 (fr) Terminal de paiement electronique pour l'echange de donnees securise sur un reseau ouvert
FR3007929A1 (fr) Procede d'authentification d'un utilisateur d'un terminal mobile
WO2020128215A1 (fr) Réinitialisation d'un secret applicatif au moyen du terminal
CH716293A2 (fr) Procédé de signature décentralisée, sous contrôle biométrique et sous condition d'identification personnelle, d'une transaction destinée à une blockchain.

Legal Events

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

Ref document number: 14715549

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14715549

Country of ref document: EP

Kind code of ref document: A1