FIPS 140-certifiering och Golang

FIPS 140 (Federal Information Processing Standard Publication 140)

FIPS 140 är en säkerhetscertifieringsstandard för kryptografiska moduler som har fastställts av den amerikanska NIST. Denna standard utvärderar om en specifik kryptografisk modul eller ett bibliotek uppfyller de säkerhetskrav som definieras av NIST. Att en modul har genomgått FIPS 140-certifiering innebär således att den officiellt anses ha tillförlitlig säkerhet och kan användas inom säkerhetskritiska områden som finans, hälsovård och försvar.

FIPS 140 fastställdes ursprungligen 1994 och har sedan reviderats till FIPS 140-2 år 2001 och FIPS 140-3 år 2019. Än idag kräver många system och applikationer FIPS 140-2 eller FIPS 140-3-certifiering.

FIPS 140 och programmeringsspråk

Av denna anledning används FIPS 140-certifierade kryptografiska moduler som en de facto-standard i flera programmeringsspråk och miljöer. Exempel inkluderar OpenSSL, BoringSSL, LibreSSL och NSS, vilka är de mest använda modulerna i säkerhetskritiska applikationer.

De flesta FIPS 140-certifierade modulerna är skrivna i C eller C++. Därför konfigurerar språk som PHP, Python och Javascript FIPS-miljön genom att integrera via externa Provider-moduler, snarare än att direkt använda dessa moduler. Denna metod har dock vissa begränsningar.

• Problem med versionsinkonsekvens

  FIPS 140-certifiering beviljas endast för specifika versioner. För att använda den senaste versionen av en modul krävs en ny certifieringsprocess, vilket kan leda till versionsinkonsekvenser mellan den modul som används av applikationen och den FIPS-certifierade modulen. Om en obehörig version används, kommer miljön inte längre 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. Denna metod kan orsaka prestandaförsämring under initialisering och exekvering, och om problem uppstår under körning finns det en risk att det direkt påverkar applikationens totala stabilitet.

• Säkerhetsbrister

  Som nämnts ovan, i en struktur som integrerar externa moduler som OpenSSL Provider, finns det en risk att säkerhetsbrister i den modulen direkt sprids till applikationen. Dessutom blir kommunikationsskiktet mellan applikationen och den externa modulen i sig en ytterligare attackyta, vilket kräver ett separat säkerhetsskikt för att skydda den. Detta kan öka komplexiteten och leda till oväntade sårbarheter.

FIPS 140 och Golang

Av dessa skäl har Golang antagit en annan strategi. Go har valt att direkt stödja FIPS 140-certifiering i sitt officiella kryptografiska bibliotek, utan att förlita sig på externa verktyg. Därför behöver utvecklare inte installera eller konfigurera en separat Provider; de kan helt enkelt aktivera FIPS-certifieringsläget (GOFIPS=1) samtidigt som de använder standardpaketet crypto. Denna process eliminerar kommunikationsgränser med externa moduler, vilket förstärker säkerheten, och driften förenklas eftersom endast en statiskt kompilerad binär behöver distribueras.

FIPS 140-2 och Golang

För att uppnå detta har Golang bäddat in BoringCrypto-modulen, som är härledd från BoringSSL, i Go-körtiden för att erhålla FIPS 140-2-certifiering. BoringCrypto kan aktiveras i specifika distributioner från och med Go version 1.19, vilket gör det möjligt för Go-applikationer att konfigurera en FIPS 140-2-certifierad miljö utan externa moduler.

Eftersom BoringCrypto är baserat på OpenSSL finns det dock fortfarande ett beroende av C-språket. Därför byggs Go-applikationer inte som helt oberoende binärer, och det fanns en begränsning att nödvändiga C-bibliotek måste distribueras tillsammans.

FIPS 140-3 och Golang

Go-teamet har förbättrat det befintliga Go standard crypto-biblioteket för att uppfylla FIPS 140-3-specifikationerna för att övervinna dessa begränsningar. Denna förbättrade modul började tillhandahållas experimentellt från och med Go version 1.21, och NIST:s FIPS 140-3-certifieringsgranskning pågår för närvarande.Lista över moduler under granskning för NIST FIPS 140-3

Detta visar mognaden hos Gos kryptografiska bibliotek, och genom detta kan Go tillhandahålla en FIPS 140-3-certifierad miljö som en helt oberoende, enskild binär.

Dessutom har Go-teamet inte bara uppfyllt FIPS 140-3-standarden utan också förstärkt säkerheten på egen hand.

• Fail Fast

  Gos FIPS-läge tillämpar Fail Fast-säkerhetsmodellen, vilket innebär att exekveringen omedelbart avbryts med en panic om en ocertifierad algoritm anropas. Detta, till skillnad från andra språks Provider-baserade modeller som lämnar utrymme för fallback, ger en striktare och tydligare garanti för säkerhet och regelefterlevnad.

• Hedged Signature

  FIPS 140-3-standarden rekommenderar RFC6979-metoden för ECDSA-signering. Go har dock utöver detta introducerat Hedged-metoden för att ge ett starkare skydd mot sidokanalattacker som kan uppstå under signeringsprocessen.

• Förstärkt slumpgenerator

  Gos slumpgenerator använder en DRBG (Deterministic Random Bit Generator) i användarutrymmet, samtidigt som den injicerar ytterligare entropi till operativsystemets kärna, vilket genererar slumpmässiga tal av hög kvalitet både i användarutrymmet och i kärnutrymmet. Detta förstärker slumpgeneratorns säkerhet ytterligare.