36C3 - Cryptography demystified

Translated by Kari Kananoja (KYBS2004 course assignment at JYU.FI) Alkumusiikkia

Seuraavaan keskusteluun. Hän on työskennellyt kuusi vuotta

kryptografian parissa Karlsruhen yliopistossa - Oots.

Kiitokset esittelystä ja tervetuloa keskusteluun. Kuten Herald juuri

sanoi, olen työskennellyt kryptografian parissa suurimman osan

viimeisistä kuudesta vuodesta. Olen huomannut että monilla ihmisillä on tavallaan mielikuva

siitä mitä kryptografia ja kryptaus on. Mutta joskus tämä

mielikuva ei vastaa sitä mistä on kysymys. Niinpä tahdoinkin pitää

esittelypuheen kryptografiasta laajalle yleisölle. Siis

yleisölle, jolla ei ole aikaisempaa kosketuspintaa kryptografiaan tai jopa

yleisölle, jolla ei ole taustaa matematiikassa tai tietotekniikassa.

Kuten aiemmin sanoin, tämä puhe on osoitettu erityisesti ei-tekniselle

yleisölle, vaikka puhutaankin 36C3:sta. Meillä kuitenkin lienee melko teknislähtöinen yleisö.

Ja tämä on puhetta perusteista. En siis puhu hienoista tutkimus-

tai kehitystuloksista. Puhun pelkistä perusteista. OK.

Paitsi työskentelystä kryptografian parissa, minä nautin sovelletusta kryptografiasta, numeroteoriasta

jne, siis kaikenlaisten muistien, korruption, vikojen ja ohjelmien tutkimisesta.

OK. Tämä on kuva vanhempieni kissasta. Koska jokaisessa puheessa pitäisi olla

kuvia kissoista. Ja tämä on - Kiitos, Tämä on muistilistani

tälle puheelle. Ensimmäinen kohta, luulenpa että sen jo teimmekin. Ja muistin virkistykseksi

haluan selittää mitä kryptaus on.

mitä se tekee ja mitä se ei tee.

Haluan selittää autentikaatiota, mikä ikään kuin... mikä korjaa ongelman

mitä kryptaus ei korjaa. Haluan selittää sertifikaatteja, koska ne auttavat

paljon niin kryptauksessa kuin autentikoinnissakin. Ja lopuksi, haluan

selittää hiukan miten selittämäni aiheet toimivat yhdessä ja voidaan

yhdistää yhä hyödyllisempiin asioihin. Aloitetaanpa ensimmäisestä kohdasta

tässä. Haluan selittää kryptaamisesta. Kryptaus on periaatteessa ratkaisu

ongelmaan. Puhutaanpa ongelmasta joka meillä on, ennen kuin mennään ratkaisuun.

Ongelma on yksi klassista ongelmista, joissa kaksi osapuolta haluaa

keskustella. Me kryptaajat puhumme yleensä Alicesta ja Bobista ja Alice

haluaa lähettää viestin Bobille.. Tässä tapauksessa hyvin yksinkertaisen viestin

"Terve". Mutta kryptografiaa on käytetty diplomatiassa ja sotilaallisissa tarkoituksissa

satoja vuosia. Joten kuvitellaanpa että kyseessä onkin jokin kriittisempi viesti. Ja

ongelma joka halutaan ratkaista onkin se, että voi olla olemassa salakuuntelija joka haluaa

kuunnella yhteyttä ja lukea viestin, ja sisällön

joka on lähetetty Alicelta Bobille. Ja jotkut ajattelevat, että kryptografia toimii

jotenkin seuraavasti: tämä on aika lähellä, mutta

ei oikeastaan. Eli kuvitellaan että Alice suoritti jonkinlaisen kryptausmenetelmän

tekstilleen tuottaakseen jotain satunnaista liirumlaarumia, mitä me kutsumme

salakirjoitukseksi. Ja Alice lähettää salakirjoituksen Bobille. Ja Bobilla on

kryptauksen purkuun menetelmä, joka tietää miten kryptaus puretaan. Siis jotta kryptaus palautettaisiin

selväkieliseen muotoon. Ja nyt se pointti, jonka

jotkut ymmärtävät väärin; tieto miten purkaa kryptaus olisi

salaisuus. Mutta se ei ole totta nykyään. Vuonna 1883, henkilö nimeltään Auguste Kerckhoffs

muodosti muutaman periaatteen, jotta sotilaallisissa tarkoituksissa tehtyjen salakirjoitusten

tulisi noudattaa. Ja yksi näistä vaatimuksista tuli tunnetuksi

nimeltään Kerckhoffin periaate ja siinä sanotaan: Salakirjoituksen ei pitäisi vaatia salailua

eikä sen pitäisi olla ongelma jos salakirjoitus päätyy vääriin käsiin.

Muotoillakseni tätä hieman uudelleen; salakirjoitus jota käytät, pitäisi olla tarpeeksi turvallinen

jotta voit kertoa vihollisellesi, miten purkuprosessi

toimii ja miten itse purkuprosessi toimii, ilman että

