elle applicazioni di rete Situazione standard Situazione standard Sicurezza di messaggio (o dei dati) Sicurezza di messaggio (o dei dati)

Transcript

1 Antonio Lioy < polito.it > Sicurezza d Politecnico di Torino Dip. Automatica Antonio e Lioy Informatica < polito.it > Politecnico di Torino Dip. Automatica e Informatica Situazione standard autenticazione debole: username e password problema: password snooping Situazione standard indirizzo IP (server web; comandi R = rsh, rlogin, rcp,...) autenticazione problema: debole: IP spoofing altri username problemi e frequenti: password data problema: snooping password / forging snooping indirizzo Sicurezza IP (server web; di comandi canale shadow server / MITM R = rsh, rlogin, rcp,...) autenticazione replay (singola o mutua), integrità e segretezza problema: solo durante IP spoofing il transito nel canale altri nessuna problemi possibilità frequenti: di non ripudio richiede data snooping poca / forging Sicurezza (o nulla) modifica canale alle applicazioni shadow server / MITM autenticazione replay (singola o mutua), integrità e segretezza solo. durante il 11 transito... nel canale nessuna possibilità di non ripudio richiede poca (o nulla) modifica alle applicazioni y - Politecnico di Torino ( ) y - Politecnico di Torino ( ) Sicurezza di messaggio (o dei dati) autenticazione (singola), integrità e segretezza auto-contenute nel messaggio possibilità di non ripudio richiede modifica alle applicazioni Sicurezza di messaggio (o dei dati) autenticazione 01(singola), 00integrità 11 e segretezza auto-contenute nel messaggio possibilità di non ripudio richiede modifica alle applicazioni

2 sec Sicurezza interna alle applicazioni canale logico (socket) TCP APP #1. IP.. APP #N sec sec canale logico rete (socket) TCP IP rete sec ogni applicazione implementa la sicurezza al proprio interno la parte in comune si limita ai canali di comunicazione (socket) ogni applicazione possibili errori di implementa la sicurezza al implementazione proprio interno (inventare protocolli di sicurezza la parte in non comune è semplice!) si limita ai canali di comunicazione non garantisce (socket) l interoperabilità possibili errori di implementazione (inventare protocolli di sicurezza non è semplice!) non garantisce l interoperabilità Sicurezza esterna alle applicazioni APP #1... APP #N il livello sessione sarebbe sec ideale per implementare molte funzioni di sicurezza canale Sicurezza logico esterna alle ma non applicazioni esiste in TCP/IP! sicuro canale logico (socket) è stato proposto un livello sessione sicura : APP #1 TCP... APP #N il livello sessione sarebbe sec ideale semplifica per implementare il lavoro degli IP Protocolli molte di sviluppatori sicurezza funzioni applicativi di sicurezza canale orientati logico al canale di ma evita comunicazione non possibili esiste errori in TCP/IP! di sicuro implementazione canale SSL logico / rete TLS(socket) è stato proposto un livello sessione a scelta sicura : dell applicazione il più diffuso al mondo TCP SSH semplifica il lavoro degli IP Protocolli di sviluppatori sicurezzapplicativi ha avuto un momento di gloria (legato ai divieti di orientati esportazione al canale USA), ma di evita oggi comunicazione è possibili una soluzione errori di di implementazione SSL nicchia / rete TLS PCT a scelta dell applicazione il più diffuso al mondo SSH proposto da MS come alternativa a SSL ha uno avuto dei pochi un momento fiaschi di di MS! gloria (legato ai divieti di esportazione USA), ma oggi è una soluzione di nicchia PCT proposto da MS come alternativa a SSL uno dei pochi fiaschi di MS! y - Politecnico di Torino ( ) 3 y - Politecnico di Torino ( ) 3 SSL (Secure Socket Layer) proposto da Netscape Communications protocollo di trasporto sicuro (circa livello sessione): autenticazione SSL (Secure (server, Socket server+client) Layer) riservatezza dei messaggi proposto autenticazione da Netscape ed integrità Communications dei messaggi protocollo protezione di trasporto da replay e sicuro da filtering (circa livello sessione): applicabile facilmente a tutti i protocolli basati su TCP: autenticazione (server, server+client) riservatezza HTTP, SMTP, dei NNTP, messaggi FTP, TLNT,... autenticazione es. famoso HTTP ed sicuro integrità ( dei messaggi = 443/TCP protezione da replay e da filtering

3 https smtps 443/tcp # http protocol over TLS/SSL 465/tcp # smtp protocol over TLS/SSL (was ssmtp) nntps 563/tcp # nntp protocol over TLS/SSL (was snntp) imap4-ssl Porte 585/tcp ufficiali # IMAP4+SSL per applicazioni (use 993 instead) SSL sshell 614/tcp # SSLshell ldaps 636/tcp # ldap protocol over TLS/SSL (was sldap) nsiiops ftps-data 989/tcp 261/tcp # IIOP ftp protocol, Name Service data, over TLS/SSL https ftps 443/tcp 990/tcp # http ftp protocol, control, over TLS/SSL over TLS/SSL smtps telnets 992/tcp 465/tcp # telnet smtp protocol over TLS/SSL(was ssmtp) nntps imaps 993/tcp 563/tcp # imap4 nntp protocol over over TLS/SSL(was snntp) ircs imap4-ssl 994/tcp 585/tcp # irc IMAP4+SSL protocol over (use TLS/SSL 993 instead) pop3s sshell 614/tcp 995/tcp # SSLshell pop3 protocol over TLS/SSL (was spop3) msft-gc-ssl ldaps 3269/tcp 636/tcp ## ldap MS protocol Global Catalog over TLS/SSL with LDAP/SSL (was sldap) ftps-data 989/tcp # ftp protocol, data, over TLS/SSL ftps 990/tcp # ftp protocol, control, over TLS/SSL telnets 992/tcp # telnet protocol over TLS/SSL imaps 993/tcp # imap4 protocol over TLS/SSL ircs 994/tcp # irc protocol over TLS/SSL pop3s 995/tcp # pop3 protocol over TLS/SSL (was spop3) msft-gc-ssl 3269/tcp # MS Global Catalog with LDAP/SSL SSL - autenticazione e integrità peer authentication all apertura del canale: il server si autentica presentando la propria chiave pubblica (certificato X.509) e subendo una sfida asimmetrica SSL - autenticazione e integrità l autenticazione del client (con chiave pubblica e certificato X.509) è opzionale peer authentication all apertura del canale: per l autenticazione e l integrità dei dati scambiati il server si autentica presentando la propria chiave il protocollo prevede: pubblica (certificato X.509) e subendo una sfida asimmetrica un keyed SSL digest -(MD5 riservatezza o SHA-1) l autenticazione un MID per evitare del replay client (con e cancellazione chiave pubblica e il client certificato genera X.509) una session è opzionale key utilizzata per la per cifratura l autenticazione simmetrica e dei l integrità dati (RC2, dei RC4, dati scambiati DS, il 3DS protocollo o IDA) prevede: la chiave un keyed viene SSL digest comunicata -(MD5 riservatezza o SHA-1) al server tramite crittografia a chiave pubblica (RSA, Diffie-Hellman o Fortezza-KA) un MID per evitare replay e cancellazione il client genera una session key utilizzata per la cifratura simmetrica dei dati (RC2, RC4, DS, 3DS o IDA) la chiave viene comunicata al server tramite crittografia a chiave pubblica (RSA, Diffie-Hellman o Fortezza-KA) y - Politecnico di Torino ( ) 5 y - Politecnico di Torino ( ) 5 SSL schema concettuale (1) server Web sicuro server Web sicuro (2) configurazione di sicurezza SSL schema concettuale (3) cert ( (3bis) server challenge / response (1) (4) cert (utente) (2) configurazione di sicurezza (4bis) client challenge / response (3) cert ( (5) canale sicuro (SSL) (3bis) server challenge / response (4) cert (utente) browser browser

