Tietoturvan perusteet - Syksy 2005 SSH salattu yhteys & autentikointi Tekijät: Antti Huhtala & Asko Ikävalko (TP02S)

Yleistä SSH-1 vuonna 1995 (by. Tatu Ylönen)  Korvaa suojaamattomat yhteydentottotavat Telnet, FTP jne..  Puutteellinen oikeellisuuden tarkistus CRC-32  Yleisimmät autentikointitavat: Password Public key Keyboard-interactive GSSAPI

Yleistä 1996 kehitettiin SSH-2  Standardoitu (IETF) Internet Engineering Task Force  Tietoturvaa parannettu Diffie-Hellman avainten vaihto Parempi tiedon eheyden tarkistus (MAC)  Tuki useammalle kanavalle Esim. Yksi terminaalille, toinen tunneloinnille

SSH arkkitehtuuri  Transport layer Avainten vaihto Palvelimen tunnistus  User authentication layer Käyttäjän tunnistus  Connection layer Kanavien hallinta

SSH-1 salatun yhteyden avaus

Serverin pysyvät salausavaimet 1024 bit (luotu asennuksen yhteydessä) - julkinen host-key - salainen host-key Lisäksi vaihtuvat salausavaimet 768 bit (vaihtuu 1 krt/h tai 1 krt/GB) - julkinen server-key - salainen server-key

Yhteyden avaus

public host-key & server-key

Onko minulla jo ennestään serverin public host-key? On. Ei. ”tunnen kaverin, voidaan jatkaa” Ei tietoa kuka avaimen meille lähetti. Mahdollisesti MiM (man- in-middle) hyökkäys meneillään.

Generoidaan 256 bitin satunnaisluku ja salataan se serverin julkisilla avaimilla

Lähetetään 256 bit satunnais- luku salattuna serverille Salattu random-luku Serveri purkaa salauksen omilla salaisilla avaimillaan ja pystyy lukemaan satunnaisluvun alkuperäismuodossaan.

Salattu liikenne Nyt molemmat tietävät yhteisen salaisuuden, jota voidaan käyttää session-key avaimena symmetrisessä salauksessa. (esim. 3DES tai Blowfish) Liikennöinti symmetrisellä salauksella on nopeampaa, kuin epäsymmetrisellä salauksella!

SSH-2 salatun yhteyden avaus

Serverin pysyvät salausavaimet (luotu asennuksen yhteydessä) - julkinen host-key - salainen host-key SSH2 ei tarvitse host-keyn lisäksi vaihtuvaa server-key avainta, jota SSH1 käyttää neuvotellessaan yhteisestä session-key:stä (symmetrinen avain). Sen sijaan käytetään Diffie-Hellman algoritmia yhteisen salaisuuden luomiseen.

Vuonna 1976 keksittyä Diffie-Hellman protokollaa käytetään yhteisen salaisuuden sopimiseen kahden sellaisen tahon välillä, jotka eivät ennestään tunne toisiaan. Ensin sovitaan julkiset avaimet P (joku iso alkuluku) ja G (oltava pienempi, kuin P), jotka on molemmilla tiedossa. Nämä voidaan sopia julkisen jakelutien välityksellä. Lisäksi kumpikin keksii oman salaisen avaimen X. Seuraavaksi kumpikin luo oman julkisen avaimen Y = G^X%P ja keskustelukumppanit kertovat Y:n toisilleen. Tämän jälkeen kumpikin laskee uuden avaimen Z = Y^X%P Lopputuloksena molempien Z on sama yhteinen salaisuus. Salaisia avaimia X ja Z ei tarvitse missään vaiheessa siirtää osapuolten välillä. (nerokasta!!) Sovitaan yhteiset P ja G Minun Y Z ZZ = Z

Yhteyden avaus Client ehdottaa haluamaansa P:n arvoa (min, toivottu, max) Serveri valitsee P:n arvon clientin toivomalta väliltä ja laskee P:n arvolle sopivan G:n arvon. Serveri toimittaa P:n ja G:n clientille. Tässä P ja G

Minun Y Client kertoo oman julkisen avaimensa serverille Client keksii oman salaisen X:n Lasketaan julkinen Y = G^X%P Serveri keksii oman salaisen X:n Lasketaan julkinen Y = G^X%P

