Vigilance sécuritéBitLocker et le délicat problème de la confiance

Justin Troutman

Windows Vista. Je n'ai encore jamais abordé ce sujet dans un article jusqu'ici, ce qui explique que la rédaction de cette rubrique me procure le même émoi que celui éprouvé par un enfant entrant dans un magasin de jouets à qui l'on a dit de choisir ce qu'il veut. En effet, je pourrais aborder un grand nombre de fonctionnalités, explorer bien des aspects, orienter la discussion sur de nombreux sujets.

Il n'y a pas très longtemps, je lisais le blog du grand manitou de la sécurité, Bruce Schneier, lorsque je suis tombé sur la mention d'un produit que je ne connaissais pas : BitLocker™. J'ai vite compris qu'il était destiné à fournir une fonctionnalité de chiffrement dans Windows Vista® et j'ai immédiatement tiqué en m'écriant : « Oh non. Windows Vista s'occupe de chiffrement ? Ça ne peut pas valoir grand chose. Et même s'il n'est pas mauvais, il y a forcément une porte dérobée quelque part. »

Certains arguments historiques (valide ou pas) permettent de comprendre pourquoi certaines personnes hésitent à faire confiance aux fonctionnalités de sécurité incluses dans Windows®. Mais ce n'est pas ce qui m'a poussé à écrire cette rubrique. Mon désir est plutôt de vous présenter les raisons valables qui justifient, à mon avis, que l'on donne une chance à BitLocker. Je souhaite également donner mon avis sur le genre de philosophie qui permet d'assurer la vitalité des logiciels et matériels de chiffrement.

Mais ne vous y trompez pas : je ne propose pas BitLocker comme une panacée universelle en matière de sécurité. BitLocker est juste l'une des nombreuses pièces composant le puzzle de la sécurité. Son objectif est d'offrir de la résilience face à certains types de menaces.

BitLocker s'intéresse plus particulièrement à la sécurité des ordinateurs portables perdus ou volés. Les employés mobiles transportent sans cesse toutes sortes d'informations confidentielles dans une multitude de lieux : trains et avions, restaurants et hôtels, bureaux à domicile et succursales. Or ils transportent ces informations sur des portables et autres périphériques mobiles qui, le plus souvent, ne disposent d'aucune sécurité réelle et rendent les données qu'ils contiennent extrêmement vulnérables. Alors qu'arrive-t-il à ces données lorsqu'un utilisateur oublie un ordinateur portable quelque part ?

S'il n'est pas possible d'éliminer le manque de rigueur caractéristique de la nature humaine, vous pouvez heureusement limiter les problèmes susceptibles d'en découler. Pour une entreprise, le coût du remplacement d'un ordinateur portable est minime par rapport au coût du traitement de données confidentielles qui ont été compromises. C'est le type de sécurité que BitLocker cherche à fournir.

Crédits

J'aborde BitLocker d'une manière un peu étrange... c'est que, voyez-vous, je ne l'ai pas encore essayé. Je sais que vous vous demandez probablement comment quelqu'un qui n'a même pas essayé BitLocker a pu se forger une opinion à son propos et, a fortiori, avoir quelque chose à en dire. Laissez-moi m'expliquer. Ce que je souhaite surtout, c'est débattre du chiffrement à un plus haut niveau et des philosophies de conception qui jouent un rôle essentiel dans l'élaboration d'une solution efficace.

Tout ceci trouve son origine dans le contenu du blog de Bruce Schneier. Imaginons que vous ayez envie de voir un certain film. En fonction de ce que vous avez vu de la bande-annonce et du choix des acteurs principaux, vous avez fait des suppositions sur ce film. Une bonne distribution, c'est vrai, ne garantit pas que le film sera bon. Cependant, la liste des acteurs est parfois très révélatrice sur le film et sur ce que vous pouvez sans doute en attendre. Les rôles principaux sont-ils tenus par Chris Rock et Ben Stiller ? Ou est-ce un film réunissant Kate Winslet et Johnny Depp ?

