sicurezza su reti 2 - 2006/2007 commessa 1 : protocollo di pagamento online utilizzato nella...
TRANSCRIPT
Sicurezza su Reti 2 - 2006/2007
Commessa 1 :
Protocollo di pagamento online utilizzato nella
commessa
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 2
Outline
• Processo decisionale
• Presentazione del protocollo
• Sicurezza del protocollo
• Difficoltà riscontrate
• Future espansioni
• Conclusioni finali
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 3
Processo decisionale
• Fase 1: Riunione di tutto il gruppo– Diverse idee valutate– Scelta dell’idea preferita dalla maggioranza– Raffinamento dell’idea scelta
• Fase 2: Stesura del documento– Correzione di alcune falle nel protocollo
• Fase 3: Implementazione della commessa
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 4
Outline
• Processo decisionale
• Presentazione del protocollo
• Sicurezza del protocollo
• Difficoltà riscontrate
• Future espansioni
• Conclusioni finali
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 5
Obiettivi del protocollo
• Dal punto di vista del negozio bisogna garantire:– Che un attaccante non possa spacciarsi
per l’ufficiale pagatore– Il non ripudio di una ricevuta dell’ufficiale
pagatore– Che il pagamento non avvenga oltre un
tempo limite predefinito per non bloccare la merce in magazzino
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 6
Obiettivi del protocollo - 2
• Dal punto di vista dell’Ufficiale Pagatore bisogna garantire:– Che il negozio non possa esigere un
pagamento non avvenuto– Il cliente non deve poter affermare di aver
effettuato un pagamento mai avvenuto
• Da quello del Cliente bisogna garantire la non ripudiabilità di una ricevuta di pagamento
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 7
Presentazione del protocolloIl cliente seleziona degli oggetti da acquistare e
conferma l’ordine
Il negozio invia al Ufficiale pagatore il token di richiesta
pagamento e il redirect al cliente
Il negozio
è registrat
o su u.p.?
ErroreNO
Procedura di autenticazione cliente
su u.p.
SI
Il pagame
nto è accettat
o?
Token di accept al client
ACCEPTED Il timeout
è scaduto
?
Negozio risponde con HTTP Status Code 200
e result trueToken di deny inviato al
negozioDENIED
Client risponde con HTTP Status Code 204
Fine
Client risponde con HTTP Status Code 408
e result false
SI
NO
Fine
Token di ricevuta inviato al cliente
Client risponde con HTTP Status Code 204 e memorizza ricevuta
Fine
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 8
Fase 1
• Il negozio invia all’Ufficiale Pagatore un token contenente
– Il proprio ID, assegnatogli in fase di registrazione dall’Ufficiale Pagatore
– Il codice ordine univoco che ha generato– L’importo complessivo dell’ordine– La firma digitale dei precedenti campi con MD5withRSA
• L’Ufficiale pagatore, verifica l’esattezza dei dati e risponde con HTTP Status code 204 (No Content) o 400 (Bad Request) in caso di errore.
• Il negozio invia al suo cliente un redirect verso la pagina di pagamento dell’’ufficiale Pagatore
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 9
Fase 2
• Dopo che il cliente ha accettato il pagamento presso l’Ufficiale Pagatore (fornendo le dovute credenziali) questo invia al cliente un token contenente:– Codice dell’ordine ricevuto nella fase precedente– Risultato del’operazione di pagamento (accettata o rifiutata)– Firma digitale dei campi precedenti con MD5withRSA
• Se l’operazione di pagamento è accettata il negozio risponde con un file xml contenente:– Id del negozio– Codice dell’ordine– Accettazione o meno del pagamento (il timeout potrebbe
essere scaduto)– Firma digitale dei campi precedenti con MD5withRSA
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 10
Fase 2 (2)
• Se l’operazione di pagamento è stata rifiutata il negozio risponde semplicemente con 204 (No Content) e il protocollo termina qui
• Se il timeout del negozio è scaduto il protocollo termina sulla risposta del negozio
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 11
Fase 2 - esempio di file XML di risposta
<response>
<cod>1234</cod>
<id>12</id>
<result>true</result>
<signature>
WF2cG[...]Q0k3o=
</signature>
</response>
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 12
Fase 3
• L’Ufficiale Pagatore invia al negozio il token che gli era stato inviato nella fase 1, firmato con la sua chiave privata, e questo potrà essere utilizzato dal negozio come conferma dell’avvenuto pagamento.
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 13
Outline
• Processo decisionale
• Presentazione del protocollo
• Sicurezza del protocollo
• Difficoltà riscontrate
• Future espansioni
• Conclusioni finali
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 14
Sicurezza del protocollo
• Il protocollo garantisce l’Ufficiale Pagatore in quanto:– Il negozio non può pretendere il pagamento di
qualcosa per cui non abbia ricevuto un token di conferma dall’U.P.
– Il negozio non può falsificare il token (firma digitale eseguita con algoritmo MD5withRSA)
– L’U.P. non invia il token di ricevuta fin quando il negozio non ha confermato la validità dell’ordine
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 15
Sicurezza del protocollo - 2
• Il protocollo garantisce il negozio in quanto:– L’U.P. non può cambiare arbitrariamente il
pagamento• Il token di richiesta di pagamento è firmato
digitalmente con MD5withRSA
– L’U.P. non può ripudiare una ricevuta di pagamento
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 16
Outline
• Processo decisionale
• Presentazione del protocollo
• Sicurezza del protocollo
• Difficoltà riscontrate
• Future espansioni
• Conclusioni finali
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 17
Difficoltà nel processo decisionale
• Tante persone che si debbono mettere d’accordo– Diverse idee di cosa dovesse riguardare il
protocollo– Diverse idee su come risolvere i problemi
• Soluzione:– Ridurre al minimo l’ambito del protocollo
• Solo interazione tra U.P. e negozio
– Lasciare le altre considerazioni alla implementazione del negozio e dell’U.P.
• Ovviamente senza ridurre la sicurezza dell’interazione
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 18
Problemi riscontrati nel protocollo
• Il protocollo in origine era in due fasi– Invio del token di richiesta di pagamento da parte
del negozio– Invio della ricevuta da parte dell’U.P.– Conferma del negozio del fatto che il timeout non
fosse ancora scaduto
• Possibile attacco:– Il negozio invia una serie di pagamenti– Li paga con un suo utente fasullo– Li manda tutti in timeout, ma conserva le ricevute di
pagamento che sono valide!!!
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 19
Problemi riscontrati nel protocollo - 2
• Il protocollo è poco espandibile:– Non prevede una fase di handshake tra il negozio e l’U.P., e
questo rende obbligatorio fissare a priori gli algoritmi di cifratura e firma digitale da utilizzare.
• In caso di una vulnerabilità scoperta negli algoritmi è impossibile cambiare gli algoritmi utilizzatisenza perdere la retro compatibilità
• Non vengono definite le procedure di registazione del negozio– Al momento abbiamo solo informalmente deciso di obbligare
il negozio ad inserire la propria mail nel suo certificato che garantisce l’identità del negozio in quanto rilasciato dal una autorità di certificazione valida
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 20
Outline
• Processo decisionale
• Presentazione del protocollo
• Sicurezza del protocollo
• Difficoltà riscontrate
• Future espansioni
• Conclusioni finali
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 21
Future espansioni
• Definire le procedure di registrazione del negozio su U.P.
• Rendere il protocollo più espandibile– Ad esempio aggiungendo una fase di
handshake iniziale
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 22
Outline
• Processo decisionale
• Presentazione del protocollo
• Sicurezza del protocollo
• Difficoltà riscontrate
• Future espansioni
• Conclusioni finali
Sicurezza su Reti 2 2006/2007 - Prof.Alfredo de Santis 23
Conclusioni finali
• La stesura del protocollo è stato un ottimo banco di prova per:– Progettare da zero un protocollo– Simulare il funzionamento di una “standard
authority”