Dit artikel is ook beschikbaar in het Nederlands.

La politique de cryptographie en tant que code ou Crypto Policy as Code (CPaC) est un principe très récent qui permet de respecter automatiquement les recommandations en matière de cryptographie. Cet article vise à concrétiser nos idées concernant la CPaC. Une représentation des politiques cryptographiques en JSON est proposée et utilisée à titre de base pour quelques expériences. L’objectif est de rendre le potentiel de la CPaC plus tangible et plus compréhensible, et ainsi d’inspirer certains lecteurs.

« Everything as Code »

L’approche Everything as Code (tout en tant que code) vise à exprimer tous les composants d’un système informatique (infrastructure, réseau, sécurité, pipelines de déploiement…) sous forme de code. Elle autorise un haut degré d’automatisation des processus et de la gestion. Elle 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. Il nous semble non seulement utile, mais aussi nécessaire à terme d’adopter cette approche dans le cadre de la gouvernance cryptographique. 

Lorsque Smals Research a débuté l’étude du CPaC début 2025, il n’existait pratiquement aucune information à ce sujet. Depuis, le CPaC semble également avoir attiré l’attention de plusieurs entreprises, notamment Garantir.

Un premier aspect de la CPaC est l’expression des actifs cryptographiques (algorithmes, clés, certificats, hardware, bibliothèques…) sous forme de code. Cela permet de gérer et d’interroger automatiquement l’inventaire des actifs cryptographiques d’une organisation. Un tel inventaire est systématiquement recommandé dans le contexte de l’état de préparation quantique et de l’agilité cryptographique.

Le modèle CBOM (Cryptography Bill of Materials ou nomenclature de cryptographie) permet d’exprimer les actifs cryptographiques d’une organisation en code JSON. Bien qu’il soit encore très récent, nous pensons qu’il sera largement adopté dans les années futures. Nous prévoyons qu’à l’avenir, les services cloud, les bibliothèques, les systèmes d’exploitation et le hardware, entre autres, seront fournis avec une description de la cryptographie appliquée et supportée, exprimée selon le modèle CBOM. Une organisation pourra ensuite importer ces descriptions dans son inventaire cryptographique.

Eu égard à cette perspective, nous intégrons autant que possible nos propositions de CPaC dans le modèle CBOM. L’illustration ci-dessous est le résultat d’une analyse statique du code et montre dans le code CBOM que RSA-2048 est utilisé à trois endroits dans une application.  

 

« Crypto Policy as Code »

Smals dispose d’une politique cryptographique qui indique quels algorithmes et paramètres cryptographiques sont recommandés, lesquels sont sûrs bien que non recommandés, lesquels doivent être progressivement supprimés et lesquels ne sont pas sûrs. Actuellement, ces recommandations sont exprimées de manière classique, que seuls les humains peuvent facilement comprendre. Nous nous sommes demandé comment exprimer ces recommandations sous forme de code.

Penchons-nous sur AES-128-GCM. AES est le chiffre de bloc ; il chiffre ou déchiffre des blocs de 128 bits. Le nombre 128 dans AES-128-GCM fait référence à la longueur en bits de la clé utilisée. Grâce au mode GCM, il est également possible de chiffrer et déchiffrer de plus grandes quantités de données.

Dans la partie gauche de l’illustration ci-dessous, la description de l’AES-128-GCM est présentée selon le modèle CBOM. On y trouve notamment des informations sur le niveau de sécurité classique et le niveau de sécurité quantique. Dans la partie droite de l’illustration se trouve notre proposition de formulation des recommandations sous forme de code. Nous maximisons ainsi la compatibilité avec CBOM ; la structure, la nomenclature et les clés d’identification sont conservées. Dans le même temps, nous évitons la duplication des données que nous trouvons déjà dans la description CBOM.

Les recommandations se trouvent dans le bloc recommendation. Il contient au minimum le niveau de recommandation recommended, secure, phase-out ou insecure. En outre, ce bloc peut contenir des informations supplémentaires facultatives, telles que :

• la date à laquelle le mécanisme cryptographique doit disparaître progressivement ;
• la date de la dernière révision de la recommandation ;
• les conditions d’utilisation correcte du mécanisme cryptographique ;
• les remarques, par exemple sur les raisons pour lesquelles le mécanisme cryptographique n’est plus considéré comme sûr.

