Crypto Policy as Code (CPaC) is een erg jong principe dat ons in staat stelt aanbevelingen met betrekking tot cryptografie op een automatische wijze na te leven. Dit artikel maakt onze ideeën rond CPaC meer concreet. Een representatie van cryptografische policies in JSON wordt voorgesteld en gebruikt als basis voor enkele experimenten. Het doel is om het potentieel van CPaC tastbaarder en inzichtelijker te maken, en zo enkele lezers te inspireren.

Everything as Code

Everything as Code wil alle componenten in een IT systeem (infrastructuur, netwerk, veiligheid, deployment pipelines, …) uitdrukken als code. Het laat een hoge graad van automatisering toe van processen en beheer. Het geeft ons meer inzicht en laat ons toe beter te anticiperen en in te grijpen indien nodig. Bovendien resulteert het in een verhoogde consistentie en schaalbaarheid dankzij de verminderde menselijke interventie. Het lijkt ons niet enkel nuttig maar op termijn ook noodzakelijk om dit principe te omarmen in het kader van cryptographic governance. 

Het concept crypto policy as code is vrij nieuw. Toen Smals Research begin 2025 de studie startte was hier vrijwel niets over te vinden. Ondertussen blijkt het ook op de radar te staan van onder meer het bedrijf Garantir.

Een eerste aspect richting CPaC is het uitdrukken van de cryptografische assets (algoritmes, sleutels, certificaten, hardware, libraries, …) als code. Dit laat toe om om de inventaris met de cryptografische assets van een organisatie geautomatiseerd te beheren en te bevragen. Een dergelijke inventaris wordt systematisch aangeraden in de context van quantum readiness en crypto agility.

CBOM (Cryptograhy Bill of Materials) is een model om de cryptografische assets in een organisatie uit te drukken in JSON code. CBOM is vandaag nog erg nieuw, maar zal volgens onze inschatting in de komende jaren een brede adoptie kennen. We verwachten dat onder meer cloud diensten, libraries, besturingssystemen en hardware in de toekomst geleverd zullen worden samen met een beschrijving van de gebruikte en ondersteunde cryptografie, uitgedrukt volgens het CBOM model. Die beschrijvingen kan een organisatie vervolgens in zijn crypto inventaris importeren.

Omwille van deze verwachting enten we onze CPaC voorstellen zoveel als mogelijk op CBOM. Onderstaande figuur is het resultaat van een statische scan van code en toont in CBOM code dat RSA-2048 op drie locaties in een toepassing gebruikt wordt. 

Crypto Policy as Code

Smals beschikt over een cryptografische policy, die aangeeft welke cryptografische algoritmes en parameters aanbevolen zijn, welke veilig zijn, hoewel niet aanbevolen, welke uitgefaseerd dienen te worden en welke onveilig zijn. Momenteel wordt dit nog uitgedrukt op een klassieke manier die enkel door mensen vlot te interpreteren is. We stelden ons de vraag hoe dit als code uitgedrukt zou kunnen worden.

Laat ons even kijken naar AES-128-GCM. AES is het blokcijfer; het encrypteert of decrypteert blokken van 128 bits. Het getal 128 in AES-128-GCM verwijst naar de bitlengte van de sleutel die daarbij gebruikt wordt. Dankzij de modus GCM kunnen ook grotere hoeveelheden data geëncrypteerd en gedecrypteerd worden.

Links op onderstaande figuur wordt de beschrijving van AES-128-GCM getoond volgens het CBOM model. We vinden er informatie over onder meer het klassieke en kwantum veiligheidsniveau. Ons daarop entend, toont de figuur rechts ons voorstel om de aanbevelingen te formuleren als code. We maximaliseren daarbij de compatibiliteit met CBOM; de structuur, naamgeving en identificatielsleutels worden behouden. Tegelijkertijd vermijden we duplicatie van data die we reeds in de CBOM beschrijving vinden.

De aanbevelingen zitten vervat in het recommendation blok. Het bevat minimum het aanbevelingsniveau: recommended, secure, phase-out of insecure. Daarnaast kan dit blok extra, optionele, informatie bevatten, zoals:

• de uiterste datum waarop het cryptografische mechanisme uitgefaseerd dient te worden,
• de datum dat de aanbeveling laatst gereviseerd werd,
• voorwaarden voor correct gebruikt van het cryptografische mechanisme
• opmerkingen, vb. waarom het cryptografisch mechanisme niet langer als veilig beschouwd wordt.

