Public Key Infrastructure

38
Public Key Infrastructure Francesco Meschia

Transcript of Public Key Infrastructure

Page 1: Public Key Infrastructure

Public Key Infrastructure

Francesco Meschia

Page 2: Public Key Infrastructure

Crittografia asimmetrica

• la crittografia asimmetrica mette a disposizione tecniche per ottenere in sicurezza due importanti risultati:– cifratura “end-to-end”– firma elettronica

• un po’ di terminologia:– crittografia: κρύπτος γράφειν, “scrittura nascosta”– in italiano si usano, mutuati dal gergo militare, i

termini “cifrario”, “messaggio cifrato”, “cifrare”, ecc.• non “crittografare”, “crittare”, ecc.

Page 3: Public Key Infrastructure

Crittografia end-to-end

• ottengo la chiave pubblica di una persona

• cifro il messaggio usando la chiave pubblica

• solo la chiave privata corrispondente potrà rivelare il testo in chiaro

• anche se il messaggio viene intercettato, il suo contenuto è protetto

Page 4: Public Key Infrastructure

Firma elettronica

• prendo un messaggio e lo cifro usando la mia chiave privata

• chi riceve questo messaggio tenta di decifrarlo usando la mia chiave pubblica

• se riesce a ottenere il testo in chiaro, significa che sono stato io a cifrare il messaggio, e che non è stato modificato

Page 5: Public Key Infrastructure

Necessità della pubblicità della chiave

• i due meccanismi funzionano se alla chiave pubblica è assicurata adeguata “pubblicità”– deve essere facilmente reperibile la chiave

pubblica di una persona

Page 6: Public Key Infrastructure

Insidie della pubblicità della chiave

• se posso essere indotto a usare la chiave pubblica sbagliata, la sicurezza del messaggio è compromessa– invio informazioni che credo riservate alla persona

sbagliata– oppure posso essere indotto a credere a

informazioni “firmate” da una fonte fraudolenta– il tutto senza che vi sia nessun attacco

crittoanalitico!

Page 7: Public Key Infrastructure

Come garantire la chiave pubblica

• è necessario garantire la paternità della chiave pubblica

• in una comunicazione punto-punto, i due interessati possono per esempio scambiarsi fuori banda la convalida della chiave pubblica– confrontandone, ad esempio, la firma (hash)

• questo meccanismo ha un grosso difetto: non scala!

Page 8: Public Key Infrastructure

Come garantire la chiave pubblica

• occorre un sistema per la gestione delle chiavi pubbliche che non richieda lo scambio fuori banda– ma che mantenga un livello di sicurezza

accettabile

Page 9: Public Key Infrastructure

Come garantire la chiave pubblica

• lo scambio fuori banda è governato dal concetto di fiducia– mi fido (conosco) la persona che mi offre la

convalida della sua chiave, quindi posso stare tranquillo

• la società umana affronta da secoli i problemi del trasferimento di fiducia…

Page 10: Public Key Infrastructure

Come garantire la chiave pubblica

• se una persona di cui mi fido mi offre la convalida non della sua chiave, ma della chiave di una persona di cui lui si fida, posso a mia volta fidarmi?

• il programma crittografico PGP si basa su questo approccio, detto web of trust

Page 11: Public Key Infrastructure

La Public Key Infrastructure

• la Public Key Infrastructure (PKI) propone un approccio differente

• la convalida delle chiavi non è più basata sulla conoscenza diretta e sul trasferimento di fiducia tra la persone

• la chiave pubblica è “inglobata” in un documento detto certificato

Page 12: Public Key Infrastructure

Certificati a chiave pubblica

• il certificato associa tre entità:– una chiave pubblica– un soggetto (individuo, sito web, azienda)– una terza parte che si fa garante della

associazione

• “garantisco che questa chiave pubblica è associata a questa persona”

Page 13: Public Key Infrastructure

Certificati e certificatori

• come posso fidarmi di quello che il certificato dice?

• il certificato contiene una firma che attribuisce alla terza parte (il certificatore, o CA - certification authority) la responsabilità dell’associazione

Page 14: Public Key Infrastructure

Certificatori

• ma la firma è a sua volta crittografica

• se non sto attento, posso essere indotto a prendere per buone certificazioni emesse da una parte fraudolenta

• avrei bisogno di un certificato del certificatore

Page 15: Public Key Infrastructure

Catena di certificazione

• il certificato del certificatore sarà a sua volta garantito (emesso) da un altro certificatore– e così via in una gerarchia ad albero

• la ricorsione si ferma giungendo a una, o poche, radici di certificazione riconosciute da un grandissimo numero di soggetti (in linea di principio, da chiunque!)

Page 16: Public Key Infrastructure

Il lavoro del certificatore

• i certificatori sono soggetti di mercato che offrono il servizio di garanzia della attribuzione delle chiavi pubbliche

• il certificatore deve mettere a disposizione diversi servizi, tra cui:– un sistema di procedure (in capo a una o più

registration authority) per la verifica dell’identità del soggetto a cui viene attribuita la chiave pubblica

