Dit artikel is ook beschikbaar in het Nederlands.

La cryptographie est essentielle dans notre société, notamment pour sécuriser les communications sensibles et les transactions financières. Les recommandations cryptographiques aident les organisations et les équipes à déterminer quand un algorithme de cryptographie doit être supprimé progressivement et remplacé par un autre dans leurs systèmes. L’expression de ces recommandations cryptographiques sous forme de code présente des avantages, tels qu’une automatisation accrue et une meilleure compréhension, et constitue une étape logique vers la maturité cryptographique.

Recommandations cryptographiques

Les algorithmes et paramètres recommandés, y compris la longueur des clés, notamment pour l’authentification, les signatures numériques, les fonctions de hachage cryptographique et le chiffrement symétrique, changent régulièrement. Les algorithmes recommandés jadis ne sont plus sûrs aujourd’hui. Il en va de même pour les suites cryptographiques dans les protocoles de communication comme TLS. Les suites cryptographiques sont des combinaisons d’algorithmes et de paramètres cryptographiques convenues par les parties communicantes. Sur cette base, un canal sûr est ensuite mis en place.

Dans de nombreux pays, y compris nos pays voisins tels que l’Allemagne, la France et les Pays-Bas, les agences nationales de sécurité de l’information publient des recommandations détaillées concernant l’utilisation de la cryptographie. Une distinction est généralement opérée entre la cryptographie recommandée (recommended), la cryptographie non recommandée mais considérée comme sûre (secure), la cryptographie à éliminer progressivement (phase out) et, enfin, la cryptographie non sûre (insecure). Ces recommandations sont actualisées régulièrement. L’agence allemande BSI le fait par exemple annuellement.

En Belgique, nous n’avons pas encore de telles recommandations. Idéalement, elles devraient être formulées au niveau européen, par exemple par  l’Agence de l’Union européenne pour la cybersécurité (ENISA). Nous n’y sommes pas encore toutefois. Néanmoins, Smals et le secteur public belge en ont concrètement besoin aujourd’hui. Aussi l’équipe Smals Research a-t-elle pris l’initiative, il y a quelques années, de formuler ses propres recommandations en interne. Ces recommandations reposent sur celles de l’agence allemande BSI, étant donné qu’il s’agit de l’agence de cybersécurité principale en Europe et la mieux subventionnée.  

Recommandations sous forme de code

Comme toutes les autres recommandations cryptographiques, celles-ci sont exprimées sous forme lisible par l’homme, mais pas suffisamment structurées pour être traitées par des machines. Ce dernier aspect autoriserait une plus grande automatisation et profiterait à la sécurité.

• Cela permettrait de générer automatiquement la partie cryptographique des fichiers de configuration pour des protocoles de communication tels que TLS et OpenSSH, avec, à la clé, des mises à jour plus rapides, moins de main-d’œuvre et moins de risques d’erreur humaine. Smals dispose en effet de centaines, voire de milliers de machines qui doivent pouvoir communiquer en toute sécurité.
• Cela permettrait d’accéder de façon interactive aux recommandations cryptographiques.
  Au moyen d’une interface web, une équipe de projet peut rapidement consulter les plus récentes recommandations cryptographiques pertinentes. Une équipe de projet peut également être automatiquement tenue informée des changements qui la concernent une fois l’application opérationnelle.

Le site web CipherSuite est ce qui s’en rapproche le plus aujourd’hui. C’est une initiative louable, mais pour plusieurs raisons, nous voulons aller plus loin avec Smals. En effet, nous ne suivons pas nécessairement ces recommandations, qui se limitent en outre au protocole de communication TLS.
De plus, nous voulons quelque chose qui soit compatible avec CBOM.

Nomenclature cryptographique (CBOM)

Dans le contexte de la menace que représentent les puissants ordinateurs quantiques, une migration majeure de la cryptographie s’impose à nouveau. Pour nous préparer à cette migration ainsi qu’à d’autres migrations futures, il est judicieux, en tant qu’organisation, de savoir où est appliquée quelle cryptographie. Ceci pour pouvoir dresser un plan de migration étayé et exécuter la migration avec plus de rapidité et de fluidité. Cet inventaire devient vite très complexe et doit donc idéalement être exprimé sous forme de code pour faciliter la mise à jour et le traitement automatiques par des machines.

IBM a dès lors développé la nomenclature cryptographique CBOM (Cryptography Bill of Materials), qui permet d’exprimer en format JSON des composants cryptographiques tels que des algorithmes, des paramètres, des protocoles et des bibliothèques ainsi que leurs dépendances. Il s’agit d’un standard OWASP CycloneDX, de sorte qu’il est compatible entre autres avec la nomenclature logicielle SBOM (Software Bill Of Materials). CBOM nous permet de faire passer la gestion des actifs cryptographiques (algorithmes, protocoles, bibliothèques, clés, certificats…) à un niveau supérieur.

L’illustration ci-dessous est un fragment de CBOM qui montre où RSA-2048 est utilisé dans le code source scanné d’une application.

Supposons qu’une organisation exprime ses actifs cryptographiques en CBOM et qu’elle dispose de recommandations cryptographiques dans un code compatible. Cette organisation peut alors vérifier très rapidement où et dans quelle mesure les recommandations cryptographiques sont observées.

Cet aperçu peut être particulièrement utile pour prendre des mesures destinées à renforcer la sécurité de l’organisation et des données qu’elle protège. Une organisation peut ainsi rapidement savoir où elle est la plus vulnérable aux puissants ordinateurs quantiques. L’organisation peut aussi rapidement communiquer des informations exactes lors d’un audit, par exemple sous la forme d’un rapport généré automatiquement au format PDF ou Excel, en réponse à des questions spécifiques de l’auditeur.

Dérogations sous forme de code

Outre les recommandations et les actifs cryptographiques, un troisième élément peut être exprimé sous forme de code lisible par une machine, à savoir les dérogations à ces recommandations.

Dans un monde idéal, Smals n’appliquerait que la cryptographie recommandée et sûre dans ses systèmes. Or, ce n’est pas toujours possible, car cela entraînerait de facto l’indisponibilité de certains services pour les utilisateurs de ces systèmes. Nous ne pouvons en effet pas attendre des médecins, des pharmaciens, des kinésithérapeutes, des CPAS, etc. qu’ils ne prennent en charge que la cryptographie sûre de dernière génération. Smals doit donc faire preuve d’une certaine tolérance et continuer à prendre en charge une cryptographie non optimale pendant une période limitée. Ceci de manière structurée, avec une période de tolérance limitée et une évaluation précise du risque par les services de sécurité et sa validation par l’équipe dirigeante.

Là encore, il est préférable de procéder de manière à permettre un traitement automatique. Ainsi, en combinaison avec les recommandations et l’inventaire, nous pouvons voir en un coup d’œil où nous dérogeons aux recommandations, sous forme documentée ou non. Cela nous permet d’avoir une idée du risque cumulé, ce qui contribue à accroître la sécurité au sein de l’organisation. Ceci aussi peut bien évidemment être utile lors d’un audit.

Conclusion

Il y a quelques années, l’équipe Smals Research a émis une proposition de recommandations cryptographiques, que Smals a adoptée et actualise au moins annuellement. L’équipe considère qu’il est temps de passer à l’étape suivante et se charge actuellement de traduire ces recommandations sous une forme structurée aussi compatible que possible avec CBOM. Elle en fait de même pour les dérogations à ces recommandations.

CBOM et les ambitions de Smals d’exprimer à la fois les actifs cryptographiques, les recommandations et les dérogations dans un format lisible par une machine s’inscrivent dans la tendance plus large du Everything as code, une philosophie qui se traduit par une automatisation accrue des processus et de la gestion. Cela nous offre un meilleur aperçu et nous permet de mieux anticiper et d’intervenir en cas de besoin. Il en résulte également une cohérence et une évolutivité accrues grâce à une moindre intervention humaine.

Selon nous, l’application de l’approche Everything as Code à la cryptographie constitue donc une étape importante dans l’augmentation de la maturité cryptographique. CBOM nous apparaît dès lors comme un standard nécessaire qui, d’après nous, sera de plus en plus pris en charge par les outils de développement, de sécurité de l’information et de migration post-quantique dans les années à venir. Nous nous attendons dès lors à ce que les fournisseurs livrent de plus en plus un CBOM avec leurs logiciels, leurs matériels ou leurs services.

Nous pensons que le triumvirat des actifs cryptographiques sous forme de code, des recommandations sous forme de code et des dérogations sous forme de code, ouvrira de nouvelles possibilités et opportunités en matière d’aperçu et d’automatisation. Une idée serait de réaliser des analyses de graphes (graph analytics) sur ce plan, idéalement à l’aide d’une base de données orientée graphes complétée d’un outil de visualisation interactif.

À suivre. N’hésitez pas à nous contacter si vous êtes intéressé.

Cette contribution a été soumise par Kristof Verslype, cryptographe chez Smals Research. Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.