E-commerce sicuro Tecnologie per la gestione dei pagamenti su Internet 02/06/03 02/06/03 P. Cremonesi – L. Muttoni – S. Zanero Anno Accademico 2002 -2003 Le problematiche del pagamento elettronico Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 3/66 Acquisto on-line sicuro • Tipica transazione di commercio elettronico • l’acquirente sfoglia un catalogo di prodotti on-line, seleziona i prodotti da acquistare e invia al venditore i dati della propria carta di credito • il venditore verifica i dati della carta di credito e conferma l’ordine • 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
Transcript
E-commerce sicuro
Tecnologie per la gestione deipagamenti su Internet
02/06/0302/06/03
P. Cremonesi – L. Muttoni – S. ZaneroAnno Accademico 2002 -2003
• Il protocollo IP e i protocolli applicativi web non incorporano elementi di identificazione (anonimità di Internet)
• Il protocollo IP non garantisce la riservatezza• Un sistema di pagamento elettronico sicuro deve
fornire un sostituto valido al rapporto di fiducia che si instaura tra acquirente e venditore negli acquisti tradizionali• Garantire all’acquirente l’identità e la rintracciabilità
del venditore• Garantire al venditore la transazione di pagamento
• Esistono tre protocolli principali che cercano di garantire la sicurezza e la fiducia del pagamento elettronico• SSL (Secure Socket Layer) per HTTP (HTTPs)
☺ sicurezza delle comunicazioniil cliente non ha garanzie sull’uso che il venditore fa dei dati riservati (frode o errore)il venditore non ha garanzie che l’acquirente sia chi dice di essere (carte di credito rubate)
• S/HTTP: Secure HTTP, un altro protocollo per la sicurezza di HTTP
• SET (Secure Electronic Transaction)☺ fiducia tra acquirente e venditore
• La sicurezza con l’utilizzo delle chiavi pubbliche e private è garantita solo se si è sicuri che la chiave pubblica che si sta usando appartiene proprio all’utente che l’ha dichiarata
• Fondamentalmente, non c’è modo 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
• 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 (de facto)• La CA di “top level” usa un certificato “self-
signed”• Problemi di prestazioni e di gestione delle
• Lo standard associa un DN (distinguished name) ad unachiave pubblica
• La struttura di un certificato X.509 è• numero di versione del certificato• serial number del certificato
un numero diverso da qeullo di tutti gli altri certificati• chiave pubblica• DN della certification authority che ha rilasciato il certificato• periodo di validità• DN del proprietario del certificato• tipo di certificato
• Cosa si può fare con la firma digitale:• firmare un contratto (“scrittura privata”)• firmare documenti destinati alla P.A.• applicare una marca temporale a un documento
• Cosa non si può fare:• comprare una casa (l’atto notarile richiede la
presenza)• Per cosa non è utile una firma a valore legale
• per il commercio online: avete mai firmato un contratto per comprare un oggetto al supermercato ?
• per identificarsi verso un server remoto SSL: non avrebbe comunque valore legale !
• SSL funziona in due fasi: • handshake: utilizzando la crittografia asimmetrica
viene scambiato un “segreto” di sessione tra cliente server, da utilizzare per la crittografia simmetrica
• connessione sicura: utilizzando il segreto scambiato durante l’handshake il client e il server possono comunicare in modo sicuro mediante crittografia simmetrica
Cipher setting• Il client e il server possono avere a disposizione diversi
algoritmi per la crittografia a chiave simmetrica e asimmetrica; 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 quali algoritmi di crittografia utilizzare
• Tra gli algoritmi implementati “come minimo”, ci sono DES, RC2, RC4 e IDEA (simmetrici), RSA e DSS (autenticazione), SHA e MD5 (integrità), X.509 (chiavi), Diffie-Hellman e RSA (scambio di chiavi); è inoltre richiesto il supporto per il sistema hardware FORTEZZA.
• il client invia al server una richiesta di connessione SSL, contenete i cipher setting del client, dei dati generati a caso ed altre informazioni che servono per stabilire la connessione sicura SSL
• Un attacco “man-in-the-middle” si verifica quando esiste un computer che può intercettare e manipolare tutte le comunicazioni tra un client e un server
• Questo tipo di attacco pone i maggiori problemi al progettista di protocolli, perché niente può essere considerato sicuro
• Nel caso di SSL, cosa può fare il MITM ?• Intercettando tutte le comunicazioni risponde al client “come se”
fosse il server e comunica con il server “come se” fosse il client !• La corretta verifica di quanto al punto 4 della slide
precedente evita questo attacco, perché il MITM può inviare un falso certificato ma non può farselo firmare dalla CA !
• 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à) e al contempo “legando” tra loro le due parti del messaggio.
• La doppia firma è generata creando due message digest, uno per ogni messaggio, e creando una firma digitale con i due digestcombinati
La richiesta in dettaglio• Il cliente, al momento di pagare, seleziona l’opzione “carta di credito”• Il merchant genera il conto e lo spedisce al buyer per l’approvazione • Il buyer sceglie e inserisce i dati della propria carta• Il software richiede al merchant la chiave pubblica sua e del suo payment
gateway. Il merchant genera una risposta composta da:• Un identificativo della transazione• Il certificato del merchant• Il certificato del payment gateway
• Il buyer verifica i certificati ed invia due pacchetti di informazioni al merchant, l’Order Information packet (OI), e il Purchase Instructions (PI) packet.
• Il PI è criptato con la chiave pubblica del payment gateway perché il merchant non vi acceda, e contiene i dati usati dalla acquiring bank per processare la transazione. Contiene:
Numero di carta e scadenzaAmmontare da pagareL’identificativo della transazione
• L’OI è invece destinato al merchant e contiene:L’identificativo della transazioneLa marca della cartaLa data della transazione
• SET descrive in modo preciso il formato dei messaggi• Viene generata una dual signature per PI e OI
• Il payment gateway decripta il messaggio, e controlla le varie componenti per eventuali manipolazioni e verifica che il transactionidentifier nella richiesta d’autorizzazione coincida con quello nel PI delbuyer
• Il payment gateway invia una richiesta di autorizzazione all’issuer, attraverso i normali canali interbancari
• L’issuer invia una risposta di conferma o di diniego attraverso il sistema interbancario
• Il gateway genera un’appropriata risposta per il merchant, che comprende:
• La risposta dell’issuer• Un capture token
• La risposta viene cifrata e inviata al merchant• Il merchant la decifra e ottiene entrambe le informazioni, salva il capture
token e procede con l’appropriata funzione:• Se la transazione è stata approvata, invia al buyer una conferma dell’acquisto
avvenuto,• Se la transazione è stata rifiutata, invia al buyer un messaggio d’errore.
![[Giornate dell'E-Commerce 2015] Lorenzo Caroli e l'ABCD...E-Commerce](https://static.documenti.site/doc/80x56/58766b591a28abd0018b536f/giornate-delle-commerce-2015-lorenzo-caroli-e-labcde-commerce.jpg)
