Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

Cryptographie en boîte blanche pour la protection des documents numériques
De nouvelles pistes inspirées des DRM
Article mis en ligne le 14 juin 2012
dernière modification le 24 janvier 2014

par Laurent Bloch
logo imprimer

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.


Forum
Répondre à cet article


pucePlan du site puceContact puceEspace rédacteurs puce

RSS

2004-2017 © Site WWW de Laurent Bloch - Tous droits réservés
Site réalisé sous SPIP
avec le squelette ESCAL-V3
Version : 3.87.47