Titres Titres
Plus tôt cette année, nous avons lancé un programme de bug bounty axé sur la recherche de problèmes dans la spécification de la chaîne de balises et/ou dans les implémentations clientes (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 avançons.
Ce premier article analysera certaines des soumissions ciblant spécifiquement les primitives BLS.
Clause de non-responsabilité: Tous les bugs mentionnés dans cet article ont déjà été corrigés.
Le BLS est partout
Il y a quelques années, Diego F. Araignée a donné une conférence au 21e atelier sur la cryptographie à courbe elliptique avec le titre : Les couples ne sont pas morts, juste au repos. Comment prophétique.
Nous voici 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à) : signatures agrégées BLS, systèmes ZK-SNARKS, etc.
Les travaux de développement et de normalisation liés aux signatures BLS sont un projet en cours pour les chercheurs d’EF depuis un certain temps maintenant, motivés en partie par Justin Drake et résumé dans un récent post de lui sur reddit.
Le dernier et le plus grand
En attendant, il y a eu beaucoup de mises à jour. BLS12-381 est maintenant universellement reconnu comme la courbe d’appariement à utiliser étant donné nos connaissances actuelles.
Trois versions différentes de l’IRTF sont actuellement en cours d’élaboration :
- Courbes adaptées aux appariements
- signature BLS
- Hachage aux courbes elliptiques
De plus, la spécification de la chaîne de balises a mûri et est déjà partiellement déployée. Comme mentionné ci-dessus, les 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 :
- Omissions du projet de l’IRTF
- Erreurs de mise en œuvre
- Violations de la mise en œuvre du projet de l’IRTF
Zoomons sur chaque section.
Omissions du projet de l’IRTF
L’un des journalistes, (Nguyen Thoi Minh Quan), a trouvé des divergences dans le projet de l’IRTF et a publié deux livres blancs avec des conclusions :
Bien que les incohérences spécifiques fassent encore l’objet de débats, il a découvert des problèmes de mise en œuvre intéressants au cours de ses recherches.
Erreurs de mise en œuvre
Guido Vranken a pu découvrir plusieurs « petits » problèmes dans BLST en utilisant le fuzz différentiel. Voir des exemples ci-dessous :
Il a complété cela avec la découverte d’une vulnérabilité modérée affectant la fonction blst_fp_eucl_inverse du BLST.
Violations de la mise en œuvre du projet de l’IRTF
Une troisième catégorie de bogues était liée aux violations d’implémentation de l’ébauche de l’IRTF. Le premier a affecté le client Prysm.
Afin de décrire cela, nous devons d’abord fournir un peu de contexte. Le BLS signatures IRTF draft comprend 3 schémas :
- Schéma de base
- Message augmentation
- Preuve de possession
Le client Prysm ne fait aucune distinction entre les 3 dans son API, qui est unique parmi les implémentations (par exemple py_ecc). Une particularité de la schéma de base cite mot pour mot : « 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ésapprouvant 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 impacté py_ecc. Dans ce cas, le processus de sérialisation décrit dans la spécification ZCash BLS12-381 qui stocke les entiers est toujours dans la plage de [0, p - 1]. L’implémentation py_ecc a effectué 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 decompress_G2 Désérialisation 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 bogues, mais 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 croître de manière 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! ??