4 SSL handshake protocol SSL change cipher alert Architettura di SSL-3 spec protocol SSL protocol SSL record protocol application protocol (es. HTTP) SSL handshake protocol reliable transport t protocol (es. TCP) SSL SSL change network cipher protocol (es. alert IP) spec protocol protocol application protocol (es. HTTP) SSL record protocol reliable transport t protocol (es. TCP) network protocol (es. IP) Tipica transazione Web: Session-id 1. open, 2. GT page.htm, 3. page.htm, 4. close 1. open, 2. GT home.gif, 3. home.gif, 4. close 1. open, 2. GT logo.gif, 3. logo.gif, 4. close Session-id 1. open, 2. GT back.jpg, 3. back.jpg, 4. close Tipica transazione Web: 1. open, 2. GT music.mid, 3. music.mid, 4. close 1. open, 2. GT page.htm, 3. page.htm, 4. close 1. open, 2. GT home.gif, 3. home.gif, 4. close Se ogni volta si devono 1. open, 2. GT logo.gif, Session-id rinegoziare i parametri crittografici per SSL, il collegamento 3. logo.gif, si 4. appesantisce close molto. 1. per open, evitare 2. GT di ri-negoziare back.jpg, 3. ad back.jpg, ogni connessione 4. close i 1. parametri open, 2. crittografici, GT music.mid, il server 3. music.mid, SSL può offrire 4. close un session identifier (ossia più connessioni possono far parte della stessa sessione logica) Se ogni volta si devono Session-id rinegoziare i parametri crittografici se il client, per all apertura SSL, il collegamento della connessione, si appesantisce molto. presenta un session-id valido si salta la fase di per negoziazione evitare di ri-negoziare e si procede ad subito ogni col connessione dialogo SSL i parametri crittografici, il server SSL può offrire un il server può rifiutare l uso del session-id id (in session identifier (ossia più connessioni possono assoluto o dopo un certo tempo dalla sua far parte della stessa sessione logica) emissione) se il client, all apertura della connessione, presenta un session-id valido si salta la fase di negoziazione e si procede subito col dialogo SSL il server può rifiutare l uso del session-id id (in assoluto o dopo un certo tempo dalla sua emissione) y - Politecnico di Torino ( ) 7 y - Politecnico di Torino ( ) 7 SSL con session-id (1) server Web sicuro (1bis) session-id SSL con session-id (1) (1bis) session-id browser server Web sicuro (5) canale sicuro (SSL) browser

5 associazione logica tra client e server creata dal protocollo di handshake SSL / TLS: sessioni e connessioni definisce un insieme di parametri crittografici è usata da una o più connessioni SSL (1:N) sessione SSL connessione SSL associazione logica tra client e server un canale SSL temporaneo tra client e server creata dal protocollo di handshake associata ad una specifica sessione SSL (1:1) definisce un insieme di parametri crittografici sessioni è usata da una o più connessioni SSL connessioni (1:N) connessione SSL un canale SSL temporaneo tra client e server associata ad una specifica sessione SSL (1:1) sessioni connessioni SSL-3 / TLS record protocol dati applicativi frammentazione F1 F2 compressione SSL-3 / TLS record protocol calcolo del MAC MAC dati applicativi frammentazione padding F1 MAC P compressione cifratura TLS-1.0 record format F2 uint8 type = change_cipher_spec (20), alert (21), calcolo header del MAC MAC handshake (22), H application_data (23) padding uint16 version = major (uint8) MAC + Pminor (uint8) uint16 length: TLS-1.0 record format type cifratura <= 2**14 major minor uint8 (record type = non change_cipher_spec compressi) (20), alert (21), header H y - Politecnico handshake per compatibilità di Torino ( ) (22), application_data con SSL-2 length (23) 9 uint16 <= 2**14 version = major (uint8) + minor fragment (uint8) [ length ] (record compressi) uint16 length:... type <= 2**14 major minor (record non compressi) per compatibilità con SSL-2 length y - Politecnico di Torino ( ) 9 <= 2** fragment [ length ] (record compressi)... TLS - calcolo del MAC MAC = message_digest ( key, seq_number type version length fragment ) TLS - calcolo del MAC message_digest dipende dall algoritmo scelto MAC key = message_digest ( key, seq_number type version length fragment ) sender-write-key o receiver-read-key read seq_number message_digest intero a 64 bit (mai trasmesso ma calcolato dipende implicitamente) dall algoritmo scelto key sender-write-key o receiver-read-key read

