Il documento discute l'infrastruttura a chiave pubblica (PKI) e la crittografia asimmetrica, enfatizzando l'importanza della pubblicità delle chiavi pubbliche e dei certificati. Descrive i certificati X.509 e il ruolo delle autorità di certificazione (CA) nell'associare chiavi pubbliche a soggetti verificati. Viene inoltre affrontata la questione della fiducia e della verifica delle chiavi e dei certificati in un contesto di sicurezza digitale.

1. Public Key Infrastructure
Francesco Meschia

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

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

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

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

6. 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!

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

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

9. 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…

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

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

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

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

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

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

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

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

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

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

20. Esempio di certificato X.509
Certificate:
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:
...

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

22. Esempio di certificato X.509 -
Certificate:
CA
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:
...

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

24. Esempio di certificato X.509 -
Certificate:
root CA
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:
...

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

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

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

28. Root CA per SSL
• Queste sono le
root CA di Internet
Explorer
– un certificato
emesso da una di QuickTime™ e un
decompressore
queste viene sono necessari per visualizzare quest'immagine.
riconosciuto subito
– l’utente può
aggiungere root CA
di cui sceglie di
fidarsi

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

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

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

32. CA di firma digitale
http://www.cnipa.gov.it/site/it-IT/Attivit%C3%A0/Firma_digitale/
QuickTime™ e un
decompressore
sono necessari per visualizzare quest'immagine.

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

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

35. CA della CIE
Certificate:
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:
...

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

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

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