Sicurezza su Reti /2007 Commessa 1 : Protocollo di pagamento online utilizzato nella commessa

Sicurezza su Reti / Prof.Alfredo de Santis 2 Outline Processo decisionale Presentazione del protocollo Sicurezza del protocollo Difficoltà riscontrate Future espansioni Conclusioni finali

Sicurezza su Reti / Prof.Alfredo de Santis 3 Processo decisionale Fase 1: Riunione di tutto il gruppo –Diverse idee valutate –Scelta dellidea preferita dalla maggioranza –Raffinamento dellidea scelta Fase 2: Stesura del documento –Correzione di alcune falle nel protocollo Fase 3: Implementazione della commessa

Sicurezza su Reti / Prof.Alfredo de Santis 4 Outline Processo decisionale Presentazione del protocollo Sicurezza del protocollo Difficoltà riscontrate Future espansioni Conclusioni finali

Sicurezza su Reti / Prof.Alfredo de Santis 5 Obiettivi del protocollo Dal punto di vista del negozio bisogna garantire: –Che un attaccante non possa spacciarsi per lufficiale pagatore –Il non ripudio di una ricevuta dellufficiale pagatore –Che il pagamento non avvenga oltre un tempo limite predefinito per non bloccare la merce in magazzino

Sicurezza su Reti / Prof.Alfredo de Santis 6 Obiettivi del protocollo - 2 Dal punto di vista dellUfficiale 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 / Prof.Alfredo de Santis 7 Presentazione del protocollo Il cliente seleziona degli oggetti da acquistare e conferma lordine Il negozio invia al Ufficiale pagatore il token di richiesta pagamento e il redirect al cliente Il negozio è registrat o su u.p.? Errore NO 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 true Token di deny inviato al negozio DENIED 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 / Prof.Alfredo de Santis 8 Fase 1 Il negozio invia allUfficiale Pagatore un token contenente –Il proprio ID, assegnatogli in fase di registrazione dallUfficiale Pagatore –Il codice ordine univoco che ha generato –Limporto complessivo dellordine –La firma digitale dei precedenti campi con MD5withRSA LUfficiale pagatore, verifica lesattezza 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 dellufficiale Pagatore

Sicurezza su Reti / Prof.Alfredo de Santis 9 Fase 2 Dopo che il cliente ha accettato il pagamento presso lUfficiale Pagatore (fornendo le dovute credenziali) questo invia al cliente un token contenente: –Codice dellordine ricevuto nella fase precedente –Risultato deloperazione di pagamento (accettata o rifiutata) –Firma digitale dei campi precedenti con MD5withRSA Se loperazione di pagamento è accettata il negozio risponde con un file xml contenente: –Id del negozio –Codice dellordine –Accettazione o meno del pagamento (il timeout potrebbe essere scaduto) –Firma digitale dei campi precedenti con MD5withRSA

Sicurezza su Reti / Prof.Alfredo de Santis 10 Fase 2 (2) Se loperazione 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 / Prof.Alfredo de Santis 11 Fase 2 - esempio di file XML di risposta true WF2cG[...]Q0k3o=

Sicurezza su Reti / Prof.Alfredo de Santis 12 Fase 3 LUfficiale 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 dellavvenuto pagamento.

Sicurezza su Reti / Prof.Alfredo de Santis 13 Outline Processo decisionale Presentazione del protocollo Sicurezza del protocollo Difficoltà riscontrate Future espansioni Conclusioni finali

Sicurezza su Reti / Prof.Alfredo de Santis 14 Sicurezza del protocollo Il protocollo garantisce lUfficiale Pagatore in quanto: –Il negozio non può pretendere il pagamento di qualcosa per cui non abbia ricevuto un token di conferma dallU.P. –Il negozio non può falsificare il token (firma digitale eseguita con algoritmo MD5withRSA) –LU.P. non invia il token di ricevuta fin quando il negozio non ha confermato la validità dellordine

Sicurezza su Reti / Prof.Alfredo de Santis 15 Sicurezza del protocollo - 2 Il protocollo garantisce il negozio in quanto: –LU.P. non può cambiare arbitrariamente il pagamento Il token di richiesta di pagamento è firmato digitalmente con MD5withRSA –LU.P. non può ripudiare una ricevuta di pagamento

Sicurezza su Reti / Prof.Alfredo de Santis 16 Outline Processo decisionale Presentazione del protocollo Sicurezza del protocollo Difficoltà riscontrate Future espansioni Conclusioni finali

Sicurezza su Reti / Prof.Alfredo de Santis 17 Difficoltà nel processo decisionale Tante persone che si debbono mettere daccordo –Diverse idee di cosa dovesse riguardare il protocollo –Diverse idee su come risolvere i problemi Soluzione: –Ridurre al minimo lambito del protocollo Solo interazione tra U.P. e negozio –Lasciare le altre considerazioni alla implementazione del negozio e dellU.P. Ovviamente senza ridurre la sicurezza dellinterazione

Sicurezza su Reti / 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 dellU.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 / Prof.Alfredo de Santis 19 Problemi riscontrati nel protocollo - 2 Il protocollo è poco espandibile: –Non prevede una fase di handshake tra il negozio e lU.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 lidentità del negozio in quanto rilasciato dal una autorità di certificazione valida

Sicurezza su Reti / Prof.Alfredo de Santis 20 Outline Processo decisionale Presentazione del protocollo Sicurezza del protocollo Difficoltà riscontrate Future espansioni Conclusioni finali

Sicurezza su Reti / 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 / Prof.Alfredo de Santis 22 Outline Processo decisionale Presentazione del protocollo Sicurezza del protocollo Difficoltà riscontrate Future espansioni Conclusioni finali

Sicurezza su Reti / 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