6 lunghezza della chiave di cifratura) P2) MAC debole (keyed-digest custom) Problemi di SSL-2 P3) i byte di padding sono inclusi nel calcolo del MAC ma la lughezza del padding non lo è! P1) nella versione esportazione, riduce senza motivo ciò permette la chiave ad di un autenticazione attaccante attivo a 40 di bit cancellare (stessa lunghezza byte alla della fine dei chiave messaggi di cifratura) P2) P4) MAC ciphersuite debole rollback (keyed-digest attack custom) poiché l handshake non è autenticato, un attaccante P3) i byte di padding sono inclusi nel calcolo del attivo può cambiare le ciphersuite nei messaggi di MAC ma la lughezza del padding non lo è! Hello per forzare l uso di cifratura debole (minimo 40 bit, ciò permette perché la ad cifratura un attaccante è obbligatoria attivo di cancellare in SSL-2) byte alla fine dei messaggi P4) ciphersuite rollback attack poiché l handshake non è autenticato, un attaccante attivo può cambiare le ciphersuite nei messaggi di Hello per forzare l uso di cifratura debole (minimo 40 bit, perché la cifratura è obbligatoria in SSL-2) SSL-3: soluzioni ai problemi di SSL-2 S1) usa chiavi di autenticazione a 128 bit, anche con chiavi di cifratura da 40 bit S2) usa HMAC (più forte del keyed digest custom usato in SSL-2) SSL-3: soluzioni ai problemi di SSL-2 S3) cambia l ordine di MAC e padding S1) S4) l handshake usa chiavi di è autenticazione autenticato (tranne a 128 i bit, messaggi anche con Change chiavi Cipher di cifratura Spec) tramite da 40 biti messaggi Finished S2) usa HMAC (più forte del keyed digest custom usato SSL-3: in SSL-2) novità rispetto a SSL-2 S3) cambia l ordine di MAC e padding S4) compressione l handshake dei è autenticato dati: (tranne i messaggi Change opzionale Cipher Spec) tramite i messaggi Finished prima della cifratura (dopo non serve ) SSL-3: novità rispetto a SSL-2 opzionalità della cifratura dei dati: per avere solo autenticazione e integrità compressione dei dati: possibilità di rinegoziare la connessione: opzionale cambio periodico delle chiavi prima della cifratura (dopo non serve ) cambio degli algoritmi opzionalità della cifratura dei dati: per avere solo autenticazione e integrità possibilità di rinegoziare la connessione: y - Politecnico di Torino ( ) 11 y - Politecnico di Torino ( ) 11 cambio periodico delle chiavi cambio degli algoritmi SSL-3 handshake protocol concordare una coppia di algoritmi per confidenzialità ed integrità scambiare dei numeri casuali tra client e server per la successiva generazione delle chiavi SSL-3 handshake protocol stabilire una chiave simmetrica tramite operazioni a chiave pubblica (RSA, DH o Fortezza) concordare una coppia di algoritmi per confidenzialità negoziare il session-id ed integrità scambiare i dei certificati numeri necessari casuali tra client e server per la successiva generazione delle chiavi stabilire una chiave simmetrica tramite operazioni a chiave pubblica (RSA, DH o Fortezza) negoziare il session-id

7 numero di sequenza generazione del MAC Protezione dei dati [ compressi ] MAC padding chiave per MAC numero di sequenza IV generazione chiave per del cifrare MAC IV chiave per cifrare dati [ compressi cifratura a ] simmetrica MAC padding dati protetti cifratura a simmetrica dati protetti Rapporto tra chiavi e sessioni (tra il server ed uno stesso client) comune a più connessioni elle applicazioni pre-master di rete secret ( stabilito con PKC ) Rapporto tra chiavi e sessioni (tra il server ed uno stesso client) generati comune ad a ogni più connessioni connessione elle applicazioni pre-master client di rete random secret ( stabilito server random con PKC ) Meccanismi effimeri comune a più connessioni master secret comune a più connessioni chiavi per MAC chiavi master per secret cifrare IV per cifrare chiavi generati usa-e-getta generate al volo: diverse per ogni connessione ad ogni per connessione avere autenticazione devono essere firmate chiavi per MAC client (es. random devo avere un certificato X.509) chiavi per cifrare server DH random adatto, Meccanismi RSA lento effimeri IV per cifrare compromesso per RSA = riuso N volte chiavi perfect usa-e-getta forward secrecy: generate al volo: diverse per ogni connessione y - Politecnico di Torino per chi conosce avere ( ) autenticazione la chiave privata devono può essere decifrare firmate tutte le 13 (es. sessioni devo avere un certificato X.509) DH con adatto, meccanismi RSA lento effimeri la chiave privata del server compromesso viene usata per solo RSA per = firma riuso N volte perfect forward secrecy: y - Politecnico di Torino ( ) 13 chi conosce la chiave privata può decifrare tutte le sessioni con meccanismi effimeri la chiave privata del server viene usata solo per firma client hello C L I N T C L I N T client hello server hello certificate certificate server request hello server key certificate exchange certificate request S R V R S R V R

8 C L I N T C L I N T certificate verify certificate change cipher spec client key exchange finished certificate verify change cipher spec finished change cipher spec finished change cipher spec S R V R S R V R finished Client hello versione di SSL preferita dal client 28 byte pseudo-casuali (Client Random) un identificatore di sessione (session-id) Client hello 0 per iniziare una nuova sessione diverso da 0 per chiedere di riesumare una versione sessione di SSL precedente preferita dal client 28 elenco byte delle pseudo-casuali cipher suite (Client (=algo Random) di cifratura + un scambio identificatore chiavi + di integrità) sessione supportate (session-id) dal client elenco 0 per dei iniziare metodi Server una di nuova compressione hello sessione supportati dal client versione diverso di da SSL 0 per scelta chiedere dal server di riesumare una sessione precedente 28 byte pseudo-casuali (Server Random) elenco delle cipher suite (=algo di cifratura + un scambio identificatore chiavi + di integrità) sessione supportate (session-id) dal client elenco nuovo dei session-id metodi Server di se compressione session-id=0 hello nel supportati client-hello dal client oppure rifiuta il session-id proposto dal client versione session-id di SSL proposto scelta dal client server il server accetta 28 byte di riesumare pseudo-casuali la sessione (Server Random) un cipher identificatore suite scelta di sessione dal server (session-id) nuovo dovrebbe session-id essere la se più session-id=0 forte in comune nel client-hello col metodo oppure di rifiuta compressione il session-id scelto proposto dal server dal client session-id proposto dal client se il server accetta di riesumare la sessione cipher suite scelta dal server dovrebbe essere la più forte in comune col client y - Politecnico di Torino ( ) 15 y - Politecnico di Torino ( ) 15 metodo di compressione scelto dal server Cipher suite algoritmo di scambio chiavi algoritmo di cifratura simmetrico algoritmo di hash (per il MAC) Cipher suite esempi: algoritmo di scambio chiavi SSL_NULL_WITH_NULL_NULL algoritmo di cifratura simmetrico SSL_RSA_WITH_NULL_SHA SHA algoritmo di hash (per il MAC) SSL_RSA_XPORT_WITH_RC2_CBC_40_MD5 SSL_RSA_WITH_3DS_D_CBC_SHA esempi: SSL_NULL_WITH_NULL_NULL SSL_RSA_WITH_NULL_SHA SHA

