Go-standardin kryptografiakirjaston FIPS 140-2- ja FIPS 140-3 -toteutusten rakenne

FIPS 140 ( Federal Information Processing Standard Publication 140 )

FIPS 140 on Yhdysvaltain NIST:n määrittelemä kryptografisten moduulien turvallisuuden sertifiointistandardi. Tämä standardi arvioi, täyttävätkö tietyt kryptografiset moduulit tai kirjastot NIST:n määrittelemät turvallisuusvaatimukset. Siten FIPS 140 -sertifioinnin läpäiseminen tarkoittaa, että kyseisellä moduulilla on virallisesti luotettava tietoturvataso, ja sitä voidaan käyttää turvallisuuden kannalta kriittisillä aloilla, kuten rahoituksessa, terveydenhuollossa ja puolustusteollisuudessa.

FIPS 140 on hyväksytty alun perin vuonna 1994, minkä jälkeen sitä on päivitetty: vuonna 2001 versioon FIPS 140-2 ja vuonna 2019 versioon FIPS 140-3. Edelleen nykyäänkin monet järjestelmät ja sovellukset edellyttävät FIPS 140-2- tai FIPS 140-3 -sertifiointia.

FIPS 140 ja ohjelmointielet

Tästä syystä FIPS 140 -sertifioidut kryptografiset moduulit ovat käytössä tosiasiallisina standardeina useissa ohjelmointielissä ja ympäristöissä. Esimerkkeinä mainittakoon OpenSSL, BoringSSL, LibreSSL ja NSS, jotka ovat laajimmin hyödynnettyjä moduuleja turvallisuuden kannalta kriittisissä sovelluksissa.

Suurin osa FIPS 140 -sertifioiduista moduuleista on kirjoitettu C- tai C++-kielellä. Tästä syystä kielet kuten PHP, Python ja JavaScript eivät käytä näitä moduuleja suoraan, vaan muodostavat FIPS-ympäristön ulkoisten Provider-moduulien välityksellä tapahtuvan integroinnin kautta. Tähän lähestymistapaan liittyy kuitenkin tiettyjä rajoituksia.

• Versioiden yhteensopimattomuusongelma

  FIPS 140 -sertifiointi myönnetään vain tietyille versioille. Siksi moduulin uusimman version käyttäminen edellyttää uutta sertifiointiprosessia, ja tämän prosessin aikana voi syntyä versioiden yhteensopimattomuus sovelluksen käyttämän moduulin ja FIPS-sertifioidun moduulin välille. Jos käytetään valtuuttamatonta versiota, kyseistä ympäristöä ei enää katsota FIPS-sertifioiduksi ympäristöksi.

• Dynaaminen lataus ja suorituskyvyn heikkeneminen

  Useimmat kielet lataavat FIPS 140 -sertifioidut moduulit dynaamisten kirjastojen muodossa ja käyttävät niitä siten. Tämä menetelmä voi aiheuttaa suorituskyvyn heikkenemistä alustuksen ja suorituksen aikana, ja ajonaikaisten ongelmien ilmetessä on olemassa riski, että ne vaikuttavat suoraan koko sovelluksen vakauteen.

• Tietoturvahaavoittuvuudet

  Kuten edellä mainittiin, rakenteessa, jossa käytetään ulkoisia moduuleja kuten OpenSSL Provideria, on riski siitä, että kyseisen moduulin tietoturvahaavoittuvuudet siirtyvät suoraan sovellukseen. Lisäksi itse sovelluksen ja ulkoisen moduulin välinen viestintäkerros muodostaa ylimääräisen hyökkäyspinnan, mikä edellyttää erillistä tietoturvakerrosta sen suojaamiseksi. Tämä lisää monimutkaisuutta ja synnyttää ennalta arvaamattomia haavoittuvuuksia.

FIPS 140 ja Golang

