Défendu ardemment par Apple et l'ensemble de l'industrie high-tech, conspué par certains politiques et représentants des forces de l'ordre, le chiffrement des données est au centre de débats enflammés depuis plusieurs mois. Gage de la protection de la vie privée pour les uns, il est l'obstacle entravant la sécurité des citoyens face aux criminels pour les autres.

Mais de quoi parle-t-on exactement ? Comment fonctionne le chiffrement ? Quelles sont les technologies employées par Apple ? Nous avons interrogé Vincent Bénony, titulaire d'une thèse en cryptographie et développeur du logiciel de rétro-ingénierie Hopper (lire aussi Interview : Hopper, le logiciel qui renverse la sécurité du Mac).

MacGeneration : De manière très générale, qu'est-ce que le chiffrement ? À quoi ça sert et comment cela fonctionne ?

Vincent Bénony : Le principe du chiffrement est de sécuriser un échange de données en les rendant inintelligibles par une personne qui intercepte le message, mais qui ne possède pas la clé de déchiffrement. Ça va même un petit peu plus loin, puisque l'idée du chiffrement est de transformer des données, comme un texte, en quelque chose d'indiscernable de données purement aléatoires. C'est-à-dire que si je vous donne une série de bits sans plus de détails, il ne vous sera pas possible de me dire s'il s'agit simplement de « 0 » et de « 1 » tirés à pile ou face, ou bien s'il s'agit de quelque chose qui a été chiffré.

Il existe deux grandes familles de systèmes de chiffrement : les systèmes symétriques, et les systèmes asymétriques. La différence concerne les clés.

Dans un système de chiffrement symétrique, comme l'AES, le RC4, etc., la clé qui sert au chiffrement est la même que celle qui sert au déchiffrement. Deux personnes qui souhaitent s'échanger des messages chiffrés en AES doivent au préalable s'être échangées une clé secrète commune.

Pour les systèmes asymétriques, comme le RSA, la clé de chiffrement n'est pas la même que la clé de déchiffrement : l'une est publique (la clé de chiffrement), l'autre est privée (la clé de déchiffrement). Il ne doit pas être possible de retrouver facilement la clé privée à partir de la clé publique. Dans ce cas, si je souhaite échanger des messages chiffrés en RSA avec quelqu'un, je construis dans mon coin ma clé publique et ma clé privée, et j'envoie ensuite la clé publique à mon interlocuteur. Il fait de même de son côté, et quand je souhaite lui envoyer un message, j'utilise sa clé publique.

Les systèmes de chiffrement asymétriques peuvent aussi servir à faire de la signature numérique. Une signature numérique sert par exemple à prouver que le document n'a pas été modifié, et qu'il provient bien d'une personne donnée. C'est ce qui est fait quand on paie ses impôts en ligne par exemple. Dans ce cas, le rôle des clés est inversé, et la personne qui désire signer un document va calculer une empreinte numérique du document (comme un condensat SHA-256 par exemple), et chiffrer cette empreinte avec sa clé privée. Toute personne qui souhaite vérifier l'authenticité de la signature peut le faire en calculant à son tour la même empreinte, et en la comparant à l'empreinte déchiffrée par la clé publique.

Est-ce que l'on peut chiffrer tous les appareils informatiques et tous les types de données ? Faut-il un composant spécial pour gérer le chiffrement ?

Il est tout à fait possible de chiffrer n'importe quel type de données. Après tout, un fichier n'est qu'une longue suite de 0 et de 1. Le sens qu'on lui donne est purement subjectif. Je veux dire que le concept de document PDF ou d'image PNG n'est pas intrinsèque aux données, c'est juste une question d'interprétation par les applications. Même la notion de caractère dans un fichier n'est qu'une convention…

En général, on regroupe ces bits par paquets de 8, ce qui permet de les considérer comme un nombre en base 2, et donc d'en calculer une valeur entre 0 et 255. Ensuite, on utilise des choses, comme la table ASCII, qui est un tableau de 256 signes, où l'on a associé un caractère, ou un symbole, à chaque nombre. Par exemple, la valeur 65 est associée à la lettre "A" majuscule.

Quand un logiciel lit un fichier, il tente de donner un sens à cette suite de nombres en fonction de règles. Par exemple, si la suite de bits, transformée en une suite de caractères grâce à la table ASCII, commence par les symboles "%PDF", alors on va utiliser les règles qui définissent les documents PDF pour interpréter le reste du fichier. Si au contraire le document commence par les nombres 31, puis 139, alors il y a de fortes chances que ce soit un fichier compressé en gzip, etc.

Et on peut descendre encore plus bas, car même la notion de fichier n'est qu'une convention : un disque dur, une clé USB, ou tout autre support de stockage ne sont que des immenses suites de bits, que le système d'exploitation interprète comme des fichiers selon des règles bien précises qui diffèrent d'un OS à l'autre (HFS+ sous OS X, NTFS sous Windows, Ext4 sous Linux, et bien d'autres).

En partant de ce principe, strictement tout peut être chiffré ! Je peux tout à fait décider de donner une autre interprétation aux données, et les utiliser en entrée à mon système de chiffrement. Pour être à nouveau compréhensible par le système d'exploitation et les applications, il suffit de déchiffrer la suite de nombres.

Souvent, les systèmes de chiffrement sont directement intégrés aux systèmes d'exploitation. En gros, ils se logent entre le pilote du disque dur (qui écrit les données brutes sur le disque) et le système de fichiers. Ils procèdent au chiffrement et au déchiffrement à la volée, en fonction d'une clé qui dépend d'un mot de passe par exemple.

Il n'est pas nécessaire d'avoir du matériel dédié pour faire du chiffrement. Par contre, les opérations de chiffrement sont généralement coûteuses en termes de CPU, et c'est pourquoi on a tendance à équiper les appareils de puces dédiées pour soulager le CPU, surtout sur les appareils mobiles. Dans le cas des processeurs Intel, le CPU possède des fonctions primitives qui permettent de simplifier le calcul de l'AES.

Pour chiffrer leurs données, les appareils iOS utilisent la technologie AES 256-bits. Quelles sont ses caractéristiques et quelle est sa robustesse ?

L'AES (Advanced Encryption Standard) est un système de chiffrement qui a été mis au point dans le cadre d'un concours au tout début des années 2000, pour remplacer le vieillissant système de chiffrement DES (Data Encryption Standard), utilisé jusque-là pour chiffrer les documents officiels aux États Unis. Il s'agit d'un système de chiffrement symétrique, qui peut fonctionner avec des clés de 128, 192 ou 256 bits.

Il fait partie de la famille des systèmes de chiffrement par bloc (en opposition aux systèmes de chiffrement par flot), ce qui veut dire qu'il découpe les données à chiffrer en blocs de 128 bits (16 octets), et procède à différentes transformations et mélanges en fonction des bits de la clé. Ce qui est intéressant avec l'AES, c'est qu'il a été pensé pour que les différents calculs soient simples à mettre en œuvre sur un CPU classique.

C'est un système qui a largement fait ses preuves ces dernières années, et on ne lui connaît pas de véritable biais exploitable. Ça signifie que pour déchiffrer un message dont on n'a pas la clé, il faut en essayer un grand nombre, et voir si le message déchiffré a un sens.

Imaginez que vous souhaitiez retrouver la clé qui a servi au chiffrement d'un message en AES 256. En moyenne, il faudrait tester la moitié de l'espace des 2^256 clés possibles, soit 2^255 clés. Imaginez encore que vous disposiez d'un appareil capable de tester une clé toutes les nanosecondes. Il faudrait donc environ 5,79 * 10^76 tentatives, ce qui fait approximativement 6,7 * 10^62 jours, ou encore 1,8 million de milliards de milliards de milliards de milliards de milliards de milliards d'années en moyenne pour déchiffrer un message…

Il y a quelques années, des chercheurs ont trouvé quelques petites faiblesses dans l'algorithme de l'AES qui permettent de réduire le temps de calcul par 4 (ce qui est suffisant en cryptographie pour dire que le système est "cassé"), mais même dans ce cas, ça laisse pas mal de marge.

Récemment, Apple a indiqué à un juge qu'elle ne pouvait pas accéder aux données d'un iPhone verrouillé. Sur son site, la firme explique la même chose : « Sur les appareils sous iOS 8 ou ultérieur, vos données personnelles sont protégées par votre code. En effet, pour ces appareils, Apple ne peut répondre aux demandes d’extraction de données iOS émanant des autorités » Est-ce vraiment impossible pour Apple de passer outre les protections d'un iPhone ? C'est pourtant elle qui a mis au point le système de chiffrement. N'a-t-elle pas les moyens d'avoir la clé pour ouvrir un iPhone sous iOS 8 ou ultérieur ?

Le schéma mis en place par Apple est détaillé dans un document public [Guide de sécurité iOS]. Il est assez complexe, et fait appel à tout un tas de clés en cascade.

Pour résumer, chaque fichier est chiffré avec une clé différente, générée aléatoirement au moment de la création de ce fichier. Cette clé est conservée chiffrée à l'aide d'une autre clé, qui est elle-même calculée en fonction d'un identifiant matériel (qui a été injecté dans le téléphone lors de sa fabrication), et du code PIN de l'utilisateur.

Cette dernière clé est calculée en interne par la puce cryptographique qui a la charge d'effectuer les opérations de chiffrement et de déchiffrement. Ainsi, elle ne sort pas, et elle n'est pas accessible au système d'exploitation, ni même aux différentes interfaces, comme le JTAG. Seules les données chiffrées et déchiffrées sortent de la puce. Pour extraire l'identifiant matériel de la puce, il faudrait la décortiquer physiquement à l'aide d'appareils extrêmement coûteux ; c'est très compliqué, très délicat, et surtout, très aléatoire.

Toute la sécurité du système repose donc sur la non-divulgation de l'identifiant matériel. Il est très probable que cet identifiant soit issu d'un processus aléatoire purement physique lors de la fabrication de la puce, ce qui exclut la possibilité de le lire et de le stocker.

Si Apple souhaitait mettre en place une porte dérobée, une technique possible serait de réduire l'entropie du générateur aléatoire utilisé pour créer les clés de chiffrement des différents fichiers. En gros, l'idée serait de faire en sorte que la clé ne soit pas totalement aléatoire, mais seulement en partie aléatoire, ce qui réduirait considérablement la quantité de calculs à faire pour la retrouver. Même si c'est techniquement faisable, il semble fort peu probable qu'ils l'aient fait… Au contraire, Apple semble avoir utilisé toutes les bonnes pratiques cryptographiques à ce niveau.

Les fichiers chiffrés par iOS semblent donc bien à l'abri, et je vois effectivement assez mal comment Apple pourrait passer outre…

Après, rien ne dit qu'on ne découvrira pas une méthode pour exfiltrer l'identifiant matériel de la puce cryptographique par un canal auxiliaire. Ce sont des choses qui se sont déjà vues. Par exemple, sur certaines smart cards (comme les cartes bancaires, ndr), en mesurant les fluctuations de la consommation énergétique pendant une phase de chiffrement, il était possible de récupérer de l'information sur les bits de la clé secrète. Mais c'est un domaine qui est maintenant relativement bien maîtrisé, et il y a peu de chance que les puces d'Apple en souffrent.

Le gouvernement britannique réclame depuis des mois une « porte d'entrée » — de la novlangue pour parler d'une porte dérobée — dans les programmes de chiffrement. Est-ce qu'une porte dérobée réservée à une seule organisation, dans le cas présent les autorités, est faisable ? N'y a-t-il pas le risque que d'autres personnes s'engouffrent dans cette porte, comme prévient Tim Cook, entre autres ?

Une porte dérobée réservée aux autorités, c'est tout à fait faisable. Il est possible, par exemple, de faire en sorte que les clés, utilisées pour chiffrer les fichiers, soient stockées de manière chiffrée comme c'est le cas actuellement, mais en double, avec deux clés différentes : une fois avec la clé utilisée actuellement, et une autre fois avec une clé que les autorités possèdent.

Malgré tout, il y aurait plusieurs problèmes. Premièrement, s'il y a une fuite de la clé gouvernementale, tout le système tombe par terre, et il ne sera pas possible de faire marche arrière. Aujourd'hui, il ne peut pas y avoir de fuite, puisque la seule copie de la clé utilisée se trouve dans la puce.

L'autre problème, c'est qu'il semble a priori impossible de modifier les iPhone existants pour fonctionner avec un nouveau système contenant une porte dérobée. Il faudrait en effet que la puce cryptographique intègre aussi la clé partagée. Or, ce n'est possible que lors de la fabrication. Ou alors, il faudrait tout implémenter de manière logicielle, avec les problèmes de performances qui vont avec…

Est-ce que tu penses que tout le monde a intérêt à chiffrer ses appareils et ses communications ?

J'aurais tendance à pousser les personnes dans mon entourage à chiffrer au maximum leurs données, tant que ça ne complique pas trop l'utilisation du service. Ne serait-ce que pour éviter les fuites d'informations sensibles, comme certains mots de passe, des cookies de session, etc. Il y a autour de moi beaucoup de gens qui se connectent à des réseaux Wi-Fi gratuits, et qui ne réalisent pas à quel point il est simple de récupérer des données dans ce cas-là.

Un procureur de Manhattan a récemment déclaré qu'il n'avait pas pu mener 111 mandats de perquisition de données à cause du système de chiffrement d'iOS 8. Apple ne va-t-elle pas trop loin dans son « engagement de confidentialité » ? Tim Cook a élevé le respect de la confidentialité des utilisateurs au rang de principe moral. Mais Apple n'a-t-elle pas également le devoir moral de coopérer avec les autorités dans l'intérêt commun ?

C'est un avis très personnel, mais je ne pense pas qu'il faille faire marche arrière concernant le chiffrement des appareils iOS. De toute façon, si une personne souhaite réellement cacher ses communications aux autorités, il y a des tonnes de solutions très simples déjà disponibles, que ce soit le chiffrement par des outils tiers, de la stéganographie, etc. Je doute que les terroristes aient attendu iMessage pour ça.

Et concernant l'utilisateur lambda, le chiffrement systématique des données d'iOS permet de limiter la casse, par exemple, en cas de vol. D'autant plus qu'Apple a tendance à pousser ses utilisateurs à enregistrer tout un tas de données très personnelles dans leur téléphone, comme le numéro de leur carte bancaire par exemple (pour remplir les formulaires d'achat sur Internet), et ce serait une catastrophe s'il était facile de récupérer toutes ces données après un vol.