FR 2906661 A1 20080404 FR 0757948 A 20070928 ARRIERE-PLAN DE L'INVENTION 1. Domaine de l'invention L'invention concerne de façon générale la sécurisation d'échanges d'images d'amorces. Plus particulièrement, un mode de réalisation de l'invention utilise la transmission de données en tunnel pour protéger un téléchargement d'image d'amorce vers un environnement d'amorçage à distance d'un système informatique. L'amorçage à distance permet à un dispositif, pendant qu'il se trouve dans un état avant amorçage, d'obtenir une image d'amorce à partir d'un serveur extérieur ou d'une autre source, plutôt qu'à partir d'un support de stockage local tel qu'une disquette, un disque dur ou un CD-ROM. L'amorçage à distance repose sur un protocole avant amorçage qui est mis en oeuvre par un environnement d'amorçage à distance résidant dans le dispositif. Un environnement d'amorçage à distance caractéristique utilise des instructions de microprogramme de système d'entrée / sortie de base (BIOS pour "Basic Input/Output System") pour commander à une interface telle qu'une carte réseau (NIC pour "Network Interface Card") de télécharger une image d'amorce qui est ensuite exécutée localement pour amorcer le dispositif. Un exemple d'un tel environnement d'amorçage à distance est l'environnement Preboot Execution Environment (PXE), qui fait partie de la spécification INTEL Wired for Management (version 2.1, publiée par INTEL Corporation, Santa Clara, CA et SYSTEMSOFT Corporation, Newton, MA, le 20 septembre 1999). 2. Art antérieur La robustesse de l'environnement PXE inclut son aptitude à effectuer un échange d'image d'amorce en mettant à profit divers protocoles de réseau tels que : Internet Protocol (IP), Dynamic Host Configuration Protocol (DHCP), User Datagram Protocol (UDP) ,et Trivial File Transfer Protocol (TFTP). Cependant, PXE offre aujourd'hui guère 2906661 2 plus qu'un ensemble de recommandations sur la manière d'utiliser ces protocoles. Par exemple, le processus PXE met actuellement à profit un DHCP non sécurisé pour obtenir de l'information concernant un serveur PXE disponible, et 5 ensuite met à profit une session TFTP non sécurisée avec le serveur PXE pour obtenir l'image d'amorce. En outre, PXE offre traditionnellement le logiciel BIS (Boot Integrity Services) pour procurer un contrôle d'intégrité d'une image d'amorce chargée. BIS n'est cependant pas largement 10 déployé, du fait qu'il repose sur la configuration par un utilisateur d'un certificat Boot Object Authorization Certificate (BOAC). Avec la montée en puissance récente de divers procédés de commande d'accès à un réseau, l'exécution 15 native de protocoles de réseau par l'environnement d'amorçage à distance n'est pas viable sans qu'une certaine forme de protocole d'authentification de réseau ne soit exécutée pour l'accès initial au réseau. De plus, le fait de profiter de ces protocoles sous une forme native 20 présente un certain nombre de vulnérabilités de sécurité, qui peuvent aisément être exploitées par un adversaire pour compromettre l'obtention d'images d'amorces ou de paramètres d'authentification sûrs, à partir d'une ressource de réseau. 25 D'autres caractéristiques et avantages de l'invention seront mieux compris à la lecture de la description qui va suivre de modes de réalisation, donnés à titre d'exemples non limitatifs. La suite de la description se réfère aux dessins annexés dans lesquels : 30 BREVE DESCRIPTION DES DESSINS : La figure 1 est un schéma synoptique illustrant un réseau transférant une information d'image d'amorce vers des environnements d'amorçage à distance résidant dans divers noeuds de réseau. 35 La figure 2 est un schéma synoptique illustrant une grappe. de serveurs dans laquelle une information d'image 2906661 3 d'amorce est transférée vers des environnements d'amorçage à distance qui résident dans des serveurs individuels. La figure 3 est un diagramme séquentiel illustrant un échange d'image d'amorce utilisant un environnement 5 d'amorçage à distance. La figure 4 est un diagramme séquentiel illustrant une utilisation d'un tunnel de données pour échanger de l'information cryptographique concernant un échange d'image d'amorce. 10 La figure 5 est un diagramme séquentiel illustrant une utilisation d'un tunnel de données pour protéger un échange d'image d'amorce. La figure 6 est un organigramme illustrant un algorithme pour l'échange sécurisé d'image d'amorce par un 15 environnement d'amorçage à distance. La figure 7 est un schéma synoptique illustrant un ordinateur dans lequel réside un environnement d'amorçage à distance. La figure 8 est un schéma de structure de données 20 illustrant une information transmise en tunnel en un format Type Longueur - Valeur (TLV). DESCRIPTION DETAILLEE On décrit des techniques et des architectures pour permettre un transfert sécurisé d'information d'image 25 d'amorce. Dans la description suivante, dans des buts d'explication, de nombreux détails spécifiques sont présentés pour permettre une compréhension approfondie de l'invention. Il apparaîtra cependant à l'homme de l'art que l'invention peut être mise en pratique sans ces détails 30 spécifiques. Dans d'autres cas, des structures et des dispositifs sont représentés sous forme de schéma synoptique afin d'éviter d'obscurcir la description. Les références faites dans la description à "un mode de réalisation" signifient qu'une fonction, structure 35 ou caractéristique particulière décrite en relation avec le mode de réalisation est incluse dans au moins un mode de 2906661 4 réalisation de l'invention. Les occurrences de l'expression "dans un mode de réalisation" à divers endroits dans la description ne font pas nécessairement toutes référence au même mode de réalisation. 5 Certaines parties des descriptions détaillées qui suivent sont présentées en termes d'algorithmes et de représentations symboliques d'opérations sur des bits de données dans une mémoire d'ordinateur. Ces descriptions et représentations algorithmiques sont les moyens utilisés par 10 les spécialistes des techniques de réseaux pour transmettre le plus efficacement la substance de leur travail à d'autres spécialistes. Ici, et de façon générale, un algorithme est conçu comme étant une séquence d'étapes ayant une cohérence interne, conduisant à un résultat 15 désiré. Les étapes sont celles qui exigent des manipulations physiques de grandeurs physiques. Habituellement, bien que non nécessairement, ces grandeurs prennent la forme de signaux électriques ou magnétiques qui peuvent être stockés, transférés, combinés, comparés et 20 manipulés de toute autre manière. Il s'est avéré commode à certains moments, principalement pour des raisons d'usage courant, de faire référence à ces signaux comme des bits, valeurs, éléments, symboles, caractères, termes, nombres, ou autres. 25 Il faut cependant conserver à l'esprit le fait que tous ces termes, et des termes similaires, doivent être associés aux grandeurs physiques appropriées et sont simplement des étiquettes commodes appliquées à ces grandeurs. Sauf mention spécifique du contraire dans 30 l'explication suivante, on appréciera que dans l'ensemble de la description, des explications utilisant des termes tels que "traitement" ou "calcul" ou "détermination" ou "visualisation", ou autres, font référence à l'action et aux processus d'un système informatique, ou d'un dispositif 35 de calcul électronique similaire, qui manipule et transforme des données représentées comme des grandeurs 2906661 5 physiques (électroniques) dans les registres et mémoires du système informatique, pour produire d'autres données représentées de façon similaire comme des grandeurs physiques dans les mémoires ou registres du système 5 informatique, ou dans d'autres dispositifs de stockage, transmission ou visualisation d'information, de type semblable. Les algorithmes et visualisations présentés ici ne sont liés de manière inhérente à aucun ordinateur ou autre 10 appareil particulier. Divers systèmes universels peuvent être utilisés avec des programmes en conformité avec les enseignements présentés ici, ou bien il peut s'avérer commode de construire un appareil plus spécialisé pour exécuter les étapes de procédé exigées. La structure exigée 15 pour une variété de ces systèmes ressortira de la description ci-dessous. De plus, l'invention n'est décrite en référence à aucun langage de programmation particulier. On appréciera qu'il est possible d'utiliser une variété de langages de programmation pour mettre en oeuvre les 20 enseignements de l'invention, comme décrit ici. La figure 1 illustre un cadre général dans lequel un mode de réalisation peut être mis en pratique. La figure 1 montre un système 100 dans lequel une image d'amorce est envoyée par une source d'images d'amorces 101, sur un 25 réseau 102, vers des environnements d'amorçage à distance d'un ou plusieurs autres noeuds de réseau. Dans cet exemple, les autres noeuds de réseau incluent un client supportant l'environnement PXE 103, un serveur unique supportant PXE 104, et une grappe de serveurs supportant PXE 105. On peut 30 cependant utiliser n'importe quel nombre de sources d'images d'amorces et n'importe quel nombre de noeuds de réseau supportant des environnements d'amorçage à distance. Il faut noter qu'une caractéristique majeure d'un système ou un appareil recevant l'image d'amorce consiste en ce 35 qu'il supporte un environnement d'amorçage à distance. Il faut également noter qu'à côté de PXE, il est possible 2906661 6 d'utiliser n'importe quel environnement d'amorçage à distance qui supporte la transmission de données en tunnel dans un canal d'authentification. Le réseau 102 assure une interconnexion entre de 5 multiples noeuds de réseau, tels que des ordinateurs clients, des serveurs lames, des grappes de serveurs, etc. Dans un mode de réalisation, le réseau 102 est un réseau local (LAN pour "Local Area Network") tel que ceux bien connus dans la technique. Dans d'autres modes de 10 réalisation, le réseau 102 peut être un réseau étendu (WAN pour "Wide Area Network"), l'Internet ou tout autre type de réseau. La source d'images d'amorces 101 est un serveur ou un autre dispositif qui stocke une ou plusieurs images d'amorces qui peuvent être utilisées dans les noeuds de 15 réseau supportés par la source d'images d'amorces. Ces noeuds peuvent par exemple être un serveur 104 ou des serveurs 105 commandés par un organisme informatique, de façon que des techniciens puissent télécharger une image d'amorce à partir de la source 20 d'images d'amorces 101, par l'intermédiaire du réseau 102, sans avoir à accéder plus directement aux noeuds récepteurs. On notera que l'image d'amorce inclut n'importe quelles données utilisées pour faire sortir un système d'un état avant amorçage. Ces données incluent, mais de façon non 25 limitative, des systèmes d'exploitation, des utilitaires de système, des diagnostics, de l'information de récupération de données et du logiciel de système similaire. L'image d'amorce peut constituer seulement une partie d'un échange d'image d'amorce, qui peut inclure en outre une autre 30 information échangée entre des dispositifs pour faciliter la transmission de l'image d'amorce d'un dispositif à un autre. L'échange d'image d'amorce peut inclure, par exemple, un établissement de liaison dans le cadre d'un protocole, l'échange de paramètres d'authentification 35 sécurisés, et des échanges de clés de chiffrement. 2906661 7 La figure 2 illustre un autre cadre général dans lequel un mode de réalisation peut être mis en pratique. La figure 2 illustre une grappe de serveurs 200 dans laquelle une image d'amorce est envoyée par un premier serveur 201, 5 à travers un bus local partagé 204, vers l'environnement d'amorçage à distance d'un ou plusieurs serveurs 202, 203 dans la grappe de serveurs 200. Dans cet exemple, chacun des serveurs 202, 203 supporte le PXE en tant qu'environnement d'amorçage à distance. A un certain point, 10 le premier serveur 201 a une version actualisée d'une image d'amorce, tandis qu'un ou plusieurs serveurs 202, 203 dans la grappe de serveurs 200 sont dans un état avant amorçage, et ont besoin de la version actualisée de l'image d'amorce. Les communications associées à un échange d'image d'amorce 15 entre le premier serveur 201 et un autre serveur 202 dans la grappe de serveurs peuvent être plus simples que ce qui est illustré sur la figure 1. Par exemple, le PXE résidant dans le serveur 202 peut lancer l'échange d'image d'amorce sans avoir besoin d'acquérir une adresse IP par 20 l'intermédiaire d'un échange DHCP. L'identification du premier serveur 201 comme la source d'images d'amorces peut également être plus simplifiée pour une grappe de serveurs, en comparaison avec la découverte d'un serveur d'images d'amorces dans un réseau. Cependant, la sécurité d'un 25 échange d'image d'amorce sur le bus partagé local 204 est dépendante de l'intégrité de chaque serveur dans la grappe de serveurs 200. Par conséquent, comme dans l'exemple d'un échange d'image d'amorce sur un réseau 102, l'échange d'image d'amorce sur le bus partagé 204 d'une grappe de 30 serveurs 200 est sujet à certains des mêmes risques de sécurité. La figure 3 illustre un échange caractéristique, 300, faisant intervenir l'environnement d'amorçage à distance d'un noeud de réseau et une source d'images 35 d'amorces sur un réseau. Dans cet exemple, le noeud de réseau est un client PXE 301 qui met en oeuvre le PXE comme 2906661 8 son environnement d'amorçage à distance, et la source d'images d'amorces est un serveur d'amorces 302. L'échange 300 comprend une première phase 303 pour établir un canal d'authentification et une deuxième phase 308 pour échanger 5 l'image d'amorce entre le client PXE 301 et le serveur d'amorces 302, en utilisant le canal d'authentification établi. Dans la première phase 303, l'environnement d'amorçage à distance du client PXE 301 envoie un message 10 PXE DHCP 304 pour découvrir un serveur DHCP et demander une adresse IP et des paramètres de configuration IP nécessaires pour communiquer avec le serveur d'amorces. Pour la simplicité de l'illustration, dans cet exemple, le serveur DHCP est également le serveur d'amorces 302. Le 15 client PXE 301 reçoit un message d'acquittement DHCP ACK 305 qui contient une information IP que le client PXE 301 utilisera pour communiquer avec le serveur d'amorces 302. Pour s'authentifier dans le réseau dans lequel réside le serveur d'amorces 302, le client PXE 301 20 procurera les capacités d'accès au réseau appropriées au cadre général d'accès au réseau. Dans des réseaux conformes au standard Institute of Electrical and Electronics Engineers (IEEE) 802.1X, ceci est sous la forme d'une requête 802.1X, exécutant un procédé EAP approprié pour 25 authentifier le client vis-à-vis d'un Dispositif d'Accès au Réseau (NAD pour "Network Access Device"), qui peut être un commutateur ou un Point d'Accès (AP pour "Access Point") (non représenté sur la figure 3). Dans des réseaux qui ne sont pas du type 802.1X, ceci se manifeste par le fait que 30 le protocole EAP est mis en oeuvre sur un échange UDP (EAPUDP). En outre, dans des scénarios d'accès à distance, ceci peut être instancié au moyen d'une connexion de Réseau Privé Virtuel (VPN pour "Virtual Private Network"). Un exemple de ce dernier type consisterait à mettre à profit 35 un procédé EAP sur un protocole Internet Key Exchange (IKE), version 2, pour des VPN basés sur IPSec. Un exemple 2906661 9 d'un tel IKE est présenté dans le document RFC 2409 de l'organisme Network Working Group, daté de novembre 1998. Dans l'exemple illustré sur la figure 3, le client PXE 301 est authentifié par l'échange de messages DEFI EAP (UDP) 5 306 et REPONSE EAP (UDP) 307. Dans la deuxième phase 308, une fois qu'un canal d'authentification a été établi entre le client PXE 301 et un réseau sur lequel réside le serveur d'amorces 302, le client PXE 301 peut commencer un échange d'image d'amorce 10 avec le serveur d'amorces 302. On notera qu'un échange d'image d'amorce comprend toutes les communications qui aident à la transmission d'une image d'amorce à partir d'une source d'images d'amorces vers un environnement d'amorçage à distance qui réside dans un autre système 15 informatique. Ceci peut inclure n'importe quels messages de découverte de serveur et d'établissement de liaison, pour des protocoles utilisés dans la transmission du message d'amorce. Le client PXE 301 découvre le serveur d'amorces 302 20 au moyen du message DECOUVERTE DE SERVEUR D'AMORCES PXE, 309, et d'un message d'acquittement retourné, ACQUITTEMENT DE SERVEUR D'AMORCES, 310. Une fois que le serveur d'amorces est trouvé, l'image d'amorce elle-même peut être demandée au moyen d'un message DEMANDE DE TELECHARGEMENT 25 PXE, 311. A la réception de la demande de l'image d'amorce, le serveur d'amorces 302 envoie le message IMAGE D'AMORCE, 312, au client PXE 301. En plus de la première phase 303 et de la deuxième phase 308 de l'échange 300, le PXE 301 peut avoir d'autres paramètres d'authentification ou une 30 certification, 315 (autres qu'un certificat BOAC) à envoyer au serveur d'amorces 302 par l'intermédiaire de messages PARAMETRES D'AUTHENTIFICATION, 313, et ACQUITTEMENT DE PARAMETRES D'AUTHENTIFICATION, 314. Une fois que l'image d'amorce est reçue, le client PXE 301 peut s'amorcer en 35 exécutant l'image d'amorce 316. 2906661 10 La figure 4 illustre un mode de réalisation 400 dans lequel une transmission de données sécurisée est utilisée pour protéger l'échange d'image d'amorce. Ce mode de réalisation 400 procure un moyen pour encapsuler dans un 5 contexte de plus forte sécurité un flux en bande d'un environnement d'amorçage à distance, basé sur un BIOS / microprogramme. Un exemple d'un tel flux basé sur un microprogramme est un flux qui est en conformité avec la spécification Unified Extensible Firmware Interface (UEFI), 10 version 2.0, publiée par le forum UEFI. De façon spécifique, un procédé de transmission en tunnel générique est utilisé pour fournir de manière sécurisée une image d'amorce au PXE résidant dans un appareil ou un système, par l'intermédiaire d'un canal d'authentification EAP 403. 15 Dans ce contexte, la transmission en tunnel de type TLV et la transmission en tunnel avec paire attribut -valeur (AVP pour "Attribute-Value Pair") sont toutes deux utilisées pour décrire un mécanisme générique pour encapsuler n'importe quelles données arbitraires. 20 La figure 4 utilise un échange d'image d'amorce sécurisé entre le client PXE 401 et le serveur d'amorces 402 mettant à profit un canal d'authentification 403 établi, représenté par des lignes hachurées. Dans le canal d'authentification EAP 403, un tunnel de données 404 est 25 utilisé pour envoyer des données liées à l'échange d'image d'amorce. Dans ce cas, le serveur d'amorces 402 utilise un échange d'image d'amorce chiffré, 406, et les données transmises en tunnel liées à l'échange d'image d'amorce sont l'information de clé de chiffrement 405 échangée. Une 30 autre information cryptographique peut être échangée au lieu, ou en plus, de l'information de clé de chiffrement 405 échangée. Des échanges de données autres que l'échange d'image d'amorce 406, comme l'échange de paramètres d'authentification 407, peuvent avoir lieu à l'extérieur du 35 tunnel de données 404. Le procédé et les clés de chiffrement peuvent par exemple être en conformité avec le 2906661 11 système Advanced Encryption System (AES), recommandé par l'organisme National Institute of Standards and Technology (NIST); voir le document Federal Information Processing Standards (FIPS) PUB 197, 26 novembre 2001. Divers types de 5 cryptographie / par exemple symétrique, asymétrique, à clés publiques, à clés privées - peuvent être utilisés dans divers modes de réalisation, qui ne sont pas limités dans ce contexte. Dans un mode de réalisation, les clés peuvent chiffrer et/ou authentifier l'image d'amorce par le 10 serveur. Les clés peuvent ensuite être transmises au client, qui peut utiliser ces clés pour valider l'intégrité de l'image d'amorce. Dans un tel modèle d'utilisation, le canal authentifié peut être utilisé seulement pour transmettre les clés cryptographiques, et l'image d'amorce 15 est transférée à l'extérieur du canal authentifié. La validation de l'intégrité de l'image d'amorce en mettant à profit ces clés cryptographiques garantit que l'image d'amorce est authentique et dans la forme attendue, et n'est pas envoyée et/ou modifiée par une entité malicieuse. 20 A l'achèvement de l'échange d'amorce chiffré 406 et de l'échange de clés en tunnel, 404, le client PXE 401 peut exécuter l'image d'amorce reçue, à partir de l'intérieur d'un environnement PXE résident, comme envisagé ci-dessus. La figure 5 utilise un échange d'image d'amorce 25 sécurisé 500 entre le client PXE 501 et le serveur d'amorces 502 mettant à profit un canal d'authentification 503 établi, représenté par des lignes hachurées. Dans le canal d'authentification EAP 503, un tunnel de données 504 est utilisé pour envoyer des données liées à l'échange 30 d'image d'amorce. Le tunnel de données 504 peut être du type TLV, du type AVP ou en conformité avec un autre procédé générique pour transmettre des données génériques entre deux entités intéressées. Dans ce cas, les données liées à l'échange d'image d'amorcé qui sont transmises en 35 tunnel sont l'échange d'amorce entier lui-même, 505. Les paramètres d'authentification 506 sont également transmis 2906661 12 en tunnel dans cet exemple. Dans divers modes de réalisation, moins de la totalité de l'échange d'image d'amorce est transmise en tunnel. Dans encore d'autres modes de réalisation, des échanges de données autres que 5 l'échange d'image d'amorce en tunnel 505, comme l'échange de paramètres d'authentification 506, peuvent avoir lieu à l'extérieur du tunnel de données 504. A l'achèvement de l'échange d'amorce en tunnel 505 et de l'échange de paramètres d'authentification 506, le client PXE 501 peut 10 exécuter l'image d'amorce reçue, à partir de l'intérieur d'un environnement PXE résident, comme envisagé ci-dessus. La figure 6 illustre un algorithme 600 pour un procédé mettant en oeuvre un mode de réalisation. Dans cet exemple, le procédé est exécuté au client PXE cherchant à 15 acquérir une image d'amorce à partir d'une source d'images d'amorces, par exemple un serveur d'amorces PXE. En 601, l'environnement PXE résidant dans le client PXE recherche un serveur d'amorces PXE existant. Cette recherche peut inclure l'acquisition de l'accès au réseau par 20 l'intermédiaire d'un serveur DHCP et l'envoi d'un message de découverte de serveur d'amorces PXE, comme envisagé ci-dessus. Si un serveur d'amorces PXE n'est pas disponible, en 606, le client PXE appelle un chargeur de système d'exploitation (OS) du client PXE qui peut charger une 25 image d'amorce existant déjà, éventuellement périmée. Si un serveur d'amorces PXE est disponible, en 602, le client PXE examine si le PXE supporte la transmission de données en tunnel pour un échange d'image d'amorce, comme l'encapsulation de l'échange PXE dans TLV/AVP. 30 Si le PXE ne supporte pas la transmission de données en tunnel pour un échange d'image d'amorce, en 605, le client PXE peut effectuer un échange PXE traditionnel, c'est-à-dire moins sûr, ou, à la place, il peut n'autoriser aucun amorçage à distance pour le dispositif (ceci n'est 35 pas représenté), en fonction de règles administratives imposées. Si le PXE supporte la transmission de données en 2906661 13 tunnel pour un échange d'image d'amorce, en 603, le client PXE tente de négocier un procédé de canal d'authentification, c'est-à-dire un procédé EAP négocié, avec le serveur d'amorces PXE. Si la négociation échoue, en 5 605, le client PXE peut effectuer un échange PXE traditionnel, c'est-à-dire moins sûr, ou bien il peut ne pas autoriser le dispositif à effectuer un amorçage à distance quelconque (non représenté), en fonction de règles administratives imposées. Après l'achèvement de l'échange 10 PXE traditionnel, en 606, le client PXE appelle un chargeur de système d'exploitation (OS) du client PXE qui peut charger l'image d'amorce reçue au moyen d'un échange non sûr. Si la négociation réussit, en 604, le client PXE 15 peut exécuter le procédé pour établir un canal d'authentification, et effectuer un échange d'image d'amorce à l'intérieur du canal d'authentification. Comme envisagé ci-dessus, des données liées à l'échange d'image d'amorce sont transmises en tunnel entre le client PXE et 20 le serveur d'amorces PXE. Dans un mode de réalisation, au moins une partie de l'image d'amorce est chiffrée, et un tunnel de données TLV/AVP est utilisé pour échanger une information de clé de chiffrement utilisée pour déchiffrer le message d'amorce. Dans un autre mode de réalisation, au 25 moins une partie de l'image d'amorce elle-même est échangée dans un tunnel de données TLV/AVP. Une fois que la transaction PXE partiellement en tunnel, entre le client PXE et le serveur d'amorces, s'achève, en 606, le client PXE appelle un chargeur de système d'exploitation (OS) du 30 client PXE, qui peut charger l'image d'amorce reçue au moyen d'un échange sûr, effectué au moins partiellement en tunnel. L'invention porte également sur un appareil pour effectuer les opérations décrites ici. Cet appareil peut 35 être construit spécialement dans le but exigé, ou peut comprendre un ordinateur universel activé ou reconfiguré 2906661 14 sélectivement par un programme informatique stocké dans l'ordinateur. Un tel programme informatique peut être stocké sur un support de stockage lisible par ordinateur, tel que, mais de façon non limitative, un type quelconque 5 de disque incluant des disquettes, des disques optiques, des CD-ROM et des disques magnéto-optiques, des mémoires mortes (ROM), des mémoires vives (RAM), des mémoires mortes programmables électriquement (EPROM), des mémoires mortes programmables et effaçables électriquement (EEPROM), des 10 cartes magnétiques ou optiques, ou n'importe quel type de supports convenant pour stocker des instructions électroniques, et chacun étant couplé à un bus de système informatique. Dans d'autres modes de réalisation, on peut utiliser des circuits câblés à la place d'instructions de 15 logiciel, ou en combinaison avec celles-ci, pour mettre en oeuvre l'invention. L'invention n'est donc limitée à aucune combinaison spécifique de circuits de matériel et d'instructions de logiciel. La figure 7 illustre un mode de réalisation d'un 20 système informatique convenant pour l'utilisation dans un mode de réalisation. Un système informatique 700 comprend un bus 704 ou un autre dispositif de communication pour transmettre de l'information, et un processeur 701 couplé au bus 704 pour traiter de l'information. Bien que le 25 système informatique 700 soit illustré avec un seul processeur, le système informatique 700 peut inclure de multiples processeurs. Le système informatique 700 inclut en outre un dispositif de mémoire 702, tel qu'une mémoire vive (RAM), couplé au bus 704 pour stocker de l'information 30 et des instructions à exécuter par le processeur 701. La mémoire 702 peut également être utilisée pour stocker des variables temporaires ou une autre information intermédiaire, pendant l'exécution d'instructions par le processeur 701. Le système informatique 700 a également, en 35 couplage avec le bus 704, un moyen de stockage non volatil 702 - par exemple une mémoire morte (ROM) ou un 2906661 15 microprogramme - pour stocker des instructions de BIOS ou un logiciel de système similaire pour le processeur 701. D'autres supports de stockage 707, tels qu'une mémoire flash, un disque magnétique ou un disque optique, et une 5 unité correspondante, peuvent en outre être couplés au bus 704 pour stocker de l'information et des instructions. Le système informatique 700 peutégalement avoir un dispositif de visualisation 706 tel qu'un tube cathodique (CRT pour "Cathode Ray Tube") ou un dispositif de 10 visualisation à cristaux liquides (LCD pour "Liquid Crystal Display"), couplé au bus 704 par l'intermédiaire d'un contrôleur de visualisation 705, pour visualiser de l'information pour un utilisateur d'ordinateur. Un dispositif d'entrée / sortie (E/S) alphanumérique 710, 15 incluant des touches alphanumériques et autres, peut également être couplé au bus 704 par l'intermédiaire d'un contrôleur d'E/S 709. Le système informatique 700 inclut en outre une interface de réseau 708 qui donne accès à un réseau 712. Dans un mode de réalisation, l'interface de 20 réseau 708 est une carte réseau (NIC pour "Network Interface Card"). L'interface de réseau 708 est utilisée pour télécharger des images d'amorces à partir d'un serveur de source d'images d'amorces à distance, pour amorcer le système informatique 700, conformément à un mode de 25 réalisation. L'image d'amorce téléchargée peut être stockée, par exemple, dans la mémoire principale 104, la mémoire morte 106 ou un autre dispositif de mémoire. Un mode de réalisation porte sur l'utilisation d'un tunnel de données pour fournir, de manière sécurisée, une 30 image d'amorce à un environnement PXE résidant dans le système informatique 700. Conformément à un mode de réalisation, un échange de données avec le système informatique 700 par l'intermédiaire d'un tunnel de données a lieu en réponse à l'exécution par le processeur 701 de 35 séquences d'instructions contenues dans le moyen de stockage non volatil 702. Dans d'autres modes de 2906661 16 réalisation, on peut utiliser un circuit câblé à la place d'instructions de logiciel, ou en combinaison avec celles-ci, pour mettre en oeuvre l'invention. L'invention n'est donc limitée à aucune combinaison spécifique de circuits de 5 matériel et d'instructions de logiciel. La figure 8 illustre la structure de données 800 de l'information transmise en tunnel conformément à un format TLV, comme utilisé dans un mode de réalisation. Une telle forme de réalisation TLV pourrait être une forme de 10 réalisation qui est en accord avec le format spécifié dans le document Network Access Control Protocol (NACP), publié sous la direction de S. Thomson, Cisco Systems, Copyright (C) The Internet Society (2005), mai 2005. On peut utiliser divers procédés TLV, procédés AVP ou d'autres procédés pour 15 transmettre en tunnel des données génériques, pour la transmission sécurisée entre deux correspondants intéressés. Dans cet exemple, une entité telle qu'une source d'images d'amorces envoie de l'information à une autre 20 entité telle qu'un client PXE. L'information peut être envoyée par l'intermédiaire d'un canal d'authentification tel qu'un canal EAP, comme décrit ci-dessus. Dans le flux de données allant vers le client PXE, la source d'images d'amorces peut insérer la structure de données 800. La 25 structure de données 800 commence avec un champ de drapeaux de TLV 801, pour identifier la structure de données TLV 800 et, par exemple, pour désigner une réponse dans le cas où le client PXE ne supporte pas le format TLV. Un champ de numéro de type de TLV, 802, est utilisé pour indiquer 30 comment l'information est formatée dans la structure de données 800. La structure de données 800 inclut également un champ de longueur de TLV 803, pour indiquer une longueur de données qui est envoyée par l'intermédiaire de la structure de données 800. La structure de données 800 35 inclut également un champ de données de TLV 804, également connu sous l'appellation de champ de valeur TLV, qui 2906661 17 représente les données réelles, transmises en tunnel, qui sont envoyées à partir de la source d'image d'amorce vers le client PXE. La figure 8 représente seulement un type de transmission de données en tunnel, de manière générale, et 5 un type de transmission en tunnel TLV, en particulier. Le type exact de TLV/AVP ou d'une autre transmission de données en tunnel utilisée dans des commutateurs de données entre la source d'images d'amorces et le client PXE, n'est pas limité dans divers modes de réalisation. 10 Bien que l'invention ait été décrite en termes de plusieurs modes de réalisation, l'homme de l'art reconnaîtra que l'invention n'est pas limitée aux modes de réalisation décrits, mais peut être mise en pratique avec une modification ou un changement, dans l'esprit et le 15 cadre des revendications annexées. La description doit donc être considérée comme illustrative, plutôt que limitative. REVENDICATIONS 1. Procédé comprenant : établir un canal d'authentification entre un premier système électronique et un deuxième système 5 électronique ; lancer un échange d'amorçage à distance entre un environnement d'amorçage à distance du premier système électronique et le deuxième système électronique à travers le canal d'authentification, l'échange d'amorçage à 10 distance incluant : l'envoi d'une demande d'image d'amorce à partir de l'environnement d'amorçage à distance du premier système électronique, et l'envoi d'une copie de l'image d'amorce à 15 l'environnement d'amorçage à distance du premier système électronique à partir du deuxième système électronique ; et transmettre en tunnel des données liées à l'échange d'image d'amorce, à travers un tunnel de données dans le canal d'authentification. 20 2. Procédé selon la revendication 1, dans lequel les données liées à l'échange d'amorçage à distance comprennent au moins une partie de l'échange d'amorçage à distance. 3. Procédé selon la revendication 1, dans lequel au 25 moins une partie de l'échange d'amorçage à distance est chiffrée, et dans lequel les données liées à l'échange d'amorçage à distance comprennent une information cryptographique pour déchiffrer l'échange d'amorçage à distance. 30 4. Procédé selon la revendication 1, dans lequel l'environnement d'amorçage à distance du premier système électronique est conforme au format INTELTM Pre-boot Execution Environment. 5. Procédé selon la revendication 1, dans 35 lequel le canal d'authentification est conforme au 2906661 19 standard Institute of Electrical and Electronics Engineers (IEEE) 802.1X. 6. Procédé selon la revendication 1, dans lequel le tunnel de données dans le canal d'authentification est un tunnel du genre "paire attribut -valeur" (AVP). 7. Procédé selon la revendication 1, dans lequel le tunnel de données dans le canal d'authentification est une tunnel du genre "type - longueur -valeur" (TLV). 8. Procédé selon la revendication 1, dans lequel le deuxième système électronique est sur un réseau, le procédé comprenant en outre : l'envoi au réseau d'une interrogation Dynamic Hast Configuration Protocol (DHCP) à partir de l'environnement d'amorçage à distance du premier système électronique ; et l'envoi d'un acquittement DHCP à partir du réseau vers l'environnement d'amorçage à distance du premier système électronique. 9. Procédé selon la revendication 1, dans lequel l'échange d'amorçage à distance inclut en outre : l'envoi au deuxième système électronique des paramètres d'authentification du premier système électronique, à partir de l'environnement d'amorçage à distance du premier système électronique ; et l'envoi d'un acquittement de réception de paramètres d'authentification, à partir du deuxième système électronique vers l'environnement d'amorçage à distance du premier système électronique. 10. Procédé comprenant : établir un canal d'authentification ; lancer, par l'intermédiaire d'un environnement d'amorçage à distance, un échange d'amorçage à distance à travers le canal d'authentification, l'échange d'amorçage à distance incluant : l'envoi d'une demande d'image d'amorce, et la réception d'une copie de l'image d'amorce; et 2906661 20 transmettre en tunnel des données liées à l'échange d'image d'amorce, à travers un tunnel de données dans le canal d'authentification. 11. Procédé selon la revendication 10, dans lequel 5 les données liées à l'échange d'amorçage à distance comprennent au moins une partie de l'échange d'amorçage à distance. 12. Procédé selon la revendication 10, dans lequel au moins une partie de l'échange d'amorçage à distance est 10 chiffrée, et les données liées à l'échange d'amorçage à distance comprennent une information de chiffrement pour déchiffrer l'échange d'amorçage à distance. 13. Procédé, comprenant : établir un canal d'authentification avec un système 15 électronique ; commencer un échange d'amorçage à distance avec un environnement d'amorçage à distance du système électronique, à travers le canal d'authentification, l'échange d'amorçage à distance incluant : la réception d'une demande d'une image d'amorce, provenant du système électronique, et l'envoi d'une copie de l'image d'amorce à l'environnement d'amorçage à distance du système électronique ; et transmettre en tunnel des données liées à l'échange d'image d'amorce, à travers un tunnel de données dans le canal d'authentification. 14. Procédé selon la revendication 13, dans lequel les données liées à l'échange d'amorçage à distance 30 comprennent au moins une partie de l'échange d'amorçage à distance. 15. Procédé selon la revendication 14, dans lequel au moins une partie de l'échange d'amorçage à distance est chiffrée, et les données liées à l'échange d'amorçage à distance comprennent une information cryptographique pour 35 déchiffrer l'échange d'amorçage à distance. 20 25 2906661 21 16. Procédé selon la revendication 15, dans lequel au moins une partie de l'échange d'amorçage à distance fait l'objet d'une protection d'intégrité, et les données liées à l'échange d'amorçage à distance comprennent en outre une 5 information de chiffrement (405) pour déchiffrer l'échange d'amorçage à distance. 17. Appareil comprenant : un dispositif de communication pour établir un canal d'authentification ; et 10 une entité fonctionnelle pour établir un environnement d'amorçage à distance pour effectuer un échange d'amorçage à distance par l'intermédiaire du canal d'authentification, l'environnement d'amorçage à distance envoyant une demande d'une image d'amorce et recevant une 15 copie de l'image d'amorce; l'environnement d'amorçage à distance transmet en outre en tunnel des données liées à l'échange d'amorçage à distance, à travers un tunnel de données dans le canal d'authentification. 20 18. Appareil selon la revendication 17, dans lequel les données liées à l'échange d'amorçage à distance comprennent au moins une partie de l'échange d'amorçage à distance. 19. Appareil selon la revendication 17, dans lequel 25 au moins une partie de l'échange d'amorçage à distance est chiffrée, et les données liées à l'échange d'amorçage à distance comprennent une information chiffrée pour déchiffrer l'échange d'amorçage à distance. 20. Système comprenant : 30 un premier ordinateur ayant . un dispositif de communication pour établir un canal d'authentification avec un ordinateur, et une entité pour créer un environnement d'amorçage à distance pour effectuer un échange d'amorçage à distance 35 par l'intermédiaire du canal d'authentification, l'environnement d'amorçage à distance envoyant une demande 2906661 22 d'image d'amorce et recevant de l'ordinateur une copie de l'image d'amorce, l'environnement d'amorçage à distance transmettant en outre en tunnel des données liées à l'échange d'amorçage à distance, à travers un tunnel de 5 données dans le canal d'authentification ; un deuxième ordinateur pour établir un canal d'authentification avec le premier ordinateur et établir l'échange d'amorçage à distance avec le premier ordinateur à travers le canal d'authentification ; et 10 un support de transmission pour supporter le canal d'authentification entre les premier et deuxième ordinateurs, le support de transmission incluant un câble à paire torsadée. 21. Système selon la revendication 20, dans lequel les données liées à l'échange d'amorçage à distance 15 comprennent au moins une partie de l'échange d'amorçage à distance. 22. Système selon la revendication 20, dans lequel au moins une partie de l'échange d'amorçage à distance est chiffrée, et les données liées à l'échange d'amorçage à distance comprennent une information de chiffrement pour 20 déchiffrer l'échange d'amorçage à distance. 23. Support lisible par une machine sur lequel est stocké un ensemble d'instructions qui, lorsqu'elles sont exécutées, font accomplir à un système un procédé caractérisé en ce qu'il comprend les étapes suivantes : 25 établir un canal d'authentification ; lancer, par l'intermédiaire d'un environnement d'amorçage à distance, un échange d'amorçage à distance à travers le canal d'authentification, l'échange d'amorçage à distance incluant 30 l'envoi d'une demande d'image d'amorce, et la réception d'une copie de l'image d'amorce; et transmettre en tunnel des données liées à l'échange d'amorçage à distance, à travers un tunnel de données dans le canal d'authentification. 35 24. Support lisible par une machine selon la revendication 23, sur lequel les données liées à l'échange 2906661 23 d'amorçage à distance comprennent au moins une partie de l'échange d'amorçage à distance. 25. Support lisible par une machine selon la revendication 23, sur lequel au moins une partie de 5 l'échange d'amorçage à distance est chiffrée, et les données liées à l'échange d'amorçage à distance comprennent une information de chiffrement pour déchiffrer l'échange d'amorçage à distance. 26. Support lisible par une machine sur lequel est 10 stocké un ensemble d'instructions qui, lorsqu'elles sont exécutées, font accomplir à un système un procédé comprenant : établir un canal d'authentification avec un système électronique ; 15 effectuer un échange d'amorçage à distance avec un environnement d'amorçage à distance du système électronique, à travers le canal d'authentification, l'échange d'amorçage à distance incluant : la réception d'une demande d'une image d'amorce, 20 provenant du système électronique, et l'envoi d'une copie de l'image d'amorce à l'environnement d'amorçage à distance du système électronique ; et transmettre en tunnel des données liées à l'échange d'amorçage à distance, à travers un tunnel de données dans 25 le canal d'authentification. 27. Support lisible par une machine selon la revendication 26, sur lequel les données liées à l'échange d'amorçage à distance comprennent au moins une partie de l'échange d'amorçage à distance. 30 28. Support lisible par une machine selon la revendication 26, sur lequel au moins une partie de l'échange d'amorçage à distance est chiffrée, et les données liées à l'échange d'amorçage à distance comprennent une information de chiffrement pour déchiffrer l'échange 35 d'amorçage à distance.