Autenticazione ed uso dei certificati:
realizzazione di una semplice
certification Authority
Luca Bechelli
Security Consultant
http://web.tiscalinet.it/LucaBechelli
[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
Asimmetrica
• 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
chiavi
• 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 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 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 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 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
RSA
• 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 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 messaggi
hello
@!ӣ$%&
@!ӣ$%&
/()==?)
/()==?)
*è#@[]
*è#@[]
hello
@#[K”!£
@#[K”!£
world
world
Crittografia asimmetrica e
autenticazione
• 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
• 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
fisica-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 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 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 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 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 (offline?)
• 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 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 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 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
abcdef
ghilmn
opq...
HASH
£$%&/()=?^ @#!£$%&/(^ @#!£$
@#!£$%&/()=?^§ @#!£/()=?^§/()
$%&/()=?^$%&/()=?^()=?^()=?^(
•Verifica Temporale
•Ricerca nella CRL
..tuvz.
£$%&/()=?^ @#!£$%&/(^ @#!£$
@#!£$%&/()=?^§ @#!£/()=?^§/()
$%&/()=?^$%&/()=?^()=?^()=?^(
•Ricerca nella CSL
LDAP
£$%&/()=?^ @#!£$%&/(^ @#!£$
@#!£$%&/()=?^§ @#!£/()=?^§/()
$%&/()=?^$%&/()=?^()=?^()=?^(
•Integrità
•Non Ripudio
•Autenticazione
La 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)
pyCA
• pyCA è una interfaccia scritta in
python per semplificare l’utilizzo
della libreria OpenSSL nelle
operazioni inerenti le attività della
CA, RA e Certificate Server
OpenSSL
• 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 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 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 & 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 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 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 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 - 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 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
Server
• 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 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 CA
• Requisiti:
– Openssl
– Apache
– mod_ssl
– Python
• Piattaforme: Linux, Solaris
Creazione 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.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.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 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 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 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 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 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 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 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 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 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 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 SSL
SSL & 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 & 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: 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”
