Sicurezza interna alle applicazioni. Sicurezza esterna alle applicazioni. SSL: introduzione. Sicurezza nei Sistemi Informativi

Transcript

1 Sicurezza nei Sistemi Informativi La sicurezza nei protocolli di rete Ing. Orazio Tomarchio Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Sicurezza interna alle applicazioni Ogni applicazione implementa la sicurezza al proprio interno La parte in comune si limita ai canali di comunicazione (socket) Possibili errori di implementazione (inventare protocolli di sicurezza non è semplice!) Non garantisce l interoperabilità O.Tomarchio Sicurezza nei Sistemi Informativi 2 Sicurezza esterna alle applicazioni : introduzione il livello sessione sarebbe ideale per implementare molte funzioni di sicurezza ma non esiste in TCP/IP! è stato proposto un livello sessione sicura : semplifica il lavoro degli sviluppatori applicativi evita possibili errori di implementazione a scelta dell applicazione Secure Socket Layer () è una suite protocollare pensata per fornire servizi di sicurezza ad applicazioni che necessitano di un canale di comunicazione a stream Modello e livello di trasporto TCP Autenticazione Integrità Confidenzialità L intento è quello di fornire un canale di comunicazione sicuro autenticato con chiavi effimere, basandosi su credenziali crittografiche asimmetriche di lunga durata: certificati X.509 O.Tomarchio Sicurezza nei Sistemi Informativi 3 O.Tomarchio Sicurezza nei Sistemi Informativi 4

2 : breve storia : funzionamento ad alto livello Proposto inizialmente da Nescape Communications v1: 1994, diversi problemi, mai utilizzata v2: 1995, implementata in Navigator 1 v3: 1996, versione rivista e corretta, la più usata oggi TLS (Transport Layer Security): 1999, versione di v3 standardizzata dall IETF, specificamente con l obiettivo di utilizzare DSS invece di RSA per motivi di proprietà intellettuale. Ci sono poi altre differenze minori con v3 Ci concentreremo su v3 AUTENTICAZIONE - all apertura del canale: il server si autentica presentando la propria chiave pubblica (certificato X.509) e subendo una sfida asimmetrica l autenticazione del client (con chiave pubblica e certificato X.509) è opzionale INTEGRITA : un digest (MD5 o SHA-1) protetto un MID per evitare il replay e la cancellazione O.Tomarchio Sicurezza nei Sistemi Informativi 5 O.Tomarchio Sicurezza nei Sistemi Informativi 6 : funzionamento ad alto livello : architettura generale CONFIDENZIALITA : Record protocol Il client genera una session key utilizzata per la cifratura simmetrica dei dati (RC2, RC4, DES, 3DES o IDEA) Handshake protocol Pacchetti da/per il livello applicativo la chiave viene comunicata al server cifrandola con la chiave pubblica del server (RSA, Diffie Hellman o Fortezza-KEA) Change CipherSpec protocol Alert protocol Handshake ChangeCipher Alert Record Protocol Negoziazione dei parametri di sicurezza Livello TCP Livello IP O.Tomarchio Sicurezza nei Sistemi Informativi 7 O.Tomarchio Sicurezza nei Sistemi Informativi 8

