FR 2946822 A1 20101217 FR 0953907 A 20090611 La présente invention concerne le domaine de la sécurité informatique et plus précisément le domaine de la protection des informations personnelles confidentielles permettant l'accès chiffré à un service distant. Aujourd'hui, grâce au développement important du réseau Internet, l'utilisateur peut accéder à un nombre grandissant de services dits � en ligne �. La plupart de ces services nécessitent une authentification de l'utilisateur pour lui permettre l'accès à des données qui le concernent. On peut citer comme exemple de tels services, l'accès aux données de son compte bancaire, le suivi de ses opérations de remboursement de prestations médicales ou encore la déclaration d'impôts en ligne. La Fig. 1 illustre l'architecture du réseau. L'utilisateur utilise typiquement un terminal 1.1 tel qu'un ordinateur personnel ou tout dispositif similaire tel qu'un assistant personnel ou un téléphone intelligent (smartphone en anglais). Ce terminal est connecté à un réseau d'échange d'informations 1.2, typiquement le réseau Internet. Sur ce réseau sont également connectés des serveurs 1.3 hébergeant les services distants. L'utilisateur peut donc accéder depuis son terminal aux services hébergés sur les serveurs 1.3 par l'intermédiaire du réseau d'échange d'informations 1.2. Nombre de ces services traitent d'informations confidentielles et il est important de sécuriser l'accès à ces services. Cette sécurisation passe généralement par la mise à disposition de l'utilisateur d'informations de connexion secrètes qu'il doit produire pour établir la connexion au service. Typiquement il s'agit d'un nom d'utilisateur et d'un mot de passe associé. Lors de la connexion, l'utilisateur se voit demander d'entrer ce nom et ce mot de passe qui servent à l'authentification et à l'établissement d'une connexion chiffrée permettant d'assurer la confidentialité des échanges d'informations entre l'utilisateur et le service distant. Il est courant de sécuriser ces échanges d'informations de connexion pour éviter qu'elles puissent être dérobées lors de leur transport entre le terminal et le serveur. Cette sécurisation se fait typiquement par la création d'une connexion chiffrée ou d'un tunnel chiffré entre le terminal et le serveur. Cette connexion chiffrée ou tunnel peut, par exemple, être créée en utilisant le protocole SSL (Secure Socket Layer en anglais), ou son successeur TLS (Transport Layer Security en anglais). La Fig. 2 illustre l'utilisation de ces techniques. Le terminal envoie une requête en connexion 2.1, généralement à l'aide de son navigateur Internet au serveur hébergeant le service. Cette requête n'est pas chiffrée. Elle est interprétée par le serveur lors d'une étape 2.2 qui répond par le message 2.3 comportant une clé publique correspondant au certificat identifiant le serveur ou le service. Le terminal détermine une clé symétrique pseudo aléatoire lors d'une étape 2.4. Il la chiffre à l'aide de la clé publique du serveur reçue dans le message 2.3 et il l'envoie au serveur dans le message 2.5. Seul le serveur est à même de déchiffrer cette clé symétrique à l'aide de sa clé privée associée à sa clé publique. Il effectue ce déchiffrement lors de l'étape 2.6. A ce moment, le terminal et le serveur partagent une même clé secrète, la clé symétrique, et sont donc à même d'établir une connexion chiffrée 2.7 à l'aide de cette clé partagée. Cette connexion chiffrée permet ensuite l'échange d'informations entre le terminal et le serveur de manière sécurisée. Toutes les données échangées sont chiffrées à l'aide de la clé secrète partagée et ne sont donc déchiffrables que par les deux extrémités de la connexion chiffrée, le terminal et le serveur, qui partagent le même secret. On voit que ce procédé permet de sécuriser les échanges entre le terminal et le serveur. Par contre, les données échangées sont manipulées en clair par le serveur et le terminal. On suppose a priori que le serveur est sûr du fait d'une gestion par des professionnels. Par contre, la sécurité du terminal pose problème. En effet, les utilisateurs sont rarement au fait des techniques permettant d'assurer la sécurité d'un poste de traitement de l'information. De plus, il est extrêmement difficile d'obtenir de leur part un strict respect des règles de sécurité. Il n'est pas rare que le terminal de l'utilisateur soit infecté par des virus, des logiciels- espions ou tout type de logiciels malicieux (malware en anglais). Ces logiciels malicieux sont susceptibles de découvrir les informations confidentielles manipulées par le terminal et de les envoyer à des tiers pouvant en faire un mauvais usage. Et ceci, même lorsque des techniques de sécurité comme celles précédemment décrites sécurisent le lien entre le terminal et le serveur. Il s'avère que le point faible du système, en ce qui concerne la sécurité, est le terminal de l'utilisateur. L'utilisateur peut également être vu comme un point faible de sécurité du fait, par exemple, d'un choix de mot de passe simple, peu robuste ou de la communication de celui-ci. Ces problèmes de sécurité posent un réel problème au développement des services en ligne. Ils provoquent des préjudices importants pour les acteurs économiques de ce secteur. L'invention vise à résoudre les problèmes précédents en offrant un dispositif et un procédé permettant la sécurisation des informations confidentielles de l'utilisateur et leurs échanges de manière sûre avec les serveurs hébergeant les services. Elle se base sur la personnalisation d'une carte à puce contenant ces informations. Cette carte à puce, connectée au terminal de l'utilisateur, possède des moyens de connexion lui permettant d'apparaître comme un hôte autonome du réseau local de l'utilisateur. Une connexion chiffrée est alors établie directement entre la carte à puce et le serveur hébergeant le service pour la transmission des données confidentielles. Ces données, stockées sur la carte à puce, sont alors échangées avec le serveur par cette connexion chiffrée. Elles ne sont jamais accessibles en clair sur le terminal de l'utilisateur. L'invention concerne un dispositif d'accès sécurisé à un service distant comportant une carte à puce; des moyens de connexion de la carte à puce à un terminal utilisateur connecté à un réseau de communication; des moyens de communication avec le terminal utilisateur auquel le dispositif est connecté; des moyens de communication avec un serveur hébergeant le service distant, ledit serveur étant connecté au réseau de communication, lesdits moyens de communication établissant la communication par l'intermédiaire du terminal utilisateur auquel est connecté le dispositif; des moyens de stockage de l'adresse dudit serveur hébergeant le service distant et de moyens d'authentification auprès de ce serveur; des moyens d'établir une connexion chiffrée entre le dispositif et le serveur hébergeant le service distant à l'aide desdits identifiants de connexion et des moyens de relayer le trafic entre le terminal utilisateur et le serveur par ladite connexion chiffrée. Selon un mode de réalisation particulier de l'invention, il comporte en outre des moyens d'authentification de l'utilisateur. Selon un mode de réalisation particulier de l'invention, les moyens d'authentification sont des moyens biométriques. Selon un mode de réalisation particulier de l'invention, le dispositif comporte en 25 outre des moyens de stockage d'une liste de services accessibles et des moyens d'offrir un choix parmi cette liste. Selon un mode de réalisation particulier de l'invention, le dispositif comporte en outre des moyens de stockage d'un logiciel client permettant l'accès au service sécurisé lorsqu'il est exécuté sur le terminal utilisateur. 30 L'invention concerne également un procédé de connexion à un service distant qui comporte une étape d'établissement d'une connexion chiffrée entre un dispositif comportant une carte à puce et un serveur distant hébergeant un service sécurisé, ledit dispositif étant connecté à un terminal utilisateur lui-même connecté à un réseau de communication, ledit serveur distant étant accessible par le réseau de communication, la connexion chiffrée étant établie par routage de la communication par le terminal utilisateur, ladite connexion chiffrée étant établie à l'aide d'identifiants de connexion stockés sur ledit dispositif et une étape d'utilisation du service depuis le terminal utilisateur, le trafic entre le terminal et le serveur distant étant relayé par ledit dispositif par ladite connexion chiffrée. Selon un mode de réalisation particulier de l'invention, le dispositif stockant une liste de services accessibles avec les identifiants correspondants, le procédé comporte en outre une étape de proposition de la liste des services à l'utilisateur et une étape de choix du service avec lequel établir la connexion chiffrée. Selon un mode de réalisation particulier de l'invention, le procédé comporte une étape préalable d'authentification de l'utilisateur. Selon un mode de réalisation particulier de l'invention, le procédé comporte une étape préalable de chargement d'un logiciel d'accès au service distant depuis le dispositif sur le terminal utilisateur. Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : La Fig. 1 illustre l'architecture du réseau ; La Fig. 2 illustre un exemple de connexion à un service sécurisé selon l'art antérieur ; La Fig. 3 illustre l'architecture de principe d'un exemple de réalisation de l'invention ; La Fig. 4 illustre l'architecture protocolaire d'un exemple de réalisation de l'invention ; La Fig. 5 illustre le processus d'utilisation d'un service sécurisé selon un exemple de réalisation de l'invention. Dans l'architecture d'accès à un service sécurisé distant par un utilisateur, le point faible du point de vue de la sécurité est le terminal de l'utilisateur. En effet, l'utilisateur est rarement au fait des règles de sécurité permettant de se prémunir d'une contamination du poste par des logiciels malveillants. En particulier, il n'est pas rare que le terminal des utilisateurs soit envahi par des logiciels tels que des virus informatiques ou des logiciels-espions. Certains de ces logiciels malveillants, une fois opérationnels sur le terminal, sont à même d'espionner les actions de l'utilisateur et de prendre connaissance des informations potentiellement confidentielles de celui-ci. Parmi les informations confidentielles sensibles, on peut citer les informations permettant à l'utilisateur de se connecter à des services distants sécurisés tels que le site de sa banque, des sites de commerces électroniques ou autres. Une fois en possession de ces données sensibles, ces logiciels malveillants sont susceptibles d'utiliser la connexion réseau du poste pour expédier ces informations sensibles à des tiers pouvant en faire un usage frauduleux. Outre le préjudice direct dû à ces actes de piraterie, l'existence même de la menace est un frein considérable à l'essor des services en ligne de part la perte de confiance de l'utilisateur. I1 est donc particulièrement important de fournir à l'utilisateur le moyen d'accéder de manière sécurisée à des services distants. La Fig. 3 illustre l'architecture d'un exemple de réalisation de l'invention. Le terminal du client 3.1 possède une première interface réseau 3.2 permettant la connexion du terminal au réseau Internet 3.5. Sur ce réseau sont disponibles des serveurs hébergeant des services. Un de ces serveurs 3.6 est représenté connecté au réseau 3.5. Le dispositif selon l'invention 3.4 est connecté au terminal 3.1 par une seconde interface réseau 3.3. Cette seconde interface réseau est basée dans l'exemple de réalisation de l'invention sur une interface physique série USB. Les flèches 3.7 et 3.8 représentent les flux de données lors de l'utilisation du dispositif pour une connexion de l'utilisateur à un service sécurisé. La flèche 3.7 entre le dispositif 3.4 et le serveur 3.6 illustre la connexion chiffrée qui est établie entre ces deux éléments. Cette connexion chiffrée est relayée par le terminal qui fonctionne alors comme un simple routeur réseau. Les données transférées sont protégées contre toute attaque de la part d'un éventuel logiciel malveillant sur le terminal 3.1 par le chiffrement utilisé pour établir la connexion chiffrée. Le terminal n'a donc aucun moyen d'accès à ces données bien qu'elles transitent par lui. La flèche 3.8 représente en fait deux flux de données différents transitant entre le terminal et le dispositif 3.4. Dans un premier temps, l'utilisateur peut être obligé de s'authentifier auprès du dispositif pour empêcher une utilisation frauduleuse. Il doit aussi, du moins lorsque le dispositif héberge plusieurs services, sélectionner le service auquel il veut accéder pour que le dispositif amorce la connexion à ce service. Les données confidentielles permettant cette connexion peuvent comprendre des couples nom de connexion et mot de passe, des certificats numériques de chiffrement et toute information nécessaire en fonction de la mise en oeuvre du service. Un module logiciel présent sur le dispositif établit alors la connexion chiffrée avec le serveur 3.6. Une fois cette connexion chiffrée établie, l'utilisateur peut utiliser le service depuis le terminal 3.1. Cette utilisation se fait par interaction, flèche 3.8, avec un module logiciel sur le dispositif permettant le relais des informations entre le serveur et l'utilisateur par la connexion chiffrée 3.7. Plusieurs mises en oeuvre peuvent être utilisées ici se différenciant par le niveau d'intelligence du logiciel embarqué sur le dispositif. Une solution est la suivante : le dispositif se contente d'un relais (proxy en anglais) au niveau de la couche de transport du réseau, en l'occurrence TCP/IP (Transmission Control Protocol / Internet Protocol en anglais défini par les RFC 791 et 793). Le modèle client-serveur est mis en oeuvre entre un client hébergé sur le terminal, par exemple un client HTTP (HyperText Transfer Protocol en anglais défini par la RFC 2616) ou navigateur et le dispositif. Ce même modèle est également mis en oeuvre entre le dispositif qui héberge le client, et le service distant auquel l'utilisateur désire accéder. L'exemple de réalisation de l'invention est basé sur l'utilisation d'une carte à puce insérée dans un lecteur de carte à puce connecté en USB au terminal client. Une première adaptation vise à permettre la communication en TCP/IP au-dessus de la connexion USB. Pour ce faire, le choix s'est porté sur l'utilisation du protocole RNDIS (Remonte Network Driver Interface Specification développé par Microsoft). Il s'agit d'une spécification pour périphériques réseaux fonctionnant sur un bus comme par exemple USB. Ce choix permet d'être compatible sans nécessiter de paramétrage ou d'ajouter un logiciel particulier avec une large sélection de systèmes d'exploitation du terminal de l'utilisateur tels que Windows Vista, Apple Mac OS X ou Linux, qui intègrent dans leur distribution par défaut la gestion de RNDIS. Sur Windows XP, il est simplement nécessaire d'ajouter un fichier �.inf� de quelques kilo-octets. Ce choix permet donc l'utilisation simple du dispositif selon l'invention avec la plupart des terminaux utilisateurs disponibles sur le marché. L'homme du métier comprend que d'autres choix peuvent être faits sur ce point, plus particulièrement si l'invention est réalisée avec une connexion autre que USB entre le dispositif et le terminal. Il est également nécessaire d'ajouter une pile de communication TCP/IP au système d'exploitation de la carte à puce qui en est généralement dépourvue. Le choix s'est ici porté sur la pile TCP/IP mise en oeuvre dans le système d'exploitation libre Contiki (http://www.sics.se/contiki/). Ce système est un système d'exploitation léger, multitâche, hautement portable qui contient une pile TCP/IP particulièrement adaptée pour un portage sur une carte à puce du fait de ses faibles exigences en ressources et de sa petite taille. Avantageusement, cette pile est rendue encore plus compacte par une désactivation de toutes les fonctions non strictement nécessaires à son fonctionnement. Grâce à la mise en oeuvre de ces deux technologies, la carte à puce au sein de son lecteur USB acquiert le statut d'hôte réseau TCP/IP à part entière. Il suffit alors que le terminal de l'utilisateur soit configuré en relais pour le partage de sa connexion réseau pour que le dispositif ait un accès réseau par cet intermédiaire. La création de la connexion chiffrée entre le dispositif et le serveur hébergeant le service nécessite une couche logicielle de chiffrement. Diverses solutions peuvent être utilisées pour établir la connexion chiffrée telles que IPsec, un ensemble de protocoles permettant de sécuriser le transport de données sur le protocole IP, PPTP (Point to Point Tunneling Protocol en anglais), SSL (Secure Socket Layer en anglais) ou encore son évolution TLS (Transport Layer Security en anglais). L'exemple de réalisation est basé sur l'utilisation de TLS, lequel est avantageusement mis en oeuvre pour utiliser le coprocesseur cryptographique généralement présent sur les cartes à puce. Cette utilisation du coprocesseur cryptographique permet d'améliorer notablement les performances des opérations de chiffrement et de déchiffrement par rapport à une solution purement logicielle. La Fig. 4 illustre les couches protocolaires impliquées dans la mise en oeuvre du mode de réalisation de l'invention. On retrouve le terminal utilisateur 4.1, le dispositif selon l'invention 4.4 et le serveur hébergeant le service sécurisé 4.6. Le terminal utilisateur 4.1 et le dispositif 4.4 possèdent une connexion USB au-dessus de laquelle le protocole RNDIS est porté pour permettre la communication IP. Au-dessus de IP on retrouve de manière classique la couche de transport TCP pour la mise en oeuvre de sessions fiables. Les données transférées sont sécurisées par chiffrement par la couche TLS qui est une évolution de SSL. C'est cette couche qui permet le chiffrement et donc la création de la connexion chiffrée de communication. La couche applicative se base dans l'exemple de réalisation sur un environnement WEB et donc sur le protocole de transport HTTP (HyperText Transfer Protocol en anglais défini par la RFC 2616). Le terminal utilisateur 4.1 dispose d'une seconde interface réseau, typiquement basée sur Ethernet, mais d'autres interfaces comme une interface sans fil Wi-Fi peut aussi être utilisée, qui lui permet de communiquer avec le serveur 4.6. Ce serveur 4.6 possède également les couches IP/TCP/TLS/HTTP déjà citées, typiquement au-dessus d'une interface Ethernet. La flèche 4.8 représente le trafic entre le terminal utilisateur 4.1 et le dispositif 4.4. Typiquement, ce trafic correspond à une phase d'authentification de l'utilisateur auprès du dispositif, au choix du service et au trafic relatif au service choisi que le dispositif renvoie au terminal pour être utilisé par l'utilisateur. La flèche 4.7, quant à elle, représente la connexion chiffrée entre le dispositif 4.4 et le serveur 4.6. Cette connexion chiffrée passe par le terminal fonctionnant en routeur réseau au niveau de la couche IP. La Fig. 5 illustre un exemple d'utilisation de l'invention. Lors d'une première étape 5.1, le dispositif se connecte au terminal. Avantageusement, pour éviter l'utilisation frauduleuse du dispositif lors d'une seconde étape 5.2, l'utilisateur doit s'authentifier auprès du dispositif. Plusieurs solutions d'authentification peuvent être utilisées. Le plus sûr est de doter le dispositif d'un capteur biométrique permettant l'identification, par exemple par un dispositif de reconnaissance d'empreinte digitale exécuté sur le dispositif (Match On Card ou MOC en anglais). De ce fait, aucune entrée relative à l'authentification n'est faite sur le terminal du client et n'est donc susceptible d'être capturée par un logiciel malveillant. Alternativement, une authentification par mot de passe peut être faite. Dans ce cas, l'utilisateur ouvre un navigateur WEB par exemple sur le terminal et se connecte au dispositif. Le dispositif possède un serveur WEB embarqué qui propose une page d'authentification. Avantageusement, le trafic entre le terminal et le dispositif 3.8, 4.8 est également protégé par chiffrement. Cela permet de limiter les risques d'attaques par un logiciel malveillant sur le terminal. Une fois que l'utilisateur est authentifié, le dispositif permet avantageusement à celui-ci de sélectionner l'un des services accessibles offerts lors d'une étape 5.3. Cette étape est optionnelle, le dispositif pouvant être configuré pour offrir uniquement l'accès à un service particulier. Cette étape peut être mise en oeuvre par l'intermédiaire d'une page WEB transmise par HTTP au terminal. L'utilisateur peut alors sélectionner le service désiré lors d'une étape 5.4 de choix du service. Lorsque le service est choisi, le dispositif établit la connexion chiffrée avec le serveur hébergeant le service choisi lors d'une étape 5.5. Cette connexion chiffrée est réalisée par la couche de sécurisation TLS dans l'exemple de réalisation. Pour ce faire, le dispositif dispose de l'adresse du service ainsi que des moyens d'authentification auprès du serveur, par exemple les identifiants nécessaires à la connexion au serveur ou au service. Ces données confidentielles sont inscrites dans la carte lors d'une étape préalable de personnalisation de celle-ci. Elles bénéficient des techniques de protection tant contre les attaques logicielles que matérielles intrinsèques aux cartes à puce. Cette programmation préalable de la carte peut être faite à l'aide d'un logiciel dédié sur le terminal. Avantageusement, cette étape de personnalisation est faite avant la distribution de la carte à l'utilisateur, par exemple par un prestataire de service pouvant être le gestionnaire d'un des services sécurisés, par exemple un établissement bancaire. Ces paramètres consistent typiquement en une liste de services accessibles et pour chaque service sont disponibles l'adresse du service et les identifiants de connexion, avantageusement un certificat numérique de chiffrement. Une fois la connexion chiffrée établie, le service peut être utilisé de manière classique. Le dispositif fonctionne alors comme relais (proxy en anglais) du trafic HTTP entre le terminal utilisateur et le service. L'utilisateur peut utiliser le service, lors d'une étape 5.6, à l'aide de son navigateur WEB comme s'il était directement connecté au serveur via son terminal. Le trafic HTTP est dirigé vers le dispositif qui le relaie vers le serveur au travers de la connexion chiffrée. Le trafic repasse donc sur le terminal, mais chiffré, le terminal fonctionnant comme simple routeur IP. A la fin de la session, le dispositif ferme la connexion chiffrée lors d'une étape 5.7. Si une connexion, par exemple chiffrée, était établie entre le terminal et le dispositif, cette connexion est également fermée lors de l'étape 5.8. Alternativement, il est possible d'augmenter encore la sécurité du système en autorisant la connexion au dispositif uniquement à partir d'un logiciel client fourni par le système et non pas depuis le navigateur WEB du terminal. Ce logiciel client peut être un navigateur WEB, mais peut également être aussi un client basé sur un protocole différent éventuellement développé pour l'occasion. Avantageusement, ce client est stocké de manière sécurisée et non modifiable sans autorisation sur la carte au sein d'un espace de stockage. Cet espace de stockage peut alors être vu depuis le terminal comme un périphérique de stockage amovible visible depuis le terminal lorsque le dispositif est connecté. Ce logiciel permet l'accès au service sécurisé lorsqu'il est exécuté sur le terminal utilisateur. L'utilisation du dispositif comporte alors une étape préalable de chargement de ce logiciel d'accès depuis le dispositif sur le terminal utilisateur. On évite ainsi toute manipulation et/ou espionnage des échanges par modification du logiciel client. Ce faisant, l'utilisateur peut se connecter à un service sécurisé sans qu'à aucun moment, l'adresse du service ni les identifiants de connexion soient présents en clair sur le terminal. Éventuellement, ces informations ne sont même jamais portées à la connaissance de l'utilisateur à qui on fournit une carte personnalisée prête à l'emploi. REVENDICATIONS1/ Dispositif d'accès sécurisé à un service distant comportant : - une carte à puce ; - des moyens de connexion de la carte à puce à un terminal utilisateur connecté à un réseau de communication ; caractérisé en ce qu'il comporte en outre : - des moyens de communication avec le terminal utilisateur auquel le dispositif est connecté ; - des moyens de communication avec un serveur hébergeant le service distant, ledit serveur étant connecté au réseau de communication, lesdits moyens de communication établissant la communication par l'intermédiaire du terminal utilisateur auquel est connecté le dispositif ; - des moyens de stockage de l'adresse dudit serveur hébergeant le service distant et de moyens d'authentification auprès de ce serveur ; - des moyens d'établir une connexion chiffrée entre le dispositif et le serveur hébergeant le service distant à l'aide desdits identifiants de connexion ; - des moyens de relayer le trafic entre le terminal utilisateur et le serveur par ladite connexion chiffrée. 2/ Dispositif selon la revendication 1, caractérisé en ce qu'il comporte en outre des moyens d'authentification de l'utilisateur. 3/ Dispositif selon la revendication 2, caractérisé en ce que les moyens 25 d'authentification sont des moyens biométriques. 4/ Dispositif selon l'une des revendications 1 à 3, caractérisé en ce que le dispositif comporte en outre des moyens de stockage d'une liste de services accessibles et des moyens d'offrir un choix parmi cette liste. 5/ Dispositif selon l'une des revendications 1 à 4, caractérisé en ce que le dispositif comporte en outre des moyens de stockage d'un logiciel client permettant l'accès au service sécurisé lorsqu'il est exécuté sur le terminal utilisateur. 306/ Procédé de connexion à un service distant caractérisé en ce qu'il comporte les étapes suivantes : - une étape d'établissement d'une connexion chiffrée entre un dispositif comportant une carte à puce et un serveur distant hébergeant un service sécurisé, ledit dispositif étant connecté à un terminal utilisateur lui-même connecté à un réseau de communication, ledit serveur distant étant accessible par le réseau de communication, la connexion chiffrée étant établie par routage de la communication par le terminal utilisateur, ladite connexion chiffrée étant établie à l'aide d'identifiants de connexion stockés sur ledit dispositif ; - une étape d'utilisation du service depuis le terminal utilisateur, le trafic entre le terminal et le serveur distant étant relayé par ledit dispositif par ladite connexion chiffrée. 7/ Procédé selon la revendication 6, caractérisé en ce que le dispositif stockant une liste de services accessibles avec les identifiants correspondants, il comporte en outre : - une étape de proposition de la liste des services à l'utilisateur ; - une étape de choix du service avec lequel établir la connexion chiffrée. 8/ Procédé selon l'une des revendications 6 à 7, caractérisé en ce qu'il comporte une étape préalable d'authentification de l'utilisateur. 9/ Procédé selon l'une des revendications 6 à 8, caractérisé en ce qu'il comporte une étape préalable de chargement d'un logiciel d'accès au service distant depuis le dispositif sur le terminal utilisateur.