Bij wijze van experiment heeft Smals Research reeds enkele cryptografische aanbevelingen uitgedrukt als code; met name cryptografische hashfuncties, symmetrische vercijfering, message authentication codes (MACs), key derivation functions (KDFs) en TLS. Deze cryptografische aanbevelingen zijn relatief eenvoudig en compatibel met CBOM. Bovendien werd een JSON schema gedefineerd om de correctheid van de syntax en structuur van onze aanbevelingen te valideren. 

Afwijkingen als code

Idealiter doet elke partij die op onze diensten beroep doet, waaronder ziekenhuizen, apothekers en OCMW’s, tijdig de update van hun software zodat die de meest recente en veiligste cryptografie ondersteunen. In de praktijk gebeurt dit niet steeds even snel en moet uitzonderlijk een afwijking van de crypto policy toegestaan worden, zodat de cruciale dienstverlening aan de burgers niet in het gedrang komt.

De onderstaande figuur toont een fictief voorbeeld van een dergelijke afwijking (deviation), waarbij de door Smals Research voorgestelde structuur gevolgd wordt. Het bestaat uit vier blokken:

• Scope. De afwijking kan van toepassing zijn op een volledige dienst, of op specifieke modules ervan.
• Approval. Hier vinden we de referentie naar de goedkeuring door het management, alsook de rechtvaardiging en het tijdsvenster van de afwijking. 
• Assessment. Dit is de beoordeling van het risico. Een afwijking kan enkel goedgekeurd worden mits een voorafgaande inschatting van het risico, wat beschreven wordt in deze sectie.
• Allow. Deze sectie geeft een opsomming van de toegestane algoritmes of cipher suites. De structuur van dit blok komt rechtstreeks uit het CBOM model.

Experimentele scripts

Smals Research schreef een aantal scripts om de kracht van CPaC te illusteren. De aanbevelingen als code, afwijkingen als code en/of CBOM beschrijvingen vormen daarbij de invoer.

Script 1: TLS configuratie

TLS (Transport Layer Security) is een een populair protocol voor veilige communicatie tussen twee partijen. Alvorens data met elkaar uit te wisselen, spreken de partijen samen af welke cipher suite (combinatie van algoritmes) ze daarbij zullen gebruiken. OpenSSL is een populaire TLS client.

Ons eerste script genereert op basis van de crypto policy as code en eventueel een deviation as code de OpenSSL configuratie m.b.t. cryptografie. De uitvoer, waarvan een voorbeeld hieronder, kan vervolgens geïntegreerd worden in openssl.cnf, wat het openSSL configuratiebestand is. De laatste lijn in ons voorbeeld bevat de lijst met cipher suites; de laatste komt uit een afwijking, de anderen zijn veilig volgens de crypto policy. De volgorde is hier van belang; de afwijking krijgt de laagste prioriteit.

