Bannière Cookies

En poursuivant votre navigation sur ce site, vous acceptez l’utilisation de cookies pour réaliser des statistiques de visites.

Article

Faire face aux nouveaux risques liés au Big Data et au cloud

Prof. Bryan Ford

Une approche holistique de la sécurité des données.

Par Bryan Ford, titulaire de la chaire AXA en sécurité des informations et vie privée, École Polytechnique Fédérale de Lausanne.

Alors que les progrès passionnants de l'informatique ouvrent de nouveaux horizons, la progression de l'informatique dans le cloud engendre aussi de nouveaux risques ; et ceux que nous connaissons aujourd’hui ne sont peut-être que la partie émergée de l'iceberg, explique le professeur Ford. Ce ne sont pas les problèmes directement liés à votre fournisseur de cloud, comme les pannes d’accès, qui l'inquiètent, mais les risques de second ordre. Il s'agit notamment des services dans le cloud qui peuvent sembler indépendants, mais qui partagent en fait des ressources en cachette, ce qui compromet la sécurité habituellement assurée par la redondance dans un système. « Cela pourrait créer des corrélations de défaillances inattendues et potentiellement catastrophiques, qui rappellent les krachs de l'industrie financière », explique le professeur Ford. Il faut également se pencher d'urgence sur le défi que représente le cloud pour la préservation des documents numériques. La technologie évolue rapidement et les versions deviennent désuètes, ce qui met en danger la disponibilité à long terme. Avec les applications en cloud, les utilisateurs ne sont jamais en possession d'une copie complète et fonctionnelle de l'élément à stocker dans un référentiel - pensez aux moteurs de recherche ou aux applications cartographiques, par opposition aux logiciels de traitement de texte installés directement sur votre ordinateur. Alors, comment les archivistes numériques peuvent-ils archiver dans le cloud des documents qui ont une importance historique pour la préservation culturelle à long terme ?

Le projet de recherches du professeur Ford permettra tout d'abord de mieux comprendre les questions comme celle-ci, qui doivent être posées dans cette nouvelle ère du cloud. En réponse aux risques encourus, il concevra également de nouvelles architectures de systèmes capables de faire face aux problèmes posés. Il vise à mettre au point des méthodes permettant de quantifier le risque d'atteinte à la vie privée ou d'échec dans un système. Ensuite, il créera des prototypes capables d'utiliser cette mesure pour reconfigurer les systèmes de cloud à risques. En commençant dès maintenant, le professeur Ford espère comprendre les risques et trouver des solutions « avant que notre tissu socio-économique ne devienne inextricablement dépendant d'un modèle informatique pratique mais potentiellement instable », dit-il.

Apple, FBI et transparence des logiciels*

*From Freedom to Tinker, Princeton's Center for Information Technology Policy, 10 mars 2016, https://freedom-to-tinker.com/2016/03/10/apple-fbi-and-software-transparency

 L'affrontement entre Apple et le FBI est rapidement devenu une poudrière d’importance cruciale dans la « nouvelle guerre du cryptage ». Le 16 février, le FBI a invoqué le All Writs Act de 1789, une loi fourre-tout au service des forces de l'ordre, exigeant qu'Apple crée une version personnalisée de son iOS pour aider le FBI à décrypter un iPhone utilisé par l’un des tireurs de San Bernardino. Le fait que le FBI ait permis à Apple de divulguer l’ordre publiquement, le jour même, constitue une rare exception au penchant secret habituel du gouvernement.

Les raisons derrière l’agitation inhabituelle du FBI sont importantes - le risque qu'une fois cette affaire terminée, le FBI et d'autres agences gouvernementales reviennent à des méthodes plus obscures pour obliger les entreprises à utiliser leurs logiciels de manière détournée est encore plus grand. Ce billet de blog explore ces risques de transparence des logiciels, et comment de nouvelles mesures techniques pourraient aider à s’assurer que le débat public sur les portes logicielles dérobées reste public.

L'ordonnance d'aide au décryptage

