Autenticazione ed uso dei certificati: realizzazione di una semplice certification Authority Luca...
-
Upload
zita-gualtieri -
Category
Documents
-
view
229 -
download
0
Transcript of Autenticazione ed uso dei certificati: realizzazione di una semplice certification Authority Luca...
Autenticazione ed uso dei certificati: realizzazione di una semplice
certification Authority
Luca BechelliSecurity Consultanthttp://web.tiscalinet.it/[email protected]
“La crittografia a chiave pubblica nacque nel maggio del 1975, come conseguenza di due problemi…il problema della distribuzione delle chiavi e quello delle firme elettroniche…La scoperta non consisteva in una soluzione, ma nel capire che i due problemi, ognuno dei quali sembrava irresolubile per definizione, poteva essere risolto e che la soluzione di entrambi scaturiva da un solo metodo”.
Whitfield Diffie
Crittografia Simmetrica e Crittografia Simmetrica e AsimmetricaAsimmetrica
• Cifratura Simmetrica: utilizza una chiave per cifrare-decifrare oppure diverse chiavi derivate l’una dall’altra o da una “master secret”
• Cifratura Asimmetrica: utilizza due chiavi, una per cifrare e l’altra per decifrare, legate entrambe da una funzione matematica. Una di esse è pubblica e l’altra è privata. Il cifrario asimmetrico è detto anche “a chiave pubblica”.
Autenticazione e scambio delle Autenticazione e scambio delle chiavichiavi
• I cifrari simmetrici non risolvono il dilemma dello scambio delle chiavi
• I cifrari simmetrici non permettono l’attestazione dell’identità in un ambiente “aperto” come la rete, verso diversi soggetti/entità:
• Per condividere dei dati cifrati con un’altra entità, in rete, è necessario accordare/scambiare assieme la chiave di cifratura/decifratura
• Nel caso di autenticazione verso un sistema, è necessaria una operazione di registrazione che può comportare il doversi recare fisicamente presso l’addetto alla registrazione
I cifrari a chiave pubblicaI cifrari a chiave pubblica
• Sono cifrari che utilizzano 2 chiavi diverse, una pubblica e l’altra privata, “costruite” in modo tale che se con una si effettua la cifratura di un documento, con l’altra (e soltanto con quella) è possibile effettuare la decifratura
• Basano la loro sicurezza su funzioni matematiche che ammettono l’inversa, ma il cui calcolo è computazionalmente troppo costoso, se non si conoscono alcuni parametri (che costituiscono la chiave)
• La conoscenza della chiave pubblica non permette di ricavare la privata
Cifrari a chiave pubblicaCifrari a chiave pubblica
• La teoria dei sistemi a chiave pubblica è stata sviluppata da Whitfield Diffie, Martin Hellman e Merkle. Loro intuirono che il sistema a due chiavi avrebbe risolto il problema della distribuzione delle chiavi. In più, Diffie e Hellman svilupparono un algoritmo per la distribuzione delle chiavi e per la condivisione di segreti che deve il nome ai due ricercatori (Diffie-Hellman).
Il cifrario RSAIl cifrario RSA
• Ron Rivest, Adi Shamir e Leonard Adleman, nel 1977 idearono l’algoritmo RSA sulla base della teoria Diffie-Hellman-Merkle
• RSA è stata la prima funzione matematica sottoposta a brevetto
• Alice possiede 2 chiavi, una pubblica e l’altra privata. Lei distribuisce la pubblica su internet. Chiunque può inviarle un messaggio cifrandolo con la chiave pubblica, e solo Alice potrà decifrarlo poiché è l’unica a possedere la chiave privata.
Il cifrario RSAIl cifrario RSA• RSA basa la sua sicurezza sul fatto che non esiste un
algoritmo di scomposizione di un numero in fattori primi efficiente dal punto di vista del tempo di elaborazione (costo computazionale).
• In particolare, il rapporto tra lunghezza della chiave e tempo necessario per “forzare” l’algoritmo è tale da rendere l’operazione infattibile o troppo costosa per essere effettuata in un tempo utile.
• RSA è utilizzato con chiavi a 512, 1024 e 2048 bit. Per chiavi maggiori o uguali a 1024 bit, attualmente, non sarebbe sufficiente un tempo superiore a quello della vita dell’universo con un potente computer per ricavare la chiave privata
RSARSA
• Le chiavi RSA devono essere generate contemporaneamente, a partire da un numero primo sufficientemente elevato e ricavato mediante un generatore random
• Il costo di operazioni di cifratura e decifratura è tale da rendere inefficiente RSA per cifrare anche piccoli documenti informatici.
• La sua robustezza lo rende utile per costruire un “canale sicuro” per lo scambio delle chiavi
RSA e la comunicazione sicuraRSA e la comunicazione sicura
• Alice vuole spedire a Bob un messaggio cifrato:– Alice ricava da un elenco pubblico la chiave pubblica di
Bob– Genera una chiave (ad esempio) DES casuale e con quella
cifra il messaggio– Alice cifra la chiave DES con la chiave pubblica di Bob e
gli invia :• Testo cifrato + chiave DES cifrata con Kpub
– Bob decifra con la chiave privata la chiave DES e con questa decifra e legge il messaggio
– Con il medesimo sistema Bob può rispondere ad Alice– NB: la chiave DES è generata casualmente ogni
volta e mai più riutilizzata!!!!
Cifratura – decifratura messaggiCifratura – decifratura messaggi
hello
world
@!”£$%&/()==?)*è#@[]
@#[K”!£
hello
world
@!”£$%&/()==?)*è#@[]
@#[K”!£
Crittografia asimmetrica e Crittografia asimmetrica e autenticazioneautenticazione
• Per sapere se un documento è stato spedito effettivamente da Alice, lei lo può cifrare con la sua chiave privata: tutti coloro che conoscono (o ricavano da un elenco pubblico) la sua chiave pubblica possono decifrare il documento. Poiché la chiave privata è in possesso solo di Alice, tutti possono essere sicuri che soltanto Alice può aver spedito il documento.
• Problema (1): RSA è inefficiente per cifrare interi documenti
• Problema (2): non è possibile sapere se durante il transito il testo cifrato con la chiave privata è stato modificato
• Problema (3): chi gestisce l’elenco delle chiavi e la relazione identità-chiave?
Problema 1: le prestazioni Problema 1: le prestazioni
• Per aumentare le prestazioni Alice non cifra il vero e proprio documento, ma un hash (impronta) dello stesso.
• La funzione hash deve avere le seguenti proprietà:– Non deve generare collisioni– Applicata ad un documento in tempi diversi deve
restituire lo stesso risultato– Deve restituire un testo di dimensione fissa– Deve restituire un testo sufficientemente breve per
non incorrere in problemi di prestazioni di RSA
Problema 3: Legame persona Problema 3: Legame persona fisica-chiave pubblicafisica-chiave pubblica
• Per essere certi dell’identità del firmatario di un documento, non basta effettuare le verifiche di tipo crittografico, ma dobbiamo essere certi dell’identità del soggetto possessore della chiave pubblica che utilizziamo per la verifica
• Per questo motivo bisogna affidarci ad una terza parte che garantisca per l’identità fisica del possessore delle chiavi.
• 2 principali soluzioni adottate:– PGP (horizontal) trusting model– Public Key Infrastructure (hierarchical) trusting model
Certification AuthorityCertification Authority
• È una “terza parte” che garantisce per l’identità dell’utente• Deve essere riconosciuta come “fidata” da tutte le entità
coinvolte nella comunicazione• La garanzia dell’identità è comprovata da un “CERTIFICATO
DIGITALE” associato alla chiave, che contiene i dati identificativi dell’utente e della chiave pubblica, più una serie di campi opzionali
• Il certificato è fornito dalla CA tramite una “procedura di certificazione”
• La CA firma il certificato utente con il proprio certificato• E’ possibile costruire gerarchie di CA: in tal caso una CA
“root” genera e firma il certificato delle sub-CA. Il processo può essere ripetuto per un numero infinito di livelli.
Procedura di CertificazioneProcedura di Certificazione• Alice genera la sua coppia di chiavi• Raggiunge l’ufficio registrazione (Registration Authority) della
CA, si identifica e fornisce la sua chiave pubblica perché sia certificata
• La RA approva la richiesta di certificazione dopo opportune verifiche, dopodiché chiede alla CA di generare un certificato per Alice
• La CA ho un proprio certificato (root CA) self-signed con il quale firma il certificato generato per Alice
• Alice riceve per e-mail il proprio certificato firmato dalla CA, ed il certificato root della CA.
• Ogni volta che firmerà un documento, Alice allegherà il proprio certificato digitale oppure il numero seriale dello stesso.
• Il certificato di Alice è pubblicato dalla CA sul proprio “Certificate Server” accessibile tramite protocollo LDAP.
Procedura di IdentificazioneProcedura di Identificazione
• Effettuata dalla Registration Authority della Certification Authority
• Descritta nel Certificate Pratice Statement della CA
• Può essere di vari livelli: dal riconoscimento dell’e-mail all’accertamento dell’identità tramite copia di un documento di identità o presentazione fisica presso lo sportello della RA
• CA + “trusted” = procedura di identificazione + sicura
Struttura della PKIStruttura della PKI• Certification Authority : è l’Autorità che emette i
certificati e le liste di sospensione e revoca. Dispone di un certificato con il quale sono firmati tutti i certificati emessi agli utenti, e quindi deve essere installata su di una macchina sicura (off-line?)
• Registration Authority:presso questa autorità, gli utenti si rivolgono per richiedere la certificazione delle chiavi, identificandosi, e fornendo almeno la chiave pubblica e l’indirizzo e-mail
• Certificate Server : servizio di directory accessibile mediante un “operational protocol”, tipicamente LDAP, è essenzialmente una lista di pubblicazione dei certificati e delle liste di certificati revocati e sospesi
Certificati sospesi e revocatiCertificati sospesi e revocati• La CA si occupa di pubblicare periodicamente due
liste sul Certificate Server:– Certificate Revocation List (CRL)– Certificate Suspension List (CSL)
• CRL: Certificati definitivamente revocati (compromissione chiave privata, smarrimento ecc…) e non più riattivabili
• CSL: Certificati sospesi per un certo periodo di tempo. Al termine della sospensione possono essere riattivati, sospesi nuovamente o revocati
• Le CRL aderiscono al formato internazionale ITU-T X.509 secondo quanto descritto dallo standard PKIX “Certificate and CRL Profile” (www.ietf.org)
Il certificatoIl certificato• E’ un documento conforme allo standard ITU-T X.509 contenente :• Attributi:
– Distinguished Name: identificativo dell’utente suddiviso nelle voci:– Issuer Distinguished Name: nello stesso formato del DN, identifica la CA che
ha emesso il certificato– Validity (not after, not before) = periodo di validità del certificato– Serial Number : numero seriale del certificato– Public Key : la chiave pubblica dell’utente
• Estensioni– CRLDistributionPoint : URL del server LDAP da dove scaricare la CRL– KeyUsage: lo scopo di utilizzo della chiave (uno o più tra i seguenti):
• Digital Signature : firma digitale• Key Encipherment : “canale sicuro” per chiavi simmetriche• non repudiation : assieme a “Digital Signature per la firma per il non ripudio dei
documenti• Data Encipherment : cifratura dei dati• CRL e KeyCert Signature : firma di CRL e Certificati ( usato dalla CA)
Verifica della firmaVerifica della firma
• Bob, ricevuta una mail firmata da Alice, per verificarla deve:– eseguire le verifiche crittografiche precedentemente
descritte– estrarre il certificato di Alice, se presente, o scaricarlo
dal Certificate Server della CA– controllare che la chiave pubblica di alice corrisponda
con quella presente nel certificato– verificare che il certificato sia firmato da una CA ritenuta
fidata utilizzando un certificato CA acquisito in modo sicuro
– controllare che il certificato non sia scaduto– Scaricare la CRL e CSL e verificare che il certificato non
sia sospeso o revocato, effettuando un controllo con i numeri seriali dei certificati elencati
Verifica Verifica
abcdefghilmnopq...
..tuvz.
£$%&/()=?^ @#!£$%&/(^ @#!£$ @#!£$%&/()=?^§ @#!£/()=?^§/()$%&/()=?^$%&/()=?^()=?^()=?^(
£$%&/()=?^ @#!£$%&/(^ @#!£$ @#!£$%&/()=?^§ @#!£/()=?^§/()$%&/()=?^$%&/()=?^()=?^()=?^(
£$%&/()=?^ @#!£$%&/(^ @#!£$ @#!£$%&/()=?^§ @#!£/()=?^§/()$%&/()=?^$%&/()=?^()=?^()=?^(
HASH •Verifica Temporale
•Ricerca nella CRL
•Ricerca nella CSL
•Integrità
•Non Ripudio
•Autenticazione
LD
AP
La Certification Authority utilizzataLa Certification Authority utilizzata
• pyCA (www.pyca.de) è una CA basata sugli standard internazionali ITU-T X.500, IETF PKIX e RSA PKCSs
• È un software OpenSource, coperto da licenza GNU GPL (www.gnu.org/copyleft/gpl.html)
• Greetings to Michael Ströder ( the author)
pyCApyCA
• pyCA è una interfaccia scritta in python per semplificare l’utilizzo della libreria OpenSSL nelle operazioni inerenti le attività della CA, RA e Certificate Server
OpenSSLOpenSSL
• Software crittografico open source, basato sulla libreria SSLeay sviluppata da Eric A. Young e Tim J. Hudson
• Inizialmente (23/12/98) destinata alla diffusione come libreria per l’implementazione dei protocolli SSL e TLS, negli anni è stata integrata con funzionalità crittografiche avanzate che la rendono la più diffusa e utilizzata in ambito open souce ( e non…) per strumenti di firma, cifratura dati e comunicazioni sicure
• Disponibile sulla maggior parte delle piattaforme Unix proprietarie e open source (Linux, OpenBSD ecc…), nonché sui sistemi Microsoft
Struttura della PKIStruttura della PKI
• La PKI è suddivisa in – Certification Authorities : la gerarchia delle
CA: il sistema che ospita ciascuna CA deve essere off-line per motivi di sicurezza ed amministrata da un addetto (caOperator)
– Registration Authorities : i sistemi di registrazione e autenticazione degli utenti che fanno richiesta di certificato
– Certificate Server : il front-end delle CA e delle RA
Struttura della PKIStruttura della PKI
• CA hierarchy: gerarchia di Certification Authorities facente capo ad una Root CA la cui policy è la certificazione delle Sub-CA
• Ciascuna CA è amministrata da un caOperator
• Ciascuna CA è ospitata su un sistema diverso, off-line, ad accesso controllato
• Le chiavi della CA sono generate ed utilizzate mediante un dispositivo crittografico hardware tamper resistant
Openssl & HSMOpenssl & HSM
• Eventuali moduli di integrazione proprietari o prodotti dal progetto MUSCLE (Movement for the Use of Smart Cards in a Linux Environment) consentono l’interfacciamento dei prodotti basati su libreria OpenSSL a moduli di cifratura hardware (hardware security modules)
Struttura della CAStruttura della CA
• La PKI di test (AntikrimenCA) è costituita da una gerarchia di Certification Authorities, ciascuna destinata ai servizi di certificazione per scopi di utilizzo diversi dei certificati degli utenti
• Per motivi di sicurezza, è infatti possibile limitare gli scopi di utilizzo ( keyUsage ) di un certificato
• A tal fine, nei CPS di ciascuna CA deve essere specificato quali servizi di certificazione eroga
Struttura delle CAStruttura delle CA
• Root CA: la CA che firma i certificati delle sub-CA e le CRL delle Certification Authorities appartenenti al suo “trust domain”– EmailCerts: sub-CA per certificati di firma e
cifratura dei messaggi di posta elettronica– AuthCerts: sub-CA per certificati di
autenticazione SSL– CodeSigning: sub-CA per certificati di firma del
codice distribuito in rete– ServerCerts: sub-CA per certificati di
autenticazione SSL/TSL dei server di rete
Amministrazione della CAAmministrazione della CA
• Le attività di amministrazione dell’intera PKI sono svolte dai caOperator, i quali svolgono i seguenti compiti:– Creazione della CA– Generazione periodica delle CRL– Acquisizione delle richieste di certificato– Generazione dei certificati (utente~server)– Rinnovo dei certificati per la CA– (Eventuale) Richiesta di revoca del
certificato sub-CA
Struttura della PKI - RAStruttura della PKI - RA• PyCA ammette una gestione gerarchica
delle Registration Authority• La RA è così strutturata:
– Un servizio web di front-end mediante il quale gli utenti accedono per richiedere un certificato
– Una casella di posta elettronica, ove gli utenti confermano, mediante un messaggio di posta elettronica, di avere effettuato una richiesta
– I repository locali delle singole RA, dove le richieste sono depositate, se approvate, in attesa di certificazione da parte della CA
Amministrazione delle RAAmministrazione delle RA
• L’operatore di RA ( raOperator ), mediante la propria casella di posta elettronica, verifica la correttezza dell’indirizzo di posta elettronica del mittente
• Gli operatori di RA delle singole CA, se la verifica di cui sopra è corretta, possono a loro volta decidere se approvare o no ciascuna richiesta inserendola o meno nei repository delle CA locali
• L’utilizzo di un challenge, inserito dall’utente in fase di richiesta, può essere di aiuto nella gestione di procedure di autenticazione più sicure da parte delle singole “sub-RA”
Struttura della PKI- Certificate Struttura della PKI- Certificate ServerServer
• Questo servizio, unico per l’intera PKI, svolge le seguenti funzioni:– Presentazione della CA– Acquisizione delle richieste di certificato da
parte degli utenti mediante procedura guidata– Pubblicazione dei certificati emessi, delle CRL
e dei certificati CA (operational protocol HTTPs)
– (Opzionale) Pubblicazione dei certificati emessi, delle CRL e dei certificati CA mediante operational protocol LDAP
La PKI AntikrimenCALa PKI AntikrimenCA
• PKI di esempio:– Un unico sistema che ospita:
• Root CA e 4 sub CA• Certificate Server• RA
– Amministrazione:• Root CA e 4 sub CA: caOperator• RA e sub-RA: raOperator
Installazione della CAInstallazione della CA
• Requisiti:– Openssl– Apache– mod_ssl– Python
• Piattaforme: Linux, Solaris
Creazione della CACreazione della CA
• Installazione del software PyCA– Estrazione dei moduli in /../pyca/– Copia dei moduli web in
/apache_home/ht_docs/– Creazione degli utenti caOperator e
raOperator– Personalizzazione del file
/../pyca/conf/openssl.cnf– Esecuzione del comando
• python /../pyca/sbin/ca-make.py
Ca-make.pyCa-make.py
• Creazione della root-CA e delle sub-Cas– Creazione dei file di configurazione delle
singole CA– Creazione della struttura del file system
necessaria per la gestione del ciclo di vista dei certificati
– Generazione della coppia di chiavi RSA, della richiesta di Certificazione e del Certificato Self-Signed della Root CA
Ca-make.pyCa-make.py
• Creazione della root-CA e delle sub-Cas– Per ciascuna delle Sub-CAs:
• Generazione della coppia di chiavi• Inserimento dati e generazione della
richiesta di certificato PKCS#10• Invio della Richiesta di Certificazione alla
Root-CA • Generazione del certificato della Sub-CA• Installazione del certificato
La Registration AuthorityLa Registration Authority
• Accessibile via web mediante il browser alla pagina https://sitowebca/ca-index.py
• La procedura di enrollment è intuitiva e affidata completamente all’utente (nessuna verifica dell’identità)
Procedura di EnrollmentProcedura di Enrollment
• Al termine della procedura di richiesta:– Il browser genera una richiesta in
formato PKCS#10 che invia automaticamente alla CA
– Un messaggio di posta è inviato automaticamente dalla casella di posta dell’Operatore di RA all’indirizzo di posta indicato dall’utente
Procedura di EnrollmentProcedura di Enrollment
• La richiesta di certificato è approvata se:– L’utente risponde al messaggio di
posta dell’operatore di RA entro i termini temporali consentiti
– L’operatore di RA non elimina il messaggio ricevuto dall’utente, dalla propria casella di posta
Procedura di EnrollmentProcedura di Enrollment
• L’operatore della CA, periodicamente, esegue una applicazione automatica volta ad estrarre le richieste di certificati dalla casella di posta dell’operatore di RA e ad approvare le medesime, inserendole in una apposito repository
• Il comando da utilizzare è :– python ca-cycle-pub.py
Procedura di enrollmentProcedura di enrollment
• L’operatore di CA, periodicamente, esegue un processo che, per ciascuna sub-CA:– Preleva le richieste di certificato, le verifica e genera
il certificato– I certificati generati sono pubblicati sul sito della sub-
CA– Un messaggio di posta è inviato
all’utente,invitandolo a prelevare il proprio certificato dal sito della CA
• Il medesimo processo si occupa inoltre di generare delle nuove CRL per la Root-CA e per le Sub-CA. Il comando da utilizzare è :– python ca-cycle-priv.py
Revoca dei certificatiRevoca dei certificati
• Operazione manuale, svolta dal caOperator su richiesta dell’operatore di RA
• La modalità di richiesta di revoca da parte dell’utente deve essere stabilita e resa nota nei CPS di ciascuna sub-CA
Ricerca dei certificatiRicerca dei certificati
• E’ disponibile una modalità di ricerca dei certificati emessi, attivi o revocati, utilizzando un apposito modulo web disponibile sul Certificate Server
Accesso sicuro ad un server webAccesso sicuro ad un server web
• Per semplificare le modalità di accesso a siti web, e per incrementare il livello di sicurezza delle procedure di autenticazione basate su password, è possibile configurare il proprio server per consentire l’accesso SSL con mutua autenticazione client-server
Protocollo SSLProtocollo SSL
• Presentato nel 1994 da Netscape Communication Corporation che successivamente rilasciò nel 1996 la v3.
• SSL introduce un ulteriore livello nell'architettura ISO/OSI che si colloca tra il livello Applicazione e quello Trasporto
• Una variante, seppur minima, del protocollo è divenuta standard con il nome TLS (RFC 2246)
Protocollo SSLProtocollo SSL
• Garantisce– Privatezza della comunicazione
• Cifratura a chiave simmetrica
– Autenticazione Server• Utilizzo di certificati digitali per scambio
di chiavi
– (opzionale) Autenticazione Client– Integrità dei dati ( Mac dei record
SSL )
Protocollo SSLProtocollo SSL
SSL & ACLSSL & ACL
• Con gli odierni server web, utilizzati con protocollo HTTPS (HTTP over SSL) è possibile definire delle ACL basate sui possibili dati presenti nei certificati degli utenti abilitati all’accesso, – Es: campo “Organization” del Distinguished
Name del certificato utente
oppure consentire l’accesso esclusivamente ad un sottoinsieme di utenti i cui certificati sono contenuti in un repository
SSL & ACLSSL & ACL
• Vantaggi: – Gestione di parte dell’autenticazione demandata alla
CA• In caso di utente malevolo, la revoca da parte della CA
del certificato ha come effetto l’impossibilità di accedere a qualunque sistema ( che ha prelevato l’ultima CRL…)
– Obbligo di revisione delle credenziali di accesso alla scadenza del certificato utente
– Semplificazione delle procedure di registrazione: l’identificazione dell’utente è stata già fatta dalla CA
– Single Sign On– Possibile centralizzazione/semplificazione delle
funzioni di Autenticazione e Autorizzazione– …
Dimostrazione: contestoDimostrazione: contesto
• Un ambiente operativo ( una azienda o altro ) che eroga servizi web ad accesso ristretto ad un insieme di utenti ( alice, bob & altri) appartenenti all’azienda “Antikrimen”
• Test:– Accesso con certificato utente valido– Accesso con certificato utente revocato– Accesso con certificato utente non
appartenente all’azienda “Antikrimen”