Free license available.

Sicurezza nei sistemi di pagamento elettronico

di: Alessandro Lippi

Il protocollo iKP

Introduzione
Impostazioni di base
- Chiavi pubbliche e certificazioni
Flusso dei messaggi
2KP vs. 3KP

Il protocollo iKP (Internet Keyed Payment Protocol), sviluppato dalla IBM, è un prototipo di sistema di pagamento su Internet basato su carta di credito.
È stato la base dello standard SEPP di Mastercard, poi abbandonato in favore del nuovo standard SET, in cooperazione con VISA.

iKP implementa un modello di pagamento di tipo cheque-like.
Anche se le specifiche fornite coprono esclusivamente sistemi di pagamento con carte di credito, IBM tiene a precisare che iKP può facilmente essere usato per implementare un sistema di assegni elettronici.

Introduzione

Nato nei primi mesi del 1995, il protocollo iKP era stato originariamente pensato come contributo alla standardizzazione piuttosto che come una tecnologia di proprietà IBM.

iKP è stato progettato per:

Ottenere un alto livello di integrità per tutte le parti coinvolte, con ciò tenendo conto delle differenze di rischio e di esigenze tra una parte e l'altra.
Fornire riservatezza nelle transazioni economiche.
Lavorare con il minimo impatto sui sistemi finanziari esistenti.
Evitare conflitti con la regolamentazione dell'export negli USA e nelle altre nazioni riguardo l'utilizzo della crittografia.

Pur fornendo quanto necessario per pagamenti sicuri, iKP:

Non consente alcuna trattativa su modalità di pagamento, prezzo ecc.: contiene una semplice procedura di contratto ("offerta/ordine").
Non fornisce la non tracciabilità dei pagamenti (ma protegge dal venditore i dati del compratore).
Non fornisce mezzi per una distribuzione sicura di informazioni: fornisce ricevute di pagamento ma non le protegge.

Impostazioni di base

Come in tutti i sistemi di pagamento elettronico le parti interessate alle transazioni economiche sono: compratore, venditore, acquirente, fornitore. Tuttavia, nel sistema iKP, le parti direttamente coinvolte sono tre: il compratore, il venditore ed il gateway dell'acquirente, come indicato nella seguente Figura.

Figura 1 - Le parti coinvolte nel sistema iKP

Il sistema di pagamento è gestito da un'organizzazione tipo Europay, Mastercard, VISA. Tali enti hanno relazioni fisse di affari con certe banche che agiscono da fornitore di carta di credito per il compratore e da acquirente dei pagamenti per il venditore. Ogni fornitore ha un BIN (Bank Identification Number), che riceve al momento in cui stipula il contratto con l'organizzazione che gestisce il sistema, e che è in rilievo su ogni carta di credito fornita, come parte del numero di carta di credito. Il BIN identifica inoltre l'organizzazione che gestisce il sistema.

È molto importante notare la presenza del gateway (dell'acquirente): tale entità funziona da interfaccia tra il "mondo elettronico" e l'infrastruttura per pagamenti già esistente. Il gateway autorizzerà le transazioni usando proprio tale infrastruttura: la rete commerciale di compensazione/autorizzazione per carte di credito.

Il protocollo sfrutta le solite primitive crittografiche. Per l'autenticazione di un messaggio iKP usa:

Firma digitale.
Codifica dei segreti con protocollo a chiave pubblica di tipo plaintext-aware.

La codifica di tipo plaintext-aware è un modo di operare che assicura l'integrità dei messaggi, ed è sicuro sotto ragionevoli ipotesi. Al contrario della firma digitale, tale metodo non consente la risoluzione di contestazioni.

Per la riservatezza, iKP sfrutta due meccanismi:

I dati segreti che devono essere verificati dal destinatario ma che non necessitano di essere trasmessi, sono nascosti sfruttando funzioni salted hash (per esempio un numero N può essere nascosto nella funzione h(N,x), dove x è un valore random noto a mittente e destinatario).
Codifica a chiave pubblica di tipo plaintext-aware.

iKP limita la codifica a quei dati che l'acquirente deve ricevere dal compratore per avviare il pagamento (per esempio il numero di carta di credito) e a quei dati che consentono l'autentifica del compratore (come PIN o valori random usati nelle funzioni hash). Tali tipi di restrizioni vengono applicate fondamentalmente per rispettare le leggi sull'export degli USA, ma non riducono il grado di sicurezza di iKP.
Infatti, dal momento che tutte le parti possono firmare, e visto che i dati usati per identificare il compratore non sono utilizzabili per pagamenti senza la firma digitale del compratore stesso, non esisterebbe la necessità di alcuna codifica.
Il motivo per cui iKP utilizza la codifica anche se il compratore sfrutta la firma elettronica dipende dal fatto che in Internet i dati di una carta di credito possono essere usati come in transazioni commerciali ordinarie. Attualmente, tali dati sono sufficienti per avviare transazioni di tipo MOTO. Il compratore non è responsabile per tali transazioni; tuttavia, transazioni contraffatte sono fonte di problemi sia per il compratore che per il mercante che le ha accettate.

Esistono tre varianti del protocollo iKP, identificate dal valore dell'indice i presente nel nome.
In 1KP solo l'acquirente può firmare digitalmente messaggi (cioè solo l'acquirente possiede una coppia di chiavi pubblica e privata).
In 2KP anche il venditore può firmare (esistono due proprietari di coppie di chiavi).
In 3KP anche il compratore può firmare (esistono tre proprietari di coppie di chiavi).

