FIPS 140-certificering en Golang

FIPS 140 (Federal Information Processing Standard Publication 140)

FIPS 140 is een beveiligingscertificeringsstandaard voor cryptografische modules, opgesteld door het Amerikaanse NIST. Deze standaard beoordeelt of een specifieke cryptografische module of bibliotheek voldoet aan de beveiligingsvereisten zoals gedefinieerd door NIST. Dat een module de FIPS 140-certificering heeft doorstaan, betekent dan ook dat deze module officieel betrouwbare beveiliging biedt en kan worden gebruikt in beveiligingskritieke sectoren zoals financiën, gezondheidszorg en defensie.

FIPS 140 werd voor het eerst vastgesteld in 1994, en is sindsdien herzien naar FIPS 140-2 in 2001 en FIPS 140-3 in 2019. Tot op heden vereisen veel systemen en applicaties nog steeds FIPS 140-2 of FIPS 140-3 certificering.

FIPS 140 en programmeertalen

Om deze reden worden FIPS 140-gecertificeerde cryptografische modules in feite als standaard gebruikt in diverse programmeertalen en omgevingen. Voorbeelden hiervan zijn OpenSSL, BoringSSL, LibreSSL en NSS, die de meest gebruikte modules zijn in beveiligingskritieke applicaties.

De meeste FIPS 140-gecertificeerde modules zijn geschreven in C of C++. Daarom configureren talen zoals PHP, Python en Javascript hun FIPS-omgeving door deze modules te koppelen via externe Provider-modules, in plaats van ze direct te gebruiken. Deze aanpak kent echter enkele beperkingen.

• Problemen met versie-incompatibiliteit

  FIPS 140-certificering wordt alleen toegekend aan specifieke versies. Om de nieuwste versie van een module te gebruiken, moet een nieuw certificeringsproces worden doorlopen, wat kan leiden tot versie-incompatibiliteit tussen de module die door de applicatie wordt gebruikt en de FIPS-gecertificeerde module. Als een niet-geautoriseerde versie wordt gebruikt, wordt de betreffende omgeving niet langer als een FIPS-gecertificeerde omgeving beschouwd.

• Dynamisch laden en prestatievermindering

  De meeste talen laden FIPS 140-gecertificeerde modules als dynamische bibliotheken. Deze methode kan leiden tot prestatievermindering tijdens initialisatie en uitvoering, en vormt een risico voor de algehele stabiliteit van de applicatie als er tijdens runtime problemen optreden.

• Beveiligingskwetsbaarheden

  Zoals hierboven vermeld, bestaat bij een architectuur die externe modules zoals de OpenSSL Provider koppelt, het risico dat beveiligingskwetsbaarheden in die modules direct naar de applicatie worden verspreid. Bovendien wordt de communicatielaag tussen de applicatie en externe modules zelf een extra aanvalsoppervlak, en is een aparte beveiligingslaag nodig om deze te beschermen. Dit verhoogt de complexiteit en kan leiden tot onverwachte kwetsbaarheden.

FIPS 140 en Golang

Om deze reden heeft Golang een andere strategie gekozen. Go heeft ervoor gekozen om FIPS 140-certificering direct te ondersteunen in de officiële cryptografische bibliotheek, zonder afhankelijkheid van externe tools. Ontwikkelaars hoeven daarom geen aparte Provider te installeren of te configureren, maar kunnen eenvoudigweg de standaard crypto-package gebruiken en de FIPS-gecertificeerde modus (GOFIPS=1) activeren. Dit proces elimineert de communicatiegrens met externe modules, waardoor de beveiliging wordt versterkt, en de bedrijfsvoering wordt vereenvoudigd omdat alleen een statisch gecompileerde, enkelvoudige binaire moet worden gedistribueerd.

FIPS 140-2 en Golang

Hiervoor heeft Golang de BoringCrypto-module, afgeleid van BoringSSL, ingebouwd in de Go runtime om FIPS 140-2-certificering te verkrijgen. BoringCrypto kan worden geactiveerd in specifieke distributies vanaf Go 1.19, waardoor Go-applicaties een FIPS 140-2-gecertificeerde omgeving kunnen configureren zonder afzonderlijke externe modules.

Echter, aangezien BoringCrypto gebaseerd is op OpenSSL, bestaat er nog steeds een afhankelijkheid van de C-taal. Hierdoor konden Go-applicaties niet volledig als onafhankelijke binaire bestanden worden gebouwd, en was er de beperking dat de benodigde C-bibliotheken samen moesten worden gedistribueerd.

FIPS 140-3 en Golang

Het Go-team heeft deze beperkingen aangepakt door de bestaande Go standaard crypto-bibliotheek te verbeteren om te voldoen aan de FIPS 140-3-specificaties. Deze verbeterde module is experimenteel beschikbaar sinds Go 1.21, en de FIPS 140-3-certificeringsbeoordeling door NIST is momenteel gaande.Lijst van modules die in behandeling zijn voor NIST FIPS 140-3-beoordeling

Dit toont de volwassenheid van de Go-cryptografische bibliotheek aan, waardoor Go een FIPS 140-3-gecertificeerde omgeving kan bieden als een volledig onafhankelijke, enkelvoudige binaire.

Bovendien heeft het Go-team niet alleen voldaan aan de FIPS 140-3-standaard, maar ook de beveiliging intern versterkt.

• Fail Fast

  De FIPS-modus van Go past het Fail Fast-beveiligingsmodel toe, waarbij de uitvoering onmiddellijk stopt met een "panic" als een niet-geautoriseerd algoritme wordt aangeroepen. Dit biedt een strengere en duidelijkere garantie op het gebied van beveiliging en naleving, in tegenstelling tot Provider-gebaseerde modellen in andere talen die de mogelijkheid van een fallback openlaten.

• Hedged Signature

  De FIPS 140-3-standaard beveelt de RFC6979-methode aan voor ECDSA-handtekeningen. Echter, Go introduceert hierbovenop de Hedged-methode om robuuster om te gaan met zijkanalen-aanvallen die tijdens het handtekeningproces kunnen optreden.

• Verbeterde willekeurige getallengenerator

  De willekeurige getallengenerator van Go maakt gebruik van een gebruikersruimte DRBG (Deterministic Random Bit Generator) en injecteert bovendien entropie in de besturingssysteemkernel, waardoor willekeurige getallen van hoge kwaliteit worden gegenereerd in zowel de gebruikersruimte als de kernelruimte. Dit versterkt de beveiliging van de willekeurige getallengenerator verder.