kryptaus ei vaikutu. Tai jos vielä uudelleenmuotoilen; jos käyttämäsi salakirjoitus

on niin epävarma, ettet voi kertoa kenellekään miten se toimii, ehkä sinun ei

kannata käyttää sitä laisinkaan. Palataanpa vielä tähän kuvaan. Joten, jos

hyökkääjä tietää miten sanoman kryptauksen saa purettua, tällä ilmeisestikin hyvin yksinkertaisella

tavalla ei vielä saavuteta mitään käytettävää. Tämän takia esiteltiin avain

tälle kuvalle. Nyt kryptaus- ja purkutoiminnot

käyttävät avainta, joka menee tehtävän tuloksen sisään. Siis Alice

tekee jonkinlaisen toiminnon viestinsä kryptaamiseksi ja avaimen sisällyttämiseksi

Ja Bob, jolla on sama avain, voi kääntää kryptauksen

takaisin viestin alkuperäiseen muotoon. Kuitenkin, niin kauan kuin vain Alice ja Bob tietävät avaimen,

mutta hyökkääjä ei, hän ei voi avata kryptausta.

Yleisesti, en mene siihen, miten nämä toiminnot teknisesti suoritetaan.

Näissä laatikoissa, jotka kuvaavat it -toimintoja, sisältävät

matemaattisia tai tiedonkäsittelyllisiä toimintoja. Ja haluaisin selittää miten

ne toimivat sisäisesti, varmistaakseni laajalle yleisölle tarkoitetun puheeni ymmärtämisen.

Ongelma tässä on se, että Alicen ja Bobin täytyy sopia avaimesta etukäteen.

Eli Alice ei voi vain lähettää avainta Bobille, koska jos hän niin tekisi,

hyökkääjä. joka salakuuntelee, kuulisi avaimen myös, kuten viestinkin

Ja hyökkääjä voisi purkaa kryptauksen kuten Bobkin. Eli tämä ei

toimi, koska se on surkea yritys. Kuitenkin, jonkin aikaa

70- ja 80-luvuille saakka, ainoastaan tätä toimintatapaa käytettiin.

Sitä kutsuttiin symmetriseksi kryptaukseksi, koska voimme yksinkertaisesti kääntää toiminnot toisin päin

ja Bob voisi vastavuoroisesti lähettää viestin Alicelle, koska kryptaus ja sen purku

käyttävät samaa avainta. Ja jos on olemassa symmetrinen kryptaus, voitte arvata

että on olemassa myös asymmetrinen kryptaus, jolla

on käytössä avainpari. Toista käytetään

kryptaamiseen ja toista kryptauksen purkuun. Nyt meillä on

asymmetrinen kryptaustoiminto, jolla voimme tehdä seuraavaa. Bob

luo avainparin, ja

pitää purkuavaimen itsellään. Siksi purkuavainta kutsutaan

salaiseksi tai yksityiseksi avaimeksi. Kuitenkin, Bob voi julkaista kryptausavaimen vapaasti.

Esimerkiksi, se voidaan laittaa vaikka johonkin julkiseen rekisteriin, esim. osoitteistoon.

Ja nyt Bob voi lähettää sekä avaimen että viestin Alicelle ja salakuuntelija

saa kryptausavaimen, mikä ei ole ongelma,

koska se on muutenkin saatavilla. Ja kun tämä on tehty, Alice voi

käyttää Bobin kryptausavainta luodakseen viestin Bobille ja

Bob voi purkaa kryptauksen yksityisellä avaimellaan. Kuitenkaan,

salakuuntelija ei viestiä voi purkaa, koska

vaikka kryptausavain hänellä onkin, purkuavainta ei ole.

Tässäkin tavassa on tavallaan riskinsä

Tässäkin on ongelmansa, koska vieläkin on varmistettava, että

avaimet on toimitettu etukäteen. OK, ajatellaanpa seuraavaa: Bob

on lähettämässä julkisen kryptausavaimensa Alicelle, siinä on ongelma. Jos hyökkääjä

ei tyydykään passiiviseen kuunteluun, vaan on valmis aktiivisesti

puuttumaan yhteydenpitoon. Esimerkiksi, salakuuntelija voisi puuttua

Bobin lähettämään salausavaimeen siten, että korvaakin sen omalla avaimellaan

Alice luulisi, että avain tulee Bobilta

ja käyttää tätä korvaavaa avainta oman viestinsä lähettämisessä ja yhtäkkiä

hyökkääjä voikin taas lukea Alicen viestin. Nyt, vedetäänpä yhteen kryptauksesta,

kryptaus pääasiallisesti salaa datasisällön. Ja sen se tekee

ja se on pääasiassa se, mitä se tekee Erityisesti, se ei salaa

tosiasiaa, että yhteydenpitoa tapahtuu. Eli salakuuntelija

luonnollisestikin huomaa Alicen lähettävän viestin Bobille. Ja vaikka

salakuuntelija tietää että kommunikaatiota tapahtuu Alicen ja Bobin välillä

ja pelkästään tämä voi olla vaarallista heille molemmille. Ajatellaanpa että Alice

