Esittely latautuu. Ole hyvä ja odota

Esittely latautuu. Ole hyvä ja odota

Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 1 Planning for PKI: Best Practices Guide for Deploying Public.

Samankaltaiset esitykset


Esitys aiheesta: "Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 1 Planning for PKI: Best Practices Guide for Deploying Public."— Esityksen transkriptio:

1 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 1 Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure Luku 13. PKI-Enabled Applications Luku 14. Defense Message System 1.0

2 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 2 Luku 13. PKI-Enabled Applications Sivut 199-218 SMIMEv3 TLS IPSec

3 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 3 S/MIMEv3 S/MIMEv3 (Secure/ Multipurpose Internet Mail Extension version 3) suojauslaajennus MIME- sähköpostistandardiin. Perustuu RSA luomaan S/MIMEv2 määrittelyyn. Määrittely julkaistiin IETF:ssä jossa parannusten jälkeen muodostui standardi S/MIMEv3. S/MIMEv2 ja S/MIMEv3 määrittelevät kaksi MIME- pakkausta (MIME wrapper), eli digitaaliseen allekirjoitukseen ja salaukseen Molemmat pakkaukset käyttävät PKCS#7: Cryptographic Message Syntax Standard- rakennetta PKCS#7, Public-Key Cryptography Standard#7

4 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 4 MIME- Formaatti Esimerkki moniosaisesta viestistä. Sisältää kaksi kappaletta jotka molemmat sisältävät tekstiä [RFC2046]. From: Nathaniel Borenstein To: Ned Freed Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST) Subject: Sample message MIME-Version: 1.0 Content-type: multipart/mixed; boundary="simple boundary" This is the preamble. It is to be ignored, though it is a handy place for composition agents to include an explanatory note to non-MIME conformant readers. --simple boundary This is implicitly typed plain US-ASCII text. It does NOT end with a linebreak. --simple boundary Content-type: text/plain; charset=us-ascii This is explicitly typed plain US-ASCII text. It DOES end with a linebreak. --simple boundary-- This is the epilogue. It is also to be ignored.

5 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 5 S/MIMEv3; enveloped-data Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V Salattu S/MIME- viesti. Viesti salattu vastaanottajan julkisella avaimella MIME- sisältötyyppi: application/pkcs7-mime SMIME- tyyppi: enveloped-data [RFC2633]

6 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 6 S/MIMEv3; signed-data Content-Type: application/pkcs7-mime; smime-type=signed-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 6YT64V0GhIGfHfQbnj75 Allekirjoitettu S/MIME- viesti. Viesti allekirjoitettu/ salattu lähettäjän yksityisellä-avaimella. MIME- sisältötyyppi: application/pkcs7-mime SMIME- tyyppi: signed-data [RFC2633]

7 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 7 S/MIMEv3; multipart/signed Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 --boundary42 Content-Type: text/plain This is a clear-signed message. --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42-- Viesti sisältää selvätekstisen viestin (MIME- formaatissa) sekä viestin allekirjoitetussa/ salatussa muodossa (SMIME- formaatti). Viesti allekirjoitettu/ salattu lähettäjän yksityisellä-avaimella. MIME- sisältötyyppi: multipart/signed Protokolla: application/pkcs7-signature Käytännöllinen tilanteessa jossa viestin vastaanottajalla on MIME- tuki mutta ei ole SMIME- tukea. Tässä tapauksessa vastaanottaja voi lukea viestin mutta ei tarkistaa allekirjoitusta. [RFC2633]

8 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 8 Transport Layer Security, TLS TLS- protokolla suojaa sovellusten välisen tietovirran. Käytetään yleisesti suojamaan Web- palvelimen ja Web- selaimen välistä liikennettä. Alkuperäinen kehittäjä Netscape jolloin käytettiin nimitystä Secure Sockets Layer (SSL). Kehitystä jatkettiin edelleen IETF:ssä missä protokolla nimettiin TLS:ksi. Protokolla SLLv3.1 nimetään uudelleen TLSv1.0. Protokolla muodostuu kahdesta eri kerroksesta; kättelyprotokolla (Handshake Protocol) ja tietueprotokollasta (Record Protocol).

