Strukturen af FIPS 140-2- og FIPS 140-3-implementeringerne i Gos standardkryptografibibliotek

FIPS 140 (Federal Information Processing Standard Publication 140)

FIPS 140 er en sikkerhedscertificeringsstandard for kryptografiske moduler, udviklet af det amerikanske NIST. Denne standard vurderer, om et bestemt kryptografisk modul eller bibliotek opfylder de sikkerhedskrav, som NIST har defineret. Derfor betyder det, at et modul har bestået FIPS 140-certificeringen, at modulet officielt har en pålidelig sikkerhed, og at det kan anvendes inden for områder, hvor sikkerhed er afgørende, såsom finans, sundhed og forsvar.

Siden FIPS 140 første gang blev fastsat i 1994, er standarden blevet revideret til FIPS 140-2 i 2001 og til FIPS 140-3 i 2019. Selv i dag kræver mange systemer og applikationer certificering efter FIPS 140-2 eller FIPS 140-3.

FIPS 140 og programmeringssprog

Af denne grund anvendes kryptografiske moduler med FIPS 140-certificering som en de facto standard på tværs af flere programmeringssprog og miljøer. Repræsentative eksempler er OpenSSL, BoringSSL, LibreSSL og NSS, og disse er de moduler, der oftest anvendes i applikationer, hvor sikkerhed er afgørende.

De fleste FIPS 140-certificerede moduler er skrevet i C eller C++. Af denne grund opbygger sprog som PHP, Python og JavaScript typisk et FIPS-miljø ved at integrere med disse moduler via eksterne Provider-moduler frem for at anvende dem direkte. Denne tilgang har dog nogle begrænsninger.

• Versionsinkompatibilitet

  FIPS 140-certificering gives kun for en specifik version. Hvis man ønsker at anvende en nyere version af modulet, skal certificeringsprocessen gennemføres på ny, og i den forbindelse kan der opstå versionsinkompatibilitet mellem det modul, applikationen anvender, og det FIPS-certificerede modul. Hvis der anvendes en ikke-godkendt version, betragtes miljøet ikke længere som et FIPS-certificeret miljø.

• Dynamisk indlæsning og ydelsesforringelse

  De fleste sprog indlæser FIPS 140-certificerede moduler som dynamiske biblioteker. Denne metode kan forårsage ydelsesforringelse under initialisering og eksekvering, og hvis der opstår problemer under kørsel, risikerer det at have direkte indvirkning på hele applikationens stabilitet.

• Sikkerhedssårbarheder

  Som nævnt ovenfor kan sikkerhedssårbarheder i det eksterne modul i en struktur, hvor eksterne moduler integreres, som OpenSSL Provider, forplante sig direkte til applikationen. Desuden udgør kommunikationslaget mellem applikationen og det eksterne modul i sig selv en yderligere angrebsflade, og der kræves et separat sikkerhedslag for at beskytte det. Dette øger kompleksiteten og kan give anledning til uventede sårbarheder.

FIPS 140 og Golang

Af denne grund har Golang valgt en anden strategi. Go har ikke valgt at lade FIPS 140-certificering afhænge af eksterne værktøjer, men har i stedet valgt at understøtte den direkte i det officielle kryptografibibliotek. Udviklere behøver derfor ikke at installere eller konfigurere en separat Provider, men kan bruge den almindelige crypto-pakke som normalt og blot aktivere FIPS-certificeringstilstanden (GOFIPS=1). I denne proces fjernes kommunikationsgrænsen til eksterne moduler, hvilket styrker sikkerheden, og driften forenkles, fordi det kun er nødvendigt at distribuere en statisk kompileret enkelt binær fil.

FIPS 140-2 og Golang

For at opnå dette integrerede Golang modulet BoringCrypto, som er afledt af BoringSSL, i Go-runtimen og opnåede dermed FIPS 140-2-certificering. BoringCrypto kan aktiveres på visse distributioner fra Go 1.19 og fremefter, og gennem dette kan Go-applikationer opbygge et FIPS 140-2-certificeret miljø uden separate eksterne moduler.

BoringCrypto er dog baseret på OpenSSL, og derfor eksisterer der stadig en afhængighed af C-sproget. Go-applikationer bliver derfor ikke bygget som fuldt uafhængige binære filer, og der var en begrænsning i, at de nødvendige C-biblioteker skulle distribueres sammen med applikationen.

FIPS 140-3 og Golang

For at overvinde disse begrænsninger forbedrede Go-teamet det eksisterende Go-standardbibliotek for kryptografi, så det opfylder specifikationerne i FIPS 140-3. Dette forbedrede modul blev første gang tilgængeligt eksperimentelt fra Go 1.21, og NIST's certificeringsvurdering af FIPS 140-3 er i øjeblikket i gang.NIST-liste over moduler under FIPS 140-3-vurdering

Dette afspejler modenheden af Go's kryptografibibliotek, og takket være det kan Go nu levere et fuldt uafhængigt, enkelt binært miljø med FIPS 140-3-certificering.

Desuden har Go-teamet ikke blot nøjes med at opfylde FIPS 140-3-standarden, men har også selvstændigt styrket sikkerheden.

• Fail Fast

  Go's FIPS-tilstand anvender en Fail Fast-sikkerhedsmodel, så når en ikke-certificeret algoritme kaldes, afbrydes udførelsen straks med en panic. I modsætning til Provider-baserede modeller i andre sprog, som efterlader en mulighed for fallback, giver dette en strengere og tydeligere garanti med hensyn til sikkerhed og regulatorisk overholdelse.

• Hedged Signature

  FIPS 140-3-standarden anbefaler RFC6979-metoden ved ECDSA-signering. Go har dog yderligere indført en Hedged-metode, som giver stærkere modstand mod sidekanalangreb, der kan opstå under signeringsprocessen.

• Styrket tilfældighedsgenerator

  Go's tilfældighedsgenerator anvender en DRBG (Deterministic Random Bit Generator) i brugerrummet, men tilfører desuden entropi fra operativsystemets kerne, hvilket gør det muligt at generere tilfældige tal af høj kvalitet, ikke kun i brugerrummet, men også i kerneområdet. Dermed styrkes tilfældighedsgeneratorens sikkerhed yderligere.