Suhteessa viime kertaan tässä artikkelissa voit kiinnittää huomiota mm. luvussa 2 esitettyyn hyökkäykseen X.509-protokollaa vastaan ja periaatteeseen 2 perusteena avaimen käytön kontrollille (vrt TTJ, id=449). TTJ-kurssilla (id=232 ja id=233) esitelty ElGamal-algoritmi sekä redundanssin lisääminen (id=231) kannattaa muistaa lukua 4 tutkiessasi. Subliminaalisesta kanavasta löytyy tietoa TTJ:n B-osasta (id=332). Periaatetta 7 kannattaa pohtia myös avaimen elinkaaren näkökulmasta (TTJ, id=74).
Luvussa 2 mainittu birthday attack lähtee siitä, että poimittaessa satunnaisesti (ja palauttaen) alkioita n:n alkion joukosta jo kertaluokkaa O(n1/2) olevan vaivan jälkeen kohtuullisen suurella todennäköisyydellä on osuttu samaan arvoon. Kun n=365, todennäköisyys ylittää 0.5, kun poimintoja on tehty 23.
Tietenkin hyökkääjä voi laskea salasana-arvauksesta s' arvauksen yhteiseksi tiedoksi y'. Jos tämä sattuisi olemaan sama kuin y, hyökkääjä voisi luonnollisesti käydä koko protokollan jomman kumman osapuolen roolissa ja tulla autentikoiduksi. Tällainen lotto-osuma on aina mahdollista, mutta sen kokeileminen on-line on äärimmäisen kallista. Arvauksen y' todentaminen off-line vaatisi sen, että y':n (tai alunperin s':n) avulla voisi laskea ja saada tulokseksi jotain samaa kuin protokollasta kaapatussa viestissä on -- ja samuus toteutuisi vain siinä tapauksessa, että y' = y. Laskun lähtöarvoina saa tietysti olla niinikään protokollasta kaapattua tietoa, myös sellaista jota hyökkääjä on itse siihen aiemmin syöttänyt.
Protokollalla SRP on lisäominaisuutena se, että palvelimelle (B:lle) tallennetut salasanatiedot eivät paljastuessaan päästä ketään esiintymään A:na. Palvelimella on A:sta tietona vain gy mod p. Tunnetusti tämä ei tarjoa mahdollisuutta käyttää pelkkää y:tä mihinkään. Palvelin ei tarvitse protokollassa pelkkää y:tä, mutta A tarvitsee sitä avaimen k laskemiseen (kertolaskussa uy), ja samoin tarvitsisi tietokannan murtanut hyökkääjä voidakseen esiintyä A:na. Vastaava "augmentoitu" muoto on olemassa myös muista kolmesta protokollasta.
Edellisiä uudempi ehdotus vastaavaan tarkoitukseen -- joskin ilman viimeksi mainittua lisäominaisuutta -- on esitetty artikkelissa Secure remote user access over insecure networks (Mohammad Peyravian, Clark Jeffries, 2005 sama HTML:nä). Siinä käytetään DH-vaihdon lisäksi vain hash-funktiota ja XOR-operaatiota (luvussa 3). Artikkeli on kirjoitettu lähes liioittelevan helppotajuiseen ja itseään kertaavaan muotoon. Silti lukijaa on "hämätty" kirjoittamalla XOR-merkinnän sijaan sulkumerkki '('. Eli joka kerta kun sulut eivät täsmää, pitää yksi osata lukea XOR:ksi!
Protokolla etenee tähän tapaan eo. merkinnöin:
Artikkeli käyttää yhden 8 sivustaan sen esittämiseen, miten A voi autentikoinnin jatkeena em. istuntoavaimen tapaisella hash-arvolla h = H( g ab mod p, RA, RB ) "maskeerata" uuden salasanan tiivisteen y' -- siis XOR-summalla h+y'. Näyttäisi, ettei tällaista tarvittaisi, mikäli viestintä on jo istuntoavaimella salattua. Erillinen salasananvaihtoprotokolla (=em. autentikointi ja sen jälkeen A:lta h+y' ja B:ltä konfirmointi) voi kuitenkin olla hyödyllinen. Salasana(tiivistee)n vaihto-operaatio ja sitä kautta uusi salasana ei silloin ole haavoittuvainen niille uhkille, joita istuntoavaimen hallinta voi tuottaa tai joita salatun viestinnän kautta voi ilmetä. Viestintähän voi tuottaa paljon kryptotekstiä ja osasta sitä voi ennemmin tai myöhemmin tarjoutua myös selkotekstiä. Vaikka istuntoavain joskus murtuisi, salasanatiiviste ei silti paljastuisi.
Harjoitus. Tutkitaan, mitä eo. autentikaatioprotollassa tapahtuu, jos toinen viesti tuleekin C:ltä, joka on kaapannut ensimmäisen viestin. Olkoon toisen viestin jälkiosa R, joka näyttää A:n silmissä yhtä satunnaiselta kuin muutenkin. Olkoon C:n yksityisenä DH-lukuna c.
Voisiko protokollan korjata jotenkin? Sitä varten pitäisi saada A huomaamaan, ettei vastaaja olekaan B. Nimeämisperiaatteen käytöstä ei ole ainakaan suoraan apua, sillä toisessa viestissä ei ole mitään, minkä A tarkastaa. Tässä protokollassa rikottiin oikeastaan Toimintaehdot-periaatetta: A purkaa 2. viestissä olevan RB-luvun XOR-maskeerauksen ja paljastaa maskin, vaikka sillä ei ole perusteita tälle toimelle. Paljastushan kuuluu asiaan, jos viesti tuli B:ltä. Voisiko viestin rakennetta monipuolistaa jotenkin, jotta paljastamiselle löytyisi peruste? (Vastauksen pitäisi ilmetä siitä mitä sanottiin autentikointijärjestyksestä.)
Mainittua hyökkäystä selitetään ja täydennetään hieman Davisin artikkelin (2001) luvussa 1.2. Erityinen huomio on huijatun julkisen RSA-eksponentin erikoislaatuisuus, kun se ei olekaan 3 tai muuta tavallista muotoa. Davisin artikkelin varsinainen idea paljastuu nimestä: "Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML", eikä kyseiseen ensin allekirjoitetun ja sitten salatun viestin tulkintaongelmaan pitäisi kenenkään langeta ainakaan tämän kurssin jälkeen.
Päivän artikkelin mukaan vastaavanlainen huijaus voi "syntymäpäivähyökkäyksen" ansiosta tulla mahdolliseksi symmetristä kryptosysteemiä vastaan, jos siinä kryptataan kahdella avaimella peräkkäin ja tulosta käytetään allekirjoituksen tapaan. Hyökkääjän tavoitteena on siis keksiä uusi avain, jolla saisi haluamastaan viestistä saman kryptaustuloksen kuin aiemminkin. Haku ei ole yhtä hankalaa kuin kahden avaimen yhteenlaskettu pituus näyttäisi vaativan, vaan "meet-in-the-middle"-tekniikalla vain yhden avaimen verran bittejä täytyy käydä läpi. Samasta syystä esim. DESiä ei kannata (salaustarkoituksiinkaan) vahvistaa kahdella kryptauksella, vaan pitää käyttää kolmea, vaikka avaimia olisikin kaksi.
Tässä kohden artikkeli korostaa käsitteellistä eroa dekryptauksen ja allekirjoituksen välillä, vaikka RSA:ssa nämä ovat näennäisesti aivan sama toimenpide. Esimerkkinä olevassa Woo-Lam-protokollassa B uskoo kyllä viestin 7 tulevan A:lta, koska A on sitä varten dekryptannut B:n viestissä 6 olleen nonce-luvun. B ei kuitenkaan voisi vakuuttaa ketään muuta tästä, sillä hän olisi tietenkin itse voinut tuottaa myös viestin 7.
Monimerkityksisyys tarkoittaa tässä sitä, että kryptaussysteemi voi joiltakin osiltaan olla "many-to-one" eikä "one-to-one" kuten yleensä. Tällöin hyökkääjä ei voi päättää mikä selväteksti on oikea useiden mahdollisten joukosta. Redundanssilla, jota on jo käsiteltykin, on päinvastaista vaikutusta.
Huolimattomasti käytetyt ylimääräiset bitit voivat avata subliminaalisen eli piilokanavan (myös: covert channel). Sillä tarkoitetaan yleisesti mitä tahansa keinoa, jonka kautta luottamuksellista tietoa voi päätyä asiattomille tyypillisesti sellaisen toimijan (esim. Troijan hevosen) lähettämänä, jolla on kyllä oikeus tietoon, mutta ei oikeutta sen lähettämiseen mitään normaalia kanavaa pitkin.
Tässä on taustalla vaikutus, joka erityisesti symmetrisen avaimen paljastumisella voi olla protokollan muihin suorituskertoihin. Artikkelin hyökkäysesimerkki (Goss-protokollaa vastaan) on varsin monipolvinen. Sen yleisenä rakenteena on seuraava: hyökkääjä C salakuuntelee A:n ja B:n väliset avaintenvaihtoviestit (ja varastoi siinä syntyneellä avaimella salattuja sanomia). Sitten C käyttää kopioimiaan viestejä avaimenvaihtoon sekä A:n että B:n kanssa. Hän ei pysty laskemaan kumpaakaan näistä avaimista, mutta tässä oletetaan, että hän saa ne urkituksi A:lta ja B:ltä jossain vaiheessa. Kun hän on saanut ne, hän pystyy laskemaan A:n ja B:n välisen avaimen ja purkamaan varastoimansa sanomat.
Tällaiseen "tunnettu-avain"-hyökkäykseen voi huolimattomuuden, varkauden tms. lisäksi tulla mahdollisuus myös, kun jonkin sopimuksen allekirjoituksen jälkeen salaukset voidaan purkaa, tai kun piilokanavien välttämiseksi avaimet paljastetaan heti, kun niitä on käytetty johonkin autentikointiin. Tällaiset seikat tarjoavat toki lisämotivaatiota myös Abadi-Needhamin 9. periaatteelle "Avaintuoreus".
Tässä viitataan esimerkkinä rahanheittoprotokollaan, jossa A saa B:ltä luvun g1r tai g2r (mod p), missä r on B:n valitsema satunnaisluku, jonka B paljastaa myöhemmin. Myöhemmin B myös kertoo, kumman hän oli korottanut g1:n vai g2:n. Lopussa A:n pitäisi voida tarkistaa, että alussa saatu luku on asiaankuuluva r:s potenssi. Mutta B onkin voinut valita r:n yhdessä toisen luvun r' kanssa siten, että g1r = g2r', jolloin hän voi olla aluksi lähettänyt g1r:n mutta myöhemmin kertookin g2:n ja r':n. Kyseisenlaisten r:n ja r':n löytäminen on helpompaa kuin (ylivaikeaksi oletettu) diskreetin logaritmin laskeminen.
Tällaisten asioiden arviointia ei välttämättä tarvitse tehdä omakohtaisesti, kunhan vain asiaa selvittäviä tutkimuksia on saatavissa ja lukijalla on riittävät kryptologian perustiedot niiden ymmärtämiseen. Tällä kurssilla ei käsitellä rajoitteita tarkemmin, mutta kynnysprotokollia kylläkin esitellään.
Tätä periaatetta tekijät esittävät eräänlaiseksi perusperiaatteeksi, josta muut ovat enemmän tai vähemmän sovelluksia. Vastaavassa asemassa viime kerralla olivat periaatteet 1 ja 2.
Use design principles at the beginning, middle, and end of designing a protocol. First, use them to guide your preliminary design. Then, when you have a specication, go through them all and look at the motivation for applying the principle in the given context. Is the motivation best served by following the principle, and if not, how might it better be served? When you have a final design, go through the principles again and look at those you violated. Make sure you have a good reason for doing so in each case.
Any good application developer has to assume that PoP was not done at the time of enrollment. In particular, an application developer must
- explicitly include all necessary identification and context information in the parts of application protocol messages that are cryptographically protected, (for example, a PKI-enabled e-mail client could include the name of the sender in the signed text; signature verification should fail if this address does not match the name in the certificate used to verify the signature.)
- require the use of different keys for different purposes, and
- consistently and correctly identify the purpose of a given key (e.g., by precisely defining the semantics of the keyUsage attributes) so that it is not used for a different purpose.