Brevets logiciels : pas de garantie d'infaillibilité !
La brevetabilité d'un concept ou d'une méthode apporte-t-elle toutes les garanties sur son efficacité? Dans certains cas, une confiance aveugle accordée à un brevet peut mettre en péril toute une organisation, ou un système d'information. Un chercheur de l'INRIA, François Letellier, vient de mettre en évidence qu'un algorithme d'authentification, tout breveté qu'il soit, et bien que proposé au secteur bancaire, peut être « cassé ». Ce chercheur est affecté par l'INRIA (Institut National de Recherche en Informatique et Automatique) au comité exécutif d'un consortium dénommé
ObjectWeb. Ce dernier, co-fondé et hébergé par l'INRIA, a pour objet de regrouper des sociétés et des membres individuels qui collaborent pour le développement de logiciels d'infrastructure distribués (ou « middleware ») en Open Source. ObjectWeb compte plus de 50 sociétés membres, dont Bull, France Télécom, Dassault Aviation, Thales, Red Hat. Les aspects sécurité sont une facette importante du « middleware ». Ses travaux s'inscrivent dans un contexte d'actualité: le débat sur la brevetabilité du logiciel. Les praticiens du logiciel Open Source sont préoccupés par l'impact que pourrait avoir une directive européenne ouvrant la voie à une brevetabilité large des inventions mises en ?uvre par ordinateur sur le phénomène du logiciel libre et sur son potentiel d'innovation. Les conditions d'un brevet européen L'étude menée par F.Letellier porte sur le brevet européen n° EP 0 810 506 B1. Ce brevet concerne une invention mise en ?uvre par ordinateur, à savoir un mécanisme d'authentification forte permettant la non répudiation. Il décrit un système mettant uniquement en ?uvre des calculateurs ordinaires (ordinateurs) et des canaux de transmission banals (disquette, Internet). Le texte du brevet précise qu'il « ne nécessite pas de modifier la structure déjà existante des micro-ordinateurs personnels utilisés » et qu'il « fait appel à un support d'authentification connu ». La seule innovation réside dans l'algorithme cryptographique proposé. Ce brevet a donc tout d'un brevet logiciel. Cela mérite d'être souligné, car aux termes de la directive européenne sur les brevets (art. 52c), les «programmes d'ordinateur» ne sont pas censés être brevetables. L'enregistrement de tels brevets démontre que la directive en vigueur est facilement contournée et que l'OEB fait preuve de complaisance vis-à-vis de la brevetabilité d'algorithmes, dès lors qu'ils sont présentés en situation. La question de la fiabilité Lors d'une présentation le 26 avril dernier, F. Letellier a insisté sur le fait que l'étude porte exclusivement sur le texte du brevet, à l'exclusion de tout autre élément. En particulier, aucune opération de « décompilation » ni aucune attaque contre des systèmes informatiques n'a été menée. Il précise également que les conclusions de l'étude ne concernent ni des produits commerciaux, ni des sociétés, mais seulement le brevet concerné. « Il est important de comprendre que la question n'est pas ici de savoir si tel ou tel produit est fiable ou non. Il est tout à fait possible que des produits commerciaux de très bonne qualité exploitent le brevet. La question est de savoir quel est l'apport du brevet. Ici, la conclusion est simple : sur la base du texte du brevet, rien ne permet de penser qu'un système exploitant le procédé est fiable. » explique F. Letellier. Le procédé décrit ici repose sur le principe de l'authentification par défi / réponse. Supposons que deux personnes, Alice et Bob, conviennent d'un code secret. Alice génère une matrice aléatoire. Puis, elle effectue sur cette matrice une opération de décalage paramétrée par le code secret. La matrice décalée est transmise à Bob par un moyen fiable. Le texte du brevet propose des modes de réalisation dans lesquels la matrice soit stockée, par exemple, sur un CD-ROM et le code secret échangé par courrier postal recommandé. Lorsqu'elle a besoin d'authentifier un correspondant, Alice lui envoie un certain nombre de « défis », constitués de couples de coordonnées ligne-colonne de cases de la matrice. Bob retourne les bonnes réponses, calculées à partir de la matrice décalée et du code secret. Si les réponses correspondent au contenu des cases demandées, Alice authentifie Bob. La sécurité du procédé réside dans le fait qu'il est impossible à un tiers, disons Oscar, de fournir les bonnes réponses uniquement avec la matrice décalée. Le scénario du piratage La question suivante se pose alors: supposons qu'un individu mal intentionné (Oscar) s'empare de la matrice et écoute un certain nombre de couples défi/réponse échangés entre Alice et Bob? Ce scénario n'a rien d'aberrant, puisque le texte du brevet propose des modes de réalisation (CD-ROM, Internet) qui ne protègent ni le canal de transmission ni la matrice décalée. Il est démontré ici qu'à partir de ces éléments, Oscar peut retrouver le code secret. Mieux: par des attaques heuristiques très efficaces, il va être possible de « casser » le code secret en des temps record, disons quelques minutes avec du matériel d'amateur. Un programme simple de quelques lignes a été réalisé pour valider la possibilité d'une telle attaque. Certes, ce brevet n'est pas stupide, ni inintéressant. Mais il propose une méthode qui n'est pas suffisante pour garantir les propriétés revendiquées. Un système reposant sur ce brevet pourra atteindre un haut niveau de sécurité, s'il s'appuie sur d'autres moyens de protection des transmissions et/ou des secrets. La caution du brevet risque donc d'endormir la vigilance d'exploitants d'inventions mises en ?uvre par ordinateur. Alors qu'un industriel ferait certainement peu confiance à un procédé cryptographique nouveau, le fait de s'appuyer sur une méthode brevetée pourra, pour le décideur non technicien, donner du crédit à un système pourtant perclus de failles de sécurité. En cas d'intrusion réussie et non détectée, la caution du brevet peut s'avérer particulièrement néfaste pour l'utilisateur de bonne foi dont on aura usurpé l'identité. Comment plaider sa bonne foi face à un tribunal, alors que l'on se voit opposer la capacité de non répudiation d'un système breveté ? En conclusion, cette étude met en évidence les risques d'une confiance « aveugle » accordée aux brevets en matière de sécurité informatique. La révision paritaire, telle que pratiquée par le monde de la recherche ou les créateurs de logiciels open-source, apparaît indispensable pour les systèmes susceptibles d'utilisations critiques comme la cryptographie. L'absence de travaux antérieurs signifie-t-elle « invention », ou « fausse bonne idée » ? Il est très probable qu'un procédé tel que celui étudié n'ait jamais fait l'objet de publication non parce qu'il est radicalement innovant, mais parce que des cryptographes sérieux auront très vite détecté son manque d'intérêt. L'argument du nombre ne tient pas non plus! De même, le nombre de brevets déposés n'est pas plus un indicateur de mesure d'innovation. Cette notion est de première importance pour des organismes de recherche comme l'INRIA, qui sont évalués sur leurs publications, mais aussi de plus en plus sur le nombre de brevets déposés. Puisque le logiciel est à ce jour exclu du champ du brevetable, les chercheurs en informatique sont injustement défavorisés dès lors que leur productivité est évaluée sur le nombre de brevets. Le processus de révision de l'OEB (Organisation Européenne des Brevets) n'a pas mis en lumière les faiblesses du procédé ici étudié. Faute d'être confronté au monde réel, il est très difficile de prouver la conformité du logiciel aux propriétés revendiquées. Des méthodes formelles pourraient être employées, mais cela semble encore hors d'atteinte dans l'état actuel de la technique. Sur l'exemple de cette étude, François Letellier propose alors un critère pour évaluer le côté « logiciel » d'une invention. Serait réputée « logicielle » une invention dont le fonctionnement peut être confirmé ou au contraire réfuté sans qu'il soit besoin de mener d'expériences matérielles. Puisqu'il semble y avoir consensus sur le fait que le logiciel reste hors du champ du brevetable en Europe, de telles inventions devraient en particulier en être exclues.
Sur le même thème
Voir tous les articles Cybersécurité