Description

Brice Minaud, cryptographe, répond aux questions de Lorenzo Jacques dans ce cent-deuxième épisode du podcast Interstices. 

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

• Speaker #0

  Technologie, science, algorithme,

• Speaker #1

  simulation,

• Speaker #0

  congé, informatique.

• Speaker #1

  Lorsqu'il s'agit de nos données, ça l'est d'autant plus lorsqu'il s'agit de données d'entreprises ou d'États qui gèrent des données particulièrement sensibles. Pour comprendre comment on protège des bases de données en ligne, mais surtout pour parler de ces recherches, je reçois aujourd'hui Brice Minot. Brice Minot, bonjour.

• Speaker #0

  Bonjour Lorenzo.

• Speaker #1

  Brice Minot, vous êtes chercheur en sciences du numérique et cryptographe au sein de l'équipe Cascade du centre INRIA Paris, et vous êtes également le porteur du projet de l'ANR SafeEd qui vise à la conception de bases de données sûres et fonctionnelles. Brice Minot, on l'a dit. Nous utilisons déjà dans la vie de tous les jours des bases de données qui sont en ligne. Comment ces systèmes peuvent-ils fonctionner alors que nous ne sommes pas sûrs de la sécurité de ces bases de données ?

• Speaker #0

  Je pense que pour répondre à cette question, il faut séparer deux aspects. Il y a d'une part la fonctionnalité et d'autre part il y a la sécurité. Si on ne se préoccupe pas de sécurité, on peut concevoir des systèmes qui ont les fonctionnalités qu'on souhaite. Et souvent, la sécurité est conçue après coup pour protéger ces systèmes-là.

• Speaker #1

  On reçoit beaucoup de préconisations sur la manière de sécuriser ces données, notamment sur le choix des mots de passe. Il faut utiliser des mots de passe différents pour chacun des services, il faut y mettre des chiffres, des lettres en majuscule, des symboles. Est-ce que vous respectez ces préconisations ?

• Speaker #0

  La réponse franche, c'est non. Et la réponse un peu plus détaillée, c'est pour les systèmes, donc je veux dire, qui sont vraiment importants pour ma sécurité. Par exemple, ma boîte mail, je les respecte complètement. Parce que quelqu'un qui a accès à votre boîte mail, par exemple, il pourrait se connecter à votre place, demander de créer un nouveau mot de passe ou dire qu'il a perdu votre mot de passe et le faire envoyer sur votre boîte mail. Votre boîte mail, c'est à la fois toutes vos données personnelles, et c'est aussi quelque chose, c'est une porte d'entrée à tous les services que vous utilisez. Donc pour quelque chose comme ça, je pense que c'est très important. Pour votre banque aussi, je pense que c'est important, par exemple. Maintenant, un service que vous utilisez, vous vous connectez une fois pour créer un compte, pour faire je ne sais pas quoi, bon, là, j'avoue que je ne vais pas créer un mot de passe dédié pour ça. Donc voilà, il y a quand même des endroits où je pense que c'est réellement important de faire attention, et puis il y en a d'autres, bon, c'est un petit peu moins important.

• Speaker #1

  On imagine souvent cette image d'épinal du hacker à capuche, seul devant son ordinateur. Est-ce que ça correspond aujourd'hui à une réalité ?

• Speaker #0

  Je pense qu'on peut voir la sécurité informatique comme un grand paysage où il y a toutes sortes d'acteurs différents. Et ces acteurs sont composés de toutes les entités qui ont un intérêt dans la sécurité ou la non-sécurité de certaines structures. Donc parmi ces attaquants, il peut y avoir des gens isolés comme l'image d'Epinal que vous évoquiez. Il y a aussi les acteurs étatiques. Il y a des grandes entreprises pour qui vos données ont une valeur même financière. Donc il y a un grand nombre d'acteurs différents qui interagissent tous ensemble et dont les rechercheurs font aussi partie en fait, puisque nous on essaye de trouver des solutions. ou d'analyser les attaques, et qui ont tous des intérêts un petit peu différents. Et je pense que l'accord que vous avez évoqué au début n'est pas forcément irréaliste, c'est un des acteurs, peut-être pas le plus important, mais c'est un des acteurs qui existe et il y en a beaucoup d'autres. Il y a différents modèles de menaces contre lesquelles on peut vouloir se protéger. Celles où toutes sortes d'acteurs malicieux peuvent vouloir attaquer les serveurs qui contiennent les données et exfiltrer ces données. Il y a un autre modèle d'attaquant auquel on pense peut-être moins, c'est celui... où vous stockez vos données, par exemple vous utilisez WhatsApp, vous utilisez toutes sortes de services auxquels vous confiez vos données, et ces services pourraient vouloir déduire des informations sur vos données. Alors, pour se protéger contre ça, il y a une technique simple qui est de chiffrer les données, mais l'entreprise pourrait vouloir déduire des informations sur vos données simplement en observant comment vous accédez ou vous manipulez ces données, même si elles restent chiffrées.

• Speaker #1

  Et donc un des buts de la NRSFED, c'est de proposer des systèmes qui peuvent être sécurisés même quand le serveur lui-même n'est pas digne de confiance.

• Speaker #0

  Oui, c'est tout à fait ça. Et non seulement ça protège contre ce scénario-là, mais en fait ça protège aussi contre le premier. Parce que si même le serveur qui voit tout ce que vous faites, toutes les données que vous déposez dessus, lui n'est pas capable d'inférer quoi que ce soit sur vos données, à fortiori, des attaquants extérieurs qui pirateraient le serveur et qui voient forcément moins que ce que voit le serveur seraient encore moins capables de le faire. C'est une exigence de sécurité qui est plus élevée.

• Speaker #1

  En quoi est-ce que ça consiste concrètement ? Comment est-ce qu'on fait de la recherche en sécurité informatique et en cryptographie ?

• Speaker #0

  C'est un sujet qui est très actif et qui est très grand. Donc il y a un grand nombre de chercheurs qui travaillent dans ce domaine-là. Et comme il y a un grand écosystème qui est déjà bien développé, on a identifié un certain nombre de problèmes. L'un d'entre eux, c'est de protéger les données qui sont stockées dans le cloud. Mais le problème, c'est que vous ne voulez pas seulement stocker des données inertes, vous voulez aussi interagir avec les données. Si vous pensez à un outil de messagerie, un grand nombre d'entre eux vous offrent la fonctionnalité que vos messages soient chiffrés de bout en bout. C'est-à-dire que le serveur qui stocke vos messages ne voit jamais vos messages clairs. Néanmoins, il stocke vos messages et peut-être qu'un jour vous voudrez faire une recherche parmi ces messages pour retrouver un message plus ancien. Si vous faites ça, vous ne pouvez pas demander au serveur de faire la recherche parce que pour lui toutes les données sont chiffrées, elles sont opaques. Donc en fait il y a une sorte de paradoxe, on veut que les données soient opaques pour le serveur mais qu'en même temps qu'il soit capable d'effectuer certaines opérations, par exemple chercher. Et c'est un problème qui est très important parce que dès que vous voulez stocker des données dans le cloud, si vous réfléchissez un peu, dans quasiment tous les cas vous voulez interagir avec elles. Si vous êtes un hôpital qui stocke les données de vos clients, vous êtes contraints par la loi que le serveur externe qui stocke vos données n'apprenne rien sur vos patients, mais vous voulez pouvoir faire des recherches sur votre base de données de clients. Donc SyFed, dans ce cadre-là, ça s'intéresse à la question de faire des recherches sur les données, qui est peut-être la fonctionnalité la plus simple, la plus immédiate que vous voulez réaliser, mais qui est en fait déjà très difficile.

• Speaker #1

  Comment est-ce qu'on peut résoudre ce problème ? Est-ce que le but, c'est de chiffrer les données de façon à ce qu'elles soient quand même recherchables, même une fois chiffrées ?

