E-commerce sicuro Tecnologie per la gestione dei pagamenti su Internet 08/06/04 L. Muttoni S. Zanero Anno Accademico 2003-2004
Le problematiche del pagamento elettronico
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 Muttoni - Zanero Impianti Informatici - A.A. 03/04 3/72
Requisiti generali 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 Muttoni - Zanero Impianti Informatici - A.A. 03/04 4/72
Requisiti più specifici Fornire un sistema sicuro per lo scambio di informazioni (confidenzialità e integrità dei dati) Autenticare mutuamente le parti coinvolte nell operazione (acquirente e venditore, terze parti) Assicurare l atomicità delle operazioni di pagamento e di evasione dell ordine Garantire l interoperabilità delle applicazioni e delle tecnologie (problema della massa critica) Muttoni - Zanero Impianti Informatici - A.A. 03/04 5/72
Problema della massa critica La fiducia di acquirenti e venditori on-line è legata anche alla diffusione dei servizi più numerosi sono gli utilizzatori di un sistema di pagamento on-line, maggiore è la fiducia dei nuovi utenti Definire standard che garantiscano: interoperabilità tra software diversi portabilità su piattaforme diverse Usare il più possibile gli standard già esistenti Muttoni - Zanero Impianti Informatici - A.A. 03/04 6/72
Protocolli sicuri 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 comunicazioni il 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 Muttoni - Zanero Impianti Informatici - A.A. 03/04 7/72
Un acquisto on-line: visione dall esterno 1. l acquirente sfoglia un catalogo on-line di prodotti 2. l acquirente seleziona gli articoli/servizi da acquistare 3. l acquirente seleziona il metodo di pagamento (carta di credito) 4. l acquirente invia al venditore i dettagli dell ordine 5. il venditore richiede alla banca dell acquirente l autorizzazione per il pagamento 6. il venditore invia all acquirente una conferma dell ordine 7. il venditore evade l ordine 8. il venditore richiede il pagamento da parte della banca del cliente Muttoni - Zanero Impianti Informatici - A.A. 03/04 8/72
Architettura di un sistema di pagamento elettronico autenticazione e protezione dei dati payment gateway Bank Bank Network Network Internet customer browser Internet Internet e-commerce web site issuer bank acquirer bank Muttoni - Zanero Impianti Informatici - A.A. 03/04 9/72
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 Muttoni - Zanero Impianti Informatici - A.A. 03/04 10/72
PKI e Certification Authorities
Crittografia asimmetrica: un ripasso Mittente Chiave PUBBLICA destinatario testo messaggio hash function digest crittaz. testo messaggio firma digitale crittazione Chiave PRIVATA destinatario decrittazione Chiave PRIVATA mittente hash function testo messaggio Autenticazione mittente Integrità messaggio Riservatezza messaggio confronto digest digest Ricevente firma digitale decrittaz. Chiave PUBBLICA Muttoni - Zanero Impianti Informatici - A.A. 03/04 mittente 12/72
Problema dell identità del mittente (2) 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-ofband (di persona e mediante dischetto, per esempio) Lo scopo di una PKI (Public Key Infrastructure) è di garantire l associazione chiave pubblicamittente Muttoni - Zanero Impianti Informatici - A.A. 03/04 13/72
Authentication Per poter garantire l identità del mittente, è 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 Muttoni - Zanero Impianti Informatici - A.A. 03/04 14/72
Rilascio di un certificato digitale L utente prova la propria identità alla CA (ad esempio mostrando un documento) La procedura dipende dalla CA ed è ovviamente molto sensibile! La CA crea una coppia di chiavi per l utente (pubblica e privata) A volte per contenere la chiave privata viene utilizzata una smart card 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 Muttoni - Zanero Impianti Informatici - A.A. 03/04 15/72
Certificato digitale proprietario del certificato validità del certificato chiave pubblica dell utente Mario Rossi dal 1/1/2000 all 1/1/2001 QH76H9H5GJ0J2JHAW ente che ha rilasciato il certificato CA firma digitale dell ente che ha rilasciato il certificato Muttoni - Zanero Impianti Informatici - A.A. 03/04 16/72
Certificato digitale (2) hash function informazioni contenute nel certificato chiave pubblica dell utente message digest firma digitale criptazione con la chiave privata dell ente che rilascia il certificato Muttoni - Zanero Impianti Informatici - A.A. 03/04 17/72
Esempio di certificazione del server presso il client X certifica certifica A B certifica certifica PEER 1 PEER 1 PEER 1 manda a PEER 2 un certificato firmato dalla certification authority CA PEER2 PEER 2 Se PEER2 considera CA affidabile PEER2 considera PEER1 affidabile Muttoni - Zanero Impianti Informatici - A.A. 03/04 18/72
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 (de facto) La CA di top level usa un certificato selfsigned Problemi di prestazioni e di gestione delle revoche Muttoni - Zanero Impianti Informatici - A.A. 03/04 19/72
Esempio di gerarchia di Certification Authorities Muttoni - Zanero Impianti Informatici - A.A. 03/04 20/72
Esempio di catena di certificazione Muttoni - Zanero Impianti Informatici - A.A. 03/04 21/72
Esempi di Certification Authorities USA Verisign (http://www.verisign.com/) Svizzera Swisskey (http://www.swisskey.ch/) Germania PCA of the German Research Network (http://www.pca.dfn.de/dfnpca/) Italia Certificatori della firma digitale legale (http://cnipa.gov.it/) CA Dipartimentali Ad es. quella del DEI (https://webmail.elet.polimi.it/) Muttoni - Zanero Impianti Informatici - A.A. 03/04 22/72
Certificati digitali: 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 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 client, server, email firma digitale della CA Muttoni - Zanero Impianti Informatici - A.A. 03/04 23/72
Esempio di Certificato digitale X.509 Muttoni - Zanero Impianti Informatici - A.A. 03/04 24/72
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:25 1997 Not After: Sun Oct 17 18:36:25 1999 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: 65537 (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: Muttoni - Zanero Impianti Informatici - A.A. 03/04 25/72
Esempio di certificato X.509 (2) -----BEGIN CERTIFICATE----- MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK EwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0 dhkwgz8wdqyjkozihvcnaqefbqadgy0amigjaogbamr6ezipgfjx3urjgejmkiqg 7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7L iqzbcrxpc0k4du+2q6xju2mpm/8wkumontuvzpo+sgxelmhvcheqoocwfdizywyz NMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNV HSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBt I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3 UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84 hw3wwehbuqvk5sy4/zj4otjx7dwnmdgwbwfprqjd1a== -----END CERTIFICATE----- Muttoni - Zanero Impianti Informatici - A.A. 03/04 26/72
Firma digitale a valor legale Normata dal D.P.R. 513/97 e successive modificazioni Basata sull uso di certificati X.509 (come da DPCM 8/02/99) a bordo di strumenti di firma hardware (al momento smart card, ma non necessariamente) Rilasciata da certificatori abilitati iscritti nell elenco CNIPA (ex AIPA) e dotati di particolari requisiti (a livello di struttura societaria e di procedure) Ha lo stesso valore di una firma su documento cartaceo, ma non può essere disconosciuta Muttoni - Zanero Impianti Informatici - A.A. 03/04 27/72
Utilizzo e feature 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! Muttoni - Zanero Impianti Informatici - A.A. 03/04 28/72
Secure Socket Layer (SSL)
Introduzione ad SSL È un protocollo di comunicazione per Internet Progettato da Netscape per le comunicazioni sicure via web, è divenuto standard de facto anche per altri protocolli In via di approvazione come standard IETF Garantisce: confidenzialità e integrità autenticazione del server autenticazione del client (opzionale) Utilizza sia crittografia a chiave simmetrica (segreta) sia a chiave asimmetrica (pubblica e privata) Esiste una ottima implementazione free, SSLeay (www.ssleay.org) Muttoni - Zanero Impianti Informatici - A.A. 03/04 30/72
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 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 Muttoni - Zanero Impianti Informatici - A.A. 03/04 31/72
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. Muttoni - Zanero Impianti Informatici - A.A. 03/04 32/72
SSL handshake: overview Session key generation 1. cipher setting 2. cipher setting 2. server public key 3. client public key 4. session key cripted with server public key client server Muttoni - Zanero Impianti Informatici - A.A. 03/04 33/72
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, contenete i cipher setting del client, dei dati generati a caso ed altre informazioni che servono per stabilire la connessione sicura SSL Muttoni - Zanero Impianti Informatici - A.A. 03/04 34/72
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 i suoi cipher setting, dei dati generati a caso, il suo certificato e il server facoltativamente richiede il certificato del client il client autentica il server; se l autenticazione fallisce, la procedura di handshake viene interrotta Muttoni - Zanero Impianti Informatici - A.A. 03/04 35/72
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 ed invia la chiave pubblica (senza certificato) al server Muttoni - Zanero Impianti Informatici - A.A. 03/04 36/72
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 il server decripta la session key con la sua chiave privata server e client hanno una stessa chiave simmetrica scambiata in modo sicuro Muttoni - Zanero Impianti Informatici - A.A. 03/04 37/72
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? Muttoni - Zanero Impianti Informatici - A.A. 03/04 38/72
Attacchi di tipo man-in-the-middle 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 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 falso certificato ma non può farselo firmare dalla CA, oppure il certificato riporta il nome sbagliato! Muttoni - Zanero Impianti Informatici - A.A. 03/04 39/72
SSL handshake con MITM 1. cipher setting 2. cipher setting 3a. fake auth. 3. server auth. 4. client auth. 4a. fake auth. Session key generation 5. session key criptata con fake key 5. session key criptata con server key client MITM server Muttoni - Zanero Impianti Informatici - A.A. 03/04 40/72
Esempio di tentativo di MITM Usiamo dnsspoof per cercare di far risolvere il sito (e.g. www.amazon.com) al computer aggressore (15.1.1.25) C:\>ping www.amazon.com Pinging www.amazon.com [15.1.1.25] with 32 bytes of data: Reply from 15.1.1.25: bytes=32 time<10ms TTL=249 Reply from 15.1.1.25: bytes=32 time<10ms TTL=249 Reply from 15.1.1.25: bytes=32 time<10ms TTL=249 Reply from 15.1.1.25: bytes=32 time<10ms TTL=249 Ora proviamo a usare 15.1.1.25 per fare da proxy e intercettare i dati di pagamento Muttoni - Zanero Impianti Informatici - A.A. 03/04 41/72
Tentativo di MITM (2) Usiamo webmitm di DSNIFF per mandare un certificato falso ecco cosa vede l utente: Muttoni - Zanero Impianti Informatici - A.A. 03/04 42/72
Tentativo di MITM (3) Se anche l utente verifica prima di cliccare ok cosa verifica? Muttoni - Zanero Impianti Informatici - A.A. 03/04 43/72
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 Muttoni - Zanero Impianti Informatici - A.A. 03/04 44/72
S/HTTP S/HTTP è un protocollo per la sicurezza delle transazioni che segue strettamente le specifiche HTTP IETF Draft Standard da anni, ma utilizzato CMS/MOSS (Crypto Message Std / Multipart Obj. Security Std) definiscono gli header per oggetti crittografati Layering di algoritmi e indipendenza (attualmente 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 ci sono implementazioni free Muttoni - Zanero Impianti Informatici - A.A. 03/04 45/72
Secure Electronic Transaction (SET)
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 un certificato digitale che contiene 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 il certificato del cliente al payment gateway il payment gateway verifica la coerenza dei dati Muttoni - Zanero Impianti Informatici - A.A. 03/04 47/72
Architettura di SET certification authority Entità che processa le informazioni dal server del merchant. Internet payment gateway Bank Network cardholder merchant issuer acquirer Muttoni - Zanero Impianti Informatici - A.A. 03/04 48/72
Un ulteriore problema il cardholder vuole comunicare con il merchant e il payment gateway con un unico messaggio il messaggio contiene ordine di acquisto istruzioni per il pagamento l ordine di acquisto sarà utilizzato dal merchant le istruzioni per il pagamento saranno utilizzate dall acquirer si vuole impedire all acquirer di vedere il contenuto dell ordine e al merchant di vedere le istruzioni per il pagamento Muttoni - Zanero Impianti Informatici - A.A. 03/04 49/72
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à). La doppia firma è generata creando due message digest, uno per ogni messaggio, e creando una firma digitale con i due digest combinati. Muttoni - Zanero Impianti Informatici - A.A. 03/04 50/72
Dual signature (2) La società X vuole comprare un prodotto dalla società Y ad un certo prezzo. 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 nel caso in cui Y accetti la richiesta. X non vuole che la propria banca veda i dettagli della richiesta e non vuole che Y veda i dettagli del proprio conto corrente. Inoltre, X vuole che l autorizzazione al pagamento sia legata all accettazione dell offerta da parte di Y. Muttoni - Zanero Impianti Informatici - A.A. 03/04 51/72
Generazione della dual Descr. Ordine signature A B hash function hash function hash function dual sig. criptazione con la chiave privata del mittente Descr. Pagamento Muttoni - Zanero Impianti Informatici - A.A. 03/04 52/72
Verifica del merchant Merchant Buyer A hash function hash function dual sig. A hash function decripto con chiave pubblica del mittente B hash function dual sig. cripta con chiave privata del mittente hash function Muttoni - Zanero Impianti Informatici - A.A. 03/04 53/72
Interazione tra merchant e payment gateway Merchant Buyer A hash function hash function dual sig. A hash function Payment gateway B hash function dual sig. cripta con chiave privata del mittente B dual sig. Muttoni - Zanero Impianti Informatici - A.A. 03/04 54/72
Le fasi di SET Fasi preliminari una tantum: registrazione del cardholder registrazione del merchant richiesta di acquisto autorizzazione al pagamento (authorization) conferma del pagamento (capture) Muttoni - Zanero Impianti Informatici - A.A. 03/04 55/72
Registrazione del cardholder richiesta del certificato della CA certificato della CA firmato richiesta del certificato formulario per ottenere il certificato richiesta del certificato certificato del cardholder cardholder CA Muttoni - Zanero Impianti Informatici - A.A. 03/04 56/72
Registrazione del merchant richiesta del certificato formulario per ottenere il certificato richiesta del certificato certificato del merchant merchant CA Muttoni - Zanero Impianti Informatici - A.A. 03/04 57/72
Dettagli sulla registrazione Ovviamente viene eseguita una tantum È necessaria per generare i certificati ed attribuirli a delle persone fisiche o giuridiche Valgono le osservazioni fatte nel discorso sulla PKI e relative al rilascio di credenziali sotto forma di certificati digitali Muttoni - Zanero Impianti Informatici - A.A. 03/04 58/72
Richiesta di acquisto richiesta del certificato del merchant certificato del merchant richiesta di acquisto fattura digitale firmata cardholder merchant Muttoni - Zanero Impianti Informatici - A.A. 03/04 59/72
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 scadenza Ammontare da pagare L identificativo della transazione L OI è invece destinato al merchant e contiene: L identificativo della transazione La marca della carta La data della transazione SET descrive in modo preciso il formato dei messaggi Viene generata una dual signature per PI e OI Muttoni - Zanero Impianti Informatici - A.A. 03/04 60/72
Generazione della dual PI signature A B hash function hash function hash function dual sig. criptazione con la chiave privata del mittente OI Muttoni - Zanero Impianti Informatici - A.A. 03/04 61/72
Autorizzazione al pagamento richiesta di autorizzazione (comprende i dati del cardholder) autrizzazione firmata merchant payment gateway Muttoni - Zanero Impianti Informatici - A.A. 03/04 62/72
L autorizzazione in dettaglio Il software del merchant controlla il messaggio del buyer e verifica che non siano stati manipolati Il software genera una richiesta di autorizzazione al pagamento, che contiene l identificativo di transazione Il merchant invia al payment gateway un messaggio criptato con la chiave pubblica del gateway stesso, in cui inserisce: La richiesta di autorizzazione Il PI ottenuto dal buyer Il proprio certificato pubblico Muttoni - Zanero Impianti Informatici - A.A. 03/04 63/72
Verifica del merchant Merchant Buyer A hash function hash function dual sig. A hash function decripto con chiave pubblica del mittente B hash function dual sig. cripta con chiave privata del mittente hash function Muttoni - Zanero Impianti Informatici - A.A. 03/04 64/72
L autorizzazione in dettaglio (2) Il payment gateway decripta il messaggio, e controlla le varie componenti per eventuali manipolazioni e verifica che il transaction identifier nella richiesta d autorizzazione coincida con quello nel PI del buyer 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. Muttoni - Zanero Impianti Informatici - A.A. 03/04 65/72
Interazione tra merchant e payment gateway Merchant Buyer A hash function hash function dual sig. A hash function Payment gateway B hash function dual sig. cripta con chiave privata del mittente B dual sig. Muttoni - Zanero Impianti Informatici - A.A. 03/04 66/72
Payment Capture In seguito, 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 Muttoni - Zanero Impianti Informatici - A.A. 03/04 67/72
Conferma del pagamento richiesta di pagamento conferma del pagamanto merchant payment gateway Muttoni - Zanero Impianti Informatici - A.A. 03/04 68/72
Esempi di payment gateway www.bancasella.it www.internetsecure.com www.ibill.com www.cybercash.com www.authorizenet.com www.itransact.com Muttoni - Zanero Impianti Informatici - A.A. 03/04 69/72
Sistemi alternativi a SET SET non è molto diffuso, nonostante sia sostenuto nientemeno che da VISA e MasterCard! ikp architettura molto simile a SET Millicent protocollo molto semplice per pagamenti di piccoli importi NetCash protocollo completo e sicuro DigiCash utilizza smart card Muttoni - Zanero Impianti Informatici - A.A. 03/04 70/72
E-wallet e-wallet è un programma che risiede sul PC del cliente memorizza i dati (ad es. carta di credito) sul hard disk del cliente. Quando il cliente deve fare un acquisto on-line, e-wallet invia automaticamente (?) i dati del cliente al sito del venditore. Esempi: Microsoft Passport, Yodlee, CitiWallet, EntryPoint Muttoni - Zanero Impianti Informatici - A.A. 03/04 71/72
Altri standard e protocolli S/PAY (Secure Payment): toolkit per applicazioni SET, sviluppato da RSA e distribuito da Trintech (www.trintech.com) OFX (Open Financial Exchange): protocollo di Microsoft e altri che usa SSL per fornire servizi di banking e transazioni (www.ofx.net) MPTP (Micro Payment Transfer Protocol): sviluppato dal W3C, altamente flessibile ma ancora in fase di sviluppo JECF (Java Electronic Commerce Framework): un framework per implementare transazioni in Java; flessibile, portabile, e 100% pure Java Muttoni - Zanero Impianti Informatici - A.A. 03/04 72/72