FIPS 140 -sertifiointi ja Golang

FIPS 140 ( Federal Information Processing Standard Publication 140 )

FIPS 140 on Yhdysvaltain NISTin vahvistama kryptomoduulien turvallisuussertifiointistandardi. Tämä standardi arvioi, täyttääkö tietty kryptomoduuli tai kirjasto NISTin määrittelemät turvallisuusvaatimukset. Siksi FIPS 140 -sertifioinnin läpäiseminen tarkoittaa, että kyseisellä moduulilla on virallisesti luotettava tietoturva, ja sitä voidaan käyttää turvallisuuskriittisillä aloilla, kuten rahoituksessa, terveydenhuollossa ja maanpuolustuksessa.

FIPS 140 hyväksyttiin alun perin vuonna 1994, ja se uudistettiin FIPS 140-2:ksi vuonna 2001 ja FIPS 140-3:ksi vuonna 2019. Tähän päivään mennessä monet järjestelmät ja sovellukset edellyttävät edelleen FIPS 140-2- tai FIPS 140-3 -sertifiointia.

FIPS 140 ja ohjelmointikielet

Tästä syystä FIPS 140 -sertifioituja kryptomoduuleja käytetään de facto -standardina useissa ohjelmointikielissä ja ympäristöissä. Esimerkkejä ovat OpenSSL, BoringSSL, LibreSSL ja NSS, jotka ovat laajimmin käytettyjä moduuleja turvallisuuskriittisissä sovelluksissa.

Suurin osa FIPS 140 -sertifioiduista moduuleista on kirjoitettu C:llä tai C++:lla. Tämän vuoksi kielet kuten PHP, Python ja Javascript konfiguroivat FIPS-ympäristön integroimalla nämä moduulit ulkoisten Provider-moduulien kautta suoran käytön sijaan. Tähän lähestymistapaan liittyy kuitenkin joitakin rajoituksia.

• Versioiden yhteensopimattomuusongelmat

  FIPS 140 -sertifiointi myönnetään vain tietyille versioille. Siksi moduulin uusimman version käyttäminen edellyttää uutta sertifiointiprosessia, ja tässä prosessissa voi syntyä versioiden yhteensopimattomuutta sovelluksen käyttämän moduulin ja FIPS-sertifioidun moduulin välille. Jos käytetään valtuuttamatonta versiota, kyseistä ympäristöä ei enää pidetä FIPS-sertifioituna ympäristönä.

• Dynaaminen lataus ja suorituskyvyn heikkeneminen

  Useimmat kielet lataavat ja käyttävät FIPS 140 -sertifioituja moduuleja dynaamisina kirjastoina. Tämä menetelmä voi aiheuttaa suorituskyvyn heikkenemistä alustus- ja suoritusprosessin aikana, ja jos suorituksen aikana ilmenee ongelmia, se voi suoraan vaikuttaa koko sovelluksen vakauteen.

• Turvallisuusheikkoudet

  Kuten edellä mainittiin, ulkoisten moduulien, kuten OpenSSL Providerin, integrointiin perustuvassa rakenteessa on riski, että kyseisten moduulien turvallisuusheikkoudet leviävät suoraan sovellukseen. Lisäksi sovelluksen ja ulkoisten moduulien välinen kommunikaatiokerros itsessään muodostaa lisähyökkäyspinnan, ja sen suojaamiseen tarvitaan erillinen turvallisuuskerros. Tämä lisää monimutkaisuutta ja voi aiheuttaa odottamattomia haavoittuvuuksia.

FIPS 140 ja Golang

Näistä syistä Golang omaksui toisen strategian. Go valitsi tavan, jossa FIPS 140 -sertifiointi tuetaan suoraan virallisessa kryptografisessa kirjastossa ilman riippuvuutta ulkoisista työkaluista. Näin ollen kehittäjän tarvitsee vain aktivoida FIPS-sertifioitu tila (GOFIPS=1) käyttäessään standardia crypto-pakettia ilman erillisen Providerin asennusta tai konfigurointia. Tässä prosessissa ulkoisten moduulien kanssa kommunikoinnin raja poistuu, mikä parantaa turvallisuutta, ja käyttö yksinkertaistuu, koska jakeluun tarvitaan vain yksi staattisesti käännetty binaaritiedosto.

FIPS 140-2 ja Golang

Tätä varten Golang sisällytti BoringSSL:stä johdetun BoringCrypto-moduulin Go-ajonaikaiseen ympäristöön saavuttaakseen FIPS 140-2 -sertifioinnin. BoringCrypto voidaan aktivoida tietyissä Go 1.19 -version jälkeisissä jakeluissa, mikä mahdollistaa Go-sovellusten FIPS 140-2 -sertifioidun ympäristön konfiguroinnin ilman erillisiä ulkoisia moduuleja.

Koska BoringCrypto kuitenkin perustuu OpenSSL:ään, sillä on edelleen riippuvuuksia C-kieleen. Siksi Go-sovelluksia ei voitu rakentaa täysin itsenäisiksi binaareiksi, ja niillä oli rajoitus, että tarvittavat C-kirjastot oli jaettava niiden mukana.

FIPS 140-3 ja Golang

Go-tiimi on näiden rajoitusten voittamiseksi parantanut olemassa olevaa Go-standardin crypto-kirjastoa FIPS 140-3 -spesifikaation mukaisesti. Tämä parannettu moduuli on ollut saatavilla kokeellisesti Go 1.21 -versiosta lähtien, ja NISTin FIPS 140-3 -sertifiointiarviointi on parhaillaan käynnissä.NIST FIPS 140-3 -arviointiprosessissa olevien moduulien luettelo

Tämä osoittaa Go-kryptografiakirjaston kypsyyttä, ja sen avulla Go voi tarjota FIPS 140-3 -sertifioidun ympäristön täysin itsenäisenä binaaritiedostona.

Lisäksi Go-tiimi ei tyytynyt pelkästään FIPS 140-3 -standardin täyttämiseen, vaan vahvisti omaa turvallisuuttaan.

• Fail Fast

  Go:n FIPS-tila soveltaa Fail Fast -tietoturvamallia, joka keskeyttää suorituksen välittömästi panic-tilalla, jos vahvistamaton algoritmi kutsutaan. Toisin kuin muiden kielten Provider-pohjaiset mallit, jotka jättävät mahdollisuuden fallback-ratkaisuille, tämä tarjoaa tiukemman ja selkeämmän takuun turvallisuuden ja sääntelyn noudattamisen osalta.

• Hedged Signature

  FIPS 140-3 -standardi suosittelee RFC6979-menetelmää ECDSA-allekirjoituksissa. Go kuitenkin ottaa käyttöön lisäksi Hedged-menetelmän, joka parantaa vastustuskykyä allekirjoitusprosessin aikana mahdollisesti ilmeneviä sivukanavahyökkäyksiä vastaan.

• Parannettu satunnaislukugeneraattori

  Go:n satunnaislukugeneraattori käyttää käyttäjätilan DRBG:tä (Deterministic Random Bit Generator) ja syöttää lisäksi entropiaa käyttöjärjestelmän ytimeen, mikä tuottaa korkealaatuisia satunnaislukuja sekä käyttäjätilassa että ytimen tilassa. Tämä parantaa entisestään satunnaislukugeneraattorin turvallisuutta.