EP1590936A1 - Procede et terminal de communication entre deux unites - Google Patents

Procede et terminal de communication entre deux unites

Info

Publication number
EP1590936A1
EP1590936A1 EP03778464A EP03778464A EP1590936A1 EP 1590936 A1 EP1590936 A1 EP 1590936A1 EP 03778464 A EP03778464 A EP 03778464A EP 03778464 A EP03778464 A EP 03778464A EP 1590936 A1 EP1590936 A1 EP 1590936A1
Authority
EP
European Patent Office
Prior art keywords
family
marking
application
unit
applications
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP03778464A
Other languages
German (de)
English (en)
Inventor
Benoít De Boursetty
Manuel Gruson
Dimitri Mouton
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1590936A1 publication Critical patent/EP1590936A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • 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/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2113—Multi-level security, e.g. mandatory access control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals

Definitions

  • the present invention relates to computer terminals allowing network browsing type activities and offering users the possibility of installing applications.
  • Such terminals can in particular be telephones using the wireless application protocol (WAP, "wireless application protocol”), desktop computers, portable computers or personal digital assistants (PDA, "personal digital assistant”). They have in common the characteristic of being connected to a digital data network, which in many practical cases is a network operating according to the IP protocol (“Internet protocol”), in particular the Internet.
  • WAP wireless application protocol
  • PDA personal digital assistant
  • the opening of a terminal refers to the possibility offered to the user to install, and often to download, new applications intended to be executed by the terminal itself.
  • Examples of "open" terminals incorporating this possibility are: • telephones for downloading applications, for example of the type
  • "Semi-open" terminals are open terminals, certain functionalities of which are not directly accessible to applications installed by the user or downloaded. For example, in a terminal whose only "opening" is ECMAScript, the downloaded applications cannot access all the network functionalities (for example, send IP packets that do not obey the formats of the most common transport protocols, namely TCP ("transmission control protocol") or UDP ("user datagram protocol”)). These functions can be accessed indirectly and controlled. For example, an ECMAScript function can command the loading of a page via HTTP ("hypertext transfer protocol”) ,. which uses the network but in a controlled manner.
  • HTTP hypertext transfer protocol
  • “Completely open” terminals are open terminals in which all functionality is accessible to downloaded applications.
  • the notion of opening a terminal depends to a large extent on the context in which we place our. For example, different layers of the OSI model (link / network / session / transport / 7) can have different degrees of openness.
  • the "semi-open" nature of a terminal generally implies that execution rights observable from a distance, accessible to trusted applications, are not accessible to applications without confidence (for example, the right to transmit requests other than HTTP on an IP network). This allows a server to distinguish, among the requests that arrive, those that come from trusted applications and those that come from other applications. It can in particular distinguish requests from downloaded applications from requests from applications present from the outset in the terminal.
  • trusted applications the server is ready to assume that these applications are not Trojans.
  • the WAP browser on a WAP phone can be a trusted application.
  • Another example could be a Java MIDP application downloaded with signature;
  • An object of the present invention is to offer a difference in the ability to send requests of a new type between "trusted” applications and "untrusted” applications, which is flexible for applications and can nevertheless be identified by the recipient server.
  • the notion of trust can be based on various criteria (signature, type of exchange, URL from which the application was downloaded, etc.).
  • the invention thus provides a method of communication between a first unit and a second unit via a telecommunications network, in which the first unit comprises applications belonging respectively to a first family and to a second family having a priori a lower level of confidence than the first family.
  • each request originating from an application of the second family, sent on the network intended for the second unit is forced to include a marking associated with the second family of applications.
  • each request originating from an application of the second family, sent on the network intended for the second unit is forced not to include a marking associated with the first family, said marking being included in at least some of the requests issued on the network and originating from applications of the first family.
  • the invention also provides a communication terminal, comprising means for implementing such a method as a first unit.
  • the method allows certain particular ("trusted") applications running in the first unit to send frames to the attention of a second unit, generally a remote server, with the guarantee for this second unit of the reliable origin of these frames.
  • the mandatory inclusion of marking for applications a priori without the confidence of the second family distinguishes, on issue, the frames emitted by these applications a priori without confidence compared to those emitted by trusted applications. This allows the server to sort between acceptable requests, which it trusts, and those which it must reject.
  • the marking applied should be completely "waterproof", that is to say that it is not possible for an a priori application without confidence to short-circuit the checks carried out at a certain level (for example: HTTP requests), by attacking the lower layers (for example: request for a TCP connection).
  • the marking included in a request sent on the network and originating from an application of the second family, is forced to include an indication of the nature and / or the origin of said application of the second family.
  • This indication consists, for example, of data relating to the certification of the signature of a signed application, or else to the download address of an application downloaded via the network. It can be used by the remote unit to assess whether it can trust the application which could a priori only be judged without confidence by the first unit.
  • terminals supporting the downloading of the applications can exchange data with confidence with a server, despite the risks inherent in these downloading capacities.
  • a remote unit such as a server 1 to obtain in a secure and flexible manner the confidence in requests received on a telecommunications network R coming from a semi-open terminal 2.
  • This terminal hosts a share of trusted applications 3, such as by example a web browser, and on the other hand a priori unreliable applications 4, in particular applications that the user of the terminal has downloaded via the network R.
  • a priori unreliable applications 4 are constrained as to the frames or requests that they can send on the network R, which, in the diagram, is symbolized by a control layer 5 forming part of the network access resources 6 of which Terminal 2 is equipped.
  • the control layer 5 verifies that certain properties are fulfilled by the frames emitted by the a priori untrusted applications 4. If these properties are fulfilled, the control layer lets the frames pass. Otherwise, it can either not let them pass to the network R and notify the application 4 which sent them, or modify the frames to conform to the constraints of the a priori untrusted applications. In the latter case, the frame loses its credibility in the eyes of the server 1, which may not use it.
  • the aforementioned constraints relate to the presence or absence of a specific marking in the requests sent on the network R from some of the applications.
  • control layer 5 requires requests from a priori unreliable applications 4 to include a marking associated with this family of applications.
  • a trusted application 3 accesses functionalities which allow it to bypass the control layer 5 and issue unmarked requests.
  • network access resources 6 do not make these functionalities available to a priori untrusted applications 4.
  • Java virtual machine 2 (for example a mobile phone) has a Java virtual machine, which can correspond to module 6 in the figure.
  • the virtual machine is used to run downloaded applications written in the Java programming language developed by the company Sun Microsystems, Inc. All instructions in the Java language are executed by the virtual machine, which calls system functions after a certain control.
  • This terminal 2 is only able to download Java code, no other type of application can be installed there by the user.
  • the protocols used for the exchanges of terminal 2 on the network R are the HTTP protocols (RFC 1945 ("Request For
  • TCP RRC 793, IETF, September 1981
  • IP RRC 791 ,, IETF, September 1981
  • the service is hosted by an HTTP 1 server which stores user-owned content. He must ensure that a request (requesting the deletion of all files for example) comes from the user, and not from a malicious Java program.
  • This service is of course an example, any other service that may be using this technique (electronic commerce, publication of documents, messaging, etc.).
  • the marking can be included in the "User-Agent" header field of HTTP requests (see section 10.15 of RFC 1945 above). It consists of a specific string such as "Application without confidence: VM Java 1.2" which indicates by its presence that the request is not coming from an application a priori of confidence. This chain may already be present in the request produced by the application 4, in which case the control layer 5 of the virtual machine 6 is satisfied with checking its presence. Otherwise, this layer 5 inserts it so that the request is properly marked.
  • the watertightness of the marking applied by the virtual machine 6 results from the fact that it is not possible for an application a priori without confidence 4 to send on the network R HTTP requests not containing this specific chain.
  • application 4 cannot have access to the network R by connecting to a protocol layer lower than HTTP, in particular to TCP sockets.
  • the marking is implemented directly in virtual machine 6 in which the a priori untrusted application is forced to run and which it cannot avoid in any way.
  • the server 1 can thus sort, among the requests which arrive at it, those which come from a priori unreliable applications 4 and those which come from trusted applications 3 such as a web browser.
  • a Java applet is generally considered to be trusted by the site from which it was downloaded, but not by other sites. Marking will therefore not always be necessary in requests intended for this download site.
  • the virtual machine 6 can impose the marking on the requests originating from such an applet and sent to a site other than the one from which it was downloaded and leave the applet free to include or not the marking in the requests it makes to its original site. Another possibility is to impose the marking on any request sent by such an applet, whatever the destination.
  • An alternative or a complement to the marking of requests without confidence can be the prohibition of some of these requests. For example, for untrusted applications downloaded from a given server, direct requests to different servers could be prohibited. Requests to the origin server would still be possible, with the marking.
  • Such an embodiment of the invention is particularly applicable in the case of a Java application signed by a certificate.
  • the virtual machine 6 must verify the signature of the Java application before issuing the requests. In practice, this verification takes place before the execution of the application 4.
  • the marking can then consist of adding a specific string in the HTTP header, such as for example: "Trusted content - Application signed by ⁇ C>" where ⁇ C> is the value of the signer's certificate. the application, or a digest of it.
  • This header indicates by its presence that the request comes directly from a user, and was created by software of known origin.
  • the server 1 trusts the holder of the private keys associated with the certificate ⁇ C>, the server is guaranteed that the requests marked with this specific header correspond to an effective agreement of the user.
  • the marking constraint prevents the application from claiming from a signatory other than the real signatory from the server.
  • the virtual machine 6 is capable of identifying the download address of the application. It can thus force the request resulting from such an applet, a priori without confidence, to include its download address or data which depend on this address.
  • the syntax of the marking is reversed: the control layer 5 imposes on the requests originating from the a priori unreliable applications 4 not to include a marking specific to the trusted applications 3. To manifest itself as being trusted by a server 1, an application 3 then includes the marking in the request that it addresses to it. The control layer 5 ensures that this marking is absent from each request originating from an a priori untrusted application 4, the untrusted character being able, as previously, to be assessed as a function of the site receiving the request.
  • the marking is present in a request originating from an a priori unreliable application 4, the request is not sent as is: the marking is removed by the control layer 5 and the latter may or may not issue the request " unmarked "on the R network and prevent or not the application 4.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Une première unité (2) comporte des applications (3, 4) appartenant respectivement à des première et seconde familles d'applications. La seconde famille présente a priori un degré de confiance plus faible que la première famille. Chaque requête issue d'une application (4) de la seconde famille, émise sur un réseau (R) à destination d'une seconde unité, est contrainte soit à inclure un marquage associé à la seconde famille d'applications, soit à ne pas inclure un marquage associé à la première famille, ce marquage associé à la première famille étant alors inclus dans certaines au moins des requêtes émises sur le réseau et issues d'applications (3) de la première famille.

Description

A
PROCEDE ET TERMINAL DE COMMUNICATION ENTRE DEUX UNITES
La présente invention concerne les terminaux informatiques permettant des activités de type navigation sur réseau et offrant aux utilisateurs la possibilité d'installer des applications.
De tels terminaux peuvent notamment être des téléphones utilisant le protocole d'application sans fil (WAP, "wireless application protocol"), des ordinateurs de bureau, des ordinateurs portables ou des assistants numériques personnels (PDA, "personal digital assistant"). Ils ont en commun la caractéristique d'être reliés à un réseau de données numérique, qui dans beaucoup de cas pratiques est un réseau fonctionnant selon le protocole IP ("Internet protocol"), notamment l'Internet.
Dans le cas d'un terminal "fermé" (exemple: un Minitel), les applications présentes sur le terminal sont connues et ne peuvent pas être changées au cours de la vie du terminal.
L'ouverture d'un terminal fait référence à la possibilité offerte à l'utilisateur d'installer, et souvent de télécharger, de nouvelles applications destinées à être exécutées par le terminal lui-même. Des exemples de terminaux "ouverts", intégrant cette possibilité, sont: • les téléphones à téléchargement d'applications, par exemple de type
Java MIDP ("Mobile Information Device Profile", Sun Microsystems, Inc.);
• les navigateurs possédant des fonctionnalités dites de scripting, par exemple de type WMLScript (voir "WAP WMLScript Language Spécification", version 1.1 , WAP Forum, novembre 2001) ou ECMAScript (aussi appelé JavaScript, voir "ECMAScript Language Spécification",
Standard ECMA-262, 3e édition, décembre 1999), ou accueillant des applets;
• la plupart des PDA, fonctionnant sous les systèmes d'exploitation PalmOS, WindowsCE, Symbian etc.; • les ordinateurs de bureau ou portables. Les terminaux "semi-ouverts" sont les terminaux ouverts dont certaines fonctionnalités ne sont pas directement accessibles aux applications installées par l'utilisateur ou téléchargées. Par exemple, dans un terminal dont la seule "ouverture" est ECMAScript, les applications téléchargées ne peuvent pas accéder à toutes les fonctionnalités du réseau (par exemple, émettre des paquets IP n'obéissant pas aux formats des protocoles de transport les plus courants, à savoir TCP ("transmission control protocol") ou UDP ("user datagram protocol")). Ces fonctionnalités peuvent être accessibles de façon indirecte et contrôlée. Par exemple, une fonction ECMAScript peut commander le chargement d'une page via HTTP ("hypertext transfer protocol"),. ce qui utilise le réseau mais d'une façon contrôlée.
Dans des terminaux "semi-ouverts", il y a coexistence:
• d'applications considérées comme "de confiance", par exemple parce qu'elles ont été installées en usine par le fabricant du terminal, ou bien du fait de la garantie procurée par des moyens tels que la signature électronique de l'application etc.;
• et d'autres applications qui peuvent être installées sur le terminal par l'utilisateur lui-même, à son libre choix, mais n'accèdent pas aux mêmes droits que les applications de confiance.
Les terminaux "complètement ouverts", par opposition, sont les terminaux ouverts dans lesquels toutes les fonctionnalités sont accessibles aux applications téléchargées. La notion d'ouverture d'un terminal dépend dans une large mesure du contexte dans lequel on se place. Par exemple, différentes couches du modèle OSI (lien / réseau / session / transport / ...) peuvent avoir différents degrés d'ouverture.
On s'intéresse ici aux fonctionnalités observables à distance, depuis un serveur, c'est-à-dire aux fonctionnalités de réseau. Dans ce cadre, le caractère "semi-ouvert" d'un terminal implique généralement que des droits d'exécution observables à distance, accessibles aux applications de confiance, ne sont pas accessibles aux applications sans confiance (par exemple, le droit d'émettre des requêtes autres que HTTP sur un réseau IP). Ceci permet à un serveur de distinguer, parmi les requêtes qui lui arrivent, celles qui proviennent d'applications de confiance et celles qui proviennent d'autres applications. Il peut en particulier distinguer les requêtes provenant d'applications téléchargées des requêtes provenant d'applications présentes dès l'origine dans le terminal.
Dans les terminaux ouverts, il faut tenir compte de la possibilité qu'un programme se comporte de façon trompeuse vis-à-vis de l'utilisateur (cheval de Troie). Ainsi, rien ne peut garantir à un serveur qu'une requête provient bien de l'utilisateur, et non d'un programme ayant simulé l'accord de l'utilisateur au niveau du réseau. Ce risque ruine la confiance que le serveur peut avoir dans les données qu'il reçoit d'un client. L'hypothèse selon laquelle les requêtes adressées au serveur reflètent les actions de l'utilisateur n'est pas raisonnable si un cheval de Troie a la possibilité de les envoyer à la place de l'utilisateur.
On fera donc dans la suite une distinction entre les applications présentes sur le terminal:
• applications de confiance: le serveur est prêt à faire l'hypothèse que ces applications ne sont pas des chevaux de Troie. Par exemple, le navigateur WAP d'un téléphone WAP peut constituer une application de confiance. Un autre exemple peut être une application Java MIDP téléchargée avec signature;
• applications sans confiance: le serveur considère que ces applications peuvent être des chevaux de Troie. Par exemple, des applications Java MIDP téléchargées sans signature sur un terminal peuvent être des applications sans confiance.
La réponse classique au risque de cheval de Troie est de limiter les capacités des applications sans confiance.
La limitation de l'émission des trames depuis les terminaux semi- ouverts se fait généralement de façon extrêmement stricte. Seules les applications système (fournies avec le système d'exploitation du terminal) sont autorisées à émettre certaines trames. Il devient donc impossible à une application téléchargée (avec ou sans confiance) d'émettre des trames vers un serveur, même si cette application dispose par ailleurs de moyens d'obtenir la confiance du serveur du fait du contenu des trames qu'elle émet (exemple: émission de données signées) ou du fait de ses caractéristiques (exemple: signature associée à son contenu).
Un but de la présente invention est d'offrir une différence de, capacité d'envoi de requêtes d'un nouveau type entre applications "de confiance" et applications "sans confiance", qui soit flexible pour les applications et puisse néanmoins être identifiée par le serveur destinataire. La notion de confiance peut s'appuyer sur des critères variés (signature, type d'échange, URL depuis laquelle l'application a été téléchargée, etc.).
L'invention propose ainsi un procédé de communication entre une première unité et une seconde unité par l'intermédiaire d'un réseau de télécommunication, dans lequel la première unité comporte des applications appartenant respectivement à une première famille et à une seconde famille présentant a priori un degré de confiance plus faible que la première famille. Selon un aspect de l'invention, on contraint chaque requête issue d'une application de la seconde famille, émise sur le réseau à destination de la seconde unité, à inclure un marquage associé à la seconde famille d'applications. Selon un autre aspect de l'invention, on contraint chaque requête issue d'une application de la seconde famille, émise sur le réseau à destination de la seconde unité, à ne pas inclure un marquage associé à la première famille, ledit marquage étant inclus dans certaines au moins des requêtes émises sur le réseau et issues d'applications de la première famille. L'invention propose aussi un terminal de communication, comprenant des moyens de mise en œuvre d'un tel procédé en tant que première unité.
Le procédé permet à certaines applications particulières ("de confiance") s'exécutant dans la première unité d'émettre des trames à l'attention d'une seconde unité, généralement un serveur distant, avec la garantie pour cette seconde unité de l'origine fiable de ces trames. L'inclusion obligatoire du marquage pour les applications a priori sans confiance de la seconde famille (ou symétriquement son interdiction) distingue, à l'émission, les trames émises par ces applications a priori sans confiance par rapport à celles émises par des applications de confiance. Ceci permet au serveur de faire le tri entre les requêtes acceptables, en lesquelles il a confiance, et celles qu'il doit rejeter.
II convient que le marquage appliqué soit complètement "étanche", c'est-à-dire qu'il ne soit pas possible pour une application a priori sans confiance de court-circuiter les contrôles effectués à un certain niveau (par exemple: fonctions de requêtes HTTP), en attaquant les couches plus basses (par exemple: requête d'une connexion TCP).
Dans une réalisation du procédé, on contraint le marquage, inclus dans une requête émise sur le réseau et issue d'une application de la seconde famille, à inclure une indication de la nature et/ou de l'origine de ladite application de la seconde famille. Cette indication consiste par exemple en des données relatives à la certification de la signature d'une application signée, ou encore à l'adresse de téléchargement d'une application téléchargée par l'intermédiaire du réseau. Elle peut être utilisée par l'unité distante pour évaluer si elle peut faire confiance à l'application qui ne pouvait a priori qu'être jugée sans confiance par la première unité.
Grâce au procédé, des terminaux supportant le téléchargement des applications peuvent échanger des données en toute confiance avec un serveur, malgré les risques inhérents à ces capacités de téléchargement
("ouverture" du terminal). Le procédé procure ainsi une protection simple et efficace contre les chevaux de Troie.
D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence au dessin annexé, dans lequel la figure unique est un schéma d'un système mettant en œuvre l'invention.
On cherche à permettre à une unité distante telle qu'un serveur 1 d'obtenir de façon sûre et souple la confiance dans des requêtes reçues sur un réseau de télécommunication R en provenance d'un terminal semi-ouvert 2. Ce terminal héberge d'une part des applications de confiance 3, comme par exemple un navigateur web, et d'autre part des applications a priori sans confiance 4, notamment des applications que l'utilisateur du terminal a téléchargées par l'intermédiaire du réseau R.
Les applications a priori sans confiance 4 sont contraintes quant aux trames ou requêtes qu'elles peuvent émettre sur le réseau R, ce qui, dans le schéma, est symbolisé par une couche de contrôle 5 faisant partie des ressources 6 d'accès au réseau dont est équipé le terminal 2.
La couche de contrôle 5 vérifie que certaines propriétés sont remplies par les trames émises par les applications a priori sans confiance 4. Si ces propriétés sont remplies, la couche de contrôle laisse passer les trames. Sinon, elle peut soit ne pas les laisser passer vers le réseau R et en prévenir l'application 4 qui les a émises, soit modifier les trames pour les conformer aux contraintes des applications a priori sans confiance. Dans ce dernier cas, la trame perd sa crédibilité aux yeux du serveur 1 , qui pourra ne pas l'exploiter.
Les contraintes précitées se rapportent à la présence ou non d'un marquage spécifique dans les requêtes émises sur le réseau R depuis certaines des applications.
Dans un premier mode de réalisation de l'invention, la couche de contrôle 5 impose aux requêtes issues des applications a priori sans confiance 4 d'inclure un marquage associé à cette famille d'applications. Une application de confiance 3 accède à des fonctionnalités qui lui permettent de contourner la couche de contrôle 5 et d'émettre des requêtes non marquées. En revanche, les ressources 6 d'accès au réseau ne mettent pas ces fonctionnalités à disposition des applications a priori sans confiance 4.
Dans un exemple illustrant ce premier mode de réalisation, le terminal
2 (par exemple un téléphone mobile) dispose d'une machine virtuelle Java, pouvant correspondre au module 6 sur la figure. La machine virtuelle permet d'exécuter des applications téléchargées écrites dans le langage de programmation Java mis au point par la société Sun Microsystems, Inc. Toutes les instructions du langage Java sont exécutées par la machine virtuelle, qui fait appel aux fonctions système après un certain contrôle. Pour les applications Java, on est bien dans un environnement semi-ouvert puisqu'il n'y a pas d'appel sans contrôle aux fonctions système. Ce terminal 2 n'est capable de télécharger que du code Java, aucun autre type d'application ne pouvant y être installé par l'utilisateur.
L'application a priori sans confiance 4 est alors écrite en langage Java.
Dans cet exemple, les protocoles mis en jeu pour les échanges du terminal 2 sur le réseau R sont les protocoles HTTP (RFC 1945 ("Request For
Comments"), publiée en mai 1996 par l'IETF ("Internet Engineering Task
Force")), TCP (RFC 793, IETF, septembre 1981) et IP (RFC 791,, IETF, septembre 1981).
Le service est hébergé par un serveur HTTP 1 qui stocke du contenu appartenant à l'utilisateur. Il doit s'assurer du fait qu'une requête (demandant par exemple l'effacement de tous les fichiers) provient bien de l'utilisateur, et non d'un programme Java mal intentionné. Ce service est bien entendu un exemple, n'importe quel autre service pouvant être faire appel à cette technique (commerce électronique, publication de documents, messagerie, etc.).
Le marquage peut être inclus dans le champ d'en-tête "User-Agent" des requêtes HTTP (cf. section 10.15 de la RFC 1945 précitée). Il consiste en une chaîne spécifique telle que "Application sans confiance : VM Java 1.2" qui indique par sa présence que la requête n'est pas en provenance d'une application a priori de confiance. Cette chaîne peut être déjà présente dans la requête produite par l'application 4, auquel cas la couche de contrôle 5 de la machine virtuelle 6 se contente de vérifier sa présence. Sinon, cette couche 5 l'insère pour que la requête soit convenablement marquée.
L'étanchéité du marquage appliqué par la machine virtuelle 6 résulte de ce qu'il n'est pas possible à une application a priori sans confiance 4 d'émettre sur le réseau R des requêtes HTTP ne contenant pas cette chaîne spécifique. En particulier, l'application 4 ne peut pas avoir accès au réseau R en se branchant sur une couche protocolaire plus basse que HTTP, notamment aux sockets TCP. Le marquage est implémenté directement dans la machine virtuelle 6 dans laquelle l'application a priori sans confiance est obligée de s'exécuter et qu'elle ne peut éviter d'aucune manière.
Le serveur 1 peut ainsi trier, parmi les requêtes qui lui arrivent, ceiîes qui proviennent d'applications a priori sans confiance 4 et celles qui proviennent d'applications de confiance 3 telles qu'un navigateur web.
Il existe des applications qui ne sont de confiance que pour certains sites. Par exemple, une applet Java est généralement considérée comme de confiance par le site depuis lequel elle a été téléchargée, mais non par d'autres sites. Le marquage ne sera donc pas toujours nécessaire dans les requêtes destinées à ce site de téléchargement. En d'autres termes, la machine virtuelle 6 peut imposer le marquage aux requêtes issues d'une telle applet et émises vers un site autre que celui d'où elle a été téléchargée et laisser Papplet libre d'inclure ou non le marquage dans les requêtes qu'elle émet vers son site d'origine. Une autre possibilité est d'imposer le marquage à toute requête émise par une telle applet, quelle qu'en soit la destination.
Une alternative ou un complément au marquage des requêtes sans confiance peut être l'interdiction de certaines de ces requêtes. Par exemple, pour des applications sans confiance téléchargées depuis un serveur donné, les requêtes directes à destination de serveurs différents pourraient être interdites. Les requêtes à destination du serveur d'origine resteraient possibles, avec le marquage.
Dans une réalisation avantageuse, on adjoint obligatoirement au marquage une indication de la nature et/ou de l'origine de l'application a priori sans confiance 4 dont elle est issue.
Cette application a priori sans confiance 4 peut être signée. Les requêtes qui en proviennent seront alors marquées avec un en-tête contenant au moins l'un des éléments suivants, susceptibles de fonder la confiance du serveur distant dans cette application:
• le certificat du signataire de l'application, ou un condensé de ce certificat; • le certificat de la chaîne de certification d'où le certificat du signataire de l'application est issu, ou un condensé de ce. certificat;
• une chaîne spécialement incluse dans le code de l'application à cet effet;
• un élément variable identifiant l'application de manière dynamique.
Une telle réalisation de l'invention est notamment applicable dans le cas d'une application Java signée par un certificat.
Dans ce cas, la machine virtuelle 6 doit vérifier la signature de l'application Java avant l'émission des requêtes. En pratique, cette vérification a lieu avant l'exécution de l'application 4.
Le marquage peut alors consister en l'ajout d'une chaîne spécifique dans l'en-tête HTTP, comme par exemple: "Contenu de confiance - Application signée par <C>" où <C> est la valeur du certificat du signataire de l'application, ou un condensé de celui-ci. Cet en-tête indique par sa présence que la requête est en provenance directe d'un utilisateur, et a été créée par un logiciel de provenance connue.
De cette façon, si le serveur 1 accorde sa confiance au détenteur des clefs privées associées au certificat <C>, le serveur est garanti que les requêtes marquées de cet en-tête spécifique correspondent bien à un accord effectif de l'utilisateur. La contrainte de marquage évite que l'application puisse, auprès du serveur, se réclamer d'un signataire autre que le signataire réel.
Dans le cas des applet Java téléchargées, la machine virtuelle 6 est capable d'identifier l'adresse de téléchargement de l'application. Elle peut ainsi contraindre la requête issue d'une telle applet, a priori sans confiance, d'inclure son adresse de téléchargement ou des données qui dépendent de cette adresse.
Dans un autre mode de réalisation de l'invention, la syntaxe du marquage est inversée: la couche de contrôle 5 impose aux requêtes issues des applications a priori sans confiance 4 de ne pas inclure un marquage spécifique aux applications de confiance 3. Pour se manifester comme étant de confiance pour un serveur 1 , une application 3 inclut alors le marquage dans la requête qu'elle lui adresse. La couche de contrôle 5 s'assure que ce marquage est absent de chaque requête issue d'une application a priori sans confiance 4, le caractère sans confiance pouvant comme précédemment être apprécié en fonction du site destinataire de la requête. Si le marquage est présent dans une requête issue d'une application a priori sans confiance 4, la requête n'est pas émise telle quelle: le marquage est enlevé par la couche de contrôle 5 et celle-ci peut émettre ou non la requête "démarquée" sur le réseau R et prévenir ou non l'application 4.
La convention employée pour la syntaxe du marquage doit naturellement être commune au terminal et au senteur, et connue des deux avant la transaction.

Claims

R E V E N D I C A T I O N S
1. Procédé de communication entre une première unité (2) et une seconde unité (1 ) par l'intermédiaire d'un réseau de télécommunication (R), dans lequel la première unité comporte des applications (3, 4) appartenant respectivement à une première famille et à une seconde famille présentant a priori un degré de confiance plus faible que la première famille, caractérisé en ce qu'on contraint chaque requête issue d'une application (4) de la seconde famille, émise sur le réseau à destination de la seconde unité, à inclure un marquage associé à la seconde famille d'applications.
2. Procédé selon la revendication 1 , dans lequel ledit marquage est inclus dans chaque requête émise sur le réseau (R) et issue d'une application de la seconde famille (4).
3. Procédé selon la revendication 1 ou 2, dans lequel on contraint le marquage, inclus dans une requête émise sur le réseau (R) et issue d'une application (4) de la seconde famille, à inclure une indication de la nature et/ou de l'origine de ladite application de la seconde famille.
4. Procédé selon la revendication 3, dans lequel, ladite application (4) de la seconde famille étant signée, on contraint le marquage, inclus dans les requêtes qui en sont issues, à inclure des données relatives à la certification de la signature.
5. Procédé selon la revendication 3 ou 4, dans lequel, ladite application (4) de la seconde famille ayant été téléchargée par l'intermédiaire du réseau (R) depuis une adresse de téléchargement, on contraint le marquage, inclus dans les requêtes qui en sont issues, à inclure des données relatives à l'adresse de téléchargement de l'application.
6. Procédé de communication entre une première unité (2) et une seconde unité (1) par l'intermédiaire d'un réseau de télécommunication (R), dans lequel la première unité comporte des applications (3. 4) appartenant respectivement à une première famille et à une seconde famille présentant a priori un degré de confiance plus faible que la première famille, caractérisé en ce qu'on contraint chaque requête issue d'une application (4) de la seconde famille, émise sur le réseau à destination de la seconde unité, à ne pas inclure un marquage associé à la première famille, ledit marquage étant inclus dans certaines au moins dès requêtes émises sur le réseau et issues d'applications (3) de la première famille.
7. Procédé selon l'une quelconque des revendications précédentes, dans lequel la seconde unité (1) examine si le marquage est présent dans une requête reçue sur le réseau (R) depuis la première unité (2), pour évaluer un degré. de confiance à attacher à ladite requête.
8. Procédé selon la revendication 7, dans lequel, lorsque le marquage est présent dans ladite requête, la seconde unité (1) examine en outre des données incluses dans ce marquage, pour évaluer un degré de confiance à attacher à ladite requête.
9. Procédé selon la revendication 8, dans lequel lesdites données examinées par la seconde unité (1 ) comprennent des données relatives à la certification d'une signature de l'application dont est issue la requête.
10. Procédé selon la revendication 8, dans lequel lesdites données examinées par la seconde unité (1) comprennent des données relatives à une adresse de téléchargement de l'application dont est issue la requête.
11. Procédé selon l'une quelconque des revendications précédentes, dans lequel les requêtes comprennent des requêtes HTTP, et le marquage est inséré dans les en-têtes des requêtes HTTP.
12. Procédé selon l'une quelconque des revendications précédentes, dans lequel la contrainte relative au marquage est contrôlée par une couche logicielle (5) appartenant à une machine virtuelle (6) dont est pourvue la première unité (2), les applications (4) de la seconde famille ne pouvant accéder au réseau (R) qu'à travers la machine virtuelle et ladite couche logicielle.
13. Procédé selon la revendication 12, dans lequel la machine virtuelle (6) est une machine virtuelle Java.
14. Terminal de communication (2), comprenant des moyens de mise en œuvre d'un procédé selon l'une quelconque des revendications précédentes en tant que première unité.
EP03778464A 2002-12-18 2003-10-27 Procede et terminal de communication entre deux unites Withdrawn EP1590936A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0216092A FR2849311B1 (fr) 2002-12-18 2002-12-18 Procede de communication entre deux unites, et terminal mettant en oeuvre le procede
FR0216092 2002-12-18
PCT/FR2003/003181 WO2004066580A1 (fr) 2002-12-18 2003-10-27 Procede et terminal de communication entre deux unites

Publications (1)

Publication Number Publication Date
EP1590936A1 true EP1590936A1 (fr) 2005-11-02

Family

ID=32406157

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03778464A Withdrawn EP1590936A1 (fr) 2002-12-18 2003-10-27 Procede et terminal de communication entre deux unites

Country Status (7)

Country Link
US (1) US20060080448A1 (fr)
EP (1) EP1590936A1 (fr)
JP (1) JP2006511890A (fr)
CN (1) CN1729670A (fr)
AU (1) AU2003285463A1 (fr)
FR (1) FR2849311B1 (fr)
WO (1) WO2004066580A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE602006020288D1 (de) * 2005-08-03 2011-04-07 St Ericsson Sa Sicheres endgerät, routine und verfahren zum schützen eines geheimen schlüssels
JP4856182B2 (ja) * 2005-08-12 2012-01-18 エヌエックスピー ビー ヴィ ソフトウェアアプリケーションセキュリティ方法およびシステム
FR2911022A1 (fr) * 2006-12-29 2008-07-04 France Telecom Procede permettant d'imposer une politique de securite a une application telechargeable accedant a des ressources du reseau
JP5644770B2 (ja) * 2009-11-09 2014-12-24 日本電気株式会社 アクセス制御システム、サーバ、およびアクセス制御方法
US8997220B2 (en) * 2011-05-26 2015-03-31 Microsoft Technology Licensing, Llc Automatic detection of search results poisoning attacks
US20200364354A1 (en) 2019-05-17 2020-11-19 Microsoft Technology Licensing, Llc Mitigation of ransomware in integrated, isolated applications

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010044819A1 (en) * 1997-11-07 2001-11-22 International Business Machines Corporation Relay server for unsigned applets

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020141376A1 (en) * 2000-09-18 2002-10-03 Sharp Labs Of America Devices, softwares, and methods for wireless devices to form a network on the fly by performing admission control in the second layer
JP4750254B2 (ja) * 2000-09-19 2011-08-17 テックファーム株式会社 情報配信サーバシステム、当該システムのアプリケーション認証方法及び記録媒体
US6968356B1 (en) * 2000-10-19 2005-11-22 International Business Machines Corporation Method and apparatus for transferring data between a client and a host across a firewall
US20040205119A1 (en) * 2002-03-26 2004-10-14 Streble Mary C. Method and apparatus for capturing web page content development data
US7185202B2 (en) * 2003-03-12 2007-02-27 Oracle International Corp. Method and apparatus for obtaining an electronic signature from a browser
US7591017B2 (en) * 2003-06-24 2009-09-15 Nokia Inc. Apparatus, and method for implementing remote client integrity verification

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010044819A1 (en) * 1997-11-07 2001-11-22 International Business Machines Corporation Relay server for unsigned applets

Also Published As

Publication number Publication date
US20060080448A1 (en) 2006-04-13
CN1729670A (zh) 2006-02-01
WO2004066580A1 (fr) 2004-08-05
JP2006511890A (ja) 2006-04-06
FR2849311A1 (fr) 2004-06-25
FR2849311B1 (fr) 2005-04-15
AU2003285463A1 (en) 2004-08-13

Similar Documents

Publication Publication Date Title
US8291475B2 (en) Secure cross-domain communication for web mashups
JP4734592B2 (ja) クライアントリダイレクトによるプライベートネットワークへの安全なアクセス提供方法およびシステム
US20190207961A1 (en) Malware detector
US7565533B2 (en) Systems and methods for providing object integrity and dynamic permission grants
US8489878B2 (en) Communication across domains
EP2692089B1 (fr) Mécanisme de redirection entrante sur un proxy inverse
US7367051B1 (en) Automated methods and processes for establishing media streaming connections through firewalls and proxy servers and countermeasures thereto
AU2002252371A1 (en) Application layer security method and system
EP1381949A1 (fr) Procede et systeme de securite de couches d&#39;applications
US8996715B2 (en) Application firewall validation bypass for impromptu components
EP1574002B1 (fr) Procédé de communication de confiance entre deux unites
US8572219B1 (en) Selective tunneling based on a client configuration and request
EP1590936A1 (fr) Procede et terminal de communication entre deux unites
EP3549330B1 (fr) Procédé et système pour réaliser une operation sensible au cours d&#39;une session de communication
Hindocha Threats to instant messaging
Bongard et al. Reverse Shell via Voice (SIP, Skype)
KR100805316B1 (ko) 명령어 코드 통제리스트 기반의 웹 서비스 보안시스템 및그 방법
Jakobsson Peer-to-peer communication in web browsers using WebRTC A detailed overview of WebRTC and what security and network concerns exists
Caswell et al. Nessus, Snort, and Ethereal Power Tools: Customizing Open Source Security Applications
Fu et al. Security aspects of full-duplex web interactions and WebSockets
KR20160142101A (ko) 드라이브 바이 다운로드를 차단하는 네트워크 보안 시스템 및 방법
Oezer “The Evil Karmetasploit Upgrade
Kizza et al. Scripting and Security in Computer Networks and Web Browsers
Ferreira et al. Android OTA Update
Joelsson Mobile web browser extensions: Utilizing local device functionality in mobile web applications

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20050610

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: AL LT LV MK

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

Effective date: 20070119

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

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

18D Application deemed to be withdrawn

Effective date: 20100504