työskentelee tiedusteluvirastolle ja Bob on journalisti; hyökkääjä huomaa Alicen

lähettävän runsaasti dokumentteja Bobille, se voisi olla vahva merkki siitä

että Alice on tiedonantaja ja voitaisiin saattaa siitä vastuuseen. Eli jotain muuta

mitä ei ole salattu kryptauksella, on liikkuvan tiedon määrä.

Eli jos Alice lähettää vain hyvin lyhyen viestin Bobille

salakuuntelija voi päätellä että ei lähetetä 20 MB

tiedostoa tai vastaavaa. Eli kaikki tämäntyyppinen metadata on sellaista

mitä kryptauksella ei voida salata. Ja kryptauksessa on pari muutakin ongelmaa. Yksi niistä

on se, että hyökkääjä voi muuntaa viestiä. Muuntamisen suojaaminen eli autentikointi

ei ole kryptauksen tehtävä. Toinen ongelma on se, että avaimien täytyy olla

vaihdettuina etukäteen, mitä jo puhuinkin. Ja muitakin ongelmia on.

Esimerkiksi, hyökkääjä voi ottaa viestin haltuun lähetettäessä.

Ja myöhemmin lähettää viestin Bobille, tai vaikkapa estää

koko viestin lähetyksen. Eli keskeyttää lähetyksen ja poistaa sen kokonaan.

Ja tässä ensiksikin

hyökkääjä voisi vaihtaa viestin sisällön, mikä taas johtaa puheeni toiseen

osaan, mikä on autentikointi. Eli merkitäänpä kryptaus listalla

käsitellyksi. OK, eli mitä on autentikointi? Se mahdollistaa datan muutoksien

havainnoinnin. Se ei estä muutoksien tekemistä, vaan ainoastaan

muutoksien huomaamisen muutosten jälkeen. Esimerkiksi,

autentikointia olisi tarvittu, kun Alice

siis Ben lähetti julkista avaintaan Alicelle, mutta tämä ei ole laisinkaan

ainoa tilanne jossa autentikointia tarvitaan. Ajatellaanpa että Alice johtaa

hyväntekeväisyysjärjestöä. Hän vaikkapa pelastaa pakolaisia hukkumasta

Välimereen. Ja Bob haluaa lahjoittaa järjestölle, jotta se voi tätä tehdä. Sitten Alice

Alicen täytyy lähettää pankkitilinumero Bobille, jotta talletus voidaan tehdä. Ja

huomatkaa että tässä tapauksessa viesti, jonka Alice Bobille lähettää, sisältäen

pankkitilinumeron, ei ole mitenkään salaista. Sen ei tarvitse olla kryptattua,

koska tämä tieto on julkista. Kuitenkin, haluamme varmistaa, että

tieto joka Bobille lähetetään, on todellakin oikea pankkitilinumero. Estääksemme

tällaisen tapauksen jossa rikollinen voisi puuttua viestin sisältöön

ja vaihtaa pankkitilin numeron omaansa, Bob lähettäisi rahansa rikollisen

tilille Alicen tilin sijaan. Ja yksi tapa autentikointiin on jälleen

avainpari, toinen autentikointiin ja toinen

verifiointiin. Eli sen tarkistamiseen, ettei viestiä ole muuteltu. Ja

autentikointiavain täytyy pitää salaisena. Siten se on salainen/yksityinen avain, kun taas

verifiointiavain voidaan tehdä julkiseksi. Ja nyt

jos tällainen järjestely on tehty, Alice voi jatkaa viestin

lähettämistä Bobille ja lisätä siihen tiedon käsittelyä yhdessä yksityisen avaimen kanssa

luodakseen jotain jota kutsumme allekirjoitukseksi

tai digitaaliseksi allekirjoitukseksi. Alice lähettää allekirjoituksen

yhdessä tilinumeronsa kanssa. Bob käyttää allekirjoitusta

avatakseen saamansa tiedon, ja sen tulosta

käytetään päättelemään, onko tilitietoa muutettu vai onko

se aito ja alkuperäinen. Jos hyökkääjä muuttaa tilitietoa, Bob

huomaa tämän. Ja tämä pätee myös siihen, jos

hyökkääjä muuttaisikin tilitiedon sijasta allekirjoitusta.

OK? Nämä asiat on suunniteltu tavalla, mikä toivottavasti tekee mahdottomaksi

hyökkääjälle saada validia allekirjoitusta muuhun kuin

alkuperäiseen viestiin. OK. Siis ainoa asia, millä tavalla Bob

hyväksyy allekirjoituksen, on se että hyökkääjä ei ole muuttanut

tilitietoja. Ja tässä tapauksessa on turvallista Bobille siirtää rahat. OK

Ja tässä on toinen ratkaisu samaiseen ongelmaan. Ja se on

itse asiassa melko tavalla samanlainen, pitsi että nyt avaimia on vain yksi

ja sitä käytetään niin autentikointiin kuin verifiointiinkin. Ja tässä tapauksessa

asioilla on vain eri nimi. Ne toimivat täysin samalla tavalla, paitsi että