• Speaker #0

  A l'intérieur du problème du calcul sur données chiffrées, il y a plusieurs techniques, il y a plusieurs sous-domaines qui existent. Et l'un d'entre eux, c'est exactement ce que vous dites en fait. Il y en a un d'entre eux qui permet de chiffrer vos données, de les stocker sur le serveur, et ensuite le serveur est capable d'effectuer des calculs arbitraires sur vos données, même quand elles sont chiffrées. Donc ça c'est assez extraordinaire. Le problème c'est que pour l'instant, en tout cas aujourd'hui, ça coûte très cher. Et notamment vous ne pouvez pas imaginer des prices sur des bases de données qui font des teraoctets, ou même des gigaoctets. Mais il y a d'autres solutions qui sont plus légères. et qui rentre plus dans le cadre de l'ANR SciFed, qui consiste à faire des compromis entre la sécurité et la fonctionnalité. C'est-à-dire qu'on va accepter que le serveur apprenne quelques informations sur ce que vous faites. En contrepartie, la performance vis-à-vis de toutes ces mesures va être meilleure. Et meilleure de plusieurs ordres de grandeur. On va gagner beaucoup au prix d'avoir une sécurité qui n'est plus parfaite. C'est-à-dire qu'on va autoriser des fuites vers le serveur qui sont limitées, qu'on va définir exactement, mais qui existent.

• Speaker #1

  Et comment est-ce qu'on décide ? quelle fuite est acceptable d'un point de vue de la sécurité et quelle fuite n'est pas acceptable ?

• Speaker #0

  C'est une question qui est très difficile pour plusieurs raisons. Une première raison, c'est que ce qui est acceptable ou non dépend du contexte d'utilisation. Les bases de données, ça apparaît partout. Et suivant les contextes d'utilisation, ce qui est acceptable ou pas comme fuite peut changer complètement. Ça, c'est une première raison. Une deuxième raison, c'est que ce qu'on aime bien en sécurité, c'est qu'on puisse prouver la sécurité de ce qu'on construit. Et donc souvent, ce qu'on va faire, c'est qu'on va dire voilà la fonctionnalité qu'on souhaite remplir. Et on va prouver que notre construction remplit cette fonctionnalité sans rien fuir aux serveurs d'autres que ce qui est nécessaire pour remplir la fonctionnalité. Or là, on sort de ce cadre-là, puisqu'on autorise des fuites qui ne sont pas strictement nécessaires pour la fonctionnalité. Elles sont simplement utiles pour l'efficacité. Et donc on rentre dans un domaine qui est beaucoup plus flou, moins bien balisé. Et donc la vraie réponse, en pratique, comment est-ce qu'on sait ce qui va être acceptable ou pas ? Il faut qu'il y ait des gens qui étudient la sécurité de ces fuites. En particulier qui étudie ce qu'on peut déduire à partir des fuites. Parce que souvent les fuites, si vous les regardez de manière superficielle, peuvent paraître anodines. Par exemple, je vais fuir à quel fichier j'accède. Pas le contenu des fichiers, pas ce que je fais avec, mais simplement que j'accède à tel fichier. Vous pourriez vous dire que ça, ce n'est pas important. Dans certains contextes, rien qu'en observant ce comportement, le serveur va pouvoir déduire tout le contenu de vos données. Comme si vous ne les aviez pas chiffrés. Donc il y a une question qui est, qu'est-ce que le serveur peut déduire à partir de ces fuites ? Et ça, ça demande des études qui peuvent être assez complexes. Donc il y a un domaine de la cryptologie qu'on appelle la cryptanalyse. Un acteur duquel... on va chercher à répondre exactement à ces questions-là. À partir de telles fuites, qu'est-ce qu'on peut déduire ? Et dans quel contexte d'utilisation, c'est acceptable ou non ? Donc c'est un domaine de recherche à part entière. Il n'y a pas de réponse simple qui s'applique à tous les cas. Il faut faire des études.

