SET (Secure Electronic Transaction) e forme di pagamento

Formalizzato nel 1997, il protocollo SET è dovuto alla collaborazione di varie aziende del settore (Microsoft, IBM, Netscape, RSA, GTE, VISA, Mastercard, e altre) con l’obiettivo di rendere sicuri al massimo i pagamenti in rete con carte di credito.

 
[adsense:block:adcontenuto]
 
Gli obiettivi che il protocollo si prefigge sono:
 
  • · Riservatezza ottenuta mediante cifratura simmetrica dei dati sensibili ed in particolare del numero di carta di credito;
  • · Integrità ottenuta mediante firma digitale;
  • · Autenticazione dell’acquirente firma e certificato garantiscono il venditore dell’identità dell’acquirente e della validità della carta di credito in suo possesso;
  • · Autenticazione del venditore firma e certificato garantiscono l’acquirente dell’identità del venditore e della sua affidabilità;

 

Oltre agli attori già elencati nel caso di Telepay Light, è coinvolto nel processo di pagamento anche il Servizio di Pagamento (Payment Gateway) che è un dispositivo HW/SW che elabora le istruzioni di pagamento inviate dall’Acquirer. Tra i certificati coinvolti, quello dell’acquirente è emesso e firmato da un istituto finanziario (che funge quindi da AC) di cui l’acquirente è cliente; non contiene in chiaro i dati della carta di credito ma solo una impronta di questi, in modo che i dati stessi non siano ricavabili dal certificato, ma a chiunque vengano esplicitamente forniti dall’acquirente, questi possono essere collegati al certificato mediante confronto delle impronte.

 
Esiste una forma ridotta di SET che non richiede questo certificato. Il certificato del venditore è solitamente emesso e firmato dall’Acquirer che in questo modo garantisce sull’identità del venditore e sulla possibilità di gestire correttamente le istruzioni di pagamento.
 
[adsense:block:adcontenuto]
 
Si prevede che ogni partecipante disponga di due coppie di chiavi pubblica/privata, una riservata a firmare i dati (chiavi di firma), l’altra a proteggere lo scambio delle chiavi per gli algoritmi simmetrici di cifratura (chiavi di scambio), cui corrispondono i relativi ertificati. Un pagamento si svolge attraverso due fasi: la richiesta di acquisto e l’autorizzazione di pagamento, gestite dai software utilizzati dai diversi attori in gioco.
 
Fasi della richiesta di acquisto:
  • 1. L’acquirente invia al venditore l’informazione relativa al tipo di carta che intende usare.
  • 2. In risposta a questa prima richiesta, il venditore invia all’acquirente un identificatore univoco assegnato alla transazione (TI), il proprio certificato per le chiavi di firma e quello del Payment Gateway per le chiavi di scambio, entrambi corrispondenti al tipo di carta comunicato.
  • 3. Dopo aver verificato i certificati ricevuti, l’acquirente crea, aggiungendovi in entrambi il TI, gli estremi d’ordine (order information – OI), e gli ordini di pagamento (Payment Instruction – PI), questi secondi contenenti i dati della carta di credito. Le impronte degli OI e dei PI vengono concatenate, dalla concatenazione viene poi ricavata un’unica impronta, quest’ultima cifrata con la chiave privata dell’acquirente (quella di firma) a costituire una specie di ‘firma doppia’. Viene quindi generata una chiave simmetrica casuale che viene usata per cifrare PI, l’impronta di OI e la firma complessiva prima calcolata. PI firmati e cifrati, e chiave simmetrica vengono cifrati con la chiave pubblica del Payment Gateway (quella di scambio). L’acquirente invia al venditore quest’ultima informazione cifrata assieme agli OI, all’impronta dei PI, alla sua firma ‘doppia’ e al suo certificato di firma.
  • 4. Il venditore, verificato il certificato dell’acquirente, può verificare l’integrità del messaggio: calcola l’impronta di OI, la concatena con l’impronta di PI (che non deve e non può calcolare) ricevuta, calcola l’impronta di questa concatenazione e la confronta con quella ricevuta in modo cifrato come firma ‘doppia’ (la decifrazione è possibile grazie alla chiave pubblica dell’acquirente contenuta nel suo certificato ricevuto). Se quest’ultimo confronto dà esito positivo, il messaggio è integro. Allora il venditore elabora gli OI e, fatto questo, invia all’acquirente un messaggio firmato e cifrato con la propria chiave privata di firma a conferma dell’avvenuta ricezione della richiesta di acquisto.
  • 5. L’acquirente, verificata l’integrità del messaggio di conferma ricevuto, verificandone la firma, lo salva opportunamente.

