Brevet FR2980062A1 — publié le 20130315

Domaine de l'invention L'invention concerne un procédé d'échange sécurisé de données entre un dispositif de communication et un fournisseur de services via un réseau de communication, ainsi que la création et la gestion de communautés d'utilisateurs. Etat de la technique Il est connu que des utilisateurs accèdent à des services, par exemple des jeux, vidéos, ou partage d'informations, proposés par des fournisseurs de service. Les fournisseurs de service sont en général des fournisseurs spécialisés, ou des opérateurs de télécommunication proposant à leurs abonnés des contenus ou services spécifiques. A cet effet, les utilisateurs disposent d'un dispositif de communication, comme par exemple un décodeur numérique, qui leur permet d'accéder aux services proposés par les fournisseurs de services, via un réseau de communication, notamment de type Internet. En général, un même dispositif de communication est utilisé par plusieurs utilisateurs, comme par exemple dans le cas d'une famille comprenant plusieurs personnes. Les échanges entre le dispositif de communication et le fournisseur de services doivent être sécurisés, afin d'éviter que des tiers n'accèdent à des informations personnelles de l'utilisateur. A cet effet, des protocoles de sécurisation des échanges de données existent, comme les certificats SSL (de l'anglais Secure Socket Layer), et HTTPS (de l'anglais Hypertext Transfer Protocol Secure). Toutefois, les procédés d'échange sécurisé de l'état de la technique peuvent être détournés par des tiers, qui peuvent par exemple proposer de faux certificats SSL aux utilisateurs. En particulier, ces échanges sont sensibles aux attaques dites de l'homme du milieu, qui concerne un tiers réussissant à intercepter les communications entre le dispositif de communication et le fournisseur de services, notamment en se faisant passer pour un relais ou un routeur. Par ailleurs, comme souligné auparavant, le même dispositif de communication est le plus souvent utilisé par une pluralité d'utilisateurs. Le fournisseur de services souhaite pouvoir distinguer les utilisateurs d'un même dispositif de communication, afin d'offrir des services adaptés et personnalisés. De même, chaque utilisateur souhaite pouvoir utiliser les services, comme par exemple les réseaux sociaux ou les comptes de messagerie, sans que les autres utilisateurs n'aient accès à ses données. Enfin, le fournisseur de services souhaite pouvoir offrir à chaque utilisateur la possibilité de créer ou de se connecter à des communautés d'utilisateurs, afin de favoriser les échanges et de diversifier les services proposés aux utilisateurs. Toutefois, à ce jour, il n'existe pas de solution permettant de répondre à ces besoins, notamment en termes de sécurité, de facilité d'utilisation, et d'efficacité. Présentation de l'invention Il est proposé, dans un mode de réalisation, un procédé d'échange sécurisé de données entre un dispositif de communication et un serveur d'un fournisseur de services via un réseau de communication, le dispositif de communication permettant à au moins un utilisateur du dispositif de communication d'utiliser des services fournis par le fournisseur de services, ledit procédé étant caractérisé en ce qu'il comprend les étapes d'échange de données entre le dispositif de communication et le serveur du fournisseur de services consistant à : - crypter, pour l'envoi de données, au moins une partie des données envoyées, par l'intermédiaire d'une clé matérielle, connue du fournisseur de services, et stockée matériellement dans une mémoire morte d'une puce électronique du dispositif de communication, et - décrypter, lors de la réception de données, les données reçues, par l'intermédiaire de cette clé matérielle. Dans un mode de réalisation, les données échangées comprennent au moins l'une des informations suivantes : - un identifiant unique propre au dispositif de communication, permettant au serveur du fournisseur de services d'identifier le dispositif de communication, le serveur du fournisseur de services utilisant cette identifiant pour trouver la clé matérielle associée au dispositif de communication, - un identifiant de service, propre à chaque service demandé par l'utilisateur via le dispositif de communication, permettant au serveur fournisseur de services d'identifier le service demandé par l'utilisateur via le dispositif de communication, - une information relative à un index utilisé pour choisir une clé transmise sur le réseau de communication, - un protocole de communication sécurisée entre le dispositif de communication et le serveur du fournisseur de services. Dans un mode de réalisation, les données échangées entre le dispositif de communication et le serveur fournisseur de services comprennent au moins une clé de premier niveau, elle-même cryptée par au moins une clé de deuxième niveau, ce cryptage successif étant réalisé jusqu'à une clé de niveau n, avec n un entier supérieur ou égal à deux, la clé de premier niveau étant cryptée par la clé matérielle. Dans un mode de réalisation, chaque utilisateur s'enregistre auprès du dispositif de communication, et se voit attribuer une clé publique asymétrique qui lui est propre, ainsi qu'une clé privée asymétrique qui lui est propre. Les données échangées entre le dispositif de communication et le serveur du fournisseur de services comprennent la clé publique asymétrique propre à l'utilisateur, ladite clé publique asymétrique étant cryptée ou non cryptée par la clé matérielle, la clé publique asymétrique permettant d'identifier l'utilisateur, et/ou des services du fournisseur de service associés à cet utilisateur. Dans un mode de réalisation, les données échangées entre le dispositif de communication et le serveur du fournisseur de services permettent la création et l'accès à des communautés regroupant une pluralité d'utilisateurs et des services spécifiques. En particulier, un utilisateur peut demander l'accès à une communauté publique, gérée par le fournisseur d'accès. Cet accès est réalisé via l'association par le serveur du fournisseur de services de la clé publique asymétrique de l'utilisateur avec la communauté publique. De même, un utilisateur peut demander l'accès à une communauté privée, gérée par un autre utilisateur. Cet accès est réalisé, après accord de l'autre utilisateur, via l'association par le serveur du fournisseur de services de la clé publique asymétrique de l'utilisateur avec la communauté privée. Dans un mode de réalisation, l'échange de données entre le serveur du fournisseur de services et des utilisateurs membres d'une même communauté comprend l'étape selon laquelle une clé pluri-utilisateurs, commune à au moins une partie des utilisateurs de la communauté, est utilisée pour crypter les données échangées. En particulier, selon un aspect, l'envoi de données du serveur du fournisseur de services vers des utilisateurs membres d'une même communauté, lesdites données étant identiques pour les utilisateurs, comprend l'étape selon laquelle le serveur du fournisseur de services envoie une seule fois ces données, cryptées par la clé pluri-utilisateurs, vers le réseau de communication qui les renvoie vers chaque utilisateur membre de la même communauté. Dans un mode de réalisation, le serveur du fournisseur de services envoie une clé de cryptage à au moins deux dispositifs de communication d'utilisateurs souhaitant échanger des données entre eux, et les dispositifs de communication échangent des données entre eux directement via le réseau de communication, lesdites données étant cryptées par la clé de cryptage. Les échanges entre le dispositif de communication et le fournisseur de services bénéficient d'une sécurisation accrue. En particulier, les attaques de tiers consistant à s'interposer entre le dispositif de communication et le fournisseur de services ne sont plus possibles. Cette sécurisation accrue n'altère pas l'interface d'utilisation du dispositif de communication, qui est configurée pour rester simple et intuitive pour un utilisateur. En outre, une personnalisation des services et une identification de chaque utilisateur d'un même dispositif de communication est rendu possible. Le fournisseur de services peut proposer des services sécurisés et à forte valeur ajoutée. Ainsi, la création et la gestion de communautés d'utilisateurs, proposant un ou plusieurs services, est rendu possible, de manière efficace et sécurisée. De même, les communications entre différents utilisateurs de différents dispositifs de communication présentent une sécurité accrue, et une efficacité améliorée. Cette sécurisation et cette amélioration de la qualité des services peuvent être obtenues, le cas échéant, sans altération de la bande passante du fournisseur de services. Présentation des figures D'autres caractéristiques et avantages de l'invention ressortiront encore de la description qui suit, laquelle est purement illustrative et non limitative, et doit être lue en regard des dessins annexés sur lesquels : - la Figure 1 est une représentation schématique d'un mode de réalisation d'un système de communication comprenant un dispositif de communication échangeant des données avec un serveur d'un fournisseur de services, via un réseau de communication ; - la Figure 2 est une représentation schématique d'un mode de réalisation d'un dispositif de communication ; - la Figure 3 est une représentation schématique d'un cryptage successifs de clés ; - la Figure 4 est une représentation schématique d'un mode de réalisation de l'enregistrement d'un utilisateur auprès d'un dispositif de communication ; - la Figure 5 est une représentation schématique d'un mode de réalisation d'un format (trame) de données échangées entre un dispositif de communication et un serveur d'un fournisseur de services ; - la Figure 6 est une représentation schématique d'un mode de réalisation de l'accès par un utilisateur à une communauté publique ; - la Figure 7 est une représentation schématique d'un mode de réalisation de l'accès par un utilisateur à une communauté privée ; - la Figure 8 est une représentation schématique d'un mode de réalisation d'échanges entre utilisateurs d'une même communauté ; - la Figure 9 est une représentation schématique d'un mode de réalisation d'échanges entre utilisateurs, et d'échanges entre un fournisseur de services et les utilisateurs. Description détaillée Description d'éléments d'un système de communication On a représenté en Figure 1 un système 37 de communication configuré pour l'échange sécurisé de données 5 entre un dispositif 1 de communication et au moins un serveur 8 d'un fournisseur 2 de services, via un réseau 3 de communication. Le réseau 3 de communication est par exemple, mais non limitativement, un réseau Internet, de type réseau IP (Internet Protocol), ou un réseau de téléphonie de type 3G, ou un réseau local. Le fournisseur 2 de services est un opérateur qui est apte à fournir des services à un utilisateur. On entend notamment par service tout contenu (musique, film, jeux, accès à Internet...), ou système d'échanges entre utilisateurs (réseaux sociaux, échanges vidéo, courriel,...) que le fournisseur 2 de services peut proposer à l'utilisateur par l'intermédiaire de son dispositif 1 de communication. Il s'agit par exemple d'un opérateur de télécommunications, auquel l'utilisateur est abonné pour pouvoir accéder au réseau de communication, l'opérateur fournissant entre outre des services à ses abonnés. Alternativement, il s'agit d'un opérateur de services dédié à la fourniture de services à des utilisateurs. Le fournisseur 2 de services comprend en général au moins un serveur 8 apte à se connecter au réseau 3 de communication, par exemple via des connexions physiques (par exemple, ADSL, ou fibre optique) ou des antennes (par exemple dans le cas de fournisseurs 2 de type opérateurs mobiles). Le fournisseur 2 de services comprend, le cas échéant, une pluralité de connexions physiques (câbles, fibres optiques, etc.), ou une série d'antennes permettant la connexion au réseau 3 de communication. En général, le fournisseur 2 de services comprend plusieurs serveurs 8. Les serveurs 8 gèrent les échanges de données avec les dispositifs 1 de communication, via le réseau 3 de communication. Les serveurs 8 comprennent une pluralité d'unités de traitement, ou d'ordinateurs, des programmes de contrôle, des mémoires, et, le cas échéant, une interface utilisateur. La structure d'un fournisseur de services est classique, et dépend principalement du type de connexion au réseau de communication (ex : opérateur ADSL, 3G ou autres normes de ce type -1G, 2G,...,4G-, Wi-Fi, fibre optique, réseau local, etc.). Comme schématisé en Figure 2, le dispositif 1 de communication comprend des moyens 29 d'accès au réseau 3 de communication, pour échanger des données, via ce réseau 3, avec le serveur 8 du fournisseur 2 de services. Les moyens 29 d'accès sont par exemple des moyens d'émission et de réception radio, ou Wi-Fi, ou de type antenne, ou des moyens filaires, ou tout autre moyen technique permettant de se connecter au réseau 3 de communication. Le dispositif 1 de communication est localisé du côté de l'utilisateur. Par exemple, le dispositif 1 de communication est localisé dans le foyer ou au lieu de travail de l'utilisateur. Alternativement, le dispositif 1 de communication est un dispositif mobile, que l'utilisateur peut emmener avec lui, comme par exemple un dispositif de téléphonie mobile. Le dispositif 1 comprend en outre une interface 30, lui permettant d'interagir avec un utilisateur. L'interface 30 est en général une interface logicielle, qui affiche sur un écran connecté au dispositif 1 des choix et instructions permettant à l'utilisateur de commander le dispositif 1. Alternativement, le dispositif 1 comprend lui-même un écran, et l'interface 30 consiste en l'interface logicielle précitée associée à l'écran. De manière classique, le dispositif 1 de communication comprend des moyens 33 d'alimentation électrique (batterie, prise de courant, etc.) et au moins un processeur 34 gérant les différentes fonctions du dispositif 1. En général, le dispositif 1 de communication comprend également une mémoire 35, de type disque dur ou mémoire amovible, permettant de stocker des données reçues ou échangées. Comme représenté en Figure 2, le dispositif 1 comprend une clé 7 matérielle, inscrite matériellement dans une mémoire 9 morte d'une puce 6 électronique du dispositif 1 de communication. Une mémoire 9 morte est une mémoire dont le contenu est inscrit matériellement une fois pour toutes, lors de la fabrication de la puce 6 comprenant ladite mémoire. Ainsi, son contenu est défini lors de la fabrication, et n'est plus modifiable. La clé 7 matérielle est donc générée lors de la fabrication du dispositif 1 de communication. On entend par puce électronique tout ensemble électronique pouvant comprendre une mémoire morte. La clé 7 matérielle est une clé de cryptage, et permet au dispositif 1 de crypter ou de décrypter des données. Cette clé 7 matérielle est inscrite physiquement dans la mémoire morte de la puce 6 électronique du dispositif 1 de communication. La clé 7 matérielle est un ensemble plus ou moins complexe de bits, ledit ensemble de bits étant réalisé via des composants physiques (transistors, etc.) de la mémoire 9 morte. La clé 7 n'est pas consultable de l'extérieur, par exemple par un logiciel. En effet, la mémoire 9 morte est enfouie dans la puce 6 électronique, de sorte à interdire la consultation de son contenu de l'extérieur par un tiers. Ainsi, seul le fabricant de la puce 6 connaît cette clé 7 matérielle, étant donné qu'il l'a lui-même définie et fabriquée. Lors de l'achat par le fournisseur 2 de services du dispositif 1 de communication, le fabricant de la puce lui communique cette clé 7 matérielle, afin qu'il puisse l'utiliser comme exposé par la suite. Bien sûr, le fournisseur 2 de services peut lui-même fabriquer la puce 6 électronique. Dans un mode de réalisation, non limitatif, il s'agit d'une clé AES (« Advanced Encryption Standard », qui est un algorithme de cryptage symétrique) de 128 bits, ou plus (par exemple 192, 256 bits). D'autres clés, utilisées dans d'autres algorithmes de cryptage, peuvent être utilisés, selon les besoins en sécurité (clés DES de 56 bits, « Data Encryption Standard », clés triple DES de 64 bits, etc.). Ces types de clés ne sont pas limitatifs. Dans un mode de réalisation, cette clé 7 matérielle est unique pour chaque dispositif 1. Echanges sécurisés dans le système de communication Dans un mode de réalisation, il est proposé un procédé d'échange sécurisé de données dans le système 37 de communication, entre le dispositif 1 de communication et le serveur 8 du fournisseur 2 de services via le réseau 3 de communication, le dispositif 1 de communication permettant à au moins un utilisateur 13 du dispositif 1 de communication d'utiliser des services fournis par le fournisseur 2 de services. Ainsi, les échanges de données 5 entre le dispositif 1 de communication et le serveur 8 du fournisseur 2 de services, via le réseau 3 de communication, comprennent, pour l'envoi de données, l'étape consistant à crypter au moins une partie des données 5 envoyées, par l'intermédiaire de la clé 7 matérielle connue du fournisseur 2 de services et inscrite matériellement dans une mémoire morte d'une puce 6 électronique du dispositif 1 de communication. Ainsi, du côté du dispositif 1 de communication, celui-ci transmet les données à envoyer à la puce 6 électronique comprenant la clé matérielle 7, qui lui renvoie les données cryptées. Puis, le dispositif 1 de communication transmet les données cryptées au réseau 3 de communication par l'intermédiaire de ses moyens 29 d'accès au réseau 3 de communication. Il en est de même pour le serveur 8 du fournisseur 2 de services, qui dispose de la clé 7 matérielle, et peut ainsi crypter les données en utilisant cette clé 7, par exemple par l'intermédiaire d'un processeur ou d'une puce électronique. Dans un mode de réalisation, le fournisseur 2 de services détient une puce comprenant cette clé 7, ladite clé 7 étant stockée dans une mémoire morte de ladite puce. Alternativement, ou en complément, le serveur 8 du fournisseur 2 de services stocke une base de données logicielle contenant cette clé, ladite clé étant représentée par des bits constitutifs dans ladite base de données logicielle. Etant donné que la clé 7 matérielle n'est pas échangée sur le réseau 3 de communication, et n'est qu'est connue que du fournisseur 2 de services, les échanges de données sont sécurisés, sans risque d'interception par un tiers. Du côté du dispositif 1, cette clé 7 ne peut être extraite de la mémoire 9 morte puce 6, et n'est même pas connue de l'utilisateur lui-même. Les échanges entre le dispositif 1 de communication et le serveur 8 du fournisseur 2 de services sont donc protégés. Lors de la réception de données 5, les données reçues sont décryptées par l'intermédiaire de cette clé 7 matérielle. Du côté du dispositif 1 de communication, celui-ci transmet les données à décrypter à la puce 6 comprenant la clé 7 matérielle, qui lui renvoie les données décryptées. Il en est de même du côté du serveur 8 du fournisseur 2 de services, qui utilise la clé 7 matérielle et un processeur pour décrypter les données. Dans un exemple de réalisation, détaillé par la suite, les données échangées entre le dispositif 1 de communication et le serveur 8 du fournisseur 2 de services permettent la création et l'accès à des communautés regroupant une pluralité d'utilisateurs et des services spécifiques, l'accès à une communauté permettant d'utiliser ces services et/ou d'échanger des données avec les autres utilisateurs de la communauté. Ainsi, la création et l'accès à ces communautés sont sécurisés grâce à l'échange sécurisé venant d'être décrit. Exemples de données échangées dans le système de communication Divers types de données peuvent être échangés entre le dispositif 1 de communication et le serveur 8 du fournisseur 2 de services. Dans certains échanges, comme par exemple des transactions bancaires, il est nécessaire de transmettre une clé de cryptage par l'intermédiaire du réseau 3 de communication. Dans un mode de réalisation de l'invention, un mécanisme de cryptage successif de clés est utilisé. Ce mode de réalisation est illustré en Figure 3. Dans ce mode de réalisation, les données 5 échangées entre le dispositif 1 de communication et le fournisseur 2 de services comprennent au moins une clé K1 de premier niveau, elle-même cryptée par au moins une clé K2 de deuxième niveau, ce cryptage successif étant réalisé jusqu'à une ou plusieurs clés Kn de niveau n, avec n un entier supérieur ou égal à deux, la clé Kl de premier niveau étant cryptée par la clé 7 matérielle. Les clés K1,...Kn, sont des clés logicielles, c'est-à-dire des suites aléatoires de bits, générés par des logiciels ou des algorithmes dédiés. La clé K1 de premier niveau permet de décrypter l'ensemble des clés des K2 de niveau 2, qui elles-mêmes permettent de décrypter l'ensemble des clés des K3 de niveau 3, et ainsi de suite. Ce mécanisme de cryptage successif renforce la sécurité. Ainsi, si le serveur 8 du fournisseur 2 de services décide de transmettre sur le réseau une clé Kn de niveau n, un tiers devrait trouver les clés K1 à Kn_1 pour pouvoir obtenir la clé Kn échangée. Or, pour trouver la clé K1, il est nécessaire de trouver la clé 7 matérielle, qui permet de décrypter la clé Kl. Toutefois, comme explicité auparavant, la clé 7 matérielle est disposée physiquement et à demeure dans une puce 6 du dispositif 1, sans qu'un tiers ne puisse y accéder. La sécurité de l'échange est donc garantie. Le fournisseur 2 de services peut choisir le nombre de clés correspondant à chaque niveau. Dans un exemple de réalisation, le fournisseur 2 de services fixe 64 clés de niveau 1, permettant chacune de déchiffrer 16 clés de niveau 2, ce qui donne au total 1024 clés de niveau 2 (clé 1, clé n°2, ..., clé n° 1024). Si le service proposé par le fournisseur 2 de services aux utilisateurs du dispositif 1 de communication est une application bancaire, le serveur 8 du fournisseur 2 de services peut par exemple contrôler et programmer le service pour que celui-ci choisisse de manière aléatoire une clé parmi les clés n°1009 à n°1024. Dans un mode de réalisation, le fournisseur 2 de services programme le service pour que celui-ci choisisse de manière aléatoire un nombre, dit index, entre 0 et 15. Le fournisseur 2 de services programme en outre le service pour que chaque index soit associé à une clé parmi les clés n°1009 à n°1024. Le choix de la clé se fait donc par tirage aléatoire de l'index, lui-même associé à une clé. Le tirage aléatoire et le choix des index n'est connu que du fournisseur 2 de services.30 Enregistrement et identification des utilisateurs et du dispositif de communication Dans un mode de réalisation, le fournisseur 2 de services souhaite pouvoir connaître l'identité de l'utilisateur du dispositif 1 de communication. Ceci présente plusieurs intérêts, comme la personnalisation des services proposés à l'utilisateur, le suivi de son profil et de sa consommation, la protection de ses données par rapport à d'autres utilisateurs, etc. Ainsi, selon un mode de réalisation, un enregistrement de l'utilisateur 13 auprès du dispositif 1 de communication est effectué, le résultat de cet enregistrement étant communiqué au serveur 8 du fournisseur 2 de services par le réseau 3 de communication. Ceci est illustré en Figure 4, dans laquelle un utilisateur 13 s'enregistre (étape 101) auprès du dispositif 1 de communication qui génère : - au moins une clé 11 publique asymétrique propre à l'utilisateur 13 (étape 104) et transmise au serveur 8 du fournisseur 2 de services (étape 105), et - une clé privée asymétrique propre à l'utilisateur 13 (étape 101) et stockée dans le dispositif 1 de communication (étape 103). Le dispositif 1 de communication décide du type de clé, de la longueur des clés, de la durée de la validité des clés, sans intervention de l'utilisateur. Le cas échéant, le dispositif 1 définit une phrase secrète prise aléatoirement dans un dictionnaire de phrases, et stockée avec la clé privée dans une zone sécurisée du dispositif 1 de communication. Cette phrase secrète est par exemple utilisée dans le processus de création des clés asymétriques, et sert de rappel mnémotechnique. Le serveur 8 du fournisseur 2 de service peut donc reconnaître l'utilisateur 13 via sa clé publique asymétrique qui lui est propre. En effet, dans un mode de réalisation, lorsqu'un utilisateur utilise le dispositif 1 de communication, les données 5 échangées entre le dispositif 1 de communication et le serveur 8 du fournisseur 2 de services comprennent la clé publique asymétrique propre à l'utilisateur 13, la clé publique asymétrique permettant d'identifier l'utilisateur 13, et/ou des services associés à cet utilisateur 13. Dans un mode de réalisation, la clé publique asymétrique de l'utilisateur, transmise lors des échanges du dispositif 1 de communication avec le fournisseur 2 de services, est cryptée par la clé 7 matérielle. Ceci n'est toutefois pas obligatoire. L'enregistrement de l'utilisateur 13 auprès du dispositif 1 de communication s'effectue en général via interaction avec l'interface 30 du dispositif 1 de communication. Dans un exemple de réalisation, l'interface 30 demande à l'utilisateur la définition d'un identifiant et d'un mot de passe, pour l'enregistrement dudit utilisateur. Le cas échéant, l'interface 30 demande à l'utilisateur des informations obligatoires (nom, prénom, courriel) et des informations facultatives (commentaires, pseudonyme, etc.) Une fois ces étapes effectuées, le procédé de génération de clés propres à l'utilisateur est exécuté. Pour éviter qu'un utilisateur d'un dispositif 1 de communication ne tente de s'identifier frauduleusement à la place d'un autre utilisateur de ce dispositif 1, il est prévu, dans un mode de réalisation, que la saisie erronée de plusieurs (par exemple trois) mots de passe entraîne le blocage du dispositif 1 de communication. Ce blocage ne peut être levé que par le fournisseur 2 d'accès. Dans un mode de réalisation, les données 5 échangées entre le dispositif 1 de communication et le serveur 8 du fournisseur 2 de services comprennent un identifiant 15 unique propre au dispositif 1 de communication, permettant au serveur 8 du fournisseur 2 de services d'identifier le dispositif 1 de communication. Un avantage de l'utilisation d'un tel identifiant 15 est que le serveur 8 du fournisseur 2 de services peut rapidement identifier le dispositif 1 de communication qui lui envoie des données, et peut donc sélectionner plus rapidement la clé 7 matérielle correspondant à ce dispositif 1 de communication. L'identifiant 15 est par exemple une suite de chiffres et/ou de lettres. Dans un mode de réalisation, les données 5 échangées entre le dispositif 1 de communication et le serveur 8 du fournisseur 2 de services comprennent un identifiant 16 de service, propre à chaque service demandé par l'utilisateur via le dispositif 1 de communication, et permettant au fournisseur 2 de services d'identifier le service demandé par l'utilisateur via le dispositif 1 de communication. Cet identifiant 16 permet au serveur 8 du fournisseur 2 de services de répondre à la demande d'accès à un service de la part de l'utilisateur, avec un temps de réponse plus court. De même, du côté du dispositif 1 de communication, cet identifiant 16 permet d'accélérer le traitement des données. Dans un mode de réalisation, les données 5 échangées entre le dispositif 1 de communication et le serveur 8 du fournisseur 2 de services comprennent une information relative à un index 17 utilisé pour choisir une clé transmise sur le réseau 3 de communication. Cet index peut être, dans un mode de réalisation, le numéro de la clé. Dans un autre mode de réalisation, l'index permet d'indiquer dans un tableau prédéfini la clé effectivement employée pour chiffrer/déchiffrer. Par exemple, dans le cas d'un tableau de N entrées, l'accès à la clé peut être donné via un calcul prédéfini et uniquement connu de l'opérateur. Un exemple de calcul est : indice de la clé dans le tableau = (nombre prédéfini + index), modulo la taille N du tableau. A nouveau, cet index permet de traiter plus rapidement les données échangées, du côté du fournisseur 2 de services et du côté du dispositif 1 de communication. Dans un mode de réalisation, les données échangées comprennent un protocole 18 de communication sécurisée entre le dispositif 1 de communication et le fournisseur 2 de services. Il s'agit par exemple d'un protocole de type HTPPS (Hypertext Transfer Protocol Secure) ou VPN (Virtual Private Network). Ces différentes modes de réalisation peuvent être combinés, ou non, en fonction des choix du fournisseur de services. Trame de données Dans un mode de réalisation, les données 5 échangées respectent un format de trame spécifique. En Figure 5, un type de trame spécifique est utilisé pour transmettre les données. La trame comprend le protocole 18 de communication sécurisée, l'identifiant 15 unique propre au dispositif 1 de communication, l'identifiant 16 de service, propre à chaque service demandé par l'utilisateur via le dispositif 1 de communication, l'information relative à un index 17 utilisé pour choisir une clé transmise sur le réseau 3 de communication. La trame peut comprendre d'autres informations ou qu'une partie de ces informations. La trame comprend en outre une ou plusieurs clés 11 publiques asymétriques propres à l'utilisateur, éventuellement cryptées par la clé 7 matérielle, comme évoqué plus haut. La trame comprend également des contenus 22, échangés entre le dispositif 1 de communication et le fournisseur 2 de services. Ces contenus sont cryptés par la clé matérielle 7. Ces contenus correspondent aux informations utiles liées aux services utilisés par l'utilisateur (texte, vidéos, etc.). Alternativement, les contenus 22 sont cryptés via le mécanisme de cryptage successif précédemment décrit. Les contenus 22 sont alors cryptés successivement par une pluralité de clés de cryptage comprenant en dernier lieu la clé matérielle, comme décrit précédemment. Le fait d'incorporer les échanges de données dans une trame spécifique permet au dispositif 1 et/ou au serveur 8 du fournisseur 2 de services de n'accepter que les échanges qui respectent cette trame, ce qui évite des attaques de tiers consistant à envoyer des blocs de données en masse (technique connue sous l'appellation anglo-saxonne« arp- spoofing »). De plus, ceci facilite le traitement des données, et accélère les échanges. Création et gestion de communautés d'utilisateurs Dans un mode de réalisation, les échanges de données 5 entre le dispositif 1 de communication et le serveur 8 du fournisseur 2 de services concernent la création, la gestion de communautés, ainsi que l'accès à ces communautés. Les différents modes de réalisation d'échanges de données s'appliquent donc ici, en combinaison ou séparément, selon les besoins. Une communauté regroupe une pluralité d'utilisateurs et des services spécifiques. L'accès à une communauté permet d'utiliser ces services spécifiques et/ou d'échanger des données avec les autres utilisateurs de la communauté. Les paramètres de création de la communauté (type de communauté, nombre de membres, nom des utilisateurs, droit d'accès, certaines données, etc.) sont stockés du côté du serveur 8 du fournisseur 2 de services. Grâce aux différents modes de réalisation d'échanges de données décrits précédemment, la création, la gestion de communautés, ainsi que 20 l'accès à ces communautés sont sécurisés. Par exemple, une communauté d'amateurs de pêche à la ligne peut être créée. Ainsi, les utilisateurs membres de cette communauté peuvent échanger entre eux des photos ou du contenu liés à la pêche à la ligne. Les utilisateurs peuvent également dialoguer entre eux, par exemple sur un 25 forum de discussion consacré à la pêche à la ligne. Des services liés à cette communauté incluent donc des forums de discussion, l'accès à des concours de pêche, l'achat de matériel en ligne, la réception de bons promotionnels, etc. Les types de service et d'échanges entre utilisateurs peuvent être 30 modulés selon les besoins. Dans un mode de réalisation, on distingue les communautés 21 publiques des communautés 20 privées (cf. Figure 1). Une communauté 21 publique est gérée par le fournisseur 2 de services, tandis qu'une communauté 20 privée est gérée par un ou plusieurs utilisateurs. En particulier, dans le cas d'une communauté publique, c'est le fournisseur 2 de services, via le serveur 8, qui décide si un autre utilisateur peut, ou non, rejoindre la communauté publique, tandis que dans le cas d'une communauté privée, c'est l'utilisateur responsable de la communauté privée qui prend cette décision. Même si une communauté est publique, le fournisseur de services peut décider que l'accès à cette communauté est payant. De même, les services proposés dans les communautés 21 publiques peuvent être gratuits, payants, ou il peut s'agir d'un mélange de services payants et de services gratuits. On peut également créer des communautés au statut intermédiaire, gérées à la fois par un utilisateur et le fournisseur de services, l'accord de l'utilisateur et du fournisseur étant nécessaires pour autoriser l'accès d'un autre utilisateur. On décrit en référence aux Figures 1 et 6 un mode de réalisation d'une demande d'accès d'un utilisateur 13 à une communauté 21 publique. Un utilisateur 13 demande, via le dispositif 1 de communication, 20 l'accès à une communauté 21 publique proposant au moins un service et/ou l'échange de données entre utilisateurs de cette communauté (étape 201). Cette demande peut être effectuée via l'interface 30 du dispositif 1 de communication, par exemple par sélection de la communauté 21 dans l'interface 30. 25 Cette communauté 21 publique est gérée par le fournisseur 2 de services, qui détermine les services associés à cette communauté ainsi que les droits d'accès des utilisateurs. Comme décrit précédemment, chaque utilisateur 13 qui s'est enregistré auprès du dispositif 1 de communication dispose d'une clé 11 30 publique asymétrique qui lui est propre. Ainsi, le dispositif 1 de communication transmet la clé 11 publique asymétrique propre à l'utilisateur 13 au serveur 8 du fournisseur 2 de services (étape 202). Cette clé 11 est éventuellement cryptée par la clé 7 matérielle du dispositif 1. Le serveur 8 du fournisseur 2 de services associe alors à la communauté 21 publique demandée par l'utilisateur la clé 11 publique asymétrique de l'utilisateur (étape 203), permettant ainsi à l'utilisateur d'utiliser le service ou les services proposés par cette communauté 21. Cette association consiste à stocker dans le serveur 8 une copie de la clé 11 de l'utilisateur, et à l'intégrer dans les paramètres de la communauté 21, lesdits paramètres étant stockés dans le serveur 8. L'accès à la communauté 21 publique ne nécessite pas l'approbation d'un autre utilisateur. Par la suite, lorsque l'utilisateur souhaite accéder aux services de la communauté, le serveur 8 du fournisseur identifie sa clé asymétrique lors des échanges de données, et constate que l'utilisateur possède une clé 15 asymétrique associée à la communauté. Les différents échanges de données avec la communauté sont pratiqués selon un ou plusieurs des différents modes de réalisation précédemment décrits (cryptage par clé matérielle, et/ou utilisation d'une trame de données, etc.). 20 A titre d'exemple, il s'agit d'une communauté 21 qui concerne les amateurs de randonnées. Les services de cette communauté sont par exemple la fourniture de cartes de randonnées, la mise en relation d'amateurs de randonnées, etc. On décrit en référence aux Figures 1 et 7 un mode de réalisation 25 d'une demande d'accès d'un utilisateur 13 à une communauté 20 privée. Un premier utilisateur 131 demande (étape 301), via le dispositif 1 de communication, l'accès à une communauté privée 20 proposant au moins un service et/ou l'échange de données entre utilisateurs de cette communauté, ladite communauté privée étant gérée par un second 30 utilisateur 132. La demande du premier utilisateur 131 est transmise (étape 302), via le serveur 8 du fournisseur 2 de services, au dispositif 1 de communication du second utilisateur 132. Le second utilisateur 132 émet une décision d'acception ou de refus via son dispositif 1 de communication (étape 303), qui est transmise au serveur 8 du fournisseur 2 de services. Le premier utilisateur 131 est autorisé (étape 304) à accéder à la communauté privée 20 en fonction de la décision du second d'utilisateur 132, une décision d'acceptation entraînant une association de la clé 11 publique asymétrique du second d'utilisateur 132 à la communauté 20 privée. Cette association consiste à stocker dans le serveur 8 une copie de la clé 11 de l'utilisateur 131, et à l'intégrer dans les paramètres de la communauté 20. Ainsi, lorsque le premier utilisateur 131 souhaite utiliser les services de la communauté 20 privée, et/ou échanger des données avec les autres utilisateurs, le fournisseur 2 de services reconnaît sa clé 11 et l'autorise à accéder à ces services. Le mécanisme d'acceptation par le second d'utilisateur 132 peut 20 prendre diverses formes. Dans un mode de réalisation, le second utilisateur 132 reçoit un message lui indiquant que le premier utilisateur 131 souhaite rejoindre sa communauté 20 privée. Le message peut être standard ou personnalisé et écrit par le premier utilisateur 131 lui-même. Ce message est affiché via 25 l'interface 30 du dispositif 1 de communication du second d'utilisateur 132. Le second d'utilisateur 132 peut alors émettre une décision d'acceptation ou de refus via son interface 30. On décrit en référence à la Figure 8 un mode de réalisation d'échange de données entre des utilisateurs d'une même communauté, 30 publique ou privée. Cet échange repose sur les différents modes de réalisation, précédemment décrits, d'échanges de données entre le dispositif de communication et le fournisseur de service. Comme illustré en Figure 8, un premier utilisateur 131 est équipé d'un premier dispositif 11 de communication comprenant une première clé 71 matérielle. Un deuxième utilisateur 132 est équipé d'un deuxième dispositif 12de communication comprenant une deuxième clé 72 matérielle. Les deux utilisateurs 131 sont 132 sont membres d'une même communauté 23 (publique ou privée). Ainsi, comme explicité auparavant, la clé 111 publique asymétrique du premier utilisateur 131, et la clé 112 publique asymétrique du deuxième utilisateur 132 sont associées à la communauté 23. Le premier utilisateur 131 demande à accéder à des données du second utilisateur 132 (étape 401). Le serveur 8 du fournisseur 2 d'accès demande au deuxième dispositif 12 de communication à accéder aux données du second utilisateur 132 (étape 402). Le deuxième dispositif 12 de communication transmet ces données au serveur 8 du fournisseur 2 d'accès, cryptées, au moins en partie, par la deuxième clé 72 matérielle (étape 403). Ce cryptage et les divers modes de réalisation d'échanges de données ont été exposés précédemment. Le serveur 8 du fournisseur 2 d'accès décrypte ces données par l'intermédiaire de la deuxième clé 72 matérielle, les ré-encrypte avec la première clé 71 matérielle, et les transmet au premier dispositif 11 de communication (étape 404). Le premier dispositif li de communication décrypte alors les données avec la première clé matérielle 71. Les échanges sont ainsi sécurisés. Dans un mode de réalisation, les données échangées respectent la trame illustrée en Figure 5, en partie ou en totalité. Dans un mode de réalisation, l'échange de données entre le serveur 8 du fournisseur 2 de services et des utilisateurs membres d'une même communauté comprend l'étape selon laquelle une clé 30 pluri-utilisateurs, commune à au moins une partie des utilisateurs de la communauté, est utilisée pour crypter les données échangées. Dans un mode de réalisation, la clé 30 pluri-utilisateurs est une clé logicielle constituée d'une succession de bits. Selon un aspect de ce mode de réalisation, l'envoi de données du serveur 8 du fournisseur 2 de services vers des utilisateurs membres d'une même communauté, lesdites données étant identiques pour les utilisateurs, comprend l'étape selon laquelle le serveur 8 du fournisseur 2 de services envoie une seule fois ces données vers le réseau de communication qui les renvoie vers chaque utilisateur membre de la même communauté. Un exemple d'un tel mode de réalisation est illustré schématiquement en Figure 9. Le serveur 8 du fournisseur 2 d'accès envoie à au moins une partie des utilisateurs d'une même communauté une clé 30 pluri-utilisateurs. Cette clé est une clé de cryptage, et est en général de validité limitée dans le temps, c'est-à-dire qu'il s'agit d'une clé temporaire. Selon les besoins, le serveur 8 du fournisseur de services peut renouveler périodiquement la clé 30 pluri-utilisateurs. Pour recevoir la clé 30 pluri-utilisateurs, les utilisateurs doivent préalablement s'inscrire auprès du fournisseur 2 d'accès. L'inscription passe par exemple par l'envoi d'une demande à partir des dispositifs 11, 12 de communication des utilisateurs vers le serveur 8, qui reçoivent en retour la clé 30 pluri-utilisateurs. Ces échanges sont réalisés selon les modes de réalisation d'échanges sécurisés de données décrits précédemment (cryptage par clé matérielle, et le cas échéant envoi des données sous forme de la trame évoquée précédemment). L'inscription peut être automatique. Par exemple, dès que les utilisateurs accèdent à une communauté, leurs dispositifs de communication reçoivent automatiquement une clé pluri-utilisateurs de la part du serveur 8 du fournisseur 2 de services. L'envoi de la clé 30 pluri-utilisateurs vers les dispositifs de communication est réalisé selon les modes de réalisation d'échanges sécurisés de données décrits précédemment. En particulier, la clé 30 pluri- utilisateurs peut être envoyée par le serveur 8 à chaque dispositif de communication en étant cryptée par la clé matérielle de chaque dispositif de communication. Alternativement, la clé 30 pluri-utilisateurs peut être envoyée à chaque dispositif de communication en utilisant le mécanisme de cryptage successif précédemment décrit. Par la suite, le serveur 8 envoie une seule fois les données cryptées par la clé 30 pluri-utilisateurs vers le réseau 3 de communication, qui les renvoie vers les dispositifs de communication de ces utilisateurs. En fonction de la taille des données, plusieurs envois successifs par le serveur 8 du fournisseur 2 de services peuvent être nécessaire, mais chaque envoi de données par le fournisseur de services vers le réseau de communication est réalisé une seule fois, et non pas répliqué pour chaque utilisateur. Le réseau 3 de communication se charge alors d'envoyer les données à chaque dispositif de communication des utilisateurs de la communauté. Les dispositifs de communication (ici 11 et 12) des utilisateurs concernés décryptent les données via la clé 30 pluri-utilisateurs. Ainsi, l'envoi de flux de données du serveur du fournisseur de services vers les dispositifs de communication des utilisateurs d'une communauté est réalisé avec un encombrement moindre de la bande passante. Cet envoi unique d'informations, crypté par une clé commune à plusieurs utilisateurs, permet d'économiser de la bande passante. Au lieu que le fournisseur de services envoie plusieurs fois les mêmes données à destination de plusieurs utilisateurs, un seul envoi est réalisé vers le réseau de communication. Il s'agit donc d'un envoi de type multidiffusion (« multicast »). Le serveur 8 n'a plus à envoyer les données plusieurs fois en les cryptant différemment pour chaque utilisateur. Dans un mode de réalisation, le serveur 8 du fournisseur 2 de services envoie une clé de cryptage 31 à au moins deux dispositifs de communication (par exemple 11 et 12, cf. Figure 9) d'utilisateurs souhaitant échanger des données entre eux. Cet envoi est réalisé selon un des modes de réalisation des échangés sécurisés précédemment décrits (cryptage par clé matérielle, et/ou respect d'une trame, et/ou cryptage successif, etc.). La clé de cryptage est en général temporaire. Elle peut être renouvelée selon les besoins. Les dispositifs de communication échangent alors des données entre eux directement via le réseau 3 de communication, lesdites données étant cryptées par la clé de cryptage 31. Ces échanges ne transitent plus par le serveur 8 du fournisseur 2 de services, mais sont directement réalisés entre les dispositifs de communication concernés, via le réseau 3 de communication. Ces échanges peuvent être réalisés entre une pluralité de dispositifs de communication, comme par exemple lors d'une vidéoconférence à plusieurs utilisateurs. Il s'agit donc d'une communication point à point, qui ne passe plus par le serveur 8 du fournisseur 2 de services. Le fournisseur 2 de services peut facturer aux utilisateurs l'utilisation de ce service de communication point à point, par exemple à la durée et/ou via un forfait. Dans un exemple de réalisation, les données échangées concernent une communication de type voix sur IP. Ces échanges directs entre utilisateurs sont donc sécurisés au maximum, et permettent une communication plus efficace. De manière générale, la solution proposée permet une sécurisation 30 accrue des échanges de données entre le dispositif de communication et le fournisseur de services. En particulier, les attaques de tiers consistant à s'interposer entre le dispositif de communication et le fournisseur de services ne sont plus possibles. Outre la sécurisation des échanges, une personnalisation et une identification des utilisateurs d'un même dispositif de communication est possible, permettant ainsi d'identifier chaque utilisateur d'un dispositif de communication, et les services associés à cet utilisateur. Malgré la sécurisation et la personnalisation accrues offertes par l'invention, l'interface d'utilisation du dispositif de communication, telle que présentée à l'utilisateur, reste simple et intuitive. Les fournisseurs de service trouvent donc des outils puissants pour la création et la gestion de communautés d'utilisateurs, proposant un ou plusieurs services, de manière efficace et sécurisée. En outre, les communications entre différents utilisateurs de différents dispositifs de communication sont sécurisées et plus efficaces. Enfin, la bande passante du fournisseur de services n'est pas altérée tout en offrant une qualité accrue du niveau de services. REVENDICATIONS1. Procédé d'échange sécurisé de données (5) entre un dispositif (1) de communication et un serveur (8) d'un fournisseur (2) de services via un réseau (3) de communication, le dispositif (1) de communication permettant à au moins un utilisateur (13) du dispositif (1) de communication d'utiliser des services (4) fournis par le fournisseur (2) de services, ledit procédé étant caractérisé en ce qu'il comprend les étapes d'échange de données (5) entre le dispositif (1) de communication et au moins un serveur (8) du fournisseur (2) de services consistant à : - crypter, pour l'envoi de données (5), au moins une partie des données (5) envoyées, par l'intermédiaire d'une clé (7) matérielle, connue du fournisseur (2) de services, et inscrite matériellement dans une mémoire (9) morte d'une puce (6) électronique du dispositif (1) de communication, et - décrypter, lors de la réception de données (5), les données reçues, par l'intermédiaire de cette clé (7) matérielle. 2. Procédé selon la revendication 1, dans lequel : - un utilisateur (13) s'enregistre (101) auprès du dispositif (1) de communication qui génère : o au moins une clé publique asymétrique propre à l'utilisateur (13), ladite clé étant transmise au fournisseur (2) de services (104, 105), o au moins une clé privée asymétrique propre à l'utilisateur (13) et stockée dans le dispositif (1) de communication (102, 103), et - les données (5) échangées entre le dispositif (1) de communication et le fournisseur (2) de services comprennent la clé publique asymétrique propre à l'utilisateur (13), lad ite clé publique asymétrique étant cryptée ou non cryptée par la clé (7) matérielle, la clé publique asymétrique permettant d'identifier l'utilisateur (13),et/ou des services du fournisseur (2) de services associés à cet utilisateur (13). 3. Procédé selon l'une des revendications 1 ou 2, dans lequel les données (5) échangées entre le dispositif (1) de communication et le serveur (8) du fournisseur (2) de services comprennent au moins une clé (K1) de premier niveau, elle-même cryptée par au moins une clé (K2) de deuxième niveau, ce cryptage successif étant réalisé jusqu'à une ou plusieurs clés (Kn) de niveau n, avec n un entier supérieur ou égal à deux, la clé (K1) de premier niveau étant cryptée par la clé (7) matérielle. 4. Procédé selon l'une des revendications 1 à 3, dans lequel les données (5) échangées entre le dispositif (1) de communication et le serveur (8) du fournisseur (2) de services comprennent au moins l'une des informations suivantes : - un identifiant (15) unique propre au dispositif (1) de communication, permettant au fournisseur (2) de services d'identifier le dispositif (1) de communication, le serveur (8) du fournisseur (2) de services utilisant cette identifiant (15) pour trouver la clé (7) matérielle associée au dispositif (1) de communication, - un identifiant (16) de service, propre à chaque service demandé par l'utilisateur via le dispositif (1) de communication, permettant au serveur (8) du fournisseur (2) de services d'identifier le service demandé par l'utilisateur via le dispositif (1) de communication, - une information relative à un index (17) utilisé pour choisir une clé transmise sur le réseau (3) de communication, - un protocole (18) de communication sécurisée entre le dispositif (1) de communication et le serveur (8) du fournisseur (2) de services. 5. Procédé selon l'une des revendications 1 à 4, dans lequel les données (5) échangées entre le dispositif (1) de communication et le serveur (8) du fournisseur (2) de services permettent la création et l'accès à descommunautés (20, 21, 23) regroupant une pluralité d'utilisateurs et des services spécifiques, l'accès à une communauté permettant à un utilisateur (13) d'utiliser ces services et/ou d'échanger des données avec les autres utilisateurs de la 5 communauté. 6. Procédé selon l'une des revendications 1 à 5, comprenant les étapes successives selon lesquelles: - un utilisateur (13) demande (201), via le dispositif (1) de 10 communication, l'accès à une communauté (21) publique proposant au moins un service et/ou l'échange de données entre utilisateurs de cette communauté, ladite communauté (21) publique étant gérée par le fournisseur (2) de services, - le dispositif (1) de communication transmet (202) une clé (11) 15 publique asymétrique, propre à l'utilisateur (13), au le serveur (8) du fournisseur (2) de services, - le serveur (8) du fournisseur (2) de services associe (203) à la communauté (21) publique demandée par l'utilisateur la clé (11) publique asymétrique de l'utilisateur, permettant ainsi à l'utilisateur 20 (13) d'accéder à cette communauté (21). 7. Procédé selon l'une des revendications 1 à 6, comprenant les étapes selon lesquelles: - un premier utilisateur (131) demande (301), via le dispositif (1) de 25 communication, l'accès à une communauté (20) privée proposant au moins un service et/ou l'échange de données entre utilisateurs de cette communauté, ladite communauté privée étant gérée par un second utilisateur (132), - la demande du premier utilisateur (131) est transmise (302), via le 30 serveur (8) du fournisseur (2) de services, au dispositif (1) de communication du second utilisateur (132),- le second utilisateur (132) émet (303) une décision d'acception ou de refus via son dispositif (1) de communication, qui est transmise au serveur (8) du fournisseur (2) de services, et - le premier utilisateur (131) est autorisé (304) à accéder à la communauté (20) privée en fonction de la décision du second d'utilisateur (132), une décision d'acceptation entraînant une association d'une clé (11) publique asymétrique du premier utilisateur (132) avec la communauté (20) privée. 8. Procédé selon l'une des revendications 5 à 7, comprenant des étapes successives d'échanges de données entre : - un premier utilisateur (131) équipé d'un premier dispositif (11) de communication comprenant une première clé (71) matérielle, et - un deuxième utilisateur (132) équipé d'un deuxième dispositif (12) de communication comprenant une deuxième clé (72) matérielle, les deux utilisateurs (131, 132) étant membres d'une même communauté (23), ledit procédé comprenant les étapes selon lesquelles : - le premier utilisateur (131) demande (401), via le premier dispositif (11) de communication, à accéder à des données du second utilisateur (132), - le serveur (8) du fournisseur (2) d'accès demande (402) au deuxième dispositif (12) de communication à accéder aux données du second (132) utilisateur, - le deuxième dispositif (12) de communication transmet (403) ces données au serveur (8) du fournisseur (2) d'accès, cryptées, au moins en partie, par la deuxième clé (72) matérielle, - le serveur (8) du fournisseur (2) d'accès décrypte (404) ces données par la deuxième clé (72) matérielle, les ré-encrypte avec la première clé (71) matérielle, et les transmet au premier dispositif (11) de communication, et- le premier dispositif (11) de communication décrypte les données avec la première clé (71) matérielle, permettant l'accès aux données par le premier utilisateur (131). 9. Procédé selon l'une des revendications 5 à 8, dans lequel l'échange de données entre le serveur (8) du fournisseur (2) de services et des utilisateurs membres d'une même communauté comprend l'étape selon laquelle une clé (30) pluri-utilisateurs, commune à au moins une partie des utilisateurs de la communauté, est utilisée pour crypter les données échangées. 10. Procédé selon la revendication 9, dans lequel l'envoi de données du serveur (8) du fournisseur (2) de services vers des utilisateurs membres d'une même communauté, lesdites données étant identiques pour les utilisateurs, comprend l'étape selon laquelle : le serveur (8) du fournisseur (2) de services envoie une seule fois ces données, cryptées par la clé (30) pluri-utilisateurs, vers le réseau de communication qui les renvoie vers les dispositifs de communication de ces utilisateurs. 11. Procédé selon l'une des revendications 1 à 10, dans lequel le serveur (8) du fournisseur (2) de services envoie une clé (31) de cryptage à au moins deux dispositifs de communication d'utilisateurs souhaitant échanger des données entre eux, et les dispositifs de communication échangent des données entre eux directement via le réseau (3) de communication, lesdites données étant cryptées par la clé (31) de cryptage. 12. Dispositif de communication (1), caractérisé que ce qu'il comprend: - des moyens (29) d'accès à un réseau (3) de communication, pour échanger des données, via ce réseau (3), avec un serveur (8) d'un fournisseur (2) de services,- une interface (30), pour interagir avec un utilisateur (13), et - une clé (7) matérielle, connue du fournisseur (2) de services, et stockée matériellement dans une mémoire morte d'une puce (6) électronique du dispositif (1) de communication, ledit dispositif étant configuré pour exécuter, en lien avec le fournisseur (2) de services, les étapes du procédé selon l'une des revendications 1 à 11. 13. Système (37) de communication, configuré pour l'échange sécurisé de données (5) entre un dispositif (1) de communication et un serveur (8) d'un fournisseur (2) de services via un réseau (3) de communication, ledit système (37) étant caractérisé en ce qu'il comprend : - au moins un serveur (8) d'un fournisseur (2) de services, - au moins un dispositif de communication (1), comprenant : o des moyens (29) d'accès à un réseau (3) de communication, pour échanger des données, via ce réseau (3), avec le serveur (8) du fournisseur (2) de services, o une interface (30), pour interagir avec au moins un utilisateur (13), et o une clé (7) matérielle, connue du fournisseur (2) de services, et stockée matériellement dans une mémoire (9) morte d'une puce (6) électronique du dispositif (1) de communication, le dispositif de communication étant configuré pour échanger des données avec le serveur (8) du fournisseur (2) de services par l'intermédiaire du réseau (3) de communication, selon le procédé d'échange de l'une des revendications 1 à 11, et permettant à l'utilisateur (13) du dispositif (1) de communication d'utiliser des services (4) fournis par le fournisseur (2) de services.