Yleisimmät kryptografian väärinkäyttömallit

Electronic Codebook (ECB) -tila salaa jokaisen lohkon itsenäisesti samalla avaimella. Samanlaiset selkotekstilohkot tuottavat samanlaiset salatekstilohkot. Tunnettu esimerkki on "ECB-pingviini": kun bittikarttakuva salataan ECB-tilassa, kuvan lohkotason rakenne säilyy, joten pingviinin ääriviivat näkyvät selvästi salatekstissä. ECB-tila ei tarjoa semanttista tietoturvaa, eikä sitä pidä koskaan käyttää mihinkään käytännön salaustarkoitukseen.

Kryptografisten primitiivien toteuttaminen alusta alkaen on yksi ohjelmistokehityksen vaarallisimmista käytännöistä. Kryptografiassa vaaditaan täydellistä oikeellisuutta vastustajan toiminnan alaisissa olosuhteissa: hienovarainen ajoitusvuoto, täytteen yhden kohdan virhe tai tietoturvavaatimusten väärinymmärtäminen voi luoda hyödynnettävän haavoittuvuuden, jota ei tavallisissa testeissä voi erottaa oikeasta toiminnasta. Jopa kokeneet kryptografit tekevät toteutusvirheitä, joten sovelluskehittäjien tulisi käyttää yksinomaan perusteellisesti tarkastettuja kirjastoja.

MD5:n törmäyskestävyys on murrettu vuodesta 2004 lähtien, ja kahden saman MD5-tiivisteen tuottavan tiedoston luominen on laskennallisesti triviaalia. SHA-1:n törmäyshyökkäykset osoitettiin käytännössä Googlen vuonna 2017 tekemässä SHAttered-hyökkäyksessä, jossa tuotettiin kaksi PDF-tiedostoa, joilla oli sama SHA-1-tiiviste. Kumpaakaan ei pidä käyttää mihinkään turvallisuustarkoitukseen: digitaalisiin allekirjoituksiin, sisällön eheyden varmistamiseen, salasanojen tallennukseen tai HMACiin. Käyttäkää nykyaikaisissa toteutuksissa SHA-256:ta, SHA-3:a tai BLAKE2:ta.

time()-funktion tai muiden ennustettavien arvojen käyttäminen näennäissatunnaislukugeneraattorin siemenenä on kriittinen haavoittuvuus, kun PRNG:n tulosta käytetään turvallisuustarkoituksiin. Hyökkääjä, joka tietää suunnilleen, milloin avain luotiin, voi kokeilla kaikki mahdolliset siemenet pienellä aikavälillä ja palauttaa avaimen. Tunnettu esimerkki on Netscapen varhaiset versiot, jotka siemensivät SSL-avainten luonnin ajalla ja prosessitunnisteella; hyökkääjä samassa koneessa saattoi havaita molemmat.

C:n rand(), java.util.Random ja Pythonin random-moduuli käyttävät deterministisiä lineaarisia kongruenssigeneraattoreita tai Mersenne Twisteriä, jotka on suunniteltu simulaatioiden tilastollista laatua, ei tietoturvaa, varten. Riittävän monta tulosta nähnyt hyökkääjä voi palauttaa generaattorin sisäisen tilan ja ennustaa kaikki tulevat tulokset. Käyttäkää turvallisuustarkoituksiin käyttöjärjestelmän tarjoamia CSPRNG:iä: Pythonissa secrets.token_bytes(), Node.js:ssä crypto.randomBytes() tai Linuxissa /dev/urandom.

Autentikoinnilla varmistamaton salaus tarjoaa vain luottamuksellisuuden, ei eheyttä. Hyökkääjä, joka ei pysty lukemaan selkotekstiä, voi silti muokata salatekstiä ja mahdollisesti aiheuttaa ennustettavia muutoksia selkotekstiin, erityisesti CTR- tai CBC-tilassa. Tämä muokattavuus mahdollistaa hyökkäyksiä: salattua pankkisiirtoa sieppaava hyökkääjä voi kääntää bittejä ja muuttaa siirtosummaa tai kohdetiliä tietämättä selkotekstiä. Käyttäkää aina todennettua salausta (AEAD).