Tutti i protocolli iKP possono essere implementati sia via software che via hardware. In 1KP e 2KP il cliente non necessita di un dispositivo di pagamento personalizzato: per completare un pagamento bastano il numero di carta di credito e il PIN (se presente). Comunque, per garantire maggiore sicurezza, è raccomandabile l'utilizzo di dispositivi anti-frode che proteggano il PIN e, nel caso 3KP, la chiave segreta del cliente.
È importante sottolineare ancora che lo scopo dei protocolli iKP è quello di abilitare ai pagamenti. iKP non si preoccupa di gestire come l'ordine venga inoltrato; iKP assume che l'ordine, incluso il prezzo, sia già stato concordato fra compratore e venditore.
Inoltre, iKP non consente alcuna codifica dei dati relativi all'ordine. Si suppone che tale tipo di protezione sia fornita da altri protocolli esistenti, come SHTTP e SSL.

Il prototipo iKP supporta solo i protocolli 2KP e 3KP; questo perché 1KP, pur essendo un protocollo molto semplice, non permette la risoluzione di contestazioni tra compratore e venditore.

Chiavi pubbliche e certificazioni

Dal momento che tutti i protocolli iKP sono basati su crittografia a chiave pubblica, si rende necessario un meccanismo per autenticare tali chiavi pubbliche. Si assume l'esistenza di un'Autorità di Certificazione, AC, con la propria chiave segreta, CS_AC. La rispettiva chiave pubblica, CP_AC, è distribuita a tutte le altre parti. L'autorità di certificazione autenticherà la chiave pubblica della parte X firmando la coppia (X, CP_X), cioè l'identità di X e la sua chiave pubblica. Tale firma è calcolata sfruttando la CS_AC. È da notare che la CP_AC deve essere distribuita in modo sicuro alle altri parti; tipicamente questo si ottiene con comunicazioni "fuori banda".

In tutti i protocolli iKP, dunque, l'acquirente A ha la propria chiave segreta, CS_A, che abilita alla firma e alla decodifica. La corrispondente chiave pubblica, CP_A, (che abilita alla verifica della firma e la codifica) è posseduta, insieme al corrispondente certificato rilasciato dall'autorità di certificazione, da ogni venditore accreditato.

Il prototipo iKP ha attualmente un'interfaccia verso un "manager di certificati", cioè è indipendente da come i certificati appaiano o siano trattati. L'attuale sistema di certificazione usato nel prototipo è una soluzione non standard progettata per lavorare in un ambiente di prova.

Flusso dei messaggi

La figura seguente mostra il flusso di messaggi per 2KP e 3KP

Figura 2 - Il flusso dei messaggi in 2KP e 3KP

Ancora prima del passo 1, compratore e venditore devono aver concordato i termini della transazione:

La somma da pagare. In iKP l'ammontare di una transazione non è mai trasmesso in chiaro.
Una descrizione della transazione alla quale il pagamento sarà collegato, per esempio l'indicazione dei beni o servizi richiesti, dell'indirizzo di consegna ecc. Tali dati sono nascosti all'acquirente con funzioni salted hash.

Ecco la descrizione dei vari passi del protocollo iKP:

Avvio: contiene l'identità del compratore (calcolata con una funzione salted hash del numero di conto del compratore), l'identificativo della marca della merce, e l'identificativo di transazione usato dal compratore (che si suppone non richieda protezione confidenziale).
Ricevuta: è l'offerta del venditore al compratore. Contiene l'identità del mercante e un identificatore di transazione, la data corrente, una data di scadenza, e i certificati dell'acquirente. Questi dati, l'identità del compratore specificata al passo 1, l'importo e una funzione hash della descrizione della transazione sono gli elementi su cui compratore, venditore e acquirente devono essersi messi d'accordo. Perciò la documentazione di tali dati è chiamata common. Il passo 2 contiene una funzione hash del common calcolata dal venditore, che permette al compratore di verificare se lui stesso e il venditore concordino sui termini della transazione in corso.

In 1KP, tale "ricevuta" non è autenticata: è dunque facile generare turbativa aprendo in Internet un negozio completamente fasullo che richiede pagamenti, anche se sembra non ci possa essere un beneficio finanziario diretto in tale tipo di attacco: sicuramente un venditore inesistente non potrà mai guadagnare da questi pagamenti.