9 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 9 TLS- Aliprotokollat Kättelyprotokolla autentikoi palvelimen ja asiakkaan, neuvottelee salausalgoritmin sekä muodostaa kryptausavaimet ennen sovellusten välisen tiedonsiirron aloittamista. Tietueprotokolla kapseloi ja suojaa ylemmäntason protokollat myös kättelyprotokollan. Tietueprotokolla käyttää yhteydellistä TCP- protokollaa. Yhteydettömien protokollien kuten UDP suojaamiseen tietueprotokolla ei sovellu. SSL- ja TLS- protokollat ovat riippumattomia sovellusprotokollasta eli kaikki tietovirtasovellusprotokollat voivat läpinäkyvästi toimia kyseisten protokollien päällä. SSL ja TLS- protokollat tarjoavat tietovirtapohjaisille sovelluksille kolme perusominaisuutta.

10 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 10 TLS- Protokolla, Perusominaisuudet Autentikaatio (Authentication) Vahvistaa vertaissolmun identiteetin. Kättelyprotokolla käyttää serfifikaatteja ja digitaalista allekirjoitusta varmentaakseen etäsovelluksen identiteetin. Eheys (Integrity) Sovellusprotokollan tieto suojataan huomaamattomalta muutokselta. Tietueprotokolla käyttää eheyden varmentamiseen HMAC- algoritmia ( Hashed Message Authentication Code ). Luotettavuus (Confidentiality) Yhteys on luottamuksellinen. Kättelyprotokolla muodostaa symmetrisensalausavaimen, tietueprotokolla salaa loput yhteydestä.

11 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 11 TLS- Autentikaatio SSL- ja TLS- protokollat mahdollistavat vastavuoroisen autentikaation. Tätä ominaisuutta ei kuitenkaan sovelleta käytännössä. Yleensä SSL- ja TLS- protokollat tarjoavat palvelimesta sertifikaattipohjaisen autentikaation asiakkaalle. Tällöin käytetään toisia menetelmiä autentikoimaan käyttäjä palvelimelle hyväksikäyttäen muodostettua salattua yhteyttä. Esimerkiksi palvelin voi pyytää asiakasta syöttämään käyttäjätunnuksen ja salasana.

12 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 12 Kättelyprotokolla Kättelyprotokolla vastaa istunnon neuvottelemista. Neuvottelussa määritellään seuraavat muuttujat: Istuntotunniste (Session Identifier) Palvelimen valitsema satunnainen bittisarja session identifiointiin Pakkausmenetelmä (Compression Method) Tiedon kompressoinnissa käytettävä pakkausalgoritmi ennen salausta Salausalgoritmi (Cipher Spec) Määrittelee kompressoidun tiedon salausalgoritmin kuten DES/3DES ja yksisuuntaisen tiivistealgoritmin kuten SHA-1 Pääsalaisuus (Master Secret) Jaettu salaisuus asiakkaan ja palvelimen välillä Palautettavuus (Is Resumable) Lippu millä osoitetaan voidaanko istuntoa käyttää uusien yhteyksien muodostamiseen Näitä muuttujia käytetään tietueprotokollan tietoturvaparametrien asettamiseen

13 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 13 Kättelyprotokolla Kättelyprotokolla muodostuu seuraavista vaiheista: Vaihe 1: 1.1 Asiakas lähettää client_hello- sanoman palvelimelle. Sanoma sisältää asiakkaan tukemat suojausominaisuudet kuten käytetyn SSL/TSL- versionumeron, tuetut salausalgoritmit ja tiedonpakkausmenetelmät. 1.2 Palvelin vastaa server_hello- sanomalla asiakkaalle. Sanoma sisältää valitun salausalgoritmin, tiedonpakkausmenetelmän ja senhetkisen istuntotunnuksen. Vaihe 2: 2.1 Palvelin lähettää certificate- sanoman. Sanoma sisältää palvelimen sertifikaatin. (2.2 Palvelin lähettää tarvittaessa server_key_exchenge- sanoman. Viestiä ei lähetä jos palvelin on lähettänyt sertifikaatin muuttumattomilla Diffie-Hellman parametreillä tai on käytetty RSA- avaintenvaihtoa.) (2.3 Palvelin lähettää certificate_request- sanoma. Sanoma sisältää asiakkaalle pyynnön lähettää oma sertifikaatti palvelimelle.) 2.4 Palvelin lähettää server_hello_done- sanoman lopetettuaan sanomien lähetyksen. Sanoman jälkeen palvelin odottaa työaseman vastausta.

