[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

EP1208684B1 - Procede de transmission de flux de donnees a haut debit sur un reseau de type internet entre un serveur et un terminal a carte a puce - Google Patents

Procede de transmission de flux de donnees a haut debit sur un reseau de type internet entre un serveur et un terminal a carte a puce Download PDF

Info

Publication number
EP1208684B1
EP1208684B1 EP01907760A EP01907760A EP1208684B1 EP 1208684 B1 EP1208684 B1 EP 1208684B1 EP 01907760 A EP01907760 A EP 01907760A EP 01907760 A EP01907760 A EP 01907760A EP 1208684 B1 EP1208684 B1 EP 1208684B1
Authority
EP
European Patent Office
Prior art keywords
data
type
agent
intelligent
session
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.)
Expired - Lifetime
Application number
EP01907760A
Other languages
German (de)
English (en)
Other versions
EP1208684A2 (fr
Inventor
Pascal Urien
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.)
CP8 Technologies SA
Original Assignee
CP8 Technologies 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 CP8 Technologies SA filed Critical CP8 Technologies SA
Publication of EP1208684A2 publication Critical patent/EP1208684A2/fr
Application granted granted Critical
Publication of EP1208684B1 publication Critical patent/EP1208684B1/fr
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

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
    • H04L63/0442—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 wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • 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/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • 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/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/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • 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/40—Network security protocols
    • 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/12—Protocol engines
    • 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