allekirjoitusta kutsutaan viestin autentikointikoodiksi tai MACiksi.

Molemmissa tapauksissa, 0oli meillä kaksi tai yksi avainta

meillä on yhä ongelma tuossa avaimen välittämisessä. Kuvitellaanpa että

kahden avaimen tapauksen prosessissa, Alice oli lähettämässä julkista avaintaan Bobille,

ja meillä olisi sama hyökkäys kuin aiemmin ja hyökkääjä ehtisi

vaihtaa Alicen avaimen ennen saapumista Bobille.

Ja jos hyökkääjä lähettää oman julkisen avaimensa

Bobille, niin luonnollisestikin hyökkääjä voi voi luoda validin allekirjoituksen

muunnetulle pankkitilitiedolle. Ja Bob hyväksyisi tämän. OK, meillä on

tämä avaimen jakelun ongelma, jossa verifiointiavain täytyy

olla Bobilla tiedossa etukäteen. Ja tämä johtaakin puheeni seuraavaan osuuteen

Merkitään autentikointi tehdyksi ja siirrytään sertifikaatteihin.

Sertifikaatti on dokumentti joka varmentaa, että tietty julkinen avain kuuluu

tietylle määreelle, kuten henkilölle tai organisaatiolle. Ja jos haluamme käyttää

sertifikaatteja, palataanpa taas aikaisempaan tapaukseen. Siis Alice

haluaa lähettää Bobille pankkitilinsä numeron, julkisen avaimensa ja allekirjoituksen

pankkitiedoille ja hyökkääjä voisi vaihtaa julkisen avaimen, pankkitiedon

ja allekirjoituksen. Ja jos nyt lisäämme tähän sertifikaatit, tarvitsemme

jotain mitä kutsutaan sertifikaattivaltuutetuksi. Ja se on

luotettu kolmas osapuoli, joka luo sertifikaatteja, jotka vahvistavat yhteyden

henkilön ja julkisen avaimen välillä. Eli ennen kuin Alice lähettää viestin Bobille,

hän lähestyy sertifikaattivaltuutettua ja sanoo: Hei sertifikaattivaltuutettu,

tämä on julkinen avaimeni, olen Alice. Ole hyvä ja anna sertifikaatti.

Ja näin valtuutettu tarkistaa että Alice on kuka hän väittää olevansa ja että

Alice todellakin omistaa tämän julkisen avaimen. Ja jos tarkistukset ovat OK,

valtuutettu luo sertifikaatin ja antaa sen Alicelle.

Sertifikaatti on dokumentti siitä että valtuutettu on

varmistanut että kuvassa näkyvä hopeinen avain kuuluu Alicelle.

Alicella on sertifikaatti ja hän voi lähettää julkisen avaimensa Bobille yhdessä

sertifikaatin kanssa. Ja Bob, jos hän tietää sertifikaatin myöntäjän julkisen avaimen,

voi tarkistaa että sertifikaatti on aito ja valtuutetun myöntämä.

Ja jos hän luottaa valtuutettuun, hän tietää

että hopeinen avain on Alicen. Ja myöhemmin,

Bob on vakuuttunut että avain on Alicen ja hän voi tarkistaa

että Alicen viestin sisältö ei ole muuttunut. Emme siis ole täysin vapaita

avaimen välittämisen ongelmasta vieläkään, koska Bobin täytyy yhä tietää

valtuutetun avain etukäteen. OK. Siis Bobin ei tarvitse

tietää Alicen avainta etukäteen, mutta valtuuttajan avain tarvitaan.

Ja käytännössä, ei ole yhtä ainoaa valtuutettua,

vaan suuri joukko ja valtuutetut

voivat luoda sertifikaatteja muille valtuutetuille jne,

Eli Bobin ei tarvitse tietää kaikkia valtuutettujen avaimia

vaan ainoastaan muutaman.

Vedetäänpä yhteen sertifikaateista. Kuten sanoin

aikaisemmin, sertifikaatit vahvistavat, että tietty julkinen avain kuuluu tietylle

osapuolelle, henkilölle tai organisaatiolle. Mutta vieläkään ei olla täysin vapaita

jakeluongelmasta, koska ihmisten täytyy tietää sertifikaattivaltuutetun

julkinen avain. Ja toinen ongelma tässä on, että toimintatapa antaa

paljon valtaa valtuutetulle, Jos siis hyökkääjä

pystyy vaarantamaan valtuutetun, hän pystyisi pakottamaan

valtuutetun luomaan valesertifikaatteja ja yhdistämään valeavaimia oikeille henkilöllisyyksille.

OK, hän voisi siis luoda valesertifikaatteja, joiden mukaan valtuutettu

olisi tarkistanut että hyökkääjän julkinen avain kuuluisi Alicelle. Ja korjaamalla

tämän ongelman valtuutetun vallasta on jotain

minkä kanssa kryptaajat painivat yhä. Eli se on ongelma vielä tänäkin päivänä. Ja

itse asiassa tämä ongelma ei ole vian teoreettinen. On olemassa joukko tapauksia

joita on tapahtunut valtuutettujan kanssa. Yksi tunnettu esimerkki on Diginotar