À titre expérimental, l’équipe Smals Research a déjà exprimé certaines recommandations cryptographiques sous forme de code, notamment les fonctions de hachage cryptographiques, le chiffrement symétrique, les message authentication codes (MAC), les key derivation functions (KDF) et TLS. Ces recommandations cryptographiques sont relativement simples et compatibles avec CBOM. De plus, un schéma JSON a été défini afin de valider l’exactitude de la syntaxe et de la structure de nos recommandations.

Dérogations sous forme de code

Idéalement, chaque partie qui sollicite nos services, notamment les hôpitaux, les pharmaciens et les CPAS, doit mettre à jour son logiciel en temps utile afin qu’il prenne en charge la cryptographie la plus récente et la plus sûre. Dans la pratique cependant, cette opération n’est pas toujours exécutée aussi rapidement et une dérogation à la politique cryptographique doit être autorisée exceptionnellement afin de ne pas compromettre les services essentiels aux citoyens.

L’illustration ci-dessous montre un exemple fictif d’une telle dérogation (deviation), où la structure proposée par Smals Research est suivie. Elle se compose de quatre blocs :

• Scope. La dérogation peut s’appliquer à un service entier ou à certains modules spécifiques de celui-ci.
• Approval. Nous trouvons ici la référence à l’approbation par le management, ainsi que la justification et la durée de la dérogation. 
• Assessment. Il s’agit de l’évaluation du risque. Une dérogation ne peut être approuvée qu’après une estimation préalable du risque, telle que décrite dans cette section.
• Allow. Cette section énumère les algorithmes ou suites cryptographiques autorisés. La structure de ce bloc provient directement du modèle CBOM.

Scripts expérimentaux

L’équipe Smals Research a rédigé plusieurs scripts afin d’illustrer la puissance de la CPaC. Les recommandations sous forme de code, les dérogations sous forme de code et/ou les descriptions CBOM constituent l’input.

Script 1 : configuration TLS

TLS (Transport Layer Security) est un protocole populaire de communication sécurisée entre deux parties. Avant d’échanger des données, les parties conviennent de la suite cryptographique (combinaison d’algorithmes) qu’elles utiliseront à cette fin. OpenSSL est un client TLS populaire.

Notre premier script génère la configuration OpenSSL relative à la cryptographie sur la base de la politique en tant que code et, le cas échéant, d’une déviation en tant que code. Le code produit, dont vous trouverez un exemple ci-dessous, peut ensuite être intégré dans openssl.cnf, qui est le fichier de configuration openSSL. La dernière ligne de notre exemple contient la liste des suites cryptographiques ; la dernière provient d’une dérogation, les autres sont sécurisées selon la politique cryptographique. L’ordre est important ici ; la dérogation a la priorité la plus faible.

[default_conf]
ssl_conf = ssl_section

[ssl_section]
system_default = system_default_section

[system_default_section]
MinProtocol = TLSv1.3
CipherString = # Sets the ciphersuite list for TLSv1.2 and below to value. This list will be combined with any configured TLSv1.3 ciphersuites.
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_8_SHA256

À terme, cela pourrait servir de base pour maintenir à jour de manière coordonnée la configuration cryptographique pour le TLS de milliers de machines. Bien évidemment, cela nécessite la mise en place des procédures pour éviter les erreurs.

Nous proposons que la politique et les déviations en tant que code soient gérées par un service central. La politique peut être accessible à l’ensemble de l’organisation, tandis que les déviations doivent être protégées par un contrôle d’accès strict.

Script 2 : génération d’un PDF

Pour la plupart des gens, un PDF bien structuré reste plus lisible qu’un fichier JSON. À partir de fichiers JSON, il n’est pas sorcier de générer de tels documents. C’est ce que réalisent nos deux scripts suivants.

Un PDF généré à titre expérimental contenant des recommandations de chiffrement symétrique peut être téléchargé ici. Il est parti du principe policy as code, mais il est fait également appel à CBOM pour enrichir le PDF ; les niveaux de sécurité classique et quantique en sont extraits.

Un deuxième fichier PDF généré à titre expérimental peut être téléchargé ici. Il contient des recommandations pour les suites cryptographiques TLS, complétées par des informations supplémentaires issues de la politique de cryptographie en tant que code. Un exemple de ce type d’informations est la date limite à laquelle une suite cryptographique peut être utilisée. Si un tel document était partagé avec les partenaires, cela leur permettrait d’anticiper en temps utile.

Script 3 : OPA policy verification

