Kryptografisten riippuvuuksien auditointi ja valinta

Valitsemanne salauskirjasto on yksi projektin merkittävimmistä tietoturvapäätöksistä. Vaikka kehittäjät toimisivat hyvässä uskossa, he voivat huonon kirjaston avulla tuottaa turvattomia järjestelmiä. Hyvin suunniteltu kirjasto puolestaan vaikeuttaa vakavien virheiden tekemistä. Valintaprosessin tulisi olla järjestelmällinen, ja siinä tulisi arvioida kirjaston tietoturvahistoriaa, API-suunnittelua, ylläpidon tilaa ja soveltuvuutta käyttötarkoitukseen.

Yksi ensimmäisistä salauskirjastoa koskevista kysymyksistä on, milloin se on viimeksi auditoitu riippumattomasti ja mitä auditointi kattoi. Viisi vuotta sitten versiolle 1.0 tehty auditointi antaa vähemmän varmuutta nykyisin käytettävästä versiosta 3.0. Etsikää hyvämaineisten tietoturvayritysten, kuten NCC Groupin, Trail of Bitsin, Quarkslabin ja Cure53:n, tekemiä auditointeja, jotka kattavat juuri ne toiminnallisuudet, joita aiotte käyttää. Jotkin kirjastot julkaisevat auditointiraportit avoimesti; auditointien täydellinen puuttuminen on merkittävä riskitekijä.

Tarkistakaa kirjaston CVE-historia NVD:stä (National Vulnerability Database). Tarkastelkaa seuraavia asioita: CVE-tapausten määrää, niiden vakavuusluokituksia, sitä, millaisia haavoittuvuuksia ne edustavat (logiikkavirheitä, muistivaurioita vai algoritmien heikkouksia), sekä sitä, kuinka nopeasti ylläpitäjät julkaisivat korjaukset. Kirjasto, jossa esiintyy ajoittain nopeasti korjattavia CVE-haavoittuvuuksia, osoittaa ylläpidon reagoivan hyvin. Kirjasto, jossa on paljon vakavia CVE-haavoittuvuuksia tai jonka korjausten julkaiseminen on hidasta, on varoitusmerkki.

Ylläpitämättömät salauskirjastot ovat vaarallisia. Tarkistakaa viimeisimmän commitin päivämäärä, julkaisutiheys ja se, käsitelläänkö tietoturvatiedotteissa ilmoitettuja ongelmia. Kirjastossa, jonka viimeisin commit on kolmen vuoden takaa, voi olla tunnettuja haavoittuvuuksia, joita ei koskaan korjata. Yhteisön koolla on merkitystä tarkastelun laajuuden kannalta: tietoturvatutkijat tarkastelevat laajasti käytettyjä kirjastoja perusteellisemmin kuin pieniä erikoisprojekteja.

Suppeampi ja vahvemmin kantaa ottava API-pinta on tietoturvan kannalta parempi. Kirjastot, jotka tarjoavat paljon algoritmivaihtoehtoja ja määritysasetuksia, luovat mahdollisuuksia virheellisiin asetuksiin. Verratkaa libsodiumia (yksi funktio käyttötapausta kohden, kiinteä algoritmi) OpenSSL EVP:hen (salausalgoritmi, toimintatila, avaimen koko, täyte ja IV:n käsittely valitaan erikseen). Mitä vaikeampaa kirjaston virheellinen käyttö on, sitä paremmin se soveltuu tietoturvatietoisiin projekteihin.

Salaisia tietoja käsittelevissä toiminnoissa, kuten avainten vertailussa, salauksen purkamisessa ja allekirjoitusten varmentamisessa, toteutuksen on käytettävä vakioaikaisia algoritmeja, jotka eivät tee haarautumisia eivätkä käytä muistia salaisten arvojen perusteella. Varmistakaa, että kirjaston dokumentaatiossa ilmoitetaan nimenomaisesti arkaluontoisten toimintojen vakioaikaiset takuut tai että lähdekoodissa käytetään hyväksyttyjä vakioaikaisia vertailufunktioita. Kirjastot, jotka eivät tarjoa tällaista takuuta, ovat alttiita ajoitukseen perustuville sivukanavahyökkäyksille.