14 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 14 Kättelyprotokolla Vaihe 3: (3.1 Jos palvelin on pyytänyt asiakasta lähettämään sertifikaatin asiakas lähettää certificate- sanoman. Sanoma sisältää asiakkaan sertifikaatin. Jos sertifikaattia ei ole olemassa asiakas lähettää no_ certificate- viestin.) 3.2 Asiakas lähettää client_key_exchenge- sanoman. Asiakas luo 48- bittisen pre-master -salaisuuden ja salaa sen palvelimen julkisella-avaimelle (kohta 2.1) tai tilapäisellä RSA- avaimella (kohta 2.2). Tätä käytetään luomaan lopullinen master- salaisuus. Palvelin avaa sanoman omalla julkisenavaimen yksityisellä avaimella. (3.3 Asiakas lähettää certificate_verify- sanoman toimittaakseen täsmällisen vahvistuksen asiakkaan sertifikaatista) Vaihe 4: Osapuolet laskevat pre-master -salaisuudesta master- salaisuuden 4.1 Asiakas lähettää change_cipher_spec- viestin. Sanoma sisältää molemmille osapuolille sopivan salausalgoritmin (3DES) ja tiivistealgoritmin (SHA-1). 4.2 Asiakas lähettää välittömästi finished- sanoman. Tämä sisältää kaikki sanomat alkaen client_hello- viestistä mutta ei sisällä tätä viestiä, MD5- tiivisteistä ja master- salaisuuden. Näin osapuolet todentavat että aikaisemmin vastaanotetut sanomat ovat kunnossa eikä niitä ole peukaloitu matkalla.

15 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 15 Kättelyprotokolla 4.3 Palvelin lähettää change_cipher_spec- viestin. Sanoma sisältää molemmille osapuolille sopivan salausalgoritmin (3DES) ja tiivistealgoritmin (SHA-1). 4.4 Palvelin lähettää välittömästi finished- sanoman. Tämä sisältää kaikki sanomat alkaen client_hello- viestistä mutta ei sisällä tätä viestiä, MD5- tiivisteistä ja master- salaisuuden. Näin osapuolet todentavat että aikaisemmin vastaanotetut sanomat ovat kunnossa eikä niitä ole peukaloitu matkalla.

16 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 16 Tietueprotokolla Tietueprotokolla jakautuu useisiin alikerroksiin. Protokolla paloittelee sovelluksen tuottaman lähetettävän tiedon osiin, valinnaisesti kompressoi tiedon, laskee eheystarkistussumman, suorittaa salauksen, lisää otsikon ja lähettää lopputuloksen eteenpäin TCP- kehyksessä. Vastaanotossa salattu paketti avataan, varmennetaan, puretaan kompressointi, kootaan uudelleen ja välitetään ylemmäntason sovelluksen käyttöön.

17 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 17 IP Security, IPSec IPSec- protokolla suojaa IP- tietopaketit kolmannella kerroksella (Layer 3) IETF:n tekemä standardi joka koostuu useita eri dokumenteista/ määrittelyistä IPSec- protokolla tarjoaa kokonaisvaltaisen IP- tason tietoturvastandardin mutta on määrittelyiltään hyvin kompleksinen Voidaan implementoida päätelaitteeseen, reitittimeen tai palomuuriin. Yleisin käyttökohde VPN- tunneleissa (Virtual Private Network). Näkymätön ylemmäntason kerroksille

18 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 18 IPSec Standardit ja Implementointi IPSec koostuu useista eri IETF:n määrittelemistä standardeista. Tärkeimpiä ovat: Security Architecture for the Internet Protocol (RFC 2401) IP Authentication Header (RFC 2402) IP Encapsulating Security Payload (ESP) (RFC 2406) Internet Security Association and Key Management Protocol (ISAKMP) (RFC 2408) IPSec implementoidaan yleisesti seuraavilla menetelmillä: Integrointi alkuperäiseen protokollapinoon Käyttöjärjestelmä kehittäjä integroi IPSec ominaisuuden suoraan IP- protokollapinoon Korvattava protokollapino Kolmas osapuoli valmistaa IP- protokollapinon joka sisältää IPSec tuen. Tällä korvataan alkuperäinen protokollapino. Jälkiasennus Kolmas osapuoli lisää IPSec tuen alkuperäiseen IP- protokollapinoon. IPSec lisätään protokollapinon ja verkkokorttiajureiden väliin. Ulkoinen verkkolaite IPSec- protokolla tukeva reititin tai palomuuri sijoitetaan haluttuun verkkosegmenttiin. Palvelee useita verkkoasiakkaita.