Apple et d'autres sociétés technologiques se conforment régulièrement aux demandes gouvernementales sur les données en leur possession. La distinction clé de l'ordonnance controversée, cependant, est que les données ne sont pas en possession d'Apple, mais se trouvent sur un iPhone crypté, et l'ordonnance oblige Apple à créer de nouveaux logiciels pour aider le FBI à contourner la sécurité de cet iPhone. Bien qu’Apple soit probablement techniquement capable de se conformer à l'ordre du FBI, la société s'y oppose au motif que « le gouvernement exige qu'Apple crée une porte dérobée pour déjouer le cryptage sur l'iPhone, rendant les informations les plus confidentielles et personnelles de ses utilisateurs vulnérables aux pirates, aux voleurs d'identité, aux agents étrangers hostiles et à une surveillance gouvernementale non justifiée ».

En effet, exiger qu'Apple, une société privée, crée un nouveau logiciel sur ordre du gouvernement, affaiblissant la sécurité des appareils de la marque et révélant les secrets les plus intimes de leurs utilisateurs, pourrait enfreindre le premier amendement. En tout cas, c'est « comme demander à General Motors de construire un nouveau camion avec une sellette pour le mois prochain ».

Le FBI pourrait probablement créer sa propre version de l'iOS avec une porte dérobée. Cependant, les appareils d’Apple n'acceptent que les mises à jour logicielles signées numériquement avec une clé secrète que seul Apple contrôle. Vraisemblablement. Nous y reviendrons.

Pourquoi toute cette médiatisation ?

Le plus intéressant et le plus surprenant dans cette affaire est la rapidité avec laquelle le public l’a appris d'Apple. Le FBI aurait pu envoyer discrètement cette demande, comme il a déjà par le passé effectué des demandes équivalentes à Apple pour l’aide au décryptage - ainsi qu'à d'autres sociétés telles que Lavabit, le fournisseur de courrier électronique maintenant disparu qu’Edward Snowden utilisait.

Apple aurait même demandé que l'ordre du FBI soit confidentiel, mais le FBI voulait une confrontation publique. Les faits contredisent cependant les affirmations du FBI selon lesquelles il avait un besoin urgent du contenu de cet iPhone : les tueurs étaient déjà morts depuis longtemps, la montagne de métadonnées que le FBI avait déjà sur les tueurs n'avait révélé aucune trace de liens avec d'autres terroristes et l'iPhone en question était un téléphone professionnel fourni par l'employeur que les tueurs ne se sont pas donné la peine de le détruire comme ils l’ont fait pour leurs deux téléphones personnels. L'interprétation des faits de selon le rasoir d’Occam suggère que le FBI s'intéresse beaucoup moins aux données elles-mêmes qu'à la jurisprudence qu'une victoire juridique établirait.

En résumé, le FBI semble « faire de la politique » par le biais d'une « bataille juridique soigneusement planifiée... des mois à l’avance ». L'iPhone en question représente une bataille stratégiquement choisie sur laquelle le FBI pense pouvoir gagner en utilisant la carte terroriste - même si cet iPhone-là n'a en fait que peu ou pas de valeur pour les renseignements.

Apple est soutenu par une multitude de citoyens américains, des organisations d'intérêt public telles que l'ACLU (l’Union américaine pour les libertés civiles), l'EFF (une ONG pour la protection des libertés sur Internet) et le CDT (Centre pour la démocratie et les technologies) et de nombreux géants de la technologie comme Google, Intel, Microsoft, Cisco et Amazon, des journaux comme le New York Times et le Wall Street Journal, le haut commissaire des Nations unies aux droits de l’homme et même l’ancien directeur de la NSA et d’autres hauts fonctionnaires du gouvernement américain.

L'alternative du secret, passé et futur

Aussi importante que soit cette affaire publique, le FBI et les gouvernements du monde entier suivent et ont souvent suivi ces mêmes objectifs discrètement : Apple contre le FBI est l'exception qui confirme la règle. Rappelons le résultat des premières guerres du cryptage, dans lesquelles le gouvernement américain a tenté de rendre obligatoire le cryptage par clé tierce avec la tristement célèbre Clipper Chip. Bien que le gouvernement ait perdu cette bataille publique, il n'a pas abandonné ses efforts pour compromettre le cryptage : il les poursuit simplement dans l'ombre.

