E-business sicuro. Tecnologie per la gestione delle transazioni su Internet 05/06/06

Transcript

1 E-business sicuro Tecnologie per la gestione delle transazioni su Internet 05/06/06

2 Ecommerce: problematiche Differenze con il commercio tradizionale dati importanti viaggiano su Internet (numero di carta e nome acquirente, indirizzo, codice fiscale ) venditore e acquirente non si conoscono : manca il fattore fiducia Problematiche derivanti dall'uso di Internet IP, TCP, HTTP e i protocolli applicativi non sono tipicamente autenticati IP non garantisce la riservatezza Impianti Informatici 2

3 Requisiti generali Un sistema di transazioni online deve fornire un sostituto valido al rapporto di fiducia Garantire all acquirente l identità e la rintracciabilità del venditore Garantire al venditore la transazione di pagamento Assicurare l atomicità delle operazioni di pagamento e di evasione dell ordine Inoltre, deve far fronte all'insicurezza intrinseca dei protocolli Internet Garantire confidenzialità e integrità dei dati Autenticare mutuamente le parti coinvolte nell operazione Deve essere trasparente e interoperabile Impianti Informatici 3

4 Protocolli principali Esistono tre protocolli principali usati per la sicurezza delle transazioni HTTP sopra SSL (Secure Socket Layer), o HTTPS Confidenzialità-integrità delle comunicazioni Mutua autenticazione il cliente non ha garanzie sull uso che il venditore fa dei dati riservati (frode o errore) il venditore non ha garanzie sull'identità dell acquirente sia chi dice di essere (carte di credito rubate) S/HTTP: Secure HTTP, estensione di HTTP SET (Secure Electronic Transaction) Enforcement della fiducia tra acquirente e venditore Impianti Informatici 4

5 Architettura di un sistema di pagamento elettronico autenticazione e protezione dei dati payment gateway Bank Network Internet customer browser Internet e-commerce web site issuer bank acquirer bank Impianti Informatici 5

6 Glossario cardholder: è il cliente che esegue acquisti online pagando con carta di credito (o tramite bonifico) issuer: la banca su cui si appoggia la carta di credito del cliente e che deve autorizzare i pagamenti merchant: è il venditore che vende prodotti/servizi on-line acquirer: è la banca su cui si appoggia il venditore e che processa le richieste di pagamento via carta di credito payment gateway: è un sistema/sito utilizzato dall acquirer che processa le richieste e le autorizzazioni di pagamento certification authority: è l istituzione che garantisce l identità del cardholder e del merchant Impianti Informatici 6

7 Certificati Digitali e PKI

8 Problema dell identità L utilizzo dell algoritmo di firma digitale garantisce che un documento sia stato firmato con una determinata chiave privata Questo non dice nulla sull AUTORE della firma, se non si è a conoscenza in modo certo della chiave pubblica di una persona Non c è un modo sicuro di scambiarsi le chiavi pubbliche, se non out-of-band (di persona e mediante dischetto, per esempio) Lo scopo di una PKI (Public Key Infrastructure) è di garantire l associazione chiave pubblica-mittente su una scala più vasta Impianti Informatici 8

9 Come funziona una PKI Per poter garantire l associazione tra un soggetto e una determinata chiave pubblica è necessario utilizzare una terza parte fidata che autentichi la chiavi pubblica Questa terza parte viene chiamata certification authority (CA) La CA rilascia un certificato digitale che contiene alcune informazioni sull utente che l ha richiesto, tra cui la chiave pubblica dell utente Il certificato è firmato digitalmente dalla CA In questo modo, pur di ottenere in maniera sicura la chiave pubblica della CA, possiamo ottenere garanzie su una molteplicità di soggetti Impianti Informatici 9

10 Rilascio di un certificato L utente prova la propria identità alla CA (come?) L utente crea una coppia di chiavi (pubblica e privata) e conferisce la pubblica alla CA in modo sicuro (come?) La CA crea un certificato digitale, che contiene la chiave pubblica dell utente ed i dati identificativi Il certificato digitale è firmato elettronicamente con la chiave privata della CA In questa sequenza di operazioni, ovviamente, i punti deboli della catena sono il primo e il secondo Impianti Informatici 10

11 Certificato digitale proprietario del certificato validità del certificato chiave pubblica dell utente ente che ha rilasciato il certificato Mario Rossi dal 1/1/2000 all 1/1/2001 QH76H9H5GJ0J2JHAW CA firma digitale dell ente che ha rilasciato il certificato Impianti Informatici 11

12 Certificato digitale (2) hash function informazioni contenute nel certificato DN utente chiave pubblica dell utente message digest firma digitale criptazione con la chiave privata della CA Impianti Informatici 12