9 il subject / subjectaltname deve coincidere con l identità del server (nome DNS, indirizzo IP,...) può essere solo di firma od anche per cifratura Certificate (server) descritto nel campo keyusage certificato se è solo per per server firma allora authentication è poi necessaria la fase il server-key subject / subjectaltname exchange deve coincidere con l identità del server (nome DNS, indirizzo IP,...) può essere solo di firma od anche per cifratura descritto nel campo keyusage se è solo per firma allora è poi necessaria la fase server-key exchange Certificate request serve per autenticazione del client specifica anche la lista delle CA che il server ritiene fidate i browser Certificate mostrano all utente request per il collegamento solo i certificati emessi da CA fidate serve per autenticazione del client specifica anche la lista delle CA che il server ritiene fidate i browser Server mostrano key all utente exchange per il collegamento solo i certificati emessi da CA fidate contiene la chiave pubblica (per scambio chiave) del server richiesto solo nei seguenti casi: server ha Server certificato key RSA exchange solo per firma si usa DH anonimo o effimero per stabilire il contiene master-secret la chiave pubblica (per scambio chiave) del ci server sono problemi di export e si devono usare richiesto chiavi RSA/DH solo nei temporanee seguenti casi: server Fortezza ha certificato RSA solo per firma importante: si usa DH unico anonimo messaggio o effimero con per firma stabilire esplicita il del master-secret server ci sono problemi di export e si devono usare chiavi RSA/DH temporanee Fortezza importante: unico messaggio con firma esplicita del server y - Politecnico di Torino ( ) 17 y - Politecnico di Torino ( ) 17 Certificate (client) trasporta il certificato per la client authentication il certificato deve essere stato emesso da una delle CA fidate elencate dal server nel messaggio Certificate Request Certificate (client) trasporta il certificato per la client authentication il certificato deve essere stato emesso da una delle CA fidate elencate dal server nel messaggio Certificate Request

10 pre-master secret cifrato con la chiave pubblica RSA del server (temporanea o dal certificato) parte pubblica di DH Fortezza varie possibilità Client key exchange pre-master secret cifrato con la chiave pubblica RSA del server (temporanea o dal certificato) parte pubblica di DH Fortezza prova esplicita di firma Certificate verify hash calcolato su tutti i messaggi di handshake che precedono questo e firmato con la chiave privata del client Certificate verify solo in caso di client authentication (per evitare impostori) prova esplicita di firma hash calcolato su tutti i messaggi di handshake che precedono questo e firmato con la chiave privata del Change client cipher spec solo in caso di client authentication (per evitare impostori) provoca l aggiornamento degli algoritmi da usare per la protezione permette di passare dai messaggi precedenti in chiaro all uso nei messaggi successivi degli algoritmi appena Change negoziati cipher spec a rigore fa parte di un protocollo specifico e non provoca l aggiornamento degli algoritmi da usare dell handshake per la protezione varie analisi indicano come sia eliminabile permette di passare dai messaggi precedenti in chiaro all uso nei messaggi successivi degli algoritmi appena negoziati a rigore fa parte di un protocollo specifico e non dell handshake varie analisi indicano come sia eliminabile y - Politecnico di Torino ( ) 19 y - Politecnico di Torino ( ) 19 Finished primo messaggio protetto con gli algoritmi negoziati fondamentale per autenticare tutto lo scambio contiene un MAC Finished calcolato su tutti i messaggi di handshake precedenti (escluso change cipher spec) tramite l uso del master secret primo messaggio protetto con gli algoritmi negoziati evita attacchi man-in-the-middle di tipo rollback (version downgrade o ciphersuite downgrade) fondamentale per autenticare tutto lo scambio differenziato per client e server contiene un MAC calcolato su tutti i messaggi di handshake precedenti (escluso change cipher spec) tramite l uso del master secret evita attacchi man-in-the-middle di tipo rollback (version downgrade o ciphersuite downgrade)

