Cryptographie en boîte blanche pour la protection des documents numériques

Sommaire-

Le numéro hors-série d'avril-mai de la revue MISC est consacré à un tour d'horizon de l'actualité de la cryptographie, dont nous ne saurions trop recommander l'emplette à nos lecteurs.

Parmi les excellents articles qu'il contient, relatifs par exemple à la cryptographie quantique, à l'espérance de vie des algorithmes face à la cryptanalyse, aux attaques par canaux auxiliaires ou à l'ingénierie inverse des virus pour smartphones, deux exposent et analysent un ensemble de méthodes promises à un bel avenir : la cryptographie en boîte blanche. Ces articles sont signés de Rod Schultz, architecte DRM chez Adobe, et de Brecht Wyseur, architecte de la sécurité et expert cryptographe du groupe NAGRA Kudelski. Ces deux articles seront en outre publiés en anglais sur le site Whiteboxcrypto

De quoi s'agit-il ?

Le problème classique de la cryptographie et ses limites

Le problème canonique de la cryptographie concerne Alice, qui veut envoyer un message confidentiel à Bob, cependant que Célia écoute le réseau et espère déchiffrer le message. Pour ce faire, Alice, à bord de son ordinateur sûr, protégé des yeux de Célia, va chiffrer le message et l'envoyer à Bob. Bob, à bord de son ordinateur sûr, le déchiffrera, et si les bons protocoles ont été respectés, Célia pourra peut-être capturer le message pendant son transport par le réseau, mais pas le déchiffrer.

De plus en plus nombreuses sont les situations qui ne correspondent pas à cette description. D'abord, l'idée que les ordinateurs d'Alice et de Bob soient sûrs et abrités des yeux de Célia est de plus en plus problématique : qui peut affirmer avec certitude qu'aucun espion dactylographique (keylogger) n'a été déposé sur son système un jour, ce qui assurerait un accès permanent à tous les secrets qui lui sont confiés ?

L'exemple de DRM

Un exemple archétypique de ce problème est celui de DRM (Digital Rights Management, gestion des droits numériques), un protocole destiné à exercer des contrôles d'accès sur les œuvres musicales ou vidéographiques enregistrées et commercialisées sur support matériel ou par le réseau. Il s'agit par exemple d'un DVD qui ne peut être joué qu'au moyen du logiciel inscrit sur le DVD lui-même, et qui ne peut être recopié que trois fois. Dans ce cas, les données à protéger et le dispositif de protection sont tous les deux sur le support, propriété de l'acheteur, qui est lui-même l'attaquant potentiel.

L'usage qui en est fait par l'industrie du divertissement a rendu le protocole DRM impopulaire. En fait, le secteur musical de cette industrie a renoncé à DRM dès lors qu'Apple y a renoncé. Rod Schultz nous explique (p. 58) qu'après avoir bâti le succès d'iTunes grâce à DRM, Apple a abandonné ce protocole dès que sa clientèle fut capturée par les iPods, puis par les iPhones et les iPads, ce qui ne laissait plus d'autre choix à la concurrence et aux majors que de suivre le mouvement. Sans l'essor prodigieux d'iTunes, jamais EMI Music n'aurait accepté (en avril 2007) de vendre son catalogue sans DRM, suivi en janvier 2009 par les autres majors. DRM reste bien vivant pour le secteur du cinéma et de la vidéo. Mais ce n'est pas pour cela qu'il faut négliger les leçons qu'il peut nous donner.

Le propos de DRM, nous dit Rod Schultz p. 59, est « d'empêcher un utilisateur d'accéder à quelque chose qui est totalement sous son contrôle ». En effet le propriétaire du DVD, s'il souhaite le recopier pour plus de trois amis, ou l'écouter avec le logiciel de son choix, sous Linux par exemple, devra essayer d'en casser le chiffrement, or, par définition, toutes les données nécessaires sont sous ses yeux et dans son ordinateur. Comment l'en empêcher ? Il est patent que ce problème est assez analogue à celui de la protection d'un document numérique sur un ordinateur compromis, sur lequel l'attaquant a installé des logiciels destinés à en contrôler le fonctionnement, situation qui va devoir être de plus en plus systématiquement prise en considération.

« Quand on conçoit n'importe quel système de sécurité, il est important de commencer par identifier les points faibles et de les prendre en compte dans le design. » Dans le cas de DRM, le fait que l'attaquant possède et contrôle la cible et son système de protection favorise l'attaque, de ce fait, une qualité demandée au dispositif de protection sera la possibilité de le renouveler périodiquement. « Il s'agit pour le concepteur de la DRM d'avoir un canal lui permettant de mettre à jour ses composants logiciels critiques déjà déployés. Cela permet de renouveler et restaurer la sécurité des DRM en cas de compromission majeure. » Atteindre cet objectif est un sacré défi !

Protection par obscurité pour cryptographie en boîte blanche

Tous les manuels de programmation et de génie logiciel vous le diront : le but que doit se fixer le programmeur, c'est d'être clair, lisible, compréhensible, afin de faciliter la construction, la maintenance et l'évolution du programme, ainsi que le travail en équipe. Décomposer le programme en sous-programmes plus faciles à comprendre, selon un découpage logique, avec des interfaces claires entre les modules. Bref, appliquer les leçons de Descartes.

Eh bien pour écrire un programme de chiffrement destiné à affronter des attaques en boîte blanche, il faut faire tout le contraire, pour empêcher l'attaquant d'en comprendre le fonctionnement. En effet, pour reprendre notre exemple du document protégé par DRM, le seul endroit où cacher les clés, c'est sur le même support physique que le document ! Voilà le défi à relever : le secret est sous les yeux (électroniques) de l'attaquant, il ne faut pas qu'il le voie.

Certes, l'attaquant n'aura affaire qu'au programme sous forme binaire, peu lisible pour un humain, mais il pourra utiliser un désassembleur. Un désassembleur effectue le travail inverse des compilateurs, c'est-à-dire qu'au lieu de traduire le texte source du programme écrit par un humain vers un code binaire destiné au processeur, il traduit le code binaire d'un programme exécutable vers un texte en langage de programmation classique, donc compréhensible (au prix d'un peu d'effort), à partir donc du binaire. Et les désassembleurs ne cessent de progresser !

Le programme de protection destiné à fonctionner en boîte blanche sera donc programmé de telle sorte que son organisation et sa sémantique soient de préférence floues et difficiles à comprendre, comme le suggère le diagramme ci-joint.

Protection par la diversité

Afin d'améliorer encore la protection, les DRM sont conçus avec une certaine diversité : pour une famille de DRM conçus sur une même base logicielle, on introduira de la diversité dans le code binaire en modifiant l'agencement des modules et la configuration des interfaces, en ajoutant du texte aléatoire, etc. De même que la diversité du génome et du système immunitaire au sein d'une espèce animale la protège de l'éradication par une pandémie, la diversité binaire des DRM limite les dégâts provoqués par une attaque, que l'on peut comparer à une bactérie ou à un virus auquel certains organismes résistent, d'autres pas. Ainsi même si un attaquant réussit, son succès ne sera pas généralisable.

Architecture des DRM

Le travail de l'attaquant est rendu plus difficile par une organisation hiérarchique des clés :

DRM master key, créée à l'initialisation du DRM sur l'appareil de lecture ;
Device key, créée quand l'appareil commence à jouer le fichier ;
Content key, pour accéder au contenu.

La première est la plus importante, aussi reste-t-elle le moins longtemps en mémoire, ce qui réduit son exposition aux attaques. Cette organisation permet aussi de réserver le fichier à certains types d'appareil.

Le fichier vidéo arrive chiffré sur l'appareil, il est chargé en mémoire, déchiffré, décodé et affiché à l'écran. Il est possible d'attaquer le système soit sur le disque, soit en mémoire pendant la projection. Il est possible que le programme de lecture soit lui-même chiffré sur le disque, ce qui améliore la protection de l'ensemble mais impose un dispositif de déchiffrement adéquat pour le chargement du programme.

L'article décrit assez en détail les méthodes de cryptographie en boîte blanche, et retrace les étapes parcourues par le système de protection développé par Apple pour iTunes, FairPlay. Ce n'est qu'après avoir colmaté les failles de sécurité des premières versions qu'Apple a pu signer des contrats avec Hollywood, en 2005.

Heurs et malheurs d'un cryptographe

Rod Scultz décrit plusieurs expériences vécues chez ses employeurs, Apple puis Adobe. Lors de la première, il devait empêcher les iPods de se synchroniser avec des systèmes autres que iTunes, notamment sous Linux : son système fut cassé en moins de 72h, et le mode d'emploi de l'attaque publié urbi et orbi.

L'expérience suivante consistait à à créer pour Adobe un protocole de chiffrement des flux vidéo pendant leur transport et d'authentification entre le serveur de licences d'Adobe et le lecteur Flash. L'auteur estime que le protocole était assez bien protégé, puisqu'il a résisté 18 mois avant que l'algorithme de chiffrement soit publié sur le Web.

L'article de Brecht Wyseur, qui suit celui de Rod Schultz, Cryptographie en boîte blanche : cacher des clés dans du logiciel, développe les thèmes du précédent avec un éclairage plus théorique et des références intéressantes aux travaux de recherche dans ce domaine.

Nul doute que ces méthodes de chiffrement en boîte blanche, si elles sont, pour des raisons évidentes, dépourvues de l'élégante sobriété mathématique de celles de la « cryptographie classique », n'en sont pas moins porteuses de solutions à des problèmes de protection qui apparaissent déjà et qui ne pourront que se multiplier avec la dissémination des données sur une multitude de supports mobiles dont la protection est souvent très insuffisante.