5. Protocollo SET

VISA e Mastercard hanno sviluppato congiuntamente il protocollo SET (Secure Electronic Transaction) come metodo per il pagamento sicuro su reti aperte.
SET è stato pubblicato come specifiche aperte per l'industria. Tali specifiche sono distribuite per essere applicate a qualsiasi servizio di pagamento e possono essere usate dai venditori di software per sviluppare applicazioni.

Assistenza nello sviluppo di queste specifiche è stata fornita da IBM, Microsoft, Netscape,SAIC,Terisa e Verisign.

5.1 Motivazioni e obiettivi

I principali motivi per cui società di carte di credito forniscono specifiche per pagamenti sicuri sono:

• Far sì che l'insieme di tali società conquisti un ruolo primario nello stabilire specifiche per pagamenti sicuri e, a lungo termine, evitare ulteriori costi dovuto a nuovi approcci di tipo implementativo.

• Rispettare e preservare le relazioni esistenti tra venditore e acquirente e tra compratore e fornitore.

• Facilitare il rapido sviluppo del mercato.

• Proteggere l'integrità dei marchi di tali società.

Gli obiettivi che SET si prefigge riguardo la sicurezza sono:

• Garantire la riservatezza dell'informazione.

• Assicurare l'integrità dei pagamenti.

• Autenticare compratore, venditore e acquirente.

• Definire algoritmi e protocolli necessari per tali servizi.

Gli obiettivi che SET si prefigge riguardo l'interoperabilità sono:

• Definire informazioni dettagliate per assicurare che applicazioni sviluppate da un venditore lavorino con applicazioni sviluppate da altri venditori.

• Creare e supportare uno standard aperto per pagamento con carte di credito.

• Sfruttare gli standard esistenti, quando possibile.

• Consentire l'implementazione su ogni combinazione di piattaforme hardware e software come Power PC, Intel, Sparc, UNIX, MS-DOS, OS/2, Windows, Macintosh.

 Gli obiettivi che SET si prefigge riguardo l'accettazione di mercato sono:

• Ottenere un'accettazione globale, tramite una facile implementazione e un impatto minimo su venditore e compratore.

• Sfruttare le applicazioni per clienti già esistenti.

• Minimizzare lo scambio di relazioni tra acquirente e venditore, e tra compratore e fornitore.

• Fornire un protocollo efficiente dal punto di vista delle istituzioni finanziarie.

Il principio fondamentale che ha guidato gli ideatori del SET è stato quello di rendere sicure le transazioni con carta di credito su Internet, senza la necessità di modificare i circuiti bancari esistenti per le autorizzazioni. Le reti bancarie hanno dei server per l’autorizzazione che filtrano le transazioni illecite in accordo a ben specificati criteri, come ad esempio raggiungere un determinato limite di spesa o effettuare un numero eccessivo di transazioni in un dato intervallo di tempo. Così, prima che sia autorizzata la transazione, il commerciante deve chiedere autorizzazione al server. Quindi nella fase di pagamento, il commerciante riceve il pagamento corrispondente al prezzo dei beni/servizi.

Il SET introduce due nuove entità:

1. la certification authority, che certifica i partecipanti;

2. il  payment gateway, che fa da filtro tra Internet e la rete bancaria.

Nel SET, ci sono sei partecipanti:

1. il cardholder (il possessore della carta di credito), la cui carta è conforme alle specifiche SET è stata emessa da una istituzione preposta, tipicamente banche affiliate con Visa e MasterCard;

2. il server del Commerciante;

3. il payment gateway; (Gateway di pagamento);

4. l'issuing institution (l’istituzione che emette la carta di credito);

5. la Certification Authority (CA);

6. l’Acquiring Institution, che è la banca del commerciante.

Il possessore della carta, il commerciante, la certification authority ed il payment gateway sono connessi attraverso la rete. Ognuno dei partecipanti deve prima ottenere un certificato dalla CA conforme alle specifiche SET. Questi certificati sono inclusi in ognuno dei messaggi scambiati tra il cardholder, il commerciante ed payment gateway.

L'issuing institution e l'acquirent institution sono collegate mediante una rete bancaria sicura e chiusa. Il gateway è il ponte fra queste reti, e protegge l'accesso alla rete bancaria. Inoltre ha due interfacce, una sul lato Internet conforme alle specifiche SET ed una dal lato della rete bancaria conforme al protocollo proprietario. Il SET garantisce la sicurezza degli scambi sia tra cliente e commerciante che tra il commerciante ed il gataway.

5.2 Servizi di sicurezza del SET

Le transazioni SET forniscono i seguenti servizi:

• Registrazione dei cardholder(possessore della carta di credito) e dei merchant (commerciante) con la CA;

• Consegna de certificati ai cardholders ed ai merchant;

• Autenticazione, riservatezza ed integrità delle transazioni di acquisto;

• autorizzazione di pagamento.

Il SET usa tecniche di crittografia a chiave pubblica per garantire simultaneamente:

• Riservatezza degli scambi;

• Integrità dei dati scambiati tra il cliente, il merchant e l’acquiring bank;

• Identificazione dei partecipanti;

• Autenticazione dei partecipanti.

Una condizione necessaria ma non sufficiente per il non ripudio della transazione è che il possessore della carta sia certificato.

• La riservatezza è assicurata sfruttando la codifica del messaggio SET si affida alla crittografia per garantire la riservatezza del messaggio. In SET i dati del messaggio sono inizialmente codificati usando una chiave simmetrica generata casualmente. Tale chiave, a sua volta, è codificata usando la chiave pubblica del destinatario del messaggio. Si ottiene la cosiddetta busta elettronica, spedita al destinatario insieme al messaggio codificato. Una volta ricevuta tale busta, il destinatario la decodifica usando la propria chiave privata: ottiene così la chiave simmetrica (generata casualmente) che usa per decodificare il messaggio originale.

• Integrità e autenticazione sono assicurate dall'uso di firme digitali. L’integrità e l’autenticazione sono invece garantite dall’uso delle firme digitali  (algoritmo di firma RSA). Nel SET l'operazione di firma è effettuata una sola volta, mentre quella di verifica è effettuata centinaia di volte; proprio per questo motivo è stato scelto come schema di firma l'RSA che ha un tempo di verifica della firma digitale di gran lunga inferiore ai tempi di verifica di altri schemi. La firma digitale di un messaggio M da parte di un'entità E viene prodotta, per le transazioni SET, mediante i seguenti passi:

1. viene generata la codifica DER (Distinguished Encoding Rules) del messaggio M, ottenendo in tal modo una sequenza di  ottetti (byte);

2. utilizzando la funzione hash sha-1, con in input la codifica DER di M, si genera un message digest di 160 bit;

3. si cifra il message digest utilizzando l'algoritmo RSA con la chiave privata di E.

La stringa risultante da tale processo è la firma digitale di M. Il numero massimo di byte del messaggio cifrato da firmare è di 128 (1024 bit). Per esempio, Alice calcola il digest del messaggio che deve mandare a Bob, e lo codifica con la propria chiave privata: firma cioè digitalmente tale messaggio. Invia quindi a Bob sia il messaggio che la firma digitale. Quando Bob riceve il messaggio, ne calcola il digest e decodifica la firma digitale usando la chiave pubblica di Alice. Se i due valori coincidono, Bob sa che il messaggio è stato firmato usando la chiave privata di Alice e che non è stato alterato dal momento in cui è stato firmato. SET utilizza una coppia di chiavi pubblica/privata esclusivamente per creare la firma digitale. Quindi, ogni partecipante a SET possiede due coppie di chiavi asimmetriche: la cosiddetta coppia di chiavi di scambio, usata nei processi di codifica e decodifica, e una coppia di chiavi di firma, per la creazione e la verifica di firme digitali.
È da notare che il ruolo delle chiavi pubbliche e private è invertito nei processi di firma dove la chiave privata è usata per codificare (firmare), e quella pubblica è usata per decodificare (verificare la firma)

