C. C.1 IPSec Il protocollo IPSec (Internet Protocol Security) è costituito da un insieme di elementi che realizzano un architettura di sicurezza a livello IP in modo trasparente rispetto alle applicazioni, garantendo i requisiti di autenticazione, integrità e riservatezza. IPSec può essere utilizzato come soluzione end to end, ovvero per la protezione dello scambio di informazioni diretto tra il mittente e il destinatario della comunicazione, oppure può intervenire tra due sistemi intermedi (security gateway), come nella realizzazione di VPN. I protocolli che costituiscono IPSec sono essenzialmente tre: AH (Authentication Header) ESP (Encapsulating Security Payload) Tesi di Laurea di Elena Nuti 172
IKE (Internet Key Exchange) AH ed ESP sono protocolli che presentano in realtà funzionalità sovrapposte (i servizi offerti da AH sono offerti anche da ESP, seppure in modo leggermente diverso), anche se AH fornisce solamente i servizi di autenticazione e integrità, mentre ESP garantisce in più la riservatezza. Questa sovrapposizione risale all esigenza di avere un protocollo esportabile, in quanto AH non comprende funzioni di cifratura e dunque non rientra nelle restrizioni all esportazione che riguardano il software crittografico. AH ed ESP possono essere implementati con due diverse modalità: Trasporto: in questa modalità (che è possibile solo tra due host e non tra due security gateway) gli header AH e/o ESP vengono inseriti tra l header IP e l header di trasporto Tunnel: in questa modalità l intero pacchetto IP originale viene incapsulato in un nuovo pacchetto. In Fig. 59, 60 e 61 sono riportati rispettivamente il pacchetto IP originale e le varianti IPSec in modalità trasporto e tunnel Fig. 59 Pacchetto IP originale Fig, 60 Pacchetto IPSec in modalità trasporto Tesi di Laurea di Elena Nuti 173
Fig. 61 Pacchetto IPSec in modalità tunnel Il protocollo IKE agisce invece nella fase di instaurazione della comunicazione IPSec, consentendo di negoziare, creare, distruggere e in generale gestire le SA (Security Association), ovvero una sorta di convenzione tra le due parti su quali protocolli, algoritmi crittografici e chiavi utilizzare, che deve essere effettuata prima di stabilire la comunicazione sicura. La SA è in sostanza l elemento che specifica la connessione IPSec ed è pertanto fondamentale per poter comunicare tramite IPsec, tuttavia AH ed ESP non si preoccupano della loro gestione e presuppongono che le SA siano già state create. La negoziazione relativa alla SA avviene in due fasi: in un primo momento i due interlocutori creano una SA, detta Internet Security Association and Key Management Protocol (ISAKMP) SA, per IKE stesso, in modo da proteggere i messaggi del protocollo di scambio delle chiavi. Lo scambio di messaggi in questa fase può essere in main mode (modalità che consiste di sei messaggi) oppure in aggressive mode (scambio più breve costituito da tre messaggi). Successivamente le due parti creano le SA per IPSec in quick mode (modalità costituita da tre messaggi). Durante la fase di negoziazione mittente e destinatario devono autenticarsi vicendevolmente: per farlo possono utilizzare metodi di crittografia a chiave pubblica oppure una pre-shared key, cioè un informazione segreta condivisa che si sono precedentemente scambiati in altro modo (qualcosa di simile ad una password, che Tesi di Laurea di Elena Nuti 174
viene però utilizzata per un autenticazione mutua e non di una sola parte). IPSec e VPN (Virtual Private Networks) IPSec può in teoria essere utilizzato per proteggere qualunque tipo di traffico IP, tuttavia il suo uso attualmente più comune è connesso alla realizzazione di reti private virtuali (VPN). L architettura VPN permette di collegare tra loro delle reti locali tramite una rete esterna non sicura (es. Internet), garantendo la sicurezza nello scambio delle informazioni. Consideriamo due reti locali distanti dal punto di vista geografico che vogliono comunicare tra loro, in maniera sicura, tramite la rete Internet. In ognuna delle due reti viene inserita una macchina che abbia le funzioni di security gateway e le tabelle di routing vengono configurate in modo che il traffico proveniente da una rete e destinato all altra venga inviato al security gateway locale attraverso il cosiddetto tunnel IPSec, creando virtualmente un'unica rete privata che sfrutta l'infrastruttura della rete pubblica. Fig. 62 Struttura di una VPN Tesi di Laurea di Elena Nuti 175
Il tutto avviene in maniera trasparente nei confronti degli host e delle applicazioni, in quanto il tunnel IPsec appare alle macchine sulle due reti locali come un unico link virtuale. Se infatti un host sulla prima rete vuole comunicare con un host sulla seconda si limiterà ad inviare il relativo pacchetto IP senza alcun particolare accorgimento. Tale pacchetto arriva al security gateway della prima rete, che si accorge che è destinato alla seconda, lo cifra e lo incapsula in nuovo pacchetto IP, che avrà come mittente il suo indirizzo pubblico e come destinazione l indirizzo pubblico del secondo gateway. Il pacchetto transita normalmente su Internet, ma chi lo intercettasse vedrebbe solamente che è in corso una comunicazione IPSec tra i due gateway, e non potrebbe ricavare né i contenuti della comunicazione, né il protocollo utilizzato a livello trasporto e applicazione, né il mittente e il destinatario reali della comunicazione. Quando il pacchetto arriva al secondo gateway, questo ne verifica l autenticità e l integrità e decifra la porzione cifrata ricostruendo così il pacchetto originale, che inoltra poi verso il destinatario. Se una delle due parti in comunicazione non è una rete bensì un singolo host, non si parla propriamente di VPN ma di architettura road warrior, anche se il tutto può essere considerato un caso degenere di VPN. La particolarità del road warrior rispetto alla VPN è che solitamente l'host esterno ha un indirizzo IP dinamico e quindi non noto a priori, al contrario di quanto avviene con i security gateway che hanno di solito un indirizzo IP statico e noto in fase di configurazione. In Fig. 63 è riportata una possibile implementazione di VPN a cui sono collegati sia singoli utenti che reti locali di varia tipologia. Tesi di Laurea di Elena Nuti 176
Fig. 63 Esempio di realizzazione di una VPN (fonte: Cisco) C.2 SSL SSL (Secure Sockets Layer) è un protocollo aperto e non proprietario che utilizza diversi algoritmi di cifratura nelle sue diverse fasi per stabilire e mantenere tre funzionalità fondamentali: Riservatezza del collegamento. La crittografia è usata dopo un handshake iniziale per definire una chiave segreta. Per crittografare i dati è usata la crittografia simmetrica (es. DES, RC4, etc.) che permette una velocità maggiore per crittare e decrittare i dati. Autenticazione. L'identità nelle connessioni può essere autenticata usando la crittografia asimmetrica (RSA). In questo modo i client sono sicuri di comunicare con il corretto server, prevenendo ogni interposizione. E' prevista la certificazione sia Tesi di Laurea di Elena Nuti 177
del server che del client (la client authentication è però opzionale). Integrità. Il livello di trasporto include un controllo dell'integrità del messaggio basato su un apposito MAC (Message Authentication Code) che utilizza funzioni hash sicure (SHA, MD5, etc.). In tal modo si verifica che i dati spediti tra client e server non siano stati alterati durante la trasmissione. Un vantaggio del SSL è la sua indipendenza dal protocollo di applicazione: un protocollo di livello più alto può interfacciarsi sul protocollo SSL in modo trasparente. Il protocollo è composto da due strati (vedi Fig. 64): a livello più basso, interfacciato su di un protocollo di trasporto affidabile come il TCP, c'è il protocollo SSL Record. Questo è usato per l'incapsulamento dei vari protocolli di livello superiore. Sul protocollo SSL Record si interfaccia l'ssl Handshake che permette al server ed al client di autenticarsi a vicenda ( come già detto, la client authentication è facoltativa) e di negoziare un algoritmo di crittografia e le relative chiavi prima che il livello applicazione trasmetta o riceva il suo primo byte. Fig. 64 SLL nello stack TCP/IP Dopo un handshake in cui client e server contrattano il livello di sicurezza da usare ed il completamento delle autenticazioni Tesi di Laurea di Elena Nuti 178
necessarie alla connessione, SSL procede alla cifratura (e/o alla messa in chiaro) della sequenza di bytes del protocollo applicazione usato, ad esempio HTTP, SHTTP, NNTP o Telnet. Ciò significa che tutte le informazioni sia nell'http request che nell'http response sono completamente crittografate, incluso l'url richiesto dal client, qualsiasi contenuto di forms compilati, ogni informazione sulle autorizzazioni all'accesso come usernames e passwords, e tutti i dati risposti dal server al client. Una sessione SSL può includere più di una connessione sicura; inoltre le applicazioni possono avere più sessioni simultanee. Per sfruttare la protezione offerta da SSL è necessario che un sito web disponga di un server in cui sia integrata la tecnologia SSL. Attualmente l'implementazione SSL v3.0 è multipiattaforma. Il browser del client può essere qualunque, purché supporti il protocollo SSL e, quindi, il nuovo metodo di accesso URL https per connessioni con un server che usa SSL. Poiché https e http sono differenti protocolli ed usano porte diverse, lo stesso sistema server può far girare contemporaneamente sia il server https che quello http. Ciò significa che un server può offrire alcune informazioni a tutti gli utenti senza sicurezza, ed altre solo in modo sicuro. Andiamo adesso ad analizzare maggiormente nel dettaglio le due fasi seguite dal protocollo. SSL Handshake Quando un client ed un server SSL iniziano a comunicare, effettuano un handshake per iniziare la connessione TCP/IP: Client e server, infatti, concordano sulla versione del protocollo e scelgono gli algoritmi di crittografia. Tesi di Laurea di Elena Nuti 179
Successivamente viene effettuata l autenticazione del server: il client richiede al server il suo certificato contenente la chiave pubblica del server medesimo e il nome del sito, quindi verifica la corrispondenza sito-certificato e se questa ha esito positivo genera una chiave simmetrica random che invia al server dopo averla crittografata con la chiave pubblica del server ricavata dal certificato; solo il server sarà in grado di ricavare questa chiave tramite la propria chiave privata. In seguito all autenticazione del server, se richiesto può avvenire l autenticazione del client, che sarà trattata in modo piuù approfondito nel proseguo del paragrafo. Dopo la fase di autenticazione, server e client usano la crittografia a chiave pubblica per generare dati segreti condivisi. E' responsabilità dell'ssl Handshake Protocol coordinare gli stati del client e del server, permettendo così ad ogni sistema operativo chiamato in causa di operare in modo consistente, nonostante lo stato non sia esattamente parallelo. Logicamente lo stato è rappresentato in modo doppio: una volta come lo stato operativo corrente (current), e, durante la fase di handshake, come lo stato in attesa (pending); inoltre sono mantenuti separati gli stati di lettura da quelli di scrittura. Lo stato della sessione include i seguenti elementi: - session identifier: è una sequenza arbitraria di bytes scelta dal server per identificare un stato attivo della sessione, o comunque riesumabile. - peer certificate: certificato X.509 del peer. Può essere nullo. - compression method: l'algoritmo usato per comprimere i dati prima della crittografia. Tesi di Laurea di Elena Nuti 180
- cipher spec: specifica l'algoritmo di crittografia (ad es. null, DES, etc.) e l'algoritmo MAC (per es. MD5 o SHA). Stabilisce inoltre dei parametri della crittografia come l' hash_size. - master secret: 48 bytes segreti, condivisi dal client e dal server. - is resumable: è un flag che indica se la sessione può essere usata per iniziare nuove connessioni. Lo stato della connessione include i seguenti elementi: - server and client random: sequenza di bytes scelti dal server e dal client per ogni connessione. - server write MAC secret: la sequenza segreta usata nelle operazioni MAC sui dati scritti dal server. - client write MAC secret: la sequenza segreta usata nelle operazioni MAC sui dati scritti dal client. - server write key: la chiave per i dati cifrati dal client e messi in chiaro dal server. - initialization vectors: se è usato un blocco cifrato in modo CBC, allora per ogni chiave è mantenuto un vettore d'inizializzazione. Questo campo è inizializzato dal SSL handshake protocol. Poi il codice cifrato finale di ogni record è salvato per essere usato con i record seguenti. - sequence numbers: ognuna delle due parti comunicanti mantiene separati numeri di sequenza per i messaggi spediti e ricevuti per ogni connessione. Quando uno dei due manda o riceve un messaggio di Change Cipher Spec, il numero appropriato della sequenza è posto a zero. I numeri di sequenza sono espressi da 64 bits e non possono quindi eccedere 2 64-1. Tesi di Laurea di Elena Nuti 181
Andiamo adesso a descrivere la fase di handshake: come prima cosa il client spedisce un messaggio di client hello al quale il server deve rispondere con un messaggio di server hello, altrimenti si verifica un errore fatale e la connessione fallisce. I messaggi client hello e server hello sono utilizzati per stabilire le prestazioni di sicurezza ottenibili fra client e server; questi messaggi stabiliscono i seguenti attributi: protocol version, session ID, cipher suite e compression method. Inoltre, due valori casuali sono generati e scambiati: ClientHello.random e ServerHello.random. Il messaggio di hello ha i seguenti campi: - protocol version: sono due byte utilizzati per indicare la versione di SSL in uso; - random byte: sono dei byte casuali generati dal client come richiesta al server - session identifier: sono 32 byte contenenti l'identificativo di una precedente sessione di una connessione che potrebbe essere riesumata. Se sono tutti zero, indicano che si tratta di una nuova sessione. - lista delle CipherSuite: è la lista contenente le combinazioni di algoritmi di crittografia supportati dal client, ordinata secondo le sue preferenze. Il server effettuerà una scelta tra gli algoritmi presenti, restituendo un messaggio di errore e terminando la connessione se nessuno di questi è supportato. Fig. 65 Esempio di lista di CipherSuite Tesi di Laurea di Elena Nuti 182
Dopo lo scambio dei messaggi di hello, se il server riconosce l ID di della sessione precedente, la sessione viene riavviata; se invece si tratta di una nuova sessione, il server invia un certificato al client per autenticarsi. Questo certificato comprende la chiave pubblica del server, firmata con la chiave privata di un autorità di certificazione. Il tipo di certificato deve essere appropriato all'algoritmo per lo scambio di chiavi selezionato nella CipherSuite (generalmente viene è utilizzato il certificato X.509 v3), quindi conterrà anche le informazioni utili al funzionamento dell'algoritmo. Il client utilizza la chiave pubblica dell autorità di certificazione per verificare l'attendibilità del certificato. Il server invia il messaggio Server Key Exchange che contiene i parametri per gli algoritmi di cifratura (in funzione della CipherSuite selezionata) e in questo modo tra il client ed il server vengono scambiate informazioni riguardanti le chiavi: al termine di questa fase, entrambi avranno una chiave principale (master key) simmetrica condivisa. Gli algoritmi supportati sono: RSA, DH, Fortezza-KEA. La chiave viene inviata come testo cifrato utilizzando la chiave pubblica del server, sulla base delle eventuali limitazioni presenti (40/56bits). Solo nel caso dell algoritmo RSA viene verificata la chiave principale e le chiavi di sessione ricevute successivamente. Quando il server riceve la chiave principale e le chiavi successive dal client, le decodifica utilizzando la propria chiave privata, quindi invia al client una conferma rispondendo alla richiesta casuale inviata dal client nel messaggio Client Hello. Il client decodifica la risposta alla richiesta casuale e, se esiste corrispondenza, si stabilisce una connessione a cui si concede fiducia tra client e server. Il server invia il messaggio di Server Hello Done, indicando che la fase hello è completa, ed attende una risposta dal client. Tesi di Laurea di Elena Nuti 183
E in questo momento che può avere luogo la fase opzionale di autenticazione del client: il server richiede al client un certificato e a questa richiesta il client risponde con un messaggio Client Certificate, quindi invia un certificato nel formato X.509 1. Il client invia quindi un messaggio di Change Cipher Spec, che copia lo stato in attesa di scrittura nello stato corrente di scrittura, così da segnalare i cambiamenti delle strategie di cifratura. Subito dopo invia il messaggio di Finished usando algoritmi, chiavi e stringhe segrete appena concordate. Il server risponde con un messaggio di Change Cipher Spec, copia lo stato in attesa di scrittura nello stato corrente di scrittura, e spedisce il suo messaggio di Finished (che contiene l ID sessione crittografato) in accordo con la nuova Cipher Spec. Fig. 66 Fase di Handshake SSL 1 cfr. par. SSL con client autentication riportato nel proseguo dell appendice Tesi di Laurea di Elena Nuti 184
Adesso la fase di handshake è completata ed il client ed il server possono cominciare a scambiare dati del livello applicazione. Come già accennato in precedenza il client ed il server possono anche decidere di riabilitare una precedente sessione o di duplicarne una esistente. In questo caso il flusso dei messaggi è il seguente: il client manda un client hello usando la Session ID della sessione da riesumare; il server allora controlla la sua session cache per trovare una corrispondenza: se la trova il server manda un server hello con la stessa Session ID. Adesso sia il client che il server devono mandare un messaggio di Change Cipher Spec e procedere direttamente fino al messaggio di Finished. Una volta che il ripristino è completo, il client ed il server possono iniziare a scambiare dati di livello applicazione. Fig. 67 Riabilitazione di una sessione precedente Se il server non trova una corrispondenza di Session ID nella propria session cache, allora il server genera un nuovo Session ID, e verrà eseguito un nuovo handshake completo. SSL con Client authentication Dopo lo scambio dei messaggi di hello e server autenthication, se il server è autenticato può richiedere, se ciò è in accordo con la CipherSuite scelta, un certificato dal client, tramite un messaggio di Certificate Request, che in particolare contiene una lista di tipi Tesi di Laurea di Elena Nuti 185
di certificati, ordinati secondo le preferenze del server, ed una lista di nomi di autorità fidate che emettono certificati. Il messaggio Client Certificate è il primo messaggio che il client può mandare dopo aver ricevuto il Server Hello Done e la richiesta di un certificato da parte del server. Se non è disponibile un certificato, il client lo segnalerà per mezzo di un messaggio di alert (No Certificate Alert), al quale il server risponde con un errore fatale se è necessaria l'autenticazione del client. Il messaggio Client Key Exchange, il cui contenuto dipende dall'algoritmo a chiave pubblica selezionato con il Client Hello ed il Server Hello, deve essere a questo punto inviato obbligatoriamente dal client al fine di fissare un Pre-master Secret utilizzato per calcolare il Master Secret, cioè un valore condiviso da client e server necessario alla generazione di chiavi per il calcolo del MAC, di chiavi simmetriche e di vettori di inizializzazione utilizzati per la cifratura. Fig. 68 Pre-master secret Tesi di Laurea di Elena Nuti 186
Se il client ha spedito un certificato con abilitazione alla firma, allora viene inviato un hash dei messaggi di handshake, scambiati a partire da client hello fino a questo punto, e della master secret, con un messaggio di Certificate Verify in modo che il server possa verificarne l autenticità. A questo punto avviene con la modalità consueta lo scambio dei messaggi di Change Cipher Spec e quindi la fase di handshake è completata: il client ed il server possono cominciare a scambiare dati. In Fig. 69 è riportato lo schema sintetico della fase di handshake con Autenticazione Client Fig. 69 Handshake con autenticazione client SSL Record SSL Record Protocol procede sui messaggi da trasmettere nel modo seguente: li frammenta in blocchi adeguati, opzionalmente comprime i dati, applica un MAC, crittografa e infine trasmette il Tesi di Laurea di Elena Nuti 187
risultato. I dati ricevuti, viceversa, sono messi in chiaro, verificati, scompattati e riassemblati e, quindi, trasmessi al livello superiore. Quando il Record layer del protocollo SSL riceve i dati dai livelli superiori, in forma di blocchi non vuoti di dimensione arbitraria li frammenta senza interpretarli, in SSLPlaintext records aventi la seguente struttura: - type: il protocollo di livello più alto usato per processare il frammento incluso. - version: la versione del protocollo impiegato, nel nostro caso SSL v3.0. - lenght: la lunghezza in bytes del frammento SSLPlaintext che segue. Non può eccedere 2 14. - fragment: i dati provenienti dal livello applicazione. Questi dati sono trasparenti e considerati come un blocco indipendente per essere poi trattati dal protocollo di livello più alto specificato nel campo type. Fig. 70 Frammentazione dei dati In seguito tutti i records sono compressi tramite un algoritmo definito nello stato corrente della sessione, che trasforma una struttura SSLPlaintext in una SSLCompressed structure. La Tesi di Laurea di Elena Nuti 188
compressione deve essere senza perdita e non può aumentare la lunghezza del contenuto più di 1024 bytes, ovvero se la decompressione incontra un frammento che scompattato è lungo più di 2 14 bytes, deve segnalare un errore fatale. La struttura di un SSLCompressed è la seguente: - length: la lunghezza in bytes del seguente frammento SSLCompressed. La lunghezza non deve eccedere 2 14 + 1024. - fragment: la forma compressa del frammento SSLPlaintext Tutti i records sono quindi protetti usando gli algoritmi di crittografia e MAC definiti nello stato corrente della sessione che trasformano una struttura SSLCompressed in una SSLCiphertext che prevede i seguenti campi: - type: come in SSLCompressed - version: come in SSLCompressed - lenght: la lunghezza in bytes del seguente frammento SSLCiphertext. Non può eccedere 2 14 + 2048. - fragment: la forma cifrata del frammento SSLCompressed, MAC compreso; sono possibili due strutture diverse a seconda che sia stato scelto l'uso di un algoritmo di crittografia che lavora su tutto lo stream di bit dei dati, il GenericStreamCipher, o a blocchi, il GenericBlockCipher. A questo punto può avvenire la trasmissione dei dati, che prevede anche un numero di sequenza, in modo che i messaggi persi, alterati o intrusi siano rilevabili. Da notare inoltre che il MAC è calcolato prima della cifratura, ovvero viene crittografato l'intero blocco incluso il MAC. I dati ricevuti sono quindi messi in chiaro, verificati, scompattati e riassemblati e, quindi, consegnati ai client di livello superiore. Tesi di Laurea di Elena Nuti 189
C.3 SET Il protocollo SET (Secure Electronic Transaction) è stato sviluppato nel 1996 congiuntamente da Visa e MasterCard con lo specifico obiettivo di introdurre uno standard di autenticazione finalizzato a garantire la riservatezza delle transazioni con carta di credito su Internet. SET è in realtà un doppio protocollo: uno di certificazione e uno per il sistema di pagamento vero e proprio. Prima di fare acquisti on-line, ad ogni utente deve essere stato rilasciato un certificato da parte di una Banca. I certificati sono verificati attraverso un trust tree, ovvero ogni certificato è collegato al certificato digitale dell entità che lo ha firmato. Una entità di basso livello, risalendo l albero dei certificati, incontrerà una entità conosciuta che la assicura della validità. Questa operazione avviene di solito mediante la consegna di un software plug-in strettamente personale, rilasciato (su floppy o CD ROM) in singola copia, in grado di aggiungere funzionalità di borsellino elettronico ai comuni browser della rete. Quando si effettua un pagamento il plug-in interagisce in tempo reale con il server del rivenditore che a sua volta contatta una Certification Authority, cioè una società abilitata a certificare che l'utente sia possessore di carta di credito (una delle più note è la VeriSign). In caso di conferma la richiesta di pagamento viene inoltrata alla banca, che provvederà a inviare la conferma definitiva dell'avvenuta transazione. La stessa operazione viene eseguita, tramite l'intermediazione bancaria, anche da chi intende vendere qualcosa su Internet, in modo tale che entrambi i soggetti siano sicuri sull'identità della controparte. Tesi di Laurea di Elena Nuti 190
La seconda parte del protocollo SET si preoccupa invece di criptare il numero di carta di credito dell'utente così da renderlo illeggibile a chiunque, se non alla Banca. SET è basato su un algoritmo di cifratura RSA a 1024 bit che fornisce un livello di sicurezza molto elevato, però il protocollo non ha riscosso un grosso successo fra gli utenti e i rivenditori della rete. Come appare evidente anche dalla breve descrizione proposta di seguito, infatti, il sistema di scambio di certificati e chiavi risulta assai complesso. Le entità coinvolte nello scambio di informazioni sono: il Customer che effettua acquisti on-line, il Merchant cui il cliente si rivolge per effettuare acquisti, e due istituzioni finanziarie (tipicamente banche) collegate rispettivamente al Customer e al Merchant: l Issuer e l Acquirer. Vediamo adesso le varie fasi del pagamento tramite SET: 1) Il Customer vuole fare un acquisto presso il Merchant e gli invia la richiesta. 2) Il Merchant genera la risposta, la firma, e la invia al Customer insieme al proprio certificato ed a quello dell Acquirer. 3) Il Customer verifica i certificati, e crea due messaggi detti Order Info (OI) e Payment Instructions (PI), ricava i digest dei due messaggi, li concatena e li firma; inoltre cifra simmetricamente PI e lo firma con la chiave pubblica dell Acquirer. 4) Il Merchant verifica certificato e firma del Customer ed invia il certificato e la risposta, che è in realtà un digest firmato della richiesta. 5) Il Customer verifica il certificato e la firma. Tesi di Laurea di Elena Nuti 191
6) Il Merchant crea, firma e cifra l autorizzazione al pagamento e poi cifra il tutto in modo simmetrico, inviando la chiave simmetrica cifrata con la chiave pubblica dell Acquirer unitamente al PI cifrato e i certificati. 7) L Acquirer decifra e verifica i dati acquisiti, quindi firma ed invia la richiesta all Issuer. 8) L Issuer risponde all Acquirer 9) L Acquirer crea la risposta per il Merchant, la firma, la cifra in modo simmetrico ed invia la chiave simmetrica cifrata. La stessa cosa fa con il token di autorizzazione ricevuto dall Issuer. Il tutto è inviato al Merchant. 10) Il Merchant decifra e verifica la totalità delle informazioni, crea la richiesta di acquisizione del pagamento, la firma e la cifra; quindi cifra il tutto simmetricamente, compresa la chiave simmetrica. L insieme dei dati è inviato all Acquirer. 11) L Acquirer decifra e verifica ciò che gli è stato recapitato, quindi invia la richiesta all Issuer. 12) L Issuer invia la risposta all Acquirer. 13) L Acquirer cifra simmetricamente la risposta dell Issuer e cifra la chiave simmetrica. Le informazioni vengono inviate al Merchant, che le decifra e le verifica. Tesi di Laurea di Elena Nuti 192