GoSudaGo standardbiblioteket för kryptografi: strukturen för FIPS 140-2- och FIPS 140-3-implementationerna
FIPS 140 (Federal Information Processing Standard Publication 140)
FIPS 140 är en säkerhetscertifieringsstandard för kryptografiska moduler som fastställts av det amerikanska NIST. Denna standard utvärderar huruvida en specifik kryptografisk modul eller ett specifikt bibliotek uppfyller de säkerhetskrav som NIST har definierat. Att en modul har godkänts enligt FIPS 140 innebär därför att modulen har officiellt erkänd tillförlitlighet i fråga om säkerhet, vilket innebär att den kan användas inom områden där säkerhet är avgörande, såsom finans, hälso- och sjukvård samt försvar.
Sedan FIPS 140 först fastställdes 1994 har standarden reviderats till FIPS 140-2 år 2001 och till FIPS 140-3 år 2019. Även i dag kräver många system och applikationer certifiering enligt FIPS 140-2 eller FIPS 140-3.
FIPS 140 och programmeringsspråk
Av denna anledning används kryptografiska moduler certifierade enligt FIPS 140 i praktiken som en de facto-standard inom flera programmeringsspråk och miljöer. Som typiska exempel kan nämnas OpenSSL, BoringSSL, LibreSSL och NSS, vilka är de moduler som används mest omfattande i applikationer där säkerhet är av central betydelse.
Merparten av de FIPS 140-certifierade modulerna är skrivna i C eller C++. På grund av detta konfigurerar språk som PHP, Python och JavaScript i regel FIPS-miljön genom att ansluta externa Provider-moduler i stället för att använda dessa moduler direkt. Ett sådant tillvägagångssätt har dock vissa begränsningar.
Problem med versionsavvikelser
FIPS 140-certifiering beviljas endast för specifika versioner. För att använda en nyare version av modulen krävs därför en ny certifieringsprocess, och under denna process kan det uppstå en versionsavvikelse mellan modulen som applikationen använder och den FIPS-certifierade modulen. Om en icke godkänd version används upphör miljön att betraktas som en FIPS-certifierad miljö.
Dynamisk laddning och prestandaförsämring
De flesta språk laddar FIPS 140-certifierade moduler som dynamiska bibliotek. Detta tillvägagångssätt kan orsaka prestandaförsämring vid initiering och exekvering, och om problem uppstår under körning finns en risk att applikationens stabilitet som helhet påverkas direkt.
Säkerhetssårbarheter
Såsom nämnts ovan innebär en struktur som kopplar externa moduler, såsom OpenSSL Provider, en risk att säkerhetssårbarheter i den modulen direkt sprids till applikationen. Dessutom utgör kommunikationslagret mellan applikationen och den externa modulen i sig en ytterligare attackyta, och ett separat säkerhetslager krävs för att skydda detta. Detta ökar komplexiteten och kan ge upphov till oväntade sårbarheter.
FIPS 140 och Golang
Av denna anledning har Golang valt en annan strategi. Go förlitar sig inte på externa verktyg för FIPS 140-certifiering utan har valt att stödja den direkt i sitt officiella kryptografibibliotek. Utvecklare behöver därför varken installera eller konfigurera någon separat Provider, utan kan använda det vanliga crypto-paketet som det är och endast aktivera FIPS-certifieringsläget (GOFIPS=1). Eftersom gränsen mot externa moduler därigenom elimineras stärks säkerheten, och driften förenklas eftersom det räcker att distribuera en statiskt kompilerad enda binärfil.
FIPS 140-2 och Golang
För detta ändamål certifierade Golang sig enligt FIPS 140-2 genom att bädda in BoringCrypto-modulen, som härleds från BoringSSL, i Go-runtimen. BoringCrypto kan aktiveras i vissa distributioner från och med Go 1.19, och genom detta kan Go-applikationer konfigurera en FIPS 140-2-certifierad miljö utan några externa moduler.
BoringCrypto bygger dock på OpenSSL och är därför fortfarande beroende av C-språket. Följaktligen byggs inte Go-applikationer till fullständigt oberoende binärfiler, och det fanns en begränsning som innebar att de nödvändiga C-biblioteken måste distribueras tillsammans med applikationen.
FIPS 140-3 och Golang
För att övervinna dessa begränsningar förbättrade Go-teamet det befintliga standardkryptografibiblioteket i Go så att det uppfyller kraven i FIPS 140-3. Den förbättrade modulen började tillhandahållas experimentellt från och med Go 1.21, och NIST:s granskning för FIPS 140-3-certifiering pågår för närvarande.Lista över moduler under granskning för FIPS 140-3 hos NIST
Detta visar på mognaden hos Gos kryptografibibliotek, och genom detta kan Go nu tillhandahålla en FIPS 140-3-certifierad miljö i form av en helt oberoende enda binärfil.
Dessutom har Go-teamet inte nöjt sig med att enbart uppfylla kraven i FIPS 140-3-standarden utan har även självständigt stärkt säkerheten.
Fail Fast
Go:s FIPS-läge tillämpar en Fail Fast-säkerhetsmodell, vilket innebär att anrop av icke certifierade algoritmer omedelbart avbryter exekveringen med ett panic. Detta ger, till skillnad från Provider-baserade modeller i andra språk som lämnar utrymme för fallback, strängare och tydligare garantier ur säkerhets- och regelefterlevnadsperspektiv.
Hedged Signature
FIPS 140-3-standarden rekommenderar RFC6979-metoden vid ECDSA-signering. Go har dock därutöver infört en Hedged-metod, vilket ger ett starkare skydd mot sidokanalattacker som kan uppstå under signeringsprocessen.
Förstärkt slumptalsgenerator
Go:s slumptalsgenerator använder en DRBG (Deterministic Random Bit Generator) i användarutrymmet, men injicerar dessutom entropi från operativsystemets kärna, vilket möjliggör generering av slumptal av hög kvalitet, inte enbart i användarutrymmet utan även i kärnutrymmet. Genom detta stärks slumptalsgeneratorns säkerhet ytterligare.