Definitions

  • the invention relates to a method for transmitting high-speed data streams over an Internet-type network between a server and a smart card terminal.
  • the invention applies more particularly to a secure multimedia data stream.
  • the term “broadband” relates to data streams whose bit rate is typically of the order of 100 kbits per second or more.
  • an audio file of data encoded in "MP3” requires a memory space of 1 MB for one minute of recording, or about 100 kbits / sec., When this file is transmitted by a digital channel for broadcast in real time.
  • video data streams that require a transmission speed of the order of 2 Mbits / sec to be displayed in real time. It is, a fortiori, also the case of so-called multimedia data streams that can convey both images, video and / or sounds.
  • the term "smart card terminal” must be understood in a general sense. It may in particular be constituted by a personal computer operating under various operating systems, such WINDOWS or UNIX (both being registered trademarks). It can also be constituted by a workstation, or a laptop.
  • Internet network encompasses, in addition to the Internet network itself, private networks of companies or the like, of the "intranet” type, and networks extending them to the Internet. outside, of the type called “extranet”, and in general any network in which the data exchange is carried out according to a protocol of the Internet type.
  • “Secure” means that the data in question is encrypted, in whole or in part, to ensure confidentiality, or at least not freely accessible. It may be, in the latter case, paid access data. In all cases, it is generally necessary to provide identification data (password, username or "login”, credit card number, etc.) that allows a transaction to obtain the data. desired (multimedia file for example). These data are said to be “sensitive” and can not be transmitted in “clear” on the Internet. They must therefore be secured: encryption or use of a secure protocol, for example of the "SSL” type (for Secure Socket Layer ").
  • the latter can be assigned various functions, including security functions. It is indeed advantageous to store the data related to security (passwords, access rights, etc.) in a smart card that can be retained by the user.
  • the data being stored in a fixed memory, in a form that can be encrypted, they are not easily modifiable, or even directly readable from the outside.
  • the "security function" can not be carried out directly inside the smart card, because the data stream, received and / or transmitted, does not cross it. . It must therefore establish a dialogue between the terminal and the smart card so that security-related checks can be made. This procedure degrades the level of security, or even allows the introduction of "Trojan horses” in the terminal, under certain adverse conditions. It would therefore be necessary for the security checks to be carried out in situ, that is to say in the smart card itself, which would require that the data flow be diverted by the smart card, before to be transmitted to the terminal.
  • the smart card could directly control certain operations that take place in the terminal and could, for example, modify predetermined characteristics of data received and / or transmitted. by the terminal.
  • FIG 1A schematically illustrates an example of architecture of this type.
  • the terminal for example a personal computer, comprises a smart card reader 2.
  • This reader 3 may or may not be physically integrated in the terminal 1.
  • the smart card 2 comprises an integrated circuit 20 including input connections the outlets are flush with the surface of its support to allow an electrical power supply and communications with the terminal 1.
  • the latter comprises access circuits 11 to the Internet network RI.
  • These circuits may be constituted by a modem for connect to a switched telephone line or, in the case of the invention, preferably to a higher speed communication channel: Integrated Services Digital Network ("ISDN”), cable or satellite links.
  • ISDN Integrated Services Digital Network
  • the circuits 11 make it possible to connect to the Internet network RI, directly or via an Internet service provider ("Internet Service Provider" or "ISP", according to the English terminology).
  • ISP Internet Service Provider
  • the terminal 1 naturally includes all the circuits and organs necessary for its proper functioning, and which have not been represented for purposes of simplification of the drawing: central unit, random and fixed memories, mass memory with magnetic disk, floppy disk drive and / or CedeRom, etc.
  • the terminal 1 is also connected to conventional peripherals, integrated or not, such a display screen 5 a and a sound reproduction system 5b (for the distribution of media files as part of the invention), a keyboard 6a and a mouse 6b, etc.
  • peripherals integrated or not, such a display screen 5 a and a sound reproduction system 5b (for the distribution of media files as part of the invention), a keyboard 6a and a mouse 6b, etc.
  • the terminal 1 can be connected to servers or all computer systems connected to the IN network , of which only one, 4, is illustrated in FIG. 1A.
  • the access circuits 11 put the terminal 1 in communication with the servers 4 through a particular software 10, called browser "WEB”, or “browser” according to the English terminology. This allows access to various applications or data files distributed over the entire network RI, generally in a "client-server” mode, including multimedia files.
  • network communications are performed according to standards-compliant protocols that include multiple overlapping software layers.
  • the communications are carried out according to protocols specific to this type of communication, which will be detailed below, but which also comprise several software layers.
  • the protocol of communication is chosen according to the more specifically targeted application: interrogation of "WEB" pages, file transfers, electronic mail (e-mail, or “e-mail” according to the English terminology), forums or "news” etc.
  • FIG. 1B on the terminal side 1, only the layers corresponding to the ISO 7816-3 standard, referenced 101, and an "APDU" command manager (ISO 7816-4 standard), referenced 102, have been represented.
  • the layers corresponding to the ISO 7816-3 standard are referenced 201 and the "ADPU" command manager (ISO 7816-4 standard) is referenced 210.
  • the applications are referenced A 1 , ... , A i , ..., A n , where n is the maximum number of applications present on the smart card 2.
  • An application “cardlet” (registered trademark), A i , present in the smart card 2 ( Figure 1A), dialogue with the terminal 1 by means of a set of orders.
  • This game typically features write commands and read commands.
  • the format of the orders is known by the abbreviation "APDU” (for "Application Protocol Data Unit”). It is defined by the aforementioned ISO 7816-4 standard.
  • An “APDU” command is denoted “ APDU.command " and an “APDU” response is noted “ APDU.response ".
  • the terminal 1 When the smart card 2 includes several separate applications, as illustrated in FIG. 1B, it is called a multi-application card. However, the terminal 1 only dialogs with one application at a time.
  • An application A i is, for example, in the form of a piece of software, called “applet”, language “JAVA” (registered trademark), which will be called hereinafter "cardlet”.
  • the selection of a particular "cardlet” A i is obtained using an "APDU” of the selection type ("SELECT"). Once this choice is made, the "APDU” that follow it are routed to this "cardlet”.
  • a new "APDU SELECT" has the effect of abandoning the current application and choosing another one.
  • the software manager subset of the "APDU” 210 makes it possible to choose a particular application A i in the smart card 2, to memorize the application thus chosen, and to transmit and / or receive "APDU” to and from this application .
  • the smart card 2 can not communicate directly with the standard browsers of the trade, except to modify the code of the latter.
  • the aforementioned standards organize communications between smart card and terminal, via the reader, of serial type.
  • the throughput of current technology is very low, in the order of 1 to 10 kbits / sec, which, once again, is incompatible with the speeds envisaged (100 Kbits / sec. ) in the context of the applications of the invention.
  • the invention aims to overcome the disadvantages of the methods and devices of the known art, some of which have just been recalled, while meeting the needs that are felt, that is to say, in particular to accommodate high-speed data flows, while enjoying maximum security.
  • the smart card behaves as a "web" type of senor / client for the terminal associated with it.
  • a specific communication software layer is provided in the smart card and its counterpart in the terminal.
  • the term "specific” should be understood as specific to the process of the invention. Indeed, these communication layers, called specific, are trivialized regardless of the application considered. They intervene only in the bidirectional data exchange process between the smart card and the terminal, on the one hand, and the smart card and the network, on the other hand.
  • the specific communication software layers include software components, called “intelligent agents", allowing in particular protocol conversions.
  • the intelligent agents will be called hereafter simply “agents”.
  • agents There are matched agents in the respective specific communication layers associated with the terminal and the smart card. According to the method of the invention, sessions are established between paired agents.
  • filter there is implemented in the smart card a particular application, which will be called “filter” in what follows. It is a software entity that plays a role similar to that of a “proxy”. To do this, we use the aforementioned provisions implementing agents. This "proxy” makes it possible to carry out data processing related to security directly within the smart card.
  • an asymmetrical communication protocol is implemented.
  • the transmission or reception data stream is subdivided into two components: a first low bit rate stream and a small amount of data, which will be referred to hereinafter as “critical data stream”, which passes directly through the card to chip, and a flow of high volume and representing a large volume of data, which will be called hereinafter “opaque data stream”, which passes through the terminal.
  • the flow of critical data is constituted by security data that can be addressed to the aforementioned "proxy" of the smart card, to be treated secretly.
  • Opaque data consists of actual multimedia data. These data are processed by agents located in the terminal. However, the authorization to receive opaque data and to process them is subordinated to the result of an authentication procedure initiated by the security data in the smart card. Due to the presence of the aforementioned filter, the reception of the data by the terminal remains under the direct control of the smart card.
  • the opaque data transiting through the terminal may also undergo particular processing within this terminal before actual use, under the control and control of the smart card, that is to say ultimately critical data that it has received.
  • the architecture of communication networks is described by various layers.
  • OSI Open System Interconnection
  • ISO Open System Interconnection
  • a given layer offers its services to the layer that is immediately superior to it and requires the layer that immediately infers it from other services, via appropriate interfaces.
  • the layers communicate using primitives. They can also communicate with layers of the same level. In some architectures, several layers may not exist.
  • the layers are five in number, and more precisely, going from the upper layer to the lower layer: the so-called application layer ("http”, “ftp”, “e- mail “, etc.), the so-called transport layer (" TCP “), the so-called network addressing layer (" IP “), the so-called data link layer (" PPP “,” Slip “, etc.). ) and the so-called physical layer.
  • the terminal 1 comprises circuits 11 for access to the network RI, consisting for example of a modem. These circuits include the lower software layers, C 1 and C 2 , which correspond to the "physical" and “data link” layers.
  • the interface between the lower layers, C 1 and C 2 , and the upper layers, C 3 and C 4 consists of a software layer generally called "low layer driver".
  • the upper layers, C 3 and C 4 rely on this interface and are implemented via libraries of specific functions or network libraries 14, with which they correspond.
  • libraries of specific functions or network libraries 14 with which they correspond.
  • TCP / IP is implemented by means of libraries called “sockets”.
  • This organization allows a browser 10 to make requests to a server 4, for the consultation of pages “WEB” (“HTTP” protocol), for the transfer of files (“FTP” protocol) or the sending of electronic mail ( protocol “e-mail”), this way quite classic in itself.
  • WEB pages
  • FTP file transfer protocol
  • e-mail electronic mail
  • the terminal 1 also comprises a card reader 3, integrated or not.
  • the card reader 3 also includes two lower layers, CC 1 (physical layer) and CC 2 (data link layer), playing a role similar to the layers C 1 and C 2 .
  • the software interfaces with the layers CC 1 and CC 2 are described, for example, by the specification "PC / SC"("part 6, service provider").
  • the layers themselves, CC 1 and CC 2 are described in particular by standards ISO 7816-1 to 7816-4, as recalled.
  • An additional software layer 16 forms an interface between the application layers (not shown) and the lower layers, CC 1 and CC 2 .
  • the main function assigned to this layer 16 is a multiplexing / demultiplexing function.
  • the communication with the smart card 2 was carried out according to a paradigm similar to that used for the manipulation of files in a "UNIX” type of operating system (registered trademark): OPEN ("OPEN”), READ (“ READ “), WRITE, CLOSE, etc.
  • OPEN OPEN
  • READ READ
  • CLOSE CLOSE
  • CC 1 physical layer
  • CC 2 data link layer
  • the specific layer 13 interfaces with the "low layer drivers" 15, the libraries 14 of the network layers, C 3 and C 4 , and the protocol layers of the card reader 3, that is to say the lower layers, CC 1 and CC 2 , via the multiplexing layer 16.
  • the specific layer 13 allows the transfer of network packets from and to the smart card 2 a .
  • it adapts existing applications such as the Internet browser 10, email, etc., for uses implementing the smart card 2 a .
  • agents agents
  • agents agents
  • the ISO 7816-3 protocol will preferably be used in block mode.
  • the primitives associated with the level two layer are of the "data request”(" Data.request ") and “data sending” type by the card (" Data.response "), as well as “ data confirmation "(" Data.confirm “), etc.
  • layers 13 and 23 are responsible for the dialogue between chip card 2a and the host, that is to say the terminal 1. These layers allow the exchange of information between a user (not shown) of terminal 1 and chip card 2a, for example via pull-down menus in the form of hypertext format "HTML.” They also allow the establishment of a suitable configuration for the transmission and / or reception of data packets.
  • HTML hypertext format
  • the layers comprise three distinct entities.
  • the first layer, 130 or 230 a consists essentially of a software multiplexer. It enables the exchange of information between the smart card 2a and the host terminal 1, in the form of protocol data units. It plays a role similar to that of a data packet switch. These units are sent or received via the layer two layer (data link layer).
  • This particular communication protocol makes it possible to put in communication at least one pair of "agents".
  • the first agent of each pair 132 is located in the layer 13 of the terminal 1, the second, 232 a, is located in the layer 23 has, in the smart card 2 a.
  • a link between two "agents" is associated with a session, which can be called " S-Agent ".
  • a session is a bidirectional data exchange between these two agents. If one or the other of the layers 13 and 23a, includes a plurality of agents, agents of the same layer can also establish sessions between them and / or with the modules 131 and 231, which constitute the particular agents.
  • an agent is an autonomous software entity that can perform all or part of functions of level three and four layers, depending on the configuration implemented by the terminal 1.
  • a particular agent is identified by a reference, for example an integer of 16 bits (i.e. between 0 and 65535).
  • agents There are two main categories of agents: "server” type agents, which are identified by a fixed reference, and “client” type agents, which are identified by a variable reference, which can be described as ephemeral, delivered by the configuration management module, 131 or 231a.
  • the agents communicate with each other using entities called “protocol data units” or " pdu " (for "protocol data unit”, according to the English terminology) comprising a destination reference and a source reference.
  • This "pdu” Special One could also call “SmartTP pdu” in reference to the term “Smart Card” (smart card) commonly used.
  • Smart pdu use in particular the references defined above.
  • the entity " SmartTP” checks the existence of the destination agent and realizes the switching of a packet towards the latter.
  • Figure 3 schematically illustrates the state diagram of the " S-Agent " sessions , as just recalled.
  • the layers 130 and 230 a manage tables (not shown) which contain the list of agents present, host terminal side 1 and smart card 2 a .
  • Agents can conveniently exchange data (for example, hypertext), but also trigger network transactions.
  • the configuration management modules, 131 and 231 a are comparable to particular agents.
  • the module 131 on the host terminal side 1, manages particular information relating to the configuration of this terminal (operating modes), list of other agents present, etc.
  • the module 231 has , on the smart card side 2 a , has similar functions. These two agents can be put in communication with each other to establish a session.
  • the smart card 2 has behaves like a client / seiner "WEB".
  • the smart card 2 a is advantageously "addressed” by using a "URL” address (for "Universal Resource Locator") defining a loopback to the terminal 1 itself, rather than pointing to a server external.
  • a "URL” address for "Universal Resource Locator”
  • the structure of this "URL” is usually the following: http://127.0.0.1:8080 (1), where 127.0.0.1 is the "IP” loopback address and 8080 is the port number.
  • FIG 4 illustrates in a simplified manner the logical architecture of a system according to the invention of the type shown in Figure 2, but shown in more detail.
  • the smart card 2 has several agents, only two of which have been represented: an agent 232 to 1 , of the so-called "WEB” type, and an agent of a type not precisely defined 232 to 2 .
  • the software stack includes the lower protocol layers, referenced 200 has, in accordance with ISO 7816-3 standards (figure 2: CC 1 and CC 2), the command handler "APDU" 201 1, and the packet multiplexer 230 a , the latter being interfaced to the agents, especially the "WEB" agent 231 to 1 .
  • the first stack comprises the network access members 11 (FIG. 2: C 1 and C 2 ) (OSI standards 1 and 2) and the "TCP / IP" protocol layers (FIG. 2: C 3 and C 4 ), referenced 100. These last layers are interfaced with the browser "WEB" 10.
  • the other stack comprises the lower protocol layers, referenced 101, meeting the ISO 7816-3 standards ( Figure 2: C 1 and C 2 ), the manager 102 orders "APDU" and the packet multiplexer 130, the latter being interfaced with agents, only one 132, is shown.
  • the latter which will be assumed to be of "network type” may furthermore communicate, on the one hand with the browser 10, via the "TCP / IP” layers 100, on the other hand with the Internet network RI, via these same layers “TCP / IP” 100 and the body 11, access network RI.
  • the order manager "APDUs" 201 is also interfaced with one or more applications-level layers, which will simply be called applications. These applications, A 1 , ..., A i ,..., A n , are, as has been indicated, conventional type applications, which have been called “cardlets”.
  • the "WEB" client / server function provided by the smart card 2 a , can be performed by the association of the "WEB” agent 232 to 1 in the smart card and the network agent 132. in the terminal 1, and by the implementation of sessions between agents, as has been described.
  • the smart card 2 has thus well the client / server "WEB” functionality. Furthermore, according to a characteristic of the method of the invention, any conventional application, A 1 to A n , of the "GCA” type mentioned above, can be activated through this client / server "WEB", either by the browser "WEB” 10 present in the terminal 1, or by a remote browser 4, located at any point of the Internet network RI , by the implementation of sessions between agents. According to the method of the invention, the applications, A 1 to A n , do not need to be rewritten and are implemented as they are.
  • proxy TCP / IP a function known as "proxy TCP / IP”. This function is performed by a particular software application that will be called “filter” below.
  • the "proxy” feature is well known in the field of Internet applications, but can not be implemented in the smart cards of the systems according to the prior art.
  • a " Py " software entity is called “proxy” which realizes, on the one hand, a "TCP / IP” server Sv and, on the other hand, a "TCP / IP” client Cl.
  • the software entity Py performs a connection between a local client and another remote TCP / IP server.
  • a proxy P y usually performs filter and / or security functions.
  • an "http” proxy generally provides the connection of a browser, for example the browser 10 of the terminal 1, to a server "WEB" 4, in a company (which is known under the name “firewall” or " firewall "). It can also be a so-called “SSL” proxy, which can be defined as a local “proxy” to the terminal, which performs the necessary security operations (authentication - confidentiality - integrity) to the institution. a secure tunnel through the Internet RI network .
  • agents unique terminal 1 are grouped under reference number 132, and the smart card 2 has, in the single reference 232 a. They will be differentiated in the following by the letter “T”, for "terminal”, and “S” for "Smart Card” (smart card), letters associated with digits in index.
  • the "proxy” 27 performed on the smart card has 2 will be called “Smart Proxy” in what follows.
  • a session T 1 -S 1 is then created.
  • the application associated with the agent S1 determines which filter function 28 should be used.
  • “des1" is the name of a particular filter
  • the filter "des1” is a filter for performing a decryption operation and / or encryption according to an algorithm of the type "DES" ("Data Encryption Standard").
  • the "map" URL (2) encapsulates another URL intended for the outside world, the first part of this URL being constituted by the loopback URL as defined by the relation (1).
  • the 28 "des1" filter creates a client instance S 2 ; a session is opened between the agents S 2 and T 2 .
  • the data inserted into the first " pdu "(" pdu OPEN ") specifies the name of the Internet server ("xxx.com”) and its associated port number (80).
  • the agent T 2 opens a connection of type "TCP” with the remote server "sTCP"("zzz.com”). Once this is established, a token is issued to S 2 .
  • a "Smart Proxy” 27 was created, a filter function 28 which lies in the smart card 2 a is able to process the data (from the Internet RI) received by the agents' network ".
  • the filter 28 controls the data sent by the " network " agents, T 1 and T 2 , in a logical manner. It behaves like a "TCP proxy” that controls the data exchanged between the "cTCP” client and the "sTCP” server.
  • FIG. 6 shows arbitrary reference numbers of the various agents: fixed, "2" and “5", for the “server” type agents, respectively T 2 and S 1 , and variables or ephemera, "15360” and “2559", for the "client” type agents, respectively T 1 and S 2 ,
  • a redirection filter associated with a map URL for example the following URL: (http // 127.0.0.1: 8080 / eMail) (3) a request "http" to an external server (for example www.email.com) which can be used for example to post, by using the well-known method "POST http", identification data: "login” and word of for example, associated with a free mail server "email”.
  • the filter can also provide identification / authentication of the service recipient by safer, challenge-based methods (these methods are described, for example, in the "http 1.1" standard).
  • the browser 10 When the browser 10 receives the redirection header, it connects to the mail server 4 with the appropriate "cookie". It typically receives a homepage written in "HTML" language.
  • Example N ° 2: filter "http - des"
  • the result of this operation is that the browser 10 receives a decoded "HTML" page.
  • the redirection operation can be automated by a script (typically in the "Java Script” language, registered trademark).
  • SSL Secure Socket Layer
  • WEB Wired Equivalent Privacy
  • the interest of achieving a "SSL" filter directly in the smart card 2a is that the certificate verification of the server's public key (which is the main point of public key systems) is performed by smart card and not by a software resident in the terminal, a priori judged safe.
  • a user or “user” (not shown) provides personal identification data, typically the association of a "login” and a password. pass, which are entered in clear on the terminal 1, using a keyboard ( Figure 1 A: 6 a ).
  • Another benefit of a session "SSL” conducted from the smart card 2a is that the "login” and password are provided by the smart card 2a and not by the user.
  • the result of this operation is that the browser 10 receives a decoded "HTML" page.
  • the redirection operation can be automated by a script (typically a "Java Script").
  • the terminal 1 obtains multimedia data, for example from the Internet network RI, this data loses all confidentiality and is stored by a generally unsafe system.
  • connection with the server 4 is asymmetrical from the point of view of security.
  • An identification and authentication procedure is secret, whereas the data subsequently exchanged are not confidential.
  • Ephemeral session keys (sometimes variable during the same connection) can be deduced from the critical flow, and implemented by the terminal 1 without particular security measures.
  • the critical flow which designates the data stream to be processed by the " Smart Proxy ", is distinguished from an "opaque" data stream that can be processed on an unsafe terminal.
  • a particular control " pdu " indicates to a first agent, arbitrarily called A 1 , the quantity of data Q 1 to be transmitted (excluding source reference fields, destination reference and flag), and another " pdu " indicates to a second agent, arbitrarily called A 2 , the quantity of data Q 2 sent from the agent A 1 and that it is authorized to receive.
  • a 1 the quantity of data Q 1 to be transmitted
  • a 2 the quantity of data Q 2 sent from the agent A 1 and that it is authorized to receive.
  • the " pdu " with the " CLOSE " flag are not transmitted out of session.
  • the critical flow contains secret information that must be processed by the filter 28 associated with the " Smart Proxy " and must therefore necessarily pass through the smart card 2 a .
  • the opaque stream can be processed only by agents located on the terminal 1, using an out-of-session data exchange mechanism, for example.
  • the opaque stream can be secured by the critical flow.
  • a global data flow can generally be broken down into a critical flow and an opaque flow, which makes it possible, for example, to decipher a high-speed flow (for example representing multimedia data per se) by a critical flow. of lower amplitude.
  • the provisions of the invention make it possible to process such a high-speed multimedia data stream by organizing asymmetrical data communication and processing protocols.
  • Example N ° 4 asymmetrical redirection filter
  • the filter 28 is said to be asymmetrical because, once authentication is performed, the data exchanged with the server 4 are not encrypted and no longer pass through the filter 28.
  • Example No. 5 asymmetric "SSL" filter
  • FIG. 8 is a simplified representation of most of the architecture according to the invention of the system of FIG.
  • an "SSL” filter can be activated by means of a "map" URL (for example that of the relation (11)).
  • a "map" URL for example that of the relation (11)
  • the flow of critical data is used to select a pair of entities that comprises an encryption algorithm and a hash function (or “hash” in the English terminology) one way, and a number of associated parameters (keys and current value of the "hash” function).
  • an additional agent T 3 (of the server type) to which an "SSL" function is devolved.
  • This agent T 3 is located in the terminal 1.
  • the "SSL" filter 28 opens a session between an additional client agent S 3 (smart card side 2 a ). and the server agent "SSL” T 3 (terminal side).
  • the agent T 3 is initialized with key values "DES” and current parameters of the "hash” function.
  • the "SSL” filter 28 sends a command " pdu " to the agent T 2 , which enables it to retransmit the data sent out of session by T 3 to the network RI , and to redirect the data received from the network to T 3 .
  • the "SSL” filter 28 sends a " pdu " command to the agent T 3 to allow it to receive, out of session, the data transmitted by T 1 and T 2 .
  • the "SSL” filter sends a " pdu " command to the agent T 1 , which allows it to retransmit the data sent out of session by T 3 to the network RI , and to redirect the data received from this network RI to T 3 .
  • a "tunnel" out of session is then established in the terminal 1, between T 1 -T 2 -T 3 . When a T 1 or T 2 agent closes the session associated with him, the filter 28 closes the other two remaining sessions.
  • a " Smart Proxy " 27 (FIG. 6) is produced from a "card” URL by means of two sessions T 1 -S 1 and T 2 -S 2 .
  • the particular filter to be made 28 is determined from this URL.
  • the filter 28 controls the flow of data between the "TCP” client (browser 10) and the remote server 4.
  • a set of security parameters is got. It consists of a critical data flow.
  • the filter 28 then opens a session with a security agent (T 3 , for example) who performs the negotiated protocol with a set of parameters defined by the filter 28 during the opening of the session.
  • the filter 28 creates an out-of-session data transfer tunnel T 1 -T 2 -T 3 .
  • T 1 -T 2 -T 3 For example, a predetermined amount of data is transmitted out-of-band by the T 1 -T 2 -T 3 chain.
  • the opaque data stream is processed by the set T 1 -T 2 -T 3 , and therefore does not pass through the smart card 2 a .
  • Critical data can be identified by various methods: opaque data length set periodically, tags in a "TCP" packet using an urgent data pointer, and so on. These methods are known per se.
  • the critical data unlike the opaque data, are transmitted by agents of the terminal 1, T 1 or T 2 , to the filter 28.
  • the latter modifies accordingly, by means of a " pdu " control, the functional parameters of the agent T 3 .
  • T 1 agent, T 1 or T 2 closes the session associated with it, the filter 28 closes the other two remaining sessions.
  • the opaque data stream apart from any aspect related to security, can undergo various transformations, performed for example by an additional agent, similar to the agent T 3 .
  • security must be understood in its most general acceptance: confidentiality, authorization, sealing or signature, in particular by the use of "certificates”, etc.
  • the filter 28 can modify the parameters of the agent T 3 accordingly , by using a particular " pdu ".
  • opaque data for example transmitted encoded in the "mp3" format, may be converted to "wav” format or any other format accepted by the terminal 1.
  • opaque data received at "MPEG” format may be converted to "avi” format or any other format accepted by the terminal 1.
  • the smart card becomes capable of delegating the processing of an information flow, the quantity of which is fixed, to the terminal to which it is connected. It follows that global flows, having a very high rate, can still be processed by a smart card terminal, through the implementation of asymmetrical communication protocols, while maintaining a maximum degree of security . This high degree of security is due to the fact that the essential operations of encryption and / or authentication remain under the exclusive control of the smart card, the so-called critical data passing through it.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

  • L'invention concerne un procédé de transmission de flux de données à haut débit sur un réseau de type Internet entre un serveur et un terminal à carte à puce.
  • L'invention s'applique plus particulièrement à un flux de données multimédia sécurisé.
  • Dans le cadre de l'invention, le terme "haut débit" concerne des flux de données dont le débit est typiquement de l'ordre de 100 kbits par seconde ou plus. A titre d'exemple, un fichier audio de données codées en "MP3" nécessite un espace mémoire de 1 MO pour une minute d'enregistrement, soit environ 100 kbits/sec., lorsque ce fichier est transmis par un canal numérique pour être diffusé en temps réel. On peut citer également des flux de données vidéo qui nécessitent une vitesse de transmission de l'ordre de 2 Mbits/sec pour être affichés en temps réel. C'est, a fortiori, aussi le cas de flux de données dits multimédias qui peuvent véhiculer à la fois des images, de la vidéo et/ou des sons.
  • Toujours dans le cadre de l'invention, le terme "terminal à carte à puce" doit être compris dans un sens général. Il peut notamment être constitué par un ordinateur personnel fonctionnant sous divers systèmes d'exploitation, tels WINDOWS ou UNIX (tous deux étant des marques déposées). Il peut être aussi constitué par une station de travail, ou un ordinateur portable.
  • De même, dans le cadre de l'invention, le terme "réseau Internet" englobe, outre le réseau Internet proprement dit, les réseaux privés d'entreprises ou similaires, du type dit "intranet", et les réseaux les prolongeant vers l'extérieur, du type dit "extranet", et de façon générale tout réseau dans lequel les échanges de données s'effectuent selon un protocole du type Internet.
  • Pour fixer les idées, on se placera dans ce qui suit dans le cas de l'application préférée de l'invention, sans en limiter la portée en quoi que ce soit, à savoir la transmission d'un flux de données multimédias sécurisées, sauf mention contraire.
  • Par "sécurisé", on entend le fait que les données en question sont chiffrées, en tout ou partie, pour en assurer la confidentialité, ou pour le moins qu'on ne peut y accéder librement. Il peut s'agir, dans ce dernier cas, de données à accès payant. Dans tous les cas, il est en général nécessaire de fournir des données d'identification (mot de passe, identifiant ou "login", N° de carte de crédit, etc.) qui permettent une transaction en vue de l'obtention des données désirées (fichier multimédia par exemple). Ces données sont dites "sensibles" et ne peuvent être transmises en "clair" sur le réseau Internet. Elles doivent donc être sécurisées : chiffrage ou utilisation d'un protocole sécurisé, par exemple du type "SSL" (pour Secure Socket Layer").
  • Avec l'essor très rapide du réseau Internet, un premier besoin se fait sentir de pouvoir transmettre par ce réseau toutes sortes de fichiers numériques, à partir de/ou vers divers systèmes serveurs et/ou clients. Lorsque la bande passante de la voie de transmission, ou d'une portion de cette voie de transmission reliant ces deux systèmes est faible (c'est le cas, par exemple, des lignes téléphoniques du type dit commuté, limitées à environ 56 kbits/sec. lorsqu'on met en oeuvre le standard V90), des fichiers volumineux peuvent être certes transmis par ces lignes de transmission, mais ne peuvent être utilisés dans la majorité des cas qu'après complet téléchargement et non en temps réel. La disponibilité de voies de communication rapides (réseau numérique à intégration de service "RNIS", ou "ISDN" selon la terminologie anglo-saxonne, câble ou liaisons par satellite) permet d'envisager la diffusion en temps réel de fichiers audio, voire multimédias, par un terminal connecté au réseau Internet. Même une ligne téléphonique classique, lorsque l'on met en oeuvre une technologie de transmission récente connue sous le sigle "ADSL", permet de transmettre des données numériques à une vitesse de l'ordre de 1 Mbits/sec.
  • Or, historiquement, le canal de transmission entre un serveur éloigné et un terminal, tous deux connectés au réseau Internet, constituait "un goulot d'étranglement". Il est en effet clair que les systèmes informatiques aux deux bouts de la chaîne, serveurs et terminaux, peuvent accepter les débits de données nécessaires à la transmission et/ou au traitement et à la diffusion de fichiers multimédia. La mise en oeuvre récente de voies rapides sur le réseau Internet permet donc ce type de traitement "de bout en bout".
  • Un autre besoin qui se fait sentir est l'utilisation de cartes à puce en association avec les terminaux.
  • En effet, dans un système d'applications à base de carte à puce, cette dernière peut se voir dévolues diverses fonctions, et notamment des fonctions de sécurité. Il est en effet avantageux de stocker les données liées à la sécurité (mots de passe, droits d'accès, etc.) dans une carte à puce qui peut être conservée par l'utilisateur. En outre, les données, étant enregistrées dans une mémoire fixe, sous une forme qui peut être chiffrée, elles ne sont pas facilement modifiables, ni même directement lisibles de l'extérieur.
  • Dans le cadre de transactions payantes, des fonctions similaires sont mises en oeuvre. Il est également nécessaire, comme il a été rappelé, de transmettre des mots de passe et/ou identifiants, ainsi que diverses données sensibles (N° de carte bancaire, etc.) et des données définissant les droits d'un utilisateur (abonnements en vigueur, services accessibles, etc.).
  • Il est cependant à noter que, dans l'art connu, la "fonction sécurité" ne peut pas être réalisée directement à l'intérieur de la carte à puce, car le flux de données, reçu et/ou transmis, ne la traverse pas. Il doit donc s'établir un dialogue entre le terminal et la carte à puce pour que les contrôles liés à la sécurité puissent s'effectuer. Ce mode opératoire dégrade le niveau de sécurité, voire permet l'introduction de "chevaux de Troie" dans le terminal, dans certaines conditions défavorables. Il serait donc nécessaire que les contrôles de sécurité s'effectuent in situ, c'est-à-dire dans la carte à puce elle-même, ce qui nécessiterait que le flux de données soit dévié par la carte à puce, avant d'être transmis au terminal.
  • En sus de la fonction "sécurité" qui lui est dévolue, il serait également intéressant que la carte à puce puisse contrôler directement certaines opérations qui se déroulent dans le terminal et puisse, par exemple, modifier des caractéristiques prédéterminées de données reçues et/ou transmises par le terminal.
  • Dans l'art connu, ces modes opératoires sont incompatibles avec les technologies actuellement disponibles et avec les normes retenues pour les applications à base de carte à puce, comme il va l'être montré ci-après.
  • On va tout d'abord rappeler brièvement l'architecture générale d'un système d'application à base de carte à puce, par référence aux figures 1 A et 1B.
  • Un système d'application à base de carte à puce comporte généralement les éléments principaux suivants :
    • une carte à puce ;
    • un système hôte constituant le terminal précité ;
    • un réseau de communication, à savoir le réseau Internet dans l'application préférée ;
    • et un serveur d'application connecté au réseau Internet.
  • La figure 1A illustre schématiquement un exemple d'architecture de ce type. Le terminal 1, par exemple un ordinateur individuel, comporte un lecteur 3 de carte à puce 2. Ce lecteur 3 peut être ou non physiquement intégré dans le terminal 1. La carte à puce 2 comporte un circuit intégré 20 dont des connexions d'entrées-sorties affleurent en surface de son support pour autoriser une alimentation en énergie électrique et des communications avec le terminal 1. Ce dernier comprend des circuits d'accès 11 au réseau Internet RI. Ces circuits peuvent être constitués par un modem pour se connecter à une ligne téléphonique commutée ou, dans le cas de l'invention, de préférence à une voie de communication à plus haut débit : réseau numérique à intégration de services ("RNIS"), câble ou liaisons par satellite. Les circuits 11 permettent de se connecter au réseau Internet RI, directement ou via un prestataire de services Internet ("Internet Service Provider" ou "ISP", selon la terminologie anglo-saxonne). On peut également avoir recours à un système intermédiaire tel qu'un "proxy" ou un système d'isolation dit "firewall" ("pare-feu" ou encore appelé "garde barrière").
  • Le terminal 1 comprend naturellement tous les circuits et organes nécessaires à son bon fonctionnement, et qui n'ont pas été représentés dans un but de simplification du dessin : unité centrale, mémoires vive et fixe, mémoire de masse à disque magnétique, lecteur de disquette et/ou de CédéRom, etc.
  • Habituellement, le terminal 1 est aussi relié à des périphériques classiques, intégrés ou non, tels un écran de visualisation 5a et un système de reproduction sonore 5b (permettant la diffusion de fichiers multimédias, dans le cadre de l'invention), un clavier 6a et une souris 6b, etc.
  • Le terminal 1 peut être mis en communication avec des serveurs ou tous systèmes informatiques connectés au réseau RI, dont un seul, 4, est illustré sur la figure 1A. Les circuits d'accès 11 mettent le terminal 1 en communication avec les serveurs 4 grâce à un logiciel particulier 10, appelé navigateur "WEB", ou "browser" selon la terminologie anglo-saxonne. Celui-ci permet d'accéder à diverses applications ou fichiers de données répartis sur l'ensemble du réseau RI, généralement selon un mode "client-serveur", notamment à des fichiers multimédias.
  • Habituellement, les communications sur les réseaux s'effectuent conformément à des protocoles répondant à des standards comprenant plusieurs couches logicielles superposées. Dans le cas d'un réseau RI de type Internet, les communications s'effectuent selon des protocoles spécifiques à ce type de communications, qui seront détaillés ci-après, mais qui comprennent également plusieurs couches logicielles. Le protocole de communication est choisi en fonction de l'application plus particulièrement visée : interrogation de pages "WEB", transferts de fichiers, courrier électronique (e-mel, ou "e-mail" selon la terminologie anglo-saxonne), forums ou "news", etc.
  • L'architecture logique du système comprenant un terminal, un lecteur de carte à puce et une carte à puce, est représentée schématiquement par la figure 1B. Elle est décrite par la norme ISO 7816, qui elle-même comporte plusieurs sous-ensembtes :
    • ISO 7816-1 et 7816-2, en ce qui concerne les dimensions et le marquage des cartes ;
    • ISO 7816-3, en ce qui concerne le transfert de données entre le terminal et la carte à puce ; et
    • ISO 7816-4, en ce qui concerne la structure du jeu d'ordres et le format des commandes.
  • Sur la figure 1B, du côté terminal 1, on n'a représenté que les couches répondant à la norme ISO 7816-3, référencées 101, et un gestionnaire d'ordres "APDU" (norme ISO 7816-4), référencé 102. Du côté carte à puce 2, les couches répondant à la norme ISO 7816-3 sont référencées 201 et le gestionnaire d'ordres "ADPU" (norme ISO 7816-4) est référencé 210. Les applications sont référencées A 1 , ..., A i , ..., A n , n étant le nombre maximum d'applications présentes sur la carte à puce 2.
  • Une application "cardlet" (marque déposée), A i , présente dans la carte à puce 2 (figure 1A), dialogue avec le terminal 1 au moyen d'un jeu d'ordres. Ce jeu présente typiquement des ordres d'écriture et des ordres de lecture. Le format des ordres est connu sous l'abréviation anglo-saxonne de "APDU" (pour "Application Protocol Data Unit"). Il est défini par la norme ISO 7816-4 précitée. Une "APDU" de commande est notée "APDU.command" et une "APDU" de réponse est notée "APDU.response". Les "APDU" sont échangées entre le lecteur de carte et la carte à puce au moyen d'un protocole spécifié par la norme ISO 7816-3 précitée (par exemple en mode caractère : T=0 ; ou en mode bloc : T=1).
  • Lorsque la carte à puce 2 inclut plusieurs applications distinctes, comme illustré sur la figure 1B, on parle de carte multi-applicative. Cependant, le terminal 1 ne dialogue qu'avec une seule application à la fois. Une application A i se présente, par exemple, sous la forme d'une pièce de logiciel, dite "applet", en langage "JAVA" (marque déposée), que l'on appellera ci-après "cardlet". La sélection d'un "cardlet" particulier A i est obtenue à l'aide d'une "APDU" du type sélection ("SELECT"). Une fois ce choix effectué, les "APDU" qui le suivent sont acheminés vers ce "cardlet". Une "APDU SELECT" nouvelle a pour effet d'abandonner l'application en cours et d'en choisir une autre. Le sous-ensemble logiciel gestionnaire des "APDU" 210 permet de choisir une application particulière A i dans la carte à puce 2, de mémoriser l'application ainsi choisie, et de transmettre et/ou recevoir des "APDU" vers et depuis cette application.
  • En résumé de ce qui vient d'être décrit, la sélection d'une application A i et le dialogue avec celle-ci s'effectuent par échanges d'ordres "APDU". On suppose que les applications A i sont des applications conventionnelles, que l'on appellera ci-après "GCA" (pour "Generic Card Application" ou application de carte générique).
  • Ces rappels étant effectués, il est à noter que la carte à puce 2 ne peut communiquer directement avec les navigateurs standards du commerce, sauf à modifier le code de ces derniers.
  • En outre, et surtout, les cartes à puce actuelles, qui par ailleurs sont conformes aux standards et normes rappelés ci-dessus, ont une configuration matérielle et logicielle qui ne permet pas non plus de communiquer directement avec le réseau Internet. En particulier, elles ne peuvent recevoir et transmettre des paquets de données, selon l'un ou l'autre des protocoles utilisés sur ce type de réseau. Il est donc nécessaire de prévoir une pièce de logiciel additionnelle, implantée dans le terminal 1, généralement sous la forme de ce qui est appelé un "plug-in", selon la terminologie anglo-saxonne. Cette pièce de logiciel, qui porte la référence 12 sur la figure 1A, effectue l'interface entre le navigateur 10 et la carte 2, plus précisément les circuits électroniques 20 de cette carte 2.
  • Il est clair également que, même compte tenu de la rapide évolution passée des technologies et de leur évolution future prévisible, la capacité d'enregistrement d'informations dans des circuits de mémoire, vive ou fixe, d'une carte à puce reste et restera très limitée, si on compare cette capacité à celle offerte par un terminal "hôte" de cette carte à puce, et naturellement à celles offertes par des systèmes plus importants, "mini-ordinateurs" ou grands systèmes de type dit "main frame". Aussi, il n'est pas possible de stocker dans la carte à puce des fichiers de données volumineux, et notamment des fichiers de type multimédia. Il serait donc nécessaire, en admettant qu'il soit possible de faire communiquer la carte à puce avec le réseau Internet et d'y faire transiter les données (ce que ne permet pas l'art connu, comme il vient d'être rappelé), d'effectuer tous les traitements nécessaires "à la volée", c'est-à-dire sans mise en mémoire, même temporaire. La puissance de calcul des circuits logiques, notamment du microprocesseur présent dans la carte à puce, ne permet pas un tel mode opératoire, dans l'état actuel des techniques connues ou envisageables à court terme.
  • Enfin, les normes précitées organisent des communications entre carte à puce et terminal, via le lecteur, de type série. Qui plus est, le débit permis par la technologie actuelle est très faible, de l'ordre de 1 à 10 kbits/sec., ce qui, une fois de plus, est incompatible avec les débits envisagés (100 Kbits/sec. au minimum) dans le cadre des applications de l'invention.
  • L'invention vise à pallier les inconvénients des procédés et dispositifs de l'art connu, et dont certains viennent d'être rappelés, tout en répondant aux besoins qui se font sentir, c'est-à-dire notamment de pouvoir accommoder des flux de données à haut débit, tout en bénéficiant d'une sécurité maximale.
  • Selon une première caractéristique de l'invention, la carte à puce se comporte comme un senreur/client de type "WEB" pour le terminal qui lui est associé.
  • Pour ce faire, on prévoit une couche de logiciel de communication spécifique dans la carte à puce et son pendant dans le terminal. Le terme "spécifique" doit être entendu comme spécifique au procédé de l'invention. En effet, ces couches de communication, dites spécifiques, sont banalisées quelle que soit l'application considérée. Elles n'interviennent que dans le processus d'échanges de données bidirectionnels entre la carte à puce et le terminal, d'une part, et la carte à puce et le réseau, d'autre part.
  • Les couches logicielles de communication spécifiques comprennent notamment des composants logiciels, dits "agents intelligents", permettant en particulier des conversions de protocoles. Les agents intelligents seront appelés ci-après plus simplement "agents". Il existe des agents appareillés dans les couches de communication spécifiques respectives associées au terminal et à la carte à puce. Selon le procédé de l'invention, il s'établit des sessions entre agents appareillés.
  • Ces dispositions permettent notamment de dériver tout ou partie du flux de données de ou vers le réseau Internet par la carte à puce, ce tout en respectant les normes ISO précitées pour les communications entre carte à puce et terminal, via le lecteur.
  • Selon une autre caractéristique de l'invention, on implante dans la carte à puce une application particulière, que l'on appellera "filtre" dans ce qui suit. Il s'agit d'une entité logicielle qui joue un rôle analogue à celui d'un "proxy". Pour ce faire, on fait appel aux dispositions précitées mettant en oeuvre des agents. Ce "proxy" permet d'effectuer des traitements de données liés à la sécurité directement au sein de la carte à puce.
  • Selon une autre caractéristique de l'invention, on implante un protocole de communication dissymétrique. Selon cette caractéristique, le flux de données en émission ou en réception est subdivisé en deux composantes : un premier flux de faible débit et représentant un faible volume de données, que l'on appellera ci-après "flux de données critiques", qui transite directement par la carte à puce, et un flux de fort débit et représentant un grand volume de données, que l'on appellera ci-après "flux de données opaques", qui transite par le terminal.
  • Dans des applications préférées de l'invention, le flux de données critiques est constitué par des données de sécurité qui peuvent être adressées au "proxy" précité de la carte à puce, pour y être traitées de façon secrète. Les données opaques sont constituées par des données multimédias proprement dites. Ces données sont traitées par des agents localisés dans le terminal. Cependant l'autorisation de recevoir des données opaques et de les traiter est subordonnée au résultat d'une procédure d'authentification initiée par les données de sécurité dans la carte à puce. Du fait de la présence du filtre précité, la réception des données par le terminal reste sous le contrôle direct de la carte à puce.
  • Les données opaques transitant par le terminal peuvent subir également des traitements particuliers au sein de ce terminal avant utilisation effective, sous la commande et le contrôle de la carte à puce, c'est-à-dire en définitive des données critiques qu'elle a reçues.
  • Pour ce faire, on prévoit des agents particuliers supplémentaires, que l'on pourra appeler « de protocole », localisés dans la carte à puce et le terminal, ou dans l'un seulement de ces dispositifs.
  • L'invention a donc pour objet principal un procédé de transmission d'un flux de données, via un réseau de type Internet, entre au moins un serveur distant et un terminal muni d'un lecteur de carte à puce, ledit terminal comprenant au moins une application de type dit "client TCP/IP", ledit terminal et ledit serveur étant tous deux connectés au dit réseau de type Internet, caractérisé en ce qu'il comprend au moins les phases suivantes :
    • a/ une première phase consistant à implanter, dans ladite carte à puce, une première pièce de logiciel, formant une couche protocolaire de communication spécifique ;
    • b/ une deuxième phase consistant à implanter, dans ledit terminal, une seconde pièce de logiciel, formant une couche protocolaire de communication spécifique et formant interface avec au moins ladite application de type "client TCP/IP" ;
      • en ce que lesdites première et seconde pièces de logiciel comprennent chacune en outre au moins une première entité logicielle autonome, de type dit client, et une deuxième entité logicielle autonome, de type dit serveur, lesdites entités coopérant de manière à permettre l'établissement de sessions d'échanges de données bidirectionnels entre ledit terminal et ladite carte à puce et de manière à ce que ladite carte à puce offre les fonctionnalités d'un client/serveur de type "WEB", et à permettre l'établissement d'une session d'échanges de données bidirectionnels entre ledit terminal et un desdits serveurs distants, via ledit réseau de type Internet, lesdites entités logicielles autonomes communiquant au moyen d'unités de données de protocole prédéterminées ;
      • en ce qu'il comprend une phase de réalisation, dans ladite carte à puce, d'une pièce de logiciel applicative de caractéristiques fonctionnelles déterminées, dite « filtre », recevant et/ou émettant des unités de données de protocole vers lesdites et/ou à partir desdites première et deuxième entités logicielles autonomes, de types respectifs client et serveur, comprises dans ladite seconde pièce de logiciel spécifique, la réalisation de ladite pièce applicative étant sous le contrôle de ladite entité logicielle autonome de type serveur ;
      • et en ce que ledit filtre coopère avec lesdites entités logicielles autonomes de ladite seconde pièce de logiciel spécifique pour ouvrir une session avec lesdites entités logicielles autonomes de ladite première pièce de logiciel spécifique, pour modifier des caractéristiques prédéterminées dudit flux de données transmis entre ledit terminal et ledit serveur distant.
  • L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels :
    • les figures 1A et 1B illustrent schématiquement les architectures matérielles et logiques, respectivement, d'un exemple de système d'application à base de carte à puce selon l'art connu ;
    • la figure 2 illustre schématiquement un exemple de système d'application à base de carte à puce selon l'invention, cette dernière agissant en tant que serveur "WEB" ;
    • la figure 3 est un diagramme d'états d'une session entre des entités logicielles dites agents intelligents, selon un aspect de l'invention ;
    • la figure 4 illustre de façon simplifiée l'architecture logique d'un système selon l'invention dans lequel la carte à puce comprend des agents intelligents ;
    • la figure 5 illustre schématiquement un "proxy" selon l'art connu ;
    • la figure 6 illustre de façon simplifiée l'architecture logique d'un système selon l'invention conforme à celui de la figure 4, dans lequel un filtre dit "proxy" est réalisé sur la carte à puce ;
    • la figure 7 est un diagramme schématique illustrant un premier exemple de réalisation de filtre dissymétrique (dit de "redirection") dans une architecture conforme à l'invention, du type de celle de la figure 6 ; et
    • la figure 8 est un diagramme schématique illustrant un deuxième exemple de réalisation de filtre dissymétrique (dit de "SSL") dans une architecture conforme à l'invention, du type de celle de la figure 6.
  • Dans ce qui suit, sans en limiter en quoi que ce soit la portée, on se placera ci-après dans le cadre de l'application préférée de l'invention, sauf mention contraire, c'est-à-dire dans le cas d'un flux multimédia sécurisé par un proxy implanté sur une carte à puce coopérant avec un terminal connecté au réseau Internet, réseau Internet sur lequel sont également connectés des serveurs WEB.
  • Avant de décrire le procédé d'activation d'applications localisées dans une carte à puce selon l'invention et de détailler une architecture pour sa mise en oeuvre, par référence à la figure 2, il apparaît tout d'abord utile de rappeler brièvement les caractéristiques principales des protocoles de communication sur les réseaux.
  • L'architecture des réseaux de communication est décrite par diverses couches. A titre d'exemple, le standard "OSI" ("Open System Interconnection"), défini par "I'ISO", comporte sept couches qui vont des couches dites basses (par exemple la couche dite "physique" qui concerne le support de transmission physique) aux couches dites hautes (par exemple la couche dite "d'application"), en passant par des couches intermédiaires, notamment la couche dite de "transport". Une couche donnée offre ses services à la couche qui lui est immédiatement supérieure et requiert de la couche qui lui immédiatement inférieure d'autres services, via des interfaces appropriées. Les couches communiquent à l'aide de primitives. Elles peuvent également communiquer avec des couches de même niveau. Dans certaines architectures, plusieurs couches peuvent être inexistantes.
  • Dans un environnement de type Internet, les couches sont au nombre de cinq, et de façon plus précise, en allant de la couche supérieure à la couche inférieure : la couche dite d'application ("http", "ftp", "e-mail", etc.), la couche dite de transport ("TCP"), la couche dite d'adressage de réseau ("IP"), la couche dite de liens de données ("PPP", "Slip", etc.) et la couche dite physique.
  • A l'exception de couches logicielles de protocole de communication spécifiques, référencées 13 et 23a, respectivement implantées dans le terminal 1 et la carte à puce 2a, les autres éléments, matériels ou logiciels, sont communs à l'art connu, et il n'y a pas lieu de les re-décrire de façon détaillée.
  • Le terminal 1 comprend des circuits 11 d'accès au réseau RI, constitués par exemple d'un modem. Ces circuits regroupent les couches logicielles inférieures, C1 et C2, qui correspondent aux couches "physique" et de "lien de données".
  • On a également représenté les couches supérieures, C3 et C4, qui correspondent aux couches "d'adressage de réseau" ("IP", dans le cas d'Internet) et de "transport" ("TCP"). La couche supérieure d'application ("http", "ftp", "e-mail", etc.) n'a pas été représentée.
  • L'interface entre les couches inférieures, C1 et C2, et les couches supérieures, C3 et C4, est constituée par une couche logicielle généralement appelée "driver couches basses". Les couches supérieures, C3 et C4, s'appuient sur cette interface et sont mises en oeuvre par l'intermédiaire de bibliothèques de fonctions spécifiques ou bibliothèques réseau 14, avec lesquelles elles correspondent. Dans le cas du réseau Internet, "TCP/IP" est mis en oeuvre au moyen de bibliothèques dites de "sockets".
  • Cette organisation permet à un navigateur 10 de poser des requêtes vers un serveur 4, pour la consultation de pages "WEB" (protocole "HTTP"), pour le transfert de fichiers (protocole "FTP") ou l'envoi de courrier électronique (protocole "e-mail"), ce de façon tout à fait classique en soi.
  • Le terminal 1 comprend également un lecteur de carte 3, intégré ou non. Pour communiquer avec la carte à puce 2a, le lecteur de carte 3 englobe également deux couches basses, CC1 (couche physique) et CC2 (couche de lien de données), jouant un rôle similaire aux couches C1 et C2. Les interfaces logicielles avec les couches CC1 et CC2 sont décrites, par exemple, par la spécification "PC/SC" ("part 6, service provider"). Les couches elles-mêmes, CC1 et CC2, sont notamment décrites par les normes ISO 7816-1 à 7816-4, comme il a été rappelé.
  • Une couche logicielle supplémentaire 16 forme interface entre les couches applicatives (non représentées) et les couches inférieures, CC1 et CC2. La fonction principale dévolue à cette couche 16 est une fonction de multiplexage/démultiplexage.
  • Les communications avec la carte à puce 2a s'effectuent selon un paradigme similaire à celui utilisé pour la manipulation de fichiers dans un système d'exploitation du type "UNIX" (marque déposée) : OUVRIR ("OPEN"), LIRE ("READ"), ECRIRE ("WRITE"), FERMER ("CLOSE"), etc.
  • Du côté de la carte à puce 2a, on retrouve une organisation similaire, à savoir la présence de deux couches basses, référencées CCa 1 (couche physique) et CCa 2 (couche de lien de données), ainsi qu'une couche d'interface 26a, tout à fait similaire à la couche 16.
  • Selon une première caractéristique de l'invention, on prévoit, de part et d'autre, c'est-à-dire dans le terminal 1 et dans la carte à puce 2a, deux couches de protocoles spécifiques : 13 et 23a, respectivement.
  • Dans le terminal 1, la couche spécifique 13 s'interface aux "drivers couches basses" 15, aux bibliothèques 14 des couches réseau, C3 et C4, et aux couches protocolaires du lecteur de carte 3, c'est-à-dire les couches inférieures, CC1 et CC2, via la couche de multiplexage 16. La couche spécifique 13 permet le transfert de paquets réseaux de et vers la carte à puce 2a. En outre, elle adapte les applications existantes telles le navigateur Internet 10, le courrier électronique, etc., pour des utilisations mettant en oeuvre la carte à puce 2a.
  • Du côté de la carte à puce 2a, on retrouve une organisation tout à fait similaire constituée par une instance supplémentaire de la couche spécifique, référencée 23a, pendant de la couche 13.
  • De façon plus précise, les couches spécifiques, 13 et 23a, sont subdivisées en trois éléments logiciels principaux :
    • un module, 130 ou 230a, de transfert de blocs d'informations entre les couches 13 et 23a, via les couches conventionnelles CC1, CC2, CCa 1 et CCa 2 ;
    • une ou plusieurs pièces de logiciel, dites "agents intelligents", 132 ou 232a, qui réalisent, par exemple, des fonctions de conversion de protocoles ;
    • et un module de gestion de la configuration spécifique, 131 et 231a, respectivement, module qui peut être assimilé à un agent intelligent particulier.
  • Pour simplifier, on appellera ci-après les agents intelligents, "agents", comme il a été précédemment indiqué.
  • On retrouve donc, dans le terminal 1 et la carte à puce 2a, une pile protocolaire de communication entre les deux entités.
  • Les couches de niveau deux (couches de lien de données), CC2 et CCa 2, assurent l'échange entre la carte à puce 2a et le terminal 1. Ces couches sont responsables de la détection et l'éventuelle correction d'erreurs de transmission. Différents protocoles sont utilisables, et à titre d'exemples non exhaustifs les suivants :
    • la recommandation ETSI GSM 11.11 ;
    • le protocole défini par la norme ISO 7816-3, en mode caractère T=0
    • le protocole défini par la norme ISO 7816-3, en mode bloc T=1 ;
    • ou le protocole défini par la norme ISO 3309, en mode trame "HDLC" (pour "High-Level Data Link Control procedure" ou procédure de commande de liaison à haut niveau).
  • Dans le cadre de l'invention, on utilisera de préférence le protocole ISO 7816-3, en mode bloc.
  • De façon connue en soi, à chaque couche de protocole, il est associé un certain nombre de primitives qui permettent les échanges de données entre couches de même niveau et d'une couche à l'autre. A titre d'exemple, les primitives associées à la couche de niveau deux sont du type "demande de données" ("Data.request") et "envoi de données" par la carte ("Data.response"), ainsi que "confirmation de données" ("Data.confirm"), etc.
  • De façon plus spécifique, les couches 13 et 23a sont chargées du dialogue entre la carte à puce 2a et l'hôte, c'est-à-dire le terminal 1. Ces couches permettent l'échange d'informations entre un utilisateur (non représenté) du terminal 1 et la carte à puce 2a, par exemple via des menus déroulants sous la forme d'hypertexte au format "HTML". Elles permettent aussi la mise en place d'une configuration adaptée pour l'émission et/ou la réception de paquets de données.
  • Comme il a été indiqué ci-dessus, les couches comprennent trois entités distinctes.
  • La première couche, 130 ou 230a, est essentiellement constituée par un multiplexeur logiciel. Elle permet l'échange d'informations entre la carte à puce 2a et le terminal hôte 1, sous la forme d'unités de données de protocole. Elle joue un rôle similaire à celui d'un commutateur de paquets de données. Ces unités sont émises ou reçues via la couche de niveau deux (couche de liens de données). Ce protocole particulier de communication permet de mettre en communication au moins une paire d' "agents". Le premier agent de chaque paire, 132, est situé dans la couche 13, côté terminal 1, le second, 232a, est situé dans la couche 23a, côté carte à puce 2a. Une liaison entre deux "agents" est associée à une session, que l'on pourra appeler "S-Agent". Une session est un échange de données bidirectionnel entre ces deux agents. Si l'une ou l'autre des couches, 13 et 23a, comporte plusieurs agents, les agents d'une même couche peuvent aussi établir des sessions entre eux et/ou avec les modules 131 et 231a, qui constituent des agents particuliers.
  • De façon plus précise, un agent est une entité logicielle autonome qui peut réaliser tout ou partie de fonctions des couches de niveau trois et quatre, en fonction de la configuration mise en oeuvre par le terminal 1.
  • Les agents sont associés à des propriétés ou attributs particuliers. Pour fixer les idées, et à titre d'exemple non limitatif, les six propriétés suivantes sont associées aux agents :
    • "hôte" : agent localisé dans le terminal ;
    • "carte" : agent localisé dans la carte à puce ;
    • "local" : agent ne communiquant pas avec le réseau ;
    • "réseau" : agent communiquant avec le réseau (côté terminal) ;
    • "client" : agent qui initialise une session ;
    • "serveur" : agent qui reçoit une demande de session.
  • Un agent particulier est identifié par une référence, par exemple un nombre entier de 16 bits (c'est-à-dire compris entre 0 et 65535). Le bit de poids fort (b15 = 1) indique si la référence est locale (communications locales à la carte à puce ou au terminal) ou distante (b15 = 0).
  • Il existe deux grandes catégories d'agents : les agents de type "serveur", qui sont identifiés par une référence fixe, et les agents de type "client", qui sont identifiés par une référence variable, que l'on peut qualifier d'éphémère, délivrée par le module de gestion de configuration, 131 ou 231a.
  • Les agents communiquent entre eux à l'aide d'entité dites "unités de donnée de protocole" ou "pdu" (pour "protocol data unit", selon la terminologie anglo-saxonne) comportant une référence de destination et une référence de source. On pourrait également appeler cette "pdu" particulière "SmartTP pdu",en référence au terme anglais "Smart Card" (carte à puce) couramment utilisé. Les "pdu" utilisent notamment les références définies ci-dessus.
  • Une "SmartTP pdu", ou plus simplement "pdu" ci-après, comporte une référence source, une référence de destination, un ensemble de bits constituant des drapeaux ou "flags" qui précisent la nature de la "pdu", et des données optionnelles :
    • le drapeau "OPEN" (ouvert) est positionné pour indiquer l'ouverture d'une session ;
    • le drapeau "CLOSE" (fermé) indique la fermeture d'une session ; et
    • Le drapeau "BLOCK" (verrouillé) indique que l'agent est en attente d'une réponse de son correspondant et suspend toute activité.
  • On appellera jeton une "pdu" qui ne comporte pas de données.
  • L'entité "SmartTP" contrôle l'existence de l'agent destinataire et réalise la commutation d'un paquet vers ce dernier.
  • Une session agent "S-Agent" possède trois états remarquables, à savoir:
    • un état déconnecté : aucune session n'est ouverte avec un autre agent ;
    • un état connecté : une session est ouverte avec un autre agent, une session "S-Agent" étant identifiée par une paire de références ; et
    • un état bloqué, l'agent étant connecté et attendant une réponse de son correspondant.
  • Le mécanisme d'établissement d'une session "S-Agent" est le suivant :
    • une nouvelle instance d'un agent client est créée (côté carte à puce ou terminal), cet agent étant identifié par une référence éphémère pseudo-unique ;
    • l'agent client émet une "pdu" à destination d'un agent serveur (dont la référence est connue par ailleurs) avec le drapeau "OPEN" positionné et l'agent client passe à l'état connecté ou bloqué selon la valeur du drapeau "BLOCK" ; et
    • l'agent serveur reçoit la "pdu" avec le drapeau "OPEN" et passe à l'état connecté
  • Une fois une session ouverte, deux agents échangent des données via des "pdu".
  • Le mécanisme de fermeture d'une session est le suivant :
    • un agent émet une "pdu" avec le drapeau "CLOSE" positionné (et qui comporte éventuellement des données) ; et
    • l'autre agent reçoit une "pdu" avec le drapeau "CLOSE" positionné (et qui comporte éventuellement des données) et la session "S-Agent" passe à l'état déconnecté.
  • La figure 3 illustre de façon schématique le diagramme d'états des sessions "S-Agent", telles qu'elles viennent d'être rappelées.
  • Les couches 130 et 230a gèrent des tables (non représentées) qui contiennent la liste des agents présents, côté terminal hôte 1 et carte à puce 2a.
  • De façon pratique, les agents permettent d'échanger des données (de l'hypertexte, par exemple), mais également de déclencher des transactions réseau.
  • Les modules de gestion de configuration, 131 et 231a, respectivement, sont assimilables à des agents particuliers. Par exemple, le module 131, côté terminal hôte 1, gère notamment des informations relatives à la configuration de ce terminal (modes de fonctionnement), liste des autres agents présents, etc. Le module 231a, côté carte à puce 2a, a des fonctions analogues. Ces deux agents peuvent être mis en communication l'un avec l'autre pour établir une session.
  • Selon une première caractéristique de l'invention, la carte à puce 2a se comporte comme un client/senreur "WEB".
  • De façon pratique, la carte à puce 2a est avantageusement "adressée" par utilisation d'une adresse "URL" (pour "Universal Resource Locator") définissant un rebouclage sur le terminal 1 lui-même, et non un pointage sur un serveur externe. A titre d'exemple, la structure de cette "URL" est habituellement la suivante :
    http://127.0.0.1:8080   (1),
    dans laquelle 127.0.0.1 est l'adresse "IP" de rebouclage et 8080 est le numéro de port.
  • La figure 4 illustre de façon simplifiée l'architecture logique d'un système selon l'invention du type représenté sur la figure 2, mais représenté de façon plus détaillée. La carte à puce 2a comprend plusieurs agents, dont deux seulement ont été représentés : un agent 232a 1, de type dit "WEB", et un agent de type non précisément défini 232a 2. La pile logique comprend les couches de protocole inférieures, référencées 200a, répondant aux normes ISO 7816-3 (figure 2 : CCa 1 et CCa 2), le gestionnaire de commandes "APDU" 201a 1, et le multiplexeur de paquets 230a, ce dernier étant interfacé aux agents, notamment l'agent "WEB" 231a 1.
  • Du côté terminal, il existe deux piles, l'une communiquant avec le réseau Internet RI, l'autre avec la carte à puce 2a. La première pile comprend les organes 11 (figure 2 : C1 et C2) d'accès au réseau (normes OSI 1 et 2) et les couches de protocole "TCP/IP" (figure 2 : C3 et C4), référencées 100. Ces dernières couches sont interfacées avec le navigateur "WEB" 10. L'autre pile comprend les couches de protocole inférieures, référencées 101, répondant aux normes ISO 7816-3 (figure 2 : C1 et C2), le gestionnaire 102 d'ordres "APDU" et le multiplexeur de paquets 130, ce dernier étant interfacé avec des agents, dont un seul 132, est représenté. Ce dernier, que l'on supposera de "type réseau", peut en outre communiquer, d'une part avec le navigateur 10, via les couches "TCP/IP" 100, d'autre part avec le réseau Internet RI, via ces mêmes couches "TCP/IP" 100 et l'organe 11, d'accès au réseau RI.
  • Le gestionnaire d'ordres "APDU" 201a est également interfacé avec une ou plusieurs couches de niveau applications, que l'on appellera simplement applications. Ces applications, A 1, ..., A i, ..., A n, sont, comme il a été indiqué, des applications de type conventionnel, que l'on a appelé "cardlet".
  • En résumé, la fonction client/serveur "WEB", fournie par la carte à puce 2a, peut être réalisée par l'association de l'agent "WEB" 232a 1 dans la carte à puce et de l'agent réseau 132 dans le terminal 1, et par la mise en oeuvre de sessions entre agents, comme il a été décrit.
  • La carte à puce 2a présente donc bien la fonctionnalité client/serveur "WEB". En outre, selon une caractéristique du procédé de l'invention, n'importe quelle application conventionnelle, A 1 à A n , du type "GCA" précité, peut être activée au travers de ce client/serveur "WEB", soit par le navigateur "WEB" 10 présent dans le terminal 1, soit par un navigateur éloigné 4, localisé en un point quelconque du réseau Internet RI, par la mise en oeuvre de sessions entre agents. Selon le procédé de l'invention, les applications, A 1 à A n , ne nécessitent pas d'être ré-écrites et sont mises en oeuvre telles quelles.
  • Selon un autre aspect de l'invention, en mettant en oeuvre le mécanisme d'agents qui vient d'être décrit, on implante directement sur la carte à puce 2a une fonction dite de "proxy TCP/IP". Cette fonction est réalisée par une application logicielle particulière que l'on appellera "filtre "ci-après.
  • La fonctionnalité "proxy" est bien connue dans le domaine des applications Internet, mais ne peut être implantée dans les cartes à puce des systèmes selon l'art connu.
  • Avant de décrire une architecture conforme à l'invention, on va tout d'abord rappeler brièvement les caractéristiques d'un "proxy" classique selon l'art connu, par référence à la figure 5.
  • Dans la technologie "TCP/IP", on nomme "proxy" une entité logicielle Py qui réalise, d'une part, un serveur "TCP/IP" Sv et, d'autre part, un client "TCP/IP" Cl. L'entité logicielle Py réalise une connexion entre un client local et un autre serveur TCP/IP distant.
  • Un proxy Py réalise usuellement des fonctions de filtre et/ou de sécurité. Par exemple, un proxy "http" assure généralement la connexion d'un navigateur, par exemple le navigateur 10 du terminal 1, à un serveur "WEB" 4, dans une entreprise (ce qui est connu sous la dénomination "firewall" ou "pare-feu"). Il peut s'agir également d'un proxy dit "SSL", que l'on peut définir comme étant un "proxy" local au terminal, qui réalise des opérations de sécurité nécessaires (authentification - confidentialité - intégrité) à l'établissement d'un tunnel sécurisé au travers du réseau Internet RI.
  • On va maintenant décrire une architecture logicielle intégrant la fonction "proxy " directement dans une carte à puce, selon un aspect supplémentaire de l'invention, par référence à la figure 6.
  • Les éléments communs aux figures précédentes portent les mêmes références et ne seront re-décrits qu'en tant que de besoin. Pour simplifier la description, les agents, côté terminal 1 sont regroupés sous la référence unique 132, et côté carte à puce 2a, sous la référence unique 232a. Ils seront différenciés dans ce qui suit par la lettre "T", pour "terminal", et "S" pour "Smart Card" (carte à puce), lettres associées à des chiffres en indice. Le "proxy" 27 réalisé sur la carte à puce 2a sera appelé "Smart Proxy" dans ce qui suit.
  • Le "Smart Proxy" 27 est réalisé par l'association de quatre agents, deux côté terminal 1 : T1 et T2, et deux côté carte à puce 2a : S1 et S2, et d'une fonction filtre 28, comme décrit ci-après :
    • un agent "Terminal/Client/Réseau" T1 réalise un serveur TCP/IP (par exemple sur le port 8080) ;
    • un agent "Carte/Serveur/local" S1 est associé par une session à l'agent T1, cet agent réalisant typiquement les fonctions d'un serveur "WEB" ;
    • une fonction filtre 28 qui est déterminée en fonction d'informations en provenance de l'agent T1, cette dernière fonction étant en mesure d'émettre ou de recevoir des "pdu" vers/depuis les agents S1 et S2 ;
    • un agent S2 "Carte/Client/Local", une instance de cet agent étant créée de manière dynamique par la fonction filtre 28 et S2 ouvrant une session avec l'agent "réseau" T2, auquel il indiquera l'adresse du serveur distant Internet 4 auquel S2 veut être relié ; et
    • un agent T2 "Terminal/Serveur/Réseau" réalise la fonction d'un client "TCP/IP", qui est connecté à un serveur Internet 4.
  • Le mécanisme de création du "Smart Proxy" 27 est décrit ci-dessous.
  • Un client "TCP", que l'on appellera ci-après "cTCP", typiquement le navigateur "WEB" 10, ouvre une connexion avec l'agent "réseau" T1. Une session T1-S1 est ensuite créée. Par exemple l'URL suivante :
    http://127.0.0.1:8080/?des1=xxx.com:80/yyy/content.html   (2)
    provoque l'ouverture d'une session entre les agents T1 et S1.
  • A partir des données échangées par T1 et S1, l'application associée à l'agent S1 (un serveur WEB) détermine quelle fonction filtre 28 doit être utilisée. Ainsi "des1" est le nom d'un filtre particulier, "xxx.com" est le nom arbitraire d'un serveur Internet, par exemple du serveur 4, "80" un numéro de port et "/yyy/content.html" est le nom arbitraire d'un fichier sur ce serveur, constitué dans l'exemple par une page en langage "HTML". Dans l'exemple, le filtre "des1" est un filtre permettant de réaliser une opération de déchiffrage et/ou de chiffrage selon un algorithme de type "DES" ("Data Encryption Standard").
  • En d'autres termes, l'URL "carte" (2) encapsule une autre URL destinée au monde extérieur, la première partie de cette URL étant constituée par l'URL de rebouclage tel que défini par la relation (1).
  • Le filtre 28 "des1 "crée une instance de client S2 ; une session est ouverte entre les agents S2 et T2. Les données insérées dans la première "pdu" ("pdu OPEN") précisent le nom du serveur Internet ("xxx.com") et son numéro de port associé (80).
  • L'agent T2 ouvre une connexion de type "TCP" avec le serveur distant "sTCP" ("zzz.com"). Une fois que cette dernière est établie, un jeton est émis à destination de S2.
  • Au terme de ces échanges, un "Smart Proxy" 27 a été créé, une fonction filtre 28 qui réside dans la carte à puce 2a est en mesure de traiter les données (en provenance du réseau Internet RI) reçues par les agents "réseau". Le filtre 28 contrôle les données émises par les agents "réseau", T1 et T2, de manière logique. Il se comporte comme un "proxy TCP" qui contrôle les données échangées entre le client "cTCP" et le serveur "sTCP".
  • Pour fixer les idées, on a représenté sur la figure 6 des numéros de référence arbitraires des différents agents : fixes, "2" et "5", pour les agents de type "serveur", respectivement T2 et S1, et variables ou éphémères, "15360" et "2559", pour les agents de type "client", respectivement T1 et S2,
  • On va maintenant décrire plus précisément des exemples particuliers de filtres 28.
    • Exemple N° 1 : filtre de redirection
  • Un filtre de redirection associe à une URL carte, par exemple l'URL suivante :
    (http//127.0.0.1:8080/eMail)   (3)
    une requête "http" vers un serveur externe (par exemple www.email.com) qui peut servir par exemple à poster, par utilisation de la méthode bien connue "POST http", des données d'identification : "login" et mot de passe par exemple, associées à un serveur de courrier gratuit "email". Le filtre peut également assurer une identification/authentification du bénéficiaire du service par des méthodes plus sûres à base de challenge (ces méthodes sont décrites, par exemple, dans la norme "http 1.1 ")
  • La mise en oeuvre d'un filtre de redirection comprend typiquement les étapes suivantes :
    1. 1. le navigateur 10 ouvre une connexion avec l'agent "réseau" T1 (adresse IP : 127.0.0.1:8080) et la session T1-S1 est ouverte avec le serveur "WEB" de la carte 2a ;
    2. 2. la requête "http" (selon la recommandation "http 1.1 rfc 2068") est transmise depuis le navigateur 10 à destination de l'agent "WEB" S1 et celui-ci détecte, à partir du nom du fichier "/eMail", l'appel à un filtre 28, de redirection dans ce cas particulier : à partir de cet instant, toutes les données reçues par l'agent "réseau" T1 sont traitées par ce filtre particulier 28 ;
    3. 3. une instance d'agent client S2 est créée par le filtre 28 ;
    4. 4. S2 ouvre une session avec l'agent "réseau" T2 et la première "pdu" émise (drapeau "OPEN" positionné) comporte l'adresse et le port du serveur "WEB" distant 4 ("www.email.com" dans l'exemple) ;
    5. 5. l'agent T2 ouvre une connexion avec le serveur "WEB" distant 4 et, après ouverture, un jeton est émis vers l'agent S2;
    6. 6. l'agent S2 transmet une requête "http" vers le serveur "WEB" distant 4 ;
    7. 7. ce serveur 4 transmet typiquement un en-tête de redirection "http" qui notifie le succès de l'opération et fournit au navigateur 10 une nouvelle "URL" de connexion et une pièce de logiciel, connue sous le nom de "cookie", qu'il doit utiliser ;
    8. 8. la fonction filtre 28 n'effectue aucun traitement sur ces données ; et
    9. 9. les données sont transmises au navigateur "WEB" 10 par la session S1-T1.
  • Lorsque le navigateur 10 reçoit l'en-tête de redirection, il se connecte au serveur de courrier 4 avec le "cookie" approprié. Il reçoit typiquement en retour une page d'accueil écrite en langage "HTML".
    • Exemple N° 2 : filtre "http - des"
  • On va maintenant considérer le cas d'une page "HTML" encodée par un algorithme du type "DES" précité. Cette page nommée, par exemple, "/yyy/content.html" est logée sur un serveur "WEB" 4 : "zzz.com:80". Une fonction filtre 28 localisée dans la carte (de nom arbitraire "?des1") va réaliser un algorithme de déchiffrement, c'est-à-dire une fonction inverse (ou "DES-1"), ce avec une clé associée à un index 1.
  • L'URL suivante :
    http://zzz.com/yyy/content.html   (4),
    exécutée depuis un navigateur 10, provoque le chargement du fichier "content.html" depuis le serveur "zzz.com. La page "HTML" étant codée, les balises «html> et </html», utilisées pour marquer, selon les conventions du langage "HTML", le début et la fin du document, n'apparaîtront pas en clair et le navigateur 10 affichera soit des signes incohérents, soit une erreur indiquant qu'une page "HTML" n'a pas été reçue.
  • L'URL suivante :
    http://127.0.0.1:8080/?des1=zzz.com:80/yyy/content.html   (5)
    indique à la carte de charger la page :
    http://zzz.com:80/yyy/content.html   (6)
    à travers un filtre 28 ce type "DES", dont l'index de clé est 1.
  • Le chargement de la page "content.html" s'effectue de la manière suivante :
    1. 1. le navigateur 10 ouvre une connexion avec l'agent "réseau" T1 (adresse IP : 127.0.0.1:8080) et la session T1-S1 est ouverte avec le serveur "WEB" de la carte à puce 2a ;
    2. 2. la requête "http" ("http 1.1 rfc 2068") est transmise depuis le navigateur 10 à destination de l'agent "WEB" S1 et à partir du nom du fichier "/?des1 = zzz.com:80/yyy/content.html", l'agent "WEB" S1 détecte l'appel à une fonction filtre 28 de type "DES" (clé d'index 1) : à partir de cet instant, toutes les données reçues par l'agent "réseau" T1 sont traitées par le filtre 28 de type "DES" associé à la clé d'index 1 ;
    3. 3. une instance d'agent client S2 est crée par le filtre 28 ;
    4. 4. S2 ouvre une session avec l'agent "réseau" T2 : la première "pdu" émise (drapeau "OPEN" positionné) comporte l'adresse et le port du serveur "WEB" distant 4 ("zzz.com").
    5. 5. l'agent T2 ouvre une connexion avec le serveur "WEB" distant 4 et, après ouverture, un jeton est émis vers l'agent S2;
    6. 6. l'agent S2 transmet une requête "http" vers le serveur distant 4 ;
    7. 7. le serveur distant 4 transmet un en-tête "http" qui indique la nature du fichier et transmet le fichier proprement dit : ces données sont relayées à la fonction filtre 28 par la session T2-S2 ;
    8. 8. la fonction filtre 28 n'effectue aucun traitement sur l'en-tête "http" et déchiffre la page "HTML" ; et
    9. 9. les données déchiffrées sont transmises au navigateur "WEB" 10 par la session S1-T1.
  • Le résultat de cette opération est que le navigateur 10 reçoit une page "HTML" décodée. L'opération de redirection peut être automatisée par un script (typiquement en langage "Java Script", marque déposée). Par exemple, un script inclus dans une page "HTML" (que l'on appellera arbitrairement "content.html") redirige l'URL :
    http://zzz.com/yyy/xcontent.html   (7), en
    http://127.0.0.1:8080/?des1 =zzz.com/yyy/content.html   (8), xcontent.html et content.html étant les noms arbitraires de deux pages "HTML".
    • Exemple N° 3 : filtre "SSL"
  • Le protocole dit "Secure Socket Layer" ou "SSL" est largement utilisé pour les applications de type "WEB". Il permet d'ouvrir des "tunnels sécurisés" entre un client (typiquement le navigateur 10) et un serveur. "SSL" permet d'authentifier le serveur et d'assurer la confidentialité et l'intégrité des données échangées. Pour ce faire, un secret partagé est construit à partir d'une clé dite publique, propre au serveur. Une clé de session est déduite du secret partagé et assure, par exemple, le chiffrement de l'information à l'aide d'un algorithme de type "triple DES". Comme il est bien connu en soi, on utilise également une technique mettant en oeuvre des "certificats" d'authentification.
  • L'intérêt de la réalisation d'un filtre "SSL" directement dans la carte à puce 2a est que la vérification du certificat de la clé publique du serveur (ce qui constitue le point essentiel des systèmes à clés publiques) est effectuée par la carte à puce et non par un logiciel résidant dans le terminal, a priori jugé peut sûr. De manière classique, une fois qu'une session "SSL" est ouverte, un utilisateur ou "internaute" (non représenté) fournit des données d'identification personnelle, classiquement l'association d'un "login" et d'un mot de passe, qui sont entrés en clair sur le terminal 1, à l'aide d'un clavier (figure 1 A : 6a). Un autre avantage d'une session "SSL" menée à partir de la carte à puce 2a est que le "login" et le mot de passe sont fournis par la carte à puce 2a et non par l'utilisateur.
  • Une connexion "SSL" se déroule de la manière suivante :
  • On va maintenant considérer une page "HTML" que l'on désire obtenir par une session "SSL". Cette page nommée par exemple "/yyy /content.html" est logée sur un serveur distant WEB 4 (de nom arbitraire "www.bank.com"). Une fonction filtre particulière 28 localisée dans la carte (appelée arbitrairement "?ssl1") réalise le protocole SSL et utilise un login et un mot de passe associé à un index 1.
  • L'URL suivante :
    http://127.0.0.1:8080/?ssl1=www.bank.com:80/yyy/content.html   (9)
    indique à la carte à puce 2a de charger la page "/yyy /content.html" en faisant appel au protocole "SSL".
  • Le chargement de la page "content.html" s'effectue de la manière suivante :
    1. 1. le navigateur 10 ouvre une connexion avec l'agent "réseau" T1 (adresse IP: 127.0.0.1:8080) et la session T1-S1 est ouverte avec le serveur WEB de la carte à puce 2a ;
    2. 2. la requête "http" (conforme à "http 1.1 rfc 2068") est transmise depuis le navigateur 10 à destination de l'agent "WEB" S1 et à partir du nom du fichier "/?ssl1 = www.bank.com:80/yyy /content.html", et l'agent "WEB" S1 détecte l'appel d'une fonction filtre 28 particulière du type "SSL" (avec des clés d'index 1) : à partir de cet instant, toutes les données reçues par l'agent "réseau" T1 sont traitées par le filtre "SSL" 28 ;
    3. 3. une instance d'agent client S2 est créée par le filtre 28 ;
    4. 4. S2 ouvre une session avec l'agent "réseau" T2 et la première "pdu" émise (drapeau "OPEN" positionné) comporte l'adresse et le port (N° 443 dans cet exemple) du serveur "WEB SSL" distant ("www.bank.com:443").
    5. 5. l'agent T2 ouvre une connexion avec le serveur "WEB" distant 4 et, après ouverture, un jeton est émis vers l'agent S2 ;
    6. 6. le filtre 28 entame une négociation conforme au protocole "SSL" avec le serveur distant 4, au moyen de la session T2-S2 ;
    7. 7. lorsqu'une session "SSL" est ouverte, le "login" et le mot de passe sont transmis par le filtre 28 au serveur distant 4 et la session T2-S2 est fermée
    8. 8. une nouvelle session : S2-T2 est ouverte par le filtre 28 ;.
    9. 9. le filtre 28 négocie la reprise de la session "SSL" précédente ;
    10. 10. L'agent S2 transmet une requête "http" chiffrée d'obtention du fichier "content.html" vers le serveur distant 4 ;
    11. 11. le serveur distant 4 transmet un en-tête "http" qui indique la nature du fichier et transmet le fichier proprement dit : ces données sont relayées à la fonction filtre 28 par la session S2-T2 ;
    12. 12. la fonction filtre 28 décode les données reçues et vérifie leur intégrité ; et
    13. 13. les données déchiffrées sont transmises au navigateur "WEB" 10 par la session S1-T1.
  • Le résultat de cette opération est que le navigateur 10 reçoit une page "HTML" décodée. L'opération de redirection peut être automatisée par un script (typiquement un "Java Script"). Par exemple, un script inclus dans une page "HTML" redirige l'URL :
    http://I27.0.0.1:8080/?ssl1 =www.bank.com/yyy/content.html   (10), en
    http://www.bank.com/-yyy /xcontent.html   (11).
  • On va maintenant décrire un aspect supplémentaire de l'invention qui va permettre notamment de traiter des flux de données multimédias selon un protocole de communication dissymétrique.
  • Lorsque le terminal 1 obtient des données multimédias, par exemple depuis le réseau Internet RI, ces données perdent tout caractère de confidentialité et sont mémorisées par un système généralement peu sûr.
  • Un "Smart Proxy", réalisé selon l'une des caractéristiques de l'invention, constitue alors un dispositif clé pour l'identification et l'authentification du bénéficiaire d'un service particulier. Les algorithmes et les clés sont stockés et exécutés à l'intérieur de la carte à puce 2a. Une fois qu'un filtre particulier 28 a ouvert une connexion "TCP" avec un serveur distant 4, deux cas peuvent être envisagés :
    • A/ des clés fixes et secrètes sont utilisées pour assurer l'intégrité et la confidentialité des données : dans ce cas, le flux de données est déchiffré et vérifié par le filtre du "Smart Proxy" ; ou
    • B/ des clés éphémères, encore nommées "clés de session" sont calculées lorsque qu'une connexion est ouverte avec succès entre le filtre 28 et le serveur distant 4 : le deuxième cas se rencontre dans de nombreux protocoles de sécurité utilisés pour le réseau Internet, comme par exemple le protocole "SSL" précité ou le protocole "IPSEC".
  • Lorsque des clés de session éphémères sont utilisées, le calcul des algorithmes par la carte à puce 2a ne présente pas d'intérêt particulier puisque de toute façon ces clés ne seront utilisées qu'une seule fois et que leur seul but est de permettre le transfert en clair de données sur un terminal peu sûr.
  • Parfois, la connexion avec le serveur 4 est dissymétrique du point de vue de la sécurité. Une procédure d'identification et d'authentification est secrète, alors que les données échangées par la suite ne présentent aucun caractère confidentiel. On voit donc apparaître la notion de flux de données que l'on appellera ci-après "critique", le "flux critique" représentant des données qui doivent être traitées par le "Smart Proxy" de manière secrète. Des clés de session éphémères (parfois variables au cours d'une même connexion) peuvent être déduites du flux critique, et être mises en oeuvre par le terminal 1 sans mesure particulière de sécurité.
  • On distinguera donc ci-après le flux critique, qui désigne le flux de données qui doit être traité par le "Smart Proxy", d'un flux de données dit "opaque" qui peut être traité sur un terminal non sûr.
  • Dans ce contexte, des "pdu" ("pdu" de commandes) identifiées par une valeur particulière du champ drapeau permettent de transmettre des commandes aux agents. Ces commandes sont traitées par l'agent adressé proprement dit et ne sont pas transmises vers un autre agent ou sur le réseau RI.
  • Toujours dans ce contexte, bien que le mécanisme des agents propre à l'invention soit mis en oeuvre, des échanges de données peuvent avoir lieu hors session.
  • Deux agents peuvent en effet échanger une certaine quantité de données sans être connectés via une session. Une "pdu" de commande particulière indique à un premier agent, arbitrairement appelé A1, la quantité de données Q1 à émettre (hors champs référence source, référence destination et drapeau), et une autre "pdu" indique à un deuxième agent, arbitrairement appelé A2, la quantité de données Q2 émises depuis l'agent A1 et qu'il est autorisé à recevoir. Les "pdu" qui comportent le drapeau "CLOSE" ne sont pas transmises hors session.
  • Les cheminements des flux critique et opaque sont respectivement les suivants :
  • Le flux critique contient des informations secrètes qui doivent être traitées par le filtre 28 associé au "Smart Proxy" et doivent donc transiter obligatoirement par la carte à puce 2a. Le flux opaque peut être traité uniquement par des agents localisés sur le terminal 1, en utilisant un mécanisme d'échange de données hors session, par exemple.
  • Le flux opaque peut être sécurisé par le flux critique.
  • En effet, un flux global de donnés peut se décomposer généralement en un flux critique et en un flux opaque, ce qui permet, par exemple, de déchiffrer un flux de fort débit (par exemple représentant des données multimédias proprement dites) par un flux critique de plus faible amplitude.
  • Les dispositions propres à l'invention permettent de traiter un tel flux de données multimédia à fort débit en organisant des protocoles de communication et de traitement de données dissymétriques.
    • Exemple N° 4 : filtre de redirection dissymétrique
  • Un filtre de redirection dissymétrique associe, à une URL "carte" du type :
    http//127.0.0.1:8080/?f1=/www.host.com/unFichier   (12),
    une requête "http" vers un serveur externe 4, par exemple :
    http://www.host.com/unFichier   (13)
  • La connexion au serveur 4, qui comporte une phase d'identification et d'authentification (mécanisme à base de "challenge" par exemple), est gérée par le filtre 28, que l'on appellera arbitrairement "?f1", associé au "Smart Proxy" 27. Le filtre 28 est dit dissymétrique car, une fois l'authentification réalisée, les données échangées avec le serveur 4 ne sont pas chiffrées et ne transitent plus par le filtre 28.
  • Les étapes de mise en oeuvre d'un filtre de redirection dissymétrique 28, illustrées schématiquement par le diagramme de la figure 7 (qui reprend, de façon simplifiée l'architecture selon l'invention du système de la figure 6), sont les suivantes :
    1. 1. le navigateur 10 ouvre une connexion avec l'agent "réseau" T1 (adresse IP : 127.0.0.1:8080) ; la session T1-S1 est ouverte avec le serveur WEB de la carte à puce 2a ;
    2. 2. une requête "http" est transmise par le navigateur 10 à destination de l'agent "WEB" S1 et, à partir du nom du fichier "/?f1 =/www.host.com/unFichier", l'agent "WEB" S1 détecte l'appel à un filtre de redirection particulier 28 ("?f1") : à partir de cet instant, toutes les données reçues par l'agent "réseau" T1 sont traitées par ce filtre 28 ;
    3. 3. une instance d'agent client S2 est créée par le filtre 28 ;
    4. 4. S2 ouvre une session avec l'agent "réseau" T2 : la première "pdu" émise (drapeau "OPEN" positionné) comporte l'adresse et le port du serveur WEB distant 4 ("www.host.com") ;
    5. 5. l'agent T2 ouvre une connexion avec le serveur "WEB" distant 4 et, après ouverture, un jeton est émis vers l'agent S2 ;
    6. 6. une procédure d'authentification se produit entre le filtre 28 "?f1" et le serveur distant 4, et des données sont échangées par la session S2-T2 ;
    7. 7. si cette procédure aboutit, le filtre 28 envoie une "pdu" de commande à l'agent T1 qui l'autorise à recevoir toutes les données émises hors session par l'agent T2, et envoie une "pdu" de commande à l'agent "réseau" T2 qui lui indique de transmettre toutes les données reçues du réseau vers l'agent T1 : les données en provenance du serveur distant 4 sont relayées, via les agents T2 et T1, vers le navigateur 10 et donc ne traversent plus la carte à puce 2a ; et
    8. 8. Lorsqu'une déconnexion "TCP" se produit (sous la commande du serveur 4) l'un des agents, T1 ou T2, émet une "pdu" avec un drapeau à l'état "CLOSE" vers l'un des agents S1 ou S2, et le filtre 28 supervise alors l'abandon des sessions T1-S1 et T2-S2.
    Exemple N° 5 : filtre "SSL" dissymétrique
  • Cet exemple est illustré schématiquement par le diagramme de la figure 8, qui reprend de façon simplifiée l'essentiel de l'architecture selon l'invention du système de la figure 6.
  • Comme il a été décrit précédemment dans l'exemple N° 3, un filtre "SSL" peut être activé au moyen d'une URL "carte" (par exemple celle de la relation (11)). Dans un tel protocole, le flux de données critiques est utilisé pour sélectionner une paire d'entités qui comprend un algorithme de chiffrement et une fonction dite de hachage (ou "hash" selon la terminologie anglo-saxonne) à sens unique, ainsi qu'un certain nombre de paramètres associés (clés et valeur courante de la fonction de "hash"). Une fois une phase de négociation terminée, l'exécution de ces algorithmes dans la carte à puce 2a ne présente pas d'intérêt particulier, puisque les données sont dirigées en clair depuis le réseau Internet RI vers le terminal 1.
  • On peut donc utiliser avantageusement un agent supplémentaire T3 (de type serveur) auquel est dévolue une fonction "SSL". Cet agent T3 est localisé dans le terminal 1. Une fois que les paramètres de la session "SSL" ont été négociés, le filtre "SSL" 28 ouvre une session entre un agent client supplémentaire S3 (côté carte à puce 2a) et l'agent serveur "SSL" T3 (côté terminal). Lors de l'ouverture de la session, l'agent T3 est initialisé avec des valeurs de clés "DES" et des paramètres en cours de la fonction de "hash". Le filtre "SSL" 28 envoie une "pdu" de commande à l'agent T2, qui lui permet de retransmettre vers le réseau RI les données émises hors session par T3, et de rediriger les données reçues du réseau vers T3. Le filtre "SSL" 28 envoie une "pdu" de commande à l'agent T3 pour lui permettre de recevoir, hors session, les données émises par T1 et T2. Le filtre "SSL" envoie une "pdu" de commande à l'agent T1, qui lui permet de retransmettre vers le réseau RI les données émises hors session par T3, et de rediriger les données reçues de ce réseau RI vers T3. Un "tunnel" hors session est alors établi dans le terminal 1, entre T1-T2-T3. Lorsqu'un agent T1 ou T2 ferme la session qui lui est associée, le filtre 28 procède à la fermeture des deux autres sessions restantes.
    • Filtre dissymétrique, cas général
  • De manière plus générale, et en se reportant de nouveau à l'un ou l'autre des diagrammes des figures 7 ou 8, les étapes de la procédure mettant en oeuvre un filtre dissymétrique 28 sont les suivantes :
  • Un "Smart Proxy" 27 (figure 6) est réalisé à partir d'une URL "carte" au moyen de deux sessions T1-S1 et T2-S2. Le filtre particulier à réaliser 28 est déterminé à partir de cette URL. Dans un premier temps, le filtre 28 contrôle le flux de donnée entre le client "TCP" (navigateur 10) et le serveur distant 4. A la fin d'une phase d'authentification et de négociation, un jeu de paramètres de sécurité est obtenu. Il consiste en un flux de données critique.
  • Le filtre 28 ouvre alors une session avec un agent de sécurité (T3, par exemple) qui réalise le protocole négocié avec un jeu de paramètres définis par le filtre 28 lors de l'ouverture de la session. Le filtre 28 crée un "tunnel" de transfert de données hors session T1-T2-T3. Par exemple, une quantité prédéterminée de données est transmise hors bande par la chaîne T1-T2-T3. En d'autres termes, le flux de données opaques est traité par l'ensemble T1-T2-T3, et ne transite donc pas par la carte à puce 2a. Les données critiques peuvent être identifiées par diverses méthodes: longueur de données opaques fixée périodiquement, marques dans un paquet "TCP" au moyen d'un pointeur de données urgentes, etc. Ces méthodes sont connues en soi. Les données critiques, contrairement aux données opaques, sont transmises par des agents du terminal 1, T1 ou T2, au filtre 28. Ce dernier modifie en conséquence, au moyen d'une "pdu" de commande, les paramètres fonctionnels de l'agent T3. Lorsqu'un agent du terminal 1, T1 ou T2, ferme la session qui lui est associée, le filtre 28 procède à la fermeture des deux autres sessions restantes.
  • De façon générale également, le flux de données opaques, en dehors de tout aspect lié à la sécurité, peut subir diverses transformations, effectuées par exemple par un agent supplémentaire, similaire à l'agent T3. Le terme "sécurité" doit être compris dans son acceptation la plus générale : confidentialité, autorisation, scellement ou signature, notamment par utilisation de "certificats", etc.
  • Dans ce cas, comme précédemment, le filtre 28 peut modifier en conséquence les paramètres de l'agent T3, par utilisation d'une "pdu" particulière.
  • Pour fixer les idées, et à titre d'exemple non limitatif, il peut s'agir d'une conversion de format. Dans le cas de données audio, des données opaques, par exemple transmises codées selon le format "mp3", pourront être converties au format "wav" ou tout autre format accepté par le terminal 1. De même pour des données vidéo, des données opaques reçues au format "MPEG" pourront être converties au format "avi" ou tout autre format accepté par le terminal 1.
  • Dans tous les cas, seul un flux de données de faible volume et de faible débit, constituant les données dites critiques, transite par la carte à puce 2a. Seules ces données sont nécessaires pour sélectionner un filtre approprié qui contrôlera ensuite le transit des données du flux opaque dans le terminal et leur traitement, via les agents T1 et T2 et éventuellement T3.
  • En d'autres termes, grâce aux dispositions propres à l'invention, transformant la carte à puce en client/serveur "WEB", d'une part, et permettant de réaliser un "proxy" directement dans celle-ci, d'autre part, la carte à puce devient capable de déléguer le traitement d'un flux d'informations, dont la quantité est fixée, au terminal auquel elle est connectée. Il s'ensuit que des flux globaux, présentant un très fort débit, peuvent tout de même être traités par un terminal à carte à puce, grâce à la mise en oeuvre de protocoles de communication dissymétriques, ce tout en conservant un degré maximal de sécurisation. Ce fort degré de sécurisation est dû au fait que les opérations essentielles de chiffrement et/ou d'authentification restent sous le contrôle exclusif de la carte à puce, les données dites critiques transitant par celle-ci.
  • A la lecture de ce qui précède, on constate aisément que l'invention atteint bien les buts qu'elle s'est fixés.
  • Il doit être clair cependant que l'invention n'est pas limitée aux seuls exemples de réalisations explicitement décrits, notamment en relation avec les figures 2 à 4, d'une part, et 6 à 8, d'autre part.
  • Il doit être clair également que le processus décrit est réversible : les transmissions entre un serveur et le terminal peuvent s'effectuer dans les deux sens. En effet, ce dernier peut aussi transmettre un fichier à haut débit au serveur distant, toujours sous le contrôle de la carte à puce. Dans ce cas, les données dites critiques sont fournies à la carte à puce par le terminal, après une phase éventuelles de négociation avec le serveur distant.
  • Enfin, bien que le procédé ait été décrit de façon détaillée dans le cas de la transmission d'un flux de données multimédias sécurisées à haut débit, le procédé selon l'invention, comme il a été précédemment indiqué, n'est en aucun cas limité à cette application particulière.
  • L'invention concerne aussi un procédé de transmission d'un flux de données, via un réseau de type Internet, entre au moins un serveur distant et un terminal muni d'un lecteur de carte à puce, ledit terminal comprenant des moyens de traitement d'information et des moyens de stockage d'information, les moyens de stockage d'information contenant au moins une application de type dit "client TCP/IP", la carte à puce comprenant des moyens de traitement d'information et des moyens de stockage d'information, ledit terminal et ledit serveur étant tous deux connectés au dit réseau de type Internet, caractérisé en ce qu'il comprend au moins les phases suivantes :
    • a/ une première phase consistant à implanter, dans les moyens de stockage d'information de ladite carte à puce (2a), une première pièce de logiciel (23a), formant une couche protocolaire de communication spécifique ;
    • b/ une deuxième phase consistant à implanter, dans les moyens de stockage d'information dudit terminal (1), une seconde pièce de logiciel (13), formant une couche protocolaire de communication spécifique et formant interface avec au moins ladite application de type "TCP/IP" (10) ;
      • en ce que lesdites première et seconde pièces de logiciel (13, 23a) comprennent chacune en outre au moins une première entité logicielle autonome (T2, S1), de type dit client, et une deuxième entité logicielle autonome (T1, S2), de type dit serveur, lesdites entités (T1, S1, T2, S2) coopérant, grâce auxdits moyens de traitement d'information du terminal et de la carte à puce, de manière à permettre l'établissement de sessions d'échanges de données bidirectionnels entre ledit terminal (1) et ladite carte à puce (2a) et de manière à ce que ladite carte à puce (2a) offre les fonctionnalités d'un client/serveur de type "WEB", et à permettre l'établissement d'une session d'échanges de données bidirectionnels entre ledit terminal (1) et un desdits serveurs distants (4), via ledit réseau de type Internet (RI), lesdites entités logicielles autonomes communiquant au moyen d'unités de données de protocole prédéterminées ;
      • en ce qu'il comprend une phase de réalisation, dans les moyens de stockage d'information de ladite carte à puce (2a), d'une pièce de logiciel applicative de caractéristiques fonctionnelles déterminées, dite « filtre » (28), recevant et/ou émettant des unités de données de protocole vers lesdites et/ou à partir desdites première et deuxième entités logicielles autonomes (S2, S1), de types respectifs client et serveur, comprises dans ladite seconde pièce de logiciel spécifique (23a), la réalisation de ladite pièce applicative étant sous le contrôle de ladite entité logicielle autonome de type serveur (S1) ;
      • et en ce que ledit filtre (28) coopère avec lesdites entités logicielles autonomes (S2, S1) de ladite seconde pièce de logiciel spécifique (23a), grâce auxdits moyens de traitement d'information de la carte à puce, pour ouvrir une session avec lesdites entités logicielles autonomes (T2, T1) de ladite première pièce de logiciel spécifique (13), pour modifier des caractéristiques prédéterminées dudit flux de données transmis entre ledit terminal (1) et ledit serveur distant (4).

Claims (17)

  1. Procédé de transmission d'un flux de données, via un réseau de type Internet, entre au moins un serveur distant et un terminal muni d'un lecteur de carte à puce, ledit terminal comprenant au moins une application de type dit "client TCP/IP", ledit terminal et ledit serveur étant tous deux connectés au dit réseau de type Internet, caractérisé en ce qu'il comprend au moins les phases suivantes :
    a/ une première phase consistant à implanter, dans ladite carte à puce (2a), une première pièce de logiciel (23a), formant une couche protocolaire de communication spécifique ;
    b/ une deuxième phase consistant à implanter, dans ledit terminal (1), une seconde pièce de logiciel (13), formant une couche protocolaire de communication spécifique et formant interface avec au moins ladite application de type "TCP/IP" (10) ;
    - en ce que lesdites première et seconde pièces de logiciel (13, 23a) comprennent chacune en outre au moins une première entité logicielle autonome (T2, S1), de type dit client, et une deuxième entité logicielle autonome (T1, S2), de type dit serveur, lesdites entités (T1, S1, T2, S2) coopérant de manière à permettre l'établissement de sessions d'échanges de données bidirectionnels entre ledit terminal (1) et ladite carte à puce (2a) et de manière à ce que ladite carte à puce (2a) offre les fonctionnalités d'un client/serveur de type "WEB", et à permettre l'établissement d'une session d'échanges de données bidirectionnels entre ledit terminal (1) et un desdits serveurs distants (4), via ledit réseau de type Internet (RI), lesdites entités logicielles autonomes communiquant au moyen d'unités de données de protocole prédéterminées ;
    - en ce qu'il comprend une phase de réalisation, dans ladite carte à puce (2a), d'une pièce de logiciel applicative de caractéristiques fonctionnelles déterminées, dite « filtre » (28), recevant et/ou émettant des unités de données de protocole vers lesdites et/ou à partir desdites première et deuxième entités logicielles autonomes (S2, S1), de types respectifs client et serveur, comprises dans ladite seconde pièce de logiciel spécifique (23a), la réalisation de ladite pièce applicative étant sous le contrôle de ladite entité logicielle autonome de type serveur (S1) ;
    - et en ce que ledit filtre (28) coopère avec lesdites entités logicielles autonomes (S2, S1) de ladite seconde pièce de logiciel spécifique (23a) pour ouvrir une session avec lesdites entités logicielles autonomes (T2, T1) de ladite première pièce de logiciel spécifique (13), pour modifier des caractéristiques prédéterminées dudit flux de données transmis entre ledit terminal (1) et ledit serveur distant (4).
  2. Procédé selon la revendication 1, caractérisé en ce que lesdites entités logicielles autonomes sont constituées par des agents intelligents (T2, T1, S2, S1).
  3. Procédé selon la revendication 2, caractérisé en ce que chacun desdits agents intelligents (T2, T1, S2, S1) est associé à au moins l'une des six propriétés suivantes :
    - "hôte" : agent intelligent localisé dans ledit terminal (1) ;
    - "carte" : agent intelligent localisé dans ladite carte à puce (2a) ;
    - "local" : agent intelligent ne communiquant pas avec ledit réseau (RI) ;
    - "réseau" : agent intelligent communiquant avec ledit réseau (RI) ;
    - "client" : agent intelligent qui initialise une desdites sessions ; et
    - "serveur" : agent intelligent qui reçoit une demande pour une desdites sessions.
  4. Procédé selon la revendication 3, caractérisé en ce que lesdits agents (T2, T1, S2, S1) sont identifiés par des identificateurs comprenant des nombres entiers, en ce que lesdits agents intelligents de type serveur (T2, S1) sont associés à ladite caractéristique "serveur" et sont identifiés par une référence fixe, et en ce que lesdits agents intelligents de type client (T1, S2) sont associés à ladite caractéristique "client" et sont identifiés par une référence variable, changeant d'une desdites sessions à la suivante, des instances desdits agents intelligents de type client étant créées lors de ces sessions.
  5. Procédé selon la revendication 4, caractérisé en ce que lesdites unités de données de protocole comprennent un desdits identificateurs, une entité dite drapeau précisant sa nature, et des données optionnelles échangées entre lesdits agents intelligents (T2, T1, S2, S1).
  6. Procédé selon la revendication 5, caractérisé en ce que lesdits drapeaux peuvent prendre au moins l'un des trois états suivants :
    - "OPEN" (ouvert) indiquant l'ouverture d'une desdites sessions ;
    - "CLOSE" (fermé) indiquant la fermeture d'une desdites sessions ; et
    - "BLOCK" (verrouillé) indiquant qu'un desdits agents intelligents (T2, T1, S2, S1) est en attente d'une réponse d'un agent intelligent correspondant et reste inactif ;
    et en ce que lesdites sessions prennent les trois états suivants :
    - un état dit « déconnecté » lorsqu'aucune session n'est ouverte entre un desdits agents intelligents (T2, T1, S2, S1) et un autre desdits agents intelligents ;
    - un état dit « connecté » lorsqu'une session est ouverte avec un autre desdits agents intelligents (T2, T1, S2, S1), une session étant identifiée par une paire desdits identificateurs ; et
    - un état dit « bloqué » lorsque l'un desdits agents intelligents (T2, T1, S2, S1) est connecté et attend une réponse d'un desdits agents intelligents avec lequel il est connecté.
  7. Procédé selon la revendication 6, caractérisé en ce que les étapes d'établissement d'une desdites sessions entre deux desdits agents intelligents (T2, T1, S2, S1) comprennent les suivantes :
    a/ création d'une nouvelle instance d'un desdits agents intelligents de type client (T1, S2), cet agent intelligent étant identifié par une desdites références variables, dite éphémère ;
    b/ émission d'une desdites unités de données de protocole à destination d'un desdits agents de type serveur (T2, S1), identifié par une référence fixe déterminée, avec un drapeau positionné au dit état "OPEN";
    c/ passage dudit agent intelligent de type client (T1, S2) à l'état connecté ou bloqué selon la valeur dudit drapeau "BLOCK"; et
    d/ réception par ledit agent intelligent de type serveur (T2, S1) de ladite unité de données de protocole avec ledit drapeau positionné au dit état "OPEN" et passage audit état connecté ;
    et en ce que, après ouverture de ladite session, lesdits deux agents intelligents connectés échangent des données via desdites unités de données de protocole.
  8. Procédé selon la revendication 7, caractérisé en ce que les étapes de fermeture d'une desdites sessions entre deux desdits agents intelligents (T2, T1, S2, S1) comprennent les suivantes :
    a/ émission par un desdits agents intelligents de type client (T1, S2) d'une desdites unités de données de protocole avec un drapeau audit état positionné "CLOSE", et comportant optionnellement des données ; et
    b/ réception par ledit agent intelligent de type serveur connecté (T2, S1) de ladite unité de données de protocole et passage de ladite session audit état déconnecté.
  9. Procédé selon la revendication 8, caractérisé en ce que ladite application de type "TCP/IP" présente dans le dit serveur comprend un navigateur de type "WEB" (10).
  10. Procédé selon la revendication 9, caractérisé en ce que ladite première pièce de logiciel spécifique comprend un premier agent intelligent (T1) associé auxdites propriétés « réseau », « client », « terminal », dit T1, réalisant la fonction d'un serveur de type "TCP/IP", en ce que ladite seconde pièce de logiciel spécifique comprend un premier agent intelligent (S1) associé auxdites propriétés "carte", "serveur" et "local", dit S1, cet agent S1 étant associé par une session audit premier agent intelligent T1, en ce que lesdites caractéristiques fonctionnelles déterminées dudit filtre (28) sont fonction d'informations en provenance dudit premier agent intelligent T1, en ce que ladite première pièce de logiciel spécifique comprend un deuxième agent intelligent (T2) associé auxdites propriétés "terminal", "serveur" et "réseau", dit T2, réalisant la fonction d'un client de type "TCP/IP", pour être connecté audit serveur distant (4) via ledit réseau de type Internet (RI), et en ce que ladite seconde pièce de logiciel spécifique (23a) comprend un deuxième agent intelligent (S2) associé auxdites propriétés "carte", "client" et "local", dit S2, une instance de cet agent intelligent S2 étant créée à chacune des dites sessions de manière dynamique par ledit filtre (28) et cet agent S2 ouvrant des sessions avec ledit deuxième agent intelligent T2 et lui indiquant une adresse permettant de se connecter audit serveur distant (4), de manière à ce que lesdits agents intelligents (T2, T1, S2, S1) et ledit filtre (28) coopèrent pour former une fonction dite de "proxy TCP" (27) et contrôlent des échanges de données entre ledit serveur éloigné (4) et ledit client (10).
  11. Procédé selon la revendication 10, caractérisé en ce que la création de ladite fonction "proxy TCP" (27) comprend les étapes suivantes :
    a/ ouverture d'une connexion entre ledit client (10) et ledit agent intelligent T1, et transmission par ledit navigateur de type "WEB" (10) d'une adresse "IP" déterminée de type "URL" provoquant un rebouclage sur ladite carte à puce (2a) et la création d'une session entre cet agent intelligent T1 et ledit agent intelligent S1, ladite adresse "IP" de type "URL" encapsulant une autre adresse "IP" de type "URL" identifiant un chemin menant à une entité comprise dans ledit serveur distant (4) ;
    b/ détermination à partir d'unités de données de protocole échangées pendant ladite session entre lesdits agents intelligents T1 et S1 d'une fonction déterminée de filtre (28) et création dudit filtre (28) ;
    c/ création par ledit filtre (28) d'une instance dudit agent intelligent S2 et ouverture d'une session entre lesdits agents intelligents S2 et T2, et transmission, par une première unité de données de protocole, de données véhiculant ladite adresse "IP" encapsulée, ces données précisant le nom dudit serveur éloigné (4) et un numéro de port associé ;
    d/ ouverture par ledit agent intelligent T2 d'une connexion de type "TCP" avec ledit serveur distant (4), via ledit réseau de type Internet (RI) ; et
    e/ contrôle subséquent des données émises par lesdits agents intelligents T1 et T2, de manière à opérer un traitement déterminé sur les données échangées entre ledit serveur éloigné (4) et ledit navigateur de type "WEB" (10).
  12. Procédé selon la revendication 11, caractérisé en ce que desdites unités de données de protocole sont dites « de commande » et identifiées par un drapeau de valeur particulière, en ce que ces unités de données de protocole de commande sont traitées directement par lesdits agents intelligents destinataires (T2, T1, S2, S1), sans être transmises à d'autres agents intelligents, ni au dit réseau de type Internet (RI), et en ce que ces unités de données de protocole de commande indiquent à un premier agent intelligent une quantité de données à émettre et à un deuxième agent une quantité de données qu'il est autorisé à recevoir du premier agent intelligent, de manière à permettre des échanges de données entre agents intelligents hors desdites sessions.
  13. Procédé selon la revendication 12, caractérisé en ce que ledit flux de données est un flux composite comprenant des données dites critiques devant être dérivées par ladite carte à puce (2a) pour y subir un premier traitement déterminé et des données dites opaques devant être transmises directement au dit terminal (1), lesdites données opaques subissant un deuxième traitement déterminé dans ledit terminal (1) sous le contrôle desdites données critiques agissant sur ledit filtre (28).
  14. Procédé selon la revendication 13, caractérisé en ce que ledit deuxième traitement desdites données opaques est réalisé lors d'échanges de données hors des dites sessions entre agents intelligents (T2, T1, S2, S1).
  15. Procédé selon la revendication 14, caractérisé en ce que ladite transmission de flux de données entre ledit navigateur de type "WEB" (10) et ledit serveur distant (4) s'effectue selon un protocole de communication dissymétrique et en ce qu'il comprend au moins les étapes successives suivantes :
    a/ ouverture d'une connexion entre ledit navigateur de type "WEB" (10) et ledit agent intelligent T1 et transmission par ledit navigateur de type "WEB" (10) d'une adresse "IP" déterminée de type "URL" provoquant un rebouclage sur ladite carte à puce (2a) et la création d'une session entre cet agent intelligent T1 et ledit agent intelligent S1, ladite adresse "IP" de type "URL" encapsulant une autre adresse "IP" de type "URL" identifiant un chemin menant à une entité comprise dans ledit serveur distant (4) ;
    b/ détermination à partir d'unités de données de protocole échangées pendant ladite session entre lesdits agents intelligents T1 et S1 d'une fonction déterminée de filtre (28) et création dudit filtre (28) ;
    c/ création par ledit filtre d'une instance dudit agent intelligent S2 et ouverture d'une session entre lesdits agents intelligents S2 et T2, et transmission, par une première unité de données de protocole, de données véhiculant ladite adresse "IP" encapsulée, ces données précisant le nom dudit serveur éloigné (4) et un numéro de port associé, et transmission à celui-ci d'une requête de type "http" ;
    d/ échanges de données dites critiques particulières entre ledit serveur distant (4) et ledit filtre (28) par l'intermédiaire de ladite session ouverte entre lesdits agents intelligents S2 et T2 ;
    e/ en fonction d'un résultat prédéterminé d'un traitement desdites données critiques particulières par ledit filtre (28), envoi d'une unité de données de protocole dite de commande au dit agent intelligent T2 autorisant celui-ci à recevoir des données émises hors session par ledit agent T1, les données échangées subséquemment entre ledit serveur distant (4) et ledit navigateur de type "WEB" (10) constituant lesdites données opaques et étant relayées directement par lesdits agents intelligents T1 et T2 , sans traverser ladite carte à puce (2a) ; et
    f/ lors de la détection d'un ordre de déconnexion "TCP", émission par l'un desdits agents intelligents T1 ou T2 d'une unité de données de protocole associée avec un drapeau au dit état "CLOSE" en direction de l'un desdits agents intelligents S1 ou S2, de manière à ce que ledit filtre (28) supervise une fermeture desdites sessions entre lesdits agents intelligents T1 et S1, d'une part, et lesdits agents intelligents T2 et S2, d'autre part.
  16. Procédé selon la revendication 15, caractérisé en ce que ladite étape d/ comprend une procédure d'authentification se produisant entre ledit filtre (28) et ledit serveur distant (4), et en ce que ledit résultat prédéterminé de ladite étape e/ est la vérification du bon déroulement de ladite procédure d'authentification.
  17. Procédé selon la revendication 16, caractérisé en ce que ledit filtre (28) est un filtre pour la mise en oeuvre dudit protocole sécurisé "SSL", en ce qu'il est fait usage d'un premier agent intelligent supplémentaire (T3) de type serveur associé à une fonction de type "SSL", dit T3, compris dans ladite première pièce de logiciel spécifique (13), et un deuxième agent intelligent supplémentaire (S3) de type client, dit S3, compris dans ladite seconde pièce de logiciel spécifique (23a), en ce qu'il comprend lesdites étapes a/ à d/ de manière à initier une négociation avec ledit serveur distant (4) et à sélectionner une paire de données de sécurité consistant en un algorithme de chiffrement et une fonction de hachage à sens unique, et des paramètres associés à ces données de sécurité, et à réaliser subséquemment les étapes suivantes :
    1/ ouverture d'une session entre lesdits agents S3 et T3, ce dernier étant initialisé avec une valeur de clé de chiffrement et des valeurs courantes de ladite fonction de hachage ;
    2/ envoi par ledit filtre (28) au dit agent intelligent T2 d'une desdites unités de données de protocole de commande lui permettant de transmettre au dit serveur distant (4), via ledit réseau de type Internet (RI), des données émises hors session par ledit agent intelligent T3 et de rediriger les données reçues du réseau de type Internet (RI) vers cet agent intelligent T3 ;
    3/ envoi par ledit filtre au dit agent intelligent T3 d'une dite unité de données de protocole de commande lui permettant de recevoir des données émises hors session par lesdits agents intelligents T1 et T2 ;
    4/ établissement d'un tunnel de transmissions, dans ledit terminal (1), au travers desdits agents intelligents T1, T3 et T2 ; et
    5/ lors de la fermeture d'une session qui lui est associée, par l'un desdits agents intelligents T1 ou T2, fermeture par ledit filtre (28) des autres sessions restant ouvertes.
EP01907760A 2000-02-10 2001-02-09 Procede de transmission de flux de donnees a haut debit sur un reseau de type internet entre un serveur et un terminal a carte a puce Expired - Lifetime EP1208684B1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0001665A FR2805062B1 (fr) 2000-02-10 2000-02-10 Procede de transmission de flux de donnees a haut debit sur un reseau de type internet entre un serveur et un terminal a carte a puce, notamment d'un flux de donnees multimedia
FR0001665 2000-02-10
PCT/FR2001/000394 WO2001060040A2 (fr) 2000-02-10 2001-02-09 Procede de transmission de donnees sur un reseau internet entre un serveur et un terminal a carte a puce, qui contient des agents intelligents

Publications (2)

Publication Number Publication Date
EP1208684A2 EP1208684A2 (fr) 2002-05-29
EP1208684B1 true EP1208684B1 (fr) 2006-11-08

Family

ID=8846860

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01907760A Expired - Lifetime EP1208684B1 (fr) 2000-02-10 2001-02-09 Procede de transmission de flux de donnees a haut debit sur un reseau de type internet entre un serveur et un terminal a carte a puce

Country Status (13)

Country Link
US (1) US7130910B2 (fr)
EP (1) EP1208684B1 (fr)
JP (1) JP3845018B2 (fr)
KR (1) KR100859782B1 (fr)
CN (1) CN1172505C (fr)
AT (1) ATE345003T1 (fr)
AU (1) AU3564801A (fr)
CA (1) CA2366568C (fr)
DE (1) DE60124367T2 (fr)
FR (1) FR2805062B1 (fr)
HK (1) HK1048906A1 (fr)
TW (1) TW509847B (fr)
WO (1) WO2001060040A2 (fr)

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6324685B1 (en) * 1998-03-18 2001-11-27 Becomm Corporation Applet server that provides applets in various forms
FR2791159B1 (fr) * 1999-03-15 2001-05-04 Bull Cp8 Procede d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce et architecture pour la mise en oeuvre du procede
US7346783B1 (en) * 2001-10-19 2008-03-18 At&T Corp. Network security device and method
DE10156036A1 (de) * 2001-11-15 2003-06-05 Evotec Ag Verfahren und Vorrichtung zur Datenverarbeitung
US7783901B2 (en) * 2001-12-05 2010-08-24 At&T Intellectual Property Ii, L.P. Network security device and method
KR20030046621A (ko) * 2001-12-16 2003-06-18 한국전자통신연구원 계층화 구조의 프로토콜 스택을 사용하는 스마트 카드와휴대 단말기의 통신 환경 설정 방법
FR2835671B1 (fr) * 2002-02-01 2004-07-16 Trusted Logic Procede et dispositif pour securiser les messages echanges sur un reseau
US7240830B2 (en) 2002-02-15 2007-07-10 Telefonaktiebolaget Lm Ericsson (Publ) Layered SIM card and security function
FR2841714B1 (fr) * 2002-06-26 2005-03-04 Viaccess Sa Protocole d'adaptation du degre d'interactivite entre equipements informatiques interlocuteurs soumis a un dialogue interactif
US7454499B2 (en) * 2002-11-07 2008-11-18 Tippingpoint Technologies, Inc. Active network defense system and method
KR100453060B1 (ko) * 2002-11-15 2004-10-15 삼성전자주식회사 ＭＰＶ(ＭｕｌｔｉＰｈｏｔｏＶｉｄｅｏ) 환경하에서자산이 위치하는 경로와 파일 이름을 나타내는 라스트유알엘 복구 방법
US7370212B2 (en) 2003-02-25 2008-05-06 Microsoft Corporation Issuing a publisher use license off-line in a digital rights management (DRM) system
KR100928848B1 (ko) 2003-02-26 2009-11-30 주식회사 비즈모델라인 스마트 카드 단말기용 호스트 애플리케이션 제공 방법
DE10311177A1 (de) * 2003-03-12 2004-09-23 Giesecke & Devrient Gmbh System und Verfahren zur Bonifikation der Kenntnisnahme vorgegebener Dateninhalte
SE0302189L (sv) * 2003-08-11 2004-05-11 Dan Duroj Handhållen nätverksanslutning skapad med åtminstone två lagringsmedium i fickformat med programvara för kommunikation
US20060242406A1 (en) 2005-04-22 2006-10-26 Microsoft Corporation Protected computing environment
US7720983B2 (en) * 2004-05-03 2010-05-18 Microsoft Corporation Fast startup for streaming media
JP2006031261A (ja) * 2004-07-14 2006-02-02 Matsushita Electric Ind Co Ltd マルチメディア処理システム
EP1782324B1 (fr) * 2004-08-24 2009-10-07 Gemalto SA Jeton personnel et procede d'authentification commandee
US8347078B2 (en) 2004-10-18 2013-01-01 Microsoft Corporation Device certificate individualization
US8176564B2 (en) 2004-11-15 2012-05-08 Microsoft Corporation Special PC mode entered upon detection of undesired state
US8336085B2 (en) 2004-11-15 2012-12-18 Microsoft Corporation Tuning product policy using observed evidence of customer behavior
US8464348B2 (en) * 2004-11-15 2013-06-11 Microsoft Corporation Isolated computing environment anchored into CPU and motherboard
US8438645B2 (en) 2005-04-27 2013-05-07 Microsoft Corporation Secure clock with grace periods
US8725646B2 (en) 2005-04-15 2014-05-13 Microsoft Corporation Output protection levels
US9363481B2 (en) 2005-04-22 2016-06-07 Microsoft Technology Licensing, Llc Protected media pipeline
US9436804B2 (en) 2005-04-22 2016-09-06 Microsoft Technology Licensing, Llc Establishing a unique session key using a hardware functionality scan
US20060265758A1 (en) 2005-05-20 2006-11-23 Microsoft Corporation Extensible media rights
US8353046B2 (en) 2005-06-08 2013-01-08 Microsoft Corporation System and method for delivery of a modular operating system
JP4979912B2 (ja) 2005-08-31 2012-07-18 フェリカネットワークス株式会社 情報処理システム，クライアント，サーバ，プログラム，情報処理方法
US7720984B2 (en) 2006-02-07 2010-05-18 Cisco Technology, Inc. Method and system for stream processing web services
US20080052770A1 (en) * 2006-03-31 2008-02-28 Axalto Inc Method and system of providing security services using a secure device
US9092635B2 (en) 2006-03-31 2015-07-28 Gemalto Sa Method and system of providing security services using a secure device
CN101449548A (zh) * 2006-05-22 2009-06-03 Nxp股份有限公司 安全互联网交易方法和装置
DE102007013339A1 (de) 2007-03-20 2008-09-25 Giesecke & Devrient Gmbh Portabler Datenträger als Web-Server
FR2916592B1 (fr) 2007-05-25 2017-04-14 Groupe Des Ecoles De Telecommunications(Get)-Ecole Nat Superieure Des Telecommunications(Enst) Procede de securisation d'echange d'information,dispositif, et produit programme d'ordinateur correspondant
EP2001202A1 (fr) * 2007-06-06 2008-12-10 Axalto SA Procédé de gestion d'une communication entre un jeton électronique et un serveur Web distant
US8219804B2 (en) * 2007-09-13 2012-07-10 Ricoh Company, Ltd. Approach for managing device usage data
DE102007050836A1 (de) * 2007-10-24 2009-04-30 Giesecke & Devrient Gmbh Internet-Smart-Card
FR2923337B1 (fr) * 2007-11-07 2010-01-01 Oberthur Card Syst Sa Procede et systeme d'echange de donnees entre serveurs distants.
US20090319922A1 (en) * 2008-06-19 2009-12-24 Bank Of America Corporation Non-Bypassable Disclosures in Electronic Transactions
KR101095163B1 (ko) * 2008-08-27 2011-12-16 에스케이플래닛 주식회사 위젯 실행을 위한 사용자 단말기와 스마트 카드 간 연동 시스템 및 그 방법
US8972584B2 (en) * 2009-03-13 2015-03-03 Sharp Laboratories Of America, Inc. Remote card reader access
FR2943198B1 (fr) * 2009-03-16 2011-05-20 Groupe Des Ecoles De Telecommunications Get Ecole Nationale Superieure Des Telecommunications Enst Procede de production de donnees de securisation, dispositif et programme d'ordinateur correspondant
FR2951845B1 (fr) * 2009-10-28 2011-12-23 Oberthur Technologies Objet a microcircuit de poche et terminal de communication comprenant cet objet
US8676954B2 (en) * 2011-12-06 2014-03-18 Kaseya International Limited Method and apparatus of performing simultaneous multi-agent access for command execution through a single client
DE102012003009A1 (de) * 2012-02-15 2013-08-22 Giesecke & Devrient Gmbh Übertragen von Datenströmen zu und von einem Sicherheitsmodul
CN104348951B (zh) * 2013-07-24 2016-10-19 北京握奇数据系统有限公司 一种卡片应用管理系统
US11463654B1 (en) 2016-10-14 2022-10-04 Allstate Insurance Company Bilateral communication in a login-free environment
US10742812B1 (en) * 2016-10-14 2020-08-11 Allstate Insurance Company Bilateral communication in a login-free environment
US10657599B2 (en) 2016-10-14 2020-05-19 Allstate Insurance Company Virtual collaboration
FR3117244B1 (fr) * 2020-12-04 2024-07-12 Banks And Acquirers Int Holding Procédé de transmission de données, dispositif et programme correspondant.

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0727894B1 (fr) * 1994-08-30 2004-08-04 Kokusai Denshin Denwa Co., Ltd Systeme de certification
DE69714752C5 (de) * 1996-10-25 2015-08-13 Gemalto Sa Verwendung einer hohen programmiersprache in einem mikrokontroller
US6282522B1 (en) * 1997-04-30 2001-08-28 Visa International Service Association Internet payment system using smart card
GB2326010A (en) * 1997-06-07 1998-12-09 Ibm Data processing system using active tokens
GB2332288A (en) * 1997-12-10 1999-06-16 Northern Telecom Ltd agent enabling technology
US6438550B1 (en) * 1998-12-10 2002-08-20 International Business Machines Corporation Method and apparatus for client authentication and application configuration via smart cards
US6547150B1 (en) * 1999-05-11 2003-04-15 Microsoft Corporation Smart card application development system and method

Also Published As

Publication number Publication date
FR2805062B1 (fr) 2005-04-08
US7130910B2 (en) 2006-10-31
JP2003522361A (ja) 2003-07-22
HK1048906A1 (en) 2003-04-17
WO2001060040A3 (fr) 2002-03-14
CA2366568C (fr) 2007-07-24
FR2805062A1 (fr) 2001-08-17
EP1208684A2 (fr) 2002-05-29
CN1172505C (zh) 2004-10-20
US20020138549A1 (en) 2002-09-26
TW509847B (en) 2002-11-11
DE60124367T2 (de) 2007-08-30
AU3564801A (en) 2001-08-20
KR20020005670A (ko) 2002-01-17
JP3845018B2 (ja) 2006-11-15
CA2366568A1 (fr) 2001-08-16
ATE345003T1 (de) 2006-11-15
WO2001060040A2 (fr) 2001-08-16
KR100859782B1 (ko) 2008-09-24
DE60124367D1 (de) 2006-12-21
CN1363171A (zh) 2002-08-07

Similar Documents

Publication Publication Date Title
EP1208684B1 (fr) Procede de transmission de flux de donnees a haut debit sur un reseau de type internet entre un serveur et un terminal a carte a puce
EP1169837B1 (fr) Procede de gestion de transmissions de donnees multimedias via internet et carte a puce pour la mise en oeuvre du procede
EP1044436B1 (fr) Procede de communication entre une station d&#39;utilisateur et un reseau, notamment du type internet, et architecture de mise en oeuvre
EP1142256B1 (fr) Terminal securise muni d&#39;un lecteur de carte a puce destine a communiquer avec un serveur via un reseau de type internet
FR2805108A1 (fr) Procede d&#39;enregistrement d&#39;un usager sur un serveur d&#39;annuaire d&#39;un reseau de type internet et/ou de localisation d&#39;un usager sur ce reseau, et carte a puce pour la mise en oeuvre du procede
EP2050081B1 (fr) Procede de routage de donnees d&#39;application entrantes dans un chipset nfc, par identification de l&#39;application
EP1188116A1 (fr) Procede de chargement d&#39;une piece de logiciel dans une carte a puce, notamment du type dit &#34;applet&#34;
WO2000056030A1 (fr) Systeme d&#39;acces a un objet a l&#39;aide d&#39;un navigateur de type &#39;web&#39; cooperant avec une carte a puce
EP2039114A2 (fr) Procede de controle d&#39;application dans un chipset nfc comprenant plusieurs processeurs hotes
WO2002073930A1 (fr) Dispositif portable pour securiser le trafic de paquets dans une plate-forme hote
WO2001024475A2 (fr) Procede et architecture de pilotage a distance d&#39;une station d&#39;utilisateur via un reseau de type internet
FR2809560A1 (fr) Procede et architecture de systeme de communication securise entre deux entites connectees a un reseau de type internet, comprenant un segment de transmissions sans fil
EP2372945A1 (fr) Procédé de transmission sécurisée de données entre un terminal numérique et une plateforme de services interactifs
EP1868349B1 (fr) Dispositif de mise en communication de réseaux locaux par un commutateur exclusif et systéme de mise en communication correspondant ainsi qu&#39;un support d&#39;informations et un programme d&#39;ordinateur
WO2010133459A1 (fr) Procede de chiffrement de parties particulieres d&#39; un document pour les utilisateurs privileges
FR3076638A1 (fr) Procede de gestion d&#39;un acces a une page web d&#39;authentification
FR2862170A1 (fr) Procede de transfert de donnees confidentielles en coeur de reseaux
EP3360293A1 (fr) Moyens de gestion d&#39;accès à des données
EP1401167A1 (fr) Architecture pour établir une session multimédia sur un réseau

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

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: CP8 TECHNOLOGIES

17P Request for examination filed

Effective date: 20020916

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

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

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20061108

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20061108

Ref country code: IE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20061108

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20061108

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

REF Corresponds to:

Ref document number: 60124367

Country of ref document: DE

Date of ref document: 20061221

Kind code of ref document: P

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20070208

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20070208

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20070219

GBT Gb: translation of ep patent filed (gb section 77(6)(a)/1977)

Effective date: 20070207

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20070228

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20070228

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20070228

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20070409

NLV1 Nl: lapsed or annulled due to failure to fulfill the requirements of art. 29p and 29m of the patents act
REG Reference to a national code

Ref country code: IE

Ref legal event code: FD4D

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

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

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

26N No opposition filed

Effective date: 20070809

BERE Be: lapsed

Owner name: CP8 TECHNOLOGIES

Effective date: 20070228

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20070228

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20070209

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20070209

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20061108

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20061108

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: IT

Payment date: 20120121

Year of fee payment: 12

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20130129

Year of fee payment: 13

Ref country code: DE

Payment date: 20130124

Year of fee payment: 13

Ref country code: FR

Payment date: 20130408

Year of fee payment: 13

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 60124367

Country of ref document: DE

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20140209

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20141031

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 60124367

Country of ref document: DE

Effective date: 20140902

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20140902

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20140228

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20140209

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20140209