•     L'autenticazione è ulteriormente rafforzata dall'uso dei certificati. Prima che due parti usino la crittografia a chiave pubblica per concludere affari, ognuna desidera esser sicura che l'altra parte sia stata autenticata.
  Prima che Bob accetti un messaggio con la firma digitale di Alice, Bob vuole essere sicuro che la chiave pubblica appartenga ad Alice e non a qualcuno che in rete dice di essere Alice. Un modo potrebbe essere quello di farsi mandare da Alice la sua chiave pubblica su un canale sicuro. Spesso però questa via non è praticabile. Un'alternativa è sfruttare una terza parte di fiducia che garantisca che quella chiave pubblica appartiene ad Alice. Tale parte è nota con il nome di Autorità di Certificazione (CA). Tale autorità può emettere certificati che forniscono assicurazioni sull'identità di una persona. Una volta che Alice ha provato la propria identità (con passaporto, patente o altro), l'CA crea un messaggio che contiene il nome di Alice e la sua chiave pubblica. Tale messaggio, noto come certificato, è firmato digitalmente dalla CA. Esso contiene dunque informazioni sull'identità del proprietario così come una copia di una delle chiavi pubbliche del proprietario (di scambio o di firma). Per ottenere i maggiori benefici, la chiave pubblica della CA dovrebbe essere conosciuta dal più grande numero di persone possibile. Poiché chi sfrutta SET ha due coppie di chiavi, ognuno dei partecipanti avrà due certificati. Entrambi i certificati sono creati e firmati nello stesso momento dalla CA. Ogni certificato contiene l’identità del suo proprietario, la chiave pubblica relativa all’algoritmo crittografico a chiave pubblica usato e la firma dell’authority che ha rilasciato il certificato.

Il SET usa algoritmi crittografici esistenti come mostrato nella tabella.

 Algoritmi crittografici usati dal SET.

In una transazione SET, molte delle entità, come i merchant, hanno due coppie di chiavi: una per firmare i documenti e l’altra per scambiare le chiavi durante la fase di identificazione. La figura sottostante riassume i principali passi necessari per processare un messaggio in modo tale che siano garantite autenticazione, riservatezza ed integrità.

5.3 Crittografia nel SET

Il SET utilizza entrambi i metodi. La crittografia a chiave privata, anche detta a chiave simmetrica, usa la stessa chiave sia per cifrare che per decifrare un messaggio. Perciò sia il mittente che il destinatario devono conoscere questa chiave, che deve rimanere sconosciuta per chiunque altro. Un diffuso algoritmo di questo tipo è il DES (Data Encryption Standard), che è usato dalle istituzioni finanziarie per cifrare i PIN (Personal Identification Numbers).  La crittografia a chiave pubblica, conosciuta anche come crittografia a chiave asimmetrica, usa due chiavi: una per cifrare i messaggi e l’altra per decifrarli; le due chiavi sono legate matematicamente, perciò informazioni crittografate con una delle due possono essere decifrate solo ed esclusivamente con l’altra chiave della coppia. Ogni utente rende pubblica una chiave, mentre mantiene segreta l’altra. Chiunque spedisca un messaggio crittografato con la chiave pubblica è sicuro che solo il destinatario, che è l’unico ad avere la chiave privata, potrà decifrare il messaggio. Il più diffuso algoritmo di questo tipo è l’RSA (dalle iniziali dei suoi inventori: Rivest, Shamir e Adleman).  La crittografia a chiave simmetrica diventa impraticabile quando si ha a che fare con un largo gruppo di corrispondenti attraverso una rete pubblica. È il caso di un commerciante che vuole condurre transazioni con un numero probabilmente altissimo di abbonati ad Internet: ciascun utente dovrebbe avere una propria chiave segreta assegnata dal commerciante e trasmessa attraverso un canale separato sicuro. Invece utilizzando la crittografia a chiave pubblica lo stesso commerciante può creare la coppia di chiavi e distribuire quella pubblica, permettendo ad ogni consumatore di spedirgli messaggi sicuri.

