La sicurezza nelle Griglie Ing. Tommaso Coviello

Cenni preliminari sulla sicurezza La crittografia è una forma di protezione dei dati da visualizzazioni o modifiche non autorizzate Offre canali di comunicazione protetti Esempio: 2 utenti che vogliono comunicare desiderano che: Eventuali ascoltatori non comprendano la comunicazione I dati non vengano alterati nella comunicazione Abbiano la certezza sulla loro reciproca identità.

Cenni preliminari sulla sicurezza La sicurezza richiede l’esistenza di 3 servizi fondamentali: Autenticazione: è il processo tramite il quale si verifica l’identità di un’entità (utente, servizio, host ecc) Autorizzazione: è il processo che garantisce i diritti di accesso o di effettuare determinate operazioni Codificazione: assicura l’integrità dei dati  i dati non devono essere alterati da entità non autorizzate La riservatezza delle comunicazioni  i dati non devono essere rivelati a entità non autorizzate

Terminologia Codificazione: è la conversione di dati in una forma, detta ciphertext (testo cifrato), che non può essere facilmente compresa da persone non autorizzate. Decodificazione: è il processo inverso alla codificazione.

Terminologia Crittografia simmetrica : si utilizza la stessa chiave per la codifica e decodifica dei dati Crittografia Asimmetrica : si utilizzano due chiavi differenti rispettivamente per la codifica e decodifica Secure Socket Layer / Transport Layer Security (SSL/TLS): sono essenzialmente lo stesso protocollo ma … Public key Infrastructure (PKI): è un infrastruttura sicura formata da un insieme di protocolli, componenti e tecnologie. Autenticazione reciproca: due entità si autenticano reciprocamente mediante lo scambio dei loro certificati digitali invece di utilizzare un repository LDAP per archiviare le chiavi pubbliche

Codifica a chiave simmetrica Si basa sull’utilizzo di un’unica chiave segreta condivisa dalle entità in comunicazione per codificare e decodificare i dati. Questo tipo di codificazione è molto più veloce rispetto a quello a chiave asimmetrica  è utilizzata nella crittografia a blocchi di grandi quantità di dati.

Codifica a chiave simmetrica Esempi: Data Encryption Standard (DES): chiave a 56 bit + 8 bit di parità sviluppato dell’ IBM Triple-DES: chiave a 112 bit + 16 bit di parità oppure chiave a 168 bit + 24 bit di parità RC2 e RC4: chiave di lunghezza variabile (da 40 a 128 bit)

Codifica a chiave simmetrica Per evitare che due blocchi di dati identici vengano trasformati in due blocchi di dati crittografati identici si utilizzano modelli di concatenazione denominati CBC (cipher block chaining). Le informazioni tratte dal blocco precedente vengono utilizzate per crittografare il blocco successivo Componenti utilizzati Chiave privata Vettore di inizializzazione (per crittografare il primo blocco)

Codifica a chiave asimmetrica Le chiavi utilizzate nella codifica e decodifica dei dati sono differenti. La chiave privata deve essere mantenuta segreta dal possessore. La chiave pubblica non è segreta. Un messaggio codificato con una chiave (pubblica o privata) può essere decodificato solo con l’altra chiave. E’ praticamente impossibile calcolare la chiave privata partendo da quella pubblica.

Codifica a chiave asimmetrica Normalmente la chiave pubblica è presente nel certificato digitale emesso da una Certification Authority la quale garantisce la proprietà della chiave pubblica. Il tempo di codifica è molto più lungo rispetto alla codifica con chiave simmetrica. Gli algoritmi a chiave pubblica non possono essere utilizzati per concatenare i dati in flussi come negli algoritmi a chiave privata Questi algoritmi vengono utilizzati per trasmettere una chiave e un vettore di inizializzazione utilizzabili da un algoritmo a chiave privata.

Codifica a chiave asimmetrica Comunicazione tra due utenti A e B: A per trasmettere un messaggio a B utilizza la chiave pubblica di B per codificare il messaggio B riceve il messaggio codificato e lo decodifica con la sua chiave privata B per trasmettere un messaggio ad A utilizza la chiave pubblica di A per codificare il messaggio A riceve il messaggio codificato e lo decodifica con la sua chiave privata.

