Site icon Crypto Week

Sécurisé non. 1 | Blog de la Fondation Ethereum

Plus tôt cette année, nous avons lancé un programme de primes aux bogues axé sur la recherche de problèmes dans la spécification de la chaîne de balises et/ou dans les implémentations des clients (Lighthouse, Nimbus, Teku, Prysm, etc.). Les résultats (et les rapports de vulnérabilité) ont été instructifs, tout comme les leçons apprises lors de la correction des problèmes potentiels.

Dans cette nouvelle série, nous visons à explorer et à partager certaines des connaissances que nous avons acquises grâce au travail de sécurité à ce jour et à mesure que nous progressons.

Ce premier article analysera certaines des soumissions ciblant spécifiquement les primitives BLS.

Clause de non-responsabilité: Tous les bugs mentionnés dans ce post ont déjà été corrigés.

Le BLS est partout

Sécurisé non. 1 | Blog de la Fondation Ethereum

Il y a quelques années, Diego F. Aranha a donné une conférence au 21e atelier sur la cryptographie à courbes elliptiques avec le titre : Les accords ne sont pas morts, juste au repos. Comment prophétique.

Nous sommes ici en 2021, et les appariements sont l’un des principaux acteurs derrière de nombreuses primitives cryptographiques utilisées dans l’espace blockchain (et au-delà) : BLS signatures agrégées, systèmes ZK-SNARKS, etc.

Le travail de développement et de normalisation lié aux signatures BLS est un projet en cours pour les chercheurs de l’EF depuis un certain temps maintenant, mené en partie par Justin Drake et résumé dans un post récent de lui sur reddit.

Le dernier et le meilleur

Entre-temps, il y a eu beaucoup de mises à jour. BLS12-381 est aujourd’hui universellement reconnu comme la courbe d’appariement à utiliser compte tenu de nos connaissances actuelles.

Trois versions différentes de l’IRTF sont actuellement en cours d’élaboration :

  1. Courbes adaptées à l’appariement
  2. Signatures BLS
  3. Hachage en courbes elliptiques

De plus, le spécification de la chaîne de balises a mûri et est déjà partiellement déployé. Comme mentionné ci-dessus, Signatures BLS sont une pièce importante du puzzle derrière la preuve de participation (PoS) et la chaîne de balises.

Leçons apprises récemment

Après avoir collecté les soumissions ciblant les primitives BLS utilisées dans la couche consensus, nous sommes en mesure de diviser les bogues signalés en trois domaines :

  • Projet d’omissions de l’IRTF
  • Erreurs de mise en œuvre
  • Violations de la mise en œuvre du brouillon de l’IRTF

Zoomons sur chaque section.

Projet d’omissions de l’IRTF

L’un des journalistes, (Nguyen Thoi Minh Quan), ont constaté des divergences dans Projet d’IRTFet a publié deux livres blancs avec des conclusions :


Bien que les incohérences spécifiques fassent encore l’objet pour débatil a trouvé des choses intéressantes la mise en oeuvre problèmes tout en menant ses recherches.

Erreurs de mise en œuvre

Guido Vranken a pu découvrir plusieurs « petits » problèmes dans BLST utilisant fuzzing différentiel. Voir des exemples de ceux ci-dessous:


Il a complété cela par la découverte d’une vulnérabilité modérée affectant le Fonction blst_fp_eucl_inverse de BLST.

Violations de la mise en œuvre du brouillon de l’IRTF

Une troisième catégorie de bogues était liée aux violations de l’implémentation du brouillon de l’IRTF. Le premier a touché le Client Prism.

Afin de décrire cela, nous devons d’abord fournir un peu de contexte. La Signatures BLS Le projet d’IRTF comprend 3 schémas :

  1. Régime de base
  2. Augmentation des messages
  3. Preuve de possession

La Client Prism ne fait aucune distinction entre les 3 dans son API, qui est unique parmi les implémentations (par exemple py_ecc). Une particularité concernant le régime de base est citer textuellement: ‘Cette fonction garantit d’abord que tous les messages sont distincts’ . Cela n’était pas assuré dans le AggregateVerify fonction. Prysm a corrigé cet écart en déprécier l’utilisation de AggregateVerify (qui n’est utilisé nulle part dans la spécification de la chaîne de balises).

Un deuxième problème a eu un impact py_ecc. Dans ce cas, le processus de sérialisation décrit dans le Spécification ZCash BLS12-381 qui stocke les entiers sont toujours dans la plage de [0, p – 1]. La py_ecc mise en œuvre a fait cette vérification pour le groupe G2 de BLS12-381 uniquement pour le partie réelle mais n’a pas effectué l’opération de module pour le partie imaginaire. Le problème a été résolu avec la pull request suivante : Validation insuffisante sur la désérialisation decompress_G2 dans py_ecc.

Emballer

Aujourd’hui, nous avons examiné les rapports liés au BLS que nous avons reçus dans le cadre de notre programme de primes aux boguesmais ce n’est certainement pas la fin de l’histoire pour le travail de sécurité ou pour les aventures liées au BLS.

Nous fortement encourager tu pour aider à garantir que la couche de consensus continue de devenir plus sûre au fil du temps. Sur ce, nous attendons avec impatience de vos nouvelles et vous encourageons à creuser ! Si vous pensez avoir trouvé une faille de sécurité ou un bogue lié à la chaîne de balises ou aux clients associés, soumettre un rapport de bogue! ??

Source https://blog.ethereum.org/en/2021/09/09/secured-no-1

Quitter la version mobile