5.4 Funzioni Hash

Il SET combina la crittografia a chiave pubblica con l'uso dei cosidetti message digest. Un message digest è un valore unico generato per un messaggio tramite una funzione crittografica one-way (che non può essere invertita). L’algoritmo usato dal SET produce message digest di 160 bit; modificando un solo bit del messaggio originale, cambiano circa la metà dei bit del message digest; inoltre la probabilità che due messaggi diversi abbiano lo stesso message digest è di 1/10⁴⁸, perciò la generazione di due documenti con lo stesso message digest è computazionalmente impossibile. Le funzioni hash utilizzate dal SET sono due:

sha-1 è lo standard per le funzioni hash creato dal NIST (http://www.nist.org/).  Nel protocollo SET tale funzione viene talvolta applicata ai valori di un tipo di dati e a volte alla codifica DER di un tipo di dati, a seconda delle esigenze.

hmac(M, key) questa funzione è una variante della precedente, ispirata alla nota funzione hash hmac-MD5. In pratica utilizza una chiave key aggiuntiva di 64 byte per produrre il message digest del messaggio M ed è definita in questo modo:

hmac(M, key)=sha-1((key xor opad))||sha-1((key xor ipad)||M)

dove opad è il byte 0x5C ripetuto 64 volte e ipad è il byte 0x36 ripetuto 64 volte.

5.5 Busta digitale

La chiave simmetrica viene cifrata utilizzando la chiave pubblica del destinatario per mezzo dell'RSA e inviata insieme al messaggio cifrato. Questo sistema viene denominato digital envelope. Il ricevente decifra prima la chiave simmetrica utilizzando la propria chiave privata, poi con la chiave simmetrica ottenuta decifra il messaggio. Una busta digitale per l'entità A è quindi un messaggio cifrato, contenente delle informazioni, che può essere decifrato solo da A. La busta digitale utilizzata nel protocollo SET ha una dimensione fissa di 128 byte (1024 bit), quindi nel caso in cui alcuni campi nella busta abbiano valore nullo vengono sostituiti da costanti prefissate. Il procedimento usato per produrre la busta digitale combina il crittosistema RSA con il Bellare-Rogaway Optimal Asymmetric Encryption Padding (OAEP) che ha il vantaggio di impedire che singoli blocchi del messaggio possano essere decifrati indipendentemente dagli altri. La prima operazione consiste nella produzione di un blocco definito OAEP di 1024 bit. In seguito questo blocco viene cifrato con l'RSA a 1024 bit e utilizzando la key-exchange pubblica dell'entità a cui è destinata la busta.

Ecco come avviene la costruzione del blocco OAEP:

Il simbolo "||" indica la concatenazione, l'altro simbolo è lo Xor.

• DB è ottenuto concatenando 4 sottoblocchi : BT è un byte con valore costante x03 che identifica il formato del blocco; BC è un byte che indica il tipo di dati contenuti nel blocco ADB (a volte il blocco ADB contiene dati di tipo "extra", cioè dati privati riguardanti l'account del cliente o del commerciante o anche dell'Acquisitore, i quali vengono cifrati in un blocco a parte); V è una stringa di 7 byte tutti a 0 utilizzata per verificare la corretta decifratura del blocco; ADB è un blocco di dati di 102 byte che contiene le informazioni da trasmettere al destinatario (contenuto della busta).

• E-Salt è un valore random di 16 byte.

• H1(E-Salt) è ottenuto prelevando i primi 111 byte della seguente sequenza di 120 byte: sha-1(E-Salt||00)||sha-1(E-Salt||01)||sha-1(E-Salt||02)||sha-1(E-Salt||03)||sha-1(E-Salt||04)|| sha-1(E-Salt||05).

• A è ottenuto come risultato dello Xor tra il blocco H1(E-Salt) e DB entrambi lunghi 111 byte.

• Il blocco B di 16 byte è calcolato come lo XOR di E-Salt e H2(A), dove H2(A) è ottenuto prelevando i primi 16 byte del message digest di 20 byte sha-1(A).

• I è un byte random con il bit di valore più alto settato a 0. Il suo scopo è di rendere il valore del blocco OAEP sempre minore del valore del modulo n di RSA, il quale a sua volta è di 128 byte ed ha il bit di valore più alto sempre settato a 1.

• Il Padded Data Block (PDB) di 127 byte è composto dalla concatenazione dei blocchi A e B.

L'apertura della busta da parte del ricevente avviene in questo modo:

- Si applica alla busta digitale l'algoritmo RSA con la chiave privata del ricevente ottenendo così OAEP.

- Essendo OAEP = l || PDB, PDB=A||B è B=E-Salt xor H2(A) con I lungo 1 byte, A lungo 111 byte e B di 16 byte si ottiene E-Salt=B xor H2(A).

- Poichè A=H1(E-Salt) xor DB e H1(E-Salt) consiste nei primi 111 byte della stringa di 120 byte, allora è possibile ricavare DB=A xor H1(E-Salt).

- Infine essendo DB=BT||BC||V||ADB, allora verificando i campi BT, BC, V, si possono ottenere i valori conservati in ADB.

5.6 Doppia firma

Il SET introduce anche una nuova applicazione della firma digitale: la dual signature (firma doppia). L'uso della doppia firma consente ad un utente A di firmare un messaggio M=M₁||M₂ da inviare ad entrambe le parti B₁ e B₂  facendo in modo che la parte M₂ del messaggio non sia visibile a B₁ e la parte M₁ non sia visibile a B₂ ma che sia B₁ che B₂ possano verificare l'autenticità della firma di A. La doppia firma da parte di A del messaggio M=M₁||M₂ è eseguita nel modo seguente:

1. A calcola il message digest di M₁ (h(M₁)) e di M₂ (h(M₂))

2. A concatena i due digest ottenuti e firma con la sua chiave privata di signature (e_A) il risultato della concatenazione ottenendo e_A(h(M₁)||h(M₂));

3. A invia a B₁ il messaggio <M₁, h(M₂), e_A(h(M₁)||h(M₂))> ed a B₂ il messaggio <h(M₁),M₂, e_A(h(M₁)||h(M₂))>.

Entrambi i destinatari dei messaggi di A saranno in grado di verificare la firma, ma potranno leggere solo la parte di messaggio che li riguarda. Per esempio, B₁ estrae il message digest della doppia firma di A, calcola il message digest di M₁ e lo concatena a quello di M₂, quindi computa il message digest del risultato e lo confronta con quello estratto dalla doppia firma di A. Se coincidono allora A ha firmato il messaggio M=M₁||M₂  (lo stesso vale per B₂). SET utilizza la doppia firma per permettere ad un cliente di firmare e inviare un ordine di acquisto al commerciante e al gateway di pagamento in modo tale che il gateway di pagamento non possa vedere le informazioni sull'ordine ma solo quelle relative al pagamento. Il gateway di pagamento riceve quindi le informazioni di pagamento, il message digest delle informazioni sull'ordine e la firma del cliente. Può quindi verificare la firma sull'intero documento, ma non può leggere le informazioni sull'ordine. Il commerciante, invece, riceve le informazioni sull'ordine, il message digest delle informazioni di pagamento e

la firma del cliente. Può quindi verificare la firma sull'intero documento, ma non può leggere le informazioni sull'ordine.

5.7 Cifratura/Decifratura dei dati

Ecco i passi seguiti nel caso in cui, per esempio, Alice voglia firmare un messaggio e spedirlo a Bob (encryption):

1. Alice manda in input il messaggio ad un algoritmo one-way e produce il message digest;

2. Cifra il message digest utilizzando la sua signature key privata, apponendo così la sua firma digitale;

3. Poi genera una chiave simmetrica random con cui cifra: il messaggio originale, la firma e una copia del suo certificato;

4. Cifra la chiave simmetrica appena utilizzata con la chiave pubblica di Bob (digital envelop);

5. Poi spedisce il tutto a Bob: il messaggio, la firma e il certificato cifrati con la chiave simmetrica, e la chiave simmetrica stessa cifrata con la chiave pubblica di Bob. 

Vediamo ora i passi seguiti da Bob per leggere il messaggio (decryption):

1. Appena ricevuto il messaggio da Alice, Bob decifra il digital envelope con la propria exchange key privata, ottenendo così la chiave simmetrica di sessione;

2. Con la chiave simmetrica decifra il messaggio, la firma digitale ed il certificato inviati da Alice;

3. Decifra la firma digitale di Alice utilizzando la chiave pubblica per le firme di quest'ultima, ottenendo il message digest del messaggio originale;

4. Manda in input il messaggio originale allo stesso algoritmo one-way usato da Alice ottenendone il message digest;

5. Infine, confronta il message digest ottenuto dal proprio algoritmo con quello ottenuto decifrando la firma digitale di Alice. Se coincidono, Bob ha la conferma che il messaggio non è stato alterato durante la trasmissione, e che è stato firmato utilizzando la chiave di firma privata di Alice. Se invece sono diversi, allora c'è qualcosa che non va, perciò Bob intraprenderà azioni appropriate, cioè notificherà il tutto ad Alice o rifiuterà il messaggio.

Conclusioni

Oggi il SET fatica ancora a diventare uno standard per i pagamenti con carta di credito, in lotta con il più diffuso SSL; nonostante questo non garantisca la non ripudiabilità di una transazione, di fatto, è più veloce e snello.

Le principali caratteristiche del SET sono:

• Il merchant riceve le informazioni relative all’ordine firmate mediante la chiave privata del buyer. Inoltre il merchant riceve la risposta del gateway anch’esso cifrato mediante la sua chiave privata. Se il cliente risulta essere certificato, il venditore riceve una copia del certificato del buyer e la sua chiave pubblica.

• Il cardholder riceve una risposta all’ordine d’acquisto, firmata con la chiave privata del merchant. Inoltre riceve una copia del certificato del merchant.

• Il payment gateway conosce le informazioni finanziarie della transazione tra il merchant ed il cardholder ma non è consapevole del soggetto della transazione.

• Ad ogni transazione è associato un numero unico che viene criptato, per prevenire eventuali attacchi.

Tuttavia, la sicurezza offerta usa mezzi complessi e questo si traduce in un eccessivo sovraccarico computazionale, per cui il tempo di risposta può essere inadeguato. Inoltre la pesantezza delle operazioni fa sì che il SET non venga usato nei pagamenti piccoli.

Altri fattori che fanno decrescere la popolarità del SET sono:

• Gli aspetti legali, in particolare le leggi che limitano l’uso della crittografia;

• I dati riguardanti il cardholder sono memorizzati nell’hard disk di un computer e questo non da garanzie sufficienti.

Il SET soddisfa, in ogni caso, sette importanti requisiti:

1. fornisce confidenzialità nella trasmissione dei dati di pagamento,

2. assicura l’integrità di tutti i dati trasmessi;

3. garantisce che il possessore della carta di credito sia un utente legittimo;

4. garantisce che il commerciante possa accettare le transazioni attraverso il contatto con una istituzione       finanziaria;

5. assicura l’utilizzo delle migliori pratiche e tecnologie di sicurezza per proteggere ogni legittima parte coinvolta  nelle transazioni di CE;

6. crea un protocollo che non dipende dai meccanismi di trasmissione dei dati;

7. facilita ed incoraggia l’interoperabilità tra software e network providers.