OpenPGP est en cours de réécriture dans Rust: le projet Sequoia



Sequoia Stagg à Alder Creek, Californie



En 2018, trois anciens développeurs de GnuPG ont commencé à travailler sur le projet Sequoia , une implémentation d'OpenPGP à Rust. Comme vous le savez, OpenPGP est une norme de cryptage de données ouvertes souvent utilisée pour le courrier électronique sécurisé; et GnuPG est l'implémentation de référence de cette norme.



Les développeurs eux-mêmes ont déclaré la motivation pour créer une nouvelle bibliothèque OpenPGP:



  • GnuPG est difficile à modifier. Le code et l'API s'accumulent depuis 21 ans. Il n'y a pas de tests unitaires. Les composants sont étroitement liés les uns aux autres. L'architecture laisse beaucoup à désirer et un simple refactoring n'aidera pas.

  • De nombreux développeurs ne sont pas satisfaits des API GnuPG. L'outil de ligne de commande GnuPG et les bibliothèques de programmation correspondantes ont des fonctionnalités différentes, certaines commandes étant disponibles uniquement à partir de la ligne de commande.

  • Rust est un langage sûr pour la mémoire qui élimine automatiquement toute une classe de bogues.

  • GnuPG ne peut pas être utilisé sur iOS en raison des restrictions GPL.


La bibliothèque Sequoia sous licence GPLv2 approche maintenant de la version 1.0 , bien qu'il reste encore plusieurs problèmes à résoudre .



Critiquer GnuPG



La nouvelle bibliothèque devrait être exempte des lacunes de GnuPG. Bien qu'il soit à noter qu'en plus de l'implémentation "de référence" d'OpenPGP, il en existe d'autres, notamment OpenKeychain , OpenPGP.js et RNP .



