Crypto-agilité

La norme de certificat à clef publique X.509 est un exemple de crypto-agilité. Un certificat à clef publique possède des paramètres cryptographiques, notamment le type de clef, la longueur de la clef et un algorithme de hachage. La version 3 de X.509, avec le type de clef RSA, une longueur de clef de 1024 bits et l'algorithme de hachage SHA-1, s'est avérée par le NIST avoir une longueur de clef qui la rendait vulnérable aux attaques, ce qui a incité la transition vers SHA-2^[7].

Avec l’essor de TLS pour sécuriser la couche transport du modèle OSI à la fin des années 1990, les primitives et algorithmes cryptographiques sont devenus de plus en plus populaires ; par exemple, en 2019, plus de 80 % des sites Web implémentent TLS^[8]. De plus, les techniques cryptographiques sont largement intégrées pour protéger les applications et les transactions commerciales.

Cependant, à mesure que les algorithmes cryptographiques se déploient, la recherche sur leur sécurité s'intensifie et de nouvelles attaques contre les primitives cryptographiques (anciennes comme nouvelles) voient le jour. La crypto-agilité vise à contrer la menace que cela représente pour la sécurité de l'information en permettant la mise hors service rapide des primitives vulnérables et leur remplacement par de nouvelles dont la sécurité a été démontrée.

Cette menace n'est pas purement théorique ; de nombreux algorithmes autrefois considérés comme sûrs (DES, RSA 512 bits, RC4, etc.) sont désormais reconnus vulnérables, certains même face à des attaquants amateurs. Par ailleurs, les nouveaux algorithmes (AES, cryptographie sur courbes elliptiques) sont souvent à la fois plus sûrs et plus rapides que les anciens. Les systèmes conçus pour répondre aux critères de crypto-agilité devraient être moins affectés si les primitives actuelles s'avéraient vulnérables, et pourraient bénéficier d'une latence ou d'une consommation d'énergie réduites grâce à l'utilisation de primitives nouvelles et améliorées.

Par exemple, l'informatique quantique, si elle devient réalisable, devrait permettre de casser les algorithmes de cryptographie à clef publique existants. La grande majorité des infrastructures de cryptographie à clef publique actuelles reposent sur la complexité de problèmes tels que la factorisation d'entiers et le calcul des logarithmes discrets (dont la cryptographie sur courbes elliptiques est un cas particulier). Les ordinateurs quantiques exécutant l'algorithme de Shor peuvent résoudre ces problèmes exponentiellement plus rapidement que les meilleurs algorithmes connus pour les ordinateurs classiques^[9]. La cryptographie post-quantique est le sous-domaine de la cryptographie qui vise à remplacer les algorithmes vulnérables à l'informatique quantique par de nouveaux algorithmes considérés comme extrêmement difficiles à casser, même pour un ordinateur quantique. Les principales familles d'alternatives post-quantiques à la factorisation et au calcul des logarithmes discrets comprennent la cryptographie sur réseaux, la cryptographie multivariée, la cryptographie par hachage et la cryptographie par codes.

L’évolution des systèmes et la crypto-agilité sont deux choses différentes. L’évolution des systèmes progresse en fonction des nouveaux besoins commerciaux et techniques. La crypto-agilité, quant à elle, est liée à l’infrastructure informatique et nécessite l’intervention d’experts en sécurité, de concepteurs de systèmes et de développeurs d’applications^[10].

L'Agence nationale de la sécurité des systèmes d'information (ANSSI) a publié un guide à destination des développeurs et des architectes systèmes sur la crypto-agilité^[11].

Les recommandations de ce guide sont les suivantes :

• la crypto-agilité doit être implémentée dès que le contexte le permet ;
• elle doit être implémentée de manière consistante à travers tous les sous-systèmes d'un système donné ;
• la crypto-agilité doit être implémentée sans casser les fonctionnalités du système ;
• l'intégrité et l'authenticité des mises à jour doivent être assurées par des mécanismes cryptographiques sûrs ;
• la protection contre les attaques par rejeu doit être implémentée le mécanisme de mise à jour ;
• si plusieurs algorithmes coexistent dans un même système, leur sélection (ou négociation) doit s'assurer de na pas tomber sur un algorithme non désiré.

L'agilité cryptographique accroît généralement la complexité des applications qui en dépendent. Les développeurs doivent implémenter la prise en charge de chaque primitive cryptographique optionnelle, ce qui augmente la quantité de code, le risque d'erreurs d'implémentation et les coûts de maintenance et de support^[12]. Les utilisateurs des systèmes doivent choisir les primitives qu'ils souhaitent utiliser ; par exemple, les utilisateurs d'OpenSSL peuvent sélectionner parmi des dizaines de suites de chiffrement lorsqu'ils utilisent TLS^[13]. De plus, lorsque deux parties négocient les primitives cryptographiques pour leurs échanges de messages, cela ouvre la voie à des attaques par repli (downgrade attacks) via des intermédiaires (comme la vulnérabilité POODLE) ou à la sélection de primitives non sécurisées^[14].

Une autre approche consiste à limiter drastiquement les choix offerts aux développeurs et aux utilisateurs, afin de réduire les risques d'erreurs d'implémentation ou de configuration^[15]. Dans cette approche, les concepteurs de la bibliothèque ou du système choisissent les primitives et ne proposent pas de choix de primitives cryptographiques (ou, s'ils en proposent un, un ensemble très restreint). Ce type de chiffrement imposé est visible dans des outils comme Libsodium, où les API de haut niveau visent explicitement à dissuader les développeurs de choisir les primitives, et dans WireGuard, où des primitives uniques sont sélectionnées afin d'éliminer intentionnellement la flexibilité cryptographique^[16].

Si un chiffrement basé sur des hypothèses est utilisé et qu'une vulnérabilité est découverte dans l'une des primitives d'un protocole, il est impossible de la remplacer par une primitive plus performante. La solution consiste alors à utiliser des protocoles versionnés. Une nouvelle version du protocole inclura la primitive corrigée. Par conséquent, deux parties utilisant des versions différentes du protocole ne pourront pas communiquer.