Par exemple, la NSA a apparemment glissé une porte dérobée dans une norme du NIST (National Institute of Standards and Technology) pour la génération de nombres aléatoires, permettant au détenteur d'un secret de compromettre tous les algorithmes cryptographiques d'un dispositif. Démontrant les dangers d'essayer de garder une porte dérobée accessible uniquement aux « gentils », un hacker a récemment réussi à « recoder » et à récupérer une copie latente de ce générateur de nombres aléatoires dans les routeurs de Juniper Networks.

Même si la raison prévaut dans ce nouveau cycle des guerres du cryptage, nous pouvons compter sur les tentatives ininterrompues des États-Unis et des gouvernements du monde entier pour mettre en place des portes dérobées secrètes. Les gouvernements peuvent bien sûr exploiter les bugs logiciels ou les vulnérabilités physiques pour infiltrer des appareils personnels, mais les portes dérobées secrètes restent le but ultime. Il est plus facile, moins cher et moins risqué d'exploiter une porte dérobée connue que « d’entrer dans le coffre au trésor... et de concevoir un programme personnalisé ».

La mise à jour du logiciel comme porte dérobée

Presque tous les appareils personnels actuels, y compris ceux d'Apple, disposent déjà d'une « porte dérobée » prête à être exploitée, sous la forme de mises à jour logicielles automatiques validées par des signatures numériques. Une façon pour le gouvernement américain d'acquérir une porte dérobée universelle vers les appareils d'Apple est simplement d'exiger une copie des clés secrètes de signature du logiciel d'Apple. Le gouvernement s'est déjà montré disposé à le faire en exigeant les clés du service de courrier électronique crypté de Lavabit lors de l'enquête sur Snowden. Ce n'est peut-être pas tout à fait anodin si les clés de signature logicielle d’Apple sont conservées dans des modules de sécurité matérielle conçus pour bloquer l'extraction ou le clonage de ces clés. Dans ce cas, cependant, le gouvernement pourrait tout simplement exiger qu'Apple utilise sa clé secrète pour produire une signature numérique valide pour la version avec porte dérobée de l'iOS du FBI, tout en gardant ce processus et l'existence même de cet iOS spécial secret.

Même si Apple remporte cette bataille publique, ils devront faire face à des craintes et à des soupçons bien fondés - de la part d'entreprises et de gouvernements du monde entier - quant à la possibilité de contraindre Apple à participer secrètement à la signature d'images de logiciels et de microprogrammes avec portes dérobées. Ce risque n'est en aucun cas spécifique à Apple : toute compagnie créant et diffusant des logiciels y est confrontée. Même les logiciels libres ne sont pas à l'abri : impossible de s’assurer qu'une mise à jour logicielle représente une version correcte et non une version avec porte dérobée, à moins de la programmer vous-même, ce que peu d'utilisateurs font.

Transparence du logiciel grâce à la cosignature décentralisée des témoins

Dans IEEE Security & Privacy 2016, nous présenterons un document (avant-projet disponible ici) introduisant la cosignature de témoins décentralisée, un moyen technologique utilisé par les fabricants de logiciels comme Apple pour protéger leurs utilisateurs de versions secrètement détournées avec portes dérobées de leurs logiciels - et pour se protéger et protéger leurs résultats financiers des craintes et des suspicions mondiales concernant la possibilité de l’existence de logiciels piratés.

Avec les signatures numériques conventionnelles, telles qu'elles sont actuellement utilisées pour la plupart des processus de signature de logiciels et de microprogrammes, une seule partie (ex. Apple) détient la clé secrète nécessaire pour produire des images logicielles valides que les appareils et leurs systèmes de mise à jour de logiciels acceptent. Tout système de mise à jour bien conçu refuse d'accepter une image logicielle à moins qu'elle n'ait été authentifiée à l'aide d'un certificat numérique intégré dans le dispositif, qui identifie cryptographiquement le fabricant du logiciel par une suite mathématique, avec la clé de signature secrète. Les bonnes pratiques en matière de signature logicielle consistent déjà à garder les clés de signature particulièrement sensibles hors ligne, peut-être dans les HSM (module matériel de sécurité), ou même à les répartir sur plusieurs de ces modules, comme le fait l'ICANN dans son rituel de signature des clés DNSSEC. Mais, comme nous l'avons déjà mentionné, de telles mesures n'empêchent pas la société d'être forcée de faire un usage abusif secret de ces clés de signature.

