e-commerce sicuro
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
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
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 4/66
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 5/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 6/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 7/66
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 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
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 8/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 9/66
Architettura di un sistema di pagamento elettronico
customerbrowser
autenticazione e protezione dei dati
e-commerceweb site
paymentgateway
issuer bank
acquirerbankInternetInternet
BankNetworkBank
Network
Internet
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 10/66
Glossario• cardholder: è il cliente
che esegue acquisti on-line 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
PKI e CertificationAuthorities
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 12/66
Ricevente
Mittentetesto
messaggio
hashfunction
digest crittaz.
crittazione
decrittazione
testomessaggio
firma digitale
testomessaggio
firma digitale
hashfunction
decrittaz.
digest••Autenticazione mittenteAutenticazione mittente••Integrità messaggioIntegrità messaggio••Riservatezza messaggioRiservatezza messaggio
digest
Crittografia asimmetrica: un ripasso
Chiave PUBBLICA destinatario
Chiave PUBBLICA mittente
Chiave PRIVATA destinatario
Chiave PRIVATA mittente
confronto
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 13/66
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-of-band (di persona e mediante dischetto, per esempio)
• Lo scopo di una PKI (Public Key Infrastructure) è di garantire l’associazione chiave pubblica-mittente
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 14/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 15/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 16/66
Certificato digitale
Mario Rossiproprietario del certificato
dal 1/1/2000 all’1/1/2001
QH76H9H5GJ0J2JHAW
…
CA
validità del certificato
chiave pubblica dell’utente
ente che ha rilasciato il certificato
firma digitale dell’ente che ha rilasciato il certificato
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 17/66
Certificato digitale (2)
informazioni contenutenel certificato
firma digitale
hash function
message digest
criptazione con la chiaveprivata dell’ente
che rilascia il certificato
…chiave pubblica
dell’utente…
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 18/66
Esempio di certificazione del server presso il client
PEER 1• PEER 1 manda a
PEER 2 un certificato firmato dalla certification authorityCA
PEER 2• Se PEER2 considera
CA affidabile⇓
• PEER2 considera PEER1 affidabile
PEER 1 PEER2
A B
Xcertifica certifica
certificacertifica
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 19/66
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 “self-
signed”• Problemi di prestazioni e di gestione delle
revoche
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 20/66
Esempio di gerarchia di Certification Authorities
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 21/66
Esempio di catena di certificazione
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 22/66
Esempi di Certification Authorities
• Provider commerciali internazionali• Verisign (www.verisign.com)
• CA riconosciute da AIPA (firma digitale a valore legale)• Elenco completo su www.aipa.it
• 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 23/66
Certificati digitali:standard X.509
• 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
client, server, email• firma digitale della CA
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 24/66
Esempio di Certificato digitale X.509
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 25/66
Esempio di certificatoX.509
Certificate:Data:Version: v3 (0x2)Serial Number: 3 (0x3)Signature Algorithm: PKCS #1 MD5 With RSA EncryptionIssuer: OU=Ace Certificate Authority, O=Ace Industry, C=USValidity:Not Before: Fri Oct 17 18:36:25 1997Not After: Sun Oct 17 18:36:25 1999Subject Public Key Info:Algorithm: PKCS #1 RSA EncryptionPublic 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 TypeCertified Usage: SSL ClientIdentifier: Authority Key IdentifierCritical: noKey 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 EncryptionSignature: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 26/66
Esempio di certificatoX.509 (2)
-----BEGIN CERTIFICATE-----MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzERMA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEwMTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQKEwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0dHkwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7LiQZBcrXpc0k4du+2Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZNMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNVHSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBtI6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A==-----END CERTIFICATE-----
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 27/66
Firma digitale a valor legale
• Normata dal D.P.R. 513/97 e successive modificazioni
• Basata sull’uso di certificati X.509 (come daDPCM 8/02/99) a bordo di strumenti di firma hardware (al momento smart card, ma non necessariamente)
• Rilasciata da certificatori abilitati iscrittinell’elenco AIPA e dotati di particolari requisiti (a livello di struttura societaria e di procedure)
• Ha lo stesso valore di una firma su documentocartaceo, ma non può essere “disconosciuta”
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 28/66
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 !
Secure Socket Layer(SSL)
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 30/66
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(www.ssleay.org)
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 31/66
Fasi di SSL
• 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
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 32/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 33/66
SSL handshake: overview
client server
1. cipher setting
2. cipher setting
2. server public key
4. session keycripted with server public key
3. client public key
Session key
generation
Session key
generation
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 34/66
SSL handshake: dettagli
1. Connection Request
• 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
client server
SSL connection request
client cipher settings
client random data
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 35/66
• 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
server cipher settings
server random data
server certificate
client certificate requestserver
authentication
client server
SSL handshake: dettagli
2. Connection Response
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 36/66
• 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
clientauthentication
client certificate
client server
SSL handshake: dettagli
3. Client Authentication
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 37/66
• 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
session key
client server
session key
SSL handshake: dettagli
4. Session Key Exchange
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 38/66
SSL handshake: server autentication
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?
client trusted CA server certificate
server public key
certificate validity period
server domain name
CA name
CA public key
CA name
CA public key
CA name
CA public key
CA name
CA public key
CA namedigital signature
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 39/66
Attacchi di tipoman-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 40/66
SSL handshake con MITM
client server
1. cipher setting
2. cipher setting
3. server auth.
5. session key criptata con
fake key
4. client auth.Session
keygeneratio
n
Session key
generation
3a. fake auth.
4a. fake auth.
5. session key criptata con server key
MITM
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 41/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
TCP/IP
SSL
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 42/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 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”
SecureElectronic Transaction
(SET)
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 44/66
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 paymentgateway (di cui si fida)
• il merchant invia il certificato del cliente al paymentgateway
• il payment gateway verifica la coerenza dei dati
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 45/66
Architettura di SET
cardholder merchant
paymentgateway
issuer acquirer
certificationauthority
InternetBank
Network
Entità che processa le informazioni dal
server del merchant.
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 46/66
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 47/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 digestcombinati
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 48/66
Generazione della dual signature
A
B
hashfunction
hashfunction
mess. dig.
mess. dig.
mess. dig.mess. dig.
hashfunction
mess. dig.
criptazione con la chiaveprivata del mittente
dual sig.
Descr.Ordine
Descr.Pagamento
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 49/66
Verifica del merchant
A
B
hashfunction
hashfunction
mess. dig.
mess. dig.
hashfunction
mess. dig.
cripta con chiaveprivata del mittente
dual sig.
A
dual sig.
mess. dig.
hashfunction
mess. dig.
Buyer
Merchant
decripto conchiave pubblica
del mittente
mess. dig.
mess. dig.
mess. dig.
hashfunction
mess. dig.
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 50/66
Interazione tra merchant e payment gateway
A
B
hashfunction
hashfunction
mess. dig.
mess. dig.
hashfunction
mess. dig.
cripta con chiaveprivata del mittente
dual sig.
A
B
dual sig.
dual sig.
mess. dig.
mess. dig.
hashfunction
mess. dig.
Buyer
mess. dig.
Merchant
Payment gateway
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 51/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 52/66
Registrazione del cardholder
richiesta del certificato della CA
cardholder CA
certificato della CA firmato
richiesta del certificato
formulario per ottenere il certificato
richiesta del certificato
certificato del cardholder
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 53/66
Registrazione del merchant
merchant CA
richiesta del certificato
formulario per ottenere il certificato
richiesta del certificato
certificato del merchant
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 54/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 discorsosulla PKI e relative al rilascio di credenzialisotto forma di certificati digitali
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 55/66
Richiesta di acquisto
cardholder merchant
richiesta del certificato del merchant
certificato del merchant
richiesta di acquisto
fattura digitale “firmata”
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 56/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 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
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 57/66
Generazione della dual signature
A
B
hashfunction
hashfunction
mess. dig.
mess. dig.
mess. dig.mess. dig.
hashfunction
mess. dig.
criptazione con la chiaveprivata del mittente
dual sig.
PI
OI
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 58/66
Autorizzazione al pagamento
merchant payment gateway
richiesta di autorizzazione(comprende i dati del cardholder)
autrizzazione firmata
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 59/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 60/66
Verifica del merchant
A
B
hashfunction
hashfunction
mess. dig.
mess. dig.
hashfunction
mess. dig.
cripta con chiaveprivata del mittente
dual sig.
A
dual sig.
mess. dig.
hashfunction
mess. dig.
Buyer
Merchant
decripto conchiave pubblica
del mittente
mess. dig.
mess. dig.
mess. dig.
hashfunction
mess. dig.
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 61/66
L’autorizzazione in dettaglio (2)
• 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.
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 62/66
Interazione tra merchant e payment gateway
A
B
hashfunction
hashfunction
mess. dig.
mess. dig.
hashfunction
mess. dig.
cripta con chiaveprivata del mittente
dual sig.
A
B
dual sig.
dual sig.
mess. dig.
mess. dig.
hashfunction
mess. dig.
Buyer
mess. dig.
Merchant
Payment gateway
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 63/66
Conferma del pagamento
merchant payment gateway
richiesta di pagamento
conferma del pagamanto
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 64/66
Payment Capture
• In seguito, il merchant utilizza il capture tokenper 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 65/66
Esempi dipayment gateway
• www.bancasella.it• www.internetsecure.com• www.ibill.com• www.cybercash.com• www.authorizenet.com• www.itransact.com
Cremonesi/Muttoni/Zanero Impianti Informatici - A.A. 02/03 66/66
Altri standard e protocolli
• SET è molto diffuso, anche perchè sostenuto nientemenoche da VISA e MasterCard !
• Esistono tuttavia altri standard e toolkit che vannomenzionati:• 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