11 1. client hello (ciphersuite list, client random) 2. server hello (ciphersuite, server random) 3. certificate (keyncipherment) TLS, no chiave effimera, no client auth 4. client key exchange (key encrypted for server) CLINT SRVR 5. change cipher spec (activate protection on client side) 1. client hello (ciphersuite list, client random) 6. finished (MAC of all previous messages) 2. server hello (ciphersuite, server random) 7. change cipher spec (activate protection on server side) 3. certificate (keyncipherment) 8. finished (MAC of all previous messages) 4. client key exchange (key encrypted for server) 5. change cipher spec (activate protection on client side) 6. finished (MAC of all previous messages) 7. change cipher spec (activate protection on server side) 8. finished (MAC of all previous messages) TLS, no chiave effimera, client auth CLINT SRVR 1. client hello (ciphersuite list, client random) 2. server hello (ciphersuite, server random) TLS, no chiave effimera, client auth 3. certificate (keyncipherment) 4*. certificate request (cert type, list of trusted CAs) CLINT SRVR 5*. certificate (client cert chain) 1. client hello (ciphersuite list, client random) elle applicazioni 6. client di key rete exchange (encrypted key) 2. server hello (ciphersuite, server random) 7*. certificate TLS, chiave verify (signed effimera, hash of previous no client messages) auth 3. certificate (keyncipherment) 8+9. change cipher spec + finished CLINT 4*. certificate request (cert type, list of trusted SRVR CAs) change cipher spec + finished 5*. 1. client certificate hello (client (ciphersuite cert chain) list, client random) 6. client key exchange 2. server (encrypted hello key) (ciphersuite, server random) TLS, chiave effimera, no client auth 7*. certificate verify (signed hash 3*. of certificate previous messages) (digitalsignature) 8+9. change 4*. server cipher key exchange spec + finished (signed RSA key or DH exponent) CLINT SRVR 5. client key exchange (encrypted change key or cipher client exponent) spec + finished y - Politecnico 1. client di Torino hello ( ) (ciphersuite list, client random) change cipher spec (activate protection on client side) 2. server hello (ciphersuite, server random) 7. finished (MAC of all previous messages) 3*. certificate (digitalsignature) 8. change cipher spec (activate protection on server side) 4*. server key exchange (signed RSA key or DH exponent) 9. finished (MAC of all previous messages) 5. client key exchange (encrypted key or client exponent) y - Politecnico di Torino ( ) change cipher spec (activate protection on client side) 7. finished (MAC of all previous messages) 8. change cipher spec (activate protection on server side) 9. finished (MAC of all previous messages) CLINT TLS, scambio dati e chiusura canale ( handshake h ) SRVR TLS, scambio dati e chiusura canale N. client data (MAC, [ encryption ] ) N+1. server data (MAC, [ encryption ] ) CLINT SRVR LAST-1. alert close notify ( handshake h ) LAST. alert close notify N. client data (MAC, [ encryption ] ) N+1. server data (MAC, [ encryption ] ) LAST-1. alert close notify

12 1*. client hello (, session-id X) 2*. server hello (, session-id X) TLS, ripresa di una sessione 3. change cipher spec (activate protection on client side) 4. finished (MAC of all previous messages) CLINT SRVR 5. change cipher spec (activate protection on server side) 1*. client hello (, session-id X) 6. finished (MAC of all previous messages) 2*. server hello (, session-id X) 3. change cipher spec (activate protection on client side) 4. finished (MAC of all previous messages) 5. change cipher spec (activate protection on server side) 6. finished (MAC of all previous messages) TLS 1.0 (SSL 3.1) Transport Layer Security standard ITF: TLS-1.0 = RFC-2246 (gennaio 1999) TLS 1.0 (SSL 3.1) TLS-1.0 = SSL-3.1 (al 99% coincide con SSL-3) enfasi su algoritmi crittografici e di digest Transport standard (non Layer proprietari); Security supporto obbligatorio: standard DH + DSA ITF: + 3DS TLS-1.0 HMAC = RFC-2246 (gennaio 1999) TLS-1.0 = SSL-3.1 TLS (al 1.199% (SSL coincide 3.2)... ossia la ciphersuite con SSL-3) enfasi TLS_DH_DSS_WITH_3DS_D_CBC_SHA RFC-4346 su algoritmi (aprile 2006) crittografici e di digest standard (non proprietari); supporto obbligatorio: per proteggere da attacchi (*) contro CBC: DH + DSA + 3DS IV implicito rimpiazzato da IV esplicito HMAC errori di padding TLS 1.1 ora usano (SSL il 3.2) messaggio di alert... bad_record_mac ossia la ciphersuite (invece di decryption_failed) TLS_DH_DSS_WITH_3DS_D_CBC_SHA RFC-4346 registrazione (aprile IANA 2006) dei parametri del protocollo per una proteggere chiusura prematura da attacchi del (*) canale contro non CBC: implica più IV che implicito non si rimpiazzato possa riprendere da IV esplicito la sessione note errori addizionali di padding per ora chiarire usano vari il messaggio possibili di attacchi alert bad_record_mac (invece di decryption_failed) y - Politecnico di Torino ( ) 23 (*) S.Vaudenay, Security flaws induced by CBC padding applications registrazione IANA dei parametri del protocollo to SSL, IPSC, WTLS..., LNCS-2332, pp , 2002 y - Politecnico di Torino ( ) 23 una chiusura prematura del canale non implica più che non si possa riprendere la sessione note addizionali per chiarire vari possibili attacchi (*) S.Vaudenay, Security flaws induced by CBC padding applications to SSL, IPSC, WTLS..., LNCS-2332, pp , 2002 TLS 1.2 (SSL 3.3) RFC-5246 (agosto 2008) ciphersuite specifica anche la PRF (pseudo-random function) uso esteso di TLS SHA (SSL (es. in Finished, 3.3) HMAC) supporto per authenticated encryption RFC-5246 (AS in modo (agosto GCM 2008) o CCM) ciphersuite incorpora le specifica estensioni anche (RFC-4366) la PRF e le AS (pseudo-random ciphersuite (RFC-3268) function) uso default esteso ciphersuite di SHA-256 (es. in Finished, HMAC) TLS_RSA_WITH_AS_128_CBC_SHA supporto per authenticated encryption (AS deprecate in modo le ciphersuite GCM o CCM) con IDA e DS incorpora le estensioni (RFC-4366) e le AS

13 (RFC-4492) CC voluzione di TLS (I) (RFC-4132) Camellia (RFC-4162) SD ciphersuites / encryption: (RFC-6209) ARIA (RFC-3268) AS ciphersuites / authentication: (RFC-4492) CC (RFC-2712) Kerberos (RFC-4132) Camellia (RFC-4279) pre-shared key (secret, DH, RSA) (RFC-4162) SD (RFC-5054) SRP (Secure Remote Password) (RFC-6209) ARIA (RFC-6091) OpenPGP ciphersuites / authentication: (RFC-2712) Kerberos (RFC-4279) pre-shared key (secret, DH, RSA) (RFC-5054) SRP (Secure Remote Password) (RFC-6091) OpenPGP compressione: voluzione di TLS (II) (RFC-3749) compression methods + Deflate (RFC-3943) protocol compression using LZS altro: voluzione di TLS (II) (RFC-4366) extensions (specific and generic) compressione: (RFC-4681) user mapping ext. (RFC-3749) compression methods + Deflate (RFC-5746) renegotiation indication ext. (RFC-3943) protocol compression using LZS (RFC-5878) authorization ext. altro: TLS e server virtuali: problema (RFC-6176) prohibiting SSL-2 (RFC-4366) extensions (specific and generic) server (RFC-4507) virtuale (frequente session resumption in caso di w/o web server hosting) state (RFC-4681) user mapping ext. (RFC-4680) diversi nomi handshake logici associati with allo supplemental stesso indirizzo data IP (RFC-5746) renegotiation indication ext. es. libri.myweb.it= , food.myweb.it = (RFC-5878) authorization ext. facile TLS in HTTP/1.1 e server virtuali: problema (RFC-6176) prohibiting SSL-2 il client usa l header Host per identificare il server server (RFC-4507) a cui virtuale vuole collegarsi (frequente session resumption in caso di w/o web server hosting) state ma (RFC-4680) diversi difficile nomi con handshake logici HTTPS associati with allo supplemental stesso indirizzo data IP es. perché libri.myweb.it= , TLS è attivato prima food.myweb.it di HTTP = facile quale in HTTP/1.1 certificato usare? (deve contenere il nome il del client server) usa l header Host per identificare il server a cui vuole collegarsi ma difficile con HTTPS perché TLS è attivato prima di HTTP quale certificato usare? (deve contenere il nome del server) y - Politecnico di Torino ( ) 25 y - Politecnico di Torino ( ) 25 TLS e server virtuali: soluzioni certificato collettivo (wildcard) es. CN=*.myweb.it chiave privata condivisa tra tutti i server trattato in modo diverso dai vari browser TLS e server virtuali: soluzioni certificato con elenco di server in subjectaltname certificato collettivo (wildcard) chiave privata condivisa tra tutti i server es. CN=*.myweb.it occorre ri-emettere il certificato ad ogni aggiunta o chiave cancellazione privata condivisa un server tra tutti i server usare trattato estensione in modo SNI diverso (Server dai vari Name browser Indication) certificato in ClientHello con elenco (permesso di server da RFC-4366) in subjectaltname chiave supporto privata limitato condivisa da parte tra di tutti browser i servere server occorre ri-emettere il certificato ad ogni aggiunta o

14 applica i concetti di TLS alla sicurezza dei datagrammi (es. UDP) non offre tutti i servizi di sicurezza di TLS DTLS in competizione con IPsec e sicurezza applicativa Datagram esempio Transport sicurezza Layer di SIP: Security (RFC-4347) applica con IPsec i concetti di TLS alla sicurezza dei datagrammi (es. UDP) con TLS (solo per SIP_over_TCP) non offre tutti i servizi di sicurezza di TLS con DTLS (solo per SIP_over_UDP) in competizione con IPsec e sicurezza applicativa con secure SIP esempio sicurezza di SIP: con IPsec con TLS (solo per SIP_over_TCP) con DTLS (solo per SIP_over_UDP) con secure SIP Sicurezza di HTTP meccanismi di sicurezza definiti in HTTP/1.0: address-based = il server controlla l accesso in base all indirizzo IP del client Sicurezza di HTTP password-based (o Basic Authentication Scheme) = accesso limitato da username e password, codificate con Base64 meccanismi di sicurezza definiti in HTTP/1.0: entrambi gli schemi sono altamente insicuri address-based = il server controlla l accesso in (perché HTTP suppone che sia sicuro il canale!) base all indirizzo IP del client HTTP/1.1 password-based -introduce basic authentication digest authentication (o Basic Authentication scheme basata su sfida simmetrica Scheme) = accesso limitato da username e RFC-2617 password, HTTP codificate authentication: con Base64basic and digest access authentication GT /path/alla/pagina/protetta HTTP/1.0 entrambi gli schemi sono altamente insicuri HTTP/ Unauthorized - authentication failed (perché HTTP suppone che sia sicuro il canale!) WWW-Authenticate: Basic realm="realmname" Authorization: HTTP/1.1 -introduce basic Basic B64_encoded_username_password authentication digest authentication scheme basata HTTP/1.0 su sfida 200 simmetrica OK Server: RFC-2617 NCSA/1.3 HTTP authentication: basic and digest Content-type: text/html GT access /path/alla/pagina/protetta authentication HTTP/1.0 y - Politecnico <HTML> di Torino pagina ( ) protetta... </HTML> 27 HTTP/ Unauthorized - authentication failed WWW-Authenticate: Basic realm="realmname" Authorization: Basic B64_encoded_username_password HTTP/ OK Server: NCSA/1.3 Content-type: text/html y - Politecnico <HTML> di Torino pagina ( ) protetta... </HTML> 27 RFC-2069 HTTP digest authentication tecnicamente obsoleto ma considerato come caso base in RFC-2617 HTTP digest authentication calcolo del keyed-digest: HA1 = md5 ( A1 ) = md5 ( user ":" realm ":" pwd ) RFC-2069 HA2 = md5 ( A2 ) = md5 ( method ":" URI ) tecnicamente obsoleto response = md5 ( HA1 ":" nonce ":" HA2 ) ma considerato come caso base in RFC-2617 usa un server nonce per evitare replay calcolo del keyed-digest: il server di autenticazione può inserire un campo "opaque" HA1 = md5 per trasportare ( A1 ) = md5 informazioni ( user ":" realm di stato ":" pwd (es. ) token HA2 SAML) = md5 verso ( A2 ) il = server md5 ( method del contenuto ":" URI ) response = md5 ( HA1 ":" nonce ":" HA2 )

