Tecnologie per la gestione dei pagamenti su...

E-commerce sicuro

Tecnologie per la gestione deipagamenti su Internet

08/06/0408/06/04

L. Muttoni – S. ZaneroAnno Accademico 2003 -2004

Le problematiche del pagamento elettronico

Muttoni - Zanero Impianti Informatici - A.A. 03/04 3/72

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


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


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)


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


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


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


Architettura di un sistema di pagamento elettronico

customerbrowser

autenticazione e protezione dei dati

e-commerceweb site

paymentgateway

issuer bank

acquirerbankInternetInternet

BankNetworkBank

Network

Internet


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


Ricevente

Mittentetesto

messaggio

hashfunction

digest crittaz.

crittazione

decrittazione

testomessaggio

firma digitale

testomessaggio

firma digitale

hashfunction

decrittaz.

digest••Autenticazione mittenteAutenticazione mittente••IntegritIntegritàà messaggiomessaggio••Riservatezza messaggioRiservatezza messaggio

digest

Crittografia asimmetrica: un ripasso

Chiave PUBBLICA destinatario

Chiave PUBBLICA mittente

Chiave PRIVATA destinatario

Chiave PRIVATA mittente

confronto


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


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


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


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


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…


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


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


Esempio di gerarchia di Certification Authorities


Esempio di catena di certificazione


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/)


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


Esempio di Certificato digitale X.509


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:


Esempio di certificatoX.509 (2)

-----BEGIN CERTIFICATE-----MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzERMA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEwMTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQKEwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0dHkwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7LiQZBcrXpc0k4du+2Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZNMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNVHSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBtI6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A==-----END CERTIFICATE-----


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 CNIPA (ex AIPA) e dotati di particolari requisiti (a livello di strutturasocietaria e di procedure)

• Ha lo stesso valore di una firma su documentocartaceo, ma non può essere “disconosciuta”


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)


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)


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


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.


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


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


• 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


2. Connection Response


• 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


3. Client Authentication


• 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


4. Session Key Exchange


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


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 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!


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 key

generation

Session key

generation

3a. fake auth.

4a. fake auth.

5. session key criptata con server key

MITM


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=249Reply from 15.1.1.25: bytes=32 time<10ms TTL=249Reply from 15.1.1.25: bytes=32 time<10ms TTL=249Reply 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…


Tentativo di MITM (2)• Usiamo “webmitm” di DSNIFF per mandare un

certificato falso… ecco cosa vede l’utente:


Tentativo di MITM (3)

• Se anchel’utente verificaprima di cliccareok… cosaverifica ?


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


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)


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


Architettura di SET

cardholder merchant

paymentgateway

issuer acquirer

certificationauthority

InternetBank

Network

Entità che processa le informazioni dal

server del merchant.


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


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


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


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


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.


Interazione tra merchant e payment gateway

A

B

hashfunction

hashfunction

mess. dig.

mess. dig.

hashfunction

mess. dig.


dual sig.

A

B

dual sig.

dual sig.

mess. dig.

mess. dig.

hashfunction

mess. dig.

Buyer

mess. dig.

Merchant

Payment gateway


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)


Registrazione del cardholder

richiesta del certificato della CA

cardholder CA

certificato della CA firmato

richiesta del certificato

formulario per ottenere il certificato


certificato del cardholder


Registrazione del merchant

merchant CA


formulario per ottenere il certificato


certificato del merchant


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


Richiesta di acquisto

cardholder merchant

richiesta del certificato del merchant

certificato del merchant

richiesta di acquisto

fattura digitale “firmata”


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


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


Autorizzazione al pagamento

merchant payment gateway

richiesta di autorizzazione(comprende i dati del cardholder)

autrizzazione firmata


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


Verifica del merchant

A

B

hashfunction

hashfunction

mess. dig.

mess. dig.

hashfunction

mess. dig.


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.


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


Interazione tra merchant e payment gateway

A

B

hashfunction

hashfunction

mess. dig.

mess. dig.

hashfunction

mess. dig.


dual sig.

A

B

dual sig.

dual sig.

mess. dig.

mess. dig.

hashfunction

mess. dig.

Buyer

mess. dig.

Merchant

Payment gateway


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


Conferma del pagamento

merchant payment gateway

richiesta di pagamento

conferma del pagamanto


Esempi dipayment gateway

• www.bancasella.it• www.internetsecure.com• www.ibill.com• www.cybercash.com• www.authorizenet.com• www.itransact.com


Sistemi alternativi a SET

• SET non è molto diffuso, nonostante sia sostenutonientemeno 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


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


Altri standard e protocolli

• S/PAY (Secure Payment): toolkit per applicazioniSET, 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”

Tecnologie per la gestione dei pagamenti su...

Documents

Transcript of Tecnologie per la gestione dei pagamenti su...