Tästä syystä Golang valitsi toisen strategian. Go valitsi lähestymistavan, jossa FIPS 140 -sertifiointi tuetaan suoraan virallisessa kryptografiakirjastossa ilman riippuvuutta ulkoisiin työkaluihin. Siksi kehittäjien ei tarvitse asentaa tai määrittää erillistä Provideria, vaan he voivat käyttää vakiomuotoista crypto-pakettia sellaisenaan ja pelkästään aktivoida FIPS-sertifiointitilan (GOFIPS=1). Tässä prosessissa viestintäraja ulkoisiin moduuleihin poistuu, mikä parantaa tietoturvaa, ja käyttö yksinkertaistuu, kun tarvitsee jakaa vain yksi staattisesti koottu binääritiedosto.

FIPS 140-2 ja Golang

Tämän saavuttamiseksi Golang sisällytti Go-ajonaikaiseen ympäristöön BoringSSL:stä johdetun BoringCrypto-moduulin ja saavutti FIPS 140-2 -sertifioinnin. BoringCrypto voidaan aktivoida tietyissä jakeluversioissa Go 1.19 -version jälkeen, minkä ansiosta Go-sovellukset voivat muodostaa FIPS 140-2 -sertifioidun ympäristön ilman erillisiä ulkoisia moduuleja.

Koska BoringCrypto perustuu OpenSSL:ään, siihen liittyy kuitenkin edelleen C-kielen riippuvuus. Siksi Go-sovelluksia ei voitu rakentaa täysin itsenäisiksi binääritiedostoiksi, ja rajoituksena oli tarve jakaa tarvittavat C-kirjastot mukana.

FIPS 140-3 ja Golang

Näiden rajoituksien voittamiseksi Go-tiimi paransi olemassa olevaa Go-standardin crypto-kirjastoa FIPS 140-3 -spesifikaation mukaiseksi. Tämä parannettu moduuli on ollut saatavilla kokeellisesti Go 1.21 -versioista alkaen, ja NIST:n FIPS 140-3 -sertifiointiarviointi on parhaillaan käynnissä.NIST FIPS 140-3 -arvioinnissa olevien moduulien luettelo

Tämä osoittaa Go-kryptografiakirjaston kypsyyttä, ja sen myötä Go pystyy tarjoamaan FIPS 140-3 -sertifioidun ympäristön täysin itsenäisenä yksittäisenä binääritiedostona.

Lisäksi Go-tiimi ei tyytynyt pelkästään FIPS 140-3 -standardin täyttämiseen, vaan se vahvisti tietoturvaa itsenäisesti.

• Fail Fast

  Go:n FIPS-tila soveltaa Fail Fast -tietoturvamallia, joka pysäyttää suorituksen välittömästi panic-tilalla, jos kutsutaan sertifioimatonta algoritmia. Toisin kuin muiden kielten Provider-pohjaiset mallit, jotka jättävät varajärjestelmän (fallback) mahdollisuuden, tämä tarjoaa tiukemman ja selkeämmän takuun tietoturvan ja säännösten noudattamisen osalta.

• Hedged Signature

  FIPS 140-3 -standardi suosittelee RFC6979-menetelmää ECDSA-allekirjoituksissa. Go on kuitenkin ottanut käyttöön tämän lisäksi Hedged-menetelmän, joka torjuu tehokkaammin sivukanavahyökkäykset, joita saattaa esiintyä allekirjoitusprosessin aikana.

• Vahvistettu satunnaislukugeneraattori

  Vaikka Go:n satunnaislukugeneraattori käyttää käyttäjätilan DRBG:tä (Deterministic Random Bit Generator), se syöttää siihen lisäksi entropiaa käyttöjärjestelmän ytimestä, mikä tuottaa korkealaatuisia satunnaislukuja paitsi käyttäjätilassa myös ydintilassa. Tämän kautta satunnaislukugeneraattorin tietoturvaa vahvistetaan entisestään.