Avec la cosignature décentralisée des témoins, un fabricant de logiciels imprime sur ses appareils et ses systèmes de mise à jour logicielle un certificat numérique correspondant non seulement à sa propre clé secrète, mais aussi aux clés secrètes détenues par un groupe de témoins indépendants. Ces témoins peuvent être d'autres sociétés de logiciels partenaires, des organisations d'intérêt public telles que l'ACLU, l'EFF ou le CDT, de grandes entreprises clientes, ou des gouvernements du monde entier désireux d'obtenir non seulement des garanties verbales, mais aussi technologiques, de l'engagement du fabricant du logiciel envers la transparence. En retour, avant d'accepter toute image logicielle, le système de mise à jour de l'appareil vérifie qu'elle a été signée non seulement par le fabricant du logiciel, mais aussi par un nombre de témoins désignés. En fait, l'appareil n'accepte aucune image logicielle à moins qu'il n'arrive avec une « preuve » cryptographique que cette image logicielle a été vérifiée par - et donc placée sous la surveillance d'un groupe décentralisé de parties indépendantes dispersées à travers le monde dans différentes juridictions.

L'extensibilité de la cosignature des témoins

Techniquement, il est assez facile de mettre en œuvre la cosignature de témoins si le nombre de témoins est faible. Un fabricant de logiciels pourrait simplement rassembler une liste de signatures individuelles pour chaque nouvelle version de logiciel, de la même manière que les gens traitent les pétitions depuis des centaines d'années. Toutefois, si nous voulons que le groupe de témoins soit nombreux - et c'est ce que nous faisons, pour garantir que compromettre la transparence n'exige pas seulement une collusion malveillante de quelques témoins, mais de centaines, voire de milliers de témoins - alors la collecte de centaines ou de milliers de signatures pour chaque version du logiciel pourrait devenir pénible et inefficace. Pire encore, tout appareil devant valider un téléchargement ou une mise à jour de logiciel devrait vérifier toutes ces signatures individuellement, ce qui causerait des retards et consommerait l’énergie de la batterie.

La principale contribution technique de nos recherches est un protocole distribué qui automatise ce processus et rend pratiques les grands groupes décentralisés de cosignataires témoins. Je vais vous épargner les détails, mais ceux qui sont intéressés peuvent les trouver ici. Le résumé simplifié à l'extrême est que le protocole consiste à comprimer des centaines ou des milliers de signatures en une seule qui peut être vérifiée presque aussi simplement et efficacement que la vérification d'une signature individuelle normale. À titre d'exemple, une pétition traditionnelle à signatures multiples traitée de cette façon pourrait ressembler à ce qui suit :

SHAPE\* MERGEFORMAT

A quoi une pétition classique pourrait ressembler en tant que multisignature cryptographique

La superposition de signatures papier n'offrirait bien sûr que peu ou pas de sécurité, mais une telle superposition peut être sécurisée par des signatures numériques modernes. C'est l'une des propriétés remarquables de la cryptographie moderne et c'est une propriété bien comprise, bien plus ancienne que nos travaux. Encore une fois, notre principale contribution est de généraliser la cosignature des témoins.

Comment savoir s’il existe une porte dérobée ?

Malheureusement, les témoins indépendants ne peuvent pas nécessairement déterminer immédiatement, pendant le processus de cosignature des témoins, si une image logicielle particulière contient ou non une porte dérobée. C'est particulièrement vrai dans le cas où le code source est propriétaire et où le fabricant du logiciel ne signe et ne publie que des images binaires. Néanmoins, les témoins peuvent toujours assurer la transparence de façon proactive en s'assurant que chaque image logicielle correctement signée qui existe a été divulguée, cataloguée et soumise à l'examen du public.

