Sovellettu kryptografia kentällä (syventävä)

Edellä krypto on esitelty enimmäkseen “bottom-up”, joskin esim. varsin keskeinen sovellusalue matkapuhelujen salaus on tullut esille. Tässä luvussa tarkastellaan kolmea muuta sovellusaluetta.

TLS, Transport Layer Security

TLS-protokolla on jo tullut mainituksi useita kertoja ohimennen. Protokollalla on pitkä historia, ja versio 1.3 valmistui vuonna 2018. TLS on monimutkainen protokolla, jossa on kolme toisiinsa liittyvää aliprotokollaa: kättely eli TLS Handshake Protocol käyttää (yleensä) epäsymmetristä algoritmia istuntoavainten muodostamiseen. Niitä käyttää sovellusdatan salaamiseen ja autentikointiin TLS Record Protocol. TLS Alert Protocol kuljettaa hallintatietoja ja virheilmoituksia. (Lisää tekniikkaa on verkkoturvan luvussa.) Nykyään TLS suojaa noin 95 % kaikesta HTTP-liikenteestä, ja siinä TLS käyttää web-PKI:tä palvelinten autentikointiin.

TLS 1.3 edustaa IETF:n puitteissa työskentelevien, eri tahoja edustavien insinöörien ja tutkijoiden monivuotista yritystä rakentaa yleiskäyttöinen turvallinen viestintäprotokolla. Työn aloittamisen tärkeimmät syyt olivat ensinnäkin aiemman version turvallisuuden parantaminen päivittämällä perusrakenne ja poistamalla vanhentuneet kryptografiset primitiivit ja toiseksi suorituskyvyn parantaminen vähentämällä suojatun yhteyden muodostamisessa tarvittavien viestinvaihtojen määrää. TLS:n aiemmissa versioissa tarvittiin kaksi vaihtoa (neljä viestiä), kun taas TLS 1.3:ssa useimmiten tarvitaan vain yksi (kaksi viestiä). Yhteys voidaan saada käyntiin suoraankin jos avaimet on muodostettu edellisessä istunnossa.

Tärkeä ero TLS 1.3:n suunnitteluprosessissa aiempaan verrattuna on laaja turvautuminen muodolliseen turvallisuusanalyysiin. Tämä johti useisiin tutkimusjulkaisuihin ja osa analyysista löysi puutteita protokollan aiemmissa versioissa, mikä vaikutti protokollan suunnitteluun ratkaisevalla tavalla. Esimerkkinä tästä on HKDF:n käyttö johdonmukaisella, hierarkkisella tavalla avainmateriaalin käsittelyssä. Protokollaa myös muutettiin, jotta se soveltuisi paremmin muodolliseen analyysiin. TLS 1.3 on lähes täydellinen menestystarina siitä, kuinka yliopistot ja teollisuus voivat työskennellä yhdessä. Prosessia ja lopputulosta voidaan arvostella varsin vähän:

• Kaikkia tietoturvan ja toiminnallisuuden vaatimuksia ei saatu heti esille, mikä merkitsi monia muutoksia matkan varrella ja haasteita analyysia tekeville tutkijoille. Tällainen iteratiivinen lähestymistapa näyttää kuitenkin olevan väistämätön monimutkaisessa protokollassa, jonka on tarkoitus palvella monia käyttötapauksia.
• Muodollisesta analyysista jäi puuttumaan muutama erikoistapaus, etenkin sellainen, jossa todennus perustuu ennalta jaettuihin symmetrisiin avaimiin. Myöhemmin (2019) löydettiin hyökkäys yhdessä tähän liittyvässä tilanteessa.
• TLS 1.3:n suora käynnistäminen (zero round trip mode) on houkuttelevan nopea, mutta siinä menetetään jatkosuojaus. Toistohyökkäyksiä vastaan puolustautuminen tässä tilassa on yleensäkin vaikeaa ja todennäköisesti mahdotonta hajautetun palvelimen ja tyypillisten selainten tapauksessa. Tutkimuksissa on jo tehty aloitteita jatkosuojauksen lisäämiseksi tähän tilaan.

Suojatut pikaviestimet

Ensi näkemältä pikaviestimet vaativat samanlaista turvallisuutta kuin TLS tarjoaa: kommunikoivat osapuolet haluavat pareittain vaihtaa viestejä turvallisesti. On kuitenkin merkittäviä eroja, jotka johtavat erilaisiin kryptografisiin ratkaisuihin. Ensinnäkin pikaviestimet ovat asynkronisia, mikä merkitsee jo sitä, että osapuolet eivät voi helposti käyttää TLS Handshake Protocol -protokollaa symmetristen avainten muodostamiseksi. Toiseksi, ei ole olemassa web-PKI:tä vastaavaa infrastruktuuria, jota voitaisiin hyödyntää autentikointiin. Kolmanneksi, ryhmäviestintä on tärkeä käyttötapaus pariviestinnän rinnalla. Neljänneksi, käytössä on yleensä erityinen palvelin, jota käytetään viestien välittämiseen, eikä sillä saisi olla pääsyä viestien sisältöön.

