E-commerce sicuro. Le problematiche del pagamento elettronico. Acquisto on-line sicuro. Tecnologie per la gestione dei pagamenti su Internet

Transcript

1 E-commerce sicuro Tecnologie per la gestione dei pagamenti su Internet 02/06/03 P. Cremonesi L. Muttoni S. Zanero Anno Accademico 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 3/66

2 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 4/66 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) Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 5/66 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 6/66

3 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 7/66 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 8/66 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 9/66

4 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 10/66 PKI e Certification Authorities Crittografia asimmetrica: un ripasso testo messaggio digest Mittente crittaz. testo messaggio firma digitale Chiave PUBBLICA destinatario crittazione Chiave PRIVATA destinatario decrittazione Chiave PRIVATA mittente testo messaggio Autenticazione mittente confronto digest firma digitale Integrità messaggio digest decrittaz. Riservatezza messaggio Ricevente Chiave PUBBLICA mittente Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 12/66

5 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 13/66 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 14/66 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 15/66

6 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 16/66 Certificato digitale (2) informazioni contenute nel certificato chiave pubblica dell utente message digest firma digitale criptazione con la chiave privata dell ente che rilascia il certificato Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 17/66 Esempio di certificazione del server presso il client X certifica certifica certifica A B 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 18/66

7 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 19/66 Esempio di gerarchia di Certification Authorities Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 20/66 Esempio di catena di certificazione Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 21/66

8 Esempi di Certification Authorities Provider commerciali internazionali Verisign ( CA riconosciute da AIPA (firma digitale a valore legale) Elenco completo su CA dipartimentali Per una singola azienda, p.es. il CED del Politecnico per i suoi dipendenti Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 22/66 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, firma digitale della CA Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 23/66 Esempio di Certificato digitale X.509 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 24/66

9 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: Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 25/66 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----- Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 26/66 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 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 27/66

10 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! Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 28/66 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) Utilizza sia crittografia a chiave simmetrica (segreta) sia a chiave asimmetrica (pubblica e privata) Esiste una ottima implementazione free, SSLeay ( Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 30/66

11 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 31/66 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. Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 32/66 SSL handshake: overview 1. cipher setting 2. cipher setting 2. server public key 3. client public key Session key generation 4. session key cripted with server public key client server Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 33/66

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, contenete i cipher setting del client, dei dati generati a caso ed altre informazioni che servono per stabilire la connessione sicura SSL Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 34/66 SSL handshake: dettagli 2. Connection Response server cipher settings server random data server authentication client server certificate client certificate request 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 35/66 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 36/66

13 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 37/66 SSL handshake: server autentication CA public key CA public key CA name CA name CA public key CA public key CA name CA name client trusted CA server public key certificate validity period server domain name CA name digital signature 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? Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 38/66 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 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! Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 39/66

14 SSL handshake con MITM 1. cipher setting 2. cipher setting 3a. fake auth. 3. server auth. Session key generatio n 4. client auth. 5. session key criptata con fake key 4a. fake auth. 5. session key criptata con server key client MITM server Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 40/66 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 41/66 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, 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 42/66

15 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 44/66 Architettura di SET certification authority Entità che processa le informazioni dal server del merchant. Internet payment gateway Bank Network cardholder merchant issuer acquirer Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 45/66

16 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 46/66 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à) 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 digest combinati Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 47/66 Generazione della dual signature Descr. Ordine A B criptazione con la chiave privata del mittente Descr. Pagamento Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 48/66

17 Verifica del merchant Merchant Buyer A A decripto con chiave pubblica del mittente B cripta con chiave privata del mittente Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 49/66 Buyer Interazione tra merchant e payment gateway Merchant A A Payment gateway B cripta con chiave privata del mittente B Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 50/66 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) Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 51/66

18 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 52/66 Registrazione del merchant richiesta del certificato formulario per ottenere il certificato richiesta del certificato certificato del merchant merchant CA Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 53/66 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 54/66

19 Richiesta di acquisto richiesta del certificato del merchant certificato del merchant richiesta di acquisto fattura digitale firmata cardholder merchant Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 55/66 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 56/66 Generazione della dual signature PI A B criptazione con la chiave privata del mittente OI Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 57/66

20 Autorizzazione al pagamento richiesta di autorizzazione (comprende i dati del cardholder) autrizzazione firmata merchant payment gateway Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 58/66 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 59/66 Verifica del merchant Merchant Buyer A A decripto con chiave pubblica del mittente B cripta con chiave privata del mittente Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 60/66

21 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. Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 61/66 Buyer Interazione tra merchant e payment gateway Merchant A A Payment gateway B cripta con chiave privata del mittente B Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 62/66 Conferma del pagamento richiesta di pagamento conferma del pagamanto merchant payment gateway Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 63/66

22 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 64/66 Esempi di payment gateway Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 65/66 Altri standard e protocolli SET è molto diffuso, anche perchè sostenuto nientemeno che da VISA e MasterCard! Esistono tuttavia altri standard e toolkit che vanno menzionati: S/PAY (Secure Payment): toolkit per applicazioni SET, sviluppato da RSA e distribuito da Trintech ( OFX (Open Financial Exchange): protocollo di Microsoft e altri che usa SSL per fornire servizi di banking e transazioni ( 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 Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 66/66