– l’elenco delle chiavi pubbliche certificate– l’elenco delle certificazioni revocate– l’elenco delle certificazioni sospese

Page 17: Public Key Infrastructure

Il valore della certificazione

• il valore della certificazione dipende dallo scopo per cui è emessa– e in certa misura anche le procedure

• un certificato che garantisce l’identità di un sito web deve permettere di ricondurre un sito alla responsabilità di una impresa

• un certificato che garantisce l’identità di una persona deve prevedere un processo di riconoscimento legale della persona fisica

Page 18: Public Key Infrastructure

Lo standard X.509

• lo standard ITU per la public key infrastructure è noto come X.509

• lo standard X.509 è alla base praticamente di tutta l’infrastruttura a chiave pubblica di Internet– significativamente, SSL - su cui si basa

HTTPS

Page 19: Public Key Infrastructure

Il certificato X.509

• deve contenere:– un numero di serie– l’identificativo del certificatore– una indicazione di limiti di validità

temporale– il soggetto sotto forma di DN X.500– una firma elettronica crittografica– l’indicazione dell’algoritmo di firma

Page 20: Public Key Infrastructure

Esempio di certificato X.509Certificate: Data: Version: 3 (0x2) Serial Number: 1247230273 (0x4a573941) Signature Algorithm: sha1WithRSAEncryption Issuer: C=IT, O=Postecom S.p.A., OU=Servizi Certification Authority, CN=Postecom CS2 Validity Not Before: Jul 10 12:51:13 2009 GMT Not After : Jul 10 12:51:13 2010 GMT Subject: C=IT, O=Citta' di Torino, OU=Settore Servizi Telematici, CN=servizi.torinofacile.it Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:e5:20:f5:82:ef:56:f8:66:12:9d:a4:ca:98:5d: ... Exponent: 65537 (0x10001)Signature Algorithm: sha1WithRSAEncryption 6d:8c:41:6d:3a:72:05:eb:21:c4:0e:3e:f5:e7:cf:bc:12:c6: ...

Page 21: Public Key Infrastructure

Esempio di certificato X.509

• questo certificato ci dice che:– esiste un soggetto (sito web, in questo contesto)

denominato “servizi.torinofacile.it” che appartiene a una organizzazione denominata “Città di Torino”

– questa certificazione di appartenenza è attestata crittograficamente come garantita da una organizzazione denominata “Postecom S.p.A.”

Page 22: Public Key Infrastructure

Esempio di certificato X.509 - CA

Certificate: Data: Version: 3 (0x2) Serial Number: 67109836 (0x40003cc) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root Validity Not Before: Feb 16 19:16:00 2005 GMT Not After : Feb 16 23:59:00 2012 GMT Subject: C=IT, O=Postecom S.p.A., OU=Servizi Certification Authority, CN=Postecom CS2 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:a9:b4:ac:56:bc:f7:21:3c:4e:f0:45:cd:ad:5b: ... Exponent: 65537 (0x10001) X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 Signature Algorithm: sha1WithRSAEncryption 81:34:09:25:55:d3:40:15:41:2a:d2:12:52:ae:2d:97:d3:97: ...

Page 23: Public Key Infrastructure

Esempio di certificato X.509 - CA

• questo certificato ci dice che:– identifica come CA (perché c’è una

opportuna “critical extension”) un soggetto denominato “Postecom S.p.A.”

– la certificazione è a sua volta firmata da un soggetto chiamato “GTE CyberTrust”

Page 24: Public Key Infrastructure

Esempio di certificato X.509 - root CA

Certificate: Data: Version: 1 (0x0) Serial Number: 421 (0x1a5) Signature Algorithm: md5WithRSAEncryption Issuer: C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root Validity Not Before: Aug 13 00:29:00 1998 GMT Not After : Aug 13 23:59:00 2018 GMT Subject: C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:95:0f:a0:b6:f0:50:9c:e8:7a:c7:88:cd:dd:17: ...

Exponent: 65537 (0x10001) Signature Algorithm: md5WithRSAEncryption 6d:eb:1b:09:e9:5e:d9:51:db:67:22:61:a4:2a:3c:48:77:e3: ...

Page 25: Public Key Infrastructure

Esempio di certificato X.509 - root CA

• questo certificato ci dice che:– c’è un soggetto denominato “GTE

CyberTrust” che si certifica da solo come CA (certificato self-signed)

– questo è detto un certificato radice (root), in quanto termina la catena di certificazione

Page 26: Public Key Infrastructure

La radice di certificazione

• come faccio a sapere che questo certificato radice è affidabile?– un malintenzionato potrebbe firmarsi da solo un

certificato fatto esattamente in questo stesso modo, come lo distinguo?

• è necessario un bootstrap della catena di certificazione, che deve essere inserito “fuori banda”– non importa che non scali bene, purché il numero

di radici non sia troppo grande

Page 27: Public Key Infrastructure

Chi pianta le radici?

• Dipende dal contesto

• per i browser: Microsoft, Mozilla, Google… chiunque fa un browser considera come attendibili le root CA di mercato più diffuse (GTE, Verisign, RSA, ecc.)