• Speaker #1

  Est-ce que dans l'analyse de ces fuites, il n'y a pas une question de créativité finalement ? D'être capable d'inventer de nouvelles façons d'utiliser des fuites auxquelles les designers du système n'ont pas pensé à la base ?

• Speaker #0

  Si, je suis tout à fait d'accord avec ce que vous dites. En lumière générale, évidemment, la recherche, c'est une activité créatrice. Mais aussi, en particulier... Une manière de voir des choses, c'est que il y a des exercices ou des problèmes ou des puzzles un peu logiques qui peuvent être amusants à résoudre. Quand vous faites ça, vous êtes en train d'essayer de chercher une solution à un problème qui a été créé pour avoir une solution. Pour moi, la recherche, c'est essayer de résoudre des problèmes qui n'ont pas été créés spécifiquement pour avoir des solutions. On ne sait même pas s'il existe une solution ou pas. La cryptanalyse, c'est-à-dire ce problème d'analyser des fuites, c'est encore pire parce que vous analysez un problème Non seulement vous ne savez pas s'il y a une solution, mais il a été conçu pour qu'il n'y ait pas de solution. Puisque les gens qui l'ont conçu voulaient justement qu'on ne puisse pas déduire d'informations. Donc c'est le cas le plus extrême si on va un peu des puzzles où il y a une solution prédéfinie que vous cherchez. La recherche où il y a une solution, on ne sait pas si elle existe ou pas. Et la cryptanalyse où normalement ça a été conçu pour qu'il n'y ait pas de solution, et vous cherchez à en trouver une quand même. Mais c'est une chose que, personnellement, je trouve très intéressante, qui est assez motivante parce qu'on a l'impression qu'on crée quelque chose justement.

• Speaker #1

  L'ensemble de votre production scientifique doit être mis en ligne et accessible publiquement sur la plateforme HAL. Est-ce que ce n'est pas difficile de concevoir des systèmes sûrs et ensuite d'expliquer comment ces systèmes fonctionnent à tout le monde et donc à des attaquants potentiels ?

• Speaker #0

  A l'origine, la manière dont le domaine était conçu était que le système de chiffrement était secret. Mais en fait, on s'est rendu compte au fil de l'histoire que ce n'est pas un bon paradigme, parce que le système de chiffrement lui-même, à un moment donné, il va tomber aux mains des ennemis. Et donc au lieu de ça, ce qu'on fait, c'est que le système est public, mais le système utilise une clé secrète, et elle ne n'est pas publique. Donc vous décrivez complètement le fonctionnement de vos algorithmes, de la machine à chiffrer, si vous voulez, mais cette machine prend en entrée une information secrète, qu'on appelle généralement la clé secrète, qui elle, est différente à chaque utilisation. et qui va changer. Aujourd'hui, on appelle ça les principes de Kirchhoff parce qu'il a formalisé cette idée qu'il vaut mieux que le système soit public mais que la clé qui est utilisée par le système reste secrète. Une des raisons pour lesquelles c'est plus sain, c'est que quand vous construisez un système par vous-même, c'est très facile de faire des erreurs. En le rendant public, tout le monde peut l'analyser et publier les faiblesses. Ça donne, en fin de compte, des systèmes qui sont beaucoup plus sûrs et dans lesquels on a beaucoup plus confiance. Aujourd'hui, on considère qu'il est nettement mieux de rendre les systèmes publics pour que tout le monde les analyse et qu'on ait une meilleure confiance dans le fait En pratique, il reste que des entreprises ou des États utilisent quand même des systèmes secrets, c'est-à-dire qu'ils essayent de faire les deux, d'utiliser des systèmes qui ont été bien analysés publiquement, mais de les modifier pour avoir un système qui est secret et une clé qui est secrète. Et ça, ce n'est pas dans l'esprit de la recherche publique. Nous, on essaye plutôt que tout soit public. Et que même si tous les attaquants peuvent regarder notre système, ils soient sûrs quand même. C'est ça qui fait qu'on a réellement confiance dans le fait qu'il soit bien conçu.

