EP1680905A1 - Procede de transfert de donnees confidentielles en coeur de reseaux - Google Patents

Procede de transfert de donnees confidentielles en coeur de reseaux

Info

Publication number
EP1680905A1
EP1680905A1 EP04805271A EP04805271A EP1680905A1 EP 1680905 A1 EP1680905 A1 EP 1680905A1 EP 04805271 A EP04805271 A EP 04805271A EP 04805271 A EP04805271 A EP 04805271A EP 1680905 A1 EP1680905 A1 EP 1680905A1
Authority
EP
European Patent Office
Prior art keywords
data
user
communication equipment
confidential data
provider
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
EP04805271A
Other languages
German (de)
English (en)
Inventor
Anne Boutroux
Vincent Boutroux
Karel Mittig
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.)
Orange SA
Original Assignee
France Telecom SA
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 France Telecom SA filed Critical France Telecom SA
Publication of EP1680905A1 publication Critical patent/EP1680905A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the present invention relates to a method for transferring confidential data at the heart of networks. It finds application in particular in the fields of transactions using the Internet. In the technical field of computer communications, users who want to consult data content via a computer network such as the Internet, must in most cases obtain a connection resource from a provider of access to the computer network.
  • this file cannot be used by another content provider and must therefore be reconstituted by the latter for its own account, which adds an entry under the responsibility of the user and the existence of a new file ("cookie") which the latter generally ignores the existence.
  • a "trusted third party" to whom the user transmits his confidential data once and for all.
  • the content provider contacts the trusted third party to securely obtain the user's confidential data.
  • the exchange with the trusted third party is done with a means of data protection which is not at the discretion of the content provider.
  • the trusted third party needs to place “cookie” type files on the user's terminal and the latter must still have registered with the trusted third party.
  • the trusted third party is also in possession of a large number of confidential data, which exposes it to the lusts of hackers who can follow secure transactions by accessing the “cookie” files signed by the trusted third party at least on user machines.
  • the "trusted third party" provides each user who requests it, software which makes it possible to memorize the confidential data of the user necessary for the execution of transactions with subscribed content providers for which the user has indicated his intention to be able to access it and to conduct transactions such as debit cards.
  • the user must still correspond with a third party supplier of the software to establish a part of the transaction, in particular the banking part of the transaction when it puts implement a payment by bank card.
  • the present invention provides a remedy to these drawbacks of the state of the art.
  • Internet users who use the services of an Internet service provider, exchange confidential data. Such data could be intercepted by people who could surprise the secret that the parties expect from a data exchange. This will be the case for a file containing professional data such as manufacturing secrets.
  • the sending party performs encryption of the data which is then transmitted to the receiving party to be decrypted there. Such encryption guarantees data confidentiality and data integrity.
  • the present invention remedies this other drawback of the state of the art. Indeed, it relates to a method for transferring confidential data between at least one user terminal and communication equipment belonging to a supplier of content, the terminal having received attributes for connection to a data processing network owned by an access provider.
  • the method of the invention consists: - on the side of the user terminal transmitting confidential data, to send, via the network, a service request for content constituted according to a predetermined protocol intended for the communication equipment of the supplier of contents; - then, on the side of a communication equipment belonging to the access provider: • to intercept the service request according to the address of the communication equipment of the content provider; • to execute an encryption service for confidential data relating to the terminal user; • modify the service request intercepted by inserting encrypted confidential data into it; • and re-route the modified service request to the communication equipment of the content provider; - then, on the communication equipment side of the content provider: • to receive the modified service request; • extract the encrypted confidential data in relation to the address of the user terminal, • and decrypt the encrypted confidential data, using a decryption key compatible with the encryption key.
  • the method also includes a preparatory step which consists on the side of the communication equipment of the access provider: - to constitute, during a registration procedure, a file comprising the confidential data associated with the terminal user at the same time as his network access account data; - to constitute, during an authorization procedure, an authorization data file of the content provider, such an authorization file containing at least data relating to the identification of the authorized content supplier.
  • the authorization file also contains an encryption key which is used during the step of encryption of confidential data relating to the user of the terminal by the communication equipment of the supplier d 'access.
  • the present invention also relates to communication equipment belonging to a provider of access to a computer network which offers a service for transferring confidential data between at least one user terminal and communication equipment belonging to a content provider.
  • the communication equipment of the access provider is remarkable in that it comprises: - an interception module for intercepting, as a function of the address of the communication equipment of the content provider, a service request d content constituted according to a predetermined protocol, such a request being sent from the user terminal to the communication equipment of the content provider; - an encryption module for encrypting confidential data relating to the user of the terminal; - a request modification module for inserting the encrypted confidential data in the intercepted service request; - And a module for re-routing the modified service request to the communication equipment of the content provider.
  • the communication equipment of the access provider further comprises a module for executing a preparatory step of registering users and authorizing content providers.
  • the execution module of the preparatory step comprises: a web server to which, on the one hand, the user's terminal transmits confidential data, and, on the other hand, the communication equipment of the content provider transmits authorization data, - a first storage sub-module in which the confidential data are recorded, - and a second storage sub-module in which the authorization data are recorded .
  • the interception module and the redirection module are contained in a proxy-cache device, while the encryption module and the module are contained in a server implementing an interface which supports an HTTP data flow transfer protocol.
  • the present invention also relates to communication equipment belonging to a content provider authorized beforehand with a provider of access to a computer data network which offers a service for transferring confidential data between at least one user terminal and this communication equipment.
  • the communication equipment of the content provider is remarkable in that it comprises: a module for receiving a service request for content sent by the terminal, such a request comprising confidential encrypted data relating to the terminal user; - A module for extracting encrypted confidential data in relation to the address of the user's terminal, - and a module for decrypting confidential encrypted data using a decryption key compatible with the encryption key.
  • the present invention also relates to a server implementing an interface which supports a data flow transfer protocol.
  • Such a server is remarkable in that it comprises: - a module for receiving, coming from a terminal, a service request for content constituted according to the aforementioned protocol, - a module for establishing a correspondence between the address allocated to the terminal and at least one confidential datum relating to the user of the terminal, the confidential datum being previously recorded in a storage sub-module, - a module for verifying the agreement of the user for the transmission of confidential data relating to the latter, the confidential data also being recorded beforehand in the storage sub-module, - an export module for extracting, in the case where the verification is positive, on the one hand, the data confidentiality of the storage sub-module, and on the other hand, an encryption key previously registered in a storage sub-module belonging to a supplier of contents for which the service request is intended, - a module for encrypting confidential data by means of the extracted encryption key, - a request modification module for inserting the encrypted confidential data in a particular field of the service request, - And a module for retransmission
  • the present invention also relates to a system for transferring confidential data between at least one user terminal and communication equipment belonging to a content provider, the terminal having received connection attributes to a data processing network owned by an access provider.
  • the user terminal transmitting confidential data comprises a module for transmitting, via the aforementioned network, a service request for content constituted according to a predetermined protocol intended for the equipment.
  • content provider communication - the communication equipment of the content provider is that defined above, and in that it further comprises: - communication equipment belonging to the access provider, as defined above.
  • FIG. 1 represents a procedure for transaction of confidential data according to a state of the art
  • - Figure 2 is a flowchart showing a particular embodiment of the method of the invention
  • Figure 3 is a block diagram of a system implementing the method of the invention
  • Figures 4 (a) and 4 (b) are diagrams of databases used in the method of the invention
  • FIG. 5 is a block diagram of a system implementing another embodiment of the method of the invention.
  • the user terminal 1 which can be a desktop computer or even a mobile phone, is connected to the computer network via a provider of access to the computer network 2. Such a connection is only possible if the user 1 is registered with the access provider 2.
  • the user indicates a certain number of confidential data determined by the access provider 2.
  • a content provider 4 is connected to the computer network 2. During of his registration, the content provider 4 indicates the type of confidential data that users who connect to his site could be led to exchange with him.
  • the computer network access provider determines the confidential data that it must request from its users when they first register with the network.
  • the user 1 connects along the path 5 to the content provider 4, the latter presents him, along the path 10, requests tending to transmit confidential data held directly by the access provider 2.
  • the content provider 4 transmits a request 6 to a billing third party 3.
  • the billing third party 3 then sends to the network access provider 2 a data transfer request confidential data associated with both user 1 and its recipient 4.
  • the network access provider 2 consults the databases and extracts confidential data relating to user 1. It transmits the confidential data requested to an invoicing third party 3 according to an encrypted procedure 8, which then sends invoicing processing to benefit of the digital content provider 4 in respect of the user and which transmits an acknowledgment of the transaction to the content provider by means of a return connection 9.
  • the content provider 4 informs its user 1 of the execution of the transaction constituted by the transfer of the confidential data requested.
  • FIG. 2 a flowchart has been represented. of an embodiment of the method of the invention.
  • a start step S 1 which can be initiated as soon as a user and / or content provider is detected.
  • a loop B 1 during which a preparatory step S2 is executed.
  • a step S21 of registering a new user is performed or a step S22 of enabling a new content provider is performed. If the user or the content provider is not identified as registered or authorized, we enter a registration or authorization phase.
  • the registration phase makes it possible to constitute a confidential data file associated with a user at the same time as his data account for access to the computer network during a registration procedure held by the supplier of access to the computer network as the Internet.
  • the authorization phase aims to constitute an authorization data file for at least one content provider.
  • This content provider for example, owns a website and offers services requiring the communication of confidential user data.
  • this user is registered with the network access provider
  • the Internet and the confidential data requested by the content provider are recorded in the confidential data file associated with this user when he requests the services of the content provider.
  • These services can be market services, purchase of multimedia documents over the Internet, or indirectly products or services, for example sold by a multimedia catalog produced by the content provider.
  • these services may also not be market services and for example consist of the transmission of confidential data produced by the user so that a special treatment is carried out by the content provider.
  • the confidential data consists of a data file returned by the content provider to the user.
  • the exchanges of keys of two-key encryption procedures are carried out when personal data of the registration and / or authorization procedures are updated with the Internet Service Provider.
  • the data file can be directly associated in an HTTP request, for example on a method called "POST Method" or in the form of a URL address or an indirect reference to a data file to be encrypted.
  • the authorization file is constructed using an application owned by the Internet access provider on the database relating to the identification of the authorized content provider and, where appropriate, configuration data to prepare a transaction with at least one registered user.
  • the access provider has an application that allows him to request the confidential data required speak authorization file for each content provider with which the user wishes to have contact. If one of the partners, user or content provider, is not registered, the access provider has a registration application or an authorization application to enter it into the transfer service of confidential data of the invention. If either partner refuses, the service is interrupted (not shown).
  • the preparatory phase S2 is immediately ended. Note that a communication between a single user and a single content provider is described here. It will be understood that more than one user can be connected in a preparatory phase, or a federation of content providers such as an Internet portal or a ring of genre providers
  • a second loop B2 is initiated and, during an end-of-loop test T1 which terminates the first loop B1, it is verified that the two partners are correctly recognized as is. described above.
  • the method of the invention then comprises an operating step S3 which starts during a transaction between a user registered with the access provider and a content provider offering the service required by said user and authorized during the preparatory stage.
  • the second loop initiated in B2 is terminated by an end-of-loop test T2 which terminates the confidential data transfer service according to the invention, during an end step S4.
  • each loop B1 or B2 can be initiated by the detection of a request to open the preparatory phase (registration or authorization) or an operating request (detection of a transaction request requesting the transfer of confidential data) asynchronously. It is understood that the process of FIG. 2 can be executed in several replications operating in parallel with a multi-channel communications system.
  • the invention therefore applies to transactions of various types.
  • a transaction according to the invention is established between a user and a transfer site of the web genre, but also of other genres, such as WAP.
  • Such a transaction always includes at least one encryption of confidential data executed at the heart of the network, and therefore an encryption which is not submitted either to the user, or to the transfer site, or to a third party other than the provider.
  • Such a transaction may relate directly to digital content presented by the content provider or to other non-digital content or non-computer products or services such as those of a Mail Order or similar service. It can be merchant or not, implement a financial or banking transaction. In the application of the invention to the payment of goods on
  • the method of the invention brings together a provider 40 for access to a network such as the Internet, at least one content provider 39 and at least one user 38 of said provider 39 content
  • a provider 40 for access to a network such as the Internet, at least one content provider 39 and at least one user 38 of said provider 39 content
  • the Internet Service Provider 40 are: - A User Registration Database 20 in which each user account registered with the Internet Service Provider 40 is maintained; - A database 21 for authorizing content providers in which each authorization account is maintained for content providers authorized by the Internet Service Provider 40.
  • the Internet Service Provider has one or more resources which are: a resource 23 for registering or modifying a user account with the user registration database 20; a resource 24 for enabling or modifying an enabling account with the database 21 for enabling; - an encryption resource C; an HTTP request diversion resource D which allows, in an HTTP channel 33, to take a request 31, 32 formulated on the user's Internet browser to present it to the encryption resource at the Internet Service Provider 40; a resource R for re-routing the HTTP request in which a portion 32 of clear or reference X data is available to allow the encryption executed by the resource C as a function of encryption data contained in the accounts database 20 user and / or in the database 21 of authorization accounts.
  • resources are: a resource 23 for registering or modifying a user account with the user registration database 20; a resource 24 for enabling or modifying an enabling account with the database 21 for enabling; - an encryption resource C; an HTTP request diversion resource D which allows, in an HTTP channel 33, to take a request 31, 32 formulated on
  • the HTTP request is conventionally composed with a mechanism for producing data in the HTTP request 31.
  • Confidential data can be inserted as described below, on the fly by the Internet Service Provider without further intervention from the registered user.
  • the encrypted part of data 35 in the request 34 as re-routed by the re-routing resource R and the encrypted part X can then be decrypted by a local resource of decryption and used by a local resource for using the X data, in particular for producing an HTTP response (not shown) on the HTTP channel 33.
  • FIG. 4 (a) the structure of a registration file is shown.
  • FIG. 4 (b) the structure of an authorization file 45 of a content provider authorized by the Internet access provider and which comprises: identification data 46 of the content provider has been represented. empowered; object generation data 47 which contain the object generation arguments allowing the application 25 (FIG. 3) to generate the object accessible by the user according to what has already been described; data defining the address of the site receiving the confidential data from the registration file sent when the user has performed the expected action on the dot object accessible by the user.
  • FIG. 5 there is shown an Internet communication system in a particular embodiment of the method of the invention in which we will specify in particular the means of control of the Internet service provider ISP on a transaction between a content provider and a user during which confidential data must be transmitted.
  • the communication system implements three parts: the user, customer of the Internet service provider, the Internet service provider ISP and at least one content provider site. The various means required are respectively:
  • a terminal 50 provided with a data processing connection to the ISP access provider, a means for producing and receiving HTTP type requests, such as a browser and means for processing digital content originating from content providers via the Internet provider's network;
  • resources 52 for producing digital content resources for producing and receiving HTTP requests with users connected to the Internet by the Internet service provider ISP;
  • a Web server 53 to execute the preparatory step of registering users and authorizing content providers, a “proxy-cache” device implementing an iCAP 51 client, a server iCAP implementing an iCAP service 55, a database 54 of the ISP users having subscribed to the secure transfer service of confidential data of the invention, a database 56 of the authorization data of the content providers, partners of the provider of Internet access ISPs and who request to benefit from the confidential data of users registered in the database 55.
  • proxy-cache and iCAP protocol techniques implemented at the level of the Internet service provider ISP, reference may be made to the content of patent application FR 2 823 044 of March 30, 2001 in the name of France Telecom. The means to produce and receive type requests
  • HTTP HyperText Transfer Protocol
  • WAP Wireless Application Protocol
  • SMTP Simple Mail Transfer Protocol
  • RTCP Real Time Transfer Protocol
  • This latter protocol is based on periodic transmissions of control packets by all the participants in a session in flow control of another protocol known as the RTP protocol, making it possible to convey basic information about the participants of a session, and on the quality of service, in particular during communications between several users and / or content providers, the latter actors being considered from the point of view of the present invention.
  • RTP protocol another protocol known as the RTP protocol
  • the user 50 informs the confidential data on a Web server 53 by a secure connection of “HTTPs” type or non-secure. This connection can take place during the first connection to the ISP Provider for user registration, or later during an update procedure.
  • the confidential data are then hosted by a writing 62, or an update if necessary, at the level of the database 54 of the users of the ISP supplier.
  • the same procedure (not shown) is followed for the authorization data of the database 56 of the content providers partners of the Internet service provider ISP.
  • the content provider to the website from which the user has connected through the proxy-cache of the ISP provider has transmitted a web page in which there is a proposed transaction with data transmission.
  • the proxy-cache 51 installed at the ISP supplier, includes a means for intercepting online purchase requests or any other HTTP request originating from the browser of a user registered with the Internet access provider. Interception 64 takes place by means of the analysis of lists, called "ACLs", which are part of the flow management functionalities of a proxy-cache. Having detected in the "ACLs" the presence of an online purchase request, the proxy-cache routes this request to a server implementing an interface supporting an HTTP flow transfer protocol such as an iCAP server implementing the iCAP service transfer of confidential data defined in the method of the invention.
  • the request arriving at the iCAP 55 server is of the following form commented in Table 1: Table 1:
  • Accept-Encoding gzip
  • deflate User-Agent Mozilla / 4.0 (compatible; list)
  • X-Forwarded-For yyy.yyy.yyy.yyy in which request: xxx. xxx. xxx. xxx is the IP Internet address of the iCAP 55 service; - yyy.yyy.yyy.yyyy is the Internet address url of the detected user and HTTP: //www.site.domain/ is the address of the detected website of the content provider; the other fields of the request in the form of table 1 make it possible to determine the resources available for the generation of the object accessible by the user.
  • the iCAP server 55 which receives the request from table 1 implements an iCAP service implementing the processing part of the operating step of the method of the invention according to the teachings presented in particular in the French patent application FR 2 823 044 registered in the name of France Telecom to which we will refer for the details of realization.
  • the iCAP service then performs a step 66 to establish the correspondence between the Internet IP address of the X-Client-I P field allocated to the user for the current session and which is found in the HTTP request header and an identifier of the user contained in its database of registered users 54.
  • the iCAP service then performs a step to verify the agreement of the user for the transmission of his data confidential to the partner site during a step 67.
  • the iCAP server 55 exports 68 this confidential data necessary for the purchase in line from the user database 54 to the iCAP server 55.
  • the iCAP service then performs a step of interrogating the database of authorized suppliers (partners) 56 to know the public key of the declared supplier and, if necessary if this data is missing, to determine the address of the destination site of confidential data, here defined in the request in the IP address field destination of confidential data (Host field - Table 1) in stream 69.
  • the exchange steps flows 68 and 69 can be performed simultaneously to speed up the service.
  • the step of exchanging the flow 69 is executed first and then only after those of the flows 66 and 67.
  • the iCAP server 55 performs an encryption step with the appropriate public key from stream 70 and inserts them in a particular field, which could be normalized and which is entitled “Encrypted-Data”, internal to the HTTP request which returns the correct public key.
  • the iCAP server 55 then performs a step of retransmission of the modified request in the stream 72 to the proxy-cache 51.
  • the modified request then becomes according to Table 2: Table 2:
  • X-Client-IP yy.yyy.yyy.yyy
  • Encrypted-Data zzzzzzzzzzzzzzzzzzzzzzzz in which request the last two lines have been added to the initial request which are: the line "VIA" defining the iCAP resource of the proxy-cache responsible for transmitting the modified request to the site of the authorized provider partner receiving the encoded data; the “Encrypted-Data” line containing the stream of encrypted data.
  • the proxy-cache then performs a transmission step 73 to the site of the host concerned by the online purchase.
  • the encryption of the user data is done on the ICAP server 55 and the insertion of this encrypted data is carried out in a field of the request received in the stream 65 by the ICAP server and retransmitted by the stream 72.
  • the content provider 62 hosting the online shopping site extracted from the HTTP header (“Encrypted-Data” line) during a step 74 which it decrypts using its own private key and processes the online purchase of the user, his own client.
  • the content provider 62 executes: if the confidential data transmitted are bank data (credit card, direct debit account number), a user billing step is carried out by the content provider; if the confidential data transmitted is identification data for a client of the content provider, a billing step for the client is carried out and transmitted with this identifier to the ISP access provider, which can then re-charge its own client client 50.
  • a response step 76 containing the confirmation of the transaction to the proxy-cache 51 is then carried out. Then, the proxy-cache 51 performs a routing step 77 of the transaction confirmation towards the user 50.
  • the Internet service provider ISP can offer a service to hide the identity of its users by assigning them a unique and encrypted identifier that can be linked to this single customer. This results in this case:
  • the real identity of the customer is hidden from the content provider, which preserves the anonymity of the customer during purchase; such a characteristic makes it possible in particular to reduce the involuntary dissemination of the name of the users in commercial files which in return produce unwanted commercial solicitation messages (spamming in particular);
  • the bank details of the registered user no longer pass over the network, which reinforces the security of confidential data; 3.
  • the Internet service provider ISP then acts as a third party for invoicing and can set up an economic model of remuneration on commercial exchanges. Finally, the invention provides assurance to any content provider authorized by the Internet service provider ISP of the veracity of the identity of its user since the latter is authenticated by his access.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne un procédé de transfert de données confidentielles en coeur de réseaux. Elle trouve application notamment dans les domaines des transactions utilisant le réseau Internet. Dans une étape préparatoire (B1, S2) le fournisseur d'accès Internet effectue l'inscription d'utilisateurs en recueillant notamment leurs données confidentielles et l'habilitation de fournisseurs de contenus. Dans une phase d'exploitation (B2, S3), le fournisseur d'accès Internet détecte l'identité tant de l'utilisateur que de son fournisseur de contenus lors d'une transaction exigeant le transfert de données confidentielles et transmet celles-ci depuis ses propres moyens par une seule action d'acquittement de l'utilisateur.