[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

Dit kan op termijn de basis vormen om op een gecoördineerde wijze de crypto configuratie voor TLS van duizenden machines geactualiseerd te houden. Uiteraard vereist dit de nodige procedures om fouten tegen te gaan.

Ons voorstel is om zowel de policy as code als de deviations as code door een centrale service te laten beheren. Daarbij kan de policy as code toegankelijk zijn binnen de gehele organisatie, terwijl de deviations as code beschermd dienen te worden door strikte toegangscontrole.

Script 2: PDF generatie

Voor de meeste mensen is een goed gestructureerde PDF nog steeds leesbaarder dan JSON. Vertrekkende van JSON bestanden is het geen heksenkunst om dergelijke documenten te genereren. Dit is wat onze volgende twee scripts realiseren.

Een experimenteel gegenereerde PDF met aanbevelingen voor symmetrische vercijfering is hier te downloaden. Er wordt vertrokken van policy as code, maar er wordt eveneens beroep gedaan op CBOM om de PDF verder te verrijken; zowel het klassieke als kwantumveiligheidsniveau zijn daaruit geëxtraheerd.

Een tweede experimenteel gegenereerde PDF bestand is hier te downloaden. Het bevat aanbevelingen voor TLS cipher suites, aangevuld met bijkomende informatie uit de crypto policy as code. Een voorbeeld van dergelijke informatie is de uiterlijke datum tot wanneer een cipher suite gebruikt mag worden. Indien een dergelijk document met partners gedeeld werd, zou dit hen toelaten tijdig te anticiperen.

Script 3. OPA policy verification

CPaC is een krachtig concept. Voorgaande scripts lieten ons toe om PDF bestanden en TLS configuraties te genereren. CPaC laat ook toe om bestaande artefacten te valideren; om na te gaan of veilige cryptografie gebruikt wordt.   

OPA staat voor Open Policy Agent. Het is een open source policy engine, wat toelaat een scheiding te maken tussen applicatie logica en policy. OPA stelt organisaties in staat policies te centraliseren en in real time af te dwingen. Verschillende services (Kubernetes, CI/CD pipelines, API gateways, …), sturen vragen (queries) in JSON formaat naar de policy engine om te weten of, bijvoorbeeld, een door een client gevraagde actie toegelaten is. Op basis van een policy, uitgedrukt in de taal Rego, laat de policy engine aan de service weten of de vraag positief of negatief beantwoord dient te worden. Zo kan de policy engine de vraag krijgen van een toepassing of iemand van 15 jaar de toepassing mag gebruiken, terwijl de policy bepaalt dat de minumleeftijd 18 jaar is. Of er kan gevraagd worden aan de policy engine of een netwerkconfiguratie in overeenstemming is met de OPA policy. Deze kan bijvoorbeeld eisen dat Telnet poorten nooit open mogen staan.

Services kunnen de OPA engine ook vragen stellen m.b.t. cryptografie: is de gegeven waarde de correcte hashwaarde (ook wel fingerprint of digest) van een gegeven payload? Is een waarde de correcte message authentication code (MAC) voor een gegeven input en sleutel? Is een certificaat ondertekend door een vertrouwde autoriteit? Gebruikt een certificaat een veilige elliptische kromme? …

In ons voorbeeld wordt een JSON bestand bestaande uit een payload en een verwachte hashwaarde (expected_digest) naar de policy engine gestuurd. De OPA policy bepaalt dat de policy engine de hash van de payload opnieuw berekent en dat het resultaat moet overeenkomen met de ontvangen verwachte hashwaarde. De vierde lijn van de OPA policy hieronder bepaalt dat de hashfunctie die daarbij gebruikt dient te worden het (onveilige) MD5 is.  

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

Cryptografie is maar een klein deeltje van wat in een OPA policy uitgedrukt kan worden. Anderzijds zijn de mogelijkheden van OPA policies te beperkt voor een volwaardige CPaC. Zowel OPA policies als CPaC hebben bijgevolg hun bestaansreden. Idealiter komt er ooit een grote master policy, maar zover zijn we vandaag nog niet. 

Een organisatie die CPaC wil introduceren zal moeten nagaan of de bestaande OPA policies compliant zijn met de meest recente versie van de cryptografische policy. Ons laatste script gaat daarom na of de cryptografie die in de OPA policy gebruikt wordt, in overeenstemming is met onze centrale crypto policy (CPaC). De invoer is de crypto policy as code (CPaC) en een OPA policy. De output is ofwel een bericht dat de OPA policy compliant is, ofwel – zoals in bovenstaand geval – een waarschuwing, die ook aangeeft welk onveilig algoritme gebruikt werd.

OPA policies dienen steeds compliant te zijn met de cryptografische policy. Het is een beetje zoals wetgeving. Lagere wetgeving zoals koninklijke besluiten dienen in onvereenstemming te zijn met hogere wetgeving zoals de grondwet. 

Conclusies

Dit artikel werpt een licht op het potentieel van een everything as code benadering om de cryptografische maturiteit van een organisatie een boost te geven. Met behulp van een aantal relatief eenvoudige scripts tonen we aan hoe een centraal beheerde crypto policy, uitgedrukt als code, een organisatie op diverse vlakken kan ondersteunen, gaande van het automatiseren van processen, het creëren van documentatie en het nagaan of de correcte cryptografie gebruikt wordt, zoals in OPA policies.

In een ideale wereld wordt de crypto policy as code aangeboden door een nationale of Europese gezaghebbende organisatie en kunnen zowel de publieke als private sector hier gebruik van maken. Dit is voorlopig nog toekomstmuziek. In de komende jaren mogen we ons wellicht aan een sterke evolutie verwachten in dit domein.

Aarzel niet ons te contacteren indien u hierover met ons van gedachten wilt wisselen!

---

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.