Tarkastellaan kolmea erilaista pikaviestinjärjestelmää: Applen iMessage, WhatsAppin Signal ja Telegram. Keskitytään vain kahden osapuolen viestintään.

Apple iMessage

Applen iMessage-järjestelmä käytti aiemmin allekirjoitus-salaus -järjestelmää, josta löydettiin merkittäviä haavoittuvuuksia vuonna 2016. Tämä tapahtui siitä huolimatta, että allekirjoitus-salaus (signcryption) on hyvin tunnettu ja mallinnettu kryptoprimitiivi, ja taustalla oli yleisiä, turvallisiksi todistettuja julkisen avaimen salauksen ja allekirjoituksen rakenteita. On päätelty, että suunnittelijat joutuivat käyttämään Applen kryptokirjastossa saatavilla olleita toteutuksia. Päätelmä ja muu järjestelmän analyysi perustuu takaisinmallinnukselle, sillä iMessage-toteutus ei ole avointa koodia. Se tiedetään, että järjestelmä perustui täysin Applen palvelimiin kohdistuneeseen luottamukseen sen jaellessa käyttäjien julkisia avaimia. Järjestelmä oli myös suunniteltu päästä-päähän -turvalliseksi. Ilman aktiivista avainten korvaamista toisilla Apple ei voinut lukea käyttäjien viestejä. Protokollasta puuttui jatkosuojaus (forward secrecy): jos käyttäjän salauksenpurkuavain paljastui, kaikki tälle käyttäjälle tarkoitetut viestit voitiin lukea. Käyttöjärjestelmä iOS 14:n myötä Apple on vuonna 2020 tiettävästi paikannut muutkin iMessage-haavoittuvuudet, joita oli vielä versiossa 13.

Signal

Signal-protokolla, jota käytetään sekä Signalissa että WhatsAppissa, käsittelee kahden osapuolen viestintää eri tavoin kuin iMessage. Se soveltaa DH-avaintenvaihtoa (Diffie-Hellman-Merkle) asynkronisella tavalla, jota kutsutaan räikäksi (ratcheting). Korkealla tasolla aina, kun Liisa lähettää Pekalle uuden viestin, hän sisällyttää myös DH-arvon ja päivittää symmetrisen avaimensa tämän DH-arvon ja viimeksi Pekalta saamansa DH-arvon perusteella. Pekka yhdistää saapuvan DH-arvon aiemmin lähettämäänsä arvoon luodakseen itselleen saman uuden symmetrisen avaimen. Tätä avainta kutsutaan ketjuavaimeksi.

Jokaista viestiä kohden, jonka Liisa lähettää Pekalle saamatta häneltä vastausta, hän johtaa kaksi uutta avainta nykyisestä ketjutusavaimesta käyttämällä siihen KDF:ää (HKDF:ään perustuvaa). Yhtä avainta käytetään seuraavana ketjutusavaimena, toista käytetään nykyisen viestin salaamiseen. Myös tätä Signalin suunnittelijat kutsuvat räikäksi, ja sen yhdistelmää DH-arvojen räikkään sanotaan kaksoisräikäksi. Tämä mekanismi tarjoaa jatkosuojauksen Signal-viesteille niiden asynkronisesta luonteestaan huolimatta. Se tarjoaa myös paljastumisen jälkeisen suojan. Räikkien käyttöön liittyy kuitenkin synkronointiongelmia: jos viesti katoaa Liisan ja Pekan väliltä, heidän avaimensa päätyvät eri tilaan. Tämä ratkaistaan säilyttämällä viimeisimpiä ketjutusavaimia.

Symmetrisessä salauksessa Signal käyttää yksinkertaista yleistä AE-rakennetta, jossa ensin salataan CBC-moodissa AES-256:lla ja sitten lasketaan ja HMAC SHA-256:lla. Tämä on varovainen ja hyvin ymmärretty menettely.

Autentikointi on Signalissa viime kädessä samanlainen kuin iMessagessa: se riippuu luottamuksesta palvelimeen. Ajatuksena on, että käyttäjät rekisteröivät joukon DH-arvoja palvelimella. Muut käyttäjät hakevat ne ja niitä käytetään luomaan ensimmäiset ketjutusavaimet. Pahantahtoinen palvelin voi kuitenkin korvata nämä arvot ja tehdä siten MitM-hyökkäyksen. Ihmisen luettavissa olevien, avaimista laskettujen sormenjälkien käyttö lieventää tätä hyökkäystä.