15 WWW-Authenticate: Digest realm="polito", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", HTTP opaque="5ccc069c403ebaf9f0171e9517f40e41" - digest authentication scheme Authorization: Digest username="lioy", GT realm="polito", /private/index.html HTTP/1.1 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", HTTP/ Unauthorized - authentication failed uri="/private/index.html", response="32a c39b4a edf", WWW-Authenticate: Digest realm="polito", opaque="5ccc069c403ebaf9f0171e9517f40e41" nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", pwd=antonio HTTP/1.1 opaque="5ccc069c403ebaf9f0171e9517f40e41" 200 OK Server: NCSA/1.3 Authorization: Digest username="lioy", Content-type: text/html realm="polito", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", <HTML> pagina protetta... </HTML> uri="/private/index.html", response="32a c39b4a edf", opaque="5ccc069c403ebaf9f0171e9517f40e41" pwd=antonio HTTP/ OK Server: NCSA/1.3 Content-type: text/html <HTML> pagina protetta... </HTML> due alternative: HTTP e SSL/TLS TLS then HTTP (RFC-2818 HTTP over TLS) HTTP e SSL/TLS HTTP then TLS (RFC-2817 upgrading to TLS within HTTP/1.1) due nota: alternative: SSL then HTTP usato ma non documentato TLS then HTTP non (RFC-2818 equivalenti e HTTP con impatto over TLS) su applicazioni, firewall Client e IDS authentication SSL HTTP then TLS concetti (RFC-2817 applicabili a livello upgrading applicativo generale to TLS a within tutti protocolli: HTTP/1.1) tramite nota: SSL/TLS la client then authentication proto HTTP vs. usato proto è ma possibile then non TLS identificare documentato l utente che ha aperto un canale (senza richiedergli username e password) non equivalenti e con impatto su applicazioni, firewall alcuni server Client e IDS web authentication permettono di fare SSL un mapping (semi-)automatico tra credenziali estratte dal concetti applicabili a livello in applicativo certificato X.509 e utenti generale del servizio a tutti HTTP protocolli: e/o del S.O. tramite SSL/TLS la client then authentication proto vs. proto è possibile then TLS 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 servizio HTTP e/o del S.O. y - Politecnico di Torino ( ) 29 y - Politecnico di Torino ( ) 29 Autenticazione nelle applicazioni web più in basso si fà il controllo e meno parti si espongono agli attacchi inutile ripetere l autenticazione (id propagabile) Autenticazione nelle applicazioni web applicazione ASP, PHP, JSP autenticazione più in basso (application si fà server) il controllo applicativa e meno parti si espongono agli attacchi mapping inutile ripetere canale l autenticazione HTTP HTTP basic/digest (id propagabile) (server web) authentication applicazione ASP, PHP, JSP autenticazione (application canale SSL server) SSL client-auth. applicativa (X.509) (libreria) mapping

16 Username e password in un form? perché la sicurezza effettiva dipende dalla URI del metodo usato per inviare username e password al server tecnicamente, non importa la sicurezza della pagina in cui <form si introducono action= > i dati ma psicologicamente è importante la sicurezza della pagina in cui si introducono i dati perché perché la sicurezza effettiva dipende dalla URI pochi utenti hanno le conoscenze tecniche del metodo usato per inviare username e password necessarie a verificare la URI del metodo usato per al server l invio <form action= > ma psicologicamente è importante la sicurezza della pagina in cui si introducono i dati perché pochi utenti hanno le conoscenze tecniche necessarie a verificare la URI del metodo usato per l invio Sistemi di pagamento elettronico fallimento della moneta elettronica per problemi tecnici e normativi (es. bancarotta di DigiCash) attualmente il metodo più usato è trasmissione del numero di carta di credito su canale SSL... Sistemi di pagamento elettronico... che però non garantisce contro le frodi: VISA uropa dichiara che il 50% dei tentativi di frode fallimento della moneta elettronica per problemi nascono da transazioni Internet, che però sono tecnici e normativi (es. bancarotta di DigiCash) solo il 2% del suo volume d affari! attualmente il metodo più usato è trasmissione Sicurezza delle transazioni del numero di carta di credito su canale SSL che però basate non garantisce su carta contro di credito le frodi: VISA STT uropa dichiara che il 50% dei tentativi di frode (Secure nascono Transaction da transazioni Technology) Internet, che però sono solo VISA il + 2% Microsoft del suo volume d affari! SPP Sicurezza delle transazioni (Secure lectronic Payment Protocol) basate su carta di credito Mastercard, IBM, Netscape, GT, CyberCash STT ST = STT + SPP (Secure Transaction Technology) (Secure lectronic Transaction) VISA + Microsoft SPP (Secure lectronic Payment Protocol) Mastercard, IBM, Netscape, GT, CyberCash ST = STT + SPP (Secure lectronic Transaction) y - Politecnico di Torino ( ) 31 y - Politecnico di Torino ( ) 31 ST ST non è un sistema di pagamento ma un insieme di protocolli per usare in rete aperta in modo sicuro un infrastruttura esistente basata su carte di credito usa certificati X.509v3 ST dedicati esclusivamente alle transazioni ST ST non è un sistema di pagamento ma un assicura la privacy degli utenti perché mostra a insieme di protocolli per usare in rete aperta in ciascuna parte solo i dati che le competono modo sicuro un infrastruttura esistente basata su carte di credito usa certificati X.509v3 dedicati esclusivamente alle transazioni ST assicura la privacy degli utenti perché mostra a ciascuna parte solo i dati che le competono

17 digest: SHA-1 crittografia simmetrica: DS Caratteristiche di ST scambio chiavi: RSA firma digitale: RSA con SHA-1 versione 1.0 (maggio 1997) digest: SHA-1 org crittografia simmetrica: DS scambio chiavi: RSA firma digitale: RSA con SHA-1 org Architettura di ST cardholder Architettura di ST INTRNT merchant cardholder Attori in ST (I) payment gateway merchant INTRNT payment network cardholder payment issuer legittimo possessore di una carta di credito acquirer gateway aderente a ST merchant venditore di un Attori prodotto in ST via Internet (I) (Web o e- payment mail) network cardholder issuer issuer acquirer y - Politecnico legittimo di Torino ( ) possessore di una carta di credito istituto finanziario che ha emesso la carta di 33 aderente a ST credito dell utente merchant venditore di un prodotto via Internet (Web o e- mail) issuer y - Politecnico istituto di Torino finanziario ( ) che ha emesso la carta di 33 credito dell utente Attori in ST (II) acquirer organizzazione finanziaria che stabilisce un rapporto col mercante e lo interfaccia con uno o più circuiti di pagamento payment gateway Attori in ST (II) sistema che traduce transazioni ST nel formato acquirer richiesto dal circuito di pagamento dell acquirer organizzazione finanziaria che stabilisce un certification authority rapporto col mercante e lo interfaccia con uno o emette certificati X.509v3 e CRL X.509v2 per tutti più circuiti di pagamento gli altri attori di ST payment gateway sistema che traduce transazioni ST nel formato richiesto dal circuito di pagamento dell acquirer certification authority