13 Esempio di Certificato digitale X.509 Impianti Informatici 13

14 Lo standard X.509 Lo standard associa un DN (distinguished name) ad una chiave pubblica La struttura di un certificato X.509 è Numero di versione del certificato Serial number del certificato (unico, per distinguerlo) Chiave pubblica DN della CA Periodo di validità DN del proprietario del certificato Tipo di certificato (client, server, ...) Firma digitale della CA Impianti Informatici 14

15 Esempio di certificato X.509 Certificate: Data: Version: v3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: OU=Ace Certificate Authority, O=Ace Industry, C=US Validity: Not Before: Fri Oct 17 18:36: Not After: Sun Oct 17 18:36: Subject Public Key Info: Algorithm: PKCS #1 RSA Encryption Public Key: Modulus: 00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86: 43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00: Public Exponent: (0x10001) Extensions: Identifier: Certificate Type Certified Usage: SSL Client Identifier: Authority Key Identifier Critical: no Key Identifier: f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36: Signature: Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06: 4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8: Impianti Informatici 15

16 Catene e reti di certificazioni Quis custodiebit custodes? I certificati rilasciati da un autorità possono essere garantiti soltanto da un autorità di livello superiore, ma la catena va fermata autorità pubbliche alla sommità della catena web-of-trust di PGP Società specializzate i cui certificati sono già presenti nei maggiori browser (standard de facto) La CA di top level (di root, di fonte, radice) usa un certificato self-signed Come distribuirlo, se non presente nel browser? Problemi di prestazioni e di gestione delle revoche (CRL, Certificate Revocation Lists) Impianti Informatici 16

17 Esempio di gerarchia di Certification Authorities Impianti Informatici 17

18 Secure Socket Layer (SSL)

