FIPS 140 certificering og Golang
FIPS 140 ( Federal Information Processing Standard Publication 140 )
FIPS 140 er en standard for sikkerhedscertificering af kryptografiske moduler, udstedt af amerikanske NIST. Denne standard evaluerer, hvorvidt specifikke kryptografiske moduler eller biblioteker opfylder de sikkerhedskrav, som NIST har defineret. Følgelig indebærer beståelse af FIPS 140-certificering, at det pågældende modul besidder officielt pålidelig sikkerhed, hvilket indikerer, at det kan anvendes inden for sikkerhedskritiske områder såsom finans, sundhedsvæsen og forsvar.
FIPS 140 blev oprindeligt fastsat i 1994 og er siden blevet revideret til FIPS 140-2 i 2001 og til FIPS 140-3 i 2019. Adskillige systemer og applikationer stiller fortsat krav om enten FIPS 140-2- eller FIPS 140-3-certificering.
FIPS 140 og programmeringssprog
Af disse årsager anvendes FIPS 140-certificerede kryptografiske moduler som de facto-standarder i adskillige programmeringssprog og miljøer. Fremtrædende eksempler inkluderer OpenSSL, BoringSSL, LibreSSL og NSS, som er de mest udbredte moduler i sikkerhedskritiske applikationer.
Størstedelen af FIPS 140-certificerede moduler er implementeret i C eller C++. Dette medfører, at sprog som PHP, Python og Javascript konfigurerer FIPS-miljøer ved at integrere disse moduler via eksterne Provider-moduler snarere end ved direkte anvendelse. Denne tilgang medfører dog visse begrænsninger.
Problem med versionsuoverensstemmelse
FIPS 140-certificering tildeles kun for specifikke versioner. Anvendelse af den nyeste modulversion kræver derfor en ny certificeringsproces, hvilket potentielt kan resultere i en versionsuoverensstemmelse mellem det modul, applikationen anvender, og det FIPS-certificerede modul. Anvendelse af en uautoriseret version vil medføre, at det pågældende miljø ikke længere betragtes som et FIPS-certificeret miljø.
Dynamisk indlæsning og ydelsesreduktion
De fleste sprog indlæser FIPS 140-certificerede moduler i form af dynamiske biblioteker. Denne metode kan inducere ydelsesnedgang under initialisering og eksekvering, og udgør en risiko for direkte påvirkning af applikationens samlede stabilitet, hvis der opstår problemer i runtime.
Sikkerhedssårbarheder
Som nævnt ovenfor, indebærer strukturer, der integrerer eksterne moduler såsom OpenSSL Provider, en risiko for direkte propagation af sikkerhedssårbarheder fra det pågældende modul til applikationen. Ydermere udgør kommunikationslaget mellem applikationen og det eksterne modul i sig selv en yderligere angrebsflade, hvilket nødvendiggør et separat sikkerhedslag til beskyttelse heraf. Dette øger kompleksiteten og kan potentielt introducere uforudsete sårbarheder.
FIPS 140 og Golang
Af disse årsager har Golang valgt en alternativ strategi. Go har valgt en metode, hvor FIPS 140-certificering understøttes direkte i det officielle kryptografiske bibliotek uden afhængighed af eksterne værktøjer. Udviklere behøver derfor ikke installere eller konfigurere en separat Provider; de kan anvende standard 'crypto'-pakken som den er, blot ved at aktivere FIPS-certificeret tilstand (GOFIPS=1). Denne proces eliminerer kommunikationsgrænser til eksterne moduler, hvilket styrker sikkerheden, og driftsmæssigt simplificeres det, da kun en statisk kompileret, enkeltstående binær skal distribueres.
FIPS 140-2 og Golang
Til dette formål har Golang opnået FIPS 140-2-certificering ved at indbygge modulet BoringCrypto, som er afledt af BoringSSL, i Go-runtime. BoringCrypto kan aktiveres i specifikke distributioner efter Go version 1.19, hvilket gør det muligt for Go-applikationer at etablere et FIPS 140-2-certificeret miljø uden separate eksterne moduler.
Dog eksisterer der stadig en afhængighed af C-sproget, idet BoringCrypto er baseret på OpenSSL. Dette medførte begrænsningen, at Go-applikationen ikke blev bygget som en fuldstændig uafhængig binær, og at de nødvendige C-biblioteker skulle distribueres sammen hermed.
FIPS 140-3 og Golang
For at overvinde disse begrænsninger har Go-teamet forbedret det eksisterende Go standard 'crypto'-bibliotek, så det overholder FIPS 140-3 specifikationen. Dette forbedrede modul begyndte at blive tilbudt eksperimentelt fra Go version 1.21, og NISTs FIPS 140-3 certificeringsevaluering er aktuelt i gang.NIST FIPS 140-3-evalueringer under behandling
Dette demonstrerer modenheden af Go's kryptografiske bibliotek og gør det muligt for Go at levere et FIPS 140-3-certificeret miljø som en fuldstændig uafhængig, enkeltstående binær.
Endvidere har Go-teamet ikke blot fokuseret på at opfylde FIPS 140-3-standarden, men har også egenhændigt forstærket sikkerheden.
Fail Fast
Go's FIPS-tilstand anvender en Fail Fast sikkerhedsmodel, der øjeblikkeligt afbryder eksekveringen med en panic, hvis en ikke-certificeret algoritme kaldes. I modsætning til provider-baserede modeller i andre sprog, som potentielt efterlader muligheden for fallback, leverer dette en strengere og mere utvetydig sikkerhedsgaranti med hensyn til sikkerhed og regulatorisk overholdelse.
Hedged Signature
FIPS 140-3-standarden anbefaler anvendelse af RFC6979-metoden ved ECDSA-signering. Go har imidlertid suppleret dette ved at introducere Hedged-metoden for at imødegå sidekanalangreb, der potentielt kan opstå under signeringsprocessen, med større robusthed.
Forbedret tilfældighedsgenerator
Go's tilfældighedsgenerator anvender en DRBG (Deterministic Random Bit Generator) i brugerområdet, men injicerer desuden entropi fra operativsystemets kerne for at generere tilfældige tal af høj kvalitet i såvel brugerområdet som kerneområdet. Dette medfører en yderligere forøgelse af sikkerheden for tilfældighedsgeneratoren.