19 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 19 IPSec- Protokolla IPSec- protokolla tarjoaa tarjoaa kaksi vaihtoehtoa IP- tietoliikenneyhteyksien suojaamiseen: Autentikointiotsikko (Authentication Header, AH): Varmistaa tiedon eheyden ja IP- paketin oikeellisuuden. Salattukapselointi (Encapsulating Security Payload, ESP): Varmistaa tiedon luottamuksellisuuden ja oikeellisuuden. AH ja ESP tukevat kuljetusmoodia ja tunnelointimoodia (Transport and Tunnel Modes)

20 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 20 Security Association, SA Turvasopimus (Security Association, SA) on yksisuuntainen luottamus lähettäjän ja vastaanottajan välillä Kaksisuuntaiseen kommunikointiin lähettäjän ja vastaanottajan välillä tarvitaan kaksi turvasopimusta eli lähteville ja saapuville datapaketeille erikseen Turvasopimus identifioidaan yksiselitteisesti kolmella parametrilla: Turvaindeksi [Security Parameters Index (SPI)]: Käytetään turvasopimuksen identifiointiin. SPI liitetään AH- ja ESP- otsikoihin identifioimaan turvasopimus vastaanottajalle. IP- kohdeosoite (IP Destination Address): Ainoastaan unicast- osoitteet ovat sallittuja. Vastapuolen IP- osoite jonka kanssa turvasopimus on muodostettu (työasema, reititin, palomuuri). Turvaprotokollatunniste (Security Protocol Identifier): Osittaa käytetäänkö AH- vai ESP- otsikkoa

21 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 21 Authentication Header, AH Seuraava otsikko [Next Header (8bit)]: Identifioi seuraavan kehyksen otsikon Hyötykuorman pituus [Payload Lenght (8bit)]: Autentikointiotsikon pituus Varattu [Reserved (16bit)]: Kenttä varattu tulevaan käyttöön Turvaindeksi [Security Parameters Index, SPI (32bit)]: Identifioi turvasopimuksen Järjestysnumero [Sequence Number (32bit)]: Monotonisesti kasvava laskuri Autentikointidata [Authentication Data (muuttuva)]: Sisältää paketin ICV- (Integrity Check Value) tai MAC- (Message Authentication Code) tarkistussumman

22 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 22 Authentication Header; Transport Mode Transport Mode AH (IPv4). AH lisätään alkuperäisen IP- otsikon jälkeen ja ennen IP- hyötykuormaa. Autentikaatio käsittää koko paketin poislukien muuttuvat kentät. Transport Mode AH (IPv6). AH lisätään alkuperäisen IP- otsikon ja lisäotsikoiden jälkeen. Destination kenttä voi sijaita ennen tai jälkeen AH- kenttää. Autentikaatio käsittää koko paketin poislukien muuttuvat kentät.

23 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 23 Authentication Header; Tunnel Mode Tunnel Mode AH (IPv4). Koko alkuperäinen IP- paketti autentikoidaan ja AH lisätään alkuperäisen IP- otsikon ja uuden uloimman IP- otsikon väliin. Uloin ja sisin IP- otsikko voi sisältää eri osoitteet. Autentikaatio käsittää koko paketin poislukien uuden IP- otsikon muuttuvat kentät. Tunnel Mode AH (IPv6). Koko alkuperäinen IP- paketti autentikoidaan ja AH lisätään alkuperäisen IP- otsikon ja uuden uloimman IP- otsikon väliin. Uloin ja sisin IP- otsikko voi sisältää eri osoitteet. Autentikaatio käsittää koko paketin poislukien uuden IP- otsikon ja lisäotsikoiden muuttuvat kentät.