Description

"Procédé de transfert de données confidentielles en cœur de réseaux" La présente invention concerne un procédé de transfert de données confidentielles en cœur de réseaux. Elle trouve application notamment dans les domaines des transactions utilisant le réseau Internet. Dans le domaine technique des communications téléinformatiques, les utilisateurs qui veulent consulter des contenus de données par un réseau informatique comme le réseau I nternet, doivent dans la plupart des cas obtenir une ressource de connexion auprès d'un fournisseur d'accès au réseau téléinformatique. Quand l'échange de données met en relation fournisseur de contenus, par exemple doté d'un serveur Web avec un utilisateur doté d'un navigateur exécuté sur un terminal connecté physiquement au réseau Internet, trois opérateurs économiques distincts se sont développés : - les fournisseurs d'accès au réseau ; - les fournisseurs de contenus qui proposent le transfert de fichiers de données numériques comme des pages html ou des images ou séquences vidéo, et aussi proposent à la vérité par le moyen de tels fichiers, des biens comme des produits ou des services à des utilisateurs ; - les utilisateurs clients de ces fournisseurs de contenus qui souhaitent consulter les contenus numériques disponibles et le cas échéant effectuer des transactions confidentielles comme des achats avec les fournisseurs de contenus. Les utilisateurs clients des fournisseurs de contenus ont besoin de disposer d'un premier contrat avec un fournisseur d'accès au réseau téléinformatique. Puis, les échanges de données se déroulent sans intervention réelle du fournisseur d'accès au réseau. Or, les communications entre leurs utilisateurs et les fournisseu rs de contenus contiennent de plus en plus fréquemment des données confidentielles. C'est particulièrement le cas d'une transaction commerciale dans laquelle un utilisateur commande directement un contenu numérique ou indirectement un bien par l'intermédiaire du réseau Internet en utilisant une carte bancaire. Il est le plus souvent conduit à échanger avec le fournisseur du bien des données personnelles qui doivent recevoir un traitement de protection comme un chiffrement ou cryptage, pour être inutilisables par des tiers non autorisés. Pour parvenir à cette protection, il est déjà défini dans l'état de la technique un protocole de transaction sécurisée de type "HTTPs" qui utilise des couches de sécurité associées au protocole Internet classique. Dans de telles transactions, l'utilisateur doit, et ce à chaque transaction, saisir à nouveau les données confidentielles de la transaction sécurisée comme le code de sa carte bancaire. Or, particulièrement sur certains terminaux de consultation, comme les téléphones mobiles, de telles saisies sont peu pratiques. Pour remédier à cet inconvénient, il est déjà connu par certains fournisseurs de contenus d'installer des fichiers définis dans les normes de téléinformatique comme les "cookies" du protocole Internet sur le terminal de l'utilisateur et qui contiennent des copies des données confidentielles transmises par l'utilisateur. Mais cette solution présente plusieurs inconvénients. Tout d'abord, le traitement de protection est effectué par le fournisseur de contenus sans aucun contrôle possible de la part de l'utilisateur et ce, sans garantie de sécurité des données. Ensuite, l'enregistrement des données confidentielles est fait à l'insu de l'utilisateur qui détient alors un fichier dont il ignore le contenu avec tous les risques qu'une telle ignorance fait courir à ces données. Enfin, ce fichier n'est pas exploitable par un autre fournisseur de contenus et doit donc être reconstitué par ce dernier pour son propre compte, ce qui ajoute une saisie sous la responsabilité de l'utilisateur et l'existence d'un nouveau fichier ("cookie") dont ce dernier ignore généralement l'existence. Pour dégager la responsabilité des fournisseurs de contenus, il a été proposé d'utiliser un "tiers de confiance" à qui l'utilisateur transmet une fois pour toutes ses données confidentielles. Lors d'une communication confidentielle avec un utilisateur, le fournisseur de contenus s'adresse au tiers de confiance pour obtenir de manière sécurisée les données confidentielles de l'utilisateur. L'échange avec le tiers de confiance se fait avec un moyen de protection des données qui n'est pas à la discrétion du fournisseur de contenus. Mais, pour réaliser le lien entre l'utilisateur et le fournisseur requérant, le tiers de confiance a besoin de déposer des fichiers de type « cookies » sur le terminal de l'utilisateur et encore faut-il que ce dernier se soit inscrit auprès du tiers de confiance. Enfin, le tiers de confiance se trouve aussi en possession d'un nombre important de données confidentielles, ce qui l'expose aux convoitises des pirates qui peuvent suivre les transactions sécurisées en accédant aux fichiers « cookies » signés du tiers de confiance au moins sur les machines des utilisateurs. Dans un autre état de la technique, il est connu que le « tiers de confiance » fournisse à chaque utilisateur qui en fait la demande, un logiciel qui permet de mémoriser les données confidentielles de l'utilisateur nécessaires à l'exécution de transactions avec des fournisseurs de contenus abonnés pour lesquels l'utilisateur a marqué son intention de pouvoir y accéder et de mener des transactions du genre débit de carte bancaire. Cependant, cette solution est, par exemple dans le cas du logiciel « Gator » ™ gratuite pour l'utilisateur et rémunérée par son acceptation de bandeaux publicitaires et autres éléments de promotion vendus par « Gator ». Par ailleurs, de tels logiciels ne sont pas compatibles avec des logiciels de navigation Internet sur téléphones mobiles. De plus, un logiciel doit être spécialement installé sur le terminal de l'utilisateur. Enfin, les opérations d'enregistrement doivent se faire service par service, c'est-à-dire un nouveau service pour chaque nouveau fournisseur de contenus auquel un utilisateur souhaite se connecter. Dans un autre état de la technique, qui sera développé plus loin, on a déjà pensé utiliser la solution au problème de la protection des données confidentielles des utilisateurs du fournisseur d'accès au réseau téléinformatique. Cependant, ainsi qu'on le décrira plus en détail à l'aide de la figure 1 , l'utilisateur doit encore correspondre avec un tiers fournisseur du logiciel pour établir une partie de la transaction, notamment la partie bancaire de la transaction quand elle met en œuvre un paiement par carte bancaire. La présente invention apporte un remède à ces inconvénients de l'état de la technique. Par ailleurs, dans de nombreuses occasions, les utilisateurs du réseau I nternet, qui utilisent les services d'un fournisseur d'accès au Réseau Internet, échangent des données confidentielles. De telles données pourraient être interceptés par des personnes qui pourraient surprendre le secret que les parties attendent d'un échange de données. Ce sera le cas d'un fichier contenant des données professionnelles comme des secrets de fabrication. Pour remédier à cet inconvénient, il existe aujourd'hui des produits logiciels que chacune des parties installe sur son ordinateur. Puis, la partie émettrice exécute un chiffrement des données qui sont alors transmises à la partie destinatrice pour y être déchiffrées. Un tel chiffrement garantit la confidentialité des données et l'intégrité des données. Cependant un tel chiffrement de garantit pas l'authenticité des données chiffrées. La présente invention apporte remède à cet autre inconvénient de l'état de la technique. En effet, elle concerne un procédé de transfert de données confidentielles entre au moins un terminal utilisateur et un équipement de communication appartenant à un fournisseur de contenus, le terminal ayant reçu des attributs de connexion à un réseau téléinformatique détenu par un fournisseur d'accès. Le procédé de l'invention consiste : - du côté du terminal utilisateur émetteur de données confidentielles, à émettre, via le réseau, une requête de service d'un contenu constituée selon un protocole prédéterminé à destination de l'équipement de communication du fournisseur de contenus ; - puis, du côté d'un équipement de communication appartenant au fournisseur d'accès : • à intercepter la requête de service en fonction de l'adresse de l'équipement de communication du fournisseur de contenus ; • à exécuter un service de chiffrement de données confidentielles relatives à l'utilisateur du terminal ; • à modifier la requête de service interceptée par insertion dans cette dernière des données confidentielles chiffrées ; • et à ré-acheminer la requête de service modifiée vers l'équipement de communication du fournisseur de contenus ; - puis, du côté de l'équipement de communication du fournisseur de contenus : • à recevoir la requête de service modifiée ; • à extraire les données confidentielles chiffrées en relation avec l'adresse du terminal utilisateur, • et à déchiffrer les données confidentielles chiffrées, au moyen d'une clé de déchiffrement compatible avec la clé de chiffrement. Selon un aspect de l'invention, le procédé comporte aussi une étape préparatoire qui consiste du côté de l'équipement de communication du fournisseur d'accès : - à constituer, lors d'une procédure d'inscription, un fichier comportant les données confidentielles associées à l'utilisateur du terminal en même temps que ses données de compte d'accès au réseau ; - à constituer, lors d'une procédure d'habilitation, un fichier de données d'habilitation du fournisseur de contenus, un tel fichier d'habilitation contenant au moins des données relatives à l'identification du fournisseur de contenus habilité. Selon un autre aspect de l'invention, le fichier d'habilitation contient en outre une clé de chiffrement qui est utilisée lors de l'étape de chiffrement de données confidentielles relatives à l'utilisateur du terminal par l'équipement de communication du fournisseur d'accès. La présente invention concerne également un équipement de communication appartenant à un fournisseur d'accès à un réseau téléinformatique qui propose un service de transfert de données confidentielles entre au moins un terminal utilisateur et un équipement de communication appartenant à un fournisseur de contenus. L'équipement de communication du fournisseur d'accès est remarquable en ce qu'il comprend : - un module d'interception pour intercepter, en fonction de l'adresse de l'équipement de communication du fournisseur de contenus, une requête de service d'un contenu constituée selon un protocole prédéterminé, une telle requête étant émise depuis le terminal utilisateur à destination de l'équipement de communication du fournisseur de contenus; - un module de chiffrement pour chiffrer des données confidentielles relatives à l'utilisateur du terminal ; - un module de modification de requête pour insérer les données confidentielles chiffrées dans la requête de service interceptée ; - et un module de ré-acheminement de la requête de service modifiée vers l'équipement de communication du fournisseur de contenus. Selon un aspect de l'invention, l'équipement de communication du fournisseur d'accès comprend en outre un module pour exécuter une étape préparatoire d'inscription d'utilisateurs et d'habilitation de fournisseurs de contenus. Selon un autre aspect de l'invention, le module d'exécution de l'étape préparatoire comprend : - un serveur Web auprès duquel d'une part, le terminal de l'utilisateur transmet des données confidentielles, et, d'autre part, l'équipement de communication du fournisseur de contenus transmet des données d'habilitation, - un premier sous-module de mémorisation dans lequel sont enregistrées les données confidentielles, - et un second sous-module de mémorisation dans lequel sont enregistrées les données d'habilitation. Selon encore un autre aspect de l'invention, lorsque la requête de service est du type HTTP, le module d'interception et le module de ré-acheminement sont contenus dans un dispositif proxy-cache, tandis que le module de chiffrement et le module de modification sont contenus dans un serveur implémentant une interface qui supporte un protocole de transfert de flux de données HTTP. La présente invention concerne également un équipement de communication appartenant à un fournisseur de contenus habilité préalablement auprès d'un fournisseur d'accès à un réseau téléinformatique qui propose un service de transfert de données confidentielles entre au moins un terminal utilisateur et cet équipement de communication. L'équipement de communication du fournisseur de contenus est remarquable en ce qu'il comprend : - un module de réception d'une requête de service d'un contenu émise par le terminal, une telle requête comprenant des données confidentielles chiffrées relatives à l'utilisateur du terminal ; - un module d'extraction des données confidentielles chiffrées en relation avec l'adresse du terminal de l'utilisateur, - et un module de déchiffrement des données confidentielles chiffrées au moyen d'une clé de déchiffrement compatible avec la clé de chiffrement. La présente invention concerne également un serveur implémentant une interface qui supporte un protocole de transfert de flux de données. Un tel serveur est remarquable en ce qu'il comprend : - un module de réception , en provenance d'un terminal, d'une requête de service d'un contenu constituée selon le protocole précité, - un module d'établissement d'une correspondance entre l'adresse allouée au terminal et au moins une donnée confidentielle relative à l'utilisateur du terminal, la donnée confidentielle étant enregistrée préalablement dans un sous-module de mémorisation, - un module de vérification de l'accord de l'utilisateur pour la transmission de données confidentielles relatives à ce dernier, les données confidentielles étant également enregistrées préalablement dans le sous-module de mémorisation, - un module d'exportation pour extraire, dans le cas où la vérification est positive, d'une part, les données confidentielles du sous-module de mémorisation, et d'autre part, une clé de chiffrement enregistrée préalablement dans un sous-module mémorisation appartenant à un fournisseur de contenus auquel est destinée la requête de service, - un module de chiffrement des données confidentielles au moyen de la clé de chiffrement extraite, - un module de modification de requête pour insérer les données confidentielles chiffrées dans un champ particulier de la requête de service, - et un module de retransmission de la requête de service modifiée en direction d'un équipement de communication appartenant au fournisseur de contenus. La présente invention concerne également un système de transfert de données confidentielles entre au moins un terminal utilisateur et un équipement de communication appartenant à un fournisseur de contenus, le terminal ayant reçu des attributs de connexion à un réseau téléinformatique détenu par un fournisseur d'accès. Un tel système est remarquable en ce que : - le terminal utilisateur émetteur de données confidentielles comprend un module d'émission, via le réseau précité, d'une requête de service d'un contenu constituée selon un protocole prédéterminé à destination de l'équipement de communication du fournisseur de contenus ; - l'équipement de communication du fournisseur de contenus est celui défini ci-dessus, et en ce qu'il comprend en outre : - un équipement de communication appartenant au fournisseur d'accès, tel que défini ci-dessus. D'autres caractéristiques et avantages de la présente invention seront mieux compris à l'aide de la description et dessins annexés parmi lesquels : la figure 1 représente une procédure de transaction de données confidentielles selon un état de la technique ; - la figure 2 est un ordinogramme représentant un mode particulier de réalisation du procédé de l'invention ; la figure 3 est un schéma bloc d'un système mettant en œuvre le procédé de l'invention ; les figures 4(a) et 4(b) sont des schémas de bases de données utilisées dans le procédé de l'invention ; la figure 5 est un schéma bloc d'un système mettant en œuvre un autre mode de réalisation du procédé de l'invention. À la figure 1 , on a représenté un exemple de réalisation de l'état de la technique qui a déjà été détaillée dans le préambule de la présente demande. Le terminal utilisateur 1 , qui peut être un ordinateur de bureau ou encore un téléphone mobile, est connecté au réseau téléinformatique par l'intermédiaire d'un fournisseur d'accès au réseau téléinformatique 2. Une telle connexion n'est possible que si l'utilisateur 1 est inscrit auprès du fournisseur d'accès 2. Lors de cette inscription, l'utilisateur indique un certain nombre de données confidentielles déterminées par le fournisseur d'accès 2. Un fournisseur de contenus 4 est connecté au réseau télé informatique 2. Lors de son inscription, le fournisseur de contenus 4 indique le type de données confidentielles que les utilisateurs qui se connectent à son site pourraient être conduits à échanger avec lui. Lors de cette inscription des fournisseurs de contenus, le fournisseur d'accès au réseau téléinformatique détermine les données confidentielles qu'il doit demander à ses utilisateurs lors de leur première inscription au réseau. Lorsque l'utilisateur 1 se connecte selon le chemin 5 au fournisseur de contenus 4, ce dernier lui présente, selon le chemin 10, des requêtes tendant à lui transmettre des données confidentielles détenues directement par le fournisseur d'accès 2. Une fois l'autorisation de transfert de données confidentielles accordées par l'utilisateur 1 , le fournisseur de contenus 4 transmet une requête 6 à un tiers de facturation 3. Le tiers de facturation 3 transmet alors au fournisseur d'accès au réseau 2 une requête de transfert de données confidentielles associées à la fois à l'utilisateur 1 et à son destinataire 4. En retour, après avoir vérifié les habilitations, le fournisseur d'accès au réseau 2 consulte les bases de données et extrait les données confidentielles relatives à l'utilisateur 1 . Il transmet selon une procédure cryptée 8 les données confidentielles demandées au tiers de facturation 3 qui émet alors un traitement de facturation au bénéfice du fournisseur de contenu numérique 4 au titre de l'utilisateur et qui transmet un acquittement de la transaction au fournisseur de contenus au moyen d'une connexion 9 de retour. Une fois l'acquittement de retour reçu du tiers de facturation 3, le fournisseur de contenus 4 informe son utilisateur 1 de l'exécution de la transaction constituée par le transfert des données confidentielles demandées. Il transmet alors cette information et/ou les informations demandées par le biais des données confidentielles par exemple quand elles sont achetées par l'utilisateur selon le chemin 10 à travers le fournisseur d'accès 2. A la figure 2, on a représenté un ordinogramme d'un mode de réalisation du procédé de l'invention. Après une étape S 1 de début, qui peut être initiée dès la détection d'un utilisateur et/ou d'un fournisseur de contenus, On entre dans une boucle B 1 au cours de laquelle, on exécute une étape S2 préparatoire. Dans un mode préféré de réalisation, selon le type de connexion, une étape S21 d'inscription d'un nouvel utilisateur est effectuée ou une étape S22 d'habilitation d'un nouveau fournisseur de contenus est effectuée. Si l'utilisateur ou le fournisseur de contenus ne sont pas identifiés comme inscrit ou habilité, on entre dans une phase d'inscription ou d'habilitation. La phase d'inscription permet de constituer un fichier de données confidentielles associées à un utilisateur en même temps que ses données de compte d'accès au réseau téléinformatique lors d'une procédure d'inscription tenue par le fournisseur d'accès au réseau téléinformatique comme le réseau Internet. De même, la phase d'habilitation vise à constituer un fichier de données d'habilitation d'au moins un fournisseur de contenus. Ce fournisseur de contenus détient par exemple un site Web et propose des services nécessitant la communication de données confidentielles d'un utilisateur. Préférentiellement, cet utilisateur est inscrit auprès du fournisseur d'accès au réseau Internet et les données confidentielles demandées par le fournisseur de contenus sont enregistrées dans le fichier de données confidentielles associées à cet utilisateur quand il requiert les services du fournisseur de contenus. Ces services peuvent être des services marchands, d'achat de documents multimédias par Internet, ou indirectement de produits ou de services par exemple vendus par un catalogue multimédia produit par le fournisseur de contenus. Mais, ces services peuvent aussi ne pas être des services marchands et par exemple consister en la transmission de données confidentielles produites par l'utilisateur pour que soit effectué un traitement spécial par le fournisseur de contenus. Dans un autre mode de réalisation du procédé de l'invention, les données confidentielles sont constituées par un fichier de données retourné par le fournisseur de contenus vers l'utilisateur. Particulièrement dans ce cas, les échanges de clés de procédures de chiffrement à deux clés sont exécutés lors de mises à jour des données personnelles des procédures d'inscription et/ou d'habilitation auprès du Fournisseur d'Accès Internet. Le fichier de données peut être directement associé dans une requête HTTP, par exemple sus une méthode dite « POST Method » ou encore sous une forme d'une adresse URL ou d'une référence indirecte à un fichier de données à chiffrer. Lors d'une procédure d'habilitation d'un nouveau fournisseur de contenus, le fichier d'habilitation est construit à l'aide d'une application détenue par le fournisseur d'accès Internet sur la base de données relatives à l'identification du fournisseur de contenus habilité et, le cas échéant, de données de configuration pour préparer une transaction avec au moins un utilisateur inscrit. Ainsi, lorsqu'un nouvel utilisateur s'inscrit dans une procédure d'inscription, ou lorsqu'un utilisateur déjà inscrit modifie son fichier d'inscription, le fournisseur d'accès dispose d'une application qui lui permet de demander les données confidentielles requises par le fichier d'habilitation de chaque fournisseur de contenus avec lequel l'utilisateur souhaite avoir un contact. Si l'un des partenaires, utilisateur ou fournisseur de contenus, n'est pas inscrit, le fournisseur d'accès dispose d'une application d'inscription ou d'une application d'habilitation pour le faire entrer dans le service de transfert de données confidentielles de l'invention. Si l'un ou l'autre des partenaires refuse, le service est interrompu (non représenté). Si les deux partenaires sont reconnus, respectivement comme utilisateur inscrit et comme fournisseur habilité, la phase préparatoire S2 est immédiatement terminée. On remarquera qu'on décrit ici une communication entre un seul utilisateur et un seul fournisseur de contenus. On comprendra que plus d'un utilisateur peuvent être connectés dans une phase préparatoire, ou une fédération de fournisseurs de contenus comme un portail Internet ou un anneau de fournisseurs de genre
« webring » peuvent se trouver en relation avec un utilisateur inscrit. A l'issue de la phase préparatoire S2, on initie une seconde boucle B2 et, lors d'un test de fin de boucle T1 qui termine la première boucle B1 , on vérifie que les deux partenaires sont correctement reconnus ainsi qu'on l'a décrit ci-dessus. Le procédé de l'invention comporte alors une étape d'exploitation S3 qui démarre lors d'une transaction entre un utilisateur inscrit chez le fournisseur d'accès et un fournisseur de contenus offrant le service requis par le dit utilisateur et habilité lors de l'étape préparatoire. La seconde boucle initiée en B2 est terminée par un test de fin de boucle T2 qui met fin au service de transfert de données confidentielles selon l'invention, lors d'une étape S4 de fin. Il est entendu que chaque boucle B1 ou B2 peut être initiée par la détection d'une requête d'ouverture de phase préparatoire (inscription ou habilitation) ou d'une requête d'exploitation (détection d'une requête de transaction demandant le transfert de données confidentielles) de manière asynchrone. Il est entendu que le processus de la figure 2 peut être exécuté en plusieurs réplications fonctionnant en parallèle avec un système de communications multi canal. L'invention s'applique donc à des transactions de types variés. Particulièrement, une transaction selon l'invention s'établit entre un utilisateur et un site de transfert du genre web, mais aussi d'autres genres, comme WAP. Une telle transaction comporte toujours au moins un chiffrement de données confidentielles exécuté en cœur de réseau, et donc un chiffrement qui n'est pas soumis ni à l'utilisateur, ni au site de transfert, ni à un tiers autre que le fournisseur d'accès au réseau téléinformatique, et un transfert des données confidentielles chiffrées. Une telle transaction peut porter directement sur le contenu numérique présenté par le fournisseur de contenus ou sur d'autres contenus non numériques ou des produits ou des services non informatiques comme ceux d'un service de Vente par Correspondance ou assimilé. Elle peut être marchande ou non , mettre en œuvre une transaction de type financier ou bancaire. Dans l'application de l'invention au paiement de biens sur
Internet, les données confidentielles comme un code « PI N » de carte bancaire sont fournies en clair par l'utilisateur, client du service de vente, et chiffrées en cœur de réseau selon le procédé de l'invention à chaque transaction. Cependant, pour simplifier l'intervention de l'utilisateur, on préférera stocker ces données et les retrouver de façon automatique ainsi qu'il sera décrit ci-après. A la figure 3, on a représenté un schéma bloc d'un système mettant en œuvre le procédé de l'invention. Ainsi qu'on l'a déjà exposé, le procédé de l'invention met en présence un fournisseur 40 d'accès à un réseau comme le réseau Internet, au moins un fournisseur 39 de contenus et au moins un utilisateur 38 dudit fournisseur 39 de contenus Chez le fournisseur d'Accès Internet 40 se trouvent : - Une Base de données 20 d'inscription d'utilisateur dans laquelle est maintenue chaque compte d'utilisateur inscrit auprès du Fournisseur d'Accès Internet 40 ; - Une Base de données 21 d'habilitation de fournisseurs de contenus dans laquelle est maintenu chaque compte d'habilitation pour les fournisseurs de contenus habilités par le Fournisseur d'Accès Internet 40. Le Fournisseur d'Accès Internet dispose d'une ou plusieurs ressources suivantes qui sont : - une ressource 23 d'inscription ou de modification de compte d'utilisateur auprès de la base de données 20 d'inscription d'utilisateur ; - une ressource 24 d'habilitation ou de modification de compte d'habilitation auprès de la base de données 21 d'habilitations ; - une ressource de chiffrement C ; - une ressource D de détournement de requête HTTP qui permet dans un canal HTTP 33 de prélever une requête 31 , 32 formulée sur le navigateur Internet de l'utilisateur pour la présenter à la ressource de chiffrement chez le Fournisseur d'Accès I nternet 40 ; - une ressource R de ré acheminement de la requête HTTP dans laquelle une partie 32 de données X en clair ou de référence est disponible pour permettre le chiffrement exécuté par la ressource C en fonction de données de chiffrement contenues dans la base de données 20 de comptes d'utilisateur et/ou dans la base de données 21 de comptes d'habilitation. Au niveau du navigateur installé chez l'utilisateur 38, la requête HTTP est composée de manière classique avec un mécanisme de production de données dans la requête HTTP 31 . Des données confidentielles peuvent être insérées ainsi qu'il sera décrit plus loin, à la volée par le Fournisseur d'accès Internet sans autre intervention de l'utilisateur inscrit. Au niveau de l'application Serveur installée chez le Fournisseur de Contenus 39 la partie chiffrée de données 35 dans la requête 34 telle que ré acheminée par la ressource de Ré acheminement R et la partie X Chiffrée 35 peut alors être déchiffrée par une ressource locale de déchiffrement et exploitée par une ressource locale d'utilisation des données X, notamment pour produire une réponse HTTP (non représentée) sur le canal HTTP 33. A la figure 4(a), on a représenté la structure d'un fichier d'inscription 41 qui comporte : - des données d'inscription 42 nécessaires à l'ouverture d'un compte de connexion au fournisseur d'accès Internet et bien connues par ailleurs ; des données confidentielles 43 qui peuvent être définies par l'utilisateur lui-même en fonction des différents fournisseurs de contenus auxquels il compte souscrire et d'après le type de données personnelles requises par chacun des fournisseurs de contenus habilités. A la figure 4(b), on a représenté la structure d'un fichier d'habilitation 45 d'un fournisseur de contenus habilité par le fournisseur d'accès I nternet et qui comporte : des données d'identification 46 du fournisseur de contenus habilité ; des données de génération d'objet 47 qui contiennent les arguments de génération d'objet permettant à l'application 25 (Figure 3) de générer l'objet accessible par l'utilisateur selon ce qui a déjà été décrit ; des données définissant l'adresse du site destinataire des données confidentielles du fichier d'inscription adressé lorsque l'utilisateur aura exécuté l'action attendue sur le dot objet accessible par l'utilisateur. D'autres données peuvent être ajoutées aux deux structures des figures 4(a) et 4(b) sans sortir de la portée de la présente invention. A la figure 5, on a représenté un système de communication Internet dans un mode particulier de réalisation du procédé de l'invention dans lequel on va préciser notamment les moyens de contrôle du fournisseur d'accès Internet FAI sur une transaction entre un fournisseur de contenus et un utilisateur au cours de laquelle des données confidentielles doivent être transmises. Le système de communication met en œuvre trois parties : l'utilisateur, client du fournisseur d'accès Internet, le fournisseur d'accès Internet FAI et au moins un site de fournisseur de contenus. Les divers moyens nécessaires sont respectivement :
Du côté de l'utilisateur : un terminal 50 doté d'une connexion téléinformatique au fournisseur d'accès FAI , d'un moyen pour produire et recevoir des requêtes de type HTTP, comme un navigateur et de moyens pour traiter des contenus numériques provenant de fournisseurs de contenus via le réseau du fournisseur d'accès Internet ;
Du côté des fournisseurs de contenus : des ressources 52 pour produire des contenus numériques, des ressources pour produire et recevoir des requêtes HTTP avec des utilisateurs connectés au réseau Internet par le fournisseur d'accès Internet FAI ;
Du côté du fournisseur d'accès Internet FAI : un serveur Web 53 pour exécuter l'étape préparatoire d'inscription d'utilisateurs et d'habilitation de fournisseurs de contenus, un dispositif « proxy-cache » implémentant un client iCAP 51 , un serveur iCAP implémentant un service iCAP 55, une base de données 54 des utilisateurs du FAI ayant souscrit au service de transfert sécurisé de données confidentielles de l'invention, une base de données 56 des données d'habilitation des fournisseurs de contenus, partenaires du fournisseur d'accès Internet FAI et qui demandent à bénéficier des données confidentielles des utilisateurs inscrits dans la base de données 55. Notamment pour les techniques des proxy-caches et du protocole iCAP implémentées au niveau du fournisseur d'accès Internet FAI on pourra se reporter au contenu de la demande de brevet FR 2 823 044 du 30 mars 2001 au nom de France Telecom. Le moyen pour produire et recevoir des requêtes de type
HTTP, comme un navigateur est dans d'autres versions capable de produire et recevoir des requêtes sur ledit réseau de divers types autre que le protocole HTTP. Particulièrement, l'invention est applicable au protocole WAP (Wireless Application Protocol) pour que les Terminaux Mobiles puissent accéder à Internet et leur permettre de consulter les courriers électroniques et divers sites ou services Web. L'invention est aussi applicable au protocole FTP qui permet à un utilisateur d'accéder à un serveur de fichiers, au protocole SMTP de transfert de courrier électronique, au protocole RTCP (Real Time Transfer Protocol). Ce dernier protocole est basé sur des transmissions périodiques de paquets de contrôle par tous les participants dans une session en contrôle des flux d'un autre protocole dit protocole RTP, permettant de véhiculer des informations de base sur les participants d'une session, et sur la qualité de service notamment lors de communications entre plusieurs utilisateurs et/ou fournisseurs de contenus, ces derniers acteurs étant considérés selon le point de vue de la présente invention. On va maintenant décrire les flux de données échangés dans le système de la figure 5 sur la base du procédé de l'invention. Lors de la phase préparatoire, l'utilisateur 50 renseigne les données confidentielles sur un serveur Web 53 par une connexion sécurisée de type « HTTPs » ou non sécurisée. Cette connexion peut avoir lieu lors de la première connexion au Fournisseur FAI pour l'inscription de l'utilisateur, ou ultérieurement lors d'une procédure de mise à jour. Les données confidentielles sont alors hébergées par une écriture 62, ou une mise à jour le cas échéant, au niveau de la base de données 54 des utilisateurs du fournisseur FAI . La même procédure (non représentée) est suivie pour les données d'habilitation de la base de données 56 des fournisseurs de contenus partenaires du fournisseur d'accès Internet FAI . Parmi les données d'habilitation , on trouve cependant une clef publique de chiffrement à mettre en œuvre par le fournisseur FAI dans une procédure de chiffrement à clés publiques lorsqu'il transmettra les données confidentielles requises d'un utilisateur, le fournisseur de contenus habilité et partenaire du fournisseur FAI maintenant secrète la clé privée permettant le déchiffrement. Lors de l'étape d'exploitation, le fournisseur de contenus au site Web duquel l'utilisateur s'est connecté à travers le proxy-cache du fournisseur FAI a transmis une page Web dans laquelle se trouve une proposition de transaction avec transmission de données confidentielles détenues par le fournisseur FAI pour le compte de l'utilisateur. Par activation de la proposition, l'utilisateur transfère alors sur le réseau une requête 63 pour effectuer une transaction comme une commande en ligne. Le proxy-cache 51 , installé chez le fournisseur FAI , comporte un moyen pour intercepter les requêtes d'achat en ligne ou toute autre requête HTTP issue du navigateur d'un utilisateur inscrit auprès du Fournisseur d'accès Internet. L'interception 64 a lieu au moyen de l'analyse de listes, dites « ACLs » , qui font partie des fonctionnalités de gestion de flux d'un proxy-cache. Ayant détecté dans les « ACLs » la présence d'une requête d'achat en ligne, le proxy-cache route cette requête vers un serveur implémentant une interface supportant un protocole de transfert de flux HTTP tel qu'un serveur iCAP implémentant le service iCAP de transfert de données confidentielles défini dans le procédé de l'invention. La requête parvenant au serveur iCAP 55 est de la forme suivante commentée dans le Tableau 1 : Tableau 1 :
// En- -tête de requête définie selon iCAP
REQMOD icap://xxx.xxx.xx .xxxxx/wwreqm od ?Profile= =Filt1 ICAP/1 .0
Host : xxx. xxx. xxx. xxx Encapsulated :req-hdr=0, null-body=394 X-Client-IP:yyy.yyy.yyy.yyy
//En-tête de requête définie selon HTTP GET HTTP://www.site.domaine/?HTTP/1 .1 Host: www. site. domaine
Accept:image/gif
Référer: HTTP://www.site.domaine/
Accept-Language: xx //code langue
Accept-Encoding :gzip, deflate User-Agent: Mozilla/4.0(compatible; liste) X-Forwarded-For : yyy.yyy.yyy.yyy dans laquelle requête : xxx. xxx. xxx. xxx est l'adresse Internet IP du service iCAP 55 ; - yyy.yyy.yyy.yyy est l'adresse Internet url de l'utilisateur détecté et HTTP://www.site.domaine/ est l'adresse du site Web détecté du fournisseur de contenus ; les autres champs de la requête de la forme du tableau 1 permettent de déterminer les ressources disponibles pour la génération de l'objet accessible par l'utilisateur. Le serveur iCAP 55 qui reçoit la requête du tableau 1 implémente un service iCAP mettant en œuvre la partie de traitement de l'étape d'exploitation du procédé de l'invention selon les enseignements présentés notamment dans la demande de brevet français FR 2 823 044 déposée au nom de France Telecom à laquelle on se reportera pour les détails de réalisation. Le service iCAP exécute alors une étape 66 pour établir la correspondance entre l'adresse IP Internet du champ X-Client-I P allouée à l'utilisateur pour la session en cours et qui se trouve dans l'en-tête de requête HTTP et un identifiant de l'utilisateur contenu dans sa base de données des utilisateurs inscrits 54. Le service iCAP exécute ensuite une étape pour vérifier l'accord de l'utilisateur pour la transmission de ses données confidentielles au site partenaire lors d'une étape 67. Si cet accord est détecté par analyse des données inscrites en relation avec l'utilisateur connecté dans la base de données 54, le serveur iCAP 55 exporte 68 ces données confidentielles nécessaires pour l'achat en ligne de la base de données des utilisateurs 54 vers le serveur iCAP 55. Le service iCAP exécute ensuite une étape d'interrogation de la base de données des fournisseurs habilités (partenaires) 56 pour connaître la clé publique du fournisseur déclaré et, le cas échéant si cette donnée est manquante, pour déterminer l'adresse du site de destination des données confidentielles, ici définie dans la requête dans le champ adresse I P destination des données confidentielles (champ Host - Tableau 1 ) dans le flux 69. Les étapes d'échange des flux 68 et 69 peuvent être réalisées simultanément pour accélérer le service. Dans un autre mode de réalisation, l'étape d'échange du flux 69 est exécutée d'abord puis seulement après celles des flux 66 et 67. En effet, dans le cas où un partenaire aurait besoin d'informations sur l'utilisateur qui soit différentes de celles des autres partenaires, on peut avoir besoin de consulter la base d'habilitation en premier pour savoir quels paramètres chercher dans la base des utilisateurs. Le serveur iCAP 55 exécute alors une étape de chiffrement avec la clé publique adéquate provenant du flux 70 et les insère dans un champ particulier, qui pourrait être normalisé et qui est intitulé « Encrypted-Data » , interne à la requête HTTP qui renvoie la bonne clé publique. Le serveur iCAP 55 exécute ensuite une étape de retransmission de la requête modifiée dans le flux 72 vers le proxy- cache 51 . La requête modifiée devient alors selon le Tableau 2 : Tableau 2 :
// En-tête de requête définie selon iCAP
REQMOD icap://xxx.xxx.xx.xxxxx/wwreqmod ?Profile=Filt1 ICAP/1 .0 Host : xxx.xxx.xx.xxxxx
Encapsulated :req-hdr=0, null-body=394
X-Client-IP:yy.yyy.yyy.yyy
//En-tête de requête définie selon HTTP GET HTTP://www.site.domaine/?HTTP/1 .1 Host: www. site. domaine
Accept:image/gif
Référer: HTTP://www.site.domaine/
Accept-Language: xx //code langue
Accept-Encoding :gzip, deflate
User-Agent: Mozilla/4.0(compatible; liste)
X-Forwarded-For : yy.yyy.yyy.yyy
VIA: 1 .0 c-icache(NetCache NetApp/5.2.1 R1 D9)
Encrypted-Data: zzzzzzzzzzzzzzzz dans laquelle requête on a ajouté les deux dernières lignes à la Requête initiale qui sont : la ligne « VIA » définissant la ressource iCAP du proxy-cache chargée de la transmission de la requête modifiée vers le site du fournisseu r habilité partenaire destinataire des données encodées ; la ligne « Encrypted-Data » contenant le flot de données encryptées. Le proxy-cache exécute alors une étape de transmission 73 vers le site de l'hébergeur concerné par l'achat en ligne. Le chiffrement des données utilisateurs se fait sur le serveur ICAP 55 et l'insertion de ces données chiffrées est réalisée dans un champ de la requête reçue dans le flux 65 par le serveur ICAP et retransmise par le flux 72. Le fournisseur de contenus 62 hébergeant le site d'achat en ligne extrait de l'en-tête HTTP (ligne « Encrypted-Data ») lors d'une étape 74 qu'il décrypte à l'aide de sa propre clé privée et traite l'achat en ligne de l'utilisateur, son propre client. Le fournisseur de contenus 62 exécute alors : si les données confidentielles transmises sont des données bancaires (carte bleue, numéro de compte de prélèvement), une étape de facturation de l'utilisateur est effectuée par le fournisseur de contenus ; si les données confidentielles transmises sont des données d'identification d'un client du fournisseur de contenus, une étape de facturation du client est effectuée et transmise avec cet identifiant au fournisseur d'accès FAI qui peut alors exécuter la refacturation de son propre client utilisateur 50. Une étape 76 de réponse contenant la confirmation de la transaction au proxy-cache 51 est alors effectuée. Puis, le proxy-cache 51 exécute une étape d'acheminement 77 de la confirmation de transaction vers l'utilisateur 50. On remarque ainsi les avantages essentiels de l'invention.
Tout d'abord, les opérations d'identification lors des procédures d'achat sont transparentes pour l'utilisateur, client du fournisseur de contenus. Ensuite, le fournisseur d'accès Internet FAI peut offrir un service de masquage de l'identité de ses utilisateurs en leur attribuant un identifiant unique et chiffré rattachable à ce seul client. I l en résulte dans ce cas :
1 . L'identité réelle du client est masquée au fournisseur de contenus ce qui préserve l'anonymat du client lors d'achat ; une telle caractéristique permet notamment de réduire la diffusion involontaire du nom des utilisateurs dans des fichiers commerciaux qui en retour produisent des envois de sollicitations commerciales non désirées (spamming notamment) ;
2. Les coordonnées bancaires de l'utilisateur inscrit ne transitent plus sur le réseau ce qui renforce la sécurité des données confidentielles ; 3. Le fournisseur d'accès Internet FAI sert alors de tiers de facturation et peut mettre en place un modèle économique de rémunération sur les échanges commerciaux. Enfin, l'invention apporte l'assurance à tout fournisseur de contenus habilité par le fournisseur d'accès Internet FAI de la véracité de l'identité de son utilisateur puisque ce dernier est authentifié par son accès.

Claims

REVENDICATIONS
1 . Procédé de transfert de données confidentielles entre au moins un terminal utilisateur (38;50) et un équipement de communication (39) appartenant à un fournisseur de contenus, ledit terminal (38;50) ayant reçu des attributs de connexion à un réseau téléinformatique détenu par un fournisseur d'accès, caractérisé en ce qu'il consiste : - du côté du terminal utilisateur (38;50) émetteur de données confidentielles, à émettre, via ledit réseau, une requête de service d'un contenu constituée selon un protocole prédéterminé à destination de l'équipement de communication (39) du fournisseur de contenus ; - puis, du côté d'un équipement de communication (40) appartenant au fournisseur d'accès : • à intercepter la requête de service en fonction de l'adresse de l'équipement de communication (39) du fournisseur de contenus ; • à exécuter un service de chiffrement de données confidentielles relatives à l'utilisateur dudit terminal (38;50) ; • à modifier ladite requête de service interceptée par insertion dans cette dernière desdites données confidentielles chiffrées ; • et à ré-acheminer ladite requête de service modifiée vers l'équipement de communication (39) du fournisseur de contenus ; - puis, du côté de l'équipement de communication (39) du fournisseur de contenus : • à recevoir ladite requête de service modifiée ; • à extraire les données confidentielles chiffrées en relation avec l'adresse du terminal utilisateur (38;50), • et à déchiffrer lesdites données confidentielles chiffrées au moyen d'une clé de déchiffrement compatible avec ladite clé de chiffrement.
2. Procédé selon la revendication 1 , caractérisé en ce qu'il comporte aussi une étape préparatoire (B 1 , S2) qui consiste du côté de l'équipement de communication (40) dudit fournisseur d'accès : - à constituer, lors d'une procédure d'inscription, un fichier (20) comportant lesdites données confidentielles associées à l'utilisateur du terminal (38;50) en même temps que ses données de compte d'accès au réseau ; - à constituer, lors d'une procédure d'habilitation, un fichier (21 ) de données d'habilitation dudit fournisseur de contenus, ledit fichier d'habilitation contenant au moins des données relatives à l'identification du fournisseur de contenus habilité.
3. Procédé selon la revendication 2, caractérisé en ce que le fichier d'habilitation contient en outre une clé de chiffrement qui est utilisée lors de ladite étape de chiffrement de données confidentielles relatives à l'utilisateur dudit terminal (38;50) par l'équipement de communication (40) du fournisseur d'accès.
4. Equipement de communication appartenant à un fournisseur d'accès à un réseau téléinformatique qui propose un service de transfert de données confidentielles entre au moins un terminal utilisateur (38;50) et un équipement de communication (39) appartenant à un fournisseur de contenus, ledit équipement de communication du fournisseur d'accès étant caractérisé en ce qu'il comprend : des moyens d'interception (D; 51 ) pour intercepter, en fonction de l'adresse de l'équipement de communication (39) du fournisseur de contenus, une requête de service d'un contenu constituée selon un protocole prédéterminé, ladite requête étant émise depuis ledit terminal utilisateur (38;50) à destination de l'équipement de communication (39) du fournisseur de contenus; - des moyens de chiffrement (C; 55) pour chiffrer des données confidentielles relatives à l'utilisateur dudit terminal (38;50) ; - des moyens (55) de modification de requête pour insérer lesdites données confidentielles chiffrées dans ladite requête de service interceptée ; - et des moyens de ré-acheminement (R;51 ) de ladite requête de service modifiée vers l'équipement de communication (39) du fournisseur de contenus.
5. Equipement de communication selon la revendication
4, comprenant en outre des moyens pour exécuter une étape préparatoire d'inscription d'utilisateurs et d'habilitation de fournisseurs de contenus.
6. Equipement de communication selon la revendication
5, dans lequel lesdits moyens d'exécution de ladite étape préparatoire comprennent : - un serveur Web (23, 24; 53) auprès duquel d'une part, le terminal (38;50) de l'utilisateur transmet des données confidentielles, et, d'autre part, l'équipement de communication (39) du fournisseur de contenus transmet des données d'habilitation, - des premiers moyens de mémorisation (20; 54) dans lesquels sont enregistrées lesdites données confidentielles, - et des seconds moyens de mémorisation (21 ; 56) dans lesquels sont enregistrées lesdites données d'habilitation.
7. Equipement de communication selon la revendication 4 ou 5, dans lequel, lorsque ladite requête de service est du type HTTP, lesdits moyens d'interception et lesdits moyens de ré- acheminement sont contenus dans un dispositif proxy-cache (51 ), tandis que lesdits moyens de chiffrement et lesdits moyens de modification sont contenus dans u n serveur (55) implémentant une interface qui supporte un protocole de transfert de flux de données HTTP.
8. Equipement de communication appartenant à un fournisseur de contenus habilité préalablement auprès d'un fournisseur d'accès à un réseau téléinformatique qui propose un service de transfert de données confidentielles entre au moins un terminal utilisateur (38;50) et ledit équipement de communication, ce dernier étant caractérisé en ce qu'il comprend : - des moyens de réception d'une requête de service d'un contenu émise par ledit terminal (38; 50), ladite requête comprenant des données confidentielles chiffrées relatives à l'utilisateur du terminal ; - des moyens d'extraction desdites données confidentielles chiffrées en relation avec l'adresse du terminal (38;50) de l'utilisateur, - et des moyens de déchiffrement desdites données confidentielles chiffrées au moyen d'une clé de déchiffrement compatible avec ladite clé de chiffrement.
9. Serveur implémentant une interface qui supporte un protocole de transfert de flux de données, ledit serveur étant caractérisé en ce qu'il comprend : - des moyens de réception, en provenance d'un terminal (38;50), d'une requête de service d'un contenu constituée selon ledit protocole, - des moyens d'établissement d'une correspondance entre l'adresse allouée audit terminal (38;50) et au moins une donnée confidentielle relative à l'utilisateur dudit terminal, ladite donnée confidentielle étant enregistrée préalablement dans des moyens de mémorisation (54), - des moyens de vérification de l'accord dudit utilisateur pour la transmission de données confidentielles relatives à ce dernier, lesdites données confidentielles étant également enregistrées préalablement dans lesdits moyens de mémorisation (54), - des moyens d'exportation pour extraire, dans le cas où la vérification est positive, d'une part, lesdites données confidentielles des moyens de mémorisation (54), et d'autre part, une clé de chiffrement enregistrée préalablement dans des moyens de mémorisation (56) et appartenant à un fournisseur de contenus auquel est destinée ladite requête de service, - des moyens de chiffrement desdites données confidentielles au moyen de ladite clé de chiffrement extraite, - des moyens de modification de requête pour insérer lesdites données confidentielles chiffrées dans un champ particulier de ladite requête de service, - et des moyens de retransmission de ladite requête de service modifiée en direction d'un équipement de communication (39) appartenant au fournisseur de contenus.
10. Système de transfert de données confidentielles entre au moins un terminal utilisateur (38;50) et un équipement de communication (39) appartenant à un fournisseur de contenus, ledit terminal (38;50) ayant reçu des attributs de connexion à un réseau téléinformatique détenu par un fournisseur d'accès, ledit système étant caractérisé en ce que : - le terminal utilisateur (38;50) émetteur de données confidentielles comprend des moyens d'émission, via ledit réseau , d'une requête de service d'un contenu constituée selon un protocole prédéterminé à destination de l'équipement de communication (39) du fournisseur de contenus ; - ledit équipement de communication (39) est défini selon la revendication 8, et en ce que ledit système comprend en outre : - un équipement de communication (40) appartenant au fournisseur d'accès, tel que défini selon l'une quelconque des revendications 4 à 7.
EP04805271A 2003-11-06 2004-10-21 Procede de transfert de donnees confidentielles en coeur de reseaux Withdrawn EP1680905A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0313053A FR2862170A1 (fr) 2003-11-06 2003-11-06 Procede de transfert de donnees confidentielles en coeur de reseaux
PCT/FR2004/002707 WO2005048558A1 (fr) 2003-11-06 2004-10-21 Procede de transfert de donnees confidentielles en coeur de reseaux

Publications (1)

Publication Number Publication Date
EP1680905A1 true EP1680905A1 (fr) 2006-07-19

Family

ID=34508304

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04805271A Withdrawn EP1680905A1 (fr) 2003-11-06 2004-10-21 Procede de transfert de donnees confidentielles en coeur de reseaux

Country Status (3)

Country Link
EP (1) EP1680905A1 (fr)
FR (1) FR2862170A1 (fr)
WO (1) WO2005048558A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11488202B2 (en) * 2014-02-28 2022-11-01 Ncr Corporation Unified channel management

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2350982B (en) * 1999-06-10 2003-06-25 John Quentin Phillipps Electronic commerce system
US20030191801A1 (en) * 2002-03-19 2003-10-09 Sanjoy Paul Method and apparatus for enabling services in a cache-based network

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
FR2862170A1 (fr) 2005-05-13
WO2005048558A1 (fr) 2005-05-26

Similar Documents

Publication Publication Date Title
JP4152051B2 (ja) インターネット・ブラウジング・セッション中に有料の電話コールを行うための方法及びシステム
US8661557B2 (en) Method and system for granting access to system and content
EP1909462B1 (fr) Procédé de mise à disposition cloisonnée d'un service électronique
EP1256911A1 (fr) Procédé de sécurisation d'un paiement d'un client à un commerçant, centre de localisation et système correspondants
EP1829280A2 (fr) PROCEDE D'AUTHENTIFICATION SECURISEE POUR LA MISE EN ŒUVRE DE SERVICES SUR UN RESEAU DE TRANSMISSION DE DONNEES
EP3391614A1 (fr) Procede de transmission d'une information numerique
WO2005034468A1 (fr) Systeme d'acces a un reseau adapte pour la mise en oeuvre d'un procede a signature simplifiee, et serveur pour sa realisation
EP1227640B1 (fr) Procédé et système de communication d'un certificat entre un module de sécurisation et un serveur
EP1983722A2 (fr) Procédé et système de sécurisation d'accès internet de téléphone mobile, téléphone mobile et terminal correspondants
WO2001001280A2 (fr) Procede et dispositif de mise en commun d'informations temoins pendant des operations sur internet
EP1680905A1 (fr) Procede de transfert de donnees confidentielles en coeur de reseaux
EP1400090B1 (fr) Procede et dispositif de securisation des communications dans un reseau informatique
CN101658004A (zh) 用于提供rel令牌的方法和系统
Sim et al. The Internet—past, present and future
FR2844943A1 (fr) Procede de production d'un premier identifiant isolant un utilisateur se connectant a un reseau telematique
EP1535253A1 (fr) Procede et systeme de securisation de transmission d'informations sur des reseaux de telecommunication
EP2630765B1 (fr) Procede d'optimisation du transfert de flux de donnees securises via un reseau autonomique
FR2844942A1 (fr) Procede de production, pour un fournisseur d'acces, d'un identifiant isolant multimedia
KR101507958B1 (ko) 모바일 메신저를 구동하는 모바일 웹페이지 제공 방법
EP0803087B1 (fr) Procede de realisation de transfert securise de donnees sur un reseau a serveurs multiples
Sim et al. The Internet—past, present and future
EP2254275A1 (fr) Procédé de chiffrement de parties particulières d'un document pour les utilisateurs privilèges
JP2001290773A (ja) ネットワーク型サービス提供システム
KR20020066853A (ko) 통신망을 통한 아이템 전달 방법
De Bruin Validity and Accuracy Issues in Electronic Commerce with Specific Reference to Vpn's

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: 20060505

AK Designated contracting states

Kind code of ref document: A1

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

RIN1 Information on inventor provided before grant (corrected)

Inventor name: BOUTROUX, VINCENT

Inventor name: BOUTROUX, ANNE

Inventor name: MITTIG, KAREL

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

Effective date: 20070209

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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: 20090605