Serveri laskee Hash-tiivisteen näistä luvuista: 1. Clientin SSH versio (string)<- yhteydenottopyynnöstä 2. Serverin SSH versio (string) 3. Clientin salausprotokolla-pyyntö<- yhteydenottopyynnöstä 4. Serverin salausprotokolla-pyyntö 5. Serverin julkinen host-key 6. Clientin pyytämä minimi P:n arvo<- yhteydenottopyynnöstä 7. Clientin toivoma P:n arvo<- yhteydenottopyynnöstä 8. Clientin pyytämä maksimi P:n arvo <- yhteydenottopyynnöstä 9. Valittu P:n arvo 10. Valittu G:n arvo 11. Clientin julkinen avain Y 12. Serverin julkinen avain Y 13. Yhteinen salaisuus Z Serveri allekirjoittaa laskemansa Hash-tiivisteen omalla salaisella host-key avaimellaan.

public host-key Minun Y Hash-signature

Onko minulla jo ennestään serverin public host-key? On. Ei. ”tunnen kaverin, voidaan jatkaa” Ei tietoa kuka avaimen meille lähetti. Mahdollisesti MiM (man- in-middle) hyökkäys meneillään.

Client laskee Hash-tiivisteen samoilla 13 arvolla, joita serveri käytti ja vertaa lopputulosta serverin lähettämään Hash-tiivisteeseen. Jos tulos on sama, voidaan olla riittävän varma siitä kenen kanssa parhaillaan keskustellaan.

Salattu liikenne Voidaan ryhtyä liikennöimään halutulla symmetrisellä salauksella käyttäen session- key avaimena yhteistä salaisuutta Z. Liikennöinti symmetrisellä salauksella on nopeampaa, kuin epäsymmetrisellä salauksella! Z Z

SSH yhteyksissä käytetään mm. seuraavia symmetrisiä salauksia: -3DES -Blowfish -AES (128, 192 tai 256 bit) -CAST128 -Arcfour -....jne.

Salasalanalla autentikointi  Ainoa tapa todistaa palvelimelle että ”olen se kuka väitän olevan”, on kertoa salasana  Jos palvelin on hakkeroitu/spooffattu hyökkääjä saa salasanan

Public key -autentikointi  Luodaan salainen ja julkinen avain  Salaisen avaimen avulla muodostetaan signature  Tämä kerrotaan palvelimelle salasanan sijaan  Palvelin todentaa signaturen aidoksi julkisella avaimella  Jos palvelin on hakkeroitu/spooffattu, hyökkääjä ei saa käsiin salasanaa, eikä salaista avainta

Public key –autentikointi jatkoa...  Salainen avain on tallennettu salaamattomana Kuka tahansa, joka pääsee käsiksi avaimeen pystyy kirjautumaan palvelimelle sinuna  Tämän takia salainen avain on syytä salata salaisella ’lausekkeella’

Avainagentti  Säilyttää istunnon ajan salaiset avaimet  Salalauseketta ei tarvitse syöttää jokaisella kerralla kun kirjaudutaan ssh-palvelimelle  Esim. Pageant

Avaimien luominen (Puttylle) 1. Generoidaan SSH2 RSA avaimet

Avaimen salaus yms.. 1. Liitetään public key palvelimelle ”~/.ssh/authorized_k eys” -tiedostoon 2. Salataan private key ’salalausekkeella’ 3. Tallennetaan salainen avain

Yhteyden avaus Puttyllä Lisätään käytettävä salainen avain  Connection/SSH/Auth Yhdistetään normaalisti palvelimelle

Jatkoa.. Mitä kirjautuessa tapahtuu: 1. Private key avataan salalausekkeella 2. Luodaan signature salaisen avaimen avulla 3. Signature lähetetään palvelimelle 4. Palvelin tarkistaa tämän public keyn avulla

Sovellusesimerkki: Remote Desktop tunnelointi SSH-putken kautta

Palomuuri, jossa SSH-palvelin (Ulko-IP = ) Kotikone, jossa Remote Desktop palvelu päällä (IP = TCP-port = 3389) Koulu Nettikahvila Duuni tms. jossa Putty.exe SSH-tunneli Palomuurisäännöissä sallittava: - Netistä muuriin SSH-portti 22 - Muurista LANiin Remote Desktop portti 3389

Remote Desktopin lisäksi SSH-tunneleita voidaan käyttää moneen muuhunkin: localhost -> :3386 localhost -> smtp.evtek.fi:25 localhost -> imap.evtek.fi:143 localhost -> cache.evtek.fi:8000 (kirjaston eKirjat)

Lähteet: Nämä kalvot saatavilla: