Qui nous protégera des logiciels tricheurs ?

Il aura donc suffi d’un petit logiciel perdu dans les centaines de milliers de lignes de code qui font désormais fonctionner nos voitures pour faire vaciller un géant mondial de la construction automobile. Quelques lignes de codes capables de modifier le calculateur moteur, permettant de réduire les émissions de gaz polluant d’un véhicule, uniquement lorsque celui-ci est soumis aux conditions très spécifiques des tests, comme l’explique dans son article de synthèse LeMonde.fr. Les conditions très établies et très spécifiques des tests (accélération lente, vitesse moyenne très faible, capot ouvert…) comme l’évoquait Thibaut Schepman pour Rue89 créent autant de conditions permettant au calculateur de la voiture de reconnaître s’il est en phase de test lui permettant d’adapter sa puissance et ses émissions en fonction. Car pour moins polluer, la voiture doit surconsommer.

jesuistonair
Image : détournement par Greenpeace France.

L’onde de choc du #Volkswagengate ne cesse d’avoir des répliques. Il est en passe de se transformer en #dieselgate éclaboussant bien d’autres constructeurs automobiles, soulignant toujours plus la contradiction entre deux objectifs contradictoires : la diminution de la consommation d’énergie d’un côté et la réduction des émissions polluantes de l’autre. Deux objectifs antinomiques pour nous aussi consommateurs, qui voudrions des voitures toujours plus sobres et moins chères qu’elles ne peuvent l’être. Un peu comme si entre boire et conduire nous n’arrivions pas à choisir la bonne option.

Pour Alain Girault, directeur de recherche à l’Inria, rapporte Industrie & Technologies, cette histoire est emblématique des transformations du monde automobile de ces dernières années avec l’intégration de plus en plus d’informatique au coeur du véhicule, permettant de réguler et contrôler leurs fonctions avancées. Cette intégration toujours plus poussée de l’électronique, Rue89 en avait très bien montré les implications, en nous racontant l’évolution du métier même de garagiste, où le diagnostic mécanique d’un véhicule se fait désormais entièrement par informatique. Avec une informatisation toujours plus poussée, les bancs de test fournis par les constructeurs ne laissent voir que ce que le constructeur veut bien laisser voir de ses programmes, chaque constructeur étant en concurrence avec l’autre.

Le volkswagengate a bien sûr reposé la double question de l’indépendance des contrôles et de la transparence du code. Si la question de l’indépendance des contrôles est en passe d’être résolue par des mesures d’homologation aléatoires en conditions de conduites réelles, la question de la transparence, pour des questions de propriété intellectuelle, elle, demeure complète. Pour Eben Moglen, avocat de la Free Software Foundation et président du Software Freedom Law Center, grand chantre de la défense du logiciel libre, cet exemple illustre toute la limite des logiciels propriétaires que nul ne peut inspecter, rappelait-il au New York Times. A l’heure où le logiciel est partout, dans les avions, les appareils médicaux, les voitures… nous devons exiger que les logiciels puissent être inspectés, estime Moglen. « Si Volkswagen savait que chaque client qui achète un véhicule avait le droit d’en lire le code source, ils n’auraient jamais envisagé de tricher ». Pour Wired, Alex Davies explique pourtant que l’Agence de l’environnement américaine (EPA) s’est opposée récemment à une demande de chercheurs réclamant l’ouverture partielle du code des voitures pour qu’il puisse être examiné de manière indépendante, au prétexte que des utilisateurs mal intentionnés auraient pu utiliser cette information pour modifier le comportement de leurs voitures en les rendant plus puissantes au détriment de la réduction de leurs émissions polluantes. Pas de chance, ce ne sont pas les utilisateurs qui ont utilisé cette faille.

Vers une généralisation des logiciels tricheurs ?

Si on ne peut pas les inspecter, alors qui permettra aux logiciels de n’être pas conçu pour tricher ? interroge Daniela Hernandez pour Fusion. Ce n’est pas la première fois qu’un constructeur utilise un logiciel tricheur, rappelle la journaliste en évoquant les démêlés de Ford avec l’EPA en 1998. Pour Anna Stefanopoulou, ingénieure en mécanique à l’université du Michigan, désormais, « la plupart des unités de contrôle du moteur disposent du matériel et du logiciel nécessaire pour contourner ou modifier la stratégie réglementaire ».

A l’heure où tous nos appareils électroniques embarquent du logiciel, le problème des logiciels tricheurs risque surtout d’empirer, suggère la journaliste. Et si nul n’a accès au code, qui pourra se rendre compte de ce que font nos machines ? Ryan Calo, de l’université de Washington donne un exemple un peu extrême, mais parlant. Demain, les entrepôts robotisés d’Amazon pourraient se réorganiser à la volée pour respecter les exigences du code de prévention des incendies lors d’un préavis d’inspection. N’est-ce pas d’ailleurs ce que font les humains quand une inspection déboule ? Les robots pourraient mémoriser une liste de points de contrôle pour répondre aux normes quand il y en a besoin. C’est d’ailleurs tout le problème des machines à voter et des machines à sous, estime Calo : comment être sûr que leur fonctionnement respecte leurs obligations ?

A mesure que nos vies s’informatisent, nous devenons toujours plus vulnérables à la fraude numérique. Pour Bart Selman, spécialiste de l’Intelligence artificielle à l’université de Cornell, d’autres domaines sont encore à risque, comme le monde médical, l’assurance ou la finance, où le secret et la confidentialité des contraintes rendent encore plus difficile la détection des actes répréhensibles. Pour lui, nous devons exiger de nouvelles règles pour contraindre les ingénieurs logiciels à être responsables de leurs actes, explique-t-il en invitant à introduire des procédures éthiques pour que les algorithmes rendent compte de leurs effets. « A mesure que les objets du quotidien deviennent plus intelligents et plus connectés, nous allons avoir besoin de nous inquiéter de manquements de plus en plus nuancés à la loi », rappelle encore Calo.

Le problème, estime Daniela Hernandez est que les agences de contrôle ne disposent pas toujours de l’expertise nécessaire ni des moyens pour vérifier tous les logiciels qui referment chaque jour un peu plus leurs rets sur nous. Calo a suggéré de créer une agence fédérale de la robotique chargée de superviser ces questions logicielles. En attendant d’ouvrir les modèles, suggère Daniela Hernandez, la meilleure solution pour les citoyens et les militants consiste à construire « des machines pour surveiller les machines », de construire une rétroingénierie des systèmes techniques. Plus facile à dire qu’à faire quand on ne peut accéder ni aux données ni aux logiciels. C’est pourtant bien ce qu’à accompli, là encore, l’ONG à l’origine de la révélation de la fraude de Volkswagen, l’International Council for Clean Transportation, qui a testé les émissions de voitures dans d’autres conditions que celles des tests standardisés avant d’en avertir l’agence de l’environnement américaine. En attendant que le régulateur comprenne la nécessité de favoriser les contrôles, de renforcer les contre-pouvoirs, indépendance et rétroingénierie, sont les deux leviers qui demeurent à notre disposition.

Hubert Guillaud

À lire aussi sur internetactu.net

