Catégorie : Sécurité

  • Sécurité dans les labos, l’équation impossible ?

    Jean-Marc Jézéquel est directeur de l’IRISA, l’un des plus grands laboratoires publics de recherche en informatique de France, depuis 6 ans. Il a récemment publié une lettre ouverte critiquant les dispositifs actuels de protection des recherches des laboratoires publics, dont les travaux, qu’ils soient financés par l’État ou par des entreprises, peuvent avoir un intérêt économique ou stratégique. A cette occasion, il confie à Binaire ses inquiétudes sur le sujet. Charlotte Truchet

    Binaire : Vous êtes directeur d’un grand laboratoire d’informatique. Dans quels domaines vos équipes développent-elles des travaux que vous considérez comme sensibles ?

    Jean-Marc Jézéquel, directeur de l’IRISA à Rennes. Crédits : UR1/Dircom/Cyril Gabbero

    Il est difficile de le dire : à la fois aucun, et tous ! Le principe général, quand on fait de la recherche, est qu’on ne sait pas à l’avance ce qui va déboucher et ce qui n’aboutira pas. On peut très bien travailler sur un sujet pas spécialement secret, et obtenir des résultats sensibles que l’on n’avait pas prévus au départ. Dans le cas de l’IRISA, un très gros laboratoire dont les thématiques couvrent tous les champs de l’informatique jusqu’à l’image ou la robotique, identifier les risques est une mission impossible.

    Il y a un exemple célèbre : la technologie des processeurs ARM, qui équipent la vaste majorité des téléphones mobiles dans le monde. Autant dire, un succès industriel d’une ampleur peu commune, une technologie (européenne d’ailleurs) qui vaut des milliards. Le point fort de ces processeurs est d’être très peu consommateurs en énergie. Et pourtant, ce n’est pas du tout dans ce but qu’ils ont été initialement conçus ! Le futur inventeur des ARMs travaillait sur tout autre chose, il avait simplement besoin de processeurs pour ses travaux. Intel ayant refusé de lui en fournir, il a conçu un processeur qu’il voulait le plus simple possible. Ce n’est qu’au moment de tester ces nouveaux processeurs qu’on a constaté qu’ils consommaient très peu d’énergie. Voilà un exemple, entre mille, de technologie ultra sensible, pas du tout imaginée comme telle. Bref, dans un laboratoire, il faut être prêt à tout.

    B : Quels sont les risques qui vous inquiètent le plus ?

    On pense facilement au piratage informatique, mais en réalité, ce qui me semble le plus délicat est le pillage des cerveaux. C’est particulièrement vrai pour un laboratoire d’informatique. Dans notre cas, ce qui compte, ce sont les idées. Les artefacts que sont les logiciels, articles ou brevets n’ont pas une si grande importance. Les logiciels conçus par nos chercheuses et chercheurs sont souvent open source, c’est-à-dire que leur code est accessible en clair sur internet. Rien de plus facile que de les récupérer : il suffit de copier coller ! Le concept de vol pour un logiciel open source est donc tout-à-fait singulier.

    S’en servir intelligemment est en revanche une toute autre affaire, qui peut requérir un très fort investissement. La difficulté est de modifier le code pour lui faire faire ce que l’ont veut. Pour cela, il faut en pratique avoir sous la main les gens qui ont conçu le logiciel.

    B : Ce pillage des cerveaux, vous l’estimez de quelle ampleur dans le cas de l’IRISA ?

    By Jens Maus – Own work, Public Domain

    Nous avons environ 850 membres du laboratoire, dont 350 doctorants et post-doctorants. Chaque année, les départs représentent 1 à 3 fonctionnaires et environ 200 contractuels (ingénieurs, post-doctorants et doctorants). Certains sont embauchés dans des multinationales de l’informatique comme Google ou Facebook ; c’est à la fois une reconnaissance de la qualité de nos personnels, et une frustration.

    Il y a là une vraie difficulté. Naturellement, parce que c’est bien une des voies privilégiées du transfert de la recherche vers la société, nos anciens doctorants et post-docs vont irriguer d’autres labos en France ou à l’étranger, ou le monde économique. Tout à fait légalement, une entreprise ou une agence non européenne peut donc recruter ces experts de haut niveau, et achètent en réalité leurs compétences.

    B : Peut-on aussi voler les idées, sans même embaucher le cerveau qui les a eues ou développées ?

    Oui, c’est possible. La recherche se fait de nos jours sous une forme contractuelle et compétitive. Les chercheurs doivent soumettre leurs meilleurs projets de recherche, donc des idées pas encore développées, à des jurys souvent internationaux. Cela représente un problème potentiel : on peut imaginer que sur des sujets de recherche appliqués à la défense par exemple, certains membres de ces jurys internationaux ne soient pas totalement neutres.

    Et sans même aller jusque là, le principe reste de donner ses meilleures idées à des équipes concurrentes. Il y a bien sûr des règles de déontologie. Malgré tout, les membres du jury ont accès au projet. S’ils sont malhonnêtes, ils peuvent assez facilement démolir le projet et s’en approprier les idées. Même s’ils sont honnêtes, dans la mesure où ils sont du même domaine, ils repartent forcément influencés par les projets auxquels ils ont eu accès : on ne peut pas oublier des idées ! Parfois, on peut identifier des cas litigieux, mais souvent on ne le voit même pas.

    B : Alors finalement, le piratage informatique n’est pas le souci d’un laboratoire d’informatique ?

    Fortifications est, Belfort.
    CC BY-SA 2.0 fr

    Pas tant que ça. Il y a parfois des tentatives d’intrusions sur nos systèmes, mais peu réussissent – d’ailleurs, même quand elles réussissent, elles ne touchent que des choses périphériques, un site web défiguré par exemple : les dégâts sont franchement anecdotiques. Nous avons quelques cas chaque année. En quelques dizaines d’années, nous n’avons jamais eu d’intrusion directe de notre réseau, jamais. Nous avons des équipes compétentes, très vigilantes sur ce sujet.

    Dans une autre catégorie, nous avons aussi chaque année une dizaine de cas de vols d’ordinateurs, souvent dans une gare ou un train, ce qui fait penser que ces vols ne sont pas forcément ciblés. Malgré tout, quand ces ordinateurs contiennent des données sensibles du laboratoire, il est important que celles-ci aient été chiffrées !

    B : Vous hébergez des données particulièrement sensibles ? Comment les protégez-vous ?

    Nous avons quelques bases de données sensibles, oui : par exemple, une base de données de virus informatiques particulièrement virulents. Nous les protégeons avec des procédures spéciales, mais je ne vais pas vous les décrire ! Nos partenaires comprennent qu’ils peuvent nous faire confiance.

    B : Dans votre lettre, vous protestez contre les dispositifs de protection des recherches dans les laboratoires publics. Pourquoi les estimez-vous inadaptés ?

    Plan des fortifications du Château de Dijon.
    By Arnaud 25 – Own work, CC BY-SA 3.0

    D’abord, elles reposent sur une échelle de dangers, déclinée en fonction des risques économiques, en matière de défense ou de terrorisme. Mais comme je vous disais, il est extrêmement difficile de caractériser objectivement le niveau de risque d’une recherche donnée à un moment donné.

    En outre, les protections mises en place sont complètement inadaptées au fonctionnement d’un laboratoire moderne. Si je m’en tenais aux dispositifs de protection recommandés, nous pourrions quasiment laisser notre base de virus en clair sur le réseau, à condition de mettre une étiquette sur la porte de la salle du serveur ! C’est totalement inadapté.

    Par ailleurs, ces dispositifs induisent des contraintes qui grèvent notre fonctionnement. Un exemple très concret : lorsque nous recrutons quelqu’un, son dossier doit être approuvé par un fonctionnaire extérieur au laboratoire. Cela ajoute un délai pouvant aller jusqu’à deux mois à toute embauche. Or, le marché de l’emploi scientifique est très tendu, en particulier dans le domaine de l’informatique. Les candidats attendent une réponse ferme et rapide, faute de quoi ils vont voir ailleurs. A cause de ces délais imprévisibles, nous ne pouvons jamais nous engager directement auprès des candidats et nous perdons d’excellentes candidatures.

    Dans un labo d’informatique, le besoin de protection est très spécifique, car notre objet de recherche est numérique, donc immatériel. On comprend bien que des mesures de protection calibrées sur l’idée d’une usine d’explosifs ne s’appliquent pas directement.

    B : Mais est-ce que vous n’auriez pas protesté, quel que soit le dispositif de protection mis en place ?

    Il y a une contradiction intrinsèque à vouloir protéger des travaux de recherche, c’est certain. La recherche fonctionne par échanges. Les idées émergent toujours entre les personnes, si possible venant d’horizons différents. Les cerveaux géniaux ne sont d’ailleurs ni nécessaires ni suffisants – l’échange des idées l’est. La liberté de mouvement est donc constitutive de la recherche. Mais nous ne vivons pas dans un monde de bisounours ! Nous sommes bien conscients d’avoir besoin de protection, d’ailleurs, nous avons de nous-mêmes pris des mesures en ce sens. Simplement, les dispositifs qui nous sont imposés par l’État ne sont pas adaptés dans leur forme actuelle. Non seulement ils ne nous protègent pas réellement comme il le faudrait, mais ils nous empêchent de fonctionner efficacement dans le monde extrêmement compétitif de la recherche internationale. Ce serait pour les laboratoires français comme d’essayer de courir le 100m avec un boulet face à des concurrents internationaux sans entrave.

  • À la recherche du logiciel parfait

    Le Collège de France accueille la nouvelle chaire « Sciences du logiciel » avec Xavier Leroy, Directeur de recherche chez Inria. Xavier Leroy est un spécialiste des nouveaux langages et outils de programmation, ainsi que de la vérification formelle de logiciels critiques afin de garantir leur sûreté et leur sécurité. Une des réalisations de Xavier Leroy et de son équipe est le compilateur CompCert qui possède une preuve mathématique de bon fonctionnement.  C’est un véritable tour de force qu’il était même difficile à imaginer avant qu’ils ne le réalisent. La leçon inaugurale aura lieu le 15 novembre à 18:00. Je ne peux que vous encourager à y assister et à podcaster les autres leçons d’informatique sur le site du collège. Serge Abiteboul
    Xavier Leroy © Inria / Photo G. Scagnelli

    Le logiciel, entre l’esprit et la matière

    C’est une évidence, l’informatique est aujourd’hui partout : au bureau, à la maison, dans nos téléphones ; au cœur des réseaux de communication, de distribution, d’échanges financiers ; mais aussi, de manière plus discrète car enfouie dans les objets du quotidien, dans les véhicules, les cartes de paiement, les équipements médicaux, les appareils photo, les téléviseurs, l’électroménager et jusqu’aux ampoules électriques, qui elles aussi deviennent « connectées » et « intelligentes ».

    Grace Hopper en contribuant à la création de compilateurs qui traduisent le logiciel en langage machine a permis l’explosion du logiciel. ©wikicommon

    Cette explosion de l’informatique doit beaucoup aux immenses progrès de la micro-électronique, qui débouche sur la production en masse d’ordinateurs et de systèmes sur puce toujours plus puissants à coût constant, mais aussi à l’incroyable flexibilité du logiciel qui s’exécute sur ces systèmes. Reprogrammable à l’infini, duplicable à coût zéro, libéré de presque toute contrainte physique, le logiciel peut atteindre une complexité hallucinante. Un navigateur Web représente environ 10 millions de lignes de code ; le logiciel embarqué dans une voiture moderne, 100 millions ; l’ensemble des services Internet de Google, 2 milliards.  Qu’un assemblage de 2 milliards de choses toutes différentes, conçues par des milliers  de personnes, fonctionne à peu près, est sans précédent dans l’histoire de la technologie.

    Revers de cette flexibilité, le logiciel est aussi extrêmement vulnérable aux erreurs de programmation : les bugs tant redoutés et leur cortège de comportements étranges, de plantages occasionnels, et de mises à jour incessantes. Les failles de sécurité produisent des dégâts considérables, de la demande de rançon à la fuite massive d’informations personnelles. Les libertés fondamentales sont menacées par la généralisation de la surveillance informatique et la manipulation d’élections.

    Sur ces problématiques, les sciences du logiciel apportent un regard objectif, rigoureux, et fondé autant que possible sur les mathématiques. Quels algorithmes utiliser ? Comment garantir qu’ils sont corrects et efficaces ? Comment les combiner sous forme de programmes ? Dans quels langages exprimer le programme ? Comment compiler ou interpréter ces langages pour les rendre exécutables par la machine ? Se prémunir contre les erreurs de programmation ? Vérifier que le programme final est conforme aux attentes ? Qu’il n’a pas de comportements indésirables menant à une faille de sécurité ? Voilà des questions élémentaires, qui se posent à tout développement logiciel, et auxquelles les sciences du logiciel cherchent à apporter des éléments de réponse mathématiquement rigoureux, de l’analyse d’algorithmes à la sémantique des langages de programmation, des spécifications formelles à la vérification des programmes.

    Concevoir des logiciels corrects

    Les sciences du logiciel nous enseignent qu’un fois donnée une sémantique aux langages de programmation utilisés, tout programme correspond à une définition mathématique : on peut raisonner sur le comportement du programme en démontrant des théorèmes à partir de cette définition ; on peut aussi s’efforcer de synthétiser un programme « correct par construction » à partir des propriétés qu’il doit vérifier. Voilà qui peut surprendre tant ces approches, connues sous le nom de « méthodes formelles », diffèrent de l’approche expérimentale utilisée le plus souvent : on écrit d’abord le programme puis on le teste longuement pour le valider.

    Un environnement générique de preuve de programmes permettant d’engendrer des obligations de preuves pouvant être ensuite déléguées à des démonstrateurs automatiques ou interactifs. Sur cet outil sont construits des environnements dédiés pour prouver des programmes C et Java annotés par des formules décrivant le comportement attendu. © Inria / Photo C. Lebedinsky

    Bien qu’efficace pour le logiciel ordinaire, le test devient extrêmement coûteux pour des logiciels complexes avec de hauts niveaux d’exigence de qualité. Le test ne parvient plus à montrer l’absence de bugs. Les méthodes formelles ne souffrent pas de ces limitations et dessinent un chemin vers le logiciel zéro défaut. Cependant, elles sont longtemps restées à l’état de curiosités académiques, tant les objets mathématiques correspondant à un programme réaliste sont énormes (bien loin des tailles des preuves que des humains savent maîtriser) et difficiles à manier. Il a fallu développer des outils de vérification formelle qui automatisent une grande partie des raisonnements pour permettre les premières utilisations systématiques de méthodes formelles pour des logiciels critiques, dans le ferroviaire, l’avionique, et le nucléaire. C’est un des résultats les plus spectaculaires et importants de la science informatique des 20 dernières années. Ma contribution à cet édifice est d’étendre la vérification formelle du logiciel critique lui-même aux outils informatiques, tels que les compilateurs, générateurs de code, ou analyseurs statiques, qui participent à sa production et sa vérification. Il s’agit de vérifier, donc de solidifier, le socle sur lequel sont bâtis ces logiciels critiques.

    Après ces premiers succès de la vérification formelle, beaucoup reste à faire pour étendre ses utilisations. Il faut mieux prendre en compte les impératifs de sécurité, le parallélisme massif des nouvelles machines, la distribution des applications. Au centre de l’intelligence artificielle d’aujourd’hui, les techniques d’apprentissage statistique produisent des logiciels qui ne sont plus complètement écrits mais en partie appris à partir d’exemples, nécessitant de nouvelles approches de vérification formelle. Beaucoup de travaux de recherche en perspective, mais nous n’avons pas le choix : il nous faut, avec la rigueur des mathématiques et la puissance des outils informatiques, apprendre à maîtriser le logiciel dans toute sa complexité.

    Xavier Leroy, Professeur au Collège de France

    Cours 2018-2019 : Programmer = démontrer ? La correspondance de Curry-Howard aujourd’hui

    L’isomorphisme Curry-Howard permet d’établir des ponts entre le « niveau logique » et le « niveau algorithmique » du langage informatique. ©aromaths.wordpress.com

    Informatique et logique mathématique sont historiquement liées : Alan Turing, John von Neumann, Alonzo Church et bien d’autres fondateurs de l’informatique étaient logiciens, professionnels ou de formation. Le cours 2018-2019 de la chaire de Sciences du logiciel étudie un autre lien, de nature mathématique celui-là (il s’agit d’un isomorphisme), entre langages de programmation et logiques mathématiques. Dans cette approche, démontrer un théorème, c’est la même chose que d’écrire un programme ; énoncer le théorème, c’est la même chose que de spécifier partiellement un programme en donnant le type qu’il doit avoir.

    http://coq.inria.fr un assistant de preuve de programme.

    Cette correspondance entre démonstration et programmation a d’abord été observée dans un cas très simple par deux logiciens : Haskell Curry en 1958 puis William Howard en 1969. Le résultat semblait tellement anecdotique qu’Howard ne l’a jamais soumis à une revue, se contentant de faire circuler des photocopies de ses notes manuscrites. Rarement photocopie a eu un tel impact scientifique, tant cette correspondance de Curry-Howard est entrée en résonance avec le renouveau de la logique et l’explosion de l’informatique théorique des années 1970 pour s’imposer dès 1980 comme un lien structurel profond entre langages et logiques, entre programmation et démonstration. Aujourd’hui, il est naturel de se demander quelle est la signification «logique» de tel ou tel trait de langages de programmation, ou encore quel est le «contenu calculatoire» de tel ou tel théorème mathématique (c’est-à-dire, quels algorithmes se cachent dans ses démonstrations ?). Plus important encore, la correspondance de Curry-Howard a débouché sur des outils informatiques comme Coq et Agda qui sont en même temps des langages de programmation et des logiques mathématiques, et s’utilisent aussi bien pour écrire et vérifier des programmes que pour énoncer et aider à démontrer des théories mathématiques.

    Le cours retracera ce bouillonnement d’idées à la frontière entre logique et informatique, et mettra l’accent sur les résultats récents et les problèmes ouverts dans ce domaine. Le séminaire donnera la parole à 7 experts du domaine pour des approfondissements et des points de vue complémentaires.

     

     

  • Vers une cybersécurité européenne pour les PME ?

    Il n’y a plus de jours où nous n’apprenons l’existence d’une cyberattaque touchant une entreprise (et il ne s’agit que de la partie émergée de l’iceberg). Données volées, comptes détournés sont devenues leur quotidien. Face à ce problème devenu crucial, il n’existe pas de réponse unique et de nombreuses actions sont mises en oeuvre : depuis les scientifiques qui analysent les attaques et imaginent de nouvelles parades jusqu’aux structures comme l’ANSSI chargées de lutter contre la cybercriminalité en passant par les ingénieur·e·s chargé·e·s de protéger les systèmes informatiques de leur entreprise. Moins informées, sans doute moins « équipées » que les grandes structures, les PME sont pourtant elles aussi touchées. Dans cet article, Jérôme Tarting revient sur une décision récente du Conseil européen qui les concerne directement. Pascal Guitton

    L’apparition des outils informatiques (mobiles, réseaux, réseaux sociaux, Cloud…) ont fait entrer les PME dans un écosystème numérique. La convergence de toutes ces nouvelles technologies les place désormais à un carrefour névralgique où transitent les données des clients, des partenaires, des fournisseurs, des salariés et des citoyens.

    Toute structure économique est donc devenue pourvoyeuse d’informations en quantité importante, d’où les réglementations qui ont pu surgir, le fameux RGPD entré en vigueur en mai 2018 étant la dernière en date. L’adage “Qui a l’information a le pouvoir” explique en grande partie les cyberattaques dont les PME sont victimes en France. Pourquoi sont-elles aussi vulnérables ? Jusqu’à très récemment, l’usage du numérique par les entreprises venait classer notre pays légèrement en-deçà de la moyenne européenne, loin derrière la Finlande ou l’Allemagne[1].

    En 2013, seuls 2 salariés sur 3 utilisaient un ordinateur et dans les 5 dernières années, 62% des actifs ont suivi une formation continue en informatique pour combler leurs lacunes[2]. Dans cette marche en avant, les PME ont rattrapé leur retard, sans pour autant tenir compte du niveau de sécurité qui a évolué très vite, et qui est désormais ATAWAD : Anytime, Anywhere, Any Device.

    L’entreprise ne doit plus se contenter de multiplier les outils numériques et les usages, son rôle est maintenant de savoir où sont ses données, d’être en mesure de les protéger, de se protéger elle-même tant contre les cyberattaques qu’en matière de  responsabilité si ses données venaient à être dérobées.

    La France, pays le plus visé

    Analyse de malware ou ransomware. © Inria / Photo C. Morel

    À qui s’attaquent les hackers ? La finance, le commerce, l’énergie et l’industrie du numérique sont les secteurs les plus touchés. Dans les deux dernières années, une société sur deux a été victime d’une attaque informatique. Les violations ont augmenté de 62% en 5 ans[3]. ¼ des attaques provenait de logiciels malveillants, une autre partie du web. 12% en interne. Et 10% par phishing.
    Au total, toutes ces malveillances ont coûté plus de 6 milliards aux entreprises françaises[4]. Enfin, notons que si les chiffres ne sont pas réellement connus, le secteur public connaît lui aussi de nombreuses malveillances.

    Solution européenne ?

    Différents aspects de l’Internet des objets.  © Wikipédia

    Un récent rapport remis aux institutions européennes a démontré l’utilité d’une lutte efficace contre la malveillance numérique, représentant 400 milliards d’euros par an à l’échelle de l’économie mondiale. L’Union, consciente que “l’internet des objets” comptera, d’ici 2020, des dizaines de milliards de dispositifs numériques, a pris le dossier très au sérieux. En effet, elle a estimé que nombreuses sont les entreprises et les administrations au sein de l’UE dont les principaux services dépendent des réseaux et des infrastructures informatiques. Les incidents concernant la sécurité des réseaux et de l’information (SRI traitée notamment par l’ENISA en Europe) peuvent avoir un impact considérable, empêchant leur fonctionnement. En outre, un incident SRI dans un pays peut se répercuter dans d’autres, voire dans l’ensemble de l’UE, sapant la confiance des consommateurs dans les systèmes de paiement en ligne et les réseaux informatiques. C’est pourquoi, le 8 juin 2018, le Conseil européen a décidé de s’attaquer aux menaces en demandant aux états membres d’identifier les acteurs essentiels en matière de SRI avant décembre 2018, d’aider les petites et moyennes entreprises à être compétitives dans l’économie numérique et à investir dans le recours à l’intelligence artificielle et aux super-ordinateurs [5].

    Agir au plus vite

    Présentation sur la cybersécurité lors de la fête de la science à un large public. © Photographie Clotilde Verdenal / LoeilCreatif (pour Inria)

    Bien entendu, si la Directive SRI est contraignante pour la France en termes de transposition et de moyens, les hackers ne vont pas s’arrêter si facilement car les données sont devenues pour eux la principale source de revenus de « l’économie malveillante ». Il est urgent d’apporter une réponse pénale plus efficace face à la cybercriminalité contre la fraude, le vol des données, la contrefaçon des moyens de paiement. Il faut donc conseiller à nos PME françaises de bâtir une cybersécurité sur des fondements solides, en misant sur le renseignement et la gestion avancée des accès, les encourager à effectuer des tests de résistance qui permettront d’identifier les champs de leur vulnérabilité, les accompagner et les encourager à investir dans les innovations de rupture (analyse et intelligence artificielle). Il en va de la pertinence du marché unique numérique mais aussi de la crédibilité de la France, qui si elle veut réellement être une start-up nation, ne peut négliger plus longtemps cette faille dangereuse pour le devenir de sa nouvelle économie.

    Jérôme Tarting (fondateur du Groupe Up’n BIZ)

    [1] Observatoire du numérique – janvier 2016.
    [2] Baromètre du numérique 2017
    [3] Enquête 2017  Accenture.
    [4] France 2 – Enquête sur les cyberattaques.
    [5] Conseil de l’europe – Réforme de la cybersécurité en Europe – Juillet 2018

  • Nouvelles mises à jour disponibles

    Régulièrement, nous sommes informé.e.s des mises à jour que nous devons apporter à nos ordinateurs. Principal support des correctifs aux failles de sécurité apportés par les éditeurs de logiciels, leur utilité n’est pas discutable. Cependant, selon l’environnement de notre machine, leur mise en œuvre n’est pas toujours simple . Dans cet article, Charles Cuveliez et Jean-Jacques Quisquater nous apportent un éclairage sur ce sujet important en passant en revue les différents équipements concernés : les systèmes d’exploitations, les machines virtuelles, les téléphones portables, les micro-processeurs et enfin, plus complexe encore, l’arrivée de l’internet des objets qui pose des questions sans véritable réponse à ce jour. Pascal Guitton

    On le sait, un des meilleurs moyens de se prémunir contre les cyberattaques est de mettre à jour sa machine, le plus vite possible, PC, laptop ou smartphone. Mais a-t-on déjà songé à la complexité du mécanisme de mise à jour pour le fabricant ou pour le concepteur du système d’exploitation ou du logiciel ? Il doit y veiller au niveau mondial et pour des centaines de millions d’utilisateurs. Dans le cas de systèmes d’exploitation très utilisés, la mise à jour, suite à un bug ou une vulnérabilité, doit parfois couvrir l’ensemble des versions, qui ont été produites avec cette vulnérabilité. Que faut-il faire ? Privilégier la version la plus récente et ainsi protéger la grande majorité des clients (mais en rendant vulnérables les utilisateurs de versions antérieures) ou attendre que la correction soit prête pour toutes les versions (un délai supplémentaire mis à profit par les hackers) ?

    Puis se pose la question de savoir qui est responsable pour faire la mise à jour ? L’utilisateur final ? Le fabricant ? C’est là que la lecture des conditions imprimées en petits caractères du contrat de licence, que seuls des gens payés pour le faire lisent (en général quand il est trop tard), importe. Les mises à jour ne concernent pas que les systèmes d’exploitation mais aussi les logiciels, des appareils électroniques….

    Les systèmes propriétaires : Windows 10

    © wikicommons

    C’est Microsoft qui le premier n’a plus laissé le choix aux utilisateurs sur les mises à jour à installer. Désormais avec Windows 10, l’utilisateur reçoit un paquet de mise à jour que l’utilisateur doit installer dans sa globalité. C’était indispensable : les mises à jour sont conçues en partant de l’hypothèse que le PC sur lequel elles seront installées est déjà protégé des vulnérabilités précédentes ! Il y a les mises à jour qui résolvent des problèmes de sécurité et, de façon séparée, celles qui apportent de nouvelles fonctionnalités. Ces dernières sont optionnelles car elles peuvent créer des instabilités ou même des vulnérabilités dans d’autres logiciels installés sur la machine.

    Les utilisateurs peuvent d’ailleurs décider, avec Windows 10, de  rester avec les mêmes fonctionnalités pendant 10 ans, le temps de support garanti des OS. Ceci dit, on l’a vu avec Windows XP ou avec Windows Server 2003 : ces 10 ans sont rarement suffisants. Les demandes d’extension restent fréquentes.

    Ce n’est pas tout de déployer et distribuer la mise à jour. Encore faut-il s’assurer que la mise à jour est installée, ce qui peut prendre du temps, par exemple pour des machines sur lesquelles Windows et un autre système d’exploitation fonctionnent simultanément.

    Les logiciels open source : Linux

    © Larry Ewing

    Les logiciels open source ne sont pas moins sûrs que les logiciels commerciaux mais la conception des mises à jour y est forcément différente. Les logiciels open source sont de nature collaborative. Il n’y aucune décision centralisée possible qui décidera du jour pour pousser la mise à jour. C’est à l’utilisateur de s’en préoccuper : une manière de l’aider est d’être transparent au niveau des composants utilisés (souvent des logiciels ou bibliothèques libres d’accès eux-mêmes). Car si, dans l’idéal, ce serait au développeur du logiciel open source de le faire lui-même, comment s’assurer que ce soit bien le cas ? Ceux qui choisiront une version commerciale Linux attendront légitimement ce service de la part de la société qui a fait d’une version libre une version payante. La nature collaborative des logiciels libres peut avoir comme conséquence un temps plus long avant de découvrir une vulnérabilité. Ensuite, lorsqu’une mise à jour est disponible, il y a beaucoup de canaux via lesquels le déployer : GitHub, RedHat…  Et ne vous croyez pas à l’abri  des logiciels libres si vous vous en méfiez (vous auriez tort) car des logiciels commerciaux ne rechignent pas à les utiliser comme briques pour leurs propres produits. Cisco a ainsi eu de grandes difficultés pour les mises à jour de ses logiciels après la découverte de Heartbleed.

    Chaque logiciel open source est un projet à part entière et sa manière de réaliser les mises à jour lui est propre. Quand les développeurs qui maintiennent Open SSL déploient une mise à jour, elle est toujours qualifiée de mise à jour de sécurité et est très détaillée. Il n’en est rien pour les mises à jour des noyaux Linux. Elles ne sont jamais qualifiées de sécurité car la communauté Linux a pour philosophie de considérer que tout bug peut affecter la sécurité. Les utilisateurs de Linux doivent-ils alors installer les mises à jour du noyau, parfois hebdomadaires, au risque de rendre leur machine instable ? Ceci dit, les distributions de Linux prévoient une marche arrière possible en cas de comportement instable (i.e.: retour à une version antérieure). Dans d’autres cas, on interdit aux utilisateurs de revenir à une version antérieure, via une protection matérielle, pour les empêcher de revenir à un état vulnérable. Et puis, de toute façon, il n’y a entre développeurs et utilisateurs de logiciel libre, par définition, aucune obligation sur les mises à jour.

    Les  machines virtuelles et codes éphémères

    Schéma de machines virtuelles ©wikipédia

    Vous avez peut-être déjà entendu parler de machine virtuelle ? Il s’agit d’installer sur un ordinateur un logiciel qui vous donne l’impression d’utiliser un « autre » environnement. Par exemple, vous pouvez installer une machine virtuelle proposant Windows sur un ordinateur Linux de façon à pouvoir utiliser des logiciels fonctionnant sur l’un quelconque des deux environnements sans manipulation compliquée.

    Cette approche entraine que des mises à jour de sécurité doivent non seulement concerner le système d’exploitation natif mais aussi les logiciels s’exécutant grâce à la machine virtuelle. Les codes éphémères, souvent utilisés par des services Web que nous utilisons tous les jours engendrent un autre souci. Les versions de Javascript, le langage de programmation le plus utilisé pour offrir ces services, évoluent tellement vite qu’on ne sait parfois pas sur quelle version vulnérable ou non, un logiciel a été conçu.

    Les mobiles

    © wikicommons

    Passons maintenant aux téléphones mobiles qui sont partout mais dont les politiques de mise à jour du système d’exploitation ne sont pas reluisantes au point que les USA ont ouvert une enquête en 2016 à l’encontre du secteur pour manquement à la sécurité des consommateurs. Le problème, dans ce secteur, vient de la diversité des modèles de smartphones et des fabricants sur le marché sans compter les opérateurs mobiles, qui demanderont des customisations sur les modèles de tiers qu’ils vendent. Un système d’exploitation va donc exister sous des centaines de  variantes et il ne faut pas demander aux opérateurs aux capacités limitées de tester dans leurs laboratoires, quand ils le font, la sécurité de tous les appareils qu’ils proposent.

    Au prix où sont vendus les smartphones et à la vitesse à laquelle de nouveaux modèles remplacent les anciens, il est intenable, économiquement parlant, pour un fabricant de gérer les mises à jours de tous les modèles qu’il met sur le marché. C’est triste à dire mais c’est bien le prix et la popularité du modèle qui justifiera la durée pendant laquelle des mises à jour de sécurité seront proposées. Oui, il y a de fortes chances que votre mobile ne soit plus supporté depuis longtemps pour les mises à jour de sécurité. Oui, il y a de fortes chances que vous ne le sachiez pas en lisant ces lignes. Oui, vous n’avez pas été prévenus au moment où ce support  a été arrêté et le vendeur ne vous a rien dit au moment où vous l’avez acheté ! Plus étonnant encore est que la plupart des fabricants n’ont pas de politique établie sur la durée du support qu’ils fournissent. C’est au cas par cas, ce qui a rendu nerveux les autorités américaines. Tout dépend des conditions du marché mais pourquoi donc les fabricants établis depuis longtemps ne veulent-ils pas exploiter et partager leurs bonnes pratiques en la matière avec tout le recul qu’ils ont acquis ? Pire, les fabricants ne semblent même pas documenter tout ce qu’ils ont fait par le passé avec leurs anciens modèles : combien de mises à jour ils ont déployées, le temps pour les développer, la durée de la phase de test et le taux d’adoption d’installation parmi les clients, un retour d’expérience qui serait pourtant si utile à la sécurité et une pratique qui laisse un peu sans voix.

    On se trouve avec les mobiles dans la situation contradictoire où la richesse et la diversité de l’écosystème mobile rend, en contrepartie, la gestion de la sécurité des mobiles aléatoire en durée et en fréquence : la période de support ne semble pas dépasser 1 ou  2 ans ! Les fabricants préfèrent se focaliser sur les nouveaux modèles ou les plus chers ou les plus populaires.

    Les microprocesseurs

    © wikicommons

    Si les failles de sécurité Spectre, Meltdown et plus récemment Foreshadow ont montré que les microprocesseurs pouvaient être vulnérables, une situation pas suffisamment prise en compte en cybersécurité et par les concepteurs de logiciels, il ne faut pas aller si loin pour s’en méfier. Les fabricants de processeurs prévoient une couche logicielle (microcode), donc une couche intermédiaire entre le niveau logiciel le plus profond d’un système d’exploitation (par ex. le noyau linux) et le processeur ! C’est un outil de différentiation possible entre les clients qui équipent leurs appareils avec le processeur mais c’est une source de vulnérabilité possible de par la personnalisation autorisée. Il est aberrant qu’on ne puisse plus disposer de ce processeur sans cette couche logicielle même en le payant, ce qui signifie qu’on ne peut plus payer pour plus de sécurité !

    L’internet des objets

    © wikicommons

    La mise à jour des objets qui constitueront l’internet des objets (IoT) de demain est une toute autre histoire encore à écrire. Beaucoup d’entreprises ne s’en préoccupent même pas car elles considèrent que la durée de vie de ce qu’elles fabriquent est si courte que cela n’en vaut pas la peine. De plus, la diffusion et l’installation de mises à jour sur un très grand ensemble d’objets connectés est infiniment plus complexe que pour un ordinateur « simple ». C’est une erreur. Parfois ce sont les entreprises elles-mêmes  qui sont éphémères et il n’y a alors plus personne pour réaliser les mises à jour. Une solution pourrait être de forcer les sociétés en questions à confier leur code à des tiers de confiance. Ainsi, en cas de faillite ou de disparition, d’autres pourraient reprendre le flambeau au moins pour les mises à jour de sécurité. Le cycle de développement de l’internet des objets va être beaucoup plus rapide que celui d’un système d’exploitation. Beaucoup de développeurs ne prendront pas le temps de se préoccuper de la politique de mise à jour. Certains songent à une piste inspirée d’Alexa ou des autres enceintes intelligentes à la Google qui ont aussi pour vocation de gérer les objets intelligents. On aurait des hubs qui gèrent la sécurité de tous les objets dans la maison. Ils sauraient quels sont leurs composants logiciels. Utilisent-ils les dernières versions ? Car si les utilisateurs finaux sont désormais conscients que leurs PC sont vulnérables, doivent être mis à jour, comment les convaincre que le moindre petit objet qui a l’air si inoffensif communique avec d’autres machines via Internet et peut donc être contrôlé par un hacker !

    Pis, les objets de l’IoT n’auront ni l’autonomie ni la puissance de calcul suffisantes pour leur permettre d’héberger des cyberprotections dernier cri ou pour s’autoriser des mises à jour fréquentes, forcément consommatrices d’énergie.

    Pour finir

    Il ne faut donc pas croire que la messe est dite avec les mises à jour logicielles. Si elles sont désormais plutôt bien faites pour des systèmes très répandus comme Windows 10, ce panorama montre le chemin à parcourir presque partout ailleurs. La diversité dans les politiques de mise à jour met en évidence un pan de recherche à développer : quel type de gestion des mises à jour est-elle la plus efficace ? La réponse ne tient pas qu’au seul critère de la sécurisation : le taux d’adhésion des utilisateurs est important, la durée du support est primordiale (des mises à jour au top niveau qui s’arrêtent au bout d’un an laisse l’appareil plus vulnérable qu’avant en fin de compte), l’information au consommateur importe aussi pour qu’il puisse faire un choix raisonné pour son mobile. La sécurité n’est pas juste une question de technologie mais aussi d’usage, de comportement et de sensibilisation.

    Charles Cuvelliez (École Polytechnique de Bruxelles, Université de Bruxelles) et Jean-Jacques Quisquater (École Polytechnique de Louvain, Université de Louvain) 

    Pour en savoir plus :

    Software Update as a Mechanism for Resilience and Security:   Proceedings of a Workshop, Committee on Cyber Resilience Workshop Series; Forum on Cyber  Resilience; Computer Science and Telecommunications Board;  Division on Engineering and Physical Sciences; National Academies of Sciences, Engineering, and Medicine, 2017

    Mobile Security Updates: Understanding the Issues, Federal Trade Commission, Februari 2018

     

  • Détecter le faux, sécuriser le vrai

    Nous avons déjà parlé de bobards dans Binaire, par exemple avec l’article de Benjamin Thierry. Cette fois, c’est Thierry Berthier, chercheur en cybersécurité et intelligence artificielle, qui vient nous en parler. Thierry est Chief Technical Officer d’Aletheion, une startup de cybersécurité financière qui développe des outils pour protéger les entreprises des fakenews. L’informatique a soulevé le problème. L’informatique avec, par exemple, l’intelligence artificielle et la blockchain, est convoquée pour le résoudre. Serge Abiteboul
    Thierry Berthier

    Depuis Sun Tzu, les sciences militaires s’appuient sur la déception, terme désignant l’ensemble des mesures et contremesures à mettre en œuvre pour induire en erreur son ennemi. On y retrouve les ruses de guerre, les leurres, les déformations crédibles de la réalité et les falsifications en tout genre. Désormais, ce sont les fausses données numériques ou Architectures de Données Fictives (ADF) qui sont utilisées pour « intoxiquer » une cible. A l’ère de Turing, les ADF sont massivement utilisées durant la phase initiale d’ingénierie sociale de nombreuses cyberattaques. Elles exploitent le facteur humain et les biais cognitifs pour amener la cible à cliquer sur la pièce jointe contenant un logiciel malveillant, pour cliquer sur un lien corrompu ou pour divulguer ses identifiants et mot de passe. Près de 90% des cyberattaques débutent par un leurre numérique contenant des données fictives. Cette réalité systémique place le facteur humain au centre de la chaine de sécurité et l’identifie comme le maillon le plus faible. La montée en puissance de l’intelligence artificielle augmente encore la menace en offrant des capacités nouvelles de création d’ADF complexes, immersives et cohérentes.

    Dans l’échelle des menaces numériques, la cybercriminalité financière occupe une place prépondérante. Elle est à la fois très rentable, facilement déployable et bien moins risquée pour l’attaquant que le braquage physique d’une banque ! Les cyberfraudes impactent aujourd’hui tout le spectre des entreprises, de la petite PME jusqu’au grand groupe industriel. Les arnaques au Président, les attaques FOVI (aux Faux Ordres de Virement), aux faux fournisseurs, au faux changement de RIB, ou aux faux supports techniques se sont généralisées. 93% des entreprises françaises ont été victimes d’au moins une tentative de FOVI depuis 2016. Deux tiers d’entre elles ont détecté (à temps) l’attaque mais le tiers restant a effectué le virement frauduleux. A l’échelle mondiale, le préjudice déclaré cumulé sur les trois dernières années dépasse les 6 milliards de dollars. Ces attaques sont construites selon des scénarios variables mais elles partagent une trame opérationnelle commune. L’attaquant usurpe l’identité d’une autorité interne ou externe à l’entreprise et amène son interlocuteur à effectuer un virement en urgence et de manière confidentielle. Pour rendre crédible l’usurpation d’identité, il s’appuie sur de faux sites web imitant un site officiel, sur de faux documents crédibles et sur une phase d’ingénierie sociale intense qui lui permet de collecter des renseignements exploitables concernant sa future victime.

    L’ADF peut être utilisée à plus grande échelle pour déstabiliser le cours d’une action d’une entreprise cotée en bourse. L’objectif de l’attaquant est de créer artificiellement une forte et éphémère volatilité sur un titre ciblé afin d’exploiter ces variations brutales. Il peut alors spéculer à la baisse puis à la hausse en avance du marché. Pour cela, il lui suffit de produire un communiqué officiel crédible, usurpant l’identité du service de communication du groupe ciblé et d’annoncer des baisses de résultats, des difficultés financières ou une fusion acquisition inamicale. Le communiqué est alors diffusé auprès des agences de presse spécialisées qui, si elles ne détectent pas le caractère frauduleux du message, le diffusent à leur tour, induisant un FlashCrash sur le titre. Ce type d’attaque par HoaxCrash ne dure jamais plus de 5 à 6 minutes, le temps qu’un démenti soit publié, souvent par l’attaquant lui-même, entrainant la remontée du cours à son niveau initial. Les « HoaxCrash en V » peuvent induire de fortes turbulences boursières. Ils provoquent des préjudices financiers pour les acteurs qui ont tenu compte de la fausse information dans leurs stratégies à court terme. Lorsqu’ils se répètent, les HoaxCrash nuisent à l’image et la réputation de l’entreprise ciblée.

    Une fois mis en place, les ADF agissent comme des leurres cognitifs immersifs de plus en plus difficilement détectables par le cerveau humain.   Comment lutter contre ces attaques ?

    L’intelligence artificielle donne de bons résultats dans la détection des tentatives de fraudes bancaires et des cyberattaques. L’apprentissage automatique appliqué à la cybersécurité a montré son efficacité dans la détection des menaces persistantes avancées et des attaques furtives en s’appuyant notamment sur l’analyse du comportement des utilisateurs. Ces techniques exploitent de grands volumes de données issues du système d’information pour identifier très en amont, les séquences caractéristiques d’attaques. Le traitement automatique du langage naturel est utilisé pour analyser le contenu d’un mail et ses métadonnées à la manière d’un filtre anti-spam. Le texte est préalablement décomposé en « token » signifiants. Ceux-ci sont ensuite confrontés à des motifs typiques de scénarios de fraude. Une métrique adaptée permet d’évaluer la proximité du message reçu avec un message d’attaque typique, de calculer un indice de véracité et un indice d’impact de ce message. En cas de forte similarité avec un message frauduleux, des alertes sont envoyées en temps réel pour bloquer au plus tôt les mécanismes destructeurs des FOVI et des HoaxCrash. L’intelligence artificielle agit alors comme un assistant bienveillant donnant l’alerte quand nos fragilités biologiques nous poussent vers le piège numérique.

    Enfin, une architecture Blockchain couplée à une identification forte et/ou biométrique de l’émetteur à l’entrée de la chaîne de blocs s’avère utile pour sécuriser la transmission de documents et lutter contre les attaques par usurpation d’identité. C’est cette complémentarité de l’IA et de la Blockchain qui assure la robustesse du dispositif et qui apporte une réponse pertinente au problème plus global des fake news.

    Thierry Berthier, Chercheur en cybersécurité & cyberdéfense, CTO Aletheion

    Pour aller plus loin, il faudra attendre :

    From Digital Traces to Algorithmic Projections, Thierry Berthier et Bruno Teboul, À paraître  le 1 octobre 2018, ISTE Wiley – Elsevier. Version françasie en janvier 2019

  • Et nos données impersonnelles alors ?

    Nous avons beaucoup entendu parler des données personnelles avec le Règlement Général sur la Protection des Données (RGPD), applicable depuis le 25 mai 2018. C’est oublier que d’autres données, « impersonnelles », sont massivement traitées pour façonner des pans entiers de nos vies quotidiennes. Ces traces numériques agrégées qu’on qualifie d’« alter ego » et dont Lêmy Godefroy, nous en explique le fonctionnement et les enjeux.

     

     

    Que sont ces données impersonnelles ?

    Ces données impersonnelles sont issues de l’agrégation de traces numériques constituées de données et de métadonnées de communications électroniques. Ces traces numériques sont des données strictement techniques comme les données de connexion (par exemple la date, l’heure et la durée de chaque connexion) ou les données de trafic (date des visites d’un site, durée de consultation, mots-clés entrés, etc.). Elles se distinguent des données d’identification des personnes (adresse IP, adresse MAC, identifiant de connexion, etc.). Agrégées et généralisées, elles participent à l’élaboration de modèles comportementaux (des alter ego numériques) par des algorithmes en vue du ciblage de catégories d’individualités (les ego).

    Par nature, ces données impersonnelles échappent aux réglementations nationales et européennes de protection des données personnelles. La Proposition de règlement du 10 janvier 2017 concernant le respect de la vie privée dans les communications électroniques (règlement « vie privée et communications électroniques » ou e-privacy), en cours de discussion au niveau européen, les envisage à demi-mots.

    Images rayons de lumière

    Ces données échappent elles à tout contrôle alors ?

    Ce texte s’attache à préserver la confidentialité des communications électroniques1. Cela implique que les données échangées entre les parties ainsi que les métadonnées ne doivent pas être divulguées sans le consentement des personnes concernées. Ces données et métadonnées peuvent en effet révéler des informations sensibles et intimes (problèmes de santé, préférences sexuelles ou encore opinions politiques).

    Lorsque ces données de communications électroniques sont à caractère personnel, la proposition de règlement e-privacy vient compléter les dispositions plus générales du RGPD. Le cadre juridique est donc bien établi.

    Elle indique par ailleurs que « les données de communications électroniques sont généralement des données à caractère personnel ». Ce qui suppose, a contrario, qu’elles peuvent parfois ne pas l’être. En effet, les données et métadonnées de communications électroniques qui proviennent d’un groupe indéterminé d’utilisateurs se distinguant par des caractéristiques comportementales communes ne se rapportent pas à une personne physique identifiée ou identifiable.

    Or, la proposition de règlement e-privacy ne s’appesantit pas sur ces données impersonnelles et ne semble alors pas prendre la mesure de la portée de leur traitement sur la vie privée et les libertés des individus.

    Quel est l’enjeu de ces données en fait ?

    Pourtant, ces données, automatiquement et systématiquement collectées, sont agrégées, analysées et dotées de sens par des algorithmes pour en extraire des modèles typiques de comportements – des alter ego numériques – représentations parcellaires d’un type d’individualités qui participent au développement de pratiques de ciblage comportemental (OBA, online behavioral advertising).

    Le traitement des traces numériques agrégées implémente ainsi un alter ego numérique ayant l’ego pour cible, avec le risque latent d’un formatage individuel et d’un enfermement dans une pseudo personnalisation2.

    On parle d’alter-égo numérique : de quoi s’agit-il précisément ?

    L’alter ego numérique est dépouillé de toute identité. Il est inféré d’une profusion de données provenant du regroupement d’une multitude d’individualités. « De fait, les personnes ont tendance à disparaître derrière leurs traces »3. Ces données sont absorbées, assimilées par des algorithmes et transmutées en modèles qui sont autant d’alter ego numériques nés sous X, sans identité, ni identification possible, auxquels sont statistiquement associés des comportements, des préférences, des dispositions d’esprit.

    La formation d’alter ego numériques se distingue de l’établissement de profils.

    Le profilage désigne une forme de traitement automatisé de données à caractère personnel destiné à évaluer certains aspects propres à une personne physique pour prévoir, notamment, son rendement professionnel, sa situation économique, sa localisation, son état de santé, ses préférences, sa fiabilité ou son comportement4. Autrement dit, le profilage convertit les données personnelles d’un individu en fidèle portrait numérique. Cette réplique numérique vise à adapter une offre de produits et de services. Par exemple, dans le domaine de l’énergie électrique, les compteurs intelligents calquent l’offre d’énergie sur la consommation réelle de l’utilisateur à partir des données personnelles qu’ils collectent.

    En revanche, l’alter ego numérique recommande à une catégorie ciblée d’individus des produits et des services qui sont probablement susceptibles d’intéresser chacun d’eux. « Le futur de l’internaute [se voit alors] prédit par le passé de ceux qui lui ressemblent »5.

    Si l’ambition du profilage est d’établir un clone numérique pour personnaliser une offre, celle de l’alter ego numérique est d’anticiper la demande de l’ego. En quelque sorte, le profilage s’adapte à l’individu tandis que l’alter ego numérique « adapte » l’individu à l’offre.

    En cela, l’alter ego numérique est dépersonnalisant même si cet autre que soi doit s’apparenter davantage à un autre soi-même6 pour que l’ego, ressentant une proximité suffisante avec l’alter ego numérique, se laisse influencer, la plupart du temps inconsciemment, par cet autrui si proche de lui.

    L’ego est subtilement invité par l’alter ego numérique à prendre un chemin qu’il n’aurait pas nécessairement emprunté de lui-même. Ce jeu d’influence se traduit par « une interaction sur le processus de décision qui aboutit à une modification des intentions »7. Plus encore, l’alter ego numérique peut, insidieusement, orienter les réflexions et les actions de l’ego.

    Quels devraient être nos droits par rapport à ce ciblage ?

    Pour prévenir les abus d’influence, chacun devrait être en mesure d’accepter ou non son rattachement à des alter ego numériques, par analogie au droit à l’autodétermination informationnelle8 qui restitue à l’individu la capacité de décider de la communication et de l’emploi de ses données à caractère personnel. Le ciblage serait alors juridiquement valable en cas de consentement exprimé clairement par une action de l’utilisateur sur le paramétrage des traceurs initialement programmés par défaut pour ne pas prélever ses traces numériques.

    Image Checklist - Yes/No

    Et dans l’hypothèse où l’individu accepte d’être ciblé, il disposerait du droit de demander des comptes au responsable du traitement sur les alter ego numériques auxquels il est affilié, sur la pertinence des ciblages dont il est l’objet, sur la correction éventuelle des erreurs de corrélation commises par les algorithmes d’agrégation des traces numériques. Ce droit de regard sur le résultat du traitement des traces numériques substituerait un ciblage consenti à un ciblage subi.

    Ce qui n’affranchirait pas pour autant les stratèges de l’influence (concepteurs initiaux des algorithmes de traitement qui délivrent leurs instructions, programmeurs dans l’opération de codage informatique, éditeurs de logiciels fabriquant des produits les intégrant ou vendeurs qui les commercialisent9) de leur responsabilité en cas de dommages consécutifs à un ciblage. En effet, « il est possible de prononcer de nombreuses prédictions à partir des données du web, mais, comme toute prédiction, elles sont des estimations statistiques imparfaites. (…) En réalité, elles ne font que dire, avec plus ou moins d’approximations, le probable »10.

    Néanmoins, si une chaîne de responsabilités devrait être établie pour tenir compte des comportements de chacun, le responsable du traitement doit demeurer au centre du dispositif afin d’éviter une dilution des responsabilités11.

    De plus, la fonction de ciblage peut également être détournée à des fins illicites, par exemple, lorsque la programmation des algorithmes de traitement des données est discriminatoire. Ainsi, dans le domaine de la culture, sont évoquées « la tentation de manipulations destinées à favoriser les œuvres produites par un éditeur et […] la menace d’une standardisation de la création »12. Dans le secteur des assurances, le traitement algorithmique pourrait également conduire à établir des typologies d’assurés à risque en fonction de critères discriminants.

    Quelle est la proposition de solution alors ?

    En définitive, la protection de la vie privée en cas de traitement massif des données impersonnelles pourrait reposer sur trois mesures : un paramétrage par défaut des traceurs programmés pour ne pas « aspirer » ces données, une normalisation éthique de la méthodologie suivie par les algorithmes de traitement qui préserverait le secret des règles de l’algorithme et dont la conformité serait attestée par l’attribution d’une certification et un contrôle en continu de cette conformité par un organisme tiers pour accroître la confiance des usagers et contrecarrer la prise de pouvoir des alter ego numériques.

    Lêmy Godefroy, Maître de conférences spécialisée en droit du numérique, au GREDEG de l’Université de Nice Côte d’Azur.

    Notes :

    1 Conformément à l’article 7 de la Charte des droits fondamentaux de l’Union européenne.
    2 D. Cardon, A quoi rêvent les algorithmes, Seuil, octobre 2015.
    3 D. Cardon, ibid..
    4 Considérant 71 du Règlement général sur la protection des données (RGPD) du 27 avril 2016.
    5 D. Cardon, ibid..
    6 P. Ricoeur, Soi-même comme un autre, Seuil, 1996.
    7 J.G. March, « Introduction to the Theory and Measurement of Influence », American Political Science Review, juin 1955, pp.431-451.
    8 BVG (Cour constitutionnelle fédérale allemande), 15 décembre 1983 cité par Y. Poullet et A. Rouvroy, « Le droit à l’autodétermination informationnelle et la valeur du développement personnel », http://www.crid.be/pdf/public/6050.pdf
    9 J.-B. Duclercq, « Les effets de la multiplication des algorithmes informatiques sur l’ordonnancement juridique », Communication Commerce électronique, novembre 2015, étude 20.
    10 D. Cardon, ibid..
    11 Ici, les remèdes classiques du droit des obligations apporteraient des réponses : en cas de mauvaise corrélation des données par les algorithmes et de ciblage non pertinent, le responsable du traitement engagerait sa responsabilité pour faute présumée. Il lui incomberait de rapporter la preuve de son absence de faute, de l’existence de la faute d’un tiers et/ou de la victime (qui aurait communiqué de fausses données générant une indication erronée en sortie du processus) ou d’un cas de force majeure (aléas inhérents au processus algorithmique) pour s’exonérer partiellement ou totalement.
    12 O. Schrameck, Allocution au Forum de Tokyo, décembre 2014, http://www.csa.fr

  • Plus silencieux que la grande muette

    Après avoir présenté la certification de systèmes informatiques à l’occasion d’un article de binaire et l’émergence de débats sur le fait que les états doivent ou pas déléguer certaines de leurs prérogatives dans la sécurité numérique. Binaire a reçu le point de vue de deux collègues à propos d’un des acteurs de ces questions : l’ENISA. L’agence européenne de sécurité des réseaux est une agence de cybersécurité, qui est au centre de ce débat.
    Pierre Paradinas

    L’agence européenne de sécurité des réseaux ne craint plus sa disparition

    https://www.enisa.europa.euOn a presque oublié son existence :  l’Union Européenne dispose d’une agence de cybersécurité, l’ENISA. On ne l’a jamais beaucoup entendue mais ce n’est pas sa faute : son rôle opérationnel a été limité dès sa naissance, par la volonté des grands Etats membres qui voyaient d’un mauvais œil une incursion européenne dans leur sécurité nationale.

    C’est aussi la raison pour laquelle l’ENISA a été la seule agence européenne avec un mandat non permanent, à l’issue duquel son existence était chaque fois remise en question. Elle était de ce fait incapable de se projeter dans le futur et de développer une vision.

    Son mandat actuel se termine en 2020 (il a commencé en 2013 : ces 7 ans de mandat sont le maximum jamais attribué à cette agence) mais en septembre la Commission a proposé une nouvelle stratégie pour la cybersécurité qui fait la part belle à cette agence. Son budget annuel doublerait : de 11,2 à 23 millions € et son personnel passerait de 84 à 125. L’agence aurait aussi un rôle opérationnel pour coordonner la réaction des Etats membres en cas de cyber-attaque.

    L’ENISA va aussi être un acteur clé pour la cyber-certification. Si on veut considérer la sécurité dès la conception du produit (on parle alors de « security by design »), la certification est nécessaire mais chaque état membre, s’il s’en préoccupe, le fait à sa sauce.  Il y a bien la norme ISO 15408 qui sert de socle à un accord international (le Common Criteria Recognition Arrangement ou CCRA) de reconnaissance mutuelle mais seuls 13 Etats membres  l’ont signé et seuls deux niveaux de certifications sur sept sont reconnus mutuellement. Avoir une certification propre à chaque état membre est évidemment insupportable pour la Commission qui y voit une entrave au marché unique. Chaque Etat membre doit mettre en place une autorité chargée d’accréditer des organes qui peuvent délivrer les certificats. Ainsi c’est l’ENISA qui serait chargée de préparer le contenu de ces certifications en coopération avec un groupe d’experts constitué des autorités d’accréditation. À moins d’être obligatoire via une autre législation de l’Union, la certification resterait volontaire. En gardant un caractère volontaire à la certification, la Commission veille à ne pas imposer cette lourdeur aux services ou produits peu critiques et dont le prix augmenterait de ce fait. S’il y a une certification européenne en place, les Etats membres ne pourront plus avoir une certification nationale propre. Un fabricant pourra aller chez l’organe d’accréditation de son choix.

    La directive « cybersécurité  » avait déjà revu à la hausse le champ de responsabilité de l’ENISA en la transformant en cheville ouvrière pour son implémentation et son suivi. C’était une bonne raison de transformer l’ENISA en agence permanente.

    Dans sa proposition de régulation qui fixe le contour de l’ENISA, nouvelle formule, cette dernière aura les compétences suivantes :

    • Développer une politique cohérente européenne de sécurité de l’information et dans d’autres secteurs sensibles (énergie, transport, finance) et dans les domaines de l’identité électronique et des services de confiance;

    • Améliorer de la capacité de réponse de l’Union Européenne et de ses Etats membres en cas d’attaque (1);

    • Conseiller le nouveau centre de recherche en cybersécurité : le European Cybersecurity Research and Competence Centre qui verra le jour en 2018;

    • Faciliter la coopération entre les Etats membres volontaires (on imagine de fait que peu de grands Etats le feront), en analysant en cas d’incident des informations reçues des Etats membres pendant leur déroulement.

    Justifier un rôle pour l’ENISA

    La Commission justifie une action au niveau de l’Union Européenne via le test de subsidiarité, qui doit prouver qu’une action au niveau européen ne peut qu’être plus efficace comparée au niveau national. Ce qui, quand on parle de sécurité est une une gageure, les arguments devront être solides pour résister aux grands Etats membres qui ont, c’est vrai, entériné lors d’un conseil européen la nécessité pour l’Europe de se doter d’une cyber-stratégie.

    Pour la Commission, les réseaux, les systèmes d’information, les infrastructures critiques sont toutes interconnectées au niveau européen. Aucun pays ne peut plus gérer seul un cyber-incident qui se propagera automatiquement à tous ses voisins de surcroit. Vu ainsi, il ne s’agit pas comme le prétendent d’aucuns d’un transfert de compétences qui privent les Etats membres de leur capacité d’analyse [1]. Accepter une coordination de l’Europe, c’est faire un premier pas vers l’Europe de la défense qui nous a tellement manqué. La France, qui est le plus crédible des Etats membres en la matière, peut montrer la voie.

    Charles Cuvelliez, École Polytechnique de Bruxelles (ULB), Jean-Jacques Quisquater, École Polytechnique de Louvain, UCL

    Pour en savoir plus:

    Review of ENISA Regulation and laying down a EU ICT security certification and labelling, European Commission, July 7, 2017

    Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on ENISA, the « EU Cybersecurity Agency », and repealing Regulation (EU) 526/2013, and on Information and Communication Technology cybersecurity certification ( »Cybersecurity Act »), Brussels, 13.09.2017

    [1] Les Etats ne doivent pas déléguer leur sécurité numérique  Nicolas Arpagian / directeur scientifique du cycle Sécurité Numérique à l’INHESJ, Les Echos du 30.11.2017

    (1) On peut se demander pourquoi elle ne devient pas elle-même cette capacité de réponse, une option qui figurait dans une consultation à son égard. Elle doit se contenter de contribuer à l’établissement d’ISACS (Information Sharing and Analysis Centres) par secteur en diffusant bonnes pratiques et guidance.

  • Sécurité routière et cybersécurité

    Avec les objets connectés, notre sécurité est remise en question. Binaire publiait l’an dernier une nouvelle « You are under arrest » qui essayait d’imaginer ce qui pourrait se produire dans le futur si, aujourd’hui, nous n’accordons pas au sujet de la sécurité, toute l’importance qu’il mérite. Nous avons demandé à Gérard Le Lann, un spécialiste de la question, de nous expliquer cette fois techniquement ce qu’il en était. Serge Abiteboul.

    Une réduction significative du nombre d’accidents graves (invalidités, pertes de vies humaines) et une meilleure efficacité (réduction des temps de trajet, quasi-élimination des embouteillages) sont deux des buts principaux de la conduite automatisée (avec ou sans chauffeur humain). Les buts d’innocuité (*) et d’efficacité ne pouvant être atteints en se limitant à la robotique embarquée (radars, lidars, caméras, etc.), des travaux ont été entrepris dès 2004 dans le but de doter les véhicules d’émetteurs/récepteurs radio. Cela a conduit au concept de véhicule autonome « connecté » (VAC). À partir de 2020, les véhicules mis en circulation aux USA devront être dotés d’équipements radio conformes aux solutions WAVE (pour Wireless Access in Vehicular Environments) actuelles, qui comprennent un ensemble de protocoles basés sur des télécommunications de type wifi, connues sous l’acronyme V2X (vehicule-to-everything), permettant à un VAC d’être « connecté » à des relais terrestres (infrastructures routières, réseaux de télécommunications) et de communiquer avec d’autres VAC. Si rien ne l’entrave, cette décision s’imposera en Europe et ailleurs. Cette perspective est inquiétante.

    Waymo Chrysler Pacifica Hybrid, testée dans la région de la Baie de San Francisco.Wikipedia

    On sait que, dans des conditions de trafic moyennement dense, le nombre de véhicules en compétition pour accéder au canal radio partagé est tel que les délais de transmission de message sont trop grands pour éviter les accidents. En outre, les communications radio étant non fiables, les messages V2X émis peuvent ne pas être reçus par les destinataires visés. Il est donc impossible de prédire quoi que ce soit concernant la coordination inter-véhiculaire. Des diffusions périodiques de balises sont censées procurer l’innocuité désirée. Tout véhicule doit diffuser, entre 1 fois et 10 fois par seconde, un message V2X daté donnant, en particulier, sa géolocalisation et sa vitesse, nécessairement non chiffrées. L’idée sous-jacente est que les VAC co-localisés peuvent maintenir la même carte donnant leurs positions exactes et celles des véhicules qui les environnent, et ainsi éviter les accidents. C’est malheureusement faux. A raison de 10 balises par seconde, en conditions de trafic moyennement dense, le canal radio est vite saturé. Du coup, les véhicules ne peuvent plus être géolocalisés. A des fréquences plus faibles, en présence de pertes de balises, les cartes des VAC ne peuvent être identiques. En dépit du gaspillage de ressources de calcul et de communication, on ne peut éviter les accidents.

    Du point de vue « connexion », avec WAVE, les VAC sont équivalents à des smartphones-sur-roues. Ils sont donc potentiellement sujets à cyberespionnage et vulnérables aux cyberattaques dont sont victimes les équipements radio sans fil. Le problème est que les smartphones-sur-roues peuvent tuer. La possibilité d’une prise de contrôle à distance de véhicule a été démontrée à plusieurs reprises, lors de conférences Black Hat et par des agences gouvernementales. Les techniques cryptographiques en cours de normalisation destinées à contrer le cyberespionnage et les cyberattaques (usurpation d’identité, falsification de messages légitimes, injection de messages frauduleux, etc.) n’éliminent pas complètement les vulnérabilités. Par exemple, les attaques de « l’homme du milieu » (**) sont possibles. On montre également qu’il est possible de pister les trajets, en reliant des géolocalisations. Même avec des messages V2X « anonymisés », si l’on peut associer des lieux fréquemment visités (par exemple un lieu de travail et un lieu de résidence), alors le piratage de données d’ordre privé devient réalisable. Ces faiblesses sont connues mais la communauté WAVE 1.0 (***) tente de s’en dédouaner en affirmant que l’on ne peut faire mieux. C’est faux.

    D’autres solutions proposées plus récemment (toute une gamme que nous appellerons ici WAVE 2.0) permettent de garantir à la fois l’innocuité maximale et la cybersécurité « by-design ». Les protocoles WAVE 2.0 reposent sur des communications directes V2V (vehicule-to-vehicle) qui garantissent des délais d’échange de messages et de coordination inter-véhiculaire extrêmement courts, ce qui permet de prouver l’innocuité. Les technologies de communications radio et optiques utilisées sont de courte portée et bien plus performantes que les technologies WAVE. Les messages V2V n’étant échangés qu’entre voisins « immédiats », les attaquants potentiels d’un VAC sont aisément et immédiatement détectables, ce qui permet de prouver que les cyberattaques rapprochées ne peuvent mettre en péril l’innocuité (une propriété fondamentale). Les identifiants des VAC émetteurs de messages V2V étant totalement anonymisés, le cyberespionnage rapproché n’est d’aucun intérêt.

    L’architecture des systèmes bord des VAC garantit que les télécommunications V2X ne peuvent avoir d’impact sur la robotique du véhicule. Ainsi, la prise de contrôle à distance devient infaisable. Plus généralement, on peut montrer que les cyberattaques ourdies par des entités inconnues distantes ne peuvent mettre en péril l’innocuité. Quant aux risques de cyberespionnage distant, ils n’existent qu’à la condition d’autoriser les télécommunications V2X sortantes (accès à Internet, etc.). Il est donc indispensable d’offrir à un passager de VAC la possibilité d’exprimer via une option « furtivité » son refus ou son consentement pour activation des télécommunications sortantes V2X individuelles. Avec WAVE 2.0, en cas de comportement malveillant, la robotique embarquée prend le contrôle du VAC et l’immobilise en lieu sûr, pendant que sont diffusés, à destination des autorités, des messages V2X chiffrés permettant d’identifier et de géolocaliser le véhicule immobilisé, ainsi que de fournir le contenu pertinent d’une boite noire. Malgré l’anonymat, les enregistrements consignés dans les boites noires assureront l’indispensable imputabilité (****).

    Les capteurs intérieurs à un VAC (caméras, par exemple) dont les avantages sont abondamment médiatisés (s’assurer de la vigilance humaine, par exemple) sont des sources supplémentaires de cyberespionnage. Les atteintes à la vie privée sont bien certaines. Que deviennent ces données, notamment en cas de piratage des serveurs qui les hébergent ? Les passagers des VAC ont pourtant droit au respect de leur vie privée. Tout comme l’option « furtivité », une option « désactivation des capteurs intérieurs » doit être offerte.

    Les voitures autonomes Navlab. Navlab 5 (le véhicule le plus proche ) achevé et 1995, a été la première voiture à traverser en autonome les États-Unis d’une côte à l’autre.

    Faux dilemme—Vrai choix de société

    Nous n’avons pas à choisir entre innocuité et cybersécurité, les deux propriétés existent avec WAVE 2.0. Nous sommes donc dès à présent confrontés à un choix de société :

    • soit les solutions WAVE 1.0 sont déployées, et alors nous seront potentiellement cybersurveillés et sujets aux cyberattaques lors de nos déplacements motorisés,
    • soit, grâce aux actions combinées des mondes académique, juridique, de sociologues, de spécialistes de l’éthique, du monde industriel et des autorités gouvernementales européennes, nous leur préférons au contraire les solutions WAVE 2.0 et leurs options « furtivité » et « désactivation des capteurs intérieurs », qui vont dans le sens du Règlement Général sur la Protection des Données. WAVE 2.0 deviendrait ainsi le socle d’une nouvelle génération de standards pour les technologies des véhicules autonomes du futur.

    Dans quel type de société voulons-nous vivre ? Voilà la question qui est posée.

    Gérard Le Lann, Inria

    NB : le lecteur intéressé pourra consulter la publication C&ESAR 2017

    (*) Non-dangerosité (quasi élimination des accidents graves).

    (**) L’attaque de l’homme du milieu (man-in-the-middle attack) a pour but d’intercepter les communications entre deux parties, sans que, ni l’une, ni l’autre ne puisse se douter que le canal de communication entre elles a été compromis. L’attaquant doit d’abord être capable d’observer et d’intercepter les messages envoyés par une victime, disons Alice, à l’autre, Bob. L’attaquant parle à Alice en prétendant être Bob, et à Bob en prétendant être Alice.

    (***) WAVE 1.0 (WAVE + balisage périodique) et WAVE 2.0 sont des notations d’ordre pratique proposées par l’auteur.

    (****) Attribution des responsabilités et non-dénégation des causes ayant entrainé un accident grave.

  • Meltdown et Spectre, c’est grave docteur ?

    Nous avons déjà publié un article de David Monniaux sur les failles des ordinateurs, Meltdown et Spectre, qui occupent le devant de l’actualité. L’importance de cette information est suffisante pour nous conduire à enrichir le débat avec un deuxième texte que nous ont proposé Jean-Jacques Quisquater et Charles Cuvelliez.
    binaire

    La faille largement médiatisée sur Intel et ses concurrents, AMD et ARM, sonnera comme une piqûre de rappel : performance et sécurité ne riment pas souvent. Il s’agit en fait de deux failles  dénommées Spectre et Meltdown par leurs découvreurs respectifs.

    Spectre

    Spectre utilise la technique d’anticipation dans l’exécution des instructions envoyées au microprocesseur. Il arrive souvent qu’un microprocesseur, pour gagner du temps, spécule sur les prochaines instructions qui doivent lui être envoyées de la mémoire.  A ce niveau élémentaire de programmation, c’est souvent possible avec succès et utile lorsque l’exécution de cette instruction dépend de valeurs en mémoire. La rapatrier de la mémoire prend relativement tellement de temps par rapport à la rapidité du microprocesseur, que ce dernier préfère encore la deviner et exécuter l’instruction quitte à tout laisser tomber s’il s’était trompé. Il revient en arrière en se basant sur l’état dans lequel il était avant de spéculer à tort. Cela arrive rarement et au final, le gain en performance est substantiel.  En fait, les microprocesseurs n’exécutent pas souvent dans l’ordre les instructions d’un programme. Il exécute parfois des instructions, qui arrivent plus loin dans le flux en question, bien en avance pour gagner du temps même si leur déroulement dépend (du résultat) des  instructions antérieures.  Plutôt que d’être bloqué à ce niveau, il spécule encore. C’est là que se trouve la vulnérabilité  Spectre : comme les microprocesseurs sont censés revenir à leur état antérieur, en effaçant matériellement tout, si l’instruction spéculée n’était pas correcte, pas suffisamment de sécurité n’a été introduire à ce niveau.

    L’erreur de conception est que le microprocesseur n’efface pas toutes les conséquences de l’exécution anticipée d’une instruction qui n’était pas la bonne. En d’autres termes, il n’efface pas tout ce que cette instruction anticipée à mauvais escient a créé comme changements dans l’état des différents éléments du microprocesseur, en particulier, les caches. Dès lors, il suffit de forcer le microprocesseur à spéculer sur une instruction qui donne accès à l’attaquant à des données sensibles.

    Les chercheurs ont montré que c’était possible. Ils ont créé un programme qui contenait des données secrètes stockées dans  la mémoire. Ils ont compilé ce programme et ont recherché dans le code exécutable les instructions qui accèdent à cette mémoire pour en extraire les données confidentielles. Ils ont ensuite forcé le microprocesseur à spéculer sur les prochaines instructions à effectuer en allant chercher précisément ces instructions-là. Bingo : le microprocesseur a tout simplement lu le contenu en mémoire du programme « normal ». Il avait donc accès à des données confidentielles d’un autre utilisateur auxquelles l’attaquant n’aurait pas dû avoir accès. Plus inquiétant : ils ont pu renouveler l’exploit avec un code javascript portable. Ceci dit, pour mettre cette attaque en pratique, ce ne sera pas une sinécure. Toute la difficulté de l’attaque consiste à donner au microprocesseur la bonne instruction à exécuter de manière spéculative et anticipée pour accéder à de l’information confidentielle. Dans leur démo, les chercheurs ont simplement forcé le processeur à lire le contenu d’une adresse mémoire choisie par eux et qui pourrait dans un cas réel contenir de l’information confidentielle d’une tierce personne.

    En fait, les techniques d’isolation des programmes qui tournent sur un même ordinateur sont connues et déployées depuis longtemps.  Elles empêchent un programme d’accéder à la mémoire utilisée par un autre programme concurrent. Ouf. Ce que ces techniques n’ont pas prévu est qu’à un niveau inférieur, le microprocesseur, l’exécution anticipée d’une instruction pourrait amener un attaquant à violer, au niveau matériel, cette séparation qui se passe au-dessus. Toutes ces techniques se basent sur l’idée que seules les instructions officielles sont réputées avoir été effectuées, et pas des instructions spéculatives qui vont aller là où il ne faut pas sans contrôle élémentaire.

    Bien sûr, cette attaque, pour être réaliste, exige que l’attaquant puisse interagir avec la victime, par exemple utiliser le même CPU et d’avoir accès, d’après le compilateur utilisé par la victime, aux zones probables de la mémoire où il pourrait y avoir de l’information confidentielle. Il n’empêche : Spectre affecte tous les microprocesseurs : AMD, ARM, Intel. Spectre est difficile à exploiter mais il existe des remèdes. On devrait pouvoir stopper l’exécution spéculative d’instructions mais c’est alors au prix d’une sérieuse dégradation de performance. On ne pourrait stopper que les instructions de lecture mémoire spéculative mais ce n’est pas suffisant car de l’information sensible pourrait ne pas venir que de la mémoire. La seule bonne nouvelle est que seul le secret des données peut être violé, par leur intégrité.

    Meltdown

    Meltdown est une autre vulnérabilité qui viole un principe fondamental de sécurité des microprocesseurs : l’isolation des mémoires utilisées par les différents programmes qui tournent sur un ordinateur en fonction de leur niveau de privilèges. On parle d’exécution en mode kernel (privilégié) ou en mode utilisateur.  Le mode kernel donne accès au système lui-même.  Face à ce danger, la mémoire utilisée par le mode kernel est normalement totalement séparée de la mémoire utilisée en mode utilisateur. Le problème est que passer du mode kernel au mode utilisateur finale ou l’inverse exige de passer d’une zone mémoire à l’autre totalement invisibles et isolées l’une de l’autre. Cela prend un temps fou et dégrade les performances du processeur. Mais c’est indispensable : la mémoire kernel peut contenir tous les secrets imaginables de votre machine : mots de passe, contenus de fichiers chargés en mémoire … Dans les microprocesseurs modernes, cette isolation entre mode kernel et mode utilisateur est réalisée au plus profond du microprocesseur : un seul bit définit dans quel mode on est et autorise ou non l’accès à la mémoire réservée au mode kernel. C’est une protection matérielle qui permet alors de faire coexister dans la mémoire pour le mode utilisateur, la référence à la mémoire pour le mode kernel. Le passage en mode kernel est alors rapide et immédiat. Ce ne serait pas le cas s’il fallait parcourir l’ensemble de la zone mémoire en sauvegardant à chaque fois le contexte du mode que l’on quitte.

    Autre protection : lorsqu’un mode utilisateur essaie d’accéder à une zone kernel, votre machine réagit très mal et fait crasher le programme en mode utilisateur qui s’essayait à cette liberté. L’attaque Meltdown consiste aussi, comme pour Spectre, à faire exécuter par le microprocesseur des instructions de manière spéculative pour gagner du temps, dont celle qui donnera accès à la mémoire kernel et à éviter ou retarder le test de savoir si ce sont les bonnes instructions qui ont été exécutées. Lorsque le microprocesseur exécute des instructions de manière spéculative, il le fait en avance de phase d’autres instructions, dont celle qui lui donnerait le droit d’accéder au kernel. C’est donc normal, à ses yeux, de ne pas exécuter le contrôle d’accès au kernel. Erreur !

    Contrairement à Spectre, il existe des remèdes logiciels contre Meltdown même s’il s’agit, comme pour Spectre,  d’un problème hardware, de sorte que les Linux, Microsoft et consorts sont affectés. Les remèdes consistent à imposer à nouveau de manière stricte la séparation entre les références mémoires kernel en utilisateurs de sorte que le mode utilisateur n’imagine même pas qu’il puisse existe une zone mémoire kernel. Meltdown a le plus d’impact sur les clouds car la même mémoire kernel est alors partagée entre plusieurs utilisateurs. En d’autres termes, tous les mots de passe et autres données sensibles de plusieurs utilisateurs simultanées s’y trouvent !  C’est le cas des clouds non totalement complètement virtualisés. Meltdown pourrait obliger ces fournisseurs de clouds à totalement virtualiser leur utilisateurs ou à pratiquer une séparation totale des zones mémoires utilisateurs et kernel, avec un impact sur leur performance. Bref, cela va coûter.

    Meltdown et spectre, pas si neufs que ça

    Ceci dit, Meltdown et Spectre ne sont pas tout à fait neufs dans leur essence et il fallait s’y attendre. On sait depuis longtemps que si l’optimisation matérielle peut aller jusqu’à modifier le statut des éléments matériels contenus dans le microprocesseur, il met en péril toutes les protections softwares au-dessus. Les algorithmes cryptographiques sont considérés comme fautifs s’ils ne sont pas immunisés contre cela. Meltdown va cependant un cran plus loin puisque la granularité d’accès va jusqu’au bit même.

    C’est pourquoi les auteurs craignent d’avoir ouvert la boite de pandore : on ne serait qu’au début de nos déboires de voir combien les optimisations matérielles qui s’autorisent à changer des éléments matériels du microprocesseur peuvent amener des vulnérabilités.

    Dans les deux attaques, il y aussi l’étape cruciale qui consiste à faire fuiter les informations contenues dans le cache pour lesquelles des techniques connues existent.

    Jean-Jacques Quisquater (École Polytechnique de Louvain, Université catholique de Louvain) et Charles Cuvelliez (École Polytechnique de Bruxelles, Université libre de Bruxelles)

    Pour en savoir plus

  • L’attaque Meltdown

    Depuis quelques jours on parle beaucoup d’une nouvelle forme d’attaque informatique qui sort des approches « habituelles » et qui laisse présager de nombreuses fuites de données dont beaucoup ne seraient pas détectables. Nous vous proposons de lire l’article de David Monniaux  publié sur  son blog personnel. David Monniaux est Directeur de recherche au CNRS et travaille au sein du laboratoire VERIMAG (CNRS, Université de Grenoble).
    binaire

    Les réseaux sociaux et les blogs spécialisés en sécurité bruissaient de rumeurs depuis une semaine (pourquoi des modifications si urgentes dans le système de gestion de mémoire du noyau Linux, alors que d’habitude il faut des mois et des mois pour que le moindre changement soit accepté ?). Comme d’habitude lorsque des trous de sécurité majeurs sont découverts, ceux-ci n’étaient documentés que sous embargo, c’est-à-dire qu’on a d’abord informé les industriels ou groupes de développeurs susceptibles de fournir des correctifs, en leur laissant un délai suffisant, avant de publier les articles décrivant les problèmes.

    Il y a en fait deux catégories d’attaques publiées ce jour : MELTDOWN et SPECTRE, qui partagent certaines caractéristiques. J’ai publié un autre billet sur SPECTRE, dont je vais reprendre ici quelques éléments explicatifs. Je vais discuter ici de MELTDOWN, en me basant sur la lecture de l’article décrivant les attaques (Lipp et al., Meltdown). Les attaques MELTDOWN sont celles contre lesquelles Microsoft, Apple et les développeurs de Linux ont intégré des contre-mesures. Je vais tenter de les expliquer à un niveau ne nécessitant pas de connaissances particulières en informatique.

    Dans un ordinateur, un ou plusieurs processeurs exécutent des séquences d’instructions de calcul (additions, soustractions, multiplications, lecture ou écriture de données dans la mémoire). Ce sont ces instructions qui constituent les logiciels : quelle que soit la complexité ou le domaine d’application de celui-ci, ou le langage de programmation utilisé, on en revient toujours à l’exécution d’une suite de petites instructions comme cela.

    On décrit parfois l’exécution de ces instructions de la façon suivante : le processeur lit l’instruction dans la mémoire, la décode (s’agit-il d’une addition, d’une soustraction, etc.), récupère éventuellement dans la mémoire les données dont elle a besoin, exécute l’opération demandée, puis écrit éventuellement son résultat dans la mémoire. C’est ainsi, en effet, que fonctionnaient les processeurs du début des années 1980 (Motorola 68000, par exemple).

    Ce mode de fonctionnement est inefficace : il faut attendre que chaque étape soit achevée pour aborder la suite. On a donc fait par la suite des processeurs qui, bien qu’ils semblent, du point de vue du programmeur, exécuter successivement les instructions, les exécutent en fait comme sur une chaîne d’assemblage automobile (on parle, en terme techniques, de pipeline) : une unité du processeur décode, dès que l’instruction est décodée on la transfère aux unités qui lisent en mémoire qui la gèrent tandis que l’instruction suivante est décodée et que l’opération de calcul de l’instruction précédente est exécutée. On en est même venu à avoir des processeurs qui réordonnent l’exécution de parties d’instruction afin d’utiliser au maximum leurs unités, voire des processeurs qui tentent d’exécuter deux programmes à la fois sur les mêmes unités en tirant parti du fait que certaines sont inoccupées (hyperthreading) ! Ce qu’il faut retenir, c’est qu’il y a de nos jours, dans les processeurs à haute performance (dont ceux des PC portables, de bureau ou serveurs), des mécanismes extrêmement complexes qui essayent, grosso modo, de simuler une exécution « comme en 1980 » alors que ce n’est pas ce qui se passe dans la machine. Voyons certains de ces mécanismes.

    J’ai dit plus haut qu’il fallait souvent chercher dans la mémoire de la machine (la RAM) les données nécessaires à l’exécution d’une instruction. Or, l’accès à la RAM prend du temps, beaucoup plus que l’exécution d’une instruction : cet écart entre la vitesse d’exécution des instructions et le temps nécessaire pour obtenir une donnée de la RAM a crû au cours du temps. Pour compenser, on a intégré dans les processeurs des mécanismes de mémoire cache qui, grosso modo (c’est en réalité bien plus compliqué) retiennent dans le processeur les données accédées les plus récemment et évitent le trajet vers la mémoire si la donnée recherchée est dans le cache.

    Par ailleurs, les processeurs intègrent des mécanismes de protection de la mémoire, qui isolent les applications les unes des autres et isolent le système d’exploitation des applications. Ils évitent qu’un banal bug dans, par exemple, un traitement de textes, provoque des dysfonctionnements dans le système d’exploitation, avec possibilité de panne plus large que l’application défectueuse et pertes de données. Le déclenchement de ces mécanismes dans une application utilisateur se manifeste généralement par la fermeture autoritaire de celle-ci par le système d’exploitation et l’affichage d’un message d’erreur (« faute générale de protection » sous Windows, « erreur de segmentation » sous Linux…).

    Ces mécanismes de protection de la mémoire servent également à la sécurité, puisqu’ils permettent d’isoler les uns des autres les utilisateurs de la machine. Ceci est bien évidemment d’une extrême importance quand cette machine fait cohabiter des utilisateurs très divers, par exemple un serveur utilisé par les étudiants d’une université, encore plus lorsqu’il s’agit d’un serveur de cloud computing, c’est-à-dire d’une machine située chez un prestataire (OVH, Microsoft Azure, Amazon Web Services…) où des clients sans aucun rapport les uns avec les autres louent la possibilité de lancer des applications.

    L’attaque MELTDOWN est possible parce que dans certains cas, sur certains modèles de processeurs, notamment du fabricant Intel, le processeur commence à exécuter des instructions dépendant d’un accès mémoire illégal avant de se rendre compte de l’illégalité de celui-ci. Bien entendu, il ne s’agit pas d’une erreur aussi naïve que d’autoriser la récupération directe d’une donnée qui devrait rester protégée : lorsque le processeur s’aperçoit de l’erreur de protection, il rétracte l’opération illégale ainsi que celles qui dépendaient de lui. Or, et c’est le même phénomène qui est exploité dans les attaques SPECTRE, cette rétractation est imparfaite : si des instructions qui ont commencé d’être exécutées avant d’être rétractées ont provoqué des chargements dans le cache, les données ainsi chargées dans le cache y restent. Il est ensuite possible d’y détecter leur présence par des moyens indirects (la présence ou l’absence de certaines données dans le cache produit des différences de temps d’exécution qu’il est possible de mesurer). J’ignore pourquoi ces processeurs ne commencent pas par vérifier la protection avant de lancer les chargements dans le cache. L’article dit que c’est peut-être pour des raisons d’efficacité.

    Quelles conséquences de l’attaque MELTDOWN ? Dans certaines circonstances (cela dépend des mécanismes précis de protection), un simple utilisateur peut lire le reste de la mémoire de la machine, y compris la mémoire du noyau et celle des autres utilisateurs, accédant à toutes les données y compris sensibles (mots de passe). C’est donc une attaque particulièrement gênante pour les prestataires de cloud computing (mais, dans leur cas, sa possibilité dépend du mécanisme technique d’isolation des utilisateurs les uns des autres, car tous ne sont pas vulnérables), ou pour les gestionnaires d’environnements avec un grand nombre d’utilisateurs ayant le droit de lancer des logiciels de leur choix (universités, entreprises). Dans le cas de machines personnelles, elle ne permet qu’une escalade de privilège : l’individu malveillant doit déjà trouver un moyen de lancer un logiciel de son choix sur cette machine, et ensuite seulement peut exploiter la faille pour obtenir l’accès à des données auxquels ce logiciel ne devrait pas déjà avoir normalement accès ; cela me semble un problème plus limité.

    Comment pallier l’attaque MELTDOWN ? Microsoft (Windows), Apple et les développeurs de Linux ont des solutions. Bien évidemment, seule celle de Linux est documentée : elle consiste à « cacher » totalement la mémoire du système d’exploitation aux applications, au lieu de, comme actuellement, l’exposer mais avec l’indication « cette mémoire est protégée et n’est accessible que par le système d’exploitation ». Cela implique qu’à chaque fois que le système d’exploitation sera appelé par l’application, celui-ci change la « carte mémoire » utilisée, et devra la changer à nouveau dans l’autre sens au retour dans l’application. Ceci a bien entendu un coût, les applications faisant beaucoup appel au système d’exploitation (on parle de 30 % d’efficacité en moins pour des bases de données) étant plus fortement touchées que celles qui font juste des calculs en mémoire. Une rectification du matériel serait bien entendu préférable, mais implique probablement de changer le parc informatique existant.

    David Monniaux, Directeur de recherche au CNRS

  • Des ordinateurs au-dessus des attaques

    On l’a déjà raconté dans Binaire, le monnaie cryptographique bitcoin est une révolution. Ce qu’on mesure moins c’est que les principes utilisés pour la faire fonctionner ont introduit des idées qui vont bien au-delà de l’intérêt qu’il y a à disposer d’un système de paiement sécurisé ne s’appuyant sur aucune autorité centrale. C’est ce que nous raconte Jean-Paul Delahaye.

    Le fonctionnement du bitcoin a fait entrevoir la possibilité d’une nouvelle classe d’ordinateurs aux propriétés étonnantes : ils ne pourront être compromis par aucune attaque, leurs calculs seront fiables à un degré bien supérieur à tout ce qu’on connaît, et toute personne disposant d’un accès à Internet pourra les utiliser. Le seul inconvénient de ces nouvelles machines sera leur lenteur et leur mémoire réduite comparée à celle de nos machines de bureau ou même de nos smartphones. Cependant, si sacrifier un peu de la vivacité de nos machines et réduire leurs fantastiques capacités de stockage d’information conduit ces nouvelles venues à être bien plus robustes, alors des champs d’applications innombrables leur seront ouverts.

    Ces machines que nous appellerons — on va voir plus loin pourquoi — « machines à blockchain » ne sont localisées nulle part et n’existent que dans le réseau. Elles s’appuient sur des protocoles d’échanges de messages entre ordinateurs usuels fonctionnant sur des schémas de réseaux pair à pair (c’est-à-dire sans nœud central détenteur de droits particuliers). Leur force vient du consensus nécessaire à chaque opération qu’elles exécutent. Leur mémoire, la blockchain, se construit page par page — block par block — sans jamais que rien n’y soit effacé, et c’est un fichier numérique qui existe en milliers d’exemplaires identiques… comme notre génome qui se trouve présent dans chacune de nos cellules. Les pages de la blockchain sont liées les unes autres par un procédé numérique qui les solidarise aussi fermement que les anneaux d’une chaîne (d’où le nom blockchain). La multiplication du fichier des données centrales de la machine la rend incorruptible : si l’une des copies de la blockchain est perdue, il reste toutes les autres. Les calculs de cet ordinateur sont eux aussi faits des milliers de fois sur des milliers de machines (ordinaires) différentes qui se contrôlent les unes les autres et qui sont disséminées sur la terre entière, travaillant prudemment et sans hâte car se coordonnant sans cesse et n’avançant que lorsqu’il y a consensus. La redondance de l’information et du calcul interdit toute erreur, ou plutôt la rend si improbable qu’on peut confier à ces machines à blockchain multiples et auto contrôlées des tâches inconcevables sur une machine isolée toujours susceptible d’être attaquée, défaillante ou isolée du réseau.

    Blockchain.info_logo_2014-01-27blockchain.info

    La première de ces tâches à l’origine de leur conception a été la création d’une sorte de monnaie, entièrement numérique qui vaut aujourd’hui environ 3 milliards d’euros, le bitcoin. Les volontaires qui donnent une partie de la puissance de leur machine pour participer à ces ordinateurs collectifs, redondants et disséminés se nomment des mineurs dans le cas de la machine à blockchain du bitcoin et c’est sans doute le nom qui leur sera appliqué pour toutes les machines de cette nouvelle classe, dont on commence à comprendre le potentiel général.

    Parmi les disciplines qui ont rendu possible cette nouvelle génération de calculateurs, n’oublions pas de mentionner les mathématiques de la complexité.  En effet, la gestion coordonnée des opérations de ces machines sécurisées et la préservation de leur mémoire sont fondées sur des primitives cryptographiques qui interdisent toute corruption du fichier principal (la blockchain), toute manipulation frauduleuse de ce qu’elles font, mais aussi tout oubli de ce qu’elles ont déjà fait. Ces ordinateurs ne peuvent pas effacer leur mémoire qui témoignera sans limitation de temps de tout ce qu’ils auront fait depuis le premier jour de leur fonctionnement — le 3 janvier 2009 pour la machine du bitcoin. La conception théorique de ces machines s’appuie de manière essentielle sur les progrès de la cryptographie mathématique qui se fonde elle-même sur la théorie de la complexité de l’informatique. Ces deux théories ont depuis 40 ans, mis à la disposition de tous, des fonctions sûres réalisant parfois ce qu’on considérait impossible. Parmi ces opérations, il y a :

    • la signature des messages : pas d’usurpation possible de l’identité de celui qui écrit sur la blockchain ;
    • le chiffrage des données quand il est nécessaire : le bitcoin n’utilise pas ce type de secret, mais d’autres ordinateurs à blockchain en ont besoin ;
    • le calcul d’empreintes ; c’est ce qui permet d’avoir la certitude qu’on ne change aucun bit d’information dans un fichier, et on utilise cette fonction pour attacher les pages d’une blockchain comme les anneaux d’une chaîne ; et
    • les « preuves de travail » qui assurent qu’un contenu en calcul (un long travail impossible à accélérer)  est déposé dans un fichier ; ce contenu rend impossible la contrefaçon d’une blockchain.

    Ces calculateurs décentralisés et redondants se multiplient aujourd’hui : il en existe déjà plusieurs centaines, pour l’instant presque tous inspirés de près de celui du bitcoin et utilisés pour gérer des crypto-monnaies concurrentes. Cependant on en étend les possibilités — projet Ethereum —, on apprend à les faire interagir entre eux par la méthode des sidechains  qui autorisent la circulation de l’un à l’autre des informations et des devises numériques. On imagine toutes sortes de nouvelles applications : système de messagerie ; votes sécurisés sans aucune possibilité de tricherie ; contrats sans tiers de confiance ; systèmes de séquestre permettant de déposer de l’argent sur la blockchain par exemple en attendant qu’un engagement soit tenu ; dépôt de messages chiffrés ; systèmes d’horodatage pour déposer des brevets ou des preuves d’antériorité  infalsifiables sans avoir à faire appel à une autorité centralisée,  etc.

    Comme nous l’indiquions au début, la redondance a comme prix une moindre vitesse de calcul et une plus faible capacité de stockage d’information. Nick Szabo (le concepteur probable du bitcoin ; il ne le reconnaît pas, mais de nombreux indices convergent vers l’idée qu’il est Satoshi Nakamoto le signataire du document à l’origine du bitcoin) a évalué cette perte à un facteur 10 000, ce qui paraît énorme. Cependant, n’oublions pas que la loi de Moore énonce une multiplication par 10 des performances moyennes des dispositifs informatiques tous les cinq ans. Elle a été vérifiée en gros depuis 40 ans produisant un gain de performance supérieur au million. La perte de performance des machines a blockchain leur laisse donc une capacité comparable à nos machines de 1990… que nous ne trouvions pas ridicules à l’époque ! Pour de nombreux problèmes, on acceptera de faire un sacrifice sur la virtuosité computationnelle et informationnelle d’un ordinateur en échange d’une sécurité améliorée et rendue presque parfaite. Les calculateurs classiques resteront dominants bien évidemment, mais les nouveaux venus dans les domaines où la confiance est centrale seront peut-être les seuls à pouvoir faire face.

    Gageons que ces machines à blockchain vont changer quelques habitudes et forcer à revoir le train-train de l’informatique contemporaine — particulièrement dans le monde bancaire et financier. Car personne ne peut nier que ce qui est proposé aujourd’hui est incapable de garantir la sécurité que chacun attend, comme la récente affaire Sony l’a montrée, une affaire parmi cent autres.

    Jean-Paul Delahaye, Professeur, Université de Lille 1

    Pour aller plus loin