tapaus, jossa Diginotar -nimisen valtuuteun sertifikaatti hakkeroitiin

ja hyökkääjät loivat valesertifikaatin google.com domainille tai

muista googlen domaineista. En ihan tarkasti muista. Ja sitten nämä

sertifikaatit ilmestyivät käytössä Iranissa. Ei siis mikään teoreettinen ongelma.

Tämä itse asiassa tapahtui jo aiemmin. Tämä siis johtaa siihen mitä halusin sanoa

sertifikaateista. Mennäänpä eteenpäin ja katsotaan miten nämä asiat voidaan yhdistää

rakentaaksemme jotain monimutkaisempaa mutta myös hyödyllisempää. Eräs työkaluista jonka haluan

esitellä nimeltään autentikoitu kryptaus ja sen on periaatteessa yhdistelmä kryptausta ja

autentikointia. Jostain syystä, ihmiset käyttävät tätä ilmausta pääosin symmetrisen

salauksen yhteydessä, jolloin on oma avaimensa kryptaamiselle ja purkamiselle ja yksi

avain autentikoinnille ja verifioinnille. Mutta saman voi luoda myös

asymmetriseen tapaan. Ja tätä tehdään myös käytännössä.

Tässä tapauksessa sitä vaan ei kutsuta autentikoiduksi kryptaukseksi. Niinpä

yksi tapa rakentaa autentikoitu kryptaus on. jos Alice haluaa lähettää viestin Bobille,

hän kryptaa viestinsä käyttämällä kryptausavainta ja lähettää salatun tekstin

Bobille. sitten hän käyttää salatun tekstin kopiota ja luo

autentikointikoodin siitä käyttäen toista avaintaan. Bob tekee saman

kun Alice lähettää hänelle autentikointikoodin. Nyt

Bob voi purkaa kryptauksen avaimellaan. Ja lisäksi Bob voi tarkistaa

onko viesti muuttumaton vaiko aito, käyttämällä verifiointi-

proseduuria. OK, tällainen autentikointi ei estä muutoksia

tapahtumasta, mutta Bob voi tarkistaa onko niitä tapahtunut. Ja itse asiassa

tällainen autentikoitu kryptaus voi kasvattaa kryptauksen

turvallisuutta. OK, toinen asia mistä halusin puhua, on ns.

hybridikryptaus. Tämä on yhdistelmä symmetrista ja asymmetristä

kryptausta. Ja miksi tämä on mielenkiintoista on se, että asymmetrinen

kryptausta. Ja miksi tämä on mielenkiintoista on se, että asymmetrinen

lähettää hyvin pitkän viestin Bobille käyttämällä julkisen avaimen tapaa,

siis asymmetristä kryptausta, se veisi hyvin paljon aikaa

kryptata ja purkaa kryptaus. Kuitenkin, voidaan yhdistää

molemmat tavalla, joka tekee kryptauksen

prosessin nopeammaksi. Tämän voi tehdä niin, että jos Alice haluaa

lähettää viestin Bobille, hän aluksi luo uuden avaimen symmetriselle tavalle

Ja Alice kryptaa viestinsä tällä avaimella ja lähettää salakirjoitetun tiedon

Bobille. Jäljempänä Alice käyttää luomaansa avainta

kryptaa avaimen, joka lähetetään Bobille myös.

Nyt Bob voi purkaa salauksen käyttämällä yksityistä avaintaan

-kultainen avain ruudulla - saadakseen symmetrisen avaimen.

Ja myöhemmin Bob voi käyttää saamaansa symmetristä avainta kryptatakseen

itse viestin. Kuitekaan, yhteyttä salakuunteleva ei voi

purkaa kryptausta, koska siinä ei ole symmetristä avainta eikä voi

purkaa symmetristä avainta, koska hänellä ei ole yksityistä avainta. OK.

Tämän tyyppistä rakentelua voidaan jatkaa ja päädytään asiaan

nimeltä kuljetuskerroksen turvallisuus, TLS, Ja se on

verkkoprotokolla joka yhdistää monet näistä asioista

joita olen esitellyt. Se siis yhdistää joko symmetrisen tai hybridikryptauksen

yhdessä autentikoinnin kanssa. Eli MACit, allekirjoitukset ja muut.

Ja se lisää muutaman jutun viestin uudelleenlukemisesta.

Eli jos hyökkääjä haluaa kuunnella aiemmin nauhoittamansa viestin

TLS huomaa tämän. Se voi myös havaita, jos viestiä on tiivistetty.

Tämä siis yhteyden osalla. Se mitä TLS tekee, se

perustaa varman yhteyden kahden päätteen väliin. Sanotaanko vaikka Alicen ja Bobin

välille turvattomaan verkkoon, jota hyökkääjä pitää hallussaan. Ja yksi sovellus

jossa TLS:ää käytetään, on mailien lähetys. Esimerkiksi,

jos Alice haluaa lähettää mailin Bobille, tätä sähköpostia

ei yleensä lähetetä suoraan. Alicen maili meneekin ensin sähköpostipalvelimelle ja