Firme digitali Gli algoritmi a chiave pubblica possono essere utilizzati anche : per autenticare l’identità del mittente Per verificare l’integrità dei dati Condizione necessaria: la chiave pubblica del mittente deve essere considerata attendibile. Viene creato un digest (rappresentazione dei dati compatta e quasi-univoca) del messaggio attraverso un algoritmo hash Il digest viene crittografato con la chiave privata del mittente Il ricevente ricava il digest del messaggio Decodifica la firma con la chiave pubblica del mittente Confronta i due digest

Firme digitali

Hashing Gli algoritmi hash trasformano una stringa di caratteri in un valore solitamente più corto e di lunghezza fissata. La funzione hash è sempre un’operazione in un senso: non è possibile ricavare il messaggio originale a partire dal suo valore hash. Una buona funzione hash dovrebbe garantire la non collisione per due input diversi con una altissima probabilità.

La Certification Authority Le responsabilità di una CA sono: Identificare con assoluta certezza l’identità di coloro che fanno richiesta di un certificato Emanare, revocare e archiviare certificati Rendere sicuro il server della Certification Authority Assicurare l’unicità dei nomi dei proprietari dei certificati In alcune PKI la CA è affiancata da una o più Registration Authority che hanno la responsabilità di: Approvare o rigettare le richieste di certificati e di trasmettere correttamente le informazioni alla CA.

La Certification Authority Per rendere il sistema affidabile, la CA prima di firmare ed emettere certificati, deve effettuare la stessa operazione su se stessa. La CA genera una coppia di chiavi Protegge la sua chiave privata Crea il proprio certificato Firma il suo certificato con la sua chiave privata La chiave privata della CA è la componente più importante in una PKI. Il possesso di questa chiave permetterebbe di impersonare qualunque entità. Quando due utenti di organizzazioni virtuali necessitano di comunicare, occorre che le rispettive CA si fidino reciprocamente

Certificati Digitali I certificati digitali sono documenti digitali che associano una entità con una specifica chiave pubblica. Un certificato contiene: Una chiave pubblica Informazioni pertinenti al possessore della chiave La firma del certificato da parte della CA attesta l’integrità del certificato. Quando due parti vogliono comunicare: Il mittente spedisce il proprio certificato Il ricevente controlla la firma della CA Se la firma coincide con la CA di cui ha fiducia, accetta la chiave pubblica in essa contenuta.

Certificati digitali Esistono 2 modelli principali di certificati X.509: organizzazione gerarchica; PGP: “ web of trust”. Un certificato X.509 è composto fondamentalmente da: informazioni sul proprietario; la data di scadenza; la chiave pubblica del proprietario; informazioni sull’autorità garante (CA); la firma della CA. I certificati sono pubblicati in una directory pubblica (ad es. LDAP o WWW) gestita dalla CA.

Richiesta di un certificato L’utente richiedente genera una coppia di chiavi Invia alla CA la sua chiave pubblica con le informazioni richieste dalla CA firmando il tutto con la sua chiave privata. La CA verifica attraverso la firma che l’utente è effettivamente possessore della chiave privata associata alla chiave pubblica inviata La CA verifica l’identità dell’utente (ad esempio telefonicamente, via e-mail ecc.) In caso di identità accertata, la CA crea il certificato firmandola con la sua chiave privata.

Certificate revocation list (CRL) Normalmente il legame tra identità e chiave pubblica vale per l’intero periodo di validità del certificato. Può essere necessario rescindere questo legame in anticipo (ad es. la chiave privata è stata persa). In alcune PKI dove viene usato un servizio a directory per immagazzinare le chiavi, la CRL è un mezzo usato per identificare i certificati non più validi. Nella maggior parte degli ambienti di griglia, le risorse utilizzano la mutua autenticazione scambiandosi reciprocamente i certificati.

Autenticazione e autorizzazione Scenario: un host A vuole farsi autenticare da un host B A invia il proprio certificato a B B accetta la chiave pubblica di A e il subjetc del certificato utilizzando la chiave pubblica della CA B genera un numero random e lo invia ad A Una volta ricevuto, A codifica il numero con la chiave privata e lo invia a B B decodifica il numero e si accerta che il certificato è effettivamente quello di A perché è l’unico che può possedere la chiave privata Il certificato è autenticato  il subject viene quindi mappato come un utente locale e quindi autorizzato a eseguire operazioni come un utente locale Subject : “C=IT/O=INFN/OU=host.dominio.it/L=Bari/CN=Tommaso Coviello/Email=tommaso.coviello@ba.infn.it”

Delegazione Supponiamo di trovarci in una situazione in cui un job lanciato dall’ host A sull’ host B crei a sua volta n sub-jobs che vengono lanciati sull ‘host C L’autenticazione sull’ host C può essere fatta delegando all’ host B l’autorità dell’ host A mediante la creazione di un proxy job subjobs HOST A HOST B HOST C

Creazione del proxy Un certificato proxy: Permette di effettuare una singola autenticazione nella griglia È un certificato di durata temporale limitata (default:12 ore) Procedura di delegazione remota Tra A e B viene creata una comunicazione sicura A richiede a B di creare un proxy che delega la propria autorità B creare la richiesta per un certificato proxy e lo rinvia ad A A firma la richiesta con la sua chiave privata e lo rinvia a B Infine A invia proprio certificato a B

Utilizzo del proxy B invia a C il certificato di A e il certificato proxy C recupera la chiave pubblica di A attraverso la procedura di path validation C recupera il subject e la chiave pubblica di A attraverso il certificato utilizzando la chiave pubblica della CA C recupera il subject e la chiave pubblica del proxy utilizzando la chiave pubblica di A I due subject saranno del tipo C=IT/O=INFN/OU=Personal Certificate/L=Bari/CN=Tommaso Coviello/Email=tommaso.coviello@ba.infn.it C=IT/O=INFN/OU=Personal Certificate/L=Bari/CN=Tommaso Coviello/Email=tommaso.coviello@ba.infn.it/CN=proxy Se coincidono a meno della stringa “/CN=proxy” allora il proxy è autenticato

Utilizzo del proxy Il proxy codifica un messaggio di richiesta utilizzando la sua chiave privata e lo invia a C C decodifica la richiesta con la chiave pubblica del proxy Accetta ed esegue la richiesta Problemi: Nella delegazione remota la chiave privata del proxy si trova sulla macchina remota  il manager di quella macchina può sfruttare il proxy per compiere operazioni a nome di un altro Si utilizza la delegazione locale per creare il certificato proxy sulla propria macchina

Sicurezza nelle comunicazioni Nel “globus toolkit” le comunicazioni si basano sulle funzioni SSL/TLS di OpenSSL mutua autenticazione (anziché usare un repository per le chiavi) Privacy nelle comunicazioni Integrità dei dati L’instaurazione di una comunicazione sicura tra un client e un server avviene mediante ciò che viene chiamata “SSL handshake”

SSL SSL è un protocollo aperto e non proprietario; è stato proposto da Netscape Communications al W3 Consortium SSL introduce un ulteriore livello nell’architettura ISO/OSI tra il livello applicazione e trasporto SSL è diviso in 2 parti: SSL Handshake Sequence Protocol: autenticazione e negoziazione delle chiavi SSL Record Protocol: presiede alla codifica e decodifica dei record Applicazione SSL Hands. SSL Record TCP IP

SSL Handshake Sequence Protocol Il client invia al server un messaggio di “ClientHello” Se il server risponde con un messaggio di “ServerHello” allora la connessione è stabilita I messaggi precedenti contengono: Versione del protocollo (v. 2/3) Identificativo della sessione Gli algoritmi di crittografia (Cipher Suite) Il metodo di compressione dei dati Numero casuale

SSL Handshake Sequence Protocol Il server invierà al client il proprio certificato Il client controlla: La validità della data del certificato La firma della CA che ha emesso il certificato Che il nome del server specificato nel certificato effettivamente coincide con quello del server con cui sta comunicando Il server può opzionalmente richiedere il certificato del client per la sua autenticazione Il client risponderà inviando il proprio certificato Il server invia un messaggio di ChangeCipherSpec per segnalare che tutte le sequenze di record rispetteranno le regole definite nella fase precedente Il server invia il messaggio finished (fino ad ora i messaggi erano in chiaro)

Cipher Suite La versione 3 del protocollo SSl specifica 31 Cipher Suites Una Cipher Suites è definita da: Algoritmo asimmetrico per la cifratura della chiave di sessione (RSA, DSA) Algoritmo di cifratura simmetrico Algoritmo di hashing utilizzato per la creazione del MAC (Message Authentication Code) (MD5, SHA)