In 2KP e 3KP la "ricevuta" è firmata, e include i certificati del venditore. In questo caso "ricevuta" può essere interpretata come un'offerta (come specificato nella descrizione) valida per un certo tempo, e il pagamento (passo 3) può essere interpretato come un ordine.

I passi 1 e 2 possono essere omessi per favorire la situazioni in cui gli ordini vengano inoltrati via e-mail, e cioè nel caso in cui compratore e venditore non comunichino in tempo reale. In questo caso i dati del venditore necessari per impostare il pagamento devono essere reperiti da un catalogo, da un CD-ROM, ecc.
Pagamento: contiene i dati del pagamento in corso, corrispondenti allo scontrino di una carta di credito (o ad un assegno) nel mondo fisico.
I dati che non devono essere rivelati al venditore sono codificati con la chiave pubblica dell'acquirente: il numero di carta di credito, la data di scadenza, il salt usato nella codifica dell'identità al passo 1 e, facoltativamente, i dati di autenticazione del compratore (PIN o passphrase). In aggiunta, tale "pagamento" contiene l'ammontare della transazione, una funzione hash della descrizione e una funzione hash del common calcolata dal compratore (che deve essere uguale a quella calcolata dal venditore al passo 2). Questo campo codificato è chiamato slip (scontrino).
In 3KP, tale "pagamento" è firmato e include il certificato del compratore. Per ragioni di riservatezza, questo certificato include i dati del compratore (numero di carta di credito, data di scadenza) solo sotto forma di funzione salted hash. I dati attuali e il salt sono inclusi nello slip codificato.
Il venditore potrà controllare il certificato e la firma, ma non il contenuto dello slip codificato che alla fine determina la validità del pagamento.
In 2KP tale "pagamento" è autenticato solo per mezzo delle parti segrete dello slip.
Richiesta di autorizzazione: è il messaggio con il quale il venditore chiede all'acquirente di autorizzare il pagamento. L'autorizzazione fornisce al venditore la garanzia che il compratore ha denaro sufficiente.

Il passo 4 è una combinazione del passo 2 e del passo 3. L'acquirente può compilare il common dopo aver decodificato lo slip, e controllare se tutte le parti concordino sul common confrontando i valori hash presenti nello slip (calcolati dal compratore), quelli presenti nella ricevuta (calcolati dal venditore) e il valore calcolato dal gateway dell'acquirente stesso. Implicitamente questo comporta il verificare se compratore e venditore concordino sull'hash della descrizione, cioè sulla descrizione stessa, senza rivelare il contenuto di tale descrizione all'acquirente.
Il gateway o la rete finanziaria hanno la responsabilità di scoprire eventuali doppie copie di richiesta di autorizzazione.
Risposta alla richiesta di autorizzazione: è la risposta dell'acquirente alla richiesta del passo 4. È firmata.
Riscontro: è una ricevuta firmata che il venditore fornisce opzionalmente al compratore. Un riscontro positivo (conferma) è spedito dopo un'autorizzazione accordata. Eventualmente tale conferma può contenere la risposta dell'acquirente alla richiesta di autorizzazione. Un riscontro negativo (rifiuto) indica che il pagamento non è o non sarà autorizzato/compensato.
Richiesta di compensazione: è il messaggio con cui il venditore chiede all'acquirente di operare il pagamento, e fa riferimento al passo 5. La somma da compensare può essere differente dalla somma autorizzata.
La richiesta di compensazione è firmata dal venditore.
Al gateway è affidato il compito di scoprire eventuali duplicati. Il fornitore è responsabile per la verifica dell'ammontare compensato (in relazione all'ammontare specificato dallo slip del compratore e all'ammontare precedentemente autorizzato).
Risposta alla richiesta di compensazione: è la risposta dell'acquirente alla richiesta del passo 7. È firmata.

A/B. Informazioni/Stato: sono semplici messaggi che consentono al compratore di chiedere al venditore informazioni sullo stato del pagamento.

2KP vs. 3KP

Le differenze tra 2KP e 3KP sono evidenti:

In 3KP il compratore è responsabile solo per gli ordini di pagamento da lui firmati.
In 2KP con passphrase segreta nello slip (2KP⁺), l'acquirente può facilmente falsificare ordini di pagamento, e non esiste alcun modo di provarlo. Esiste sicurezza verso esterni, anche per passphrase relativamente corte (come PIN, per esempio), dal momento che non sono possibili attacchi tipo del dizionario.
In 2KP senza segreto (2KP^-) chiunque conosca i dati del pagamento può effettuare pagamenti falsi (anche se 2KP^- è leggermente più affidabile delle transazioni MOTO, dal momento che il venditore non riceve i dati del pagamento).

Explore the TELEMAT Site !!!