Omat kryptografiset kehitelmät (syventävä)¶

Omien kehitelmien haasteet¶

Tässä pääluvussa on käsitelty monipuolisesti mutta melko abstraktisti algoritmeja. On raotettu myös joitain yksityiskohtia ja esille toivottavasti on tullut sen verran tietoa myös toteutuksesta, että lukijalle ei vielä tule houkutusta ruveta omin päin toteuttamaan kryptografiaa mihinkään todelliseen järjestelmään edes krypto-APIn kautta. Moni sitä ilmeisesti yrittää ja tunnettuja lähestymistapoja varmasti turvalliseen kryptografiaan ovat “lihamylly”, “suuret avaimet” ja “ystävällinen analyysi”. Keittiövertaus liittyy kehitelmiin, joissa käytetään mahdollisesti tunnettuja palikoita, mutta joka tapauksessa sovelletaan “riittävän” monia moduuleja ja niiden kierroksia, jotta bitit varmasti sekoittuvat. Vastaavasti suuri avainavaruus poistaa ainakin raa’an voiman hyökkäyksen, mutta samoin kuin mylly se vähintään heikentää suorituskykyä. Ystävällinen analyysi tarkoittaa, ettei algoritmia tai protokollaa alisteta tiede- tai teknologiayhteisön tarkasteltavaksi, joten haavoittuvuudetkin jäävät piiloon. Kontribuution lähettäminen kryptokonferensseihin tai vastaaviin olisi kuitenkin ajanhukkaa sekä kirjoittajalle että arvioijille, sillä parannusten aikaansaaminen tai uuden keksiminen on hyvin epätodennäköistä ilman että on kouluttautunut kryptologiassa ja jo seurannut tutkimuksen edistymistä.

Haasteisiin vastaaminen¶

Tämän pääluvun oppimistavoitteena on ollut kryptografian ymmärtäminen, joten mihin sitä tarvitaan, jos osaamista vähän kehittämällä ei voisi myös päästä toteuttamaan kryptoa? Kysyntää sellaiselle kuitenkin olisi. Jos olet lukenut tähän asti, vastaus juuri tuohon kysymykseen lienee tullut selville. Tarkastellaan sen sijaan, miten turhia ja turvattomia omia kehitelmiä voi välttää.

Ensinnäkin perusalgoritmit ovat nykyisellään riittävän turvallisia pitkälle tulevaisuuteen, ja krypto-APIt tarjoavat hyviä toteutuksia niille. Nämä seikat on jo edellä todettukin. Mistä saa asiantuntemusta, kun yrityksen tuotteessa kuitenkin pitäisi kryptografiaa toteuttaa?

Jos oma tietämys yrityksessä on kovin rajattua, on syytä palkata ammattilainen, jolla on näyttöä osaamisesta. Lievempää sitoutumista voi toteuttaa konsultoimalla yrityksiä, jotka tarjoavat tällaista palvelua. Niidenkin mainetta kannattaa arvioida etukäteen esim. referenssien kautta, siis kyselemällä aiemmilta asiakkailta.

Jos yrityksessä jo on kryptologi, hän voi täydentää tietämystään julkaisuista, kunhan ne ovat riittävän laadukkaita. Krypto-osasto StackExchange-sivustolla on laaja, mutta sieltä on vaikea erottaa päteviä neuvoja. Wikipediassa on erittäin runsaasti kryptoaineistoa, ja se voi hyvin toimia lähteenä tämän kurssin jälkeisille opinnoille ennen vaativampia kursseja. Tieteellisten julkaisujenkin tapauksessa kannattaa noudattaa lähdekritiikkiä.

Suurten yritysten kannattaa hankkia kryptografian ammattilaisista koostuva tiimi, joka osallistuu krypton toteuttamiseen ja ainakin tarkastaa kaiken kryptografiaan liittyvän yrityksen tuotteissa.

Yritys voi myös hankkia kryptoa palveluna samalla periaatteella kuin ohjelmistoratkaisujakin. Jälkimmäisiä saa tunnetusti SaaS-pilvipalveluna, ja sitä uudempi käsite on CaaS eli Cryptography as a Service. Erityisen tärkeää se voi olla avaintenhallinnan toteuttamisessa. Se voi olla oleellisesti turvallisempaakin kuin pienen yrityksen resursseilla muuten olisi mahdollista, jos otetaan käyttöön palveluntarjojan ylläpitämä HSM.

Kryptografian tekeminen käyttäjälle näkymättömäksi¶

Tietojärjestelmien suunnittelussa pitäisi pyrkiä siihen, että käyttäjien ei tarvitse valita kryptografisia parametreja—erityisesti sitä, salataanko jokin yhteys vai ei, tai hyväksytäänkö yhteys palvelimeen, jonka varmenne ei ole kunnossa. Asioiden hoitaminen näyttää joskus vaativan tyytymisen heikkoon turvallisuuteen, mutta tällöin asianhoitovälineen, esim. verkkoselaimen tai viestimen, pitäisi estää arkaluonteisen tiedon käsittely. Tällaista ei vielä tapahdu kuluttajasovelluksissa, mutta se olisi mahdollinen kompromissi suhteessa siihen, että yhteys estettäisiin kokonaan. Sähköpostien suodatus tarjoaa jo esimerkin, vaikka erottelu tapahtuukin välillä “spam–ham” (eli roska poistetaan) eikä välillä “ham–caviar” (eli arvotietoja ei lähetettäisi salaamattomina). Yrityksissä on jo käytössä DLP-sovelluksia (data leak prevention), joilla arkojen tietojen liikkeitä rajoitetaan automaattisesti. Oleellista tässä ideassa on se, että kryptografinen suojaus olisi kaikessa oletuksena eikä sen käynnissä oloa tarvitsisi käyttäjän todeta. Vain poikkeaminen näkyisi ja jos se sallittaisiin, käyttäjä ikään kuin sammuttaisi valot ja koko ajan tietäisi etenevänsä pimeässä.