PKI

1. PKI

2. Firma digitale ed elettronica • La firma digitale esprime un atto volontario di sottoscrizione e, sotto il profilo tecnico organizzativo, deve essere basata su un certificato qualificato (quindi rilasciato da una trusted part detta Certification Authority che, per quanto previsto dalla vigente legislazione nazionale deve essere iscritta nell’elenco pubblico dei certificatori) e creata mediante un dispositivo di firma sicuro (in genere una smart card). • La direttiva europea e la nascita del commercio elettronico, hanno introdotto altri tipi di firma applicabili in contesti diversi da quello di un documento, come per esempio quello dei messaggi di posta elettronica: in questo caso si parla di firma elettronica.

3. Rete di Fiducia Validità della firma: • Esiste una rete di fiducia (meccanismo utilizzato in PGP) • Vi è una infrastruttura gerarchica di certificazione, o Public Key Infrastructure (PKI) Il primo approccio prevede che ogni utente si preoccupi di notificare la propria chiave pubblica alle persone con le quali ha necessità di scambiare informazioni in modo sicuro. Lo scopo della PKI è invece quello creare e mantenere un ambiente affidabile per la diffusione delle chiavi pubbliche, così da legare in modo sicuro la chiave pubblica con il possessore, con la caratteristica fondamentale della trasparenza rispetto all’utente.

4. PKI-principi • L’idea di fondo è che nulla impedisce che un certificato possa a sua volta essere firmato. • È necessario, innanzi tutto, un soggetto che si occupi della pubblicazione dei certificati: è evidente che questo soggetto debba essere una terza parte. • Non è proponibile l’idea di delegare all’ente preposto alla pubblicazione dei certificati il compito di identificare il soggetto (dovrebbe avere una presenza capillare che non giustificherebbe i costi di gestione)

6. Componenti di una PKI • End Users • Certification Authorities • Registration Authorities • Certificate Directories • Root CA(s) • Certification Practice Statements (CPS) • Certificate Management Protocols & APIs • Personal Security Environments (PSE)

7. Componenti • certificati: in cui si attesti che l’utente è effettivamente il possessore di quella chiave pubblica • Una Autorità di Certificazione (CA Certification Autority) che attesta questa affermazione. • L’uso di una CA evita ad ogni utente di verificare direttamente la correttezza delle chiavi pubbliche degli altri utenti con cui interagisce. • La CA è la terza parte fidata del modello generale per la sicurezza di rete.

8. Divisione dei compiti Ci si orienta verso una divisione dei compiti: • Chi verifica l’identità del soggetto (la Registration Authority o RA), con una struttura che possa anche fornire una capillare assistenza agli utenti • Chi emette e pubblica il certificato (la Certification Authority o CA), che è sostanzialmente un’entità centralizzata che deve invece garantire standard tecnici e di sicurezza di massima qualità

9. Requisiti di una CA • il garantire la massima disponibilità delle informazioni: il sistema deve essere quanto più possibile fault-tolerant; • il garantire la massima sicurezza: nessuno deve accedere a risorse cui non è autorizzato ad accedere (questo punto e il precedente sono inglobati nel piano di sicurezza della CA); • la necessità di formulare una politica di certificazione, ossia un insieme di regole che indichino il campo di applicabilità di ogni certificato (non tutti i certificati vengono rilasciati per tutti gli scopi); • l’obbligo di pubblicare un corretto ed esaustivo manuale operativo, che descriva esattamente tutte le procedure relative alla gestione dei certificati stessi; • Una CA deve garantire la massima interoperabilità con tutti i possibili client, il che implica automaticamente che la CA deve essere sempre costantemente aggiornata sulle ultime tecnologie in fatto di certificazione. Tale struttura è molto più orientata, per motivi di sicurezza, al concetto di centralità rispetto che a quello di capillarità.