se välittää vietin Bobin sähköpostipalvelimelle. Kun

Bob menee sähköpostisovellukseensa, sähköpostit latautuvat palvelimelta Bobille,

puhelimeen, työkoneelle tai mitä Bob nyt sitten käyttääkään.

Näin Alice voi luottaa siihen, että kun hän lataa mailiaan palvelimelle

yhteys on turvallinen pelkästään kryptaamalla viesti.

Tämä siis tapahtuu käyttämällä TLSää ja kaikkia siihen liittyviä asioita

kuten kryptausta, autentikointia jne. Kuitenkaan, Alice ei voi tarkistaa

käyttääkö hänen sähköpostipalvelimensa turvallista yhteyttä välittäessään viestiä Bobin

palvelimelle. Katsotaanpa vähän tarkemmin; jokainen näistä vihreistä lukoista

tarkoittaa turvattua yhteyttä. Tämä tarkoittaa että kun viesti lähetetään tai

on lähetetty turvallisen yhteyden kautta, on käytetty kryptausta

ja autentikointia lähettäjän osalta ja purkua ja verifiointia

vastaanottajan osalta. OK, jos Alice haluaa lähettää mailin Bobille,

Alice muodostaa turvatun yhteyden ja lähettää viestinsä sen kautta. Ja tämä sisältää

viestin kryptauksen ja sen autentikoinnin. Alicen palvelin

purkaa viestin ja verifioi että sisältö ei ole muuttunut. Sen jälkeen

Alicen palvelin lähettää viestin edelleen Bobin palvelimelle, kryptaten

ja autentikoiden sen. Bobin serveri purkaa ja verifioi viestin. Ja

sama prosessi jatkuu kun Bobin palvelin välittää viestin Bobille.

Kuitenkin, tässä tapauksessa vaikka viesti on kryptattu joka

kerta kun se on lähetetty verkon yli, Alicen ja Bobin palvelimet näkevät

viestin selvänä tekstinä. Koska Alice lähettää viestin, hän kryptaa sen ja

Alicen palvelin purkaa sen. Eli Alicen palvelin näkee viestin selväkielisenä.

Sama koskee Bobin palvelinta. Tätä me kutsumme kuljetuskryptaukseksi,

koska viesti salataan joka kerta sen liikkuessa verkossa.

Vastakkainen tapa, end-to-end -kryptaus, on kun Alice

ennen viestin lähetystä kryptaa viestin avaimella, jota palvelimensa ei tiedä

vaan Bobin julkisella avaimella. Alice voi jopa allekirjoittaa oman

autentikointiavaimensa. Ja sitten Alice lähettää tämän valmiiksi kryptatun

viestin turvattua yhteyttä pitkin palvelimelleen. Tämä taas sisältää kryptauksen

uudelleen ja autentikoinnin uudelleen ja Alicen palvelin purkaa

viestin ja ja verifioi sen muuttumattomuuden. Kuitenkaan, palvelin

ei voi purkaa toisen kerroksen salausta, eihän? Viesti on siis kryptattu kahdesti.

Kerran Bobin avaimella ja toisen kerran, jotta palvelin voi purkaa tämän. Ja

nyt palvelin voi purkaa toisen kerroksen kryptauksen. Mutta ensimmäinen kryptaus

on yhä olemassa, eli Alicen palvelimelta tekstiä ei voi lukea. Ja prosessi jatkuu,

kryptattu viesti kryptataan uudelleen ja Bobin palvelimella taas puretaan

ja lähetettäessä Bobille taas kryptataan ja puretaan.

Lopuksi Bob, jolla on yksityinen avain, sillä voidaan

purkaa ensimmäinen kryptaus ja näin viesti on Bobilla luettavassa muodossa.

Kuitenkaan, välissä olevat palvelimet eivät viestiä voi lukea, koska se on

kryptattu Bobin julkisella avaimella- OK, eli tällä asia olisikin käsitelty.

Tässä kuitenkin pari kappaletta asioita kotiin vietäviksi.

Ensiksikin, kryptaus kätkee datasisällön. Ja eipä se paljoa muutakaan

tee. Se ei kätke metadataa, eikä estä lähetetyn datan

muokkaamista. Se on autentikoinnin

tehtävä. Autentikointi mahdollistaa muutoksien huomaamisen,

sekä kryptaukselle että autentikoinnille. Sinulla täytyy olla etukäteen jaetut

avaimet, tai ehkä ei etukäteen, mutta jako täytyy tapahtua ennen varsinaista viestin käsittelyä.

Ja yksi tapa yksinkertaistaa tätä ongelmaa ovat sertifikaatit

jotka vahvistavat tietyn julkisen avaimen kuuluvan tietylle toimijalle.

Ja jos sinulla on kaikki nämä asiat, kryptaus, autentikointi ja

sertifikaatti, voit rakentaa verkkoprotokollan, joka huolehtii varmasta

viestin välityksestä paikasta toiseen. Ja voit käyttää niitä saadaksesi

kuljetuskryptauksen. Mutta kuljetuskryptaus on huonompi kuin end-to-end -kryptaus