0 commentaires

  1. De la même façon qu’on doit pouvoir ouvrir le capot de sa voiture pour accéder au moteur, on doit pouvoir accéder au code source des logiciels qui y tournent.

  2. Quelques remarques sur ce problème compliqué :

    – On peut blâmer la fermeture du code, mais on peut aussi explorer d’autres pistes pour s’attaquer au problème. À cet égard, ça serait intéressant de connaître les détails du cas Volkswagen. Première possibilité : la triche est l’oeuvre d’un programmeur isolé. Peu probable : il n’a rien a gagné. Seconde possibilité : le ou les programmeurs coopèrent avec les managers pour tricher. Très risqué pour une entreprise de cette taille. Troisième possibilité : les managers savaient ce qu’ils demandaient aux programmeurs mais les programmeurs n’étaient pas ou peu conscients des conséquences. Ça me semble assez vraisemblable : les spécifications logicielles peuvent être assez abstraites. Programmeur1 implémente « si module A est en mode F, transmettre un paquet de type H1 sur le bus de données », tandis que Programmeur2 implémente la fonctionnalité « s’il y a un paquet H1 sur le bus, stopper le module G ».
    Cela étant dit, je ne sais pas comment résoudre ce problème, mais par exemple « affecter les programmeurs à des modules différents tous les 6 mois » ou « avoir un technicien au courant de tous les modules » pourrait faire partie d’une norme ISO certifiée par audit.

    – Je suis entièrement pour l’ouverture du code. Ça me semble être un objectif réaliste dans de nombreux domaines, en particulier là où l’utilisateur est directement impliqué entant qu’individu (par exemple pour une prothèse électronique). Pour les constructeurs automobiles mainstream, ce n’est pas près d’arriver. Premièrement ils peuvent avoir du code innovant à protéger, et il y a déjà assez de brevets pour ne pas en rajouter une couche. Deuxièmement, je doute que les propriétaires de Volkswagen se sentent concernés par les émissions polluantes de leur propre véhicule. On ne peut pas s’appuyer sur eux pour vérifier le code.
    Il serait peut-être plus réaliste de demander aux fabricants de fournir au public les spécifications des interfaces d’entrées/sorties pour permettre d’improviser des tests facilement.

  3. L’argument de pouvoir inspecter pour savoir si le logiciel triche ne tient pas. Il y a bon nombre de logiciels open source et/ou libres dont personne ne sait ce qu’ils font car vu le nombre de lignes de code personne n’est capable de les lire. Genre OpenSSL dont on découvre de nouvelles failles régulièrement alors qu’il est censé être sur-inspecté (et ce ne sont pas des failles récentes).

  4. @Hadrien : il faudra un peu de temps pour connaître les détails de ce qu’il s’est passé chez Volkswagen et la chaîne de responsabilité… Mais plus les détails sortent, plus ta troisième solution semble aussi improbable que la première : http://www.lepoint.fr/automobile/affaire-volkswagen-le-logiciel-de-trucage-fourni-par-bosch-27-09-2015-1968420_646.php

    Sur l’ouverture du code, bien sûr qu’elle n’est pas une réponse magique et qu’elle demande d’être explorée plus avant pour mieux comprendre sous quelles modalités cette proposition peut avancer. L’accès au code ne va pas faire que demain, tout le monde va pouvoir le corriger. Mais, pour répondre également à Michel, qui aurait découvert les failles d’un CloseSSL 😉 ? On peut bien plus facilement tricher si tout est protégé que le contraire.

    Le spécialiste de la sécurité informatique, Bruce Schneier, qui vient de publier un billet sur le sujet, ne dit pas autre chose. Il souligne que les logiciels permettent de tricher d’une manière nouvelle, plus subtile et plus difficilement repérable – surtout qu’elle peut souvent se faire passer pour un bug, que comme une fonctionnalité. Le logiciel rend les malversations plus faciles à commettre et plus difficiles à prouver.

    Pour lui aussi, nous devons nous doter de moyens de vérifier, de contrôler, de rendre le code disponible pour analyse. La transparence ne suffit pas, comme le montre les limites la question de l’open source, il faut la coupler à l’analyse. A mesure que le logiciel investit des applications critiques, nous devons pouvoir les contrôler.

  5. Dans son excellent et très pédagogique petit livre sur les algorithmes (A quoi rêvent les algorithmes), le sociologue Dominique Cardon estime qu’il est vain de demander que soi levé le secret des algorithmes, du fait qu’ils révisent sans arrêts leurs variables. Pour lui, il est plus utile de connaître les flux des données qui « entrent » dans la composition du calcul (les critères) et les objectifs que ceux qui fabriquent ces machines auto-apprenantes leur demandent (passer plus de temps sur FB, favoriser le déclenchement d’un second achat après un premier, etc.).