Hyvän salauskirjaston tulisi tukea nykyaikaisia algoritmeja ja valmistautua vanhentuneiden algoritmien poistamiseen käytöstä. Sen tulisi tarjota salaukseen ChaCha20-Poly1305 tai AES-256-GCM, allekirjoituksiin Ed25519 tai ECDSA P-256, avaintenvaihtoon X25519 ja salasanojen hajautukseen Argon2id. Kirjastot, jotka tarjoavat vain vanhoja algoritmeja (DES, RC4, MD5, SHA-1), eivät sovellu uusiin käyttöönottoihin muista ominaisuuksistaan riippumatta.

Arvioikaa transitiviset riippuvuudet: mistä kirjastoista salauskirjastonne riippuu ja millainen niiden tietoturvan taso on? Kirjastolla, jolla ei ole ulkoisia riippuvuuksia, kuten libsodiumilla, on toimitusketjun kannalta vain vähän riskejä. Kirjastolla, joka riippuu tusinasta npm-paketista ja jonka jokaisella paketilla on omat riippuvuutensa, on toimitusketjun kautta laaja hyökkäyspinta. Tarkistakaa, käyttääkö kirjasto toistettavia koontiversioita, joiden avulla voidaan varmistaa, että jaeltu binääri vastaa lähdekoodia.

Säännellyillä toimialoilla, kuten terveydenhuollossa, rahoitusalalla ja julkishallinnossa, edellytetään usein FIPS 140-2- tai FIPS 140-3 -standardin mukaisesti validoituja salausmoduuleja. FIPS-validointi on kallista ja aikaa vievää, joten vain osalla kirjastoista on se. OpenSSL FIPS-providerin kanssa, BoringCrypto (Go:n crypto/tls:n käyttämä) ja jotkin HSM-kirjastot ovat FIPS-validoituja. Jos käyttöönottonne edellyttää FIPS-vaatimustenmukaisuutta, tämä vaatimus rajaa kirjastovaihtoehtoja huomattavasti.

Hardware Security Modules (HSM:t) ja pilvipalveluiden KMS-palvelut käyttävät avaintoimintoihin usein omia rajapintojaan. Sovelluksen tiivis kytkeminen AWS KMS:ään tai tietyn HSM-toimittajan ratkaisuun aiheuttaa toimittajaloukun riskin. Arvioikaa, tarjoaako kirjasto abstraktiokerroksia, kuten Tinkin KMS-integraation, joiden avulla palveluntarjoajaa voidaan vaihtaa. Huomioikaa myös, että jos HSM-toimittaja lopettaa tuen tai korottaa hintoja, siirtymiskustannukset voivat olla huomattavat.

Tärkein sääntö salausriippuvuuksia valittaessa on käyttää tunnettuja ja laajasti käyttöönotettuja kirjastoja, jotka toteuttavat vakiintuneita standardeja, eikä koskaan toteuttaa salausprimitiivejä itse. Vaikka ymmärtäisitte teorian kuinka hyvin tahansa, AES:n, RSA:n, elliptisten käyrien operaatioiden tai todennetun salauksen toteuttaminen oikein tuotantokoodissa on erittäin vaikeaa, eikä se lähes koskaan ole todistetun kirjaston käyttämiseen verrattuna riskin arvoista.

Kirjaston valinnan tarkistuslista: tarkistakaa viimeaikaisen riippumattoman auditoinnin laajuus ja raportti, tarkastelkaa CVE-historiaa ja korjausten julkaisemiseen kuluvaa aikaa, varmistakaa aktiivinen ylläpito ja yhteisön osallistuminen, suosikaa väärinkäyttöä rajoittavia suppeampia API-pintoja, varmistakaa arkaluontoisten toimintojen vakioaikaiset takuut, varmistakaa nykyaikaisten algoritmien tuki, arvioikaa toimitusketjun riippuvuudet, tarkistakaa FIPS-validointi säännellyillä toimialoilla, huomioikaa KMS-toimittajaloukun riski ja käyttäkää aina vakiintuneita kirjastoja sen sijaan, että toteuttaisitte primitiivit itse.