siinä mielessä, että kuljetuskryptauksessa välipalvelimet pystyvät yhä

lukemaan lähetetyt viestit. Kuitenkin, end-to-end -kryptaus

ei sitä mahdollista. Ja tällä haluaisinkin nyt lopettaa ja

vastaan mielelläni kysymyksiinne. Jos tulee kysymyksiä, joita ette nyt voi kysyä

voitte lähettää niitä sähköpostitse kuvassa näkyvään osoitteeseen. Yritän

pitää osoitteen voimassa pari vuotta.

--suosionosoituksia-

Kiitokset puheestasi. Ja nyt voimmekin siirtyä kysymysosioon

Jos teillä on kysymyksiä, voitte nousta mikrofonien luo

Onko netistä tullut kysymyksiä? Meillä on runsaasti aikaa. Onko ketään?

Jos on kysymyksiä, tervetuloa. Meillä on kysymys mikrofonilla 2.

Kiitos hyvästä puheesta. Haluaisin tietää, miten voit muuttaa viestiä

joka on kunnolla kryptattu, mutta vastaanottaja huomaa, että

kryptaus ei toimi enää?
Se riippuu käytettävästä kryptaamistavasta.

Mutta monessa tavassa, viestin muuttaminen

on itse asiassa melko helppoa. On oikeasti olemassa todella paljon

kryptaustapoja, jotka muuttavat vain muutaman bitin. Viesti koostuu siis

biteistä ja kryptaustavat mahdollistavat mitkä bitit muutetaan ja mitä ei.

Eli kun kryptasit viestiä, käytät kryptaustapaa valitaksesi

mitkä bitit pitää kääntää. Eli muutos nollasta ykköseksi

tai päinvastoin, lisäät sen viestiin jota lähetät

ja vastaanottaja vain poistaa tekemäsi muutoksen saadakseen alkuperäisen

sisällön, kun taas hyökkääjällä muutos ei ole tiedossa, sitä ei voi tehdä

Kuitenkin, hyökkääjä voi kääntää pari bittiä, ja tässä tapauksessa

sanotaanko Alicen kääntäneen bitin ja se käännetään uudelleen hyökkääjän

toimesta. Eli bitti on jälleen alkuperäisessä arvossaan. Ja sitten Bob, joka

tietää, miten purkaa, kääntää bitin jälleen. Ja jälleen

viesti on muuttunut. Ja parilla tavalla voit tehdä

tällaisia muutoksia viesteihin, jotta purku ei yksinkertaisesti

epäonnistu. Ainoastaan viesti saattaa olla hiukan vääränlainen.

OK. Seuraava kysymys mikrofonista 6, olkaa hyvä.

Kerroit, että kryptaus ei koske metadataa. Onko siitä mitään

ajatuksia?
Ajatuksia?

Mitään ratkaisua metadatan kryptaamiseen? En tiedä.

Paljon tästä on melko hankalaa ratkaistavaksi.. Tarkoitan että sähköposteihin

ajatus aiheen kryptaamiseen, mitä ei yleensä kryptata.

Jos haluat piilottaa viestin pituuden, voit yksinkertaisesti suojata

viestin. Eli loppuun satunnaista roskaa jotta peitetään sen itseasiallinen pituus.

Juuri niin. Eli hyökkääjällä on yhä viestin väärä pituus

eli tiedetään, että viesti on enintään jonkin pituinen, mutta

ei tiedetä, mikä sen oikea pituus on. Eli jos haluat

piilottaa identiteettisi yhteydenpidossa, sinun täytyisi toimia kuten

Tor -verkossa, eli et ota yhteyttä suoraan vaan

muutaman välikäden kautta siten, että välikädet eivät tiedä

lopullista vastaanottajaa.

Kiitos

OK. Sitten meillä taitaa olla kysymys internetin kautta.

Kyllä, kysytään, että voitko sanoa mitään koituvasta

tehon kulutuksesta maailmanlaajuisesti, koskien kryptauskerroksia?

Valitettavasti en osaa sanoa. En tiedä, paljonko tehoa kuluu

kryptaamiseen. Tiedon käsittelyn kannalta, ainakin, symmetrinen

kryptaus on melko edullista, koska se ei tarvitse kuin pari

prosessorisykliä purkuun. En tiedä, kuusitoista sanaa tai jotain. Joten

voit tavallisesti purkaa satoja megatavuja sekunnissa yhdellä prosessorilla. Ainakin

modernilla koneella. Eli en tiedä numeroita, mutta voitte arvata jos jokainen

ensimmäisen maailman maissa käyttää kryptausta, niin kokonaismäärä

tehoa on melko lailla suuri.

Seuraava kysymys. Mikrofoni 2, olkaa hyvä.

Mainitsit pari kertaa että hyökkääjä voi toistaa viestin.

Mainitsit pari kertaa että hyökkääjä voi toistaa viestin.

Ajattelepa jos Alice lähettää pankkiin pyynnön

rahan siirtämisestä. Ja joka kerta kun pankki saa sellaisen pyynnön