Page 28: Public Key Infrastructure

Root CA per SSL

• Queste sono le root CA di Internet Explorer– un certificato

emesso da una di queste viene riconosciuto subito

– l’utente può aggiungere root CA di cui sceglie di fidarsi

QuickTime™ e undecompressore

sono necessari per visualizzare quest'immagine.

Page 29: Public Key Infrastructure

CA per firma digitale

• La firma digitale fu introdotta nell’ordinamento italiano nel 1997, e ora risulta normata dal D.Lgs. 82/2005 “Codice dell’Amministrazione Digitale”

• “Il documento informatico, sottoscritto con firma digitale o con un altro tipo di firma elettronica qualificata, ha l'efficacia prevista dall'articolo 2702 del codice civile. L'utilizzo del dispositivo di firma si presume riconducibile al titolare, salvo che questi dia prova contraria”

Page 30: Public Key Infrastructure

Firma digitale

• Lo stato delle norme prevedono diversi tipi di “firma”:– firma elettronica: insieme di dati in forma elettronica

utilizzati come strumento di identificazione del sottoscrittore

– firma elettronica qualificata: firma elettronica con• una procedura che garantisca l’univoca associazione al

firmatario• uno strumento su cui il firmatario mantenga il controllo

esclusivo, e dotato di certificato qualificato (creato sotto certe prescrizioni)

– firma digitale: firma elettronica qualificata basata su crittografia asimmetrica

Page 31: Public Key Infrastructure

Certificatori “di firma digitale”

• i certificatori qualificati sono sottoposti all’attività di vigilanza del Centro Nazionale per l’Informatica nella Pubblica Amministrazione (CNIPA)

• il CNIPA raccoglie e pubblica l’elenco dei certificatori attivi e delle chiavi pubbliche delle loro CA– ad oggi esistono 17 certificatori attivi– non esiste una root CA comune

Page 32: Public Key Infrastructure

CA di firma digitale

QuickTime™ e undecompressore

sono necessari per visualizzare quest'immagine.

http://www.cnipa.gov.it/site/it-IT/Attivit%C3%A0/Firma_digitale/

Page 33: Public Key Infrastructure

CA per strumenti di autenticazione legali

• Secondo il D.Lgs. 82/2005, Carta di Identità Elettronica e Carta Nazionale dei Servizi “costituiscono strumenti per l'accesso ai servizi erogati in rete dalle pubbliche amministrazioni per i quali sia necessaria l'autenticazione informatica”

Page 34: Public Key Infrastructure

CA della CIE

• il Ministero dell’Interno esercisce numerose CA per la CIE– almeno 6 nel 2008

• il Ministero chiama queste CA “sub-CA”, ma in realtà sono tutte root con certificati self-signed– non esiste una vera gerarchia con una root

e subCA

Page 35: Public Key Infrastructure

CA della CIECertificate: Data: Version: 3 (0x2) Serial Number: 980849447 (0x3a769327) Signature Algorithm: sha1WithRSAEncryption Issuer: C=IT, O=MINISTERO DELL'INTERNO, OU=CIE, OU=SERVIZI TECNICI, CN=SUBCA-EMISSIONE2-MI Validity Not Before: Jan 30 10:18:37 2001 GMT Not After : Jan 30 10:18:35 2011 GMT Subject: C=IT, O=MINISTERO DELL'INTERNO, OU=CIE, OU=SERVIZI TECNICI, CN=SUBCA-EMISSIONE2-MI Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:d2:2a:70:1e:9c:9b:6e:d2:c1:9f:9d:2d:d0:29: ... Exponent: 65537 (0x10001) Signature Algorithm: sha1WithRSAEncryption 13:b0:d7:f9:a4:c2:01:a1:c1:e6:10:0c:4d:37:4d:0b:99:10: ...

Page 36: Public Key Infrastructure

CA della CIE

• i certificati della CIE risultano emessi da queste CA

• la pubblicazione dei certificati delle root CA non è tempestiva

• le pubbliche amministrazioni sono nell’impossibilità di garantire l’accesso con “qualunque CIE”

Page 37: Public Key Infrastructure

CA della CNS

• In base alle leggi e ai regolamenti istitutivi della CNS (DPR 445/2000, D.Lgs. 10/2002, DPR 137/2003), ogni pubblica amministrazione che lo desidera può emettere CNS

• la norma detta che i certificatori della CNS debbano essere i certificatori di firma digitale

• la norma non però fissa la corrispondenza tra l’amministrazione emittente e la CA emittente– come risultato, si è creata una situazione mista

Page 38: Public Key Infrastructure

CA della CNS

• alcuni certificatori hanno usato la loro root CA per emettere i certificati

• altri hanno creato sub-CA intestate agli Enti ma PKI-dipendenti dalla loro root

• altri infine hanno creato root CA intestate agli enti senza PKI-dipendenza dalla loro root

• esiste una norma disattesa che richiede al DIT la pubblicazione delle chiavi pubbliche delle CA emittenti CNS– di conseguenza non è possibile essere sicuri di

accettare tutte le CNS come prescrive la norma