Par exemple, si les prochains appareils Apple adoptent la cosignature décentralisée des témoins et qu'un gouvernement tente secrètement de contraindre Apple à signer une version avec porte dérobée de la version 11.2.1 d’iOS, la seule façon pour Apple de le faire serait de soumettre cette version d’iOS aux témoins indépendants pour cosignature. Même si ces témoins ne pourraient pas nécessairement reconnaître la porte dérobée, ils pourraient immédiatement remarquer que deux images d’iOS différentes intitulées « version 11.2.1 » ont été signées : la version standard et la version avec porte dérobée. À elle seule, cette incohérence déclencherait immédiatement des alarmes et attirer l'attention des entreprises de sécurité du monde entier, qui pourraient examiner attentivement les différences entre les deux images logicielles.

Un gouvernement pourrait bien sûr contraindre Apple à donner à l'image de fond un numéro de version différent que la plupart de ses clients ne reçoivent jamais : par exemple, « 11.2.1fbi » - ou un « 11.2.1.1.1 » plus discret. Toutefois, les témoins seraient toujours en mesure de dire qu'il existe une image de l'iOS qui a été signée mais qui n'a pas été largement diffusée, ce qui, là encore, susciterait probablement des soupçons et un examen minutieux par des experts en sécurité.

Bien sûr, Apple - ou un employé malveillant d'Apple - pourrait encore glisser un « bug » discret de porte dérobée ou de sécurité dans les versions d’iOS standard que tout le monde utilise. Les bugs accidentels et les portes dérobées peuvent persister pendant des années sans qu'on s'en aperçoive, comme le démontre amplement l’incident Juniper. Les logiciels open source offrent un avantage en termes de transparence, en particulier avec des versions reproductibles, mais même les portes dérobées au niveau des sources peuvent s'avérer extrêmement délicates.

Néanmoins, les techniques et les outils d'analyse des logiciels sources et binaires ne cessent de s'améliorer et la cosignature décentralisée des témoins peut garantir que toutes les versions soient connues du public et exposées à cette analyse par de talentueux chercheurs en sécurité et des hackers du monde entier. Un hacker qui glisse une porte dérobée dans une version publique d'un logiciel est intrinsèquement exposé au risque que la porte dérobée puisse être découverte à tout moment. La cosignature par un témoin empêche les hackers de contourner ce risque de découverte, même en déployant secrètement le logiciel piraté uniquement sur des dispositifs ciblés dans des conditions contrôlées par le hacker.

Approches proactive ou rétroactive en matière de transparence

La cosignature décentralisée des témoins n'est en aucun cas le premier mécanisme de transparence cryptographique. Par exemple, l'infrastructure à clé publique (ICP) utilisée pour sécuriser les connexions Web présente des faiblesses similaires. Les mécanismes de transparence de l'ICP tels que la convergence, la transparence des certificats, l’AKI et l’ARPKI permettent de résoudre ce problème. La transparence des certificats est désormais une norme standard dans le navigateur Chrome. La transparence des applications est une variante offerte de la transparence des certificats adaptée aux téléchargements et aux mises à jour de logiciels. Des propositions connexes telles que Perspectives et CONIKS traitent des problèmes étroitement liés aux connexions Secure Shell (SSH) et à la messagerie cryptée de bout en bout, respectivement.

Ces mécanismes de transparence préalable présentent toutefois deux faiblesses cruciales : ils n'augmentent pas de manière significative le nombre de clés secrètes qu'un hacker doit contrôler pour compromettre un dispositif personnel, et les dispositifs personnels ne peuvent même pas détecter rétroactivement un tel piratage à moins de pouvoir communiquer activement avec plusieurs serveurs Internet connus. Par exemple, même avec la transparence des certificats, un hacker peut falsifier un certificat Extended Validation (EV) pour Chrome après avoir compromis ou contraint seulement trois parties : une autorité de certification (CA) et deux serveurs de logs. Étant donné que de nombreux CA et serveurs de logs sont sous juridiction américaine, une telle attaque est clairement à la portée du gouvernement américain. Si une telle attaque se produit, la transparence des certificats ne peut la détecter que si l'appareil victime a la possibilité de communiquer sur le faux certificat avec d'autres parties sur Internet - après avoir déjà accepté et commencé à utiliser le faux certificat numérique.

Les mécanismes de communication ne peuvent pas garantir la transparence du logiciel

Ces faiblesses sont particulièrement graves dans le domaine de la transparence des logiciels, question centrale dans l'affaire qui a opposé Apple au FBI. Tout d'abord, si un appareil personnel accepte et commence à exécuter une mise à jour logicielle piratée avant que l'appareil n'ait eu la possibilité d'échanger des informations sur la mise à jour avec d'autres parties sur Internet, alors le logiciel piraté peut échapper à la transparence en désactivant simplement les communications dans le code actualisé. Deuxièmement, même si, pour une raison quelconque, le hacker ne peut ou ne veut pas prendre cette mesure évidente, il peut toujours échapper à la transparence en contrôlant soit l'appareil, soit ses chemins d'accès à Internet. Dans l'affaire FBI contre Apple, par exemple, le FBI pourrait trivialement se soustraire à la transparence basée sur les communications et garder secrète son image d’iOS en arrière-plan, en gardant l'appareil déconnecté du reste de Internet après avoir installé sa mise à jour logicielle en arrière-plan. (Ils avaient probablement l'intention de le faire de toute façon, pour s'assurer qu'aucun « cyber-pathogène » ne s'échappe.

Cette faiblesse de la transparence basée sur les communications s'applique également aux hackers qui peuvent ne pas contrôler l’appareil lui-même mais contrôler l'accès à Internet de l’appareil. Par exemple, un fournisseur d’accès à Internet ou un portail Internet d'entreprise compromis peut nuire à la transparence fondée sur les communications en bloquant constamment l'accès d'une victime aux serveurs de transparence ailleurs sur Internet. Même si l'appareil de l'utilisateur est mobile, un service de renseignements gouvernemental tel que le « Great Firewall » chinois pourrait vaincre la transparence basée sur les communications en bloquant constamment les connexions des appareils d'une victime ciblée aux serveurs de transparence globale, de la même manière que la Chine bloque déjà les connexions à de nombreux sites Web et au réseau anonyme Tor.

Conclusion

L’affaire entre Apple et le FBI n'est que la partie émergée de l’iceberg de l'intégrité des logiciels, illustrant à la fois l'importance des mécanismes de transparence des logiciels et les défis techniques pour les sécuriser. Les méthodes actuelles basées sur les communications ne peuvent pas réellement garantir la transparence si un hacker contrôle l’appareil cible ou son chemin d'accès à Internet, comme dans le scénario FBI contre Apple. Même si les mises à jour logicielles étaient protégées par la transparence des certificats ou la transparence des applications, le FBI pourrait quand même forcer secrètement Apple à signer une mise à jour logicielle avec portes dérobées, contraindre deux serveurs de logs basés aux États-Unis à signer de fausses entrées de logs tout en gardant secrets la mise à jour logicielle et les faux logs, et isoler l’appareil cible hors ligne afin de ne pouvoir communiquer les métadonnées des fausses mises à jour avec personne.

La cosignature décentralisée des témoins est actuellement la seule méthode connue pour assurer la transparence et la responsabilité publique dans de telles situations. En adoptant une approche proactive, la cosignature de témoins fournit aux appareils la preuve cryptographique autonome qu'une mise à jour logicielle a été vérifiée par de nombreuses parties indépendantes, avant que l’appareil n’accepte ou n’exécute le logiciel. De cette façon, des entreprises comme Apple pourraient offrir à leurs clients une forte garantie que toutes les images logicielles valides existantes ont été vérifiées publiquement avant qu'aucun de leurs appareils, où que ce soit, ne les considère comme valides - même si l'appareil et/ou son réseau est contrôlé par un hacker aussi secret que le FBI.

Le débat public actuel sur les portes dérobées dans les appareils personnels est d'une importance cruciale pour notre sécurité, notre vie privée et notre liberté individuelle. Mais il est tout aussi important de veiller à ce que le débat reste public, cette fois-ci.