19 Introduzione ad SSL È un protocollo di comunicazione progettato da Netscape per le comunicazioni sicure via web Essendo flessibile è divenuto standard de facto anche per altri protocolli Draft standard di IETF Garantisce: confidenzialità e integrità autenticazione del server autenticazione del client (opzionale) Utilizza sia crittografia simmetrica sia asimmetrica Esistono implementazioni free (as in free speech), SSLeay ( e OpenSSL ( Impianti Informatici 19

20 Fasi di SSL SSL funziona in due fasi: handshake: utilizzando la crittografia asimmetrica viene scambiato un segreto di sessione tra client e server, da utilizzare nella fase successiva connessione sicura: utilizzando il segreto scambiato durante l handshake il client e il server possono comunicare in modo sicuro mediante crittografia simmetrica Impianti Informatici 20

21 Cipher setting SSL è un protocollo flessibile rispetto all'evoluzione tecnologica Il client e il server possono avere a disposizione diversi algoritmi per la crittografia simmetrica, asimmetrica e per lo scambio di chiavi L insieme degli algoritmi di crittografia conosciuti dal client (o dal server) viene chiamato cipher setting Durante la fase di handshake client e server devono mettersi d accordo su algoritmi di crittografia comuni Tra gli algoritmi minimi implementati per lo standard ci sono DES, RC2, RC4 e IDEA (simmetrici), RSA e DSS (autenticazione), SHA e MD5 (integrità), X.509 (certificati), Diffie-Hellman e RSA (scambio di chiavi); è inoltre richiesto il supporto per il sistema hardware FORTEZZA. Impianti Informatici 21

22 SSL handshake: overview Session key generation 1. cipher setting 2. cipher setting 2. server public key 3. client public key client 4. session key cripted with server public key server Impianti Informatici 22

23 SSL handshake: dettagli 1. Connection Request SSL connection request client cipher settings client random data client server il client invia al server una richiesta di connessione SSL, contenente: il cipher setting del client dei dati random per evitare replay attacks Impianti Informatici 23

24 SSL handshake: dettagli 2. Connection Response server authentication client server cipher settings server random data server certificate client certificate request server il server invia al client il suo cipher setting, una serie di dati random ottenuta concatenando quelli del client con dati scelti da lui Il server ha il cipher setting del client, quindi conosce gli algoritmi da usare: può inviare il suo certificato il server facoltativamente richiede il certificato del client il client autentica il server; se l autenticazione fallisce, la procedura di handshake Impianti viene Informatici interrotta 24

25 SSL handshake: dettagli 3. Client Authentication client certificate client authentication client server se il server ha richiesto l autenticazione del client, il client invia al server il suo certificato il server verifica l identità del client; se l autenticazione fallisce, la procedura di handshake viene interrotta Alternativamente, il client genera una coppia di chiavi asimmetriche (o ne usa una già generata) ed invia la chiave pubblica (senza certificato) al server Impianti Informatici 25

26 SSL handshake: dettagli 4. Session Key Exchange session key session key client server Il client genera una chiave simmetrica (session key) che viene criptata con la chiave pubblica del server e inviata al server Perchè solo il server è sicuramente autenticato! Il server la decripta con la sua chiave privata server e client hanno una stessa chiave simmetrica scambiata in modo sicuro Impianti Informatici 26

27 SSL handshake: server autentication CA public key CA name CA public key CA name CA public key CA name CA public key CA name server public key certificate validity period server domain name CA name digital signature client trusted CA server certificate 1. il certificato del server è nel periodo di validità? 2. la CA del server è considerata attendibile? (anche risalendo la gerarchia delle CA del server e del client) 3. la chiave pubblica della CA valida la firma digitale del certificato del server? 4. il nome (indirizzo) del server specificato nel certificato corrisponde all indirizzo reale del server a cui mi sto collegando? Impianti Informatici 27

28 Resistenza a man-in-the-middle Un attacco man-in-the-middle potrebbe avere effetto contro SSL? Cosa potrebbe cercare di fare un MITM? Intercettando tutte le comunicazioni risponde al client come se fosse il server e comunica con il server come se fosse il client! SSL resiste a questo attacco: il MITM può inviare un certificato con la chiave sostituita: non risulterebbe firmato validamente Inviare un certificato finto, non firmato da una CA attendibile: sarebbe individuato Inviare un certificato vero, ma col nome sbagliato: sarebbe individuato Impianti Informatici 28

29 SSL handshake con MITM 3a. fake auth. 1. cipher setting 2. cipher setting 3. server auth. Session key generatio n client 4. client auth. 5. session key criptata con fake key MITM 4a. fake auth. 5. session key criptata con server key server Impianti Informatici 29

30 Esempio di tentativo di MITM Usiamo dnsspoof per cercare di far risolvere il sito (e.g. al computer aggressore ( ) C:\>ping Pinging [ ] with 32 bytes of data: Reply from : bytes=32 time<10ms TTL=249 Reply from : bytes=32 time<10ms TTL=249 Reply from : bytes=32 time<10ms TTL=249 Reply from : bytes=32 time<10ms TTL=249 Ora proviamo a usare per fare da proxy e intercettare i dati di pagamento Impianti Informatici 30

31 Tentativo di MITM (2) Usiamo webmitm di DSNIFF per mandare un certificato falso ecco cosa vede l utente: Impianti Informatici 31

32 Tentativo di MITM (3) Se anche l utente verifica prima di cliccare ok cosa verifica? Impianti Informatici 32

33 HTTPS HTTP sopra un canale sicuro costruito con SSL Utilizza la porta 443 invece della classica 80 Una alternativa più potente ma non usata è S/HTTP HTTP HTTP SSL SSL TCP/IP Impianti Informatici 33

34 SSL in breve Che cosa fa Protegge le trasmissioni Crittografia Verifica dell integrità (i dati trasmessi non sono stati alterati) Certifica l identità Del server Del client (opzionale) Che cosa NON fa Non protegge i dati prima che vengano spediti o dopo che sono stati ricevuti Sul server Sul client Violazione dei sistemi di server e utenti Non protegge da compromissioni delle PKI Furto di chiavi, per esempio Non è invulnerabile Bachi nel software Stupidità dell'utente Impianti Informatici 34

35 Problema di protezione dei dati dall'uso illecito Problema: SSL protegge i dati da terzi, ma costringe il cardholder a dare il numero di c.c. al merchant Soluzione (possibile) il cliente invia al merchant solo i dati dell'ordine il cliente invia i dati della carta di credito al payment gateway (di cui si fida) il merchant invia la richiesta di pagamento al payment gateway il payment gateway verifica la coerenza dei dati Come fare? Impianti Informatici 35

36 Prima proposta: SET SET introduce il concetto della doppia firma questo meccanismo consente di interagire con soggetti diversi rivelando a ciascuno solo la parte di dati di sua competenza (confidenzialità aumentata) Purtroppo, SET richiede necessariamente che oltre a Merchant e Payment Gateway, anche il Cardholder (cioè il cliente) disponga di un certificato digitale, cioè una preregistrazione del cardholder per usare il protocollo Per questa ragione SET, nonostante sia estremamente affidabile ed elegante, non ha mai preso piede come strumento di e-business Il consorzio VISA - MasterCard che lo ha proposto è stato sciolto Impianti Informatici 36

37 Cosa si usa in pratica Cardholder Merchant Ordine (in chiaro o su SSL) 1 3 O. TransactionID + Generazione richiesta di pagamento $$$$ + Conferma, poi trasmessa al Cardholder Redirect con TransactionID 2 Issuer Pagamento (su SSL) 4 Payment Gateway P. TransactionID + $$$$ Impianti Informatici 37