 Bienvenue à tous, à la session d'examen du Code et de la cryptographie de l'animérité Épéligie Ursa, présenté par Pierre Auvêche, co-fondateur et directeur général de l'Avoitateur d'identité numérique du Canada, IT Labs. Pierre, je te passe la parole. Merci beaucoup, Kevin. Merci beaucoup. Merci, Kevin, pour l'introduction. Merci à la communauté Hyperledger pour nous donner l'occasion de présenter les résultats de notre examen indépendant du Code et de la sécurité de la bibliothèque Ursa. Comme Kevin l'a mentionné, mon nom est Pierre Auvêche, je suis directeur général et le fondateur du Laboratoire d'identité numérique du Canada. Je tiens à vous informer que cet événement est enregistré et je vous demanderai de garder vos questions à la fin. On va prendre les questions à la fin, s'il vous plaît. Voilà. Alors, lors du jour pour aujourd'hui, on va faire une brève introduction du Laboratoire d'identité numérique. On va faire une brève introduction de Hyperledger et de Ursa. Après ça, on va se concentrer sur la jeunesse, la portée, le processus qui apportait à la mise en place de cette revue de code. Et on va partager avec vous la résumé des conclusions. La rencontre aujourd'hui, c'est vraiment pour les passionnés d'Hyperledger, les praticiens en identité des centralisées ou les personnes qui sont responsables de projets en identité numérique. Je vous invite, il y a un blog qui a été écrit qui va couvrir beaucoup des points qui vont être discutés aujourd'hui. Le code à bord en haut à droite, je vous invite ça point à un blog qui est disponible, qui est un blog francophone. Si vous êtes plutôt un praticien en sécurité des technologies de l'information ou un cryptographe, je vous avertis, je ne suis pas un cryptographe et je crois que vous allez avoir beaucoup plus de plaisir à lire le rapport détaillé qui a été produit, qui a été partagé par le Laboratoire à la communauté et c'est le code à bord, le QR code en bas à droite. C'est un rapport en anglais, c'est un rapport détaillé. Si vous recherchez les détails croustillants et plus au niveau de la cryptographie plus en détail, je vous invite à regarder le rapport détaillé avec lequel on fait suivre en bas à droite. J'ai aussi écrit le lien, mais le code à bord va directement sur le lien qu'on voit là. Alors, c'est ça, juste un instant. Alors, à propos du Laboratoire des identités numériques, le Laboratoire des identités numériques du Canada, c'est une organisation canadienne qui est sans bulle créative qui existe pour promouvoir l'adoption de l'identité numérique. La façon de promouvoir l'adoption de l'identité numérique pour faire progresser la confiance numérique, c'est d'appuyer les efforts de conformité et d'interopérabilité à une identité numérique. Le Laboratoire est technologiquement neutre. On n'est pas un laboratoire diaper ledger, on n'est pas un laboratoire du W3C. Je crois qu'on reconnaît qu'il va y avoir différentes technologies, différents standards qui vont être utilisés dépendant des codes d'utilisation, dépendant des places d'utilisation. Donc, le marché décidera des solutions qui sont les plus appropriées, qui sont les mieux implémentées. Mais le Laboratoire est là pour supporter des efforts de conformité et d'interopérabilité. Ce n'est pas suffisant de dire que notre technologie suit un standard X, Y ou Z. Le Laboratoire est là comme acteur neutre, acteur de confiance pour s'assurer de la conformité de l'implementation. Une formule qu'on voit dans d'autres industries tel que la télécommunication, les paiements. Donc, le Laboratoire d'identité numérique, on est unique sur notre focus en identité numérique, mais la façon, le modèle d'opération, l'offre de services qu'on fait, on le voit dans d'autres industries. Je pense que c'est important de noter que le Laboratoire travaille avec des acteurs du secteur public, des acteurs du secteur privé. On travaille avec les acheteurs de technologiens d'identité numérique. On travaille avec les fournisseurs de technologiens d'identité numérique. Donc, on voit de bout en bout de ce côté-là et on appuie ces efforts-là. Le Laboratoire aujourd'hui, un petit peu plus de deux ans, à peu près deux employés, comme j'ai mentionné, on est base au Canada. Finalement, je veux renforcer le point que le Laboratoire n'est pas un incubateur et on ne développe pas et ne vend pas de solutions d'identité numérique. Alors, je crois que c'est important aujourd'hui de faire une mise en contexte. Probablement que beaucoup d'entre vous sont déjà au courant. Une bonne partie d'entre vous seront au courant, diaper ledger, et de voir ça, qu'est-ce que ça fait. Mais juste au cas où, pour mettre à niveau toutes les personnes qui sont présentes aujourd'hui, je pense que ça pourrait être intéressant et nécessaire de faire une brève introduction de diaper ledger et d'Ursa. Alors, diaper ledger, c'est une pile technologique open source multi-projet qui se concentre principalement sur les technologies de la chaîne des blocs et des outils qui lui sont associés. La technologie diaper ledger, elle est beaucoup utilisée dans des projets d'identité numérique, à travers un nombre de ses sous-projets. On peut en parler tantôt. Ursa, c'est la bibliothèque cryptographique partagée. C'est une bibliothèque référentielle qui est optionnelle pour les différents projets. Mais c'est là qu'on retrouve toutes les fonctions cryptographies de sécurité des différents projets diaper ledger, tels que Indy, Aries, Fabric et autres. Il y a de nombreux avantages d'avoir une librairie module, une librairie partagée pour la cryptographie. On peut penser à plusieurs avantages premièrement, il y a une réduction des doublons. Les implementations de cryptographie sont notoirement difficiles à bien implementer. Donc de le faire juste une fois, de le faire à un endroit, ça devient un petit peu plus facile. D'être capable de partager les implementations de chiffrement en invitant de doubler le travail supplémentaire c'est l'avantage principal de la librairie. Donc pour une seule librairie d'avoir toute la cryptographie à un endroit, ça facilite aussi la revue de code de sécurité. C'est un seul endroit pour à vérifier et ça permet à l'équipe de cryptographie et à l'équipe de sécurité de se concentrer sur la librairie au lieu de toutes les autres lignes de code des différents projets. Finalement, le troisième avantage qu'on peut nous voir, c'est l'interoperabilité multiplatforme. Si on a deux projets qui utilisent la même librairie de chiffrement on simplifie l'interoperabilité entre les plateformes parce que la vérification cryptographique impliquera que les mêmes implementations du protocole aient été faites des deux côtés. Donc ça devient une interoperabilité à l'intérieur des projets Hyperledger ou à l'intérieur des projets qui utilisent cette librairie-là Ursa. Effectivement, d'avoir une librairie de sécurité rend plus facile de démarrer des nouveaux projets. On est capable de réutiliser la librairie pour les aspects de sécurité, d'encryption, d'identification, de protection de la vie privée en identité numérique on va rajouter la divulgation sélective et même les preuves à divulgation nulle de connaissance. Donc, notre beau projet l'adoption d'identité numérique s'accélère à travers le monde. Je pense que c'est clair. Le Canada abrite un certain nombre de projets de ce type-là qui sont dirigés par des organisations autant du secteur public et du secteur privé. La technologie Hyperledger est envisagée dans un grand nombre des projets qu'on voit en déploiement au Canada en partie dans le processus de diligence raisonnable requise pour l'éventuelle utilisation de la technologie Hyperledger en production. On a trois provinces aujourd'hui au Canada qui publiquement ont communiqué l'utilisation de l'adoption de la technologie Hyperledger. On peut penser au gouvernement du Québec. On peut penser au gouvernement de l'Ontario. On peut penser au gouvernement de la Colombie-Britannique. Ces trois provinces-là ensemble je crois représentent plus que 70% de la population au Canada. Donc c'est important. Et au fur et à mesure que ces provinces-là regardent pour travailler sur la technologie utilise la technologie Urso pour appuyer leurs projets en identité numérique ça devenait important d'être capable de garantir que la cryptographie avait été bien faite que les meilleurs pratiques étaient en place dans le développement de cette librairie-là pour assurer la sécurité et la protection de l'information des différentes organisations, même des citoyens. Donc les meilleurs pratiques étaient déjà en place au sein de l'équipe Urso pour garantir un ingénierie de qualité et une sécurité appropriée mais il n'y avait pas d'examins publics indépendants qui avaient été faites. Dans les certaines organisations j'ai mentionné des provinces, c'est aussi une organisation du secteur privé Interac, on voit le logo ici. On retenut les services du laboratoire pour effectuer cette revue de sécurité. Donc le laboratoire et je l'ai mentionné en introduction on est une organisation indépendante technologiquement neutre et le laboratoire a travaillé avec la communauté Urso pour faire une revue de code pour s'assurer que les utilisateurs ou les organisations qui avaient adopté cette technologie pouvaient mettre ça en production. Je vais faire une parenthèse rapide sur le respect de la vie privée dès la conception le Privacy by Design. C'est Anne Kavoukian qui a créé ça. C'est une ontarienne et la raison pourquoi j'en parle notamment le Privacy by Design se reflète dans un nombre croissant des projets des nouvelles initiatives qu'on retrouve au Canada. Et la raison et un autre des aspects de Privacy by Design c'est l'esprit de confiance mais vérification. En anglais on dit trust but verify donc esprit de confiance mais vérification. C'est exactement dans cet esprit que la revue de code s'est effectuée. Il n'y avait pas d'attente on s'attendait pas à trouver il n'y avait pas de problèmes présumés. On ne s'attendait pas à avoir des portes dérobées mais ça fait partie d'une bonne cyber-hygiène de faire cette vérification de soutenir le processus de diligence raisonnable des différentes organisations en faisant la révision de la librairie avant que ceux-ci puissent passer en production. Alors les acteurs impliqués dans la revue les provinces et l'organisation privée tous et chacun donnent une grande valeur à plusieurs des projets d'open source particulièrement les provinces qui voient la danque d'un esprit d'ouverture, un esprit de transparence un esprit de pour dire que nos gouvernements n'ont rien à cacher que si le citoyen l'organisation veut voir comment c'est fait veut prendre avantage de cette technologie-là, ça peut être fait c'est le code il est ouvert. L'autre aspect important un autre des bénéfices que les acteurs voient là-dedans c'est le travail avec une communauté qui partage ces valeurs-là. Donc les provinces ou les acteurs qui ont supporté la revue de code bénéficient des travaux qui ont été fait en open source et veulent redonner à la communauté veulent amène les améliorations au code et amène une certaine une certaine ce que c'est le mot que je cherche une certaine maturité dans l'implémentation et veulent redonner ça aussi à la communauté. Donc dès le début dans cet esprit-là il y a de l'expression de contribution communautaire les commandes-d'études du projet avaient prévu de mettre à la disposition le rapport qui vous est présenté aujourd'hui qui est considéré comme un bien public et pour s'assurer que les résultats profitent à toute la communauté donc je suis très content l'abatture est très contente d'être ici aujourd'hui d'être capable de partager les résultats de la présentation de l'étude. La portée oui c'est ça la portée du code donc la portée premièrement il y a la revue de code je mène liste des différentes façons que ça a été examiné premièrement il y a les points d'entrée c'est une bibliothèque c'est une librairie de fonctions donc beaucoup il y a beaucoup de points d'entrée la partie importante des fonctions sont apportées publiques et aussi qu'il y a des liaisons qui sont également présentes et qu'on est capable de référencier à partir d'un code client juste pour donner des chiffres des points d'entrée il y a des liaisons assez en environ 138 et des liaisons en Rust il y en a au-dessus de 2732 donc ça c'est tout des points d'entrée il y a une revue qui a été analysée pour s'assurer que les meilleures pratiques avaient été suivies pour s'assurer qu'il n'y avait pas de problème de logique je vais continuer avec les autres points on voulait aussi voir les normes de codage on voulait valider et évaluer les normes de codage utilisées pour la mise en oeuvre dans le code il y a une revue de la cryptographie de la gestion des clés sans limiter la génération de pouvoir, la génération des clés les signatures, la vérification l'identification d'éventuelles portes dérobées on a aussi porté la attention au stockage et au transfert de données ça fait partie d'un examen par contre comme c'est une librairie le stockage et le données relèvent habituellement c'est la responsabilité du code client on a regardé comment le cache était géré il y a eu une revue des API de la sécurité des API pour s'assurer que tous les API revue de l'intégrité de tous les API parce que le code est ouvert donc vous avez il peut y avoir des modifications possibles des points d'entrée qui peuvent créer il y a aussi une modification des points d'entrée qui peuvent être effectués par les développeurs donc c'était important de voir comment les API avaient été sécurisés avaient été implémentés on a regardé pour des problèmes de codage y compris s'il y avait des problèmes de gestion de mémoire, des problèmes de concurrence, des exceptions non détectées il y a une revue de la logique voir s'il y avait des défauts logiques dans la mise en oeuvre il y a aussi une attention particulière à l'utilisation des bibliothèques tiers pour évaluer si c'était adéquat, si c'était nécessaire si ça créait des nouveaux risques pour la librairie ursa elle-même au niveau de la revue de la cryptographie il y a eu une évaluation de la cryptographie pour garantir que l'utilisation de la cryptographie qui a été implémentée est sécuritaire ça comprenait un examen de l'entropé et un examen des meilleures pratiques particulièrement au niveau de la longueur des clés et l'utilisation des courbes qui sont faits dans la librairie c'est important de noter que les fondements mathématiques des différentes cryptographies ne faisaient pas partie de la revue de code donc il y a des algorithmes BBS plus etc qui nous on regarde comment l'algorithme est décrit publiquement et on s'assure que la façon que l'algorithme tel que développé, tel que les mathématiens l'ont développé, l'ont représenté que l'implémentation code suivait cette implementation mais il n'y a pas un jugement il n'y a pas une évaluation dure académique qui a été faite à savoir si l'algorithme lui-même le fondement mathématique était suffisant donc je voulais juste clarifier ça le projet en durée environ 4 mois on a commencé au mois de décembre 2021 on a fini au mois de mars 2022 la première étape ça a été une définition du périmètre de revue la deuxième étape c'est à l'identifier ça va être quoi le code, la version du code qui va être utilisée par la revue donc on a utilisé la version 0.3.7 qui s'ensuit l'examen du code lui-même ensuite la validation, la planification de la rémédiation a été effectuée en partenariat avec la communauté donc on a identifié des problèmes potentiels ces problèmes-là ils sont évalués en termes d'impact et une fois qu'on a fait ce travail on a engagé, on a eu des communications avec la communauté Hyperledger pour s'assurer qu'on avait tous la même lecture de l'information et pour commencer à planifier des efforts possibles de rémédiation donc on a travaillé avec des représentants d'Hyperledger, David Boswell on a travaillé avec des représentants de Ursa, je vais les nommer on nous a beaucoup aidé Art Montgomery, Mike Lauder Cam Parra et Nathan George le laboratoire d'identité numérique et la ferme console Hyperion ont aussi participé à ce travail-là une fois que la validation de la planification a été faite on a regardé pour les mesures de rectification donc le pire scénario c'est de trouver un problème majeur sans avoir une réponse sans avoir un plan pour être capable de remédier à ce problème-là ça aurait pu causer des problèmes pour certains des acteurs qui veulent aller en production donc il y avait des mesures de rectification qui ont été mises en place et ça a été fait avec la communauté Ursa et finalement aujourd'hui on est dans cette phase-là rapport et communication de qu'est-ce qu'on a fait, comment on l'a fait qu'est-ce qu'on a trouvé et de communiquer on est dans cette phase-là aujourd'hui alors un instant alors il y a des... l'exemple est révélé qu'avec quelques défauts qu'avec quelques défauts de sécurité qui étaient relativement mineurs et on a aussi partagé des observations au niveau de comment mettre en place ou comment la librairie pouvait être utilisée donc premièrement je vais commencer en disant qu'il y a eu consensus au niveau de la catégorisation des problèmes de la communauté et dans la mise en place le plan de remédiation avec la communauté plus souvent qu'autrement cette remédiation-là pour des problèmes qui ont été identifiés je ne les nommerai pas tous aujourd'hui mais la façon que ça va être fait c'est qu'il y a eu des bugs de TechEd qui ont été soumis au fur de travail normal de la communauté pour résoudre ces problèmes-là donc la communauté on identifie un problème la communauté prend un ordre de ce problème-là et est capable d'apporter des modifications nécessaires pour faire la remédiation dans les grandes catégories de dans les grandes catégories des observations qui ont été faites une des catégories vraiment au niveau de la mise en garde de la compilation de la librairie si on n'a pas un environnement qui est sécuritaire pour la compilation on ne peut pas garantir que la résultante de cette librairie-là elle est saine donc je pense que c'est important de comprendre ça et on a fait quelques observations dans le rapport un autre précaution au niveau de la compilation c'est la dépendance sur les librairies tiers il y en a une principalement qui est utilisée dans Ursa c'est la librairie OpenSSL OpenSSL de temps en temps on le voit on le vu, on le vécu il y a des problèmes de vulnérabilité qui sont identifiés donc ça sera important pour les organisations qui veulent utiliser Ursa de s'assurer de prendre la dernière version d'Ursa et de garder un œil sur les vulnérabilités trouvées dans le futur dans cette librairie-là pour être capable de mettre à jour la librairie qui pourrait être utilisée à l'interne on a identifié des problèmes mineurs au niveau du manque de prise en charge de l'augmentation des messages techniquement l'implémentation vérifie pas toujours qu'une signature est un élément d'un sous-groupe donc c'est une grévité faible c'est quelque chose qui a été identifié il y a aussi la vérification des clés publiques qui est pas toujours effectué qui est pas toujours explicite par exemple dans le module Lib Ursa BLS il y a pas une vérification explicite des clés publiques ça pourrait causer un problème parce que si la clé a été révoquée on ne sera pas au courant et ça crée une chaîne ça crée des enjeux c'est quelque chose qui avait été identifié dans le passé mais pour des raisons de performance n'est pas fait explicitement donc on a ramené ça la communauté va revoir si elle prend la bonne décision ultimement le développeur l'organisation qui utilise la librairie peut forcer une vérification explicite qui ne fait pas au nom du développeur au nom de l'application donc il y a des façons de résoudre ce problème mais cet aspect a été identifié et la communauté Ursa s'est engagée à revoir s'il n'y avait pas de meilleure façon ou une façon différente de communiquer ou de résoudre cette situation un autre problème qui a été identifié je pense que là c'est un petit peu plus la surprise il y a une problème avec il y a une façon de briser l'indice sociabilité d'identity mixer et si on a une clé qui est malveillante un certificat qui est malveillant d'un émetteur ça serait possible entre un émetteur si il y a de la collusion entre un émetteur et un vérificateur d'être capable d'avoir une information donc ça c'est une faille une faiblesse il y a un groupe de recherche qui a été mis en place pour rectifier le problème et des solutions ont été identifiées pour rectifier ce problème au niveau d'identity mixer c'est un problème c'est une gravité faible qui est malveillante et si on a de la collusion avec les vérificateurs à ce moment-là il serait possible de compromettre la protection de la vie privée d'un usager je vous invite à voir le rapport détaillé pour la liste complète des choses qui ont été identifiées je n'en ai juste nommé quelques-uns ici je n'ai pas partagé tous les détails il y a une liste complète qui a été faite ils sont tous la gravité des différents problèmes identifiés et les documentés le plan de remédiation est documenté donc je vous invite très très fortement à revoir le rapport détaillé si vous êtes intéressé aller plus en détail donc en tout et partout la revue de code on juge que la librairie est de bonne qualité c'est une très bonne nouvelle c'est une très bonne nouvelle pour la communauté c'est une très bonne nouvelle pour les utilisateurs et puis on est bien content de se résilier le telom je voudrais remercier les principaux contributeurs à l'examen indépendant je vais vous mentionner on a travaillé beaucoup avec la communauté Ursa on a travaillé beaucoup avec la communauté Hyperledger mais je voudrais prendre le temps de remercier les contributeurs indépendants donc on parle de Neil Kettle on parle de Matthew Barker Justin Gage Lishroy Francis Bruce Daly et Bruce Daly et moi même si vous avez des questions spécifiques au niveau d'Ursa j'ai un code à bord dans la présentation c'est un code à bord vers le serveur Discord pour Ursa c'est en anglais mais c'est la meilleure place pour poser vos questions c'est le groupe de personnes qui s'occupent de la librairie donc si vous avez des questions spécifiques au niveau de l'implementation de l'utilisation je vous invite à présenter vos questions sur le serveur Discord je vous remercie d'avoir pris le temps de participer aujourd'hui à la présentation merci d'avoir regardé le vidéo je répète le URL le code à bord vers le rapport détaillé et on va prendre des questions maintenant je rappelle que je ne suis pas un cryptographe mais si vous voulez on va prendre des questions aujourd'hui si vous voulez m'envoyer des questions vous pouvez le faire par courriel mon adresse courriel c'est pierre.roberge arobace idelab.org alors on va prendre les questions maintenant Kevin je vois pas de questions que ce que t'en as vu pas pour le moment ok je vais revenir je vous invite je vous invite si vous voulez une version écrite si vous voulez une version papier de la présentation d'aujourd'hui le plus au niveau de la jeunesse du projet et de la façon que ça a été fait c'est le code à bord en haut à droite et le rapport détaillé en bas à droite si je vois pas d'autres questions je vais redonner tout le monde retrouve 15 minutes ou 30 minutes dans leur journée aujourd'hui je vous remercie beaucoup bonne journée merci beaucoup Pierre bonne journée à tous et on se retrouve pour la prochaine session merci