3 : architettura generale handshake protocol Record protocol Si occupa di trasportare dati utente, o messaggi protocollari, da un peer all altro, fornendo ai livelli superiori gli stessi servizi di TCP, con in più i servizi di sicurezza Una volta terminato il setup della sessione, tutto ciò che viene trasportato da questo protocollo sarà protetto (integrità, autenticazione e confidenzialità) Handshake protocol Il protocollo usato da per la gestione dei parametri di sicurezza (cipher suite, ecc.), autenticazione (mutua, opzionalmente) e derivazione di chiavi effimere L operazione di derivazione di chiavi effimere è costosa computazionalmente (basata su crittografia asimmetrica), quindi introduce il concetto di sessione, sulla quale si possono appoggiare più connessioni distinte, ciascuna con le proprie chiavi effimere, derivate da quelle di sessione Change CipherSpec protocol Un protocollo banale (un messaggio con un bit impostato a 1!) che segnala la conclusione dell handshake in chiaro Alert protocol Il protocollo usato per gestire condizioni di errore, per esempio quando ci sono problemi con il sottostante livello di trasporto Obiettivi Autenticazione di B ad A, e, opzionalmente, di A a B Instaurazione di una chiave effimera di sessione K ms (Master Secret), dalla quale sarà possibile derivare altre chiavi effimere per le varie connessioni identifica A (initiator) come il client, e B (responder) come il server I messaggi dell Handshake protocol vengono scambiati tra A e B incapsulati nell Record protocol O.Tomarchio Sicurezza nei Sistemi Informativi 9 O.Tomarchio Sicurezza nei Sistemi Informativi 10 handshake protocol handshake protocol Ciascun record contiene di norma diversi messaggi di handshake Per esempio, il record (2) di solito contiene i messaggi server_hello, certificate, [certificate_request], server_hello_done R A, R B : numeri casuali Auth A = SIG KprivA (hash(messaggi precedenti)) PMS: pre-master secret, numero casuale scelto da A K ms = f PMS (R A, R B ), dove f è una funzione MAC basata su PMS abbastanza complicata derivata dalla combinazione di SHA1 e MD5 hash A/B = g Kms ({client/server}, messaggi precedenti), dove g è un altra funzione MAC complicata derivata da SHA1 e MD5 A questo punto abbiamo raggiunto l instaurazione di una sessione Autenticazione (mutua) A autentica B perché B è in grado di provare ad A di poter decrittografare PMS (e quindi calcolare la corretta Kms) con la chiave privata certificata in CERTB Opzionalmente, B autentica A grazie ad AuthA Instaurazione di una sessione, identificata da (K ms, sess-id). K ms è di 384 bit (48 byte) A questo punto vengono derivate le chiavi effimere necessarie ad assicurare i servizi di sicurezza al traffico utente (che verrà trasportato, criptato, nell Record protocol): connessione O.Tomarchio Sicurezza nei Sistemi Informativi 11 O.Tomarchio Sicurezza nei Sistemi Informativi 12

4 handshake protocol handshake protocol Vengono derivate, da Kms, tre coppie di chiavi (key expansion): Client write MAC, client write, client IV (Kcm, Kc, IVc) Server write MAC, server write, server IV (Ksm, Ks, IVs) Il meccanismo di derivazione è simile a quello usato per derivare K ms da PMS: combinazione complicata di MD5 e SHA1, che agisce su K ms, R A, R B Le tre chiavi client servono per crittografare e autenticare tutti i dati utente inviati da A a B Le tre chiavi server servono per crittografare e autenticare tutti i dati utente inviati da B ad A Supporto opzionale per PFS La derivazione di K ms può anche avvenire a partire da un valore PMS derivato con Diffie-Hellman, invece di essere generato da A e trasportato a B Gestione di gerarchie di CA Quando A o B inviano un certificato, possono in realtà includere non solo il loro certificato, ma tutta la catena di certificati necessari a validare il loro certificato Quando il server (B) richiede che A si autentichi, normalmente include anche nella richiesta una lista di CA ammissibili O.Tomarchio Sicurezza nei Sistemi Informativi 13 O.Tomarchio Sicurezza nei Sistemi Informativi 14 Sessione/connessione: session-id Sessione/connessione: session-id Se ad ogni connessione si dovessero rinegoziare tutti i parametri crittografici di, il collegamento si appesantirebbe notevolmente Per evitare di dover ri-negoziare ad ogni sessione i parametri crittografici, il server può offrire un connection identifier Se il client, all apertura della sessione, presenta un connection-id valido si salta la fase di negoziazione e si procede subito col dialogo Il server può rifiutare l uso del connection-id (in assoluto o dopo un certo tempo dalla sua emissione) Una volta stabilita una sessione tra A e B, e derivata K ms, è possibile, mantenendo stato tra diverse connessioni, generare le chiavi effimere necessarie senza ripetere le operazioni (costose, computazionalmente) di derivazione di Kms Questa variante del protocollo viene utilizzata quindi per riprendere una sessione di cui ci si ricorda (sess-id, K ms ) La cipher suite può essere rinegoziata I numeri casuali R A e R B vegono rinegoziati O.Tomarchio Sicurezza nei Sistemi Informativi 15 O.Tomarchio Sicurezza nei Sistemi Informativi 16

5 Record Protocol CipherSuite di L Record protocol, una volta instaurata una connessione, protegge tutti i dati, sia utente, sia di segnalazione (es., Alert protocol) scambiati tra A e B La compressione è opzionale La funzione di MAC è HMAC per TLS, è un precursore di HMAC per v3 v3 (e TLS) definiscono un insieme piccolo e finito di cipher suite, non una combinazione arbitraria, definibile da uno dei due party, di algoritmi La cipher suite scelta identifica univocamente tutti gli algoritmi crittografici, insieme con gli eventuali loro parametri, da utilizzarsi nelle connessioni appartenenti ad una data sessione Ad esempio: DES-CBC per cifratura, HMAC-MD5 per MAC, MD5+SHA1 per hash, ecc. Il client presenta al server una lista delle cipher suite che esso implementa, in ordine decrescente di preferenza Il server ne sceglie una, di solito quella più in alto nella lista che esso è in grado di supportare Attenzione alle cipher suite EXPORTABLE, esplicitamente pensate per l export dagli USA Cipher suite da evitare assolutamente, visto che usano chiavi effimere di soli 40 bit O.Tomarchio Sicurezza nei Sistemi Informativi 17 O.Tomarchio Sicurezza nei Sistemi Informativi 18 CipherSuite di In particolare, una ciphersuite definisce: Algoritmo per lo scambio di chiavi Algoritmo per l autenticazione Algoritmo per la cifratura simmetrica Algoritmo per il message authentication code (MAC) Esempi EXP-RSA-RC4-MD5 Kx= RSA( 512), Au= RSA, Enc= RC4(40), Mac= MD5 RSA-DES-CBC3-SHA Kx= RSA, Au= RSA, Enc= 3DES( 168), Mac= SHA1 Uso di Ad oggi, viene usato soprattutto per rendere sicure le transazioni HTTP ( In questi casi l autenticazione non è mutua: il client di solito viene autenticato con meccanismi a livello applicativo (es., password), che però viaggiano in rete protetti dalla connessione Tutti i maggiori browser Web oggi supportano O.Tomarchio Sicurezza nei Sistemi Informativi 19 O.Tomarchio Sicurezza nei Sistemi Informativi 20

6 Uso di Porte ufficiali per applicazioni Tuttavia si può usare anche per rendere sicura la comunicazione di alcune applicazioni standard -telnet, -ftp, -rsh Oppure è possibile utilizzare per creare una sorta di tunnel sicuro a livello TCP Ci sono vari tool basati su questo approccio (es., stunnel) Problema principale di questo approccio: TCP over TCP nsiiops 261/tcp # IIOP Name Service over TLS/ https 443/tcp # http protocol over TLS/ smtps 465/tcp # smtp protocol over TLS/ (was ssmtp) nntps 563/tcp # nntp protocol over TLS/ (was snntp) sshell 614/tcp # shell ldaps 636/tcp # ldap protocol over TLS/ (was sldap) ftps-data 989/tcp # ftp protocol, data, over TLS/ ftps 990/tcp # ftp protocol, control, over TLS/ telnets 992/tcp # telnet protocol over TLS/ imaps 993/tcp # imap4 protocol over TLS/ ircs 994/tcp # irc protocol over TLS/ pop3s 995/tcp # pop3 protocol over TLS/ (was spop3) O.Tomarchio Sicurezza nei Sistemi Informativi 21 O.Tomarchio Sicurezza nei Sistemi Informativi 22 Access control su Web Access control su Web Autenticazione basata sull indirizzo dell host Soltanto alcuni indirizzi IP hanno l accesso (spoofing) Autenticazione basata su username e password (su pagine Web inviate su https) Tutto ciò che passa in rete è cifrato Viene evitato lo spoofing Ma i cookie sono in chiaro su disco Le password sono facilmente comunicate ad altri Client Authentication: Il server ha un database con i certificati degli utenti qualificati e le politiche di accesso Il web server richiede il certificato client durante l handshake di Il client invia il certificato richiesto dal server, di conseguenza, dopo aver stabilito la transazione sicura, potrà ottenere tutti i servizi consentiti dalle politiche di accesso in base all identità evidenziata dal certificato digitale O.Tomarchio Sicurezza nei Sistemi Informativi 23 O.Tomarchio Sicurezza nei Sistemi Informativi 24

7 Client Authentication a livello applicativo Tramite la client authentication è quindi possibile identificare l utente che ha aperto un canale (senza richiedergli username e password) Alcuni server web permettono di fare un mapping (semi-)automatico tra credenziali estratte dal certificato X.509 e utenti del server web e/o del S.O. O.Tomarchio Sicurezza nei Sistemi Informativi 25