Signalin rakenne on innostanut tutkimuksia siitä, kuinka hyvän suojauksen kahden osapuolen protokollalla voi pikaviestinjärjestelmässä saavuttaa ja miten tämä vuorovaikuttaa synkronointiongelmien kanssa. Ei tämä eikä muukaan edellä tarkoita, että Signalin turvallisuus tekisi sitä käyttävästä pikaviestimestä erityisen turvallista. Signal on protokolla ja pikaviestin on monimutkainen ohjelmisto. Whatsapp kärsi vuonna 2019 puskurin ylivuotohaavoittuvuudesta, jolla puhelimeen saatiin istutetuksi haittaohjelma pelkästään soittamalla siihen Whatsapp-puhelu. Edes puheluun vastaaminen ei ollut tarpeen.

Telegram

Kolmas tyyppi pikaviestinnän protokollia on Telegramin käyttämä malli. Se yhdistää erikoisella tavalla erilaisia kryptoprimitiivejä: RSA, äärellisen kunnan DH-avaintenvaihto, hash-pohjainen avaimen johtaminen, hash-pohjainen MAC ja epästandardi salausmoodi nimeltään IGE. Lisäksi siitä puuttuu kunnollinen avainten eriyttäminen: Liisalta Pekalle menevien viestien salaukseen käytetyissä avaimissa on useita samoja bittejä vastakkaisen suunnan avainten kanssa, ja avaimen bitit on otettu suoraan DH-vaihdon tuottamista arvoista. Ominaisuudet rikkovat parhaita kryptokäytäntöjä ja hankaloittavat merkittävästä muodollista turva-analyysia. Lisäksi Telegramissa ei yleisesti ole päästä päähän -salausta, vaan kaksi tilaa, joista toinen on suojattu päästä päähän ja toinen tarjoaa suojatun viestinnän vain välillä asiakas–palvelin. Jälkimmäinen tila näyttää olevan edellistä yleisemmin käytössä, mikä on senkin takia huolestuttavaa, että Telegram on erityisen suosittu epädemokraattisissa maissa.

Kontaktien seuranta à la DP-3T

Yksi tuoreimmista kryptografian sovelluksista on vuoden 2020 alussa käynnistyneen Covid-19 -pandemian seurauksia. Paremminkin sovelluksia syntyi monia, sillä useissa maissa kehiteltiin omanlaisia altistumisten seurantajärjestelmiä. Tässä luonnostellaan DP-3T -hankkeen tuotos, Decentralized Privacy-Preserving Proximity Tracing (oikeastaan siis DP³T). Se syntyi hyvin nopeasti ja isolla työryhmällä ja sillä on erityisen tiukat yksityisyysominaisuudet. Pandemiaseurantaan se puolestaan ei sovellu hajautetun rakenteensa takia.

Matkapuhelimessa DP-3T on sovellus, joka aluksi generoi satunnaisen salassa pidettävän avaimen. Sen perusteella sovellus johtaa joka päiväksi uuden päiväavaimen (yksisuuntaisesti), ja siitä edelleen 15 minuutin välein AESilla CTR-moodissa (eli toistettavasti) bittijonon, jota se lähettää parin minuutin välein Bluetoothin kautta lähellä olevien laitteiden saataville. Bittijonosta käytetään nimitystä beacon, joskin majakkavalon välähdys voisi olla kuvaavampi. Vastaanottavien puhelinten sovellus tallentaa tunnisteen, ajan ja havaitun signaalin voimakkuuden. Kun joku sovelluksen käyttäjä saa positiivisen Covid-19 -testituloksen, hän käyttää terveysviranomaiselta saamaansa vahvistuskoodia, jolla sovellus lähettää viimeaikojen päiväavaimensa keskukseen. Muiden käyttäjien sovellukset saavat tietää nämä, kun sovellukset kyselevät niitä säännöllisin välein keskukselta. Sovellus laskevat päiväavainten listasta eteenpäin beacon-tunnisteita ja saattavat löytää joitakin, jotka niillä on tallessa vastaanotettuina. Sovellus yhdistelee tällaisten havaintojen aikoja, määriä ja signaalinvoimakkuuksia päätelläkseen, onko syytä varoittaa käyttäjää altistumisesta.

DP-3T siirtynee historiaan pandemian kulkiessa väestön läpi. Suomen oma sovellus Koronavilkku ainakin on käynnissä vain kesään 2022 asti.

Palautusta lähetetään...