Progetto Mini di Sistemi Distribuiti – AA 2007/08 Secure Group Communication with GDH.1 Alessandro Licata Caruso Matr:
Alessandro Licata Caruso Specifiche progetto Il protocollo di key agreement Diffie-Hellman può essere generalizzato a N partecipanti (si veda "Diffie-Hellman Key Distribution Extended to Group Communication"). Si implementi un servizio distribuito che offra una primitiva asincrona di join che dato un id del gruppo e la componente della chiave del client effettua il join del client al gruppo. Una volta costruita la chiave simmetrica di gruppo questa viene comunicata al client in maniera asincrona. Il client può in qualunque momento uscire dal gruppo invocando la primitiva di leave, nel cui caso gli altri membri ottengono la nuova chiave che garantisce al sistema la forward secrecy. Si implementi la versione più semplice del protocollo (indicata con GDH.1 nell'articolo) e si fornisca un semplice servizio di broadcast di messaggi cifrati che utilizza la chiave simmetrica stabilita da GDH.
Alessandro Licata Caruso Tecnologie utilizzate JINI RMI
Alessandro Licata Caruso Architettura generale Registrar registra un servizio Group (un proxy RMI) comunicazione remota tramite proxy RMI cerca un Group / ottiene un proxy RMI GroupClient GroupServiceProvider main: avvia e termina il processo. Crea un oggetto GroupImpl. lookup discovery: si occupa della ricerca multicast dei service locator. lease manager: si occupa del rinnovo delle lease delle registrazioni. registration: si occupa di registrare un proxy di GroupImpl presso i service locator via via trovati. key agreement: gestisce il protocollo di key agreement. message dispatching: si occupa di effettuare il broadcast dei messaggi. proxy thread: richieste remote degli utenti del gruppo attraverso il proxy RMI. GroupServiceProvider main: avvia e termina il processo. Crea un oggetto GroupImpl. lookup discovery: si occupa della ricerca multicast dei service locator. lease manager: si occupa del rinnovo delle lease delle registrazioni. registration: si occupa di registrare un proxy di GroupImpl presso i service locator via via trovati. key agreement: gestisce il protocollo di key agreement. message dispatching: si occupa di effettuare il broadcast dei messaggi. proxy thread: richieste remote degli utenti del gruppo attraverso il proxy RMI. GroupClient main: avvia il processo. prompt thread: gestisce l'interazione con l'utente attraverso una GUI. lookup discovery: si occupa della ricerca multicast dei service locator. inbox: si occupa di decriptare i messaggi in arrivo proxy thread: richieste remote del gruppo attraverso il proxy RMI. GroupClient main: avvia il processo. prompt thread: gestisce l'interazione con l'utente attraverso una GUI. lookup discovery: si occupa della ricerca multicast dei service locator. inbox: si occupa di decriptare i messaggi in arrivo proxy thread: richieste remote del gruppo attraverso il proxy RMI.
Alessandro Licata Caruso Interfaccia Group Espone tre primitive join() per effettuare laccesso ad un gruppo leave() per abbandonare un gruppo broadcast() per inviare un messaggio cifrato agli altri membri del gruppo
Alessandro Licata Caruso Protocollo di Key Agreement GDH.1 Occorre stabilire un ordinamento totale sullinsieme dei membri del gruppo Tutti i partecipanti M 1,…,M n condividono le seguenti informazioni prima di iniziare il protocollo: il modulo primo p il generatore g del gruppo algebrico individuato da p la dimensione,in bit, della chiave privata N i Due fasi: upflow e downflow upflow: raccoglie i contributi da tutti i membri del gruppo downflow: distribuisce le informazioni necessarie al calcolo della chiave simmetrica
Alessandro Licata Caruso Il membro M i riceve una collezione di valori intermedi V i = {g N 1, g N 1 N 2, …, g N 1 N 2 …N i-1 }, utilizza lultimo valore per calcolare g N 1 N 2 …N i-1 N i, quindi inoltra la collezione V i+1 = V i U {g N 1 N 2 …N i-1 N i } al membro M i+1. GDH.1 - Upflow M1M1 M2M2 M3M3 M4M4 M5M5 Dal segreto di sessione S 5 viene quindi ricavata la chiave simmetrica K 5 utilizzata per cifrare i messaggi scambiati fra i membri del gruppo.
Alessandro Licata Caruso GDH.1 - Downflow Dopo aver ottenuto K n, M n inizia la fase di downflow. In questa fase ogni membro M i effettua i elevamenti a potenza: uno per calcolare S n (e quindi ricavare K n ) e i-1 per calcolare i valori intermedi da inviare ai successivi membri del gruppo. M1M1 M2M2 M3M3 M4M4 M5M5
Alessandro Licata Caruso Key Agreement – Scelte implementative Key agreement centralizzato: è GroupImpl a coordinare lo scambio di messaggi di upflow- downflow fra i membri del gruppo Il protocollo di key agreement può essere interrotto da una join/leave; il key agreement viene riavviato solo se necessario Broadcast dei messaggi accettato solo se la fase di downflow è terminata se in fase di upflow (giunta a Mj) si verifica una join/leave di Mi con i > j e dopo la join/leave la condizione is_last(Mj) non cambia, non è necessario riavviare il key agreement se la fase di downflow non è terminata, un messaggio inviato da parte di un membro che ha già calcolato la nuova chiave può non essere leggibile da un altro membro che ancora attende il downflow, se nel frattempo il protocollo di key agreement è interrotto e riavviato
Alessandro Licata Caruso Interfaccia GroupUser Ogni membro del gruppo deve fornire al gruppo di appartenenza un oggetto remoto di tipo GroupUser. Linterfaccia espone i seguenti metodi: upflow() per effettuare la fase di upflow con lutente specificato downflow() per effettuare la fase di downflow con lutente specificato receiveMessage() per inviare un messaggio allutente specificato
Alessandro Licata Caruso Struttura dei package it.polimi.distsys0708.mini.gdh.service contiene le classi relative alla specifica del servizio Group it.polimi.distsys0708.mini.gdh.serviceimpl contiene le classi relative allimplementazione del servizio Group it.polimi.distsys0708.mini.gdh.client contiene le classi relative allimplementazione dei client del servizio Group