Salausavainten tai alustusvektoreiden kovakoodaus lähdekoodiin on kriittinen haavoittuvuus. Lähdekoodia tallennetaan usein versionhallintavarastoihin, jotka voivat joskus olla julkisia. Yksityisissäkin varastoissa avain on kaikilla, joilla on pääsy koodiin. Kovakoodatut avaimet tarkoittavat, että kaikki instanssit käyttävät samaa avainta ja että avaimen kierto edellyttää uuden käyttöönoton. Avaimet on tallennettava ympäristömuuttujiin, salaisuuksien hallintajärjestelmiin (HashiCorp Vault, AWS Secrets Manager) tai laitteistoturvamoduuleihin.

Saman alustusvektorin käyttäminen useisiin salauksiin samalla avaimella aiheuttaa vakavia haavoittuvuuksia. CTR-tilassa IV:n uudelleenkäyttö tuottaa saman avainvirran, mikä mahdollistaa selkotekstin palauttamisen XOR-operaatiolla. CBC-tilassa IV:n uudelleenkäyttö auttaa hyökkääjää havaitsemaan, milloin kaksi viestiä alkaa samoilla selkotekstilohkoilla. GCM-tilassa nonce-arvon (IV:n) uudelleenkäyttö on katastrofaalista (katso nonce-arvojen uudelleenkäyttöä käsittelevä oppitunti). Luokaa jokaiselle salaustoiminnolle uusi satunnainen IV ja sijoittakaa se salatekstin alkuun, jotta se voidaan tallentaa salauksen purkuyhteyden kanssa.

Salasanojen tallentaminen MD5:llä, SHA-256:lla tai millä tahansa muulla nopealla kryptografisella hajautusfunktiolla ei ole riittävän turvallista. Nykyaikaiset GPU:t voivat laskea miljardeja SHA-256-tiivisteitä sekunnissa, joten varastettuihin tiivistetietokantoihin kohdistuvat offline-raaka voima -hyökkäykset voidaan suorittaa erittäin nopeasti. Salasanojen hajautukseen tarvitaan tarkoitukseen suunniteltuja hitaita ja muistivaativia funktioita: bcrypt, scrypt tai Argon2id. Ne on suunniteltu tekemään raakavoimahyökkäyksistä kalliita myös erikoislaitteistoa käytettäessä, jolloin offline-hyökkäykset ovat laskennallisesti käytännössä mahdottomia.

SSL/TLS-varmenteen validoinnin poistaminen käytöstä (ssl.CERT_NONE-asetuksen määrittäminen Pythonissa, -k-vivun välittäminen curlille, trustAllCerts=true-asetuksen määrittäminen Androidissa) poistaa suojan välimieshyökkäyksiä vastaan. Hyökkääjä voi esittää minkä tahansa varmenteen ja siepata kaiken viestinnän. Tätä käytäntöä esiintyy kehityksessä itse allekirjoitettujen varmenteiden virheiden ohittamiseksi, mutta se säilyy usein tuotannossa. Käyttäkää aina asianmukaista varmenteiden validointia ja korjatkaa taustalla olevat varmenneongelmat oikealla tavalla.

Kryptografiset funktiot ilmoittavat virheistä paluuarvoilla tai poikkeuksilla. Niiden sivuuttaminen sallii suorituksen jatkumisen virheellisessä tilassa: salauksen purku on tuottanut virheellistä dataa, varmennus on epäonnistunut tai avainten luonti on tuottanut virheen. C-pohjaisissa rajapinnoissa, kuten OpenSSL:ssä, paluuarvojen sivuuttaminen on erityisen vaarallista, koska ohjelma voi jatkaa alustamattoman muistin käytöllä. Tarkistakaa aina kryptografisten funktioiden kaikki paluuarvot ja käsitelkää virheet turvallisesti.

Tärkeimmät vältettävät väärinkäyttötavat: älkää koskaan käyttäkö ECB-tilaa (lohkojen rakenteen vuotaminen), älkää toteuttako kryptografisia primitiivejä itse, hylätkää MD5 ja SHA-1 turvallisuuskäytössä, siementäkää PRNG CSPRNG:llä time()-funktion sijaan, käyttäkää CSPRNG:tä kaikkeen turvallisuuden kannalta tärkeään satunnaisuuteen, todentakaa salattu data aina (AEAD), älkää koskaan kovakoodatko avaimia tai IV:itä, luokaa jokaiselle salaukselle uusi IV, käyttäkää salasanoihin Argon2id:tä nopeiden hajautusfunktioiden sijaan, validoikaa TLS-varmenteet aina ja tarkistakaa jokainen kryptografinen paluuarvo.