[adsense:block:adcontenuto]

 

Fasi della autorizzazione di pagamento:
 
  1. 1. Al punto 4 del protocollo precedente il venditore provvede anche a generare e firmare una richiesta di autorizzazione che include l’ammontare della transazione e il suo TI. La richiesta viene cifrata con una chiave simmetrica casuale a sua volta cifrata con la chiave pubblica di scambio del Payment Gateway. La richiesta, assieme ai PI cifrati ricevuti dall’acquirente, vengono inviati al Payment Gateway assieme ad entrambi i certificati del venditore e a quello di firma dell’acquirente.
  2. 2. Quando il Payment Gateway riceve il messaggio, ne ricava la chiave simmetrica di cifratura decifrandola con la propria chiave privata di scambio. Decifra quindi la richiesta, controlla la validità del certificato di firma del venditore e, grazie a questo, verifica la validità della firma con cui il venditore a sottoscritto la richiesta. Quindi decifra con la propria chiave privata di scambio la chiave simmetrica con cui sono stati cifrati i PI e con questa decifra i PI stessi. Provvede poi a controllarne l’integrità confrontando la firma ‘doppia’ decifrata con il valore hash calcolato sulla concatenazione dell’impronta dei PI (da calcolare) e di quella degli OI (già disponibile). Quindi verifica che il TI ricevuto dal Merchant sia identico a quello contenuto nelle PI: se il controllo dà esito positivo, invia una richiesta di autorizzazione allo issuer specificando i dati della carta (questa parte non è qui descritta, può essere gestita da un terminale virtuale POS). Ricevuta la risposta dallo issuer, il Payment Gateway genera e firma un messaggio di risposta all’autorizzazione che comprende il suo certificato di firma e la risposta dello issuer. Questo messaggio viene cifrato con una chiave simmetrica casuale e questa chiave viene cifrata con la chiave pubblica di scambio del Merchant. Il messaggio cifrato e chiave simmetrica cifrata vengono inviati al Merchant.
  3. 3. Il Merchant decifra la chiave simmetrica con la propria chiave privata e con la prima il messaggio ricevuto. Controlla quindi la validità del certificato di firma del Payment Gateway e, se tutto è ok, salva opportunamente la risposta ricevuta e provvede alla consegna della merce richiesta.

 

Si può notare come con il protocollo SET si sia realizzato un notevole salto di qualità nella sicurezza dei pagamenti con carta di credito, anche se la sua complessità ne limita al momento la diffusione e fa prevalere altre soluzioni più limitate (Telepay Light o addirittura il semplice invio via SSL del numero di carta al Merchant). V’è anche da notare il ruolo centrale svolto in questo protocollo dai certificati emessi in questo caso dagli istituti finanziari che svolgono quindi funzione di AC. In futuro, con le nuove ersioni del protocollo, è previsto anche l’utilizzo di tecnologie più avanzate quali smartcard per aumentare il profilo di sicurezza di SET.
 

Altre forme di pagamento

Sono state ideate anche altre forme di pagamento elettronico, basate sul concetto di moneta virtuale, alternative all’uso della carta di credito, che tra l’altro possono risolvere il problema che nasce quando la consistenza economica della transazione è paragonabile al costo ‘finanziario’ della stessa (ovvero nel caso di piccoli acquisti): si dispone infatti, in questo caso, di un borsellino virtuale paragonabile ad una carta a debito, da cui prelevare ‘moneta’ nella misura che serve di volta in volta fino ad esaurimento, cui fa seguito una ricarica. Un esempio di questo è E-Cash della DigiCash.

 

 

 

 

Risorse per sviluppo: 

Ti potrebbero anche interessare: