EP1829280A2 - PROCEDE D'AUTHENTIFICATION SECURISEE POUR LA MISE EN ŒUVRE DE SERVICES SUR UN RESEAU DE TRANSMISSION DE DONNEES - Google Patents

PROCEDE D'AUTHENTIFICATION SECURISEE POUR LA MISE EN ŒUVRE DE SERVICES SUR UN RESEAU DE TRANSMISSION DE DONNEES

Info

Publication number
EP1829280A2
EP1829280A2 EP05796271A EP05796271A EP1829280A2 EP 1829280 A2 EP1829280 A2 EP 1829280A2 EP 05796271 A EP05796271 A EP 05796271A EP 05796271 A EP05796271 A EP 05796271A EP 1829280 A2 EP1829280 A2 EP 1829280A2
Authority
EP
European Patent Office
Prior art keywords
service
container
data
server
access
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP05796271A
Other languages
German (de)
English (en)
Inventor
Jean-Luc Leleu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Publication of EP1829280A2 publication Critical patent/EP1829280A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/0014—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for vending, access and use of specific services not covered anywhere else in G07F17/00
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G06Q20/123—Shopping for digital content
    • G06Q20/1235—Shopping for digital content with control of digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/346—Cards serving only as information carrier of service
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/351—Virtual cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • the present invention generally relates to the authentication domain on a data transmission network and relates, in particular, to a method of accessing a service on a data transmission network, via a connected user terminal. to the network.
  • a service may designate any exchange of information, via a digital data transmission network or telecommunication network between two or more users, or between a user and a service provider.
  • the present invention aims to provide a robust authentication system, very flexible to implement, and can be implemented on inexpensive user terminals with limited computing resources, for access to services, including services voice over IP, on a data transmission network.
  • the subject of the invention is a method of accessing a service on a data transmission network, via a user terminal connected to said network, characterized in that it comprises a phase for subscribing to said service where: an information container associated with the user is generated, comprising a first set of authentication data of the access to the service and a second set of useful data relating to said user and access rights to said service, said first and second sets of data being encrypted, and wherein said container is transmitted securely on said user terminal, and access to said service where: said container is transmitted securely from said user terminal to at least one management server connected to the network during a request for access to said service, and where the server verifies, after decryption of the constituent data of said container, the validity of said first set of authentication data and, if successful verification, authorizes access to the service for its execution according to said access rights of the second set of data.
  • the subscription phase to the service includes the payment of said service by the user to a payment server.
  • the subscription phase further comprises the provision of a one-time password by the payment server to the user, the transmission of the password of the user terminal to the management server, triggering securely transmitting the container from said server to said terminal.
  • a step of updating the useful data of the container relating to the access rights to the service is implemented. server-side, said updated data being saved on the management server side.
  • the first and second sets of data of the container are encrypted on the server side, then the said updated container is transmitted securely from the management server to the user terminal for an access phase. at the later service.
  • the secure transmission of the container consists in transmitting in encrypted form the constituent data of said container by applying a symmetric encryption algorithm using a secret key shared by the user terminal and by the server.
  • the secret key implemented is renewed by configurable period.
  • the renewal of the secret key consists in transmitting a new key at the same time as the container during its secure transmission from the server to the user terminal for a subsequent service access phase.
  • the symmetric encryption algorithm implemented at the terminal and server side is of the RC4 type.
  • the encryption of the first and second sets of constituent data of the container before their secure transmission is obtained by applying to said data of a public key encryption algorithm, the corresponding private key being stored only on the server side.
  • the first set of authentication data is represented by hashing function collisions.
  • the server-side verification step consists in checking that the authentication data actually form hashing function collisions.
  • the verification step consists in checking the correspondence of the authentication data from the container with authentication data referenced in a user database for this user.
  • a service cost billing element is generated at the server after execution of said service, from the payload data of the container relating to the service access rights for the user, the authentication data being associated with said service. billing item generated as evidence that access to that service has been authorized.
  • the billing element is stored for use for subsequent financial compensation.
  • the service accessed is a voice over IP service.
  • the transmission of the container from the user terminal to the server or from the server to the user terminal for access to the service is integrated into a protocol allowing voice over IP transmissions, for example the SIP protocol.
  • the transmission of the container from the user terminal to the management server during a phase of access to a service is performed via an intermediate gateway of the network, said gateway implementing a preliminary verification step of the validity of the container before routing it to said server.
  • the preliminary verification step of the validity of the container consists in checking the validity of a third set of authentication data of said container.
  • the invention also relates to a server connected to a data transmission network, for accessing a service via a user terminal connected to said network, characterized in that it comprises means for implementing process steps as just described.
  • FIG. 1 schematically illustrates an exemplary network architecture in which the invention can be described
  • FIG. 2 illustrates, according to a preferred exemplary embodiment, the steps implemented when registering a user with a service on a data transmission network
  • FIG. 3 illustrates a possible model for the structure of a secure container bearing the information necessary for accessing and performing the service on the network
  • FIG 4 illustrates steps of obtaining the secure container by the terminal following the subscription to the service for access to it;
  • FIG. 5 is a block diagram illustrating a sequence of steps implemented on the server side during access to the service.
  • the invention therefore relates to a method of accessing a service on a data transmission network.
  • Access to the service is preferably performed via a user terminal 30 connected to an access network RA coupled by a PA gateway to the data transmission network, typically the Internet network and generally with its couplings to other autonomous networks, such as the PSTN public switched telephone network.
  • the access network can be either a wireless local area network, for example a Wifi network, a public or private network operating with the IP protocol or with a protocol other than IP, a public or private switched telephone network.
  • the service subscribed by the user may be an IP telephony service, video telephony or a download service for digital files, for example music files type MP3.
  • IP telephony service for example IP telephony service
  • video telephony for example video files type MP3.
  • download service for digital files
  • music files type MP3 for example music files type MP3.
  • FIG 2 illustrates precisely this phase of subscription of the user to the service, which is more particularly materialized by a deed of payment
  • the user obtains (b) an activation number of the subscribed service.
  • This activation number includes a OTP one-time password and a secret key Ko, the use of which will be explained later.
  • the transaction between the user and the payment server is preferably implemented according to a protocol allowing the secure transmission of information, such as the SSL protocol for example.
  • the activation number could be transmitted to the user by any other suitable means, for example by mail, a call to an interactive voice response system or via a card to scratch.
  • a secure container is an encrypted numerical value representative of various information associated with a user subscribed to a service and, in particular, access rights to this service. It allows this information to pass between different nodes of the network in a secure manner without the need to provide for the implementation of a channel figure.
  • the container also allows its owner, in this case a user terminal, to be authorized to access a service on the network according to the access rights to this service as they were defined at the time of subscription in the service and stored in digital form in the secure container.
  • FIG. 3 illustrates an exemplary structure of a TOKEN secure container, which is generated on a network management server during the subscription phase to the service by the user. It comprises a first set of CBF data forming the core of the container, essentially comprising authentication data of access to the XO service, Xl, X2 and X3, which form the proof that the access to the service can be authorized for its execution.
  • the value and the origin of this first set of authentication data must be easily authenticated and verifiable by the entity authorizing the access and this, of course.
  • a TPID field can thus be inserted in this first set of data, representative of the producer entity of the container.
  • the authentication data of the access to the service denoted X0, X1, X2 and X3 in the example of FIG. 3, are manufactured according to a method described in FIG. article entitled "PayWord and Micromint - Two Simple Micropayment Schemes" by RL RIVEST and A. SHAMIR and presented on January 26, 1996 at the 1996 RSA conference. manufacturing electronic coins, represented by bit strings whose validity can be verified by anyone, but which are very difficult to produce. In this system, parts are represented by hashing function collisions.
  • the container also comprises a second set of useful data PBF, including data relating to the user of the service and rights of access to this service that were defined at the time of subscription to the service by the user.
  • PBF useful data
  • an RBF field of the container includes data defining the conditions of access to the services, for example indicating whether the user can make local calls and / or national and / or international.
  • a UBF field includes value data associated with the service for establishing a billing, for example a number of units representative of the amount of the payment paid by the user when subscribing to the service.
  • a TCBF field comprises time data, for example data representative of a communication time. Other critical information could still be inserted in the second set of useful data PBF, such as for example an expiry date of the validity of the container.
  • the second payload data set may also include a SID / PN field including user data, such as a subscriber ID number and / or its telephone number.
  • the first set of authentication data thus provides the security and integrity functions of the second set of useful data and can be likened to a unique non-forgeable key for authenticating access to a given service.
  • the container can thus guarantee, by means of a verification of the first set of authentication data, that access to a given service can be authorized, depending on the access rights defined in the container, and that the latter has already been paid or the user can be charged for this service.
  • a public key encryption algorithm E PK for example an RSA type algorithm.
  • E PK public key encryption algorithm
  • This container thus secured is intended to be stored on the user terminal side, in order to allow the implementation, from this terminal, of a service access phase, which will be implemented at a PA gateway of data transmission network, typically the management server.
  • the private key corresponding to the public key implemented as part of the RSA algorithm for the encryption of the constituent data of the container is stored only on the server side.
  • the data transmission network must comprise, at the level of each management server involved in a phase of access to the service by the user terminal, a data processing system programmed so as to perform the various steps of the method of the invention.
  • This data processing system can be individualized as a separate system from the computer system managing the server, or integrated into the computer system by the addition of integrated software.
  • the secure container must first be stored on the user terminal side. This step is described with reference to FIG.
  • the server 40 is a server placed in the network in front of a voice over IP VoIP infrastructure and which will transmit all the signaling packets of the call to the next VoIP device of this infrastructure, once the information of a TOKEN container received from a terminal or, alternatively, from another node of the network, as part of an access request VoIP service will have been recovered and verified as explained below.
  • the server 40 is for example a SIP proxy server ("Session Initiation Protocol").
  • the container and its use in a data transmission network as described in the present description to authenticate access to a given service can also be implemented in the context of a communication protocol between two nodes of the network involved in the access to the service, for example between two servers of the SIP proxy type.
  • step c of transmitting the password OPT of the user terminal 30 to the management server 40 is implemented, triggering the secure transmission to step d, of the container TOKEN, itself already secured by heavy RSA type encryption, from the server 40 to the terminal 30.
  • the secure transmission of the TOKEN container over the network is ensured by the application of a symmetric encryption algorithm C K 0 / for example of type RC4, with the secret key Ko, provided beforehand to the user and shared by the user. management server.
  • Two types of encryption are applied to the container.
  • the first set of data of the CBF container is securely linked to the second set of PBF data by heavy RSA type encryption, managed server side.
  • the container has a second level of encryption, lighter, type RC4 for its secure transmission through the network.
  • this last type of encryption is intended to be implemented on both the server and the terminal side, so as to provide anti-replay properties to the secure container.
  • the secret keys used in the secure transmission of the container on the network are changed very often so as to further enhance the security given the light encryption algorithm used.
  • the secret keys implemented are thus renewed by configurable period.
  • the renewal of the secret key K 0 is carried out by transmitting a new key K1 at the same time as the TOKEN container during its secure transmission of the the
  • the server 40 to the user terminal 30.
  • the server 40 therefore sends C ⁇ o (TOKEN, K1) to the terminal 30.
  • the terminal 30 decrypts the received value using the secret key K 0 which it already has, and thus retrieves the TOKEN container value, always encrypted RSA, and the secret key K1.
  • a service access request sent by the terminal 30 consists of transmitting the (C) securely to the container C RI (TOKEN). to the server 40, by application on the terminal side of the algorithm RC4 with the secret key K1 on the container.
  • the process steps can advantageously be implemented on user terminals with few available CPU resources.
  • the heavy security operations of the container being managed mainly on the management server side, including RSA encryption of the data constituting the container, client-side implementation on the user terminal requires only a simple application that can ensure secure storage of the container on the terminal and the implementation of RC4 encryption, used for the secure transmission of the container.
  • step f the server performs a decryption operation of the data received from the terminal. It first decrypts C K i (TOKEN) with the secret key K1 in order to retrieve the TOKEN container whose data is encrypted with RSA. Then, in a second step, it retrieves the first set of authentication data CBF and the second set of user data UBF from the container by the decryption operation RSA with the corresponding private key of which it is the only one to dispose.
  • a step of checking the validity of the first set of authentication data XO, X1, X2, X3 is implemented. This step can simply consist in checking that the authentication data X0, X1, X2, X3 actually form hashing function collisions.
  • the server 40 authorizes access to the service for its execution according to the access rights to this service referenced in the second set of useful data of the container.
  • the service accessed may be a SIP call to an international number, authorized under the RBF / UBF / TCBF values, the signaling packets of this call being then transmitted by the server to the VoIP infrastructure.
  • the properties of the container implemented thus provides a great deal of flexibility in managing access to the IP telephony service.
  • the container we do not have to go back to a centralized database to identify the user.
  • the access rights of the user to access the service can indeed be verified directly from the container without having to go back to a user account defining these rights.
  • the server 40 may, however, use a user database.
  • the verification can thus consist in verifying the correspondence of the authentication data of the transaction coming from the container with authentication data referenced in a user database for this user.
  • Authentication data access to the service may indeed be formed in one variant by a digital fingerprint of the user, having the same security guarantees that the use of hashing function collisions.
  • the server can also check in the user database that the useful data RBF, UBF and TCBF from the container actually correspond to the current useful data for access to the service stored for this user in the database.
  • a step i of updating the payload data of the container relating to the access rights to the service is implemented, in particular, a step of updating the data RBF, UBF and TCBF. For example, if a prepaid period of 500 minutes had been subscribed by the user, at the end of a 7 minute call session, the initial value 500 of the TCBF field of the payload data of the container is decreased by 7. The updated payloads are then saved to the management server side in the user database.
  • a service cost billing element may optionally be generated and stored at the server 40, the content of which is determined from the payload data of the container relating to the service access rights for the user. .
  • the variations of the TCBF data, giving the communication time, and UBF for the cost of a communication unit can be memorized to form the billing element.
  • the authentication data is also associated with the generated billing item as evidence that access to the service has been authorized.
  • the billing element thus stored on the server side 40 can then be used subsequently with a third party organization to obtain financial compensation on the basis of the accumulated data.
  • an RSA encryption step of the first set of authentication data CBF and the second set of payload data PBF with the updated data is implemented. In this way, the updated secure container is obtained.
  • the updated secure container is transmitted in step k securely to the user terminal 30 for a subsequent service access phase, the secure transmission being provided as previously explained by the application of the RC4 algorithm with Kl.
  • the renewal of the secret key Kl is performed during this step, by transmitting a new key K2 which will be used during the subsequent service access phase.
  • the new secret key K2 is transmitted together with the updated container TOKEN during the secure transmission of the server 40 to the user terminal 30.
  • the server 40 sends thus C ⁇ i (TOKEN, K2) to the terminal 30 .
  • the secure transmission of the TOKEN container, whose data are already encrypted, from the user terminal 30 to the management server 40, or from the server to the user terminal, or between two servers of the network, for the implementation of the access the service and its execution, is intended to be integrated in a protocol for voice transmissions over IP, for example the SIP protocol, according to the embodiment described with reference to a subscribed VoIP service.
  • a protocol for voice transmissions over IP for example the SIP protocol
  • IP for example the SIP protocol
  • a header in order to allow the appropriate processing according to the invention of container-carrying packets. This header could for example consist of several fields such as the size of the data, a control number, a session identifier or other control information.
  • the TOKEN information container may comprise a third set of authentication data, the role of which will be described below.
  • an intermediate gateway of the network is implemented to carry out the transmission of the container of the user terminal to the management server during a phase of access to a service on the network.
  • the intermediate gateway is then provided to perform a preliminary verification of the validity of the container before routing it to the management server, consisting of checking the validity of the third set of authentication data of the container.
  • the third set of authentication data can be represented by bit strings obtained by hashing function collisions, in the same way as for the first set of data of the container.
  • the third data set of the container can also be encrypted using a symmetric key encryption algorithm, type RC4.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Signal Processing (AREA)
  • Finance (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé d'accès à un service sur un réseau, par un terminal utilisateur (30) , comprenant une phase de souscription où : un container (TOKEN) est généré, comprenant un premier ensemble de données d'authentification (XO, Xl, X2 , X3 ) de l'accès au service et un second ensemble de données utiles relatives à des droits d'accès audit service (RBF, UBF, TBF) , lesdits premier et second ensembles de données étant chiffrés ; ledit container est transmis (d) de façon sécurisée sur ledit terminal ; et une phase d'accès où : ledit container est transmis (e) de façon sécurisée dudit terminal vers un serveur de gestion (40) connecté au réseau lors d'une requête d'accès ; le serveur vérifie (g), après déchiffrement (f) des données dudit container, la validité dudit premier ensemble de données et, en cas de succès de la vérification, autorise (h) l'accès au service pour son exécution selon lesdits droits d'accès .

Description

l'
PROCEDE D'AUTHENTIFICATION SECURISEE POUR LA MISE EN ŒUVRE DE SERVICES SUR UN RESEAU DE TRANSMISSION DE
DONNEES
La présente invention concerne de manière générale le domaine de authentification sur un réseau de transmission de données et concerne, en particulier, un procédé d'accès à un service sur un réseau de transmission de données, par l'intermédiaire d'un terminal utilisateur connecté au réseau.
Au sens de la présente invention, un service peut désigner tout échange d'informations, via un réseau de transmission de données numérique ou de télécommunication soit entre deux ou plusieurs utilisateurs, soit entre un utilisateur et un fournisseur de services.
Les services mis en œuvre sur les réseaux de transmission de données numériques, tels que le réseau Internet, connaissent un développement considérable. En particulier, ceux se rapportant à des services de voix sur IP, où les données constituant la voix numérisée sont donc transportées sous forme de paquets d'information selon le protocole IP, voient leur potentiel de développement encore renforcé par le déploiement des réseaux locaux sans fil, tels que les réseaux utilisant la technologie de transmission sans fil basée sur la norme de réseau radioélectrique 802.11 et ses évolutions, regroupées sous l'appellation Wifi (pour « Wireless Fidelity ») .
L' arrivée sur le marché de terminaux mobiles équipés de moyens pour établir une connexion sans fil avec l'Internet, via un réseau d'accès Wifi par exemple, rend d'autant plus prégnante l'émergence de services de voix sur IP.
Cependant, l'un des freins gui limite actuellement la mise en œuvre de tels services sur ce type de réseau, réside dans la forte exigence de sécurité devant être associée aux transactions mises en oeuvre, en particulier pour l'authentification des utilisateurs abonnés au service et l'intégrité des données. Les mécanismes de sécurité à employer conduisent à une gestion lourde et complexe des autorisations permettant de donner ou non la permission d'accéder au service, en l'occurrence effectuer un appel dans le cadre d'un service de téléphonie sur IP souscrit auprès d'un l'opérateur"
La présente invention a pour but de proposer un système d'authentification robuste, très souple à mettre en place, et pouvant être implémenté sur des terminaux utilisateurs bon marchés disposant de ressources de calcul limitées, pour l'accès à des services, notamment des services de type voix sur IP, sur un réseau de transmission de données.
Avec cet objectif en vue, l'invention a pour objet un procédé d'accès à un service sur un réseau de transmission de données, par l'intermédiaire d'un terminal utilisateur connecté audit réseau, caractérisée en ce qu'il comprend une phase de souscription audit service où: un container d'informations associé à l'utilisateur est généré, comprenant un premier ensemble de données d'authentification de l'accès au service et un second ensemble de données utiles relatives audit utilisateur et à des droits d'accès audit service, lesdits premier et second ensembles de données étant chiffrés, et où - ledit container est transmis de façon sécurisée sur ledit terminal utilisateur, et une phase d'accès audit service où : - ledit container est transmis de façon sécurisée dudit terminal utilisateur vers au moins un serveur de gestion connecté au réseau lors d'une requête d'accès audit service, et où le serveur vérifie, après déchiffrement des données constitutives dudit container, la validité dudit premier ensemble de données d'authentification et, en cas de succès de la vérification, autorise l'accès au service pour son exécution en fonction desdits droits d'accès du second ensemble de données.
De préférence, la phase de souscription au service comprend le paiement dudit service par l'utilisateur auprès d'un serveur de paiement.
Dans un mode de réalisation, la phase de souscription comprend en outre la fourniture d'un mot de passe à usage unique par le serveur de paiement à l'utilisateur, la transmission dudit mot de passe du terminal utilisateur vers le serveur de gestion, déclenchant la transmission sécurisée du container dudit serveur vers ledit terminal.
Avantageusement, après l'exécution du service, une étape de mise à jour des données utiles du container relatives aux droits d'accès au service est mise en œuvre côté serveur, lesdites données mises à jour étant sauvegardées côté serveur de gestion.
Selon une caractéristique, suite à la mise à jour, les premier et second ensembles de données du container sont chiffrés côté serveur, puis ledit container mis à jour est transmis de façon sécurisée du serveur de gestion vers le terminal utilisateur pour une phase d'accès au service ultérieure.
De préférence, la transmission sécurisée du container consiste à transmettre sous forme cryptée les données constitutives dudit container par application d'un algorithme de chiffrement symétrique utilisant une clé secrète partagée par le terminal utilisateur et par le serveur. De préférence, la clé secrète mise en œuvre est renouvelée par période paramétrable.
Selon un mode de réalisation, le renouvellement de la clé secrète consiste à transmettre une nouvelle clé en même temps que le container lors de sa transmission sécurisée du serveur vers le terminal utilisateur pour une phase d'accès au service ultérieure.
De préférence, l'algorithme de chiffrement symétrique mis en œuvre côté terminal et côté serveur est de type RC4. De préférence, le chiffrement des premier et deuxième ensembles de données constitutives du container avant leur transmission sécurisée est obtenue par application aux dites données d'un algorithme de chiffrement à clé publique, la clé privée correspondante étant mémorisée uniquement côté serveur. Selon un mode de réalisation, le premier ensemble de données d'authentification est représenté par des collisions de fonction de hashing.
Selon ce mode de réalisation, l'étape de vérification côté serveur consiste à contrôler que les données d'authentification forment effectivement des collisions de fonction de hashing.
Selon un autre mode de réalisation, l'étape de vérification, consiste à vérifier la correspondance des données d'authentification issue du container avec des données d'authentification référencées dans une base de données utilisateurs pour cet utilisateur.
De préférence, un élément de facturation du coût du service est généré au niveau du serveur après exécution dudit service, à partir des données utiles du container relatives aux droits d'accès au service pour l'utilisateur, les données d'authentification étant associées audit élément de facturation généré en tant que preuve que l'accès audit service a été autorisé. Avantageusement, l'élément de facturation est mémorisé en vue d'être utilisé pour compensation financière ultérieure.
Selon un mode de réalisation, le service accédé est un service de voix sur IP. Avantageusement, la transmission du container du terminal utilisateur vers le serveur ou du serveur vers le terminal utilisateur pour l'accès au service, est intégrée dans un protocole permettant des transmissions de voix sur IP, par exemple le protocole SIP. Selon une variante, la transmission du container du terminal utilisateur vers le serveur de gestion lors d'une phase d'accès à un service est réalisée par l'intermédiaire d'une passerelle intermédiaire du réseau, ladite passerelle mettant en œuvre une étape de vérification préliminaire de la validité du container avant de router celui-ci vers ledit serveur.
Selon cette variante, l'étape de vérification préliminaire de la validité du container consiste à vérifier la validité d'un troisième ensemble de données d'authentification dudit container. L' invention concerne encore un serveur connecté à un réseau de transmission de données, pour l'accès à un service par l'intermédiaire d'un terminal utilisateur connecté audit réseau, caractérisé en ce qu' il comprend des moyens de mise en œuvre des étapes du procédé telles qu' elles viennent d' être décrites .
D' autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante donnée à titre d'exemple illustratif et non limitatif et faite en référence aux figures annexées dans lesquelles :
-la figure 1 illustre schématiquement un exemple d' architecture de réseau dans laquelle peut être décrite l'invention ;
-la figure 2 illustre, selon un exemple de réalisation préféré, les étapes mises en œuvre lors de l'enregistrement d'un utilisateur auprès d'un service sur un réseau de transmission de données ;
-la figure 3 illustre un modèle possible pour la structure d'un container sécurisé portant les informations nécessaires à l'accès et l'exécution du service sur le réseau ; -la figure 4 illustre des étapes d'obtention du container sécurisé par le terminal suite à la souscription au service pour l'accès à celui-ci ;
-la figure 5 est un schéma fonctionnel illustrant une suite d'étapes mises en œuvre côté serveur lors de l'accès au service.
L'invention concerne donc un procédé d'accès à un service sur un réseau de transmission de données. L'accès au service est effectué de préférence par l'intermédiaire d'un terminal utilisateur 30 connecté à un réseau d'accès RA couplé par une passerelle PA au réseau de transmission de données, typiquement le réseau Internet et de manière générale avec ses couplages vers d'autres réseaux autonomes, tels que le réseau téléphonique commuté public RTCP.
Le réseau d'accès peut être soit un réseau local sans fil, par exemple un réseau Wifi, un réseau public ou privé fonctionnant avec le protocole IP ou avec un autre protocole que IP, un réseau téléphonique commuté public ou privé.
En référence à la figure 2, sont illustrées les étapes permettant à un utilisateur 10 de souscrire à un service sur le réseau de transmission de données. Par exemple, le service souscrit par l'utilisateur peut être un service de téléphonie sur IP, de visiophonie ou encore un service de téléchargement de fichiers numériques, par exemple des fichiers musicaux de type MP3. D'autres types de services multimédia sur le réseau de transmission de données peuvent encore être envisagés et proposés à l'utilisateur, lequel, pour pouvoir y accéder doit préalablement y souscrire. La figure 2 illustre précisément cette phase de souscription de l'utilisateur au service, qui est plus particulièrement matérialisée par un acte de paiement
(a) de la part de l'utilisateur auprès d'un serveur de paiement 20. Pour souscrire ainsi au service souhaité, l'utilisateur peut de préférence effectuer la transaction par l'intermédiaire de sa carte de crédit sur un site Web prévu à cet effet.
L'utilisateur obtient en retour (b) un numéro d'activation du service souscrit. Ce numéro d'activation comprend un mot de passe à usage unique OTP, ainsi qu'une clé secrète Ko, dont l'usage sera explicité plus loin.
La transaction entre l'utilisateur et le serveur de paiement est de préférence mise en œuvre selon un protocole permettant la transmission sécurisée d'informations, tel que le protocole SSL par exemple.
Toutefois, il convient de noter que le numéro d'activation pourrait être transmis à l'utilisateur par tout autre moyen adéquat, par exemple par courrier, par un appel à un système de réponse vocal interactif ou encore par l'intermédiaire d'une carte à gratter.
Considérons maintenant la notion de container sécurisé introduite ici dans le contexte de la présente invention. Un container sécurisé est une valeur numérique chiffrée représentative d' informations variées associées à un utilisateur abonné à un service et, notamment, aux droits d'accès à ce service. Il permet à ces informations de transiter entre différents nœuds du réseau d'une manière sécurisée sans qu'il y ait nécessité de prévoir la mise en œuvre d'un canal chiffré. Le container permet en outre à son propriétaire, en l'occurrence un terminal utilisateur, d'être autorisé à accéder à un service sur le réseau en fonction des droits d'accès à ce service tels qu'ils ont été définis lors de la souscription au service et qui sont stockés sous forme numérique dans le container sécurisé.
La figure 3 illustre un exemple de structure d'un container sécurisé TOKEN, qui est généré sur un serveur de gestion du réseau lors de la phase de souscription au service par l'utilisateur. Il comprend un premier ensemble de données CBF formant le cœur du container, comprenant essentiellement des données d'authentification de l'accès au service XO, Xl, X2 et X3, qui forment la preuve que l'accès au service peut être autorisé pour son exécution. Selon un principe de l'invention, la valeur et la provenance de ce premier ensemble de données d'authentification doivent être authentifiables et vérifiables facilement par l'entité autorisant l'accès et ce, de façon sûre.
Un champ TPID peut ainsi être inséré dans ce premier ensemble de données, représentatif de l'entité productrice du container.
Egalement, selon un mode de réalisation de l'invention, les données d'authentification de l'accès au service, notées XO, Xl, X2 et X3 dans l'exemple de la figure 3, sont fabriquées selon une méthode décrite dans l'article intitulé « PayWord and Micromint - Two Simple Micropayment Schemes » par R.L. RIVEST et A. SHAMIR et présenté le 26 janvier 1996 lors de la conférence RSA de 1996. Cet article décrit un système de fabrication de pièces de monnaie électroniques, représentées par des chaînes de bits dont la validité peut être vérifiée par n'importe qui, mais qui sont très difficiles à produire. Dans ce système, les pièces sont représentées par des collisions de fonction de hashing.
Ainsi, en reprenant ce principe, les données d' authentification de l'accès au service contenues dans le container sont elles-même représentées par des chaînes de bits obtenues par des collisions de fonction de hashing h, et il est possible de vérifier très facilement la validité de ces données en contrôlant que : h(X0) = h(Xl) = h(X2) = h(X3) .
Le container comprend également un second ensemble de données utiles PBF, comprenant des données relatives à l'utilisateur du service et à des droits d'accès à ce service qui ont été définis au moment de la souscription au service par l'utilisateur.
Ainsi, si l'on prend l'exemple d'un service souscrit de téléphonie sur IP, un champ RBF du container comprend des données définissant les conditions d'accès au services, par exemple indiquant si l'utilisateur peut passer des appels locaux et/ou nationaux et/ou internationaux. Un champ UBF comprend des données de valeur associées au service permettant d'établir une facturation, par exemple un nombre d'unités représentative du montant du paiement acquitté par l'utilisateur lors de sa souscription au service. Un champ TCBF comprend des données temporelles, par exemple des données représentatives d'un temps de communication. D'autres informations critiques pourraient encore être insérées dans le second ensemble de données utiles PBF, telles que par exemple une date d'expiration de la validité du container.
Le second ensemble de données utiles peut également comprendre un champ SID/PN comprenant des données relatives à l'utilisateur, telles qu'un numéro d'identifiant d'abonné et/ou son numéro de téléphone.
Il convient de noter que la définition des champs du container se rapportant aux données utiles du container permettant d'utiliser le service pour lequel le container a été créé, ne confère aucun caractère restrictif pour la présente invention.
Le premier ensemble de données d'authentification fournit donc des fonctions de sécurité et d' intégrité du second ensemble de données utiles et peut être assimilé à une clé unique non forgeable permettant d'authentifier l'accès à un service donné.
Le container peut ainsi garantir par l'intermédiaire d'une vérification du premier ensemble de données d'authentification que l'accès à un service donné peut être autorisé, en fonction de droits d'accès définis dans le container, et que celui-ci a déjà été payé ou que l'utilisateur peut être facturé pour ce service. Une fois le premier ensemble de données CBF et le second ensemble de données PBF du container générés, ces premier et second ensembles de données sont chiffrés par application d'un algorithme de chiffrement à clé publique EPK, par exemple un algorithme de type RSA. On obtient de cette manière le container sécurisé TOKEN. Ce container ainsi sécurisé est prévu pour être stocké côté terminal utilisateur, afin de permettre la mise en oeuvre, à partir de ce terminal, d'une phase d'accès au service, qui sera mise en œuvre au niveau d'une passerelle PA du réseau de transmission de données, typiquement le serveur de gestion. La clé privée correspondante à la clé publique mise en œuvre dans le cadre de l'algorithme RSA pour le chiffrement des données constitutives du container étant mémorisée uniquement côté serveur.
De cette manière, les champs du container ne peuvent être modifiés que côté serveur de gestion et le terminal utilisateur ne pourra pas avoir accès aux données constitutives du container en clair. Le réseau de transmission de données .doit comprendre, au niveau de chaque serveur de gestion intervenant dans une phase d'accès au service par le terminal utilisateur, un système de traitement de données programmé de manière à réaliser les différentes étapes du procédé de l'invention. Ce système de traitement de données peut être individualisé en tant que système séparé du système informatique gérant le serveur, ou être intégré au système informatique par l'adjonction de logiciels intégrés. Ainsi, pour pouvoir mettre en œuvre une phase d'accès au service, le container sécurisé doit d'abord être stocké côté terminal utilisateur. Cette étape est décrite en référence à la figure 4 illustrant un échange sécurisé du container TOKEN, entre un terminal utilisateur 30 et un serveur de gestion 40 du réseau de transmission de données, lequel est prévu pour assurer la distribution des containers sur les terminaux, la vérification de ces containers et leur validation pour autoriser l'accès à un service donné et son exécution. La mise en œuvre de ces étapes sera décrite plus en détail par la suite.
Toujours selon l'exemple où le service souscrit par l'utilisateur est un service de téléphonie sur IP, le serveur 40 est un serveur placé dans le réseau devant une infrastructure de voix sur IP VoIP et qui transmettra tous les paquets de signalisation de l'appel vers le prochain dispositif VoIP de cette infrastructure, une fois que l'information d'un container TOKEN reçu d'un terminal ou, selon une variante, d'un autre nœud du réseau, dans le cadre d'une requête d'accès au service VoIP aura été récupérée et vérifiée, comme expliqué plus loin. Le serveur 40 est par exemple un serveur de type proxy SIP (« Session Initiation Protocol ») .
Ainsi, selon la variante introduite ci-dessus, le container et son utilisation dans un réseau de transmission de données comme décrit dans la présente description pour authentifier l'accès à un service donné, peuvent également être mis en œuvre dans le cadre d'un protocole de communication entre deux nœuds du réseau intervenant dans l'accès au service, par exemple entre deux serveurs de type proxy SIP.
Préalablement à la phase d'accès au service par l'intermédiaire du terminal utilisateur 30, une étape c de transmission du mot de passe OPT du terminal utilisateur 30 vers le serveur de gestion 40 est mise en oeuvre, déclenchant la transmission sécurisée à l'étape d, du container TOKEN, lui-même déjà sécurisé par le chiffrement lourd de type RSA, du serveur 40 vers le terminal 30.
Avantageusement, la transmission sécurisée du container TOKEN sur le réseau est assurée par l'application d'un algorithme de chiffrement symétrique CK0/ par exemple de type RC4, avec la clé secrète Ko, fournie préalablement à l'utilisateur et partagée par le serveur de gestion. Deux types de chiffrement sont donc appliqués sur le container. D'une part, le premier ensemble de données du container CBF est lié de façon sécurisé au second ensemble de données PBF par un chiffrement lourd de type RSA, géré côté serveur. D'autre part, le container bénéficie d'un second niveau de chiffrement, plus léger, de type RC4 pour sa transmission sécurisée à travers le réseau. Comme il apparaîtra plus loin, ce dernier type de chiffrement est prévu pour être mis en œuvre à la fois côté serveur et côté terminal, de sorte à assurer des propriétés anti-rejeu au container sécurisé.
Les clés secrètes utilisés dans les transmissions sécurisées du container sur le réseau sont changées très souvent de manière à renforcer davantage la sécurité compte-tenu de l'algorithme de chiffrement léger employé.
Les clés secrètes mises en œuvre sont donc renouvelées par période paramétrable. Ainsi, le renouvellement de la clé secrète K0 est réalisée en transmettant une nouvelle clé Kl en même temps que le container TOKEN lors de sa transmission sécurisée du l'
serveur 40 vers le terminal utilisateur 30. Le serveur 40 envoie donc Cκo(TOKEN, Kl) à destination du terminal 30.
A la réception, le terminal 30 déchiffre la valeur reçue à l'aide de la clé secrète K0 dont il dispose déjà, et récupère ainsi la valeur de container TOKEN, toujours chiffrée RSA, et la clé secrète Kl.
En référence à la figure 5, pour mettre en œuvre une phase d'accès au service souscrit, une requête d'accès au service envoyée par le terminal 30, consiste à transmettre en (e) le container de façon sécurisé CRI(TOKEN) vers le serveur 40, par application côté terminal de l'algorithme RC4 avec la clé secrète Kl sur le container. Compte-tenu du schéma de chiffrement léger, type RC4 choisi pour la transmission sécurisé du container, les étapes du procédé peuvent avantageusement être mises en œuvre sur des terminaux utilisateurs disposant de peu de ressources CPU disponibles. En outre, les opérations lourdes de sécurité du container étant gérées principalement côté serveur de gestion, notamment le chiffrement RSA des données constitutives du container, implémentation côté client sur le terminal utilisateur ne requiert qu'une application simple pouvant assurer un stockage sécurisé du container sur le terminal et la mise en œuvre du chiffrement RC4, servant à la transmission sécurisée du container.
A la réception du container chiffré RC4 CKi (TOKEN) côté serveur de gestion 40, la série d'étapes f à k est mise en œuvre. A l'étape f, le serveur réalise une opération de déchiffrement des données reçues du terminal. Il déchiffre tout d'abord CKi(TOKEN) avec la clé secrète Kl de manière à récupérer le container TOKEN, dont les données sont chiffrées avec RSA. Puis dans un second temps, il récupère le premier ensemble de données d'authentification CBF et le second ensemble de données utiles UBF du container par l'opération de déchiffrement RSA avec la clé privée correspondante dont il est le seul à disposer.
Une fois les données en clair du container récupérées, une étape de vérification de la validité du premier ensemble de données d'authentification XO, Xl, X2, X3 est mise en œuvre. Cette étape peut simplement consister à contrôler que les données d'authentification XO, Xl, X2, X3 forment effectivement des collisions de fonction de hashing.
En cas de succès de la vérification, le serveur 40 autorise l'accès au service pour son exécution en fonction des droits d'accès à ce service référencés dans le second ensemble de données utiles du container. Par exemple, le service accédé peut être un appel SIP vers un numéro international, autorisé en vertu des valeurs RBF/UBF/TCBF, les paquets de signalisation de cet appel étant alors transmis par le serveur vers l'infrastructure VoIP.
Les propriétés du container mis en œuvre apporte ainsi une grande souplesse dans la gestion d'accès au service de téléphonie sur IP. Notamment en ce qui concerne la problématique de « roaming ». Grâce au container, on n'est pas obligé de remonter vers une base de donnée centralisée pour identifier l'utilisateur. Les droits d'accès de l'utilisateur pour accéder au service peuvent en effet être vérifiés directement à partir du container sans avoir à remonter vers un compte utilisateur définissant ces droits.
Lors de l'étape g, le serveur 40 peut toutefois faire appel à une base de données utilisateur. La vérification peut ainsi consister à vérifier la correspondance des données d'authentification de la transaction issue du container avec des données d'authentification référencées dans une base de données utilisateurs pour cet utilisateur. Les données d'authentification de l'accès au service peuvent en effet être constituées dans une variante par une empreinte digitale numérisée de l'utilisateur, présentant les mêmes garanties de sécurité que l'utilisation des collisions de fonction de hashing.
Le serveur peut également vérifier dans la base de données utilisateur que les données utiles RBF, UBF et TCBF issues du container correspondent effectivement aux données utiles courantes pour l'accès au service mémorisées pour cet utilisateur dans la base.
Après l'exécution du service, une étape i de mise à jour des données utiles du container relatives aux droits d'accès au service, est mise en œuvre, en particulier, une étape de mise à jour des données RBF, UBF et TCBF. Par exemple, si une durée prépayée de 500 minutes avait été souscrite par l'utilisateur, à la fin d'une session d'appel de 7 minutes, la valeur initiale 500 du champ TCBF des données utiles du container est diminuée de 7. Les données utiles mises à jour sont alors sauvegardées côté serveur de gestion dans la base de données utilisateur.
Au cours de cette étape, un élément de facturation du coût du service peut éventuellement être généré et stocké au niveau du serveur 40, dont le contenu est déterminé à partir des données utiles du container relatives aux droits d'accès au service pour l'utilisateur. Par exemple, pour chaque accès au service VoIP, les variations des données TCBF, donnant le temps de communication, et UBF pour le coût d'une unité de communication, peuvent être mémorisées pour former l'élément de facturation. Les données d'authentification sont également associées à l'élément de facturation généré en tant que preuve que l'accès au service a bien été autorisé. L'élément de facturation ainsi mémorisé côté serveur 40 peut alors être utilisé ultérieurement auprès d'un organisme tiers afin d'obtenir une compensation financière sur la base des données accumulées. Suite à l'étape de mise à jour des donnée utiles du container, une étape de chiffrement RSA du premier ensemble de données d'authentification CBF et du second ensemble de données utiles PBF avec les données mises à jour, est mise en œuvre. On obtient de cette manière le container sécurisé mis à jour.
Enfin, le container sécurisé mis à jour est transmis à l'étape k de manière sécurisé vers le terminal utilisateur 30 pour une phase d'accès au service ultérieure, la transmission sécurisé étant assurée comme expliqué précédemment par l'application de l'algorithme RC4 avec Kl. Eventuellement, le renouvellement de la clé secrète Kl est réalisée lors de cette étape, en transmettant une nouvelle clé K2 qui servira lors de la phase d'accès au service ultérieur. La nouvelle clé secrète K2 est transmise en même temps que le container mis à jour TOKEN, lors de la transmission sécurisée du serveur 40 vers le terminal utilisateur 30. Le serveur 40 envoie donc Cκi(TOKEN, K2) à destination du terminal 30.
La transmission sécurisée du container TOKEN, dont les données sont déjà chiffrées, du terminal utilisateur 30 vers le serveur de gestion 40, ou du serveur vers le terminal utilisateur, ou encore entre deux serveurs du réseau, pour la mise en œuvre de l'accès au service et son exécution, est prévue pour être intégrée dans un protocole permettant des transmissions de voix sur IP, par exemple le protocole SIP, selon l'exemple de réalisation décrit en référence à un service VoIP souscrit. Afin d'insérer le container dans un paquet de données selon le protocole choisi, il est nécessaire de définir une en-tête afin de permettre le traitement adéquat selon l'invention des paquets porteurs de containers. Cette en-tête pourra par exemple être constituée de plusieurs champs tels que la taille des données, un numéro de contrôle, un identifiant de session ou d'autres informations de contrôle.
Selon une variante, le container d'informations TOKEN peut comprendre un troisième ensemble de données d'authentification, dont le rôle va être décrit ci- après. Ainsi, selon cette variante, une passerelle intermédiaire du réseau est mise en œuvre pour réaliser la transmission du container du terminal utilisateur vers le serveur de gestion lors d'une phase d'accès à un service sur le réseau. La passerelle intermédiaire est alors prévue pour réaliser une vérification préliminaire de la validité du container avant de router celui-ci vers le serveur de gestion, consistant à vérifier la validité du troisième ensemble de données d'authentification du container.
Le troisième ensemble de données d'authentification peut être représentées par des chaînes de bits obtenues par des collisions de fonction de hashing, de la même façon que pour le premier ensemble de données du container.
Le troisième ensemble de données du container peut également être chiffré en utilisant un algorithme de chiffrement à clés symétriques, type RC4.

Claims

REVENDICATIONS
1. Procédé d'accès à un service sur un réseau de transmission de données, par l'intermédiaire d'un terminal utilisateur (30) connecté audit réseau, caractérisée en ce qu' il comprend une phase de souscription audit service où:
- un container d'informations (TOKEN) associé à l'utilisateur est généré, comprenant un premier ensemble de données d'authentification (XO, Xl, X2, X3) de l'accès au service et un second ensemble de données utiles relatives audit utilisateur (SID/PN) et à des droits d'accès audit service (RBF, UBF, TBF), lesdits premier et second ensembles de données étant chiffrés, et où ledit container est transmis (d) de façon sécurisée sur ledit terminal utilisateur (30), et une phase d'accès audit service où : ledit container est transmis (e) de façon sécurisée dudit terminal utilisateur (30) vers au moins un serveur de gestion (40) connecté au réseau lors d'une requête d'accès audit service, et où
- le serveur (40) vérifie (g) , après déchiffrement (f) des données constitutives dudit container, la validité dudit premier ensemble de données d'authentification et, en cas de succès de la vérification, autorise (h) l'accès au service pour son exécution en fonction desdits droits d'accès du second ensemble de données.
2. Procédé selon la revendication 1, caractérisé en ce que la phase de souscription au service comprend le paiement (a) dudit service par l'utilisateur (10) auprès d'un serveur de paiement (20) .
3. Procédé selon la revendication 2, caractérisé en ce que la phase de souscription comprend en outre la fourniture (b) d'un mot de passe à usage unique (OTP) par le serveur de paiement (20) à l'utilisateur (10) , la transmission (c) dudit mot de passe du terminal utilisateur (30) vers le serveur (40) de gestion, déclenchant la transmission sécurisée (d) du container (TOKEN) dudit serveur (40) vers ledit terminal (30) .
4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, après l'exécution du service, une étape de mise à jour (i) des données utiles du container (TOKEN) relatives aux droits d'accès au service est mise en œuvre côté serveur (40) , lesdites données mises à jour étant sauvegardées côté serveur de gestion (40) .
5. Procédé selon la revendication 4, caractérisé en ce que, suite à la mise à jour, les premier et second ensembles de données du container sont chiffrés
(j) côté serveur (40), puis ledit container mis à jour est transmis (k) de façon sécurisée du serveur de gestion(40) vers le terminal utilisateur (30) pour une phase d'accès au service ultérieure.
6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la transmission sécurisée (d) du container consiste à transmettre sous forme cryptée les données constitutives dudit container par application d'un algorithme de chiffrement symétrique utilisant une clé secrète (K0, Kl, K2) partagée par le terminal utilisateur (30) et par le serveur (40) .
7. Procédé selon la revendication 6, caractérisé en ce que la clé secrète mise en œuvre est renouvelée par période paramétrable.
8. Procédé selon les revendications 5 et 7, caractérisé en ce que le renouvellement de la clé secrète consiste à transmettre une nouvelle clé en même temps que le container lors de sa transmission sécurisée du serveur (40) vers le terminal utilisateur (30) pour une phase d'accès au service ultérieure.
9. Procédé selon l'une quelconque des revendication 6 à 8, caractérisé en ce que l'algorithme de chiffrement symétrique mis en œuvre côté terminal (30) et côté serveur (40) est de type RC4.
10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le chiffrement des données constitutives du container avant leur transmission sécurisée est obtenue par application aux dites données d'un algorithme de chiffrement à clé publique, la clé privée correspondante étant mémorisée uniquement côté serveur (40) .
11. Procédé selon la revendication 10, caractérisé en ce que l'algorithme de chiffrement est un algorithme de type RSA.
12. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le premier ensemble de données d'authentification (XO, Xl, X2, X3) est représenté par des collisions de fonction de hashing.
13. Procédé selon la revendication 12, caractérisé en ce que l'étape de vérification côté serveur (40) consiste à contrôler que les données d'authentification (XO, Xl, X2, X3) forment effectivement des collisions de fonction de hashing.
14. Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce que l'étape de vérification, consiste à vérifier la correspondance des données d'authentification (XO, Xl, X2, X3) issue du container avec des données d'authentification référencées dans une base de données utilisateurs pour cet utilisateur.
15. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que un élément de facturation du coût du service est généré au niveau du serveur (40) après exécution dudit service, à partir des données utiles du container relatives aux droits d'accès au service pour l'utilisateur, les données d'authentification étant associées audit élément de facturation généré en tant que preuve que l'accès audit service a été autorisé.
16. Procédé selon la revendication 15, caractérisé en ce que l'élément de facturation est mémorisé en vue d'être utilisé pour compensation financière ultérieure.
17. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le service accédé est un service de voix sur IP.
18. Procédé selon la revendication 17, caractérisé en ce que la transmission du container du terminal (30) utilisateur vers le serveur (40) ou du serveur vers le terminal utilisateur pour l'accès au service, est intégrée dans un protocole permettant des transmissions de voix sur IP.
19. Procédé selon la revendication 18, caractérisé en ce que le protocole est un protocole SIP.
20. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la transmission du container (TOKEN) du terminal (30) utilisateur vers le serveur de gestion (40) est réalisée par l'intermédiaire d'une passerelle intermédiaire du réseau, ladite passerelle mettant en œuvre une étape de vérification préliminaire de la validité du container avant de router celui-ci vers 1edit serveur.
21. procédé selon la revendication 20, caractérisé en ce que l'étape de vérification préliminaire de la validité du container (TOKEN) consiste à vérifier la validité d'un troisième ensemble de données d'authentification dudit container.
22. Serveur (40) connecté à un réseau de transmission de données, pour l'accès à un service par l'intermédiaire d'un terminal utilisateur (30) connecté audit réseau, caractérisé en ce qu'il comprend des moyens de mise en œuvre des étapes du procédé selon l'une quelconque des revendications 1 à 21.
23. Serveur selon la revendication 22, caractérisé en ce qu'il est de type proxy SIP.
EP05796271A 2004-08-10 2005-08-05 PROCEDE D'AUTHENTIFICATION SECURISEE POUR LA MISE EN ŒUVRE DE SERVICES SUR UN RESEAU DE TRANSMISSION DE DONNEES Withdrawn EP1829280A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0408797A FR2874295B1 (fr) 2004-08-10 2004-08-10 Procede d'authentification securisee pour la mise en oeuvre de services sur un reseau de transmission de donnees
PCT/FR2005/002034 WO2006021661A2 (fr) 2004-08-10 2005-08-05 Procede d'authentification securisee pour la mise en œuvre de services sur un reseau de transmission de donnees

Publications (1)

Publication Number Publication Date
EP1829280A2 true EP1829280A2 (fr) 2007-09-05

Family

ID=34950840

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05796271A Withdrawn EP1829280A2 (fr) 2004-08-10 2005-08-05 PROCEDE D'AUTHENTIFICATION SECURISEE POUR LA MISE EN ŒUVRE DE SERVICES SUR UN RESEAU DE TRANSMISSION DE DONNEES

Country Status (4)

Country Link
US (1) US8359273B2 (fr)
EP (1) EP1829280A2 (fr)
FR (1) FR2874295B1 (fr)
WO (1) WO2006021661A2 (fr)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6735288B1 (en) * 2000-01-07 2004-05-11 Cisco Technology, Inc. Voice over IP voice mail system configured for placing an outgoing call and returning subscriber to mailbox after call completion
GB0319918D0 (en) * 2003-08-23 2003-09-24 Ibm Method system and device for mobile subscription content access
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US7596092B2 (en) * 2006-02-02 2009-09-29 Cisco Technology, Inc. VoIP verifier
PL1833219T3 (pl) * 2006-03-08 2015-01-30 Monitise Ltd Sposób, urządzenie i oprogramowanie wykorzystujące kod w celu obliczania ograniczonego czasowo hasła w telefonie komórkowym
US9807096B2 (en) * 2014-12-18 2017-10-31 Live Nation Entertainment, Inc. Controlled token distribution to protect against malicious data and resource access
JP5034821B2 (ja) * 2007-09-21 2012-09-26 ソニー株式会社 生体情報記憶装置
US8819838B2 (en) * 2008-01-25 2014-08-26 Google Technology Holdings LLC Piracy prevention in digital rights management systems
GB2464553B (en) * 2008-10-22 2012-11-21 Skype Controlling a connection between a user terminal and an access node connected to a communication network
US20110119190A1 (en) * 2009-11-18 2011-05-19 Magid Joseph Mina Anonymous transaction payment systems and methods
US20110162054A1 (en) * 2009-12-30 2011-06-30 Infosys Technologies Limited FIRMWARE AND METHOD FOR GENERATING ONE TIME PASSWORDS (OTPs) FOR APPLICATIONS
JP5573489B2 (ja) * 2010-08-23 2014-08-20 ソニー株式会社 情報処理装置、および情報処理方法、並びにプログラム
CN102572815B (zh) * 2010-12-29 2014-11-05 中国移动通信集团公司 一种对终端应用请求的处理方法、系统及装置
US9734306B2 (en) * 2012-05-21 2017-08-15 Sony Corporation Information processing apparatus, information processing system, information processing method, and program
US9106411B2 (en) * 2012-09-30 2015-08-11 Apple Inc. Secure escrow service
US9332008B2 (en) 2014-03-28 2016-05-03 Netiq Corporation Time-based one time password (TOTP) for network authentication
US9842062B2 (en) 2015-05-31 2017-12-12 Apple Inc. Backup accessible by subset of related devices
US10063557B2 (en) 2015-06-07 2018-08-28 Apple Inc. Account access recovery system, method and apparatus
JP5951094B1 (ja) * 2015-09-07 2016-07-13 ヤフー株式会社 生成装置、端末装置、生成方法、生成プログラム及び認証処理システム
US10630648B1 (en) * 2017-02-08 2020-04-21 United Services Automobile Association (Usaa) Systems and methods for facilitating digital document communication
US11870899B2 (en) * 2021-08-30 2024-01-09 Whitestar Communications, Inc. Secure device access recovery based on validating encrypted target password from secure recovery container in trusted recovery device
CN115600177B (zh) * 2022-10-09 2024-04-16 北京金和网络股份有限公司 一种身份认证的方法、装置、存储介质及电子设备

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5153919A (en) * 1991-09-13 1992-10-06 At&T Bell Laboratories Service provision authentication protocol
US5970144A (en) * 1997-01-31 1999-10-19 Synacom Technology, Inc. Secure authentication-key management system and method for mobile communications
CA2255285C (fr) * 1998-12-04 2009-10-13 Certicom Corp. Protocole ameliore d'authentification d'abonne
US7035410B1 (en) * 1999-03-01 2006-04-25 At&T Corp. Method and apparatus for enhanced security in a broadband telephony network
EP1410658A2 (fr) * 1999-12-03 2004-04-21 First Hop Oy Procede et systeme d'obtention de services via un systeme de telecommunication cellulaire
US6760841B1 (en) * 2000-05-01 2004-07-06 Xtec, Incorporated Methods and apparatus for securely conducting and authenticating transactions over unsecured communication channels
US7721109B1 (en) * 2000-07-28 2010-05-18 Verizon Business Global Llc Secure transaction card using biometrical validation
US6938019B1 (en) * 2000-08-29 2005-08-30 Uzo Chijioke Chukwuemeka Method and apparatus for making secure electronic payments
PL345054A1 (en) * 2001-01-11 2002-07-15 Igor Hansen Personal database system and method of managing the access to such database
US7181017B1 (en) * 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
US20030037261A1 (en) * 2001-03-26 2003-02-20 Ilumin Corporation Secured content delivery system and method
US7302571B2 (en) * 2001-04-12 2007-11-27 The Regents Of The University Of Michigan Method and system to maintain portable computer data secure and authentication token for use therein
EP1257106B1 (fr) * 2001-05-08 2005-03-23 Telefonaktiebolaget LM Ericsson (publ) Accès sécurisé à un module d'abonné distant
US20040029562A1 (en) * 2001-08-21 2004-02-12 Msafe Ltd. System and method for securing communications over cellular networks
DE10164131A1 (de) * 2001-12-30 2003-07-17 Juergen K Lang Kryptographisches Modul zur Speicherung und Wiedergabe kopier-und nutzungsgeschützter elektronischer Ton- und Bildmedien
GB2410658B (en) * 2002-10-14 2006-03-01 Toshiba Res Europ Ltd Methods and systems for flexible delegation
US20050004873A1 (en) * 2003-02-03 2005-01-06 Robin Pou Distribution and rights management of digital content
JP2006526204A (ja) * 2003-03-13 2006-11-16 ディーアールエム テクノロジーズ、エルエルシー セキュアストリーミングコンテナ
US7421732B2 (en) * 2003-05-05 2008-09-02 Nokia Corporation System, apparatus, and method for providing generic internet protocol authentication
US20050050330A1 (en) * 2003-08-27 2005-03-03 Leedor Agam Security token
US7430606B1 (en) * 2003-10-17 2008-09-30 Arraycomm, Llc Reducing certificate revocation lists at access points in a wireless access network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006021661A2 *

Also Published As

Publication number Publication date
FR2874295B1 (fr) 2006-11-24
WO2006021661A2 (fr) 2006-03-02
US8359273B2 (en) 2013-01-22
WO2006021661A3 (fr) 2006-10-26
FR2874295A1 (fr) 2006-02-17
US20080176533A1 (en) 2008-07-24

Similar Documents

Publication Publication Date Title
EP1829280A2 (fr) PROCEDE D'AUTHENTIFICATION SECURISEE POUR LA MISE EN ŒUVRE DE SERVICES SUR UN RESEAU DE TRANSMISSION DE DONNEES
EP1683388B1 (fr) Methode de gestion de la sécurité d'applications avec un module de sécurité
EP1427231B1 (fr) Procédé d'établissement et de gestion d'un modèle de confiance entre une carte à puce et un terminal radio
EP1909462B1 (fr) Procédé de mise à disposition cloisonnée d'un service électronique
EP0973318A1 (fr) Procédé pour payer à distance, au moyen d'un radiotéléphone mobile, l'acquisition d'un bien et/ou d'un service, et système et radiotéléphone mobile correspondants
EP1442557A2 (fr) Systeme et procede pour creer un reseau securise en utilisant des justificatifs d'identite de lots de dispositifs
EP1103935A2 (fr) Procédé de transmission d'information et serveur le mettant en oeuvre
FR2930390A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise.
FR3058243A1 (fr) Procede de controle d'identite d'un utilisateur au moyen d'une base de donnees publique
EP3375133A1 (fr) Procede de securisation et d'authentification d'une telecommunication
WO2015059389A1 (fr) Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal
EP3965361B1 (fr) Echange de données entre un client et un dispositif distant, par exemple un module sécurisé
EP1949590A1 (fr) Procede de depot securise de donnees numeriques, procede associe de recuperation de donnees numeriques, dispositifs associes pour la mise en uvre des procedes, et systeme comprenant les dits dispositifs
EP1514377A1 (fr) Procede et dispositif d'interface pour echanger de maniere protegee des donnees de contenu en ligne
WO2020260136A1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
EP1400090B1 (fr) Procede et dispositif de securisation des communications dans un reseau informatique
WO2022269179A1 (fr) Procede et dispositif de paiement par chaines de blocs
EP1413158B1 (fr) Procede d'acces a un service specifique propose par un operateur virtuel et carte a puce d'un dispositif correspondant
EP2911365B1 (fr) Procédé et système de sécurisation de transactions offertes par une pluralité de services entre un appareil mobile d'un utilisateur et un point d'acceptation
EP2317691B1 (fr) Système et procédé de sécurisation contextuelle et dynamique des échanges de données au travers d'un réseau
WO2024153437A1 (fr) Procédés de signature de données, de fourniture de données signées, terminal et serveur associés
WO2021165625A1 (fr) Procede de calcul d'une cle de session, procede de recuperation d'une telle cle de session
FR3128089A1 (fr) Procédé et dispositif de sélection d’une station de base
FR3066346A1 (fr) Procede de securisation en vue d'un appairage hors bande dans la bande
FR3049087A1 (fr) Procede permettant a des dispositifs par l'intermediaire de connaissances et de capacites croisees, de realiser des transactions a travers un reseau informatique decentralise

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070615

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20100421

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20130701