Public Key Infrastructure

Francesco Meschia

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.

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

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

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

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!

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!

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

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…

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

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

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”

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

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

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!)

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

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

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

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

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: ...

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.”

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: ...

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”

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: ...

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

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

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.)

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.

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”

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

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

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/

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”

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

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: ...

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”

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

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