• Speaker #1

  Les projets de l'Agence nationale de la recherche, ils sont conçus pour durer entre 4 et 5 ans. Là, nous arrivons au bout. Quelles sont les conclusions de votre travail de recherche dans le cadre de l'ANR SciFed ?

• Speaker #0

  A l'origine, SciFed était conçu pour avoir un spectre assez large dans le domaine des bases de données chiffrées. Et en fait, ce qui s'est passé et qu'on n'avait pas prévu au départ, c'est que vers le début du projet, on s'est rendu compte qu'il y avait une question très intéressante qui venait de sortir et qui avait été à l'époque encore assez peu étudiée. Dans le cas des bases de données chiffrées, vous stockez vos informations sur le serveur et vous voulez que ces données soient proches dans la mémoire du serveur. Parce que quand vous allez interroger la mémoire du serveur, vous pouvez les retrouver en même temps. Il se trouve que quand vous accédez la mémoire de cette manière-là sur un ordinateur, c'est beaucoup plus rapide que si vous faites beaucoup d'accès à des endroits aléatoires dans la mémoire. Mais quand vous faites ça, comme le serveur voit à quel endroit de la mémoire du serveur vous accédez, c'est-à-dire qu'il va voir quand vous accédez plusieurs fois des données en mémoire qui sont proches, vous accédez probablement à des données corrélées. Il y a une sorte de paradoxe entre le fait de stocker ensemble des données qui sont corrélées sémantiquement et qui va être bon pour l'efficacité. et le fait de vouloir les séparer, de les disséminer en mémoire, qui va être bon pour la sécurité. Et ce que nous on a fait, c'est qu'on s'est rendu compte qu'en modifiant légèrement la définition d'efficacité pour les disques SSD, les disques flash, ceux que vous avez par exemple sur des clés USB, on était capable d'avoir des systèmes qui étaient optimaux en un certain sens, à la fois pour l'efficacité et pour la sécurité. Comme ça, c'était un résultat que nous on trouvait très intéressant. On s'est beaucoup penché dessus, et on a eu un certain nombre d'autres résultats qui sont dans la suite de celui-là. Donc globalement, par rapport à ce qu'on avait prévu au départ, en fait, on n'a pas exploré tous les axes qu'on voulait. Par contre, on a eu une opportunité qui n'était pas prévue au départ, qui était très intéressante. Mais sur ce problème, on a fait des gros progrès.

• Speaker #1

  Quelle est la prochaine étape ? Est-ce que vous allez demander un autre ANR ?

• Speaker #0

  Je ne vais pas demander un nouvel ANR sur les bases de données chiffrées. Par contre, ce qui est prévu dans la suite de SciFed, c'est que je vais collaborer avec des gens qui travaillent en entreprise et qui cherchent à implémenter et à vraiment réaliser et à déployer dans le monde réel ces systèmes de bases de données chiffrées. Donc ça, c'est très intéressant. Parce qu'une partie de la recherche que j'ai décrite est un peu théorique. Mais à mon sens, c'est important de résoudre d'abord les problèmes théoriques pour en quelque sorte défricher le terrain avant de résoudre les problèmes concrets. La suite du projet va s'orienter plutôt dans la direction de problèmes pratiques et du déploiement de bases de données chiffrées. Donc je vais collaborer avec des collègues qui travaillent dans ce contexte-là. Et donc les problèmes théoriques ne seront pas tout à fait les mêmes, mais ça va être dans la suite de SciFed.

• Speaker #1

  Eh bien, merci beaucoup Brice Minot et à bientôt sur Interstice.

• Speaker #0

  Merci Lorenzo et au revoir.

• Speaker #1

  Chers auditeurs et auditrices,

• Speaker #0

  à la prochaine et n'oubliez pas les sciences du numérique sur Interstice.