Mozilla ne cesse de le répéter, sa mission est de rendre Internet meilleur pour tous les utilisateurs, c’est-à-dire utilisable, bidouillable, sûr… Relancer l’innovation dans le domaine des navigateurs était une première étape. Firefox a été l’instrument de cette étape, et on peut dire qu’il a rempli sa mission.
Sans le délaisser, il est temps pour la Fondation d’élargir ses activités pour apporter à l’ensemble des composants du Web ce qu’elle a fait pour le navigateur. Cela vaut pour les logiciels de bas-niveau qui s’exécutent sur les smartphones — avec le projet B2G — comme pour les applications sur les serveurs. Sync est une première étape, qui permet de stocker les informations de son Firefox sur un serveur pour les partager entre plusieurs machines.
Mais on peut s’attendre à voir Mozilla lancer dans les prochains mois d’autres services qu’elle hébergera. La fondation va donc héberger de plus en plus de données personnelles de ses utilisateurs, et se pose naturellement la question des mesures à prendre pour garantir au mieux leur confidentialité.
C’est pourquoi Mitchell Baker elle-même introduit ci-dessous un article qu’elle a estimé éclairant sur une question assez technique.
Chiffrement et données utilisateur
Article original paru le 22/12/2011
Nous créons tous de grandes quantités de données personnelles en ligne. Comment devraient être traitées ces données ? Un élément clé est le chiffrement, et offrir la possibilité de stocker les données dans un format qui n’est pas facilement lisible par les gens qui n’y sont pas autorisés. Le « chiffrement » peut rapidement devenir compliqué, et la cryptographie sur lequel il repose peut également être complexe. De ce fait, il est facile de se dire que le « chiffrement » est la réponse en pensant que nos données sont à l’abri si elles sont chiffrées.
Mon collègue Ben Adida a écrit un billet très utile pour évaluer le chiffrement . Il décrit pourquoi le chiffrement fait partie de la solution pour protéger les données, mais n’est pas à lui seul toute la solution. C’est un billet très intéressant, parce qu’il respecte ceux d’entre nous qui ne sont pas cryptographes et qu’il propose un aperçu réfléchi et compréhensible du problème.
Trouver de meilleurs moyens de gérer les données des utilisateurs sera au cœur de nos préoccupations à l’avenir. J’ai été heureuse de lire son article car il m’aide à mieux réfléchir à ces problématiques.
Le chiffrement n’est pas (complètement) de la magie
Article original paru le 21/12/2011
Il y a quelques mois, le réseau Playstation de Sony a été piraté. Des millions de comptes ont été fracturés, dévoilant des adresses physiques et des mots de passe. Sony a reconnu que leurs données « n’étaient pas chiffrées ».
À peu près au même moment, des chercheurs ont découvert que Dropbox stockait des fichiers utilisateurs « non chiffrés ». Des dizaines (ou des centaines ?) de personnes ont fermé leur compte en signe de protestation. Ce sont mes données confidentielles, ont-ils clamé, pourquoi ne les avez-vous pas au minimum chiffrées ?
Beaucoup de gens, incluant des technophiles, ont déclaré qu’il aurait été d’une grande facilité de chiffrer les données, que ne pas l’avoir fait prouve l’incompétence de Sony et Dropbox.
De mon point de vue, ce n’est pas si simple.
Le chiffrement n’a rien de compliqué, c’est vrai. Vous pouvez télécharger le code qui implémente un chiffrement de niveau militaire dans n’importe quel langage en quelques secondes. Ainsi, pourquoi les entreprises ne pourraient-elles donc pas chiffrer les données qu’elles hébergent et nous protéger des pirates ?
Le problème majeur, c’est que pour être utilisable par des êtres humains, les données doivent être déchiffrées. Et donc que la clé de déchiffrement doit se trouver quelque part entre le silo de stockage et l’utilisateur. Pour des raisons de sécurité, on préférerait que la clé de déchiffrement soit le plus loin possible du silo de stockage et le plus près possible des yeux de l’utilisateur. Vous-mêmes, vous aimeriez que la clé de déchiffrement soit *dans* la cervelle de l’utilisateur, non ? Ce n’est pas (encore) possible. En fait, la plupart du temps, conserver la clé si éloignée du silo n’est pas si pragmatique que ça.
Le chiffrement déplace le problème
Sony doit pouvoir débiter votre carte de crédit, ce qui nécessite votre adresse de facturation. Ils en ont probablement besoin que vous soyez en ligne ou pas, car il y a peu de chances que vous aimiez être sollicité tous les mois pour renouveler votre abonnement. Donc, même s’ils chiffrent votre numéro de carte de crédit et votre adresse, ils ont aussi besoin de stocker la clé de déchiffrement quelque part sur leurs serveurs. Et puisqu’ils veulent sûrement vous présenter une page « Mettre mon compte à jour » pré-remplie avec votre adresse, cette clé de déchiffrement doit être disponible pour traiter les données dès que vous cliquez sur « Mettre mon compte à jour ». Si les serveurs web de Sony doivent être capables de déchiffrer vos données, et que les pirates font intrusion sur les serveurs en question, le chiffrement ne vous apportera pas grande protection.
Pendant ce temps, Dropbox veut vous donner accès à vos fichiers où que vous soyez. Ils pourraient garder vos fichiers chiffrés sur leurs serveurs, avec des clés de chiffrement stockées seulement sur votre ordinateur personnel. Certes… jusqu’à ce que vous ayez envie d’accéder à vos données avec l’ordinateur d’un copain. Et que se passe-t-il si vous voulez partager un fichier avec un ami alors qu’il n’est pas en ligne ? D’une manière ou d’une autre, il vous faudra lui envoyer la clé de déchiffrement. Dropbox doit à présent demander à ses utilisateurs de gérer le partage de leur clé de déchiffrement (bon courage pour leur expliquer la manœuvre), ou bien la conserver et gérer les permissions sur cette clé… ce qui signifie stocker des clés de déchiffrement sur ses serveurs. Si vous explorez jusqu’au bout la chaîne d’utilisabilité — et même sans aller jusqu’au bout — il devient clair que Dropbox a probablement besoin de stocker la clé de déchiffrement à proximité des fichiers chiffrés eux-mêmes. Le chiffrement ne peut vous protéger une fois que vous avez vraiment l’intention de déchiffrer les données.
Les fonctionnalités nécessaires à l’utilisateur déterminent souvent l’endroit où est stockée sa clé de déchiffrement. Plus le produit est utile, plus la clé doit être proche des données chiffrées. N’imaginez pas que le chiffrement est une sorte de bouclier magique qui sache distinguer miraculeusement les bons des méchants. Représentez-vous plutôt le chiffrement comme un mécanisme destiné à diminuer la taille du secret (une seule petite clé de chiffrement peut sécuriser des gigaoctets de données), ce qui nous permet de transférer le secret d’un endroit à l’autre. C’est déjà bien utile, mais certes pas aussi magique que beaucoup de gens ne le supposent.
Mais alors que font Firefox Sync, Apple TimeMachine, spiderOak, Helios et tous les autres ?
…mais alors, pourriez-vous vous dire, il existe pourtant des systèmes qui stockent les données chiffrées mais pas la clé de chiffrement. Firefox Sync. Le système de sauvegarde TimeMachine d’Apple. Le système de sauvegarde en ligne de The SpiderOak. Mince, même mon propre système de vote Helios chiffre les votes des utilisateurs dans le navigateur sans stocker nulle part de clé de déchiffrement, sauf dans les machines de l’administrateur.
C’est vrai, dans certains cas bien particuliers, vous pouvez concevoir des systèmes dans lesquels les clés de déchiffrement sont stockées dans l’ordinateur de l’utilisateur. Parfois, vous pouvez même mettre au point un système dans lequel la clé n’est stockée durablement nulle part ; elle est au contraire générée à la volée à partir du mot de passe de l’utilisateur, utilisée pour chiffrer/déchiffrer, puis oubliée.
Mais tous ces sytèmes ont des inconvénients d’utilisabilité non négligeables (mais oui, même mon système de vote). Si vous n’avez qu’une machine connectée à Firefox Sync et que vous la perdiez, vous ne pourrez pas récupérer vos marque-pages et votre historique de navigation. Si vous oubliez votre mot de passe pour TimeMachine ou SpiderOak et que votre disque dur principal vous lâche, vous ne pourrez pas récupérer de sauvegarde de vos données. Si vous perdez votre clé de déchiffrement Helios Voting, vous ne pourrez pas pointer le résultat de vos élections.
Et quand j’écris « vous ne pourrez pas récupérer vos données », je veux dire qu’il vous faudrait une batterie d’opérations mathématiques de vaste ampleur pour les récupérer. Impossible. Vos données sont perdues. Gardez ça en tête : toute la question du stockage de la clé de chiffrement est là. Ce n’est pas un bug, c’est une fonctionnalité.
Et puis il y a le problème du partage…
J’ai abordé ce problème ci-avant, dans ma description de Dropbox : que se passe-t-il lorsque les utilisateurs veulent partager les données les uns avec les autres ? Si les serveurs ne disposent pas de la clé de déchiffrement, cela signifie que les utilisateurs doivent se la transmettre. Peut-être pensez-vous pouvoir utiliser une clé de chiffrement dont chaque utilisateur a une paire, l’une qui est publiée et publique, l’autre qui est privée et demeure secrète ? Nous voilà revenus au problème « vous ne pouvez pas récupérer vos données » si l’utilisateur perd sa clé privée.
Et que se passe-t-il pour des fonctionnalités comme le fil d’actualité de facebook, lorsque les serveurs traitent, malaxent, rassemblent et filtrent les données des utilisateurs avant même qu’ils ne puissent les voir ? Si le serveur ne peut pas déchiffrer les données, comment donc peut-il vous aider à les traiter avant que vous ne les ayez vues ?
Soyons clair : si votre site web propose des fonctionnalités de partage, il est peu vraisemblable que vous puissiez remettre les clés de déchiffrement à l’utilisateur. Vous aurez besoin de lire des données sur vos serveurs. Et si ces derniers ont besoin de lire les données, alors un pirate qui s’introduit sur les serveurs peut lire les données lui aussi.
Donc le cryptographe me dit que chiffrer est inutile ?
Non, pas du tout. Je dis seulement que le chiffrement avec des clés contrôlées par les utilisateurs a bien moins d’applications que ne le pensent la plupart des gens. Le périmètre de ces applications doit être bien défini, et elles doivent afficher en gros des avertissements sur les conséquences d’une perte de clés.
Cela dit, le chiffrement demeure un outil très puissant pour diviser le pouvoir et les droits d’accès du côté du serveur. Si vous devez stocker des numéros de carte de crédit, il vaut mieux créer un sous-système dont l’unique rôle est de stocker les numéros de carte en les chiffrant, et gérer les transactions dans des parties distinctes du système. Si tout votre système est compromis, ça ne vaut pas mieux que si vous n’avez pas pris ces précautions. Mais si une seule partie du système est compromise, le chiffrement pourrait bien empêcher un attaquant d’accéder aux parties les plus sensibles du système.
Vous pouvez pousser très loin cette idée d’utiliser le chiffrement comme un moyen de contrôler les accès. Une équipe du MIT vient de publier CryptDB, une base de données relationnelle modifiée pour utiliser des techniques intéressantes de chiffrement pour renforcer drastiquement les contrôles d’accès. Notez que si vous détenez le mot de passe pour vous connecter à la base, ce chiffrement ne masquera pas les données : la clé pour les déchiffrer est sur le serveur. Cela n’en reste pas moins une bonne approche de défense en profondeur.
D’accord, j’ai un peu menti en parlant du pré-traitement des données. Il existe un type de chiffrement, le chiffrement homomorphique, qui vous permet d’exécuter des opérations sur les données sans les déchiffrer. Ces dernières années ont vu de grands progrès dans ce domaine, et c’est très excitant… pour un cryptographe. Ces techniques demeurent extrêmement peu pratiques dans la plupart des cas d’utilisation courants, avec une surcharge de l’ordre du trillion, tant en termes de stockage que de temps de traitement. Et même si elles deviennent plus utilisables, elles n’en suppriment pas moins le problème central de la clé servant à déchiffrer : obliger les utilisateurs à gérer des clés de déchiffrement est, pour l’essentiel, un cauchemar en termes d’utilisabilité. Ceci dit, je dois l’admettre, le chiffrement homomorphique confine vraiment à la magie.
Le cas particulier des mots de passe
Les mots de passe sont à part, car une fois qu’ils sont enregistrés, vous n’avez jamais besoin de les relire, vous devez juste vérifier que le mot de passe tapé par l’utilisateur correspond à celui stocké sur le serveur. C’est très différent d’un numéro de carte de crédit, qui doit pouvoir être relu après avoir été stocké, pour que la carte puisse être débitée tous les mois. Pour les mots de passe, il existe donc des techniques particulières. Ce n’est pas du chiffrement, car le chiffrement est réversible, et le but de la manœuvre, c’est que le système empêche l’extraction de mots de passe de la base. Nous utilisons un outil spécial, une fonction à sens unique, comme bcrypt. Prenez le mot de passe, passez-le à travers la moulinette de cette fonction et ne stockez que le résultat. La fonction à sens unique est conçue pour rendre très difficile l’opération inverse : vous devez essayer un mot de passe pour voir s’il correspond. C’est très pratique, mais ça ne peut être utilisé que pour les mots de passe.
Si vous stockez des mots de passe, vous devez absolument les faire passer à travers une fonction à sens unique. Vous pouvez dire que vous les « hachez », ça y ressemble. En fait, on peut probablement dire qu’on les sale et qu’on les hache. Mais quelle que soit la technique utilisée, il ne s’agit pas d’un « chiffrement » des mots de passe. Ça ne rime à rien.
Le chiffrement n’est pas de la magie
Pour l’essentiel, le chiffrement n’est pas de la magie. Il vous permet de mieux garder vos secrets, mais si les utilisateurs participent à la gestion des clés, c’est de façon quasi-certaine au détriment de l’utilisabilité et des fonctionnalités. Les services web devraient vraiment penser à utiliser le chiffrement lorsque c’est possible pour gérer de façon plus stricte leurs contrôles d’accès internes. Mais réfléchissez-y à deux fois avant de vous lancer dans la conception d’un produit qui oblige les utilisateurs à gérer leurs clés. Dans de nombreux cas, les utilisateurs ne comprennent tout simplement pas que perdre leurs clés signifie perdre leurs données. Comme l’explique mon collègue Umesh Shankar, si vous concevez une serrure de voiture tellement inviolable qu’en oubliant vos clés à l’intérieur vous êtes bons pour l’envoyer à la casse et en racheter une, alors vous vous êtes sans doute trompé quelque part.
Un billet de Clochix, traduction Clochix et Goofy
.