GnuPG est critiqué depuis des années . Il a été critiqué pour sa complexité absurde, une conception de couteau suisse universelle: GnuPG fait tout mais fait mal, y compris les signatures numériques, la protection par mot de passe, le cryptage à clé publique, les transferts de fichiers sécurisés, la signature de paquets, la protection des sauvegardes, la messagerie de chat, etc. .ré. On pense qu'à l'ère moderne, des outils spécialisés sont nécessaires: une bibliothèque distincte pour la messagerie sécurisée, une bibliothèque distincte pour la signature des paquets, une autre pour le chiffrement des fichiers (en tant qu'utilitairerage écrit en Rust) et ainsi de suite. Et tous ces utilitaires n'ont pas besoin d'être entièrement conformes à PGP.



Les efforts d'OpenPGP pour la compatibilité descendante avec les chiffrements des années 90 ont été critiqués, ce qui signifie que les paramètres par défaut ne correspondent pas aux meilleures pratiques modernes pour une cryptographie forte et que la sécurité est toujours possible grâce à des protocoles de négociation. Le problème est qu'il est impossible de maintenir simultanément la compatibilité descendante et de se conformer à la cryptographie sécurisée moderne.



Nous avons déjà mentionné le code garbage: «L'implémentation PGP standard de facto est GnuPG. Ce programme n'est pas très bien écrit. Il existe une base de code C étendue - un langage avec des fonctionnalités dupliquées (par exemple, une récente attaque par déni de service sur l'analyse SKS indique qu'il a plusieurs analyseurs de clé) avec une longue expérience CVE, allant de la corruption de la mémoire à l'attaque cryptographique via des canaux latéraux. Parfois, il était possible de supprimer l'authentification des messages sans que GnuPG ne s'en aperçoive. Vous auriez pu lui donner les clés sans l'empreinte digitale correcte. En 2018, la vulnérabilité Efail a été causée par GnuPG qui diffusait du texte brut non authentifié sur demande » , écrit Latacora.



Un autre problème est l '(in) utilisabilité.



Il y a plusieurs années, une étude d'utilisabilité de PGP a été menée, dans laquelle un groupe de techniciens a été placé dans une pièce avec un ordinateur et invité à configurer PGP. Deux heures plus tard, aucun d'entre eux n'est encore sorti. - Ted Unangst , développeur OpenBSD et LibreSSL


D'autres plaintes sont l'insécurité du stockage à long terme de la même clé, le système d'authentification par texte chiffré MDC complètement faible , le manque de secret de transmission et les clés géantes maladroites.



Projet Sequoia



Sequoia est une boîte à outils OpenPGP moderne qui résout nombre de ces problèmes, écrit LWN. Sequoia a déjà été adopté par plusieurs autres projets, notamment keys.openpgp.org , OpenPGP CA , koverto , Pijul et KIPA .



Le projet est financé par les fondations p≡p (pep) et Wau Holland , tous les développements étant open source .



La nouvelle bibliothèque est axée sur la sécurité et l'exactitude, tout en utilisant la cryptographie moderne la plus fiable. Les développeurs promettent des outils puissants, y compris un programme de ligne de commande et des sous-commandes de style Git.



$ echo hi | sq encrypt --recipient neal
-----BEGIN PGP MESSAGE-----
wcBMA8K4GQVsZSWYAQgAllrQ+9490eoFdB/jLrVvGl+IVtGJWPFDg9uhcl0D8k05
AWz8ZU2sd6GzoCH1nRpwASJWHxloNbPgvxhNRRVReg3GgfFwMkcoNJ2Xb4zocvx+
niH7ZlP9Py6kseuqtjhQZEyvtIfWc58TK9DRdPp5suzS3Y9Zbew9vC2N2u+8YsKL
BbbminTZqLYbt/00ZT/ZuDbtHhoDUxlnCK2Y2R6NZvuvwS1ujI0EOfdOagZO0z5k
hs8U9Xgk1/BWpQtKn3ygMDO0401nBBbwNgialcu/8yFS+wXoifRaj60Cbxhjv2/G
aTcl9loYpN93BL0a7EbKmcwDl14HwosKdkMj4Px25dI0AZjLxI7TBX18e+hBu5vr
q83G7aEwllpiDU3z+rFXBjsWDOwP2UBf05D/Bl05eSYx4x7UnQ==
=qAvC
-----END PGP MESSAGE----- 


Une interface claire pour l'analyseur et l'inspection des paquets a été implémentée, ainsi que des vidages hexadécimaux, qui peuvent maintenant être consultés dans la démo en ligne .



$ sq packet dump --hex message.pgp
New CTB, 13 bytes: One-Pass Signature Packet
Version: 3
Type: Binary
Pk algo: EdDSA Edwards-curve Digital Signature Algorithm
Hash algo: SHA512
Issuer: 83F8 2E4F E9A5 E098
Last: true

00000000 c4 0d frame
00000002 03 version
00000003 00 sigtype
00000004 0a hash_algo
00000005 16 pk_algo
00000006 83 f8 2e 4f e9 a5 e0 98 issuer
0000000e 01 last 


Contrairement à GnuPG, où l'outil de ligne de commande gpg est plus puissant que la bibliothèque, Sequoia est avant tout une bibliothèque; toutes ses fonctionnalités sont disponibles via des API ouvertes. Le projet prévoit de fournir deux «couches» d'API: une implémentation de bas niveau des spécifications OpenPGP et une API de haut niveau avec des valeurs par défaut raisonnables pour permettre aux utilisateurs d'effectuer plus facilement des tâches courantes telles que la signature de packages et la vérification des signatures:



$ sqv --trace --keyring tails-signing.key \
tails-amd64-3.11.iso.sig tails-amd64-3.11.iso
Will check signature allegedly issued by A8B0 F4E4 5B1B 50E2.
Found key A8B0 F4E4 5B1B 50E2.
Checking signature allegedly issued by A8B0 F4E4 5B1B 50E2.
Signature by A8B0 F4E4 5B1B 50E2 is good.
A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F
1 of 1 signatures are valid (threshold is: 1).
$ echo "Just check the exit status: $?"
Just check the exit status: 0 


Malgré la mise en œuvre de bas niveau des spécifications OpenPGP, les développeurs ont éliminé certaines normes obsolètes et dangereuses, telles que les hachages MD5.



Même avant le début de l'initiative, les fondateurs du projet ont rencontré des membres éminents de la communauté OpenPGP et des utilisateurs finaux pour discuter des plans du projet et s'assurer que leur approche est bien justifiée. Un développement actif est en cours actuellement. À en juger par les entrées dans le référentiel et le tracker , il y a environ 30 participants, et trois versions ont été faites depuis l'annonce en avril 2020 de la préparation de la version 1.0. La dernière version 0.19.0 a été publiée en août 2020 - l'amélioration la plus notable est l'intégration de l' API Windows Cryptography: Next Generation en tant que backend(CNG) au lieu de Nettle, qui a des problèmes dans les environnements non POSIX.



Pour plus de sécurité, Sequoia prévoit d'utiliser la séparation des processus entre les services de clé publique et privée (comme dans gpg-agent). Ici, pour la communication interprocessus, le protocole de sérialisation Cap'n Proto est introduit - c'est quelque chose de similaire aux tampons de protocole, mais plus rapidement.



Dans la présentation, les développeurs soulignent que la séparation des processus n'est pas toujours possible, par exemple dans les environnements iOS. Lorsqu'elle n'est pas disponible, Sequoia prévoit d'utiliser une base de données SQLite partagée pour communiquer entre les services du processus, comme une colocation.



Sequoia adopte une approche conceptuellement différente des porte-clés publics: ils sont conçus pour «ressembler davantage à un carnet d'adresses qu'à un porte-clés PGP». Les clés sont stockées par des identifiants utilisateur ( petname ), avec la possibilité de lier des données structurées arbitraires utiles dans la mise en œuvre de modèles de confiance. Les développeurs disent que cette approche est plus conforme à la façon dont les utilisateurs représentent réellement les clés: elles sont associées à des noms plutôt qu'à un ensemble d'identificateurs abstraits. C'est un domaine dans lequel Sequoia diffère des autres implémentations d'OpenPGP.



De plus, toutes les clés se voient attribuer un "domaine" indiquant le but prévu de la clé. Deux domaines sont actuellement pris en charge: «Contacts» et «Clé de mise à jour logicielle».



Le trousseau est automatiquement mis à jour à partir de serveurs distants (similaire à parcimonie ) pour suivre les changements, les nouvelles sous-clés et les révocations de clés en temps opportun. La documentation indique que cela peut être fait en utilisant des services anonymisés tels que Tor, en plus des méthodes de cryptage TLS les plus courantes.



L'implémentation du trousseau privé de Sequoia prendra en charge le secret de transmissionvia les spécifications OpenPGP, qui ne sont pas implémentées dans de nombreuses autres bibliothèques. Ces spécifications permettent de distinguer les données «au repos» (stockage crypté) et les données «en mouvement» (transmission cryptée). Du point de vue de la sécurité, il est bon de changer périodiquement les clés des données «en mouvement», mais de conserver la possibilité de décrypter les données «au repos». Une présentation de l' un des développeurs, Justus Winter, compare les fonctionnalités de confidentialité de Sequoia à d'autres implémentations d'OpenPGP.



Avantages de la rouille



Sequoia profite de tous les avantages de Rust en matière de sécurité de la mémoire .



Qu'est-ce que la sécurité de la mémoire est populairement expliqué dans un article de Michael Hicks. En termes simples, cela signifie que dans aucun état un programme ne peut accéder à une mémoire invalide. Voici les erreurs suivantes:



  • débordement de tampon;

  • déréférencer un pointeur nul;

  • sauvegarde du pointeur après avoir libéré de la mémoire (utilisation après libre);

  • utilisation de la mémoire non initialisée;

  • une tentative par un programme de libérer la même cellule deux fois (double-free).


Les violations de la sécurité de la mémoire entraînent des vulnérabilités telles que la fuite de données et l'exécution de code à distance. Alors que certains langages se sont résignés à la dégradation des performances au nom de la sécurité de la mémoire, le concept de propriété de Rust garantit la sécurité et minimise les frais généraux.



Sur la base du développement actuel de Sequoia, des efforts importants sont faits pour écrire des tests unitaires afin d'éviter les régressions et d'améliorer la qualité du code.



Sequoia cible les «plates-formes modernes» telles que Linux, Windows, macOS, Android et iOS, en tirant le meilleur parti des outils cryptographiques existants; l'objectif du projet est une intégration étroite avec les services cryptographiques d'une plateforme spécifique. Par exemple, sur les appareils iOS, il est prévu d'utiliser le coprocesseur Secure Enclavequand disponible. Sequoia fournit également une interface de fonction externe (FFI) pour intégrer un projet avec des programmes écrits dans d'autres langues. Des liaisons (liaisons) avec Python et C. sont actuellement proposées. Cependant, il convient de noter que les programmes avec ces liaisons n'ont pas la sécurité mémoire intégrée de Rust, donc des règles spéciales ont été publiées pour la gestion correcte de l'utilisation de la mémoire .





Composants Sequoia



Projets pour le futur



La sortie de la version 1.0 pourrait avoir lieu dans un futur proche, bien qu'au départ, seule l'API de bas niveau sera publiée, c'est-à-dire la caisse sequoia-openpgp et ses dépendances. Cela signifie que Sequoia ne remplace pas encore des outils comme GnuPG pour tous les utilisateurs: la première version majeure se concentrera sur une bibliothèque de développeurs. Les développeurs Sequoia doivent compléter un outil de ligne de commande sqqui ne sera pas inclus dans la version 1.0. De plus, le service de stockage de clés est toujours en cours de développement - avec l'outil de ligne de commande, c'est l'une des principales priorités du projet après la sortie de la version 1.0.



Dans l'ensemble, il est agréable de voir un projet qui tente de rendre OpenPGP plus facile à utiliser et plus accessible. On constate qu'en trois ans, les développeurs ont fait des progrès significatifs. La documentation vous permet d'utiliser cette bibliothèque dans les applications. Cependant, Sequoia a encore un long chemin à parcourir avant de devenir un outil cryptographique fiable. Plus important encore, le code doit être audité. La page du projet indique qu'il n'a pas encore été audité, mais «dès que nous publierons la caisse principale Sequoia, elle sera auditée par un tiers». Aucune date de sortie pour la version 1.0 n'a été annoncée, mais il semble qu'elle arrivera bientôt.






La publicité



VDS pour les programmeurs avec le dernier matériel, une protection contre les attaques et une vaste sélection de systèmes d'exploitation. La configuration maximale est de 128 cœurs de processeur, 512 Go de RAM, 4000 Go de NVMe.






All Articles