Tecnologie per la gestione delle transazioni su Internet 19/04/06

Transcript

1 E-business sicuro Tecnologie per la gestione delle transazioni su Internet 19/04/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

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

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

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

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

7 Secure Socket Layer (SSL)

8 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 (

9 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

10 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.

11 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

12 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

13 SSL handshake: dettagli 2. Connection Response server cipher settings server random data server authentication server certificate client certificate request client 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 viene interrotta

14 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

15 SSL handshake: dettagli 4. Session Key Exchange session key session key client server Se usiamo D-H: a questo punto una chiave di sessione è già stata scambiata Se usiamo RSA: il client genera una chiave simmetrica (session key) che viene criptata con la chiave pubblica del server e inviata al server, che la decripta con la sua chiave privata Perchè solo il server è sicuramente autenticato! server e client hanno una stessa chiave simmetrica scambiata in modo sicuro

16 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?

17 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

18 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

19 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

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

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

22 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

23 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

24 S/HTTP S/HTTP è un protocollo per la sicurezza delle transazioni che segue strettamente le specifiche HTTP IETF Draft Standard da anni, ma inutilizzato CMS/MOSS (Crypto Message Std / Multipart Obj. Security Std) definiscono gli header per oggetti crittografati Layering di algoritmi e indipendenza (di base usa MD5 per hash, DES-CBC come algoritmo simmetrico, e NIST-DSS per generare le chiavi) Key management: scambio manuale, uso di PKI o di protocolli a chiave pubblica Tutti i browser lo supportano, ma non è mai stato adottato (problema classico di massa critica)

25 Secure Electronic Transaction (SET)

26 Perché SET e non SSL Problema: SSL protegge i dati da terzi, ma costringe il cardholder a dare il numero di c.c. al merchant Soluzione il cliente invia al merchant il message digest dei dati della carta di credito 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?

27 Dual signature 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) La doppia firma è generata creando due message digest, una per ogni parte di messaggio, e creando una firma digitale con i due digest combinati

28 Scenario X vuole comprare un prodotto da Y ad un certo prezzo P. X invia a Y una richiesta (messaggio A) per acquistare il prodotto e, nello stesso tempo, invia un autorizzazione alla propria banca (messaggio B) per autorizzare il pagamento di P nel caso in cui Y accetti la richiesta. X non vuole che la banca veda i dettagli della richiesta, e non vuole che Y veda i dettagli del pagamento (e Y ne è ben contento!) X vuole che il pagamento sia legato all'evasione dell'ordine da parte di Y.

29 Generazione della dual Descr. Ordine signature A B hash function hash function message digest message digest mess. dig. mess. dig. hash function dual sig. mess. dig. Descr. Pagamento criptazione con la chiave privata dell'acquirente

30 Verifica dual signature Merchant Buyer A hash function hash function dual sig. mess. dig. A mess. dig. mess. dig. mess. dig. hash function mess. dig. decripto con chiave pubblica del mittente mess. dig. mess. dig. B hash function dual sig. cripta con chiave privata del mittente mess. dig. hash function mess. dig.

31 Un ulteriore problema Il cardholder deve comunicare soltanto con il merchant il messaggio dovrà contenere ordine di acquisto (destinato al merchant): chiamato OI, order information istruzioni per il pagamento (destinate all'acquirer), chiamato PI, purchase instructions Come impedire all acquirer di vedere il contenuto dell ordine e al merchant di vedere le istruzioni per il pagamento?

32 Preparazione della richiesta Cardholder OI cripta con chiave pubblica del Merchant Msg. dig. PI Encrypted OI dual sig. PI Generazione Dual Signature cripta con chiave pubblica del Payment Gateway Msg. dig. OI Encrypted PI

33 Verifica del Merchant Decr. Pub key merchant Merchant Cardholder Encrypted OI OI Encrypted OI Msg. dig. PI Msg. dig. PI dual sig. hash function Msg. dig. OI dual sig. Unico messaggio decripta con chiave pubblica del cardholder Msg. dig. Msg. dig. OI Msg. dig. PI Msg. dig. OI Encrypted PI Msg. dig. OI hash function Msg. dig. Encrypted PI

34 Autorizzazione al pagamento Merchant Encrypted PI Decr. Pub key Payment GW Payment Gateway PI Issuer dual sig. Msg. dig. OI Msg. dig. OI dual sig. hash function Verifiche su rete interbancaria Encrypted PI TransactionID + $$$$ + Authorization Request 1 decripta con chiave pubblica del cardholder Msg. dig. TransactionID + $$$$ + Msg. dig. PI Msg. dig. PI Msg. dig. OI hash function Msg. dig. check 2 4 Conferma di autorizzazione + Capture Token 3

35 Payment Capture Dopo aver ricevuto l autorizzazione al pagamento, il merchant evade l ordine del cardholder (es. spedisce i prodotti acquistati) In seguito (anche parecchio tempo dopo l evasione dell ordine), il merchant utilizza il capture token per inviare una richiesta di payment capture al Payment Gateway, contenente: Il capture token L ID della transazione Le informazioni d autorizzazione Il payment gateway invia una richiesta di pagamento all issuer, attraverso i normali canali interbancari L issuer invia una risposta di conferma attraverso il sistema interbancario La risposta viene cifrata e inviata al merchant

36 I limiti di SET 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 Tuttavia, ha fornito alcune direttive e soluzioni utili al mondo dell e-commerce che vengono applicate in maniera semplificata nei sistemi comunemente usati per il commercio elettronico

37 Cosa si usa in pratica Cardholder Merchant OI (in chiaro o su SSL) 1 3 OI Generazione richiesta di pagamento TransactionID + $$$$ + Conferma, poi trasmessa al Cardholder Redirect con TransactionID 2 Issuer PI (su SSL) 4 Payment Gateway PI TransactionID + $$$$