CPaC est un concept puissant. Les scripts précédents nous permettaient de générer des fichiers PDF et des configurations TLS. CPaC nous permet également de valider les artefacts existants, en vérifiant si un chiffrement sûr est utilisé.

OPA signifie Open Policy Agent. Il s’agit d’un moteur de politiques open source qui permet de séparer la logique applicative et les politiques. OPA permet aux organisations de centraliser leurs politiques et de les appliquer en temps réel. Différents services (Kubernetes, pipelines CI/CD, API gateways…) envoient des requêtes (queries) au format JSON au moteur de politiques afin de savoir si une action demandée par un client est autorisée. Sur la base d’une politique exprimée dans le langage Rego, le moteur de politiques indique au service si la requête doit recevoir une réponse positive ou négative. Par exemple, le moteur de politiques peut recevoir la requête d’une application demandant si une personne âgée de 15 ans est autorisée à utiliser l’application, alors que la politique stipule que l’âge minimum est de 18 ans. Le moteur de règles peut également être interrogé pour déterminer si une configuration réseau est conforme à la politique OPA. Par exemple, il peut exiger que les ports Telnet ne soient jamais ouverts.

Les services peuvent également poser des questions au moteur OPA concernant la cryptographie : la valeur donnée est-elle la valeur de hachage correcte (également appelée fingerprint ou digest) d’une charge utile donnée ? Une valeur est-elle le MAC correct pour une donnée d’entrée et une clé donnés ? Un certificat est-il signé par une autorité de confiance ? Un certificat utilise-t-il une courbe elliptique sécurisée ? …

Vous trouverez ci-dessous un exemple d’une telle requête et la politique correspondante. La politique stipule que la valeur de hachage de la charge utile est calculée à l’aide de la fonction de hachage (non sécurisée) MD5.

Input by service to policy engine
{
  "payload": {
    "user": "alice",
    "action": "read",
    "resource": "/api/users"
  },
  "expected_digest": "ea99819f665c10c744cbbf8da651c37a"
}

OPA Policy (in Rego) applied by the policy engine 
package crypto_digest_verification
payload_json := json.marshal(input.payload)
computed_digest := crypto.md5(payload_json)
digest_valid := computed_digest == input.expected_digest

Une organisation souhaitant mettre en place CPaC devra vérifier que ses politiques OPA existantes sont conformes à la dernière version de la politique cryptographique. Notre script final vérifie donc si la cryptographie utilisée dans la politique OPA est conforme à notre politique cryptographique centrale. En entrée est la crypto policy as code et une politique OPA. En sortie on obtient soit un message indiquant que la politique OPA est conforme, soit, comme dans le cas ci-dessus, un avertissement précisant également quel algorithme non sécurisé a été utilisé. À long terme, nous souhaitons également pouvoir déduire directement de notre CPaC les politiques OPA relatives à la cryptographie.

Conclusions

Cet article met en lumière le potentiel d’une approche everything as code pour stimuler la maturité cryptographique d’une organisation. À l’aide d’un certain nombre de scripts relativement simples, nous montrons comment une politique cryptographique centralisée, exprimée sous forme de code, peut soutenir une organisation dans divers domaines, de l’automatisation des processus à la création de documentation, en passant par la vérification de l’utilisation de la cryptographie appropriée, par exemple dans les politiques OPA.

À terme, nous souhaitons permettre l’accès aux informations sous forme de code via des API REST. Ainsi, les informations les plus récentes seront affichées clairement sur des tableaux de bord interactifs pour les utilisateurs autorisés. Les systèmes et applications pourront également accéder aux informations en temps réel via cette API REST. Idéalement, nous travaillerons avec une politique et un inventaire unifiés sous forme de code, la cryptographie n’étant qu’un aspect de ce système.

Dans un monde idéal, une politique de cryptographie en tant que code  pourrait être proposée par une organisation nationale ou européenne faisant autorité et pourrait être utilisée tant par le secteur public que par le secteur privé. Pour l’instant, cela reste une utopie. Au cours des prochaines années, nous pouvons nous attendre à une forte évolution dans ce domaine.

N’hésitez pas à nous contacter si vous souhaitez échanger vos idées avec nous à ce sujet !

 

---

Dit is een ingezonden bijdrage van Kristof Verslype, cryptograaf bij Smals Research. Het werd geschreven in eigen naam en neemt geen standpunt in namens Smals.