24 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 24 Encapsulating Security Payload, ESP Turvaindeksi [Security Parameters Index, SPI (32bit)]: Identifioi turvasopimuksen Järjestysnumero [Sequence Number (32bit)]: Monotonisesti kasvava laskuri Hyötykuorma [Payload (muuttuva)]: Verkkokerroksen segmentti (Transport Mode) tai IP- paketti (Tunnel Mode) Sivutus [Padding (0-255 tavua)] Sivutuksen pituus [Pad Lenght (8bit)] Varattu [Reserved (16bit)]: Kenttä varattu tulevaan käyttöön Seuraava otsikko [Next Header (8bit)]: Identifioi seuraavan kehyksen otsikon Autentikointidata [Authentication Data (muuttuva)]: Sisältää ESP- paketin ICV- (Integrity Check Value) tarkistussumman poislukien Authentication Data-kenttä

25 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 25 Encapsulating Security Payload; Transport Mode Transport Mode ESP (IPv4). ESP Header lisätään ennen kuljetuskerroksen otsikoita (TCP, UDP, ICMP). ESP Trailer lisätään IP- paketin loppuun. Käytettäessä autentikaatiota ESP Authentication Data lisätään ESP Trailer- otsikon perään. Transport Mode ESP (IPv6). ESP Header lisätään lisäotsikoiden jälkeen. Kohdeoptio lisäkenttä voi sijaita ennen tai jälkeen ESP Header- otsikkoa. ESP Trailer lisätään IP- paketin loppuun. Käytettäessä autentikaatiota ESP Authentication Data lisätään ESP Trailer- otsikon perään.

26 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 26 Encapsulating Security Payload; Tunnel Mode Tunnel Mode ESP (IPv4). Alkuperäinen IP- paketti salataan kokonaan. ESP Header lisätään uuden IP- otsikon jälkeen. Käytettäessä autentikaatiota ESP Authentication Data lisätään uuden IP- paketin perään. Tunnel Mode ESP (IPv6). Alkuperäinen IP- paketti salataan kokonaan. ESP Header lisätään uuden IP- otsikon ja lisäotsikoiden jälkeen. Käytettäessä autentikaatiota ESP Authentication Data lisätään uuden IP- paketin perään.

27 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 27 Luku 14. Defense Message System 1.0 Sivut 219-232

28 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 28 Defense Message System 1.0, DMSv1.0 DMS on tietoturvallinen X.400- pohjainen sähköpostijärjestelmä. Kehitetty Yhdysvaltojen puolustusministeriön (Department of Defense, DoD) tarpeisiin yhteystyössä alihankkijoiden kanssa. Ohjelman tavoitteena oli turvata kriittiset operaatiot. DMS korvasi aikaisemman DoD:n käytössä olleen AUTODIN- sähköpostijärjestelmän (automated digital network) sekä 45 muuta erilaista sähköpostijärjestelmää. Don Heckman kehitti helmikuussa vuonna 1994 DMS PKI- arkkitehtuurin

29 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 29 DMS ja Algoritmit DMS järjestelmä käyttää NSA- organisaation (National Security Agency) luomia algoritmeja tiedon varmentamiseen, eheyden ja kiistämättömyyden toteutukseen DMS- käyttää algoritmeja: Digital Signature Algorithm (DSA) digitaaliseen allekirjoitukseen Secure Hash Algorithm (SHA-1) yksisuuntaisena tiivistefunktiona Key Exchange Algorithm (KEA) avainsopimuksena SKIPJACK algoritmin symmetriseen salaukseen KEA ja SKIPJACK olivat vuonna 1994 salaisia algoritmeja. Vuonna 1998 kesäkuun 28 päivänä DoD julkaisi algoritmit yleiseen tietouteen.

30 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 30 SPYRUS ja FORTEZZA Edellisellä sivulla luetellut algoritmit on implementoitu SPYRUS- yhtiön valmistamaan FORTEZZA- salauskorttiin. Kortti liitetään PCMCIA- väylään. Kortti toimii itsessään salausmodulina eikä sisällä kortinlukijaa (vertaa HTS- älykortti ratkaisu). Salauskortti sisältää yhden sertifikaattivaltuutetun julkisenavaimen. Hinta Spyrus FORTEZZA Crypto Card (PC300) Encryption Module- kortilla on 271$ (www.shopping.com)

31 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 31 PKI- Arkkitehtuuri PAA- juurivarmentaja luo oman avainparin ja allekirjoittaa sertifikaatin itselleen. Sertifikaatti sisältää PAA- juurivarmentajan yksikäsitteisen X.500 nimen ja julkisenavaimen. Kyseinen sertifikaatti kirjoitetaan FORTEZZA- salauskorttiin. Tämän avulla osoitetaan yksi luotettu juurivarmentaja ja sen alapuolella olevat alivarmentajat. Koska käyttäjät eivät tiedä salauskortin SSO PIN- tunnusta (System Security Officer Personal Identification Number) niin käyttäjät eivät voi vahingossa tai tahallisesti muuttaa juurivarmentajaa.

32 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 32 PAA- Juurivarmentaja FORTEZZA- salauskortti sisältää sertifikaattipolun juurivarmentajan ja käyttäjän välillä. Korttiin tallennetaan PAA, PCA, CA ja käyttäjä sertifikaatit. Lisäksi sertifikaatit julkaistaan julkisessa X.500 hakemistojärjestelmässä. PAA - juurivarmentaja on vastuussa PCA- alivarmentajien autentikoinnista ja myöntää niille seftifikaatit. PCA luo oman avainparin, kopioi julkisenavaimen levykkeelle ja kuljettaa sen PAA:lle. Levykkeeltä PAA lukee PCA:n julkisenavaimen. PAA varmistaa että jokaisella PCA:lla on yksikäsitteinen X.500 nimi ja PAA antaa jokaiselle PCA:lle 20 bittisen ainutkertaisen tunnisteen. Tunniste on osa ainutkertaista KMID- tunnistetta (Key Material Identifier) mikä annetaan jokaiselle julkiselle/ salaiselle -avainparille. PAA generoi sertifikaatin PCA:lle ja kirjoittaa sen levykkeelle joka siirretään sitten PCA:lle. PAA:n sertifikaatin allekirjoitusprosessi varmistaa että vihamielistä PCA ei tuoda mukaan PKI- järjestelmään. PAA ei pidä yllä sertifikaattien poistolistaa (Certificate Revocation Lists, CRL).

33 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 33 PCA- Alivarmentaja PCA- alivarmentaja on vastuussa sertifikaattien myöntämisestä ja täytäntöönpanon valvonnasta omassa yhteisössään. PCA on vastuussa FORTEZZA- salauskorttien jakamisesta ja sertifikaattien myöntämisestä CA- alivarmentajille sekä niiden valvonnasta. Fyysisen FORTEZZA- salauskortin olemassaolo vähentää vihamielisen CA:n liittämistä PKI- järjestelmään. PCA antaa jokaiselle CA:lle 20 bittisen ainutkertaisen tunnisteen. Tunniste on osa ainutkertaista KMID- tunnistetta (Key Material Identifier) mikä annetaan jokaiselle julkiselle/ salaiselle – avainparille. PCA on vastuussa CLR- ja CKL- listasta (Compromised Key List). Jälkimmäinen lista sisältää KMID- tunnisteen assosioituna jokaiseen vaarantuneeseen yksityisavaimeen järjestelmässä. Jokainen CA ilmoittaa ylemmäntason PCA:lle vaarantuneista yksityisavaimista ja kaikki PCA:t ilmoittavat toisille PCA:lle. CKL- lista julkaistaan julkisessa x.500 hakemistojärjestelmässä.

34 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 34 CA- Asiakasvarmentaja CA- asiakasvarmentaja on vastuussa sertifikaattien myöntämisestä ja täytäntöönpanon valvonnasta omassa reviirissään. CA on vastuussa FORTEZZA- salauskorttien jakamisesta ja sertifikaattien myöntämisestä asiakkaille sekä niiden valvonnasta. Fyysisen FORTEZZA- salauskortin olemassaolo vähentää vihamielisen asiakkaan liittämistä PKI- järjestelmään. CA ei myönnä kahta sertifikaattia eri käyttäjille samalla x.500- nimellä. CA antaa jokaiselle asiakkaalle 20 bittisen ainutkertaisen tunnisteen. Tunniste on osa ainutkertaista KMID- tunnistetta (Key Material Identifier) mikä annetaan jokaiselle julkiselle/ salaiselle – avainparille. CA on vastuussa käyttäjien hallinnasta ja FORTEZZA- salauskorttien päivittämisestä ennen sertifikaattien umpeutumisaikaa. CA hallinnoi myös CLR- listaa. Sertifikaatit ja CLR- listat julkaistaan julkisessa x.500 hakemistojärjestelmässä. CA ilmoittaa PCA:lle vaarantuneista yksityisavaimista CLK- listalla.

35 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 35 DMS- Käyttäjät DMS- sisältää kahden tyyppisiä käyttäjiä; yksilökohtaisia ja järjestöllisiä Järjestölliset käyttäjät kuuluvat organisaation ja voivat käyttää hyväksi organisaation palveluita

36 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 36 DMSv1.0- Sertifikaatti DMSv1.0- sertifikaatti pohjautuu X.509v1- tietorakenteeseen. Tietorakenteen Subject's Public Key Info- kenttä sisältää DMSv1.0- sertifikaatin. DMS- sertifikaatti kostuu KEA-, KMMID- ja DSA- otsikoista sekä julkisista avaimista.

37 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 37 Certificate Managenent Sertifikaatteja hallitaan CAW- ohjelmistolla (Certification Authority Workstation): Sertifikaattien luonti ja hallinta (PAA, PCA, CA) CLR- ja CKL- listojen ylläpito ja julkaisu FORTEZZA- salauskorttien ohjelmointi CAW- ohjelmistolla on kolme eri roolia: Sertifikaattien myöntäminen (Certificate Issuer/ CAW Operator) Hallinnointi (CAW Administrator) Tietoturvapäällikkö (CAW Site Security Officer) Yhdellä vastuuhenkilöllä ei voi olla kuin kaksi samanaikaista roolia CA tallentaa FORTEZZA- salauskorttiin henkilösertifikaatin lisäksi sertifikaattipolun (PAA->PCA->CA). Korttiin tallennetaan myös henkilön julkisenavaimenavainparit (julkinen/ yksityinen). CA toimittaa henkilölle PIN- koodin jolla käyttäjä aktivoi salauskortilla olevat salausfunktiot ja lähettää henkilösertifikaatin X.500- hakemistojärjestelmään. DMSv1.0 ei sisällä mitään hallintaprotokollia. Kaikki tapahtumat suoritetaan verkon ulkopuolella.

38 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 38 Successes and Shortcomings Onnistumiset: Hierarkkinen PKI- arkkitehtuuri Rautapohjainen PAA-, PCA- ja CA- yksityisavaimien tallennus FORTEZZA- salauskortille Puutteet Harvassa tietokoneessa valmiina PCMCIA- korttipaikka. Nämä maksavat usein enemmän kuin FORTEZZA- salauskortti. Lisäksi tarvitaan omat laiteajurit PCMCIA- korttipaikalle. Huonosti suunniteltu käyttöliittymä CAW- ohjelmistossa. Virheen tapahtuessa joudutaan FORTEZZA- salauskortti kirjoittamaan uudelleen mikä puolestaan kasvattaa CLR- listan kokoa. Jokainen CAW- laitteisto/ ohjelmisto vaati kaksi käyttäjää. Yhdysvaltojen armeija tilasi 400 laitetta joiden käyttöön jouduttiin varamaan 800 henkilöä. Nämä henkilöt jouduttiin myös kouluttamaan CAW- ohjelmiston käyttöön. DMS- sertifikaatit sisältävät valtuutusinformaation. Sertifikaatin myöntäjä ei tiedä jokaisen henkilön oikeuksia/ valtuutuksia. CKL- listan yksilöllisen rakenteen takia kaupallisia ohjelmia ei voitu käyttää asiakasohjelmistoissa.

39 Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 39 Lähteet R. Housley, "Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure," John Wiley & Sons Inc., 2001. W. Stallings, "Network Security Essentials: Applications and Standards," Prentice-Hall Inc., 2000. E. Kerttula, "Tietoverkkojen Tietoturva," Liikenneministeriö, Oy Edita Ab, 1999. SPYRUS Pty. Limited, "FORTEZZA® Crypto Card," Lokakuu 20, 2003; http://www.spyrus.com.au/content/products/rosetta/Hardware_Security_Modules.asp#FORTEZZA


Lataa ppt "Teemu Alapaholuoma Tampereen Teknillinen Yliopisto, Porin Yksikkö PKI- Seminaari 22.10.2004 1 Planning for PKI: Best Practices Guide for Deploying Public."

Samankaltaiset esitykset


Iklan oleh Google