Dans le même ordre d'idée, lorsque j'ai découvert qu'un grand manitou de la sécurité internationalement respecté parlait de BitLocker sur son blog, j'en ai tiré quelques conclusions. Tout d'abord, je me suis dit que cette nouvelle technologie était soit suffisamment bonne pour mériter une mention honorable soit si ridiculement mauvaise qu'il fallait la dénoncer publiquement. À ma grande surprise, le verdict final de Bruce Schneier était positif.

Une phrase, en particulier, retenait l'attention : « Il n'y a pas de porte dérobée pour la surveillance policière ». C'est une déclaration marquante. Elle était faite avec beaucoup d'assurance et s'accompagnait d'un lien vers le blog de l'équipe chargée de l'intégrité des systèmes chez Microsoft®. J'ai suivi ce lien, ce qui m'a conduit jusqu'à un commentaire de Niels Ferguson, un développeur s'occupant de sécurité chez Microsoft, lequel s'élevait contre des rumeurs spéculatives selon lesquelles Microsoft aurait intentionnellement inclus des portes dérobées dans BitLocker à des fins d'application de la loi. Ferguson déclarait sans ambages que les portes dérobées étaient inacceptables et qu'il ne participerait à aucun projet qui les prendrait en charge. (Il expliquait également que même si Microsoft était contraint par la loi à inclure une porte dérobée, l'entreprise l'annoncerait publiquement ou retirerait carrément ce produit.)

La signature au bas de cette annonce (celle de Niels Ferguson) explique la confiance de Schneier, et a suscité le même sentiment en moi. Ferguson est quelqu'un qui sait de quoi il parle et son expérience professionnelle permet d'avoir confiance dans ses affirmations. Bruce Schneier et Niels Ferguson sont les coauteurs de Practical Cryptography (un ouvrage de séminaire sur l'application simple, correcte et sécurisée d'un bon système de chiffrement). Ce sont également les co-concepteurs de l'algorithme de chiffrement par bloc Twofish, un réseau de Feistel de 128 bits qui a prouvé sa valeur en parvenant à se classer parmi les finalistes du concours AES (Advanced Encryption Standard).

Bien sûr, disposer d'un cryptographe aguerri sur un projet ne garantit pas que le produit final sera sûr. Même les maîtres de cet art sont faillibles. Mais indépendamment du comportement de BitLocker dans le temps, vous pouvez au moins être certain que de solides stratégies conceptuelles ont contribué à sa création.

Puisque nous parlons d'erreurs, on peut citer les tentatives de bonne foi de développeurs sans aucun sens de ce qu'est le chiffrement, et les tentatives de mauvaise foi de ceux qui cherchent surtout à sortir un produit. Ces deux attitudes, indépendamment de l'intention à leur origine, ouvrent la porte à des failles de sécurité. Ce n'est pourtant pas le cas avec BitLocker, semble-t-il. Le fait qu'au moins un cryptographe compétent ait été impliqué et que de nombreuses ressources soutiennent cet effort est de bon augure.

Quand on parle de confiance

Il y a peu de temps, Phil Zimmerman, le créateur du logiciel de chiffrement PGP, m'a fait part de certaines règles de base. Si l'on publiait un jour un « Credo de sécurité pour les développeurs », ses conseils arriveraient certainement en tête de liste. Bien que ses remarques ne se soient pas spécifiquement adressées à BitLocker, les philosophies de conception qu'elles recommandent peuvent s'appliquer à pratiquement n'importe quelle solution de chiffrement. Vous les trouverez peut-être évidentes, ou extrêmes, mais face aux problèmes de sécurité actuels, elles méritent d'être énoncées de façon explicite.

Lorsqu'il conçoit une infrastructure de chiffrement, le développeur doit rechercher la simplicité, l'exactitude et la sécurité. Bien que les erreurs soient inévitables, elles ne doivent pas être considérées comme des événements naturels que l'on ignore d'un haussement d'épaule. Le développeur doit être un défenseur acharné du perfectionnisme le plus méticuleux. Comme Zimmerman l'a exprimé : « Concevez vos produits comme si une erreur pouvait coûter la vie à quelqu'un ». Vous pensez qu'il exagère ? Lors de la conférence ACSAC (Annual Computer Security Applications Conference) 2005, Brian Snow, cryptographe à la NSA (il a depuis pris sa retraite), a déclaré : « Je veux des fonctions et des assurances dans un dispositif de sécurité. Nous ne faisons pas reposer le test bêta sur le client. Si mon produit connaît une défaillance, quelqu'un pourrait mourir ». N'oubliez pas que les erreurs peuvent avoir plus que de simples conséquences monétaires.

Les utilisateurs méritent des assurances. Gagner, et conserver, la confiance des utilisateurs est crucial. Zimmerman le dit très clairement lorsqu'il déclare : « Gagnez la confiance des utilisateurs. Une fois vous endossez ce fardeau, vous ne pouvez plus jamais le déposer. » En agissant de la sorte, l'entreprise préserve l'assurance du client et sa propre réputation d'entreprise sûre. Si cette confiance est perdue, il est impossible de la regagner.

Ce sont là les perspectives que, je j'espère, Microsoft a gardées présentes à l'esprit lors de la conception de BitLocker (ou de n'importe quel autre produit de la société, du reste). Ceci dit, je veux expliquer pourquoi je crois réellement que Microsoft a fait ce qu'il fallait et fourni un outil technologique de chiffrement qu'il convient de prendre au sérieux.

Le pauvre et son éléphant

Essentiellement, BitLocker est l'élément de Windows Vista (en particulier pour les versions Entreprise ou Intégrale) qui chiffre toutes données de volumes système. Si cette application vous semble simple, pensez aux contraintes qui pèsent sur elle. Étant donné que BitLocker chiffre des données au niveau par secteur et que le texte chiffré ne peut pas dépasser la longueur du texte en clair, il n'y a aucune marge de manœuvre pour quoi que ce quoi d'autre, comme une valeur à usage unique (un numéro ou une chaîne utilisés une fois seulement pour l'authentification), un vecteur d'initialisation ou un code d'authentification de message (MAC). J'avais imaginé que de telles contraintes et les conditions qu'elles imposent étaient probables, mais je savais également que le problème de l'authentification des messages serait résolu d'une façon ou d'une autre.

BitLocker repose sur ce que l'on appelle souvent l'authentification du pauvre. Ce compromis n'est pas aussi modéré qu'on le souhaite généralement puisque il suppose que texte chiffré manipulé ne produit pas un texte en clair significatif. En d'autres termes, si le texte chiffré est manipulé, il doit, par exemple, provoquer une panne du système plutôt que d'autoriser un adversaire à exécuter une certaine fonction.

L'équipe de Microsoft à l'origine de BitLocker savait qu'il faudrait plus de temps pour analyser un algorithme de chiffrement par bloc entièrement nouveau qu'on ne pouvait l'accepter mais les conceptions déjà existantes n'avaient pas encore été assez bien analysées ou n'étaient pas suffisantes. Donc, pour le chiffrement, Microsoft a choisi l’algorithme AES en mode CBC (Cipher Block Chaining) que j'appellerai AES-CBC. Ceci ne se remarque pas dans le modèle d'attaque à texte clair choisi (nom abrégé : IND-CPA), mais l'intégrité n'est pas préservée. Et comme il n'y a pas de place pour un code MAC et que le CBC est un mode de confidentialité, il n'y a absolument aucune préservation de l'intégrité. C'est là que doit intervenir Éléphant.

Le nouveau composant Éléphant utilise deux diffuseurs, conçus pour fournir une authentification du pauvre bien meilleure qu'un simple AES-CBC. (Je dois cependant signaler qu'il existe une option permettant d'exécuter AES-CBC sans Éléphant pour ceux d'entre vous qui doivent respecter des règles strictes de conformité aux normes.) Bien qu'elle ne soit pas toujours idéale, l'authentification du pauvre est la solution la plus appropriée face à certaines contraintes et Éléphant a pour but de tirer le meilleur parti de la situation. Comment exactement ceci fonctionne-t-il ?

L'illustration de la figure 1 l'explique. Lorsque le chiffrement a lieu, le texte en clair est combiné, à l'aide de XOR, à une clé de niveau secteur. Le texte passe ensuite par deux diffuseurs sans clé. Puis le texte est chiffré à l'aide d'AES-CBC. La clé de secteur et AES-CBC requièrent tous deux du matériel de clé et sont donc codés de façon indépendante. Cette méthode simplifie la formalisation d'une preuve pour réduire la sécurité de la construction AES-CBC et Éléphant à celle d'AES-CBC. Éléphant est une nouvelle primitive et les nouvelles primitives sont parfois reçues avec réticence lorsqu'elles n'ont pas été rigoureusement analysées. Mais cette approche équilibre les choses étant donné que BitLocker peut montrer qu'AES-CBC avec Éléphant n'est pas plus facile à attaquer qu'AES-CBC seul.

Figure 1** Authentification du pauvre avec Éléphant **

La clé de secteur et les composants AES-CBC reçoivent tous deux 256 bits de matériel de clé, de sorte que la clé fait 512 bits. Par défaut, cependant, ces composants utilisent seulement 128 bits de matériel de clé, ce qui signifie qu'une partie du matériel de clé n'est pas utilisé. La raison en est simplement qu'il est plus facile de jeter les bits inutiles que de modifier l'infrastructure de gestion des clés lorsque les longueurs de clés varient.

La longueur du bloc peut prendre n'importe quelle valeur multiple de 2, dans la plage entre 512 et 8192 octets. Pour garantir qu'aucune modification du texte chiffré n'entraîne une modification aléatoire de tout le texte en clair d'un secteur, l'algorithme de chiffrement par bloc est conçu pour tolérer de telles variations de la taille du bloc. De plus, s'il se comporte comme un chiffrement par bloc ajustable (comme l'ont décrit Liskov, Rivest et Wagner), avec un algorithme changeant légèrement d'un secteur à un autre, un adversaire ne peut pas parvenir à déplacer le texte chiffré d'un secteur vers un autre secteur.

L'épreuve du temps

Spéculer sur la sécurité du chiffrement de BitLocker revient à parler de l'arbre plutôt que de la forêt. Pour BitLocker, être sûr n'est pas nécessairement suffisant pour pouvoir accomplir sa tâche. Ceci est dû au fait que BitLocker n'est pas une solution en soi mais juste l'un des nombreux éléments périphériques de Windows Vista. Microsoft déclare que BitLocker est solidement intégré à Windows Vista. Mais si l'intégration au système d'exploitation est si étroite, ne serait-il pas logique de supposer qu'une défaillance d'un autre composant pourrait à son tour entraîner une défaillance de BitLocker ou permettre qu'il soit compromis ?

Personnellement, je suis partisan de la modularité et de l'isolement des défaillances. Une étroite intégration dépourvue de modularité conduit à la complexité. Il est vrai que ce n'est peut-être pas le cas avec Windows Vista et BitLocker, mais seul le temps, et des analyses poussées, diront de quoi il retourne.

Alors, quel est mon avis sur BitLocker ? Je tire mon chapeau à l'équipe de Microsoft chargée de l'intégrité des systèmes pour s'être appuyée sur des cryptographes véritables et fiables qui ont fait les choses comme les cryptographes doivent le faire. Il est clair que cette fonctionnalité a été conçue pour la cryptographie, pas pour une campagne de commercialisation. En réponse à cette question, je déclare donc qu'il faut prendre BitLocker au sérieux. N'oublions pas cependant que ceci ne permet pas de déterminer si la sécurité est solide. Une fois encore, seules l'épreuve du temps et une évaluation en situation réelle pourront le dire. Un grand nombre de primitives et de protocoles de chiffrement ont été percés à jour. Mais au moins, l'équipe de Microsoft chargée de l'intégrité des systèmes nous a fourni des connaissances et des plates-formes sur lesquelles s'appuyer pour construire des solutions encore meilleures.

Justin Troutman est un cryptographe aguerri et un étudiant de premier cycle en mathématiques. Son intérêt se porte principalement sur le chiffrement symétrique. Il est également le fondateur d'Extorque, qui se spécialise dans la recherche et les services de conseils en chiffrement

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.