GoSuda

Strukturen til FIPS 140-2- og FIPS 140-3-implementeringene i Gos standardkryptografibibliotek

By Gosunuts views ...

FIPS 140 (Federal Information Processing Standard Publication 140)

FIPS 140 er en standard for sikkerhetssertifisering av kryptografiske moduler, utstedt av amerikanske NIST. Denne standarden evaluerer hvorvidt en spesifikk kryptografisk modul eller et bibliotek oppfyller de sikkerhetskravene som er definert av NIST. Følgelig innebærer det å ha bestått FIPS 140-sertifiseringen at den aktuelle modulen besitter en offisielt pålitelig sikkerhet, og at den kan benyttes innen sikkerhetskritiske felt som finans, helsevesen og forsvar.

Siden den først ble etablert i 1994, har FIPS 140 blitt revidert til FIPS 140-2 i 2001, og til FIPS 140-3 i 2019. Per i dag krever fremdeles mange systemer og applikasjoner enten FIPS 140-2- eller FIPS 140-3-sertifisering.

FIPS 140 og programmeringsspråk

Av denne grunn brukes kryptografiske moduler som har mottatt FIPS 140-sertifisering, som en de facto-standard på tvers av ulike programmeringsspråk og miljøer. Eksempler på dette er OpenSSL, BoringSSL, LibreSSL og NSS, som er de mest utbredte modulene i sikkerhetskritiske applikasjoner.

De fleste FIPS 140-sertifiserte moduler er skrevet i C eller C++. Av denne den grunn konfigurerer språk som PHP, Python og Javascript FIPS-miljøet ved å integrere disse modulene gjennom eksterne providermoduler i stedet for å bruke dem direkte. Imidlertid har denne tilnærmingen enkelte begrensninger.

  • Problem med versjonsuoverensstemmelse

    FIPS 140-sertifisering tildeles kun for spesifikke versjoner. Følgelig, for å kunne bruke den nyeste versjonen av en modul, må sertifiseringsprosessen gjennomgås på nytt, og under denne prosessen kan det oppstå versjonsuoverensstemmelse mellom modulen som applikasjonen benytter, og den FIPS-sertifiserte modulen. Dersom det brukes en uautorisert versjon, vil det aktuelle miljøet ikke lenger bli betraktet som et FIPS-sertifisert miljø.

  • Dynamisk innlasting og redusert ytelse

    De fleste språk laster inn FIPS 140-sertifiserte moduler i form av dynamiske biblioteker for bruk. Denne metoden kan utløse ytelsesforringelse under initialiserings- og eksekveringsprosessene, og det foreligger en risiko for at det har en direkte innvirkning på hele applikasjonens stabilitet dersom det oppstår problemer under kjøring.

  • Sikkerhetssårbarheter

    Som nevnt ovenfor, innebærer strukturen der eksterne moduler integreres, slik som OpenSSL Provider, en risiko for at sikkerhetssårbarheter i den aktuelle modulen blir direkte overført til applikasjonen. I tillegg blir kommunikasjonslaget mellom applikasjonen og den eksterne modulen en ekstra angrepsflate, og det kreves et separat sikkerhetslag for å beskytte dette. Dette øker kompleksiteten og kan skape uventede sårbarheter.

FIPS 140 og Golang

Av disse årsakene valgte Golang en annen strategi. Go valgte en tilnærming der FIPS 140-sertifisering støttes direkte i det offisielle krypteringsbiblioteket, uten å være avhengig av eksterne verktøy. Følgelig trenger ikke utviklere å installere eller konfigurere en separat provider; de kan simpelthen aktivere FIPS-sertifiseringsmodus (GOFIPS=1) mens de benytter standardpakken crypto uendret. I denne prosessen fjernes kommunikasjonsgrensen mot eksterne moduler, noe som styrker sikkerheten, og ettersom det kun er nødvendig å distribuere en enkelt statisk kompilert binærfil, forenkles også driften.

FIPS 140-2 og Golang

For å oppnå dette har Golang innlemmet modulen BoringCrypto, som er avledet fra BoringSSL, i Go-kjøretiden, og dermed oppnådd FIPS 140-2-sertifisering. BoringCrypto kan aktiveres i spesifikke distribusjoner fra og med Go versjon 1.19, og gjennom dette kan Go-applikasjoner konfigurere et FIPS 140-2-sertifisert miljø uten separate eksterne moduler.

Ettersom BoringCrypto imidlertid er basert på OpenSSL, eksisterer det fremdeles en avhengighet av C-språket. Følgelig har det vært en begrensning ved at Go-applikasjoner ikke har blitt bygget som fullstendig uavhengige binærfiler, og de nødvendige C-bibliotekene må distribueres sammen med dem.

FIPS 140-3 og Golang

For å overvinne disse begrensningene har Go-teamet forbedret det eksisterende standard krypteringsbiblioteket i Go slik at det samsvarer med FIPS 140-3-spesifikasjonen. Denne forbedrede modulen ble gjort tilgjengelig som en eksperimentell funksjon fra og med Go versjon 1.21, og NIST sin FIPS 140-3-sertifiseringsvurdering pågår for tiden.Liste over moduler under NIST FIPS 140-3-vurdering

Dette demonstrerer modenheten til Go sitt krypteringsbibliotek, og gjennom dette har Go blitt istand til å tilby et FIPS 140-3-sertifisert miljø som en fullstendig uavhengig enkeltbinærfil.

I tillegg har Go-teamet styrket sikkerheten på egenhånd, utover å simpelthen oppfylle FIPS 140-3-standardene.

  • Fail Fast

    Go sin FIPS-modus anvender en Fail Fast-sikkerhetsmodell, som umiddelbart stanser utførelsen med en panic dersom en ikke-sertifisert algoritme blir kalt opp. I motsetning til providerbaserte modeller i andre språk, som etterlater en mulighet for tilbakefall, gir dette en strengere og tydeligere garanti når det gjelder sikkerhet og regelverkssamsvar.

  • Hedged Signature

    FIPS 140-3-standardene anbefaler metoden RFC6979 ved utførelse av ECDSA-signering. Go har imidlertid i tillegg introdusert en Hedged-tilnærming, for å stå imot sidekanalangrep som kan oppstå under signeringsprosessen på en kraftigere måte.

  • Forsterket generator for tilfeldige tall

    Go sin generator for tilfeldige tall bruker en DRBG (Deterministic Random Bit Generator) i brukermodus, samtidig som den i tillegg tilfører entropi til operativsystemkjernen. Dette gjør at den genererer tilfeldige tall av høy kvalitet ikke bare i brukermodus, men også i kjernemodus. Gjennom dette forsterkes sikkerheten til generatoren for tilfeldige tall ytterligere.