18 issuer) si usa una doppia firma al merchant non vengono fatti sapere gli estremi del pagamento Doppia firma ST alla banca non viene fatto sapere quale merce si è per garantire privacy all utente nei confronti di acquistata merchant e del sistema finanziario (acquirer + issuer) solo l utente si usa può una dimostrare doppia firma l associazione tra merce e pagamento al merchant non vengono fatti sapere gli estremi del pagamento alla banca non viene fatto sapere quale merce si è acquistata solo l utente può dimostrare l associazione tra merce e pagamento Doppia firma ST: dettagli PI: Purchase Information (pagamento) OI: Order Information (merce) DS = ( H( H(PI),H(OI) ), Ukpri) OI+DS+H(PI) Doppia al merchant firma ST: dettagli merchant conosce OI e può calcolare PI: H(H(PI),H(OI)) Purchase Information verificando (pagamento) che corrisponda al OI: valore Order estratto Information dalla firma (merce) PI+DS+H(OI) = ( H(PI),H(OI) all acquirer ), Ukpri) OI+DS+H(PI) acquirer conosce Problemi al merchant PI e può di calcolare ST H(H(PI),H(OI)) verificando che corrisponda al valore estratto merchant conosce OI e può calcolare dalla software firma molto caro (sia per le CA, sia per il H(H(PI),H(OI)) merchant e l acquirer) verificando che corrisponda al valore estratto dalla firma necessita di un applicazione speciale dal lato PI+DS+H(OI) utente (ST wallet) all acquirer acquirer conosce Problemi PI e può di calcolare ST procedura di rilascio del certificato a H(H(PI),H(OI)) chiave verificando pubblica per che gli corrisponda utenti complessa al valore estratto dalla software firma molto caro (sia per le CA, sia per il merchant in sviluppo e la l acquirer) versione 2.0 di ST che farà a meno del wallet (userà un browser) necessita di un applicazione speciale dal lato utente (ST wallet) procedura di rilascio del certificato a chiave pubblica per gli utenti complessa in sviluppo la versione 2.0 di ST che farà a meno del wallet (userà un browser) y - Politecnico di Torino ( ) 35 y - Politecnico di Torino ( ) 35 Architettura di pagamento via Web 1. offerta 2. ordine Architettura Internet di pagamento via Web cardholder merchant cardholder 2. ordine POS virtuale Internet payment gateway POS 1. offerta mondo finanziario merchant payment network mondo finanziario

19 l acquirente possiede una carta di credito l acquirente ha un browser con SSL Pagamento conseguenze: con carta di credito via Web la sicurezza effettiva dipende dalla configurazione ipotesi sia del base: server sia del client l acquirente il payment gateway possiede ha una tutte carta le informazioni di credito (pagamento l acquirente ha + merce) un browser mentre con il SSL merchant ha solo le informazioni sulla merce conseguenze: la sicurezza effettiva dipende dalla configurazione sia del server sia del client il payment gateway ha tutte le informazioni (pagamento + merce) mentre il merchant ha solo le informazioni sulla merce PCI DSS Payment Card Industry Data Security Standard oggi richiesto da tutte le carte di credito per transazioni Internet molto più prescrittivo PCI rispetto DSS ad altre norme di sicurezza (es. HIPAA = Health Insurance Portability and Accountability Act) Payment Card Industry Data Security Standard oggi richiesto da tutte le carte di credito per transazioni v2.0 = ott Internet 2010 molto v3.0 più = Requisiti nov prescrittivo 2013 PCI rispetto DSS ad altre (I) norme di sicurezza (es. HIPAA = Health Insurance Portability costruire e and mantenere Accountability una rete Act) protetta: R1 = installare e mantenere una configurazione v2.0 con firewall = ott 2010 per proteggere i dati dei titolari delle carte v3.0 = Requisiti nov 2013 PCI DSS (I) R2 = non usare password di sistema predefinite o altri parametri di sicurezza impostati dai fornitori costruire e mantenere una rete protetta: proteggere i dati dei titolari delle carte: R1 = installare e mantenere una configurazione con R3 = firewall proteggere per proteggere i dati dei titolari i dati delle dei titolari carte delle carte memorizzati R2 R4 = cifrare non usare i dati password dei titolari di delle sistema carte predefinite quando o altri trasmessi parametri attraverso di sicurezza reti pubbliche impostati aperte dai fornitori proteggere i dati dei titolari delle carte: R3 = proteggere i dati dei titolari delle carte memorizzati R4 = cifrare i dati dei titolari delle carte quando trasmessi attraverso reti pubbliche aperte y - Politecnico di Torino ( ) 37 y - Politecnico di Torino ( ) 37 Requisiti PCI DSS (II) rispettare un programma per la gestione delle vulnerabilità R5 = usare e aggiornare con regolarità l antivirus R6 = sviluppare Requisiti e mantenere PCI DSS applicazioni (II) e sistemi protetti rispettare implementare un programma misure forti per per la il gestione controllo delle accessi vulnerabilità R7 = limitare l accesso ai dati dei titolari delle R5 carte = usare solo se e effettivamente aggiornare con indispensabili regolarità l antivirus per lo svolgimento dell attività commerciale R6 = sviluppare e mantenere applicazioni e sistemi R8 = dare protetti un ID univoco ad ogni utente del SI implementare R9 = limitare misure la possibilità forti per di accesso il controllo fisico accessi ai dati dei titolari delle carte R7 = limitare l accesso ai dati dei titolari delle

20 R10 = monitorare e tenere traccia di tutti gli accessi effettuati alle risorse della rete e ai dati dei titolari delle carte Requisiti PCI DSS (III) R11 = eseguire test periodici dei processi e dei sistemi di protezione monitorare e testare le reti con regolarità adottare una Politica di Sicurezza R10 = monitorare e tenere traccia di tutti gli accessi R12 = adottare effettuati una alle Politica risorse di della Sicurezza rete e ai dati dei titolari delle carte R11 = eseguire test periodici dei processi e dei sistemi di protezione adottare una Politica di Sicurezza R12 = adottare una Politica di Sicurezza y - Politecnico di Torino ( ) 39 y - Politecnico di Torino ( ) 39