Auditer et sélectionner les dépendances cryptographiques

La bibliothèque cryptographique que vous choisissez constitue l’une des décisions de sécurité les plus lourdes de conséquences dans un projet. Même des développeurs bien intentionnés utilisant une bibliothèque médiocre peuvent produire des systèmes non sécurisés. À l’inverse, une bibliothèque bien conçue rend les erreurs catastrophiques difficiles à commettre. Le processus de sélection doit être systématique et évaluer l’historique de sécurité, la conception de l’API, l’état de la maintenance et l’adéquation à l’usage prévu.

L’une des premières questions à poser pour toute bibliothèque cryptographique est de savoir quand elle a fait l’objet de son dernier audit indépendant et ce que cet audit couvrait. Un audit réalisé il y a cinq ans sur la version 1.0 fournit moins de garanties pour la version 3.0 utilisée aujourd’hui. Recherchez des audits réalisés par des entreprises de sécurité réputées (NCC Group, Trail of Bits, Quarkslab, Cure53) et couvrant les fonctionnalités précises que vous prévoyez d’utiliser. Certaines bibliothèques publient leurs rapports d’audit ; l’absence de tout audit constitue un facteur de risque important.

Examinez l’historique des CVE de la bibliothèque dans le NVD (base nationale de données des vulnérabilités). Examinez notamment le nombre de CVE existantes, leurs niveaux de gravité, les classes de vulnérabilités qu’elles représentent (erreurs logiques, corruption de mémoire ou faiblesses algorithmiques) et la rapidité avec laquelle les responsables ont publié des correctifs. Une bibliothèque présentant occasionnellement des CVE corrigées rapidement témoigne d’une maintenance réactive. Une bibliothèque avec de nombreuses CVE de gravité élevée ou une publication lente des correctifs doit vous alerter.

Les bibliothèques cryptographiques qui ne sont plus maintenues sont dangereuses. Vérifiez la date de la dernière validation, la fréquence des versions et la prise en charge des avis de sécurité. Une bibliothèque dont la dernière validation remonte à trois ans peut présenter des vulnérabilités connues qui ne seront jamais corrigées. La taille de la communauté compte pour l’étendue des examens : les bibliothèques largement utilisées font l’objet d’un examen plus approfondi de la part des chercheurs en sécurité que les projets de niche.

Une surface d’API plus réduite et plus directive est préférable pour la sécurité. Les bibliothèques qui exposent de nombreuses options d’algorithmes et de nombreux paramètres de configuration créent des possibilités de mauvaise configuration. Comparez libsodium (une fonction par cas d’utilisation, avec un algorithme fixe) à OpenSSL EVP (où il faut choisir séparément le chiffrement, le mode, la taille de clé, le remplissage et la gestion du vecteur d’initialisation). Plus il est difficile d’utiliser une bibliothèque de manière incorrecte, plus elle convient aux projets soucieux de leur sécurité.

Pour les opérations portant sur des données secrètes (comparaison de clés, déchiffrement, vérification de signatures), l’implémentation doit utiliser des algorithmes à temps constant qui n’effectuent pas de branchement et n’accèdent pas à la mémoire en fonction de valeurs secrètes. Vérifiez que la documentation de la bibliothèque indique explicitement des garanties de temps constant pour les opérations sensibles, ou que le code source utilise des fonctions de comparaison à temps constant approuvées. Les bibliothèques qui n’offrent pas cette garantie sont vulnérables aux attaques par canal auxiliaire fondées sur le temps.

Une bonne bibliothèque cryptographique doit prendre en charge les algorithmes modernes et prévoir le retrait progressif des algorithmes obsolètes. Elle doit proposer ChaCha20-Poly1305 ou AES-256-GCM pour le chiffrement, Ed25519 ou ECDSA P-256 pour les signatures, X25519 pour l’échange de clés et Argon2id pour le hachage des mots de passe. Les bibliothèques qui ne proposent que des algorithmes anciens (DES, RC4, MD5, SHA-1) ne conviennent pas aux nouveaux déploiements, quelles que soient leurs autres qualités.

Évaluez les dépendances transitives : de quelles bibliothèques votre bibliothèque cryptographique dépend-elle et quelle est leur posture de sécurité ? Une bibliothèque sans dépendance externe (comme libsodium) présente un risque minimal lié à la chaîne d’approvisionnement. Une bibliothèque qui dépend d’une douzaine de paquets npm, chacun ayant ses propres dépendances, possède une vaste surface d’attaque liée à la chaîne d’approvisionnement. Vérifiez si la bibliothèque utilise des compilations reproductibles, afin de pouvoir vérifier que le binaire distribué correspond au code source.

Les secteurs réglementés (santé, finance, gouvernement) exigent souvent des modules cryptographiques validés selon FIPS 140-2 ou 140-3. La validation FIPS est coûteuse et longue, de sorte que seule une partie des bibliothèques en bénéficie. OpenSSL avec son fournisseur FIPS, BoringCrypto (utilisé dans le module crypto/tls de Go) et certaines bibliothèques de HSM sont validés selon FIPS. Si votre déploiement exige la conformité FIPS, cette exigence réduit considérablement le choix des bibliothèques.

Les modules de sécurité matériels (HSM) et les services KMS cloud disposent souvent d’API propriétaires pour les opérations sur les clés. Coupler étroitement votre application à AWS KMS ou à un fournisseur de HSM particulier crée un risque de dépendance. Évaluez si la bibliothèque fournit des couches d’abstraction (comme l’intégration KMS de Tink) qui permettent de changer de fournisseur. Tenez également compte du fait que si le fournisseur de HSM cesse d’assurer la maintenance ou augmente ses prix, les coûts de migration pourraient être considérables.

La règle la plus importante pour sélectionner des dépendances cryptographiques est la suivante : utilisez des bibliothèques connues et largement déployées qui implémentent des normes établies, et n’implémentez jamais vous-même des primitives cryptographiques. Quelle que soit votre maîtrise de la théorie, implémenter correctement AES, RSA, les opérations sur courbes elliptiques ou le chiffrement authentifié dans du code de production est extrêmement difficile et ne justifie presque jamais le risque, comparé à l’utilisation d’une bibliothèque éprouvée.

Liste de vérification pour la sélection d’une bibliothèque : vérifiez la portée et le rapport d’un audit indépendant récent, examinez l’historique des CVE et le délai de publication des correctifs, vérifiez l’activité de la maintenance et l’implication de la communauté, privilégiez les surfaces d’API réduites qui résistent aux usages incorrects, confirmez les garanties de temps constant pour les opérations sensibles, assurez-vous de la prise en charge des algorithmes modernes, évaluez les dépendances de la chaîne d’approvisionnement, vérifiez la validation FIPS si votre secteur est réglementé, tenez compte du risque de dépendance à un fournisseur de KMS et utilisez toujours des bibliothèques établies plutôt que d’implémenter vous-même des primitives.