se tekee siirron. Silloinhan hyökkääjälle olisi hyödyllistä

tätä käyttää hyväksi, kun kerran saisi sellaisen viestin haltuunsa,

toistaa pyyntöä myöhemmin, ja lisäsiirtoja tapahtuisi.

Jos olisit vastaanottaja, se olisi melko mukavaa,

sinähän voisit tyhjentää Alicen tilin.

Sitten kysymys mikrofoni kolmelta.

Olin kuuntelemassa keskustelua elliptisestä kryptografiasta ja

pohdin, voisitko näyttää, mihin se sijoittuisi esittelemässäsi prosessissa?

Mennäänpä toiselle dialle. Tyypillisesti kryptaus on

lisätään tai ellipsoidin lisätään näihin laatikoihin.

OK. Eli näissä käsittelyissä tapahtuu paljon matematiikkaa

jota en tarkemmin selittänyt pitääkseni esityksen laajalle

kuulijakunnalle. Mutta yksi tapa realisoida sellainen kryptaustapa

on käyttää ellipsoideja näissä laatikoissa.

OK: Mikrofoni 1. Toinen rajoitus jota voisin ajatella tai mikä voisi vaikeuttaa

tätä olisivat IoT laitteet, joissa on vähän tehoa ja rajoitettu

prosessointikyky. Miten näihin voi liittää kompleksisen kryptauksen?

Meneillään on tutkimuksia kryptaustavoista

jotka ovat erityisen keveitä, eli erityisen sopivia

resurssirajoitteisille laitteille. Mutta mitä asiasta tiedän, melkein

kaikissa on jotain heikkouksia. Eli turvallisuusmielessä ne eivät

tarjoa samoja takuita kuten nämä, joita käytetään tehokkaammissa laitteissa.

Mikrofoni kaksi, ole hyvä.
Hei. Mainitsit

sen laajan vallan, jota sertifikaattivaltuutetut pitävät

sertifioinnin ja autentikoinnin kohdalla. Pohdin, että mitkä ovat

mahdolliset ratkaisut tai ehdotetut ratkaisut tähän tällä hetkellä?

Mikä on tämän hetken tilanne ratkaista tuo ongelma?
Yksi ratkaisu jota kehitetään, on nimeltään

sertifikaattien läpinäkyvyys. Se toimii periaatteessa

julkisen tai julkisia lokeja, joihin kaikki luodut sertifikaatit

talletetaan. Jos olet google.com tai olet Google

ja näet jonkun lisäävän Googlen sertifikaatin lokitiedostoon

ja tiedät, ettet ole sitä pyytänyt, tiedät että joku

on tehnyt valesertifikaatin. Eli aina kun pyydät sertifikaatin,

sinun täytyy tarkistaa, että se on lisätty lokitietoihin.

Vastaako tuo kysymykseesi?
Kyllä. Mutta miten tuo sertifikaatin lisäys toimisi?

Esimerkiksi miten varmistetaan sertifikaatti lailliseksi?

OK. Idea on että milloin tahansa saat

sertifikaatin, se laitetaan lokiin ja jokainen joka saa sertifikaatin,

odotetaan tarkistavan että se on lokitiedoissa.

Eli valtuutettu laittaa sertifikaatin lokiin?

Niin sen odotetaan toimivan.

Kyllä. OK. Kiitos.

Ole hyvä.
Sitten meillä on yksi kysymys

internetistä.
Kysyjä haluaa tietää, voimmeko

tai mistä voimme saada autentikoinnin PGP avaimelle ja miten se liitetään avaimeen

jälkikäteen. Onko se mahdollista?

Se vähän riippuu. PGP:n kanssa, yleensä on niin siinä ei ole

keskitettyä sertifiointi valtuutettua tai joukkoa niitä, vaan on

olemassa tietyn lainen sosiaalinen joukko ihmisiä, jotka tuntevat ja vaihtavat

sähköposteja, joista jokaisen pitäisi autentikoida julkiset avaimensa

OK? Eli kun haluat kommunikoida jonkun kanssa jota et tunne

mutta jonka ystävä voi olla oma ystäväsi,

on voinut autentikoida tämän avaimen. Ja jos luotat

ystävääsi, voit tarkistaa, et hän on voinut luoda jonkinlaisen

sertifikaatin omalle ystävälleen.
Onko lisäkysymyksiä?

Yksi vielä? Olkaa hyvä.
En tiedä koskeeko kysymys puhettasi

mutta joku haluaisi tietää. Suosittelisitko

startTLSää tai SSSL/TLSää sähköpostiin?
Omasta puolestani suosittelisin aina varustamaan uloimman

kryptauksella. Ensiksikin, rakennettaessa

turvallista yhteyttä sähköpostipalvelimelle ja tekemällä SMTPn

tai jotain siihen, on aina parempi perustaa suora varmennettu

yhteys kuin käyttää startTLSää.

Tämä taitaa olla tässä kysymyksien osalta, annetaanpa

Aplodit Ootsille!

- suosionosoituksia -

- musiikkia -

Translated by {FirstName}{LastName} (ITKST56 course assignment at JYU.FI) 2023