Gagliardoni Elena, Pannacci Laura, Cantarini Damiano Clifford Neuman & Ari Medvinsky (1955) Un conto corrente NetCheque funziona allo stesso modo di un conto corrente tradizionale utilizzato per il pagamento degli assegni Micropagamenti Controlli: Firme Digitali, Protocollo Kerberos, Server certificati, Connessioni Crittografate Proxy Kerberos Unità Monetaria Account del Pagatore Firme Digitali =64 bit Ammontare dell’assegno Data di Scadenza Account del Beneficiario Assegno dell’Utente Server di autenticazione Kerberos (Ticket Kerberos ) Server di autenticazione Server di Contabilità del Beneficiario CheckSum Autenticatore Server di Contabilità del Beneficiario -Legge il Tiket Kerberos -Approva l’autenticatore Server Affidabili consentono collegamenti più rapidi tra i server di contabilità Confidenzialità Integrità Disponibilità Debolezza di NetCheque Limitato numero di clienti Non garantisce l’Anonimato Necessità di registrazione ai server NetCheque Nascita dalla diffusione dei programmi di intrattenimento Si paga solo ciò che si guarda Rischio della connessione Modello di PPV S: Server fornitore del servizio C: Cliente del servizio Step 1: Sottoscrizione Step 2: Browse (Scelta) Step 3: Richiesta e Visione Step 4: Pagamento e risoluzione delle dispute Rischi del Fornitore del Servizio ( S ) Video richiesto da un non abbonato C nega la richiesta C nega di aver ricevuto il servizio C dichiara che il servizio è stato interrotto Rischi dell’Utente ( C ) Hakeraggio dell’Account C viene caricato di servizi non richiesti C viene caricato di servizi non completi Sovraccarico di servizi richiesti Non-repudiation of Origin (NRO) (Invio di un messaggio che certifica la scelta) Non-repudiation of Billing (NRB) (Invio di un messaggio che certifica l’acquisto) Senza protocolli tra le due parti C è responsabile di ogni scelta fatta ed S è responsabile di ogni servizio richiesto Necessità di un Protocollo Protocollo SPPV (Simple Pay Per View) La sicurezza nello STEP 3 (la ricezione del servizio) è la base per un buon servizio PPV E’ necessario stabilire delle prove per evitare il Ripudio C Cliente del Provider C S : Id, Pr, Tg, sSC(S, Id, Pr, Tg) S C : ePC(Ks), sSS(C, Id, Tg, Ks) C S: H(C, S, Id, Tg, Ks) S Provider fornitore Conseguenze del protocollo SPPV C non può più rifiutare il servizio richiesto C deve pagare il servizio anche se incompleto Connessioni non stabili Servizio non conforme alle aspettative Necessità di un protocollo più equo Protocollo FPPV (Fair Pay Per View) Funzione HASH creata con una funzione Ricorsiva Hi(x)=H(Hi-1(x)) (i=1,2,…) dove H0(x)=x Funzione Ricorsiva C Cliente del Provider C S: Id, Pr, L, m, Hm(n),Tg,sSC(S,Id,Pr,L,m,Hm(n),Tg) S C: ePC(Ks), sSS(C,Id,Tg,Ks) C S: H(C,S,Id,Tg,Ks) S Provider fornitore E se il servizio dovesse saltare? Due tipi di Policy E’ il server a bloccare il servizio Anche l’utente può bloccare il servizio Stringa del servizio completo S, Id, Pr, L, m, Hm(n), Tg, sSC(S,Id,Pr,L,m,Hm(n),Tg), H0(n) L’arbitro controlla che: la firma digitale di C sSC(S,Id,Pr,L,m,Hm(n),Tg) è valida Hm(H0(n)) = Hm(n) dove H0(n) è l’ultima funzione H raccolta da S Decoder: Praticità di utilizzare il servizio a casa propria tramite una Smart Cart Il protocollo PPV video service ha i seguenti meriti: - Il compratore può scegliere quale programma guardare, a seconda del suo interesse -Il compratore può guardare in ogni momento quello che desidera paghi solo quello che guardi Inoltre l’utilizzo di questi protocolli assicura: -Non repudiabilità, siccome ci sono controlli durante la visione -Subscriber mobility. L’acquirente può farlo comodamente tramite la smart card -Praticità ed efficienza: il servizio può essere mantenuto senza invocazione di terze parti.