10. Una CA è realmente quello che sostiene di essere !!! La procedura di certificazione è iterabile. • CA può essere certificata o da un organismo pubblico preposto a questo compito (che sarà a sua volta una CA) o da un’altra CA di livello superiore che sia legalmente abilitata a certificare la CA in questione • Pertanto, il certificato della CA (che dovrà essere reso pubblico) risulta a sua volta firmato da un’altra CA. • A monte di tutto ciò ci sarà una CA che non sarà certificata da nessun’altra: tale CA, che sarà ovviamente la CA pubblica per eccellenza, disporrà di un certificato “self-signed”.

11. Root CA CA CA CA CA

12. CA radice • In Italia tale ruolo è ricoperto dall’Autorità per l’Informatica nella Pubblica Amministrazione (AIPA). • Il certificato a monte di ogni catena di certificazione prende il nome di certificato radice (root certificate) e, analogamente, la CA a monte di ogni catena prende il nome di CA radice (o root CA);

13. Operazioni basilari sui certificati • registrazione: è il processo preliminare mediante il quale un soggetto si notifica presso una RA (o, dove non prevista, direttamente presso la CA); • inizializzazione: è il momento in cui l’utente o il client ottengono i valori necessari per iniziare le comunicazioni con l’infrastruttura PKI (generalmente mediante uno scambio Diffie-Hellman[1]); • certificazione: è il processo mediante il quale la CA rilascia un certificato per la chiave pubblica del soggetto; • aggiornamento: è così definita l’obbligatoria generazione di una nuova coppia di chiavi una volta scaduta la precedente (ogni certificato ha, infatti, un proprio periodo di validità);

14. Operazioni basilari sui certificati • verifica di un certificato: l’operazione mediante la quale chi riceve il certificato verifica la firma digitale appostavi dall’ente certificatore, realizzata recuperando il certificato del certificatore e verificandolo a sua volta, fino a giungere alla root CA (che, come già detto, ha il certificato preinstallato in macchina). Si noti che, per motivi di efficienza, talvolta si usa allegare in una firma digitale non solo il certificato utente, ma anche quello della CA che lo ha firmato… • revoca di un certificato: l’operazione mediante la quale un certificato viene annullato, o per scadenza o perché venuti a mancare i presupposti per la sua validità (manomissione, cambio di identità giuridica del soggetto, ecc.).

15. Revoca Dovendo la CA garantire la verificabilità delle firme antecedenti la revoca anche in tempi successivi alla revoca stessa. La CA dovrà suddividere i certificati in due liste: • quella dei certificati attivi • quella dei certificati revocati (la Certificate Revocation List o CRL).

16. CA certificate Certificate Repository (X.500, DNS, etc.) certificate name, public-key certificate query signed message Interazione

17. Protocolli

18. Revoca Chi deve essere autorizzato a richiedere la revoca di un certificato: • per i privati cittadini: • è il titolare stesso del certificato che detiene la facoltà di richiederne la revoca • eventualmente l’anagrafe, in caso di decesso • Nel caso di società: ????? Ci sarà un ritardo tra la decisione di revoca e l’effettiva verificabilità della operazione stessa !!!!!! E’ questo uno dei problemi ancora irrisolti della Firma digitale.

19. Certificate Verification • To verify a certificate: • You need the issuer’s certificate and CRL: Name: Anish Bhimani Issuer: SAIC Serial: 0x0AF Key: a4653d73b95483jh Issuer’s Signature: F54673HGMABS8496FH3J Name: SAIC Issuer: California Dept. of Commerce CA Serial: 0x016a7f Key: b47326fh482faiwn83j523 Issuer’s Signature: F63GHDJ28F7CHL238CXN3DJ Name: SAIC Issuer’s Signature: F63GHDJ28F7CHL238CXN3DJ Revoked Certs: 0x0A3 (2/7/97), 0x087, (11/2/96)

20. Protocolli • LDAP: certificate retrieval • PKCS #10: certification requests • S/MIME CRS: certification request syntax • Cisco CMS: Certificate Management Syntax • IETF CMP: Certificate Management Protocol (Entrust-based)

21. Lo standard Lo standard per i certificati attualmente utilizzato è l’ITU-T X.509 versione 3. Esso definisce le informazioni di base che devono essere contenute in un certificato ed un regola di codifica con cui trasformare questo oggetto in una sequenza di byte da trasmettere in rete

22. Certificato X.509 Certificate ::= SIGNED { SEQUENCE { version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONALV2, subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONALV2, extensions [3] Extensions OPTIONALV3} NOTA: V2 = da versione 2 in poi, V3 = da versione 3 in poi

24. Semplice certificato

25. Definizione dei campi • Certificate Serial Number: identificatore univoco (tra tutti quelli emessi dalla CA) del certificato. • Validity Period: coppia di date che determina la validità del certificato (data di inizio e di fine). • Subject: l’intestatario del certificato e le informazioni ad esso relative (ad esempio per un utente umano potrebbero essere nome, cognome, indirizzo, data di nascita, ecc., per un utente server Web l’indirizzo IP).

26. Definizione dei campi • Subject Public Key Information: è l’informazione vera e propria che viene certificata. Questa informazione comprende la chiave pubblica dell’utente e l’algoritmo a cui essa è applicabile. • Issuer: nome della CA che ha emesso il certificato. • CA’s Digital Signature: la firma digitale dell’intero certificato. Questa è calcolata su tutti gli altri campi del certificato.

27. Definizione dei campi • extension, novità introdotta nella v3 di X.509, contiene le possibili estensioni del certificato, che, data la loro importanza, meritano un approfondimento a parte. Le estensioni sono così definite: Extension ::= SEQUENCE { extnId EXTENSION.&id ({ExtensionSet}), critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING }

28. Estensioni Le estensioni sono campi aggiuntivi al certificato non sempre previsti dallo standard. Non vengono inserite in un ordine specifico e quindi, dispongono di un identificatore che consenta, in caso di estensione non nota al programma che riceve il certificato, di ignorarla e passare oltre. Fondamentale, in questo caso, diventa però il flag critical: con tale flag settato l’intero certificato dovrà essere considerato non valido se l’applicazione non è in grado di gestire l’estensione in questione (cosa che non avverrebbe, invece, col flag impostato a false).

29. Classi di estensioni • key and policy information extensions, che contengono informazioni sullo scopo per il quale la chiave o il certificato possono essere usati

30. subject and issuer information extensions, che consentono di definire nomi alternativi (alias) per subject e issuer del certificato, oltre ad alcuni attributi aggiuntivi; • certification path constraints extensions, che contengono informazioni sul percorso di certificazione del certificato stesso e, in particolare, se il titolare del certificato è una CA • in quest’ultimo caso, possono essere specificati i vincoli imposti a nome e policy dei certificati rilasciati (ad esempio si può stabilire che il subject di tutti i certificati rilasciati da ABC cominci con “ABC Certificate no. ”).

31. CRL X.509 definisce anche tutta una serie di strutture accessorie ai certificati. Tra queste vanno citate: • la CRL (Certificate Revocation List – o, più precisamente, la Certificate List, di cui la CRL è una specializzazione –È una lista di numeri di serie di certificati e delle relative date di revoca), • l’AttributeCertificate (la cui definizione ricorda quella di un certificato normale, ma il cui corpo è costituito da una lista di attributi il cui funzionamento ricalca quello delle estensioni, delle quali il certificato di attributo è comunque corredato).

32. La PKI stabilisce anche molti altri aspetti, tra i quali è fondamentale la revoca dei certificati (quando un certificato viene invalidato prima della sua data di scadenza, bisogna stabilire dei meccanismi con cui avvertire tutti quelli che potrebbero riceverlo ed erroneamente assumerlo come valido).

33. Certificati per l’autorizzazione In tal caso il certificato viene indicato come Privilege Attribute Certificate (PAC), e le differenze dal certificato X.509v3 standard sono: • Subject: questo campo indica l’utente che sta ricoprendo il ruolo rappresentato dal PAC. Esso quindi memorizza un riferimento al certificato dell’utente. • Attributes List: insieme di coppie attributo – valore, che rappresentano le credenziali/privilegi che il ruolo è autorizzato a ricoprire.