FIPS 140-sertifisering og Golang
FIPS 140 (Federal Information Processing Standard Publication 140)
FIPS 140 er en sikkerhetssertifiseringsstandard for kryptografiske moduler, etablert av NIST i USA. Denne standarden evaluerer om en spesifikk kryptografisk modul eller et bibliotek oppfyller sikkerhetskravene definert av NIST. Følgelig innebærer bestått FIPS 140-sertifisering at den aktuelle modulen har oppnådd offisielt pålitelig sikkerhet, og at den kan benyttes i sikkerhetskritiske sektorer som finans, helse og forsvar.
FIPS 140 ble opprinnelig etablert i 1994, og har siden blitt revidert til FIPS 140-2 i 2001 og FIPS 140-3 i 2019. Frem til i dag krever mange systemer og applikasjoner fortsatt FIPS 140-2- eller FIPS 140-3-sertifisering.
FIPS 140 og programmeringsspråk
Av denne grunn brukes FIPS 140-sertifiserte kryptografiske moduler som en de facto-standard i ulike programmeringsspråk og miljøer. Eksempler inkluderer OpenSSL, BoringSSL, LibreSSL og NSS, som er de mest brukte modulene i sikkerhetskritiske applikasjoner.
De fleste FIPS 140-sertifiserte moduler er skrevet i C eller C++. Dette betyr at språk som PHP, Python og Javascript, i stedet for å bruke disse modulene direkte, konfigurerer FIPS-miljøer ved å integrere dem via eksterne Provider-moduler. Denne tilnærmingen har imidlertid flere begrensninger.
Versjonskonfliktproblem
FIPS 140-sertifisering tildeles kun for en spesifikk versjon. Derfor krever bruk av den nyeste versjonen av en modul en ny sertifiseringsprosess, noe som kan føre til versjonskonflikter mellom modulen som brukes av applikasjonen og den FIPS-sertifiserte modulen. Hvis en ikke-autorisert versjon brukes, vil miljøet ikke lenger bli ansett som et FIPS-sertifisert miljø.
Dynamisk lasting og ytelsesnedgang
De fleste språk laster og bruker FIPS 140-sertifiserte moduler som dynamiske biblioteker. Denne metoden kan forårsake ytelsesnedgang under initialisering og utførelse, og det er en risiko for at problemer som oppstår under kjøretid kan ha en direkte innvirkning på den generelle stabiliteten til applikasjonen.
Sikkerhetssvakheter
Som nevnt ovenfor, i en arkitektur som integrerer eksterne moduler som OpenSSL Provider, er det en risiko for at sikkerhetssvakheter i den aktuelle modulen direkte kan overføres til applikasjonen. I tillegg blir kommunikasjonslaget mellom applikasjonen og den eksterne modulen en ekstra angrepsflate i seg selv, noe som krever et separat sikkerhetslag for å beskytte det. Dette kan øke kompleksiteten og føre til uventede sårbarheter.
FIPS 140 og Golang
Av disse grunnene har Golang valgt en annen strategi. Go har valgt å støtte FIPS 140-sertifisering direkte i sitt offisielle kryptografiske bibliotek, i stedet for å være avhengig av eksterne verktøy. Derfor trenger utviklere bare å aktivere FIPS-sertifisert modus (GOFIPS=1) mens de bruker standard crypto-pakken, uten å måtte installere eller konfigurere en separat Provider. Denne prosessen eliminerer kommunikasjonsgrensene med eksterne moduler, forbedrer sikkerheten, og forenkler driften ved at kun en statisk kompilert binærfil trenger å distribueres.
FIPS 140-2 og Golang
For å oppnå dette har Golang oppnådd FIPS 140-2-sertifisering ved å innebygge BoringCrypto-modulen, som er avledet fra BoringSSL, i Go-kjøretiden. BoringCrypto kan aktiveres i spesifikke distribusjoner etter Go 1.19-versjonen, noe som gjør det mulig for Go-applikasjoner å konfigurere et FIPS 140-2-sertifisert miljø uten behov for separate eksterne moduler.
Imidlertid er BoringCrypto basert på OpenSSL, og har derfor fortsatt en avhengighet av C-språket. Dette medførte en begrensning der Go-applikasjoner ikke kunne bygges som fullstendig uavhengige binærfiler, og de nødvendige C-bibliotekene måtte distribueres sammen med dem.
FIPS 140-3 og Golang
Go-teamet har overvunnet disse begrensningene ved å forbedre det eksisterende Go-standard crypto-biblioteket for å overholde FIPS 140-3-spesifikasjonene. Denne forbedrede modulen har vært eksperimentelt tilgjengelig siden Go 1.21-versjonen, og er for tiden under NISTs FIPS 140-3-sertifiseringsvurdering.Liste over moduler under NIST FIPS 140-3 vurdering
Dette demonstrerer modenheten til Go-kryptografibiblioteket, og gjør det mulig for Go å tilby et FIPS 140-3-sertifisert miljø som en fullstendig uavhengig enkeltbinærfil.
I tillegg har Go-teamet ikke bare oppfylt FIPS 140-3-standarden, men også forbedret sikkerheten internt.
Fail Fast
Go's FIPS-modus anvender en Fail Fast-sikkerhetsmodell, hvor et kall til en ikke-sertifisert algoritme umiddelbart avbryter utførelsen med en panic. Dette gir en strengere og klarere garanti når det gjelder sikkerhet og overholdelse av regelverk, i motsetning til Provider-baserte modeller i andre språk som tillater fallback-muligheter.
Hedged Signature
FIPS 140-3-standarden anbefaler RFC6979-metoden for ECDSA-signering. Go har imidlertid i tillegg introdusert en Hedged-metode for å gi en sterkere respons på sidekanalangrep som kan oppstå under signeringsprosessen.
Forbedret tilfeldig tallgenerator
Go's tilfeldige tallgenerator bruker en brukerroms DRBG (Deterministic Random Bit Generator), samtidig som den injiserer ytterligere entropi til operativsystemkjernen, for å generere tilfeldige tall av høy kvalitet ikke bare i brukerrommet, men også i kjernen. Dette forbedrer sikkerheten til den tilfeldige tallgeneratoren ytterligere.