Brevet FR3076012A1 — publié le 20190628

I Procédé de sécurisation d'un protocole USB par authentification d'un périphérique USB par un appareil et par chiffrement des échanges entre le périphérique et l'appareil et dispositifs associés La présente invention concerne un procédé de sécurisation d'un protocole USB. Le procédé de sécurisation est un procédé de sécurisation d'un protocole USB par authentification d'un périphérique USB par un appareil et par chiffrement des échanges entre le périphérique et l'appareil. La présente invention se rapporte également à un périphérique et un appareil associé. Le protocole USB a été réalisé pour permettre l'utilisation d'une grande diversité de périphériques de la manière la plus simple possible. Le protocole USB est ainsi incontournable dans les équipements du fait notamment de son universalité. L'utilisation du protocole USB est ainsi multiple : insertion d'accessoires comme un clavier ou une caméra, mises à jour logicielles ou chargement de configuration. La grande polyvalence de l'USB, qui rend cette norme très appréciée et utilisée, a comme contrepartie une grande surface d'attaque. De manière générale, un périphérique malveillant (par exemple, une clé USB malveillante) attaque l'hôte (appareil sur lequel on branche ladite clé) et cherche à déclencher un ou plusieurs des défauts suivants : exécution de code malveillant, compromission de données (« aspiration » de données de l'hôte sur le périphérique) ou déni de service. Il est à noter que, sans mesure prise, un périphérique USB malveillant peut potentiellement utiliser toutes les fonctionnalités permises par l'interface USB : commande clavier, liaison série, messages Ethernet, etc... Pour cela, le périphérique exploite la vulnérabilité du protocole USB qui ne propose aucune vérification du fait que ledit périphérique est bien celui qu'il prétend être. En effet, le périphérique USB branché annonce lors de son branchement sur l'hôte son constructeur et son modèle et l'hôte met alors en oeuvre le pilote correspondant à ces informations annoncées. Il n'y a aucune vérification des informations fournies à l'hôte. Si un attaquant est capable de créer un périphérique USB encapsulant un dispositif d'attaque dans un périphérique à l'aspect d'une clé USB banale du commerce, plusieurs scénarios d'attaque sont alors possibles. Trois scénarios sont donnés dans ce qui suit à titre d'exemple. Selon un premier scénario d'attaque, l'attaque est une attaque par détournement applicatif. Le périphérique se présente à l'hôte comme un clavier ou une souris et simule 2 des interactions utilisateurs pour déclencher un comportement indésirable ou une exécution de code. Par exemple, il est branché un périphérique malveillant sur un ordinateur dont le rôle nominal est de commander les ouvertures de portes d'un bâtiment sécurisé sous la 5 supervision d'un opérateur, et le périphérique émulant une souris va modifier par l'interface homme-machine le contrôle d'accès sans que l'opérateur ne fasse rien. Selon un autre exemple, un raccourci clavier « ouvrir un terminal » est créé puis on tape des commandes écrivant un script et l'exécutant. Selon un deuxième scénario d'attaque, l'attaque est une attaque par détournement 10 réseau. Le périphérique se présente comme une carte réseau Ethernet. La carte réseau Ethernet la plus récente prenant la priorité sur les autres, le trafic réseau est détourné vers le périphérique qui peut alors écouter et enregistrer voire modifier ce dernier - cela pouvant, lorsque combiné à d'autres éléments (tels qu'une mise à jour par HTTP au lieu de HTTPS), aboutir à de l'exécution de code arbitraire. 15 Selon un troisième scénario d'attaque le périphérique se présente sous un profil falsifié, comme, par exemple, un vieux décodeur TNT oublié dont le pilote présente une faille. Le périphérique peut alors l'exploiter et récupérer un accès système à l'hôte. La simplicité du protocole USB étant obtenue au détriment de la sécurité, les attaques utilisant un périphérique USB comme vecteur se sont multipliées. 20 Il est donc souhaitable de sécuriser l'utilisation d'un périphérique USB. Pour cela, il est connu, lorsque le système d'exploitation de l'hôte est préparé, de choisir d'activer uniquement certains pilotes spécifiques à un type de périphérique USB. Ces pilotes spécifiques sont souvent désignés comme des « class drivers ». Par exemple, si l'on choisit d'activer seulement le pilote « Mass Storage », seuls 25 les périphériques de stockage de masse fonctionnent et l'attaquant n'est pas en mesure d'émuler un clavier, ni une carte réseau, ni le vieux décodeur TNT. Toutefois, si l'appareil doit conserver le support des claviers, cartes audio ou cartes réseau, il n'est pas possible d'appliquer une telle méthode de protection. Cette méthode de protection n'est donc satisfaisante que dans le cas des hôtes n'ayant besoin 30 que de périphériques de stockage de masse. De manière alternative, à chaque insertion de périphérique USB, l'hôte peut demander à l'utilisateur de quel type de périphérique il s'agit avant d'activer les fonctionnalités du périphérique. Ainsi, si un périphérique malveillant cherche à émuler un clavier ou une carte réseau alors que l'utilisateur s'attend à être en train de brancher un 35 périphérique de stockage de masse, l'accès est refusé et l'attaque déjouée, grâce à l'opérateur. 3 Cependant, une telle technique est lourde pour l'utilisateur. La technique est également incompatible avec les usages requérant la présence d'un périphérique USB spécifique au démarrage de l'appareil. Enfin, la présence d'une interface homme-machine n'est pas toujours compatible des contraintes d'un équipement embarqué. 5 En outre, cette technique ne permet pas de faire la différence entre un clavier bienveillant (normal) et un clavier malveillant, par exemple un périphérique malveillant déguisé en récepteur de clavier/souris sans fil, qui se verrait donc accorder par l'utilisateur le droit d'envoyer des entrées clavier/souris. De part l'analyse sommaire précédente des attaques possibles, il est clair que le 10 branchement et l'acceptation par l'hôte d'un périphérique qui s'avère être piégé est le prérequis à toutes ces attaques par USB. Par conséquent, si l'authenticité du périphérique est parfaitement garantie avant de l'accepter, l'hôte ne craint plus ces attaques. Pour cette raison, une méthode visant à garantir la non malveillance d'un périphérique branché en l'authentifiant avant de lui accorder les accès dont le périphérique a besoin pour 15 fonctionner peut être conçue. Toutefois, la garantie d'authenticité avant tout accès est bien sûr impossible à obtenir : il faudra un minimum de communications avec l'hôte pour précisément réaliser cette authentification, et l'hôte restera donc nécessairement vulnérable à toute exploitation d'une vulnérabilité présente à un niveau inférieur à celui où est réalisée 20 l'authentification. Ainsi, plus l'authentification est réalisée à bas niveau, plus on réduit la surface d'attaque. Le protocole USB de type C propose une méthode d'authentification des périphériques USB. Pour cela, la méthode propose de télécharger la chaîne de certificats jusqu'au périphérique et d'effectuer un test pour vérifier que le périphérique est bien que 25 le périphérique prétend être. Un tel protocole USB de type C est utile dans un certain nombre de cas. Par exemple, il peut être cité les cas suivants : un vendeur inquiété par la possibilité de dommages causés à ses appareils par des chargeurs de basse qualité peut forcer ses appareils à n'accepter la recharge que depuis des chargeurs certifiés ; un utilisateur 30 inquiété par la recharge de son appareil dans un terminal public peut activer un mode dans lequel l'appareil n'accepte la recharge que si le chargeur est certifié ou une organisation, inquiétée par la possibilité que des périphériques non identifiables gagnent des accès aux postes de travail, peut définir une politique d'accès selon laquelle seuls des périphériques certifiés par l'organisation peuvent être utilisés. 35 En revanche, tout le reste des communications reste inchangé, non chiffré. Cela rend le système vulnérable aux attaques de type Man-ln-The-Middle (MITM). L'attaque de 4 l'homme du milieu (HDM) ou man-in-the-middle attack (MITM), parfois appelée attaque de l'intercepteur, est une attaque qui a pour but d'intercepter les communications entre deux parties, sans que ni l'une ni l'autre ne puisse se douter que le canal de communication entre elles a été compromis. 5 Une telle attaque est possible dans au moins un cas décrit ci-après. L'attaquant branche un périphérique officiel sur son périphérique malveillant, et le périphérique malveillant à l'hôte (ou, le périphérique malveillant est relié d'une manière ou d'une autre, éventuellement sans fil, à un périphérique officiel). Le périphérique malveillant transfère toutes les commandes relatives à l'authentification au périphérique officiel et transfère ses 10 réponses à l'hôte. L'hôte accorde alors les accès au périphérique malveillant. Il existe donc un besoin pour un procédé de sécurisation d'un protocole USB utilisé entre un périphérique et un appareil, le procédé garantissant notamment une meilleure sécurité pour l'appareil. Pour cela, la présente description porte sur un procédé de sécurisation d'un 15 protocole USB par authentification d'un périphérique par un appareil et par chiffrement des échanges entre le périphérique et l'appareil, le périphérique fonctionnant selon le protocole USB, l'appareil comportant au moins un port d'entrée, le procédé comportant au moins l'étape de branchement du périphérique à un port d'entrée, de détection par l'appareil du périphérique uniquement si le périphérique a activé un protocole de 20 transformation de l'USB en réseau local à commutation de paquets, dit réseau local, de connexion de l'appareil au réseau local, un des éléments parmi l'appareil et le périphérique étant un serveur pour le réseau local, le serveur étant propre à communiquer au niveau de la couche de transport selon un unique protocole prédéfini, d'établissement d'un canal de communication entre l'autre élément parmi l'appareil et le périphérique et le 25 serveur et de demande par le périphérique des droits d'accès à l'appareil via le canal de communication. Suivant des modes de réalisation particuliers, le procédé comprend une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toutes les combinaisons techniquement possibles : 30 - à l'étape de connexion, l'appareil se connecte via une adresse IP spécifique. - lors de l'étape de connexion, les communications émanant de protocoles différents du protocole prédéfini sont filtrées. le protocole prédéfini est un protocole garantissant l'établissement et le maintien d'un canal de communication sécurisé, en particulier avec 35 authentification préalable des parties prenantes au canal de communication. 5 le protocole prédéfini est un protocole choisi dans le groupe constitué du protocole SSH, du protocole SSL et du protocole TLS. le canal de communication est un canal chiffré. le canal de communication est chiffré selon un protocole de chiffrement 5 asymétrique, le protocole de chiffrement asymétrique comportant de préférence un ensemble de clés privées, chaque clé privée étant mémorisée dans un coffre-fort numérique du périphérique. La présente description se rapporte également à un périphérique fonctionnant selon un protocole USB, le périphérique étant adapté pour la mise en oeuvre d'au moins 10 une étape du procédé de sécurisation du protocole USB par authentification du périphérique par un appareil et par chiffrement des échanges entre le périphérique (14) et l'appareil, le procédé de sécurisation étant tel que précédemment décrit. Suivant des modes de réalisation particuliers, le périphérique comprend une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toutes les 15 combinaisons techniquement possibles : le périphérique est adapté à bloquer les échanges avec l'appareil lorsque l'appareil est incapable de mettre en oeuvre le procédé de sécurisation en interaction avec le périphérique. le périphérique, dit premier périphérique, comporte au moins un port d'entrée 20 propre à accueillir un deuxième périphérique, le deuxième périphérique fonctionnant selon un protocole USB, le premier périphérique étant également adapté pour la mise en oeuvre d'au moins une étape d'un procédé de sécurisation du protocole USB par authentification du deuxième périphérique par le premier périphérique et par chiffrement des échanges entre le premier 25 périphérique et le deuxième périphérique, le procédé de sécurisation étant tel que précédemment décrit. La présente description concerne aussi un appareil comportant au moins un port d'entrée, l'appareil étant adapté pour la mise en oeuvre d'au moins une étape du procédé de sécurisation tel que précédemment décrit. 30 D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit de modes de réalisation de l'invention, donnés à titre d'exemple uniquement et en référence aux dessins qui sont : - figure 1, une représentation schématique d'un ensemble informatique, et - figure 2, un schéma illustrant le fonctionnement de l'ensemble informatique. 35 Un ensemble informatique 10 est schématisé sur la figure 1. L'ensemble informatique 10 comporte un appareil 12 et un périphérique 14. 6 Un appareil 12 comportant au moins un port 16 d'entrée. Le port 16 est adapté pour accueillir une partie 18 du périphérique 14. L'appareil 12 est, par exemple, un ordinateur. Le périphérique 14 est, par exemple, un clavier. 5 Le périphérique 14 est propre à fonctionner selon un protocole USB. Le Universal Serial Bus (USB, en français Bus Universel en Série) est une norme relative à un bus informatique en transmission série qui sert à connecter des périphériques 14 informatiques à un ordinateur ou à tout type d'appareil 12 prévu à cet effet (tablette, smartphone). Le bus USB permet de connecter des périphériques 14 à 10 chaud (quand l'ordinateur est en marche) et en bénéficiant du Plug and Play qui reconnaît automatiquement le périphérique 14. Il peut alimenter les périphériques 14 peu gourmands en énergie (clé USB, disques SSD). Le périphérique 14 est pourvu d'un protocole de transformation de l'USB en réseau 20 local à commutation de paquets, le protocole de transformation étant activable 15 ou non par le périphérique 14. A titre d'exemple, le périphérique 14 est muni d'un protocole dit « Ethernet over USB » permettant d'assurer que le périphérique 14 est un noeud d'un réseau Ethernet 20, un réseau Ethernet étant un réseau local 20 à commutation de paquets. Il est à noter que, lorsque le protocole de transformation est activé, le 20 périphérique 12 est configuré pour être seulement un noeud du réseau local 20 à commutation de paquets, c'est-à-dire à proposer uniquement un service d'émulation du réseau local 20 sur le protocole USB. Cela implique que l'ensemble des autres services fournis par le service USB sont interdits ou inhibés. Le périphérique 14 comporte un coffre-fort numérique propre à mémoriser des 25 données. Par exemple, le coffre-fort est une zone de sécurité d'un microprocesseur, comme une mémoire sécurisée. En variante, le coffre-fort est un microprocesseur de sécurité, notamment un microprocesseur propre à mettre en oeuvre un protocole TPM (sigle pour le terme anglais 30 de « Trusted Platform Module » signifiant littéralement « Module de plateforme de confiance »). Selon une autre variante, le coffre-fort est une carte à puce. Dans l'exemple décrit, le coffre-fort numérique mémorise des éléments d'authentification. 35 Le fonctionnement de l'ensemble informatique 10 est maintenant décrit en référence à un exemple de mise en oeuvre d'un procédé de sécurisation du protocole 7 USB par authentification du périphérique 14 par l'appareil 12 et par chiffrement des échanges entre le périphérique 14 et l'appareil 12 dont le résultat est schématisé sur la figure 2. Le procédé comporte une étape de branchement, une étape de détection, une 5 étape de connexion, une étape d'établissement, une étape de demande, une étape de fourniture et une étape d'exploitation. Lors de l'étape de branchement, le périphérique 14 est branché à un port 16 d'entrée de l'appareil 12. Lors de l'étape de détection, l'appareil 12 tente de détecter le périphérique 14. 10 La détection du périphérique 14 n'a lieu que si le périphérique 14 a activé un protocole de transformation. Cela signifie que le périphérique 14 est un noeud 22 d'un réseau local 20 à commutation de paquets. Un tel réseau est appelé réseau local 20 dans ce qui suit. Lors de l'étape de connexion, l'appareil 12 se connecte au réseau local 20 via une 15 adresse IP spécifique. Une adresse IP (le sigle IP renvoyant au terme anglais d'« Internet Protocol » signifiant littéralement protocole internet) est un numéro d'identification qui est attribué de façon permanente ou provisoire à chaque appareil connecté à un réseau informatique utilisant le protocole internet. L'adresse IP est à la base du système d'acheminement (le 20 routage) des messages sur Internet. L'appareil 12 se connecte alors sous la forme d'un serveur 24 propre à communiquer au niveau de la couche de transport selon un unique protocole préfini. La couche de transport est, selon le modèle OSI, une couche intermédiaire de la couche réseau et de la couche session. 25 La couche transport gère les communications de bout en bout entre processus. Cette couche est souvent la plus haute couche où on se préoccupe de la correction des erreurs. Plusieurs protocoles sont possibles dans la couche de transport, à savoir le protocole DCCP (de l'anglais « Datagram Congestion Control Protocol » signifiant 30 littéralement « protocole de contrôle de congestion de datagramme »), le protocole SPX (de l'anglais « Sequenced packet exchange » signifiant littéralement « échange séquencé de paquets »), le protocole SCTP (de l'anglais « Stream Control Transmission Protocol » signifiant littéralement « protocole de transmission de flux contrôlé »), le protocole TCAP (de l'anglais « Transaction Capabilities Application Part » signifiant littéralement « Partie 35 d'application de capacités de transaction »), le protocole TCP (de l'anglais « Transmission Control Protocol » signifiant littéralement « protocole de contrôle de transmission ») ou le 8 protocole UDP (de l'anglais « User Datagram Protocol» signifiant littéralement « protocole de datagramme utilisateur »). Selon le mode de réalisation considéré, le protocole prédéfini est un des protocoles précités. 5 De préférence, le protocole prédéfini est un protocole garantissant l'établissement et le maintien d'un canal de communication sécurisé, en particulier avec authentification préalable des parties prenantes au canal de communication. Ainsi, parmi les protocoles précités, le protocole TCP est particulièrement adapté pour le protocole prédéfini du fait que le protocole TCP est un protocole de transport 10 fiable. Plus précisément, dans l'exemple décrit, l'appareil 12 se connecte sous la forme d'un serveur 24 communiquant uniquement selon le protocole prédéfini. Cela signifie que, lors de l'étape de connexion, les communications émanant de protocoles différents du protocole prédéfini sont filtrées, notamment par le serveur 24.Le 15 filtrage est, par exemple, mis en oeuvre à l'aide d'un logiciel spécifique. Un exemple de logiciel spécifique est le logiciel iptables qui est un logiciel libre de l'espace utilisateur Linux grâce auquel l'administrateur système peut configurer les chaînes et règles dans le pare-feu en espace noyau. Selon l'exemple détaillé ici, l'appareil 12 se connecte sous la forme d'un serveur 20 SSH 24. Le sigle SSH renvoie au terme anglais de « Secure Shell » signifiant littéralement « interpréteur de commandes sécurisé». Un serveur SSH 24 est à la fois un programme informatique et un protocole de communication sécurisé. Le protocole de connexion impose un échange de clés de chiffrement en début de connexion. Par la suite, tous les 25 segments échanges sont authentifiés et chiffrés. Cela rend impossible d'utilisation d'un sniffer pour observer l'appareil 12 ou pour nuire à l'intégrité des échanges entre 12 et 14. Dans un tel cas, le protocole prédéfini est le protocole SSH. En variante, l'appareil 12 se connecte sous la forme d'un serveur SSL ou TLS. Dans une telle variante, le protocole prédéfini est le protocole SSL ou le protocole TLS. 30 Le sigle SSL renvoie au terme anglais de « Secure Sockets Layer » signifiant littéralement « Couche de connecteurs sécurisés» alors que le sigle TLS renvoie au terme anglais de « Sécurité de la couche de transport» signifiant littéralement « Couche de transport sécurité ». Le protocole TLS et le protocole SSL sont des protocoles de sécurisation des échanges sur Internet. Le terme ssuns est également utilisé 35 indifféremment pour désigner ces protocoles, le protocole TLS étant le successeur du protocole SSL. 9 Les deux protocoles SSL et TLS fonctionnent suivant un mode client-serveur et permettent de satisfaire un certain nombre de contraintes de sécurité, notamment l'authentification du serveur et du client mais aussi la confidentialité et l'intégrité des données échangées. 5 Lors de l'étape d'établissement, le périphérique 14 requiert l'établissement d'un canal de communication 26 entre le périphérique 14 et le serveur 24, c'est-à-dire indirectement entre le périphérique 14 et l'appareil 12. Le canal de communication 26 est un canal chiffré. Selon l'exemple décrit, le chiffrement est réalisé selon un protocole de chiffrement 10 asymétrique. Le chiffrement asymétrique ou la cryptographie asymétrique est un domaine de la cryptographie où il existe une distinction entre des données publiques et privées, en opposition à la cryptographie symétrique où la fonctionnalité est atteinte par la possession d'une donnée secrète commune entre les différents participants. 15 L'algorithme RSA est un exemple particulier de protocole de chiffrement asymétrique. Avantageusement, le protocole de chiffrement asymétrique comporte un ensemble de clés privées, chaque clé privée étant mémorisée dans le coffre-fort du périphérique 14. Lors de l'étape de demande, le périphérique 14 demande des droits d'accès à 20 l'appareil 12 via le canal de communication 26. En l'espèce, les droits d'accès sont les éléments dont a besoin le périphérique 14 pour fonctionner. A ce stade, l'appareil 12 est capable de déterminer si le périphérique 14 est un périphérique USB sécurisé ou non. 25 En supposant que dans l'exemple décrit, l'appareil 12 détermine que le périphérique 14 est un périphérique USB sécurisé, l'appareil 12 fournit les droits d'accès au périphérique 14 lors de l'étape de fourniture. Lors de l'étape d'exploitation, comme le périphérique 14 dispose des droits d'accès fournis par l'appareil 12, le périphérique 14 est capable de fonctionner 30 normalement. Le procédé propose repose ainsi sur un principe permettant d'obtenir les fonctionnalités des périphériques USB classiques (stockage de masse, clavier, casque audio, réseau...) au travers d'une connexion authentifiée et chiffrée TCP (SSH, SSL ou TLS), afin de limiter drastiquement la surface d'attaque par réduction du nombre de profils 35 USB dans l'appareil 12 au seul réseau local 20. La surface d'attaque est réduite en ne permettant le passage d'une attaque que via le protocole SSH ou SSL ou TLS. Le 10 procédé offre, en outre, la possibilité d'une rupture protocolaire ou d'une encapsulation protocolaire vers une instance logicielle maîtrisée sur l'appareil 12. Le procédé de sécurisation assure en exploitation qu'après authentification, la connexion est chiffrée de sorte que l'attaque de l'homme du milieu est impossible. Il est 5 donc impossible de prendre connaissance des échanges mais également de nuire à l'intégrité des échanges sans que cela soit détectable. En outre, quand bien même un attaquant viendrait à avoir connaissance de la clé privée de l'un des périphériques 14, ou modifierait un appareil 12 autorisé pour le rendre malveillant, puisqu'on s'abstrait du protocole USB, il devrait faire face à une rupture 10 protocolaire : un périphérique 14 authentifié compromis ne pourra pas utiliser les éventuelles failles du class driver classiquement associé à ce périphérique 14. Dans le cas du clavier, on peut aisément filtrer les entrées clavier en modifiant le programme simulant les entrées utilisateur de façon à limiter au maximum les détournements applicatifs possibles sans modifier le système d'exploitation. 15 Ainsi, le procédé de sécurisation est un procédé permettant d'utiliser un périphérique 14 fonctionnant selon un protocole USB de manière sécurisée pour l'appareil 12. Il est, en outre, à noter que le procédé de sécurisation est un procédé automatisé de sécurisation du périphérique 14. De fait, aucune intervention de l'utilisateur hormis le 20 branchement du périphérique 14 n'est requise, notamment ni la saisie d'un mot de passe ni une validation sur un écran. De plus, le procédé de sécurisation est aisé à mettre en oeuvre et notamment adapté pour une application embarquée. En outre, le procédé peut être utilisé en série en utilisant d'abord le procédé pour un premier périphérique 14 qui, une fois validé, peut servir d'appareil 12 pour un 25 deuxième périphérique 14 fonctionnant selon le protocole USB par mise en oeuvre du même procédé, le deuxième périphérique 14 devenant le premier périphérique 14 et le premier périphérique 14 l'appareil 12. Selon une autre variante, lors de l'étape de connexion de l'appareil 12 au réseau local 20, le périphérique 14 est le serveur alors que l'appareil 12 est un noeud et lors de 30 l'étape d'établissement, le canal de communication 26 est établi entre l'appareil 12 et le serveur 24. Il est également à noter que le périphérique 14 est adapté à bloquer les échanges avec l'appareil 12 lorsque l'appareil 12 est incapable de mettre en oeuvre le procédé de sécurisation en interaction avec le périphérique 14. Cela garantit que l'accès aux données 35 du périphérique 14 n'est pas possible pour un appareil 12 qui serait un appareil non- sécurisé au sens du protocole prédéfini. 11 L'invention REVENDICATIONS1.- Procédé de sécurisation d'un protocole USB par authentification d'un périphérique (14) par un appareil (12) et par chiffrement des échanges entre le périphérique (14) et l'appareil (12), le périphérique (14) fonctionnant selon le protocole USB, l'appareil (12) comportant au moins un port (16) d'entrée, le procédé comportant au moins l'étape de : - branchement du périphérique (14) à un port (16) d'entrée, - détection par l'appareil (12) du périphérique (14) uniquement si le périphérique (14) a activé un protocole de transformation de l'USB en réseau local à commutation de paquets, dit réseau local (20), - connexion de l'appareil (12) au réseau local (20), un des éléments parmi l'appareil (12) et le périphérique (14) étant un serveur (24) pour le réseau local (20), le serveur (24) étant propre à communiquer au niveau de la couche de transport selon un unique protocole prédéfini, - établissement d'un canal de communication (26) entre l'autre élément parmi l'appareil (12) et le périphérique (14) et le serveur (24), - demande par le périphérique (14) des droits d'accès à l'appareil (12) via le canal de communication (26). 2.- Procédé selon la revendication 1, dans lequel, à l'étape de connexion, l'appareil (12) se connecte via une adresse IP spécifique. 3.- Procédé selon la revendication 1 ou 2, dans lequel, lors de l'étape de connexion, les communications émanant de protocoles différents du protocole prédéfini sont filtrées. 4.- Procédé selon l'une quelconque des revendications 1 à 3, dans lequel le protocole prédéfini est un protocole garantissant l'établissement et le maintien d'un canal de communication sécurisé, en particulier avec authentification préalable des parties prenantes au canal de communication. 5.- Procédé selon l'une quelconque des revendications 1 à 4, dans lequel le protocole prédéfini est un protocole choisi dans le groupe constitué du protocole SSH, du protocole SSL et du protocole TLS. 13 6.- Procédé selon l'une quelconque des revendications 1 à 5, dans lequel le canal de communication (26) est un canal chiffré. 7.- Procédé selon la revendication 6, dans lequel le canal de communication (26) 5 est chiffré selon un protocole de chiffrement asymétrique, le protocole de chiffrement asymétrique comportant de préférence un ensemble de clés privées, chaque clé privée étant mémorisée dans un coffre-fort numérique du périphérique (14). 8.- Périphérique (14) fonctionnant selon un protocole USB, le périphérique (14) 10 étant adapté pour la mise en oeuvre d'au moins une étape du procédé de sécurisation du protocole USB par authentification du périphérique (14) par un appareil (12) et par chiffrement des échanges entre le périphérique (14) et l'appareil (12), le procédé de sécurisation étant selon l'une quelconque des revendications 1 à 7. 15 9.- Périphérique (14) selon la revendication 8, dans lequel le périphérique (14) est adapté à bloquer les échanges avec l'appareil (12) lorsque l'appareil (12) est incapable de mettre en oeuvre le procédé de sécurisation en interaction avec le périphérique (14). 10.- Périphérique (14), dit premier périphérique (14), le périphérique (14) 20 fonctionnant selon un protocole USB et comportant au moins un port (16) d'entrée propre à accueillir un deuxième périphérique (14), le deuxième périphérique (14) fonctionnant selon un protocole USB, le premier périphérique (14) étant selon la revendication 8 ou 9, le premier périphérique (14) étant également adapté pour la mise en oeuvre d'au moins une étape d'un procédé de sécurisation du protocole USB par authentification du 25 deuxième périphérique (14) par le premier périphérique (14) et par chiffrement des échanges entre le premier périphérique (14) et le deuxième périphérique (14), le procédé de sécurisation étant un procédé selon l'une quelconque des revendications 1 à 7. 11.- Appareil (12) comportant au moins un port (16) d'entrée, l'appareil (12) étant 30 adapté pour la mise en oeuvre d'au moins une étape du procédé de sécurisation selon l'une quelconque des revendications 1 à 7.