UNIVERSITÀ DEGLI STUDI DI GENOVA

Transcript

1 UNIVERSITÀ DEGLI STUDI DI GENOVA FACOLTÀ DI INGEGNERIA CORSO DI LAUREA MAGISTRALE IN INGEGNERIA DELLE TELECOMUNICAZIONI TESI DI LAUREA ANALISI ED ATTUAZIONE DELLA SICUREZZA IN UN SISTEMA DI TELECOMUNICAZIONE VoIP 22 MARZO 2013 Relatore: Chiar.mo Prof. Rodolfo Zunino Correlatore: Ing. Fabio Sangiacomo Controrelatore: Ing. Chiara Peretti Candidato: Massimiliano Baratella ANNO ACCADEMICO

2 Questa Tesi è dedicata alla tutta la mia Famiglia che mi ha supportato, agli Amici che ho la fortuna di avere e che mi hanno aiutato ed in particolare a mia zia Nella, a ciò che ha fatto e rappresentato per me Genova, 22/03/2013

3 Abstract This thesis has been carried out at the SeaLab laboratory of the department of Naval, Electric, Electronics and Telecommunications Engineering of the University of Genoa. It mainly focuses on issues related to VoIP systems, paying attention to security aspects that characterize them. Large amounts of information about VoIP and how communications can be secured are available in scientific literature and on the web. Nevertheless, in most practical achievements it's often preferred to apply none of them, exposing the network to high risks. The purpose of this work is to investigate possible threats that can affect VoIP systems, describing possible solutions to ensure the confidentiality and integrity of the communications. After an outlook of the state of art for IP-based telephone calls, a prototype composed of a VoIP PBX and some clients has been created. Due to its widespread adoption and open source nature, Asterisk has been chosen as a telephony platform, whereas different softphones has been tested for the client side. The main aim of this work was to fully understand all possible threats that can affect VoIP systems, in order to create a security model suitable to meet the requirements of a small/medium sized network. Several attacks have been carried out against the developed prototype, in order to evaluate its security robustness and the chance to eavesdrop calls or compromise users identity. Finally, the impact of the proposed security solutions on VoIP delay and QoS, has been discussed. I

4 Prefazione Questa tesi è stata svolta presso il laboratorio SeaLab del Dipartimento di Ingegneria navale, elettrica, elettronica e delle telecomunicazioni (DITEN) dell Università di Genova. Essa si focalizza sulle tematiche relative ai sistemi VoIP, con particolare attenzione agli aspetti inerenti la sicurezza che lo caratterizzano. Sono disponibili grandi quantità di informazioni sul VoIP e su come rendere sicure le sue comunicazioni, tuttavia nella maggior parte delle realizzazioni pratiche la scelta adottata è quella di non applicare nessuna di queste tecniche, esponendo la rete a rischi elevatissimi. Questa tesi mira ad investigare le possibili minacce che possono colpire un sistema VoIP, descrivendo le diverse alternative per la sua difesa. Dopo aver mostrato lo stato dell arte con tutte le possibili soluzioni disponibili per la sicurezza di una telefonata su IP, è stato realizzato un prototipo di rete composta da un centralino VoIP e da alcuni client che comunicano tra di loro. Per la scelta del centralino l attenzione è principalmente incentrata su Asterisk, di fatto la soluzione opensource più diffusa su scala mondiale, mentre lato client si sono testati diversi softphone disponibili. L obiettivo era quello di comprendere pienamente le possibili minacce perpetrabili ai danni del VoIP al fine di realizzare un modello di sicurezza adatto a soddisfare i requisiti di una rete di piccole dimensioni. Sono stati realizzati degli attacchi controllati al prototipo per valutare se fosse possibile intercettare le chiamate o compromettere le identità degli utenti. Considerando la caratteristica sensibilità al ritardo di una chiamata vocale, si è anche voluto approfondire l impatto che l adozione dei meccanismi crittografici proposti ha avuto sulla QoS della conversazione. II

5 Indice Indice Introduzione... 1 Motivazioni della Tesi... 3 Obiettivi... 4 Contenuto della tesi... 5 Capitolo Session Initiation Protocol (SIP) Introduzione Architettura del protocollo SIP Indirizzamento nel protocollo SIP Gestione della mobilità nel protocollo SIP Capitolo Meccanismi di sicurezza per il VoIP Concetti generali Crittografia Scambio di chiavi mediante Certificati Digitali Scambio di chiavi con Diffie-Hellman Meccanismi di Hash Modelli di sicurezza di SIP HTTP Digest Authentication IP Security (IPSec) Transport Layer Security (TLS) Security Multipurpose Internet Mail Extensions (S/MIME) Modelli di sicurezza per il Media Plane Secure Real-Time Transport Protocol (SRTP) Security Descriptions for media Streams (SDES) Key-Management Extensions for SDP (KMESDP) Capitolo Zimmermann Real-time Transport Protocol (ZRTP) Introduzione Funzionamento di ZRTP III

6 Indice Discovery Hash Commitment Diffie-Hellman Exchange Switch to SRTP and Confirmation Short Authentication String (SAS) Funzionamento in modalità Pre-shared Capitolo Realizzazione prototipo per test Configurazione rete e dispositivi Configurazione Asterisk Creazione utenze con funzioni base Configurazione per Signaling sicuro Configurazione per Media Plane sicuro Configurazione dei contesti FreeSwitch e configurazione per ZRTP Creazione certificati digitali per Asterisk Capitolo Test e valutazioni prestazionali Analisi procedura autenticazione HTTP Digest Authentication TLS Authentication Analisi cifratura del Media Plane Valutazione della scelta ottimale per il Key-Exchange Analisi prestazionale dell impatto della sicurezza sulla QoS Configurazione e scelta parametri per analisi Risultati ottenuti con SIP Risultati ottenuti con SIP-TLS Risultati ottenuti con SRTP-SDES Risultati ottenuti con ZRTP Capitolo Attacchi alla comunicazione Introduzione IV

7 Indice 6.2 Information Gathering Contromisure applicabili Denial of Service INVITE Flood UDP Flood RTP Flood Contromisure applicabili Attacchi MiTM all autenticazione ARP Spoof Cracking Authentication Contromisure applicabili Attacchi MiTM alla comunicazione (Eavesdropping) Nessuna protezione né per segnalazione né per traffico voce Protezione segnalazione con TLS e nessuna protezione per traffico voce Protezione segnalazione con TLS e protezione voce con SDES-SRTP Protezione segnalazione con TLS e protezione voce con ZRTP-SRTP Conclusioni Bibliografia Bibliografia siti Internet Appendice Cenni alla teoria delle Curve Ellittiche Introduzione Nozione di gruppo Curve Ellittiche Operazioni di su Curve Ellittiche Teorema di Hasse Coordinate Proiettive Definizione dei parametri per specificare la curva Problema del logaritmo discreto Elliptic Curve Diffie Helmann (ECDH) Crittografia a chiave pubblica su curva ellittica Ringraziamenti V

8 Introduzione Introduzione Con il termine VoIP (Voice over Internet Protocol) si fa riferimento ad una tecnologia nata negli anni 90 per consentire la comunicazione audio, e successivamente video, tra più terminali connessi ad una rete comune ed utilizzanti il protocollo IP. La tecnologia VoIP sfrutta IP per scambiare pacchetti contenenti un segnale audio opportunamente digitalizzato e compresso. È particolarmente flessibile e può essere utilizzato su diversi tipi di rete: privata casalinga o di una piccola azienda (LAN), di dimensione e copertura maggiore (WAN), fino alla grande rete che ormai ci circonda ed interconnette, Internet. Condizione imprescindibile e fondamentale è che la rete sia basata sul protocollo IP. I clienti abituati alle linee telefoniche tradizionali erano inizialmente restii a questa nuova forma di comunicazione a causa della qualità inferiore rispetto alla comunicazione basata su commutazione di circuito. In pochi anni però, grazie all aumento della banda a disposizione, alla nascita di nuovi codec audio e a sempre più efficienti protocolli per garantire la QoS (Quality of Service), si è raggiunto un livello tale da rendere il grado di piacevolezza di una chiamata basata su Voip equiparabile a quello di una telefonata tradizionale [1]. Ancora più determinante per il diffondersi della tecnologia sono i prezzi estremamente economici che consentono di abbattere la spesa della telefonata, soprattutto nel caso di chiamate su scala internazionale. I concetti chiave che hanno fatto la forza del VoIP sono riassumibili in due parole: Flessibilità ed Efficienza. La prima è dovuta al fatto che il VoIP di per sé si basa sullo standard IP, uno standard non proprietario ma frutto di accordi tra sviluppatori hardware e software che hanno deciso di premiarne la libertà di utilizzo da parte di chiunque. Grazie a ciò è possibile fruire del VoIP su qualsiasi terminale che supporti il protocollo IP: può essere implementato a livello hardware o a livello software, su infrastrutture dedicate allo stesso modo di computer o smartphone nati per scopi differenti. Al contrario la rete telefonica tradizionale basata su commutazione di circuito è un sistema di comunicazione che non consente il libero sviluppo di applicazioni e dispositivi per il suo utilizzo e non vanta un protocollo condiviso e standardizzato a livello internazionale. La possibilità di muoversi liberamente e connettersi alla rete ovunque sia disponibile un canale di accesso mantenendo invariato il proprio recapito telefonico è un altro dei vantaggi impareggiabili 1

9 Introduzione della scelta VoIP, così come la videochiamata o la videoconferenza o la possibilità di integrare lo scambio di messaggi testuali e multimediali. L uso della rete internet basata su commutazione di pacchetto porta il vantaggio di una maggiore efficienza in quanto, a differenza di ciò che avviene nella comunicazione Connection Oriented, i pacchetti possono essere instradati su percorsi differenti consentendo un ottimale utilizzo della risorsa. Nascono ovviamente nuove problematiche relative al far viaggiare sullo stesso mezzo pacchetti di natura diversa, contenenti informazioni di tipo eterogeneo che richiedono diversi vincoli di priorità. Internet nasce come rete Best Efford, ovvero che fa del suo meglio per consegnare al destinatario un messaggio ma senza nessuna garanzia sui tempi, sull ordine e sulla possibilità di perdita di pacchetti. Fortunatamente in parallelo alla tecnologia VoIP, ed indipendentemente da essa, si sono sviluppati protocolli di QoS sempre più efficienti che assistono la rete IP e si occupano di garantire un servizio migliore di quello Best Effort originale [1]. Un problema molto importante, che al momento è probabilmente il maggiore deterrente contro una totale migrazione verso la telefonia VoIP, è quello energetico. I telefoni tradizionali sono alimentati direttamente dalla linea telefonica ed in caso di blackout della rete elettrica continuerebbero a funzionare grazie a generatori e batterie interni alle centrali telefoniche. Al contrario un interruzione della fornitura di corrente renderebbe completamente inutilizzabile qualsiasi dispositivo VoIP. Un altro ostacolo alla completa dismissione dei sistemi a commutazione di circuito è il problema del tracciamento di una chiamata VoIP in caso di necessità per fini giudiziari, investigativi o per un emergenza. A causa della natura della rete a commutazione di pacchetto risulta infatti nettamente complicato risalire alla posizione geografica in tempi brevi del mittente o del destinatario di una telefonata. Questo aspetto è estremamente delicato soprattutto in ambito forense. Ad intralciare le operazioni va aggiunto il fatto che le autorità hanno bisogno di permessi particolari per accedere alle tabelle di routing di uno stato straniero a causa di limitazioni nella collaborazione internazionale. Capita così che facendo rimbalzare la comunicazione su server situati in paesi diversi si può rendere estremamente difficoltoso l essere rintracciato. In oltre in caso di emergenza una telefonata tradizionale è instradata verso la centrale più vicina rendendo tempestivo l invio dei soccorsi, per una comunicazione VoIP in alcuni casi questo è praticamente impossibile. Sono in fase di studio e sperimentazione però alcune tecniche simili a quelle utilizzate nella telefonia mobile per ottenere una georeferenziazione del chiamante, ma restano tutt ora non sufficientemente affidabili. 2

10 Introduzione Per fronteggiare soprattutto all inizio la limitazione imposta dalla scarsa banda sono stati sviluppati diversi codec audio e video. Fortunatamente i maggiori enti di standardizzazione internazionali hanno emanato regolamentazioni e raccomandazioni specificanti i terminali e i protocolli da utilizzare sui diversi tipi di reti e sottoreti. Per esempio tra i più diffusi in ambito VoIP ricordiamo H.323 standardizzato dall ITU [A] e SIP promosso dall IETF [B]. In particolare il secondo sta diventando sempre più dominante nell ambito della telefonia su rete a pacchetto, per tale motivo è stato scelto nel prototipo realizzato per i test eseguiti in questa tesi. Al giorno d oggi quasi tutti i fornitori di servizi VoIP consentono non solo di effettuare telefonate tra utenti esclusivamente VoIP, ma anche di interfacciarsi con i telefoni tradizionali con tariffe particolarmente vantaggiose. Per poter interconnettere tecnologie differenti sono ovviamente necessari opportuni centralini detti Internet Telephony Gateway che sono solitamente presenti presso i gestori telefonici. Mediante questi centralini avvengono le necessarie operazioni di conversione dei flussi audio in modo da adattarli ad un canale a commutazione di pacchetto o di circuito rispettivamente. Motivazioni della Tesi Le motivazioni che hanno spinto alla stesura della presente Tesi riguardano la volontà di indagare in maniera dettagliata i sistemi VoIP, vista la loro sempre crescente importanza del campo delle Telecomunicazioni. La sempre maggiore diffusione di dispositivi mobili con possibilità di connessione alla rete ha accentuato ancora di più quelle che sono le potenzialità della telefonia su rete IP, rendendo di fatto l alternativa VoIP una scelta quasi sempre vantaggiosa rispetto alla telefonia su rete radiomobile cellulare. Insieme ai vantaggi precedentemente elencati, compaiono però una varietà di problematiche relative agli aspetti di sicurezza che è importante analizzare. Partiamo dal capire cosa intendiamo per sicurezza. Esistono meccanismi di sicurezza validi universalmente? Esistono regole assolute che consentano di garantire contemporaneamente la prevenzione da qualsiasi minaccia senza penalizzare il servizio di comunicazione? È sempre indispensabile applicare protocolli di sicurezza e quali garanzie vi si richiedono? Bisogna partire dallo stabilire quali siano le potenziali minacce che possono affliggere una specifica rete e concentrarsi esclusivamente sulla difesa da queste. Nel caso di una rete LAN di piccole dimensioni, dove sono noti tutti gli utenti e potenzialmente non vi è connessione con il mondo esterno, non avrebbe senso implementare meccanismi di sicurezza 3

11 Introduzione sofisticati. Inoltre appesantire inutilmente il carico sulla rete risulterebbe controproducente, potrebbe condurre a blocchi del servizio e ad un peggioramento della QoS percepita senza portare alcun beneficio. Al contrario su una rete di grandi dimensioni, con accesso ad internet ed un numero di utenti elevato e variabile, l implementazione di protocolli opportuni è imprescindibile. Primo aspetto da considerare è quindi determinare quali sono le possibili minacce della rete che si vuole proteggere. Il traffico VoIP viene solitamente scambiato sulle stesse reti dedicate ad altri tipi di traffico, fattore che lo rende esposto agli stessi rischi del traffico dati tradizionale. Se per intercettare una comunicazione telefonica in precedenza bisognava accedere fisicamente al mezzo utilizzato (cioè ai cavi per il trasporto della linea telefonica o alle centraline di commutazione), richiedendo comunque un certo sforzo, il fatto di utilizzare per la stragrande maggioranza delle comunicazioni la rete internet condivisa a livello mondiale, rende le possibilità di violazione elevatissime. Si sono così aperte grandi sfide sia per gli hacker desiderosi di mostrare le falle del sistema che per le aziende ed i fornitori del servizio per garantirne la sicurezza. In questo contesto ricadono una grande quantità di problematiche. Bisogna garantire sia la segretezza dell identità dei chiamanti sia quella del messaggio che questi si scambiano, bisogna trovare meccanismi per rendere sicura la comunicazione senza però appesantire troppo la dimensione dei pacchetti da inviare in rete, per evitare un calo della qualità della conversazione. Non può essere dimenticato che il VoIP elargisce un servizio in real-time per cui sono necessarie reti affidabili e tempestive azioni di sicurezza al fine di garantire la QoS adeguata. Tutte queste tematiche imprescindibili saranno analizzate nel dettaglio nel proseguo di questa tesi. Obiettivi L obiettivo della tesi presentata è innanzitutto la comprensione esaustiva del VoIP e dei protocolli che lo supportano. Per fare ciò si desidera realizzare un prototipo dove effettuare i test di interesse, analizzando nel dettaglio sia la parte relativa al centralino che quella inerente il client, in modo tale da poter indagare il funzionamento di entrambi. Partendo da uno studio delle alternative possibili, si vuole scegliere un centralino, detto anche PBX (Private Branch Exchange), imparare a configurarlo ed a gestirlo correttamente e si vuole poi riuscire ad effettuare delle telefonate che lo attraversino. 4

12 Introduzione Vista la sempre maggiore importanza che sta assumendo il VoIP nelle aziende e gli enormi rischi che si corrono in caso di manomissione di informazioni riservate scambiate via telefono, si vuole offrire a chi legge un metodo per comprendere l importanza di una corretta cifratura delle comunicazioni. Essendovi diversi aspetti di sicurezza da considerare, si desidera analizzare i protocolli di trasmissione più adeguati a soddisfare determinati requisiti di protezione, misurandone la robustezza e l efficacia sulla cifratura. Senza dimenticare i vincoli stringenti sul ritardo propri di una comunicazione vocale, si cercheranno strumenti precisi per valutare l impatto dei protocolli di sicurezza sulla QoS complessiva del sistema. L obiettivo è quello di riuscire a scegliere un insieme di protocolli che consenta un elevato livello di protezione senza penalizzare la qualità della conversazione. Contenuto della tesi La strutturazione dell elaborato presenta una forma volta ad accompagnare il lettore in un percorso che inizi con lo studio del funzionamento del protocollo VoIP e degli aspetti di sicurezza ad esso relativi. Si prosegue andando ad analizzare maggiormente nel dettaglio i protocolli disponibili, mostrando come è stato creato e configurato un prototipo di rete dove eseguire i test desiderati. Vengono dunque effettuate una serie di prove volte a valutare sia la sicurezza dei protocolli che la variazione della qualità della telefonata. Si conclude quindi l elaborato con alcune considerazioni ricavate dai risultati raggiunti. Nel Capitolo 1 viene spiegata l importanza di un protocollo di segnalazione per il corretto funzionamento del VoIP. Si elencano le diverse scelte possibili focalizzando poi l attenzione e l analisi su quello comunemente più utilizzato, SIP. Nel Capitolo 2 sono spiegati brevemente alcuni concetti chiave relativi alla cifratura ed alla sicurezza di comunicazioni in generale. Ampio spazio è poi dedicato alla descrizione dello stato dell arte per la sicurezza di SIP e delle comunicazioni voce su VoIP Nel Capitolo 3 l attenzione è completamente rivolta al protocollo ZRTP, proposto come soluzione per la sicurezza a seguito dei risultati ottenuti da questo lavoro di Tesi. Viene mostrato nel dettaglio il modo in cui esso opera, focalizzando l attenzione sui punti chiave che lo rendono competitivo rispetto alle altre scelte disponibili. 5

13 Introduzione Nel Capitolo 4 viene mostrato in che modo è stato realizzato il prototipo per la realizzazione dei test. Si spiega brevemente il modo in cui i diversi dispositivi utilizzati sono stati configurati al fine di soddisfare le richieste e si mostra la configurazione della rete che li interconnette. Nel Capitolo 5 vengono mostrati i procedimenti per eseguire le prove che ci si era prefissati, con un analisi volta a coprire gli aspetti di sicurezza così come quelli relativi alla garanzia di qualità per la conversazione. In particolare grazie ad alcuni strumenti utilizzati è stato possibili confrontare in maniera precisa l impatto sulla QoS dei diversi meccanismi di sicurezza adottati. Nel Capitolo 6 vengono realizzati diversi tipi di attacchi ai danni del prototipo con la finalità di determinare le debolezze di alcuni dei meccanismi di sicurezza utilizzati. Si tenta di compromettere sia la segnalazione che la conversazione stessa, indicando i risultati ottenuti e proponendo eventuali contromisure per proteggersi da queste minacce. Nelle Conclusioni vengono riassunte le considerazioni ottenute dai test realizzati e viene spiegato in che modo il protocollo ZRTP si presenti come una valida soluzione per superare diverse limitazioni nelle attuali reti VoIP usate nelle aziende. Nell Appendice posta in coda a questa Tesi sono analizzati maggiormente nel dettaglio alcuni aspetti strettamente matematici relativi ad alcuni dei protocolli crittografici utilizzati. Viene specificata l importanza e l efficacia delle curve ellittiche in ambito crittografico. 6

14 Session Initiation Protocol (SIP) Capitolo 1 Capitolo 1 Session Initiation Protocol (SIP) 1.1 Introduzione Supponiamo che due utenti vogliano effettuare una chiamata utilizzando invece della linea telefonica tradizionale un sistema di tipo Voice over Internet Protocol. Senza perdita di generalità supponiamo che per farlo utilizzino due computer dotati di microfono, altoparlanti, scheda audio e quanto altro necessario, oltre ovviamente ad una connessione ad una rete basata su IP. Utilizzeranno un programma che farà in modo che la scheda audio campioni la voce dal microfono e la codifichi in un flusso di bit da incapsulare in pacchetti IP da trasmettere sulla rete. Nella realtà i pacchetti non vengono direttamente incapsulati in IP, viene usato un protocollo di livello superiore che per il caso di pacchetti multimediali è solitamente Real Time Protocol (RTP). Nella semplificazione precedente abbiamo anche assunto che i due utenti fossero entrambi già davanti al computer pronti a dialogare, e che le schede audio e gli altri componenti fossero già attivati e pronti alla comunicazione. Questo scenario appare abbastanza limitante; non sempre gli utenti possono essersi precedentemente accordati su un orario per effettuare la telefonata, ancora più inverosimile è che le risorse della scheda audio, della memoria e degli altri componenti restino allocate perennemente in attesa della chiamata. Serve pertanto un protocollo che si occupi di creare le sessioni, di inviare richieste di chiamata, di fare squillare i telefoni, di trasportare i messaggi relativi alla chiamata [2]. La tecnologia VoIP offre diversi protocolli per soddisfare i requisiti di segnalazione degli utenti. Al giorno d oggi non vi è uno standard ufficiale e si può scegliere tra diverse soluzioni. L ITU (International Telecomunication Union), l IETF (Internet Engeneering Task Force), l ETSI (European Telecomunication Standard Institute) [C], insieme ai maggiori provider di servizi VoIP stanno cercando di raggiungere uno standard comune. I protocolli maggiormente in uso al momento risultano: SIP (Session Initiation Protocol) della IETF 7

15 Session Initiation Protocol (SIP) Capitolo 1 H.323 della ITU IAX2, usato dai server Asterisk open source PBX Skinny Client Control Protocol, protocollo proprietario della Cisco Megaco (conosciuto anche come H.248) e MGCP MiNET, protocollo proprietario della Mitel XMPP, usato da Google Talk. Inizialmente pensato per l'im ora esteso a funzioni Voip grazie al modulo Jingle. Tra questi i più diffusi sono certamente i primi due: H.323 e SIP. Le somiglianze tra i due protocolli sono molte ma a differenziarli è principalmente la diversa filosofia con cui si prestano ad offrire il loro servizio. Entrambi supportano la negoziazione di parametri, la creazione di sessioni per effettuare chiamate VoIP, i meccanismi di crittografia ed i protocolli RTP e RTCP [3]. H.323 è però maggiormente legato alla vecchia concezione telefonica, è un protocollo completo che specifica tutta la pila protocollare e stabilisce rigidamente tutto ciò che è consentito o non è consentito fare. Questo approccio lo rende affidabile e sicuro, ma ne limita le possibilità di adattamento ad applicazioni future. Al contrario SIP è molto più semplice e leggero, sicuramente meno completo e dettagliato, ma pensato per interfacciarsi e cooperare con altri protocolli esistenti in internet. Questa flessibilità ha rappresentato il suo punto di forza rendendolo sempre di più vincente in un panorama come quello VoIP dove la ricerca di un sistema più leggero di H.323 era particolarmente sentita. Per questo motivo è stato scelto per effettuare i test che seguono in questa tesi e su di lui si focalizzerà la nostra attenzione. Definito dall RFC 3261 [4] (ma anche in molti altri), SIP è un protocollo di Signaling operante a livello di applicazione che viene standardizzato dall IETF come alternativa più semplice al protocollo H.323 promosso da ITU. La sua funzione è quella di creare, modificare e terminare delle sessioni multimediali tra due o più utenti. Non nasce per servire un fine specifico, al contrario si presenta come un protocollo multiservizio adatto ad interfacciarsi e supportare videocomunicazione, sistemi virtuali distribuiti, Instant Messaging (IM) o giochi interattivi. SIP svolge fondamentalmente le seguenti funzioni: Invitare gli utenti a partecipare ad una sessione Localizzare gli utenti Acquisire le preferenze degli utenti 8

16 Session Initiation Protocol (SIP) Capitolo 1 Determinare la capacità degli utenti Trasportare una descrizione della sessione Instaurare le connessioni di sessione Setup della chiamata, cioè la gestione di eventuali modifiche dei parametri di sessione Rilasciare le parti Cancellare la sessione in qualunque momento si desideri SIP è un protocollo che è nato sfruttando l esperienza di progettisti esperti in ambito HTTP, con il quale condivide pertanto diversi aspetti. Si tratta di un protocollo text-based, facilmente integrabile con internet grazie ad un meccanismo di indirizzamento che ricalca il classico indirizzamento mail del tipo user@domain.com. La parte iniziale dell indirizzo, user, può essere un nome o un numero associato ad un utente; domain specifica invece il dominio mediante un nome o un indirizzo di rete. Questo tipo di indirizzamento consente di slegare l utente da un determinato dispositivo fisico; il numero da chiamare non è associato ad un terminale ma ad una persona che può essere raggiunta su qualunque apparecchio utilizzi per effettuare l accesso. Per quello che concerne la trasmissione di flussi audio o video, SIP non si occupa di specificare le operazioni da eseguire, demandando tale compito al già collaudato protocollo RTP/RTCP. Allo stesso modo tutte le funzioni relative alla garanzia di QoS non sono qui fissate ma ottenute dall integrazione con i protocolli Resource reservation Protocol (RSVP) e Session Description Protocol (SDP) che si occupano dell allocazione delle risorse necessarie ad instaurare una chiamata con la qualità desiderata. 1.2 Architettura del protocollo SIP I principali elementi che compongono un architettura basata su protocollo SIP (Figura 1.2) sono i seguenti [5]: User Agent Sono hosts fully qualified che si occupano di realizzare il protocollo SIP (Figura 1.1). Si dividono in User Agent Client (UAC) che si occupa di far partire la SIP Request verso un User Agent Server (UAS) che è un host che si occupa di ricevere e rispondere alle SIP 9

17 Session Initiation Protocol (SIP) Capitolo 1 Request degli (UAC). Un unico User Agent può però anche comportarsi da client o da server a seconda dei casi: interpreta la parte del client nel momento in cui vuole instaurare una sessione di comunicazione con un altro User Agent, assume invece il ruolo di server se è lui ad essere invitato da un UAC. Figura 1.1 User Agent Proxy Server È un dispositivo intermedio all interno della rete SIP, può rispondere direttamente alle richieste o inoltrarle ad un UAC, UAS o ad un altro server. Solitamente opera limitatamente ad un dominio presso cui è registrato l utente. Un Proxy Server analizza i parametri di instradamento dei messaggi, occultando la reale posizione del destinatario, essendo come visto in precedenza l indirizzo una convenzione all interno di un dominio di appartenenza. Esistono due categorie principali di Proxy Server: 1. Proxy Stateless: inoltrano i messaggi senza conservarne una traccia, sfruttando unicamente informazioni di instradamento fornite nel messaggio stesso. I vantaggi derivati da tale approccio sono la velocità e la semplicità, ma non sono in grado di gestire le ritrasmissioni di messaggi e di realizzare forme avanzate di instradamento quali biforcazioni o attraversamenti ricorsivi. 2. Proxy Stateful: considerano le informazioni ottenute dalle richieste precedenti, per questo sono più complessi e lenti, ma permettendo l'uso di alcuni servizi aggiuntivi, come la ritrasmissione e un instradamento più sofisticato. Redirect Server Si occupa di accettare e reindirizzare le richieste SIP sia da parte di un client, che da parte di un server. Fornisce ad un client l indirizzo del server successivo verso l host di destinazione 10

18 Session Initiation Protocol (SIP) Capitolo 1 e consente all UAC di cambiare temporaneamente la sua posizione geografica rimanendo comunque raggiungibile allo stesso indirizzo SIP. Non si occupa di accettare o elaborare chiamate. Registrar Server È un server che accetta le richieste di registrazione provenienti dagli UA ed immagazzina le informazioni all interno del Location Server del dominio che gestisce. In questo modo viene tenuta traccia della locazione degli utenti in maniera simile a quanto accade con Home Location Register (HLR) delle reti GSM, ma con la differenza che si registra l utente e non il terminale. Location Server Implementa un servizio di risoluzione degli indirizzi basato su un database contenente le informazioni relative ad ogni utente (indirizzo IP, URL, script) e alla locazione di Proxy, Gateway e altri Location Server. Quando un UAC vuole iniziare una sessione con un UAS deve per prima cosa trovare l indirizzo a cui il l UAS è raggiungibile, di norma l UAC non può contattare direttamente il Location Server. Questo compito è solitamente svolto dai Proxy Server e dai Redirect Server che si occupano di contattare il Location Server ed indirizzare opportunamente le richieste dell UAC. Figura 1.2 Esempio architettura SIP 11

19 Session Initiation Protocol (SIP) Capitolo Indirizzamento nel protocollo SIP Ad ogni utente di un sistema VoIP viene assegnato un indirizzo univoco detto SIP URI, definito in [6] come: A uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. L indirizzo è simile ad un indirizzo mail, contraddistinto da una URL: sip:utente@dominio:port;parameters Utente: identifica un particolare dispositivo VoIP, può trattarsi di un numero così come di un alias Dominio: specifica quale sia l host che fornisce il servizio SIP, può esservi indicato un indirizzo IP o un nome. Port: indica la porta da utilizzare, convenzionalmente la porta standard per i messaggi SIP è la 5060 Parameters: insieme di tutti i parametri che possono essere specificati: protocollo di trasporto usato, tipo di dispositivo utilizzato, ecc L indirizzo può contenere numeri, fax, alias, parametri. Possono anche essere utilizzate le URL per i numeri telefonici locali o globali ove siano presenti Gateway che permettano l accesso alla tradizionale rete telefonica. La procedura di segnalazione prevede che un UAC ed un UAS si scambino dei messaggi sotto forma di richieste e risposte. Una sequenza di una richiesta ed una o più risposte prende il nome di Transaction-ID. Un messaggio SIP è distinguibile da tre parti principali: Start line Header fields Message body Mostriamo in seguito l esempio di un messaggio di INVITE dove l utente Alice tenta di inoltrare una chiamata verso l utente Bob, il campo body fornisce la descrizione della sezione (SDP) (Tabella 1.1): 12

20 Session Initiation Protocol (SIP) Capitolo 1 Start Line Header fields Message body INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bk776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 151 v=0 o=alice IN IP4 client.atlanta.com s=c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 Tabella 1.1 Messaggio SIP Secondo il protocollo SIP all interno di un messaggio REQUEST possono essere utilizzati sette metodi differenti: I. INVITE: permette di avviare il setup di una sessione. In esso il caller inserisce i dettagli sul tipo di sessione che vuole creare definendo tutto mediante il protocollo Session Description Protocol. II. ACK: permette al caller di confermare la ricezione della risposta alla parte remota. Il corpo dell'ack può contenere una descrizione della sessione nella usuale codifica SDP. In caso contrario, il chiamato deve considerare ancora validi i parametri di sessione presenti nell'invite ricevuto precedentemente. III. BYE: è usato da un UA per chiudere una sessione attiva. IV. CANCEL: permette di annullare una richiesta pendente di connessione, non ha nessun effetto nel caso in cui la sessione sia già stata instaurata. V. REGISTER: permette la registrazione presso un Registrar Server del proprio SIP URI. VI. OPTION: permette al client di chiedere al server informazioni su eventuali estensioni da esso supportate. VII. UPDATE: permette agli utenti di una chiamata di variare i parametri di una sessione senza modificare lo stato della stessa I messaggi di risposta contengono un codice numerico che specifica lo stato attuale della richiesta. A testimonianza della forte similitudine tra SIP ed il protocollo HTTP, i codici utilizzati per i 13

21 Session Initiation Protocol (SIP) Capitolo 1 messaggi di segnalazione corrispondono quasi perfettamente a quelli usati nel Web (l unica differenza è che in tale contesto sono presenti due classi aggiuntive per Reference ed External links). Le risposte sono raggruppate in sei generiche categorie: 1xx: Informational Sono risposte inviate al client per comunicargli che una richiesta è stata ricevuta e la si sta processando. Dopo aver ricevuto una risposta provvisoria, il client deve attendere nuove informazioni sull esito dell operazione senza ritrasmettere la richiesta. 2xx: Success La richiesta è stata ricevuta, capita ed accettata. Il server notifica la riuscita con un messaggio 200 OK. 3xx: Redirection Permette al server di fornire al richiedente la nuova posizione dell utente o di altri elementi del dominio al fine di portare a termine con successo la chiamata. 4xx: Client Error Si tratta di risposte che indicano il fallimento di un operazione. Invitano il client a non inoltrare una nuova richiesta senza prima aver modificato alcuni parametri della stessa. 5xx: Server Error La richiesta è apparentemente valida, ma il server non è in grado di risolverla. 6xx: Global Failure La richiesta non può essere risolta da nessun server. I messaggi SIP Request vengono instradati seguendo le informazioni contenute all interno dell URL. I messaggi di SIP Response vengono inviati sullo stesso percorso ma a ritroso, non vi è alcuna tabella di stato all interno dei Proxy ma viene utilizzata l informazione contenuta nel campo Via degli header fields (in caso di necessità è comunque possibile memorizzare il percorso dei messaggi INVITE con Record-Route e forzarlo sulle successive richieste con Route). Un link tra due utenti SIP può essere stabilito direttamente tra gli UA (Figura 1.3) o mediante un meccanismo di tipo hop-by-hop (Figura 1.4). Figura Collegamento diretto tra due terminali 14

22 Session Initiation Protocol (SIP) Capitolo 1 In questo primo caso due utenti creano la sessione, effettuano la conversazione e terminano la sessione senza passare per alcun Proxy: 1) Alice (UAC) manda una richiesta di INVITE verso Bob (UAS) 2) Bob risponde accettando la richiesta e con un messaggio 180 Ringing 3) Alice invia un ACK per informare bob che possono iniziare la conversazione 4) A questo punto è stata creata la sessione e i due utenti sono in grado di conversare tra loro 5) Bob termina la chiamata ed invia un messaggio BYE ad Alice 6) Alice risponde con un messaggio 200 OK e la sessione viene terminata Nel secondo caso (Figura 1.4) Alice e Bob non comunicano direttamente tra loro ma vengono messi in collegamento da una serie di Proxy: Figura Collegamento tra terminali mediante proxies 15

23 Session Initiation Protocol (SIP) Capitolo 1 1) Alice (UAC) invia una richiesta INVITE verso il Proxy atlanta 2) Il Proxy atlanta ritrasmette la richiesta verso il Proxy biloxi 3) Il Proxy atlanta contemporaneamente risponde ad Alice con un messaggio 100 Trying 4) Il Proxy biloxi indirizza il messaggio INVITE verso Bob 5) Il Proxy biloxi risponde al Proxy atlanta con un messaggio 100 Trying 6) L UAS invia un messaggio 180 Ringing informando il Proxy Biloxi che il telefono di Bob sta squillando 7) Il Proxy biloxi inoltra il messaggio 180 Ringing verso il Proxy atlanta 8) Il Proxy atlanta inoltra il messaggio 180 Ringing ad Alice 9) Bob risponde al telefono e l UAS invia un messaggio 200 OK al Proxy biloxi 10) Il Proxy biloxi inoltra la risposta 200 OK al Proxy atlanta 11) Il Proxy atlanta inoltra la risposta 200 OK ad Alice 12) L UAC invia un ACK verso Bob. È ora attivata la sessione e la voce viene scambiata secondo le specifiche prefissate con il protocollo RTP 13) Bob Finisce la telefonata ed invia un BYE direttamente ad Alice 14) Alice risponde con un messaggio 200 OK e la sessione viene terminata Cerchiamo ora di analizzare un caso più completo che coinvolga tutti i componenti di un architettura SIP visti in precedenza. Supponiamo pertanto di essere nella situazione in cui un utente Bob voglia effettuare una chiamata verso un utente Alice di cui conosce solo l URI alice@unige.it. Saranno necessari diversi passaggi prima di poter instaurare la comunicazione (Figura 1.5): Figura Collegamento tra due terminali con Location Server 16

24 Session Initiation Protocol (SIP) Capitolo 1 a) Per prima cosa Bob deve contattare un server DNS che gli consenta di risolvere il nome in un indirizzo IP b) Il DNS risponde specificando l indirizzo del Proxy c) Bob inoltra dunque una richiesta INVITE verso il Proxy indicando che vuole parlare con Alice d) Il Proxy contatta il Location Server per scoprire quale sia l indirizzo a cui Alice è al momento raggiungibile e) Il Location Server fornisce l attuale indirizzo di Alice al Proxy f) Il Proxy inoltra la richiesta verso l UAC Alice g) Alice risponde con un 200 OK Message alla richiesta effettuata dal Proxy h) Il Proxy inoltra il messaggio verso Bob i) Bob ed Alice iniziano la loro conversazione 1.4 Gestione della mobilità nel protocollo SIP Tra le caratteristiche più innovative e vantaggiose dell utilizzo di SIP come protocollo di segnalazione per VoIP vi è il fatto che, con l indirizzamento URI, un utente non sia legato ad un terminale specifico ma raggiungibile su dispositivi differenti. La mobilità degli utenti è consentita grazie al processo di registrazione, che avviene con un meccanismo simile a quello delle reti radiomobili cellulari, con la differenza che in quel contesto si registrano i terminali mentre nelle reti VoIP si registrano le persone fisiche. Come accennato in precedenza, indispensabile risulta il Location Server che fornisce al Proxy che ne fa richiesta l ultima locazione presso cui si è registrato un determinato utente (Figura 1.6). Figura Registrazione utente presso due dispositivi 17

25 Session Initiation Protocol (SIP) Capitolo 1 L utente si registra utilizzando prima il telefono di ufficio e successivamente quello di casa. Entrambe le richieste di registrazione vengono inoltrate al Registrar Server che provvede a sua volta comunicare con un Update al Location Server i diversi indirizzi presso cui è raggiungibile l utente. Il messaggio REGISTER conterrà tutte le locazioni presso cui si sceglie di registrarsi. Il client può specificare delle preferenze sull indirizzo predefinito così come indicare l ordine di indirizzi a cui tentare di inoltrare le chiamate (Figura 1.7). Figura Messaggio Register 18

26 Meccanismi di sicurezza per il VoIP Capitolo 2 Capitolo 2 Meccanismi di sicurezza per il VoIP 2.1 Concetti generali Nello scegliere una soluzione basata su VoIP piuttosto che PSTN, i venditori e gli utenti devono essere consapevoli di quelli che sono i rischi e le minacce che accompagnano questi sistemi. Basandosi sull architettura IP, segue che il VoIP erediti tutte le problematiche ad essa relative. Pertanto non c è da stupirsi se le metodologie di attacco tipiche di una rete tradizionale siano efficaci per disturbare, intercettare o interrompere una telefonata su rete a pacchetto. Per garantire la sicurezza di un sistema VoIP sarà indispensabile intervenire con tecniche opportune ad ogni livello funzionale (Tabella 2.1). Application layer (SIP/SDP/RTP/RTCP) Transport layer (TCP/UDP) Network Layer (IP) Physical layer (Ethernet) Tabella Stack protocollare VoIP Proteggere una comunicazione multimediale significa rendere sicura sia la segnalazione (SIP) che il traffico audio (RTP), tenendo conto dei requisiti specifici dei due tipi di traffico. Un ulteriore minaccia è data dal fatto che la segnalazione viene scambiata utilizzando la stessa rete su cui transita il flusso multimediale. Come sarà più chiaro dai capitoli seguenti, spesso compromettere la segnalazione coincide con il rendere non più sicuro anche il media plane [7]. Bisogna prestare 19

27 Meccanismi di sicurezza per il VoIP Capitolo 2 attenzione al fatto che, mentre il flusso audio può essere criptato end-to-end, il traffico SIP deve essere interpretabile dai nodi intermedi sul percorso e pertanto non esiste un algoritmo off-the-shelf valido contemporaneamente per segnalazione e media. Al fine di prevenire e combattere le numerose e crescenti minacce, è stata fondata un organizzazione specifica, VOIPSA (Voice over IP Security Alliance) che: aims to fill the void of VoIP security related resources through a unique collaboration of VoIP and Information Security vendors, providers, and thought leaders. VOIPSA ha pubblicato diversi articoli inerenti le minacce ai sistemi VoIP, elencando e specificando nel dettaglio una numerosa quantità di attacchi perpetrabili ai danni del protocollo [D]. A livello generale è possibile raggruppare le possibili minacce per una comunicazione VoIP in: Negazione di Servizio Intercettazioni e analisi del traffico Furti di identità Accesso non autorizzato Frodi Il compito di un efficiente architettura di sicurezza è quello di impedire queste minacce proteggendo il sistema ai diversi livelli protocollari con meccanismi differenziati ed appropriati agli stessi. Prima di inoltrarsi nello specifico nelle tecniche adottate per proteggere la segnalazione ed il traffico multimediale VoIP, vediamo quali sono i principi e gli algoritmi utilizzabili Crittografia La crittografia è una tecnica tramite cui si rende un messaggio da scambiare tra due parti interpretabile solo dalle stesse mediante uno specifico meccanismo. Etimologicamente deriva dalle parole greche Kriptos = Nascosto ed Egraphos = Scrittura. Il messaggio originario che le parti vogliono scambiarsi prende il nome di plaintext mentre il risultato dell applicazione dell algoritmo crittografico è chiamato ciphertext. Un algoritmo è considerato sicuro se, a partire dalla conoscenza dello stesso e del ciphertext, non è possibile risalire al plaintext a meno che non si conosca la chiave utilizzata per cifrare [8]. Una classificazione generale può dividere gli algoritmi esistenti in: 20

28 Meccanismi di sicurezza per il VoIP Capitolo 2 Cifrari Simmetrici: utilizzano la stessa chiave sia per cifrare che per decifrare il messaggio Cifrari Asimmetrici: utilizzano una coppia di chiavi, una per cifrare e l altra per decifrare il messaggio Nei Cifrari Simmetrici entrambe le parti che vogliono scambiare un messaggio cifrato devono essere in possesso di una chiave segreta condivisa. Non è parte dell algoritmo specificare in che modo le due entità debbano essere entrate in possesso della chiave; si basa sull assunzione che questa sia stata ottenuta mediante un canale sicuro. Se un intruso riesce ad entrare in possesso della chiave è in grado di decifrare tutti i messaggi che transitano sulla rete, ne segue che sia fondamentale avere un modo per scambiarla senza che possa essere intercettata. Appare evidente come questo scenario sia particolarmente limitante e poco realistico in una rete di grandi dimensioni dove può capitare che le parti non si conoscano e non possano scambiare la chiave in sicurezza (Figura 2.1). Figura Cifrario Simmetrico Per comunicare in maniera sicura con Alice, Bob sceglie di cifrare il messaggio che vuole inviare con la chiave condivisa precedentemente accordata. Sul canale transita un messaggio cifrato incomprensibile a chiunque se non ad Alice, che possiede la chiave per decifrarlo. Questi algoritmi sono caratterizzati da un intrinseca semplicità; altresì chiara è la velocità del procedimento di crittografia, che rende l algoritmo particolarmente adatto ad applicazioni quali comunicazioni realtime, caratterizzate da stringenti vincoli sul ritardo. Un alternativa agli algoritmi di crittografia a chiave simmetrica è stata proposta nel 1978 da Ron Rivest, Adi Shamir e Leonard Adleman che misero a punto un nuovo sistema detto RSA per eliminare il problema dello scambio della chiave su un canale sicuro, il nuovo sistema prese il nome di crittografia a chiave pubblica. Questo algoritmo di sicurezza utilizza una coppia di chiavi, una 21

29 Meccanismi di sicurezza per il VoIP Capitolo 2 pubblica ed una privata, che vengono utilizzate per cifrare e decifrare il plaintext. Solo uno dei partecipanti alla sessione possiede entrambe le chiavi; in particolare la chiave pubblica viene scambiata liberamente sul canale mentre quella privata viene tenuta segreta. Ovviamente per garantire il funzionamento dell algoritmo è necessario che non sia possibile risalire alla chiave privata partendo dalla conoscenza di quella pubblica e che il messaggio sia decifrabile solo mediante l uso della chiave privata. Chiunque voglia comunicare con il dispositivo detentore di entrambe le chiavi chiede la trasmissione della chiave pubblica, cifra il plaintext utilizzando la stessa ed invia il ciphertext. Solamente il destinatario che è in possesso della chiave privata sarà in grado di risalire al messaggio originale. Questo introduce una differenza concettuale tra il canale instaurato con un meccanismo a chiave simmetrica e quello nato da chiave pubblica. Nel primo caso parliamo di un canale two-way, dove i partecipanti sono entrambi capaci di cifrare e decifrare un messaggio. Nel secondo caso parliamo invece di un canale one-way, perché solo uno dei partecipanti è in grado di decifrare il messaggio. Un ulteriore importante proprietà dei cifrari a chiave pubblica è il fatto che la chiave privata può essere utilizzata per cifrare, con lo stesso algoritmo, un messaggio che può essere decifrato utilizzando la chiave pubblica. Ovviamente questo aspetto non è importante per garantire la sicurezza del messaggio, dato che chiunque può entrare in possesso della chiave pubblica e decifrarlo, ma è utile per l autenticazione, in quanto permette a chi riceve di essere certo che chi ha scritto il messaggio possedesse entrambe le chiavi. Tornando al classico esempio della chiamata tra due utenti, per scambiare un messaggio in sicurezza, Bob deve cifrare lo stesso utilizzando la public key di Alice ed inviarlo successivamente sul canale. Solo lei sarà in grado di interpretarne il contenuto, dopo averlo decifrato utilizzando la sua private key. I cifrari asimmetrici presentano proprietà in gran parte opposte ai corrispondenti simmetrici. Da un lato hanno il vantaggio di poter scambiare liberamente la chiave pubblica sul canale senza la necessità di avere a disposizione un mezzo sicuro, di contro il procedimento per la creazione della coppia di chiavi è nettamente più oneroso. Come conseguenza non è adatto a cifrare singolarmente ogni messaggio da mandare in una rete. La massima efficienza si ottiene da un uso congiunto dei due algoritmi al fine di sfruttare i vantaggi di entrambi. Per cifrare i dati è più opportuno utilizzare un cifrario simmetrico, essendo come visto il procedimento più rapido e semplice. Di contro l algoritmo a chiave pubblica si presta come canale sicuro necessario a scambiare la chiave simmetrica utilizzata per garantire la riservatezza dei messaggi. Volendo quindi rendere sicura una comunicazione si può scegliere di seguire il seguente procedimento (Figura 2.2): 22

30 Meccanismi di sicurezza per il VoIP Capitolo 2 1) Bob genera una Session Key (equivalente della chiave simmetrica) da utilizzare per cifrare tutto il flusso di dati. 2) Bob utilizza la chiave pubblica di Alice per cifrare la chiave di sessione 3) Viene inviata sul canale la chiave mascherata grazie alla Public Key di Alice 4) Alice decifra il messaggio utilizzando la sua chiave privata e recupera la Session Key 5) Bob ed Alice effettuano traffico cifrato con la chiave condivisa Figura Cifrario Asimmetrico Scambio di chiavi mediante Certificati Digitali Gli algoritmi per la generazione di una coppia di chiavi pubblica e privata sono in gran parte pubblici e reperibili online. Nel momento in cui vengono generate le due chiavi l utente deve tenere nascosta quella privata e rendere disponibile quella pubblica. Supponendo di essere nel classico scenario di Alice e Bob, una volta che Alice ha generato le due chiavi rimane il problema di come possa Bob essere certo che la chiave pubblica che vede sia realmente di Alice e non di un intruso. Uno degli schemi maggiormente diffuso per risolvere il problema prevede l uso di Certificati Digitali che leghino la Public Key all identità di un utente. Il meccanismo per effettuare tale operazione prende il nome di Public Key Infrastructure (PKI). Un Certificato Digitale è una sorta di documento contenente le seguenti informazioni: 23

31 Meccanismi di sicurezza per il VoIP Capitolo 2 Identità dell entità che viene certificata Public Key dell entità che viene certificata Identità della Certification Authority che firma il certificato Un identificativo dell algoritmo usato per l identificazione Altre informazioni opzionali La Certification Authority è un entità la cui affidabilità deve essere riconosciuta dalle parti comunicanti. I certificati vengono firmati dalla CA, pertanto se Bob ritiene affidabile la CA che ha firmato il certificato presentato da Alice, allora ritiene affidabile l identità di Alice stessa e la provenienza della Public Key. Il meccanismo di fiducia su cui si basano le CA è assolutamente scalabile permettendo di creare delle chains of trust (Figura 2.3). Figura Struttura ad albero di Certification Authorities Scambio di chiavi con Diffie-Hellman Un valido meccanismo per effettuare lo scambio di una chiave condivisa segreta su un canale insicuro è stato proposto nel 1976 da Whitfield Diffie e Martin Hellman. All epoca in cui fu presentato il meccanismo sfortunatamente la tecnologia non ne consentiva ancora una valida implementazione, sono stati necessari altri vent anni prima che il sistema venisse reso pubblico, anche a seguito di alcune aggiunte e modifiche. Lo schema fondamentale del funzionamento risulta il seguente (Figura 2.4): 1) Alice e Bob decidono una base p ed un numero g che siano molto grandi e primi tra di loro 24

32 Meccanismi di sicurezza per il VoIP Capitolo 2 2) Alice e Bob scelgono ciascuno un numero casuale A e B e calcolano rispettivamente =g A mod p e β =g B mod p 3) Alice e Bob si scambiano sul canale i valori appena calcolati e β 4) Alice e Bob calcolano rispettivamente β A mod p e B mod p ottenendo lo stesso risultato che può essere usato come chiave simmetrica. Figura Meccanismo Diffie-Hellman In questo modo se anche un utente avesse osservato lo scambio dei messaggi non sarebbe in grado di risalire alle chiavi private A e B poiché tale operazione richiederebbe la risoluzione del logaritmo discreto (maggiori dettagli su tale problema e sul caso di uso di DH su curve ellittiche sono forniti in Appendice) Meccanismi di Hash Gli algoritmi che effettuano l operazione prendono in ingresso stringhe di lunghezza variabile e ne restituiscono una di lunghezza fissa. Il valore ottenuto dalla funzione di Hash è anche detto Digest, vedremo come questo verrà utilizzato per l autenticazione degli utenti in SIP. L obiettivo di un algoritmo di hash è quello di garantire semplicemente che il contenuto di un messaggio non sia stato modificato durante il transito sulla rete, mentre non sono assicurate Confidentiality ed Authentication. Viene calcolato un Hash Value applicando una determinata funzione matematica al messaggio da trasmettere e vengono inviati congiuntamente sia il messaggio stesso che il valore di Hash appena calcolato. Il ricevente effettua l Hash dei valori ricevuti e lo confronta con quello 25

33 Meccanismi di sicurezza per il VoIP Capitolo 2 inviatogli dal mittente al fine di sincerarsi che non vi siano state modifiche sul canale. I più comuni algoritmi di Hash sono Message Digest 5 (MD5) [9], che genera un output a 128 bit e Secure Hash Algorithm (SHA) che genera un output a 160 bit [10]. 2.2 Modelli di sicurezza di SIP HTTP Digest Authentication Il primo passo per garantire sicurezza in una sessione SIP è quello di autenticare le entità coinvolte. Grazie a questa operazione si verificano le credenziali dei soggetti evitando di scambiare informazioni con parti non autorizzate. Il protocollo SIP utilizza HTTP Digest Authentication per l autenticazione di un User Agent Client, secondo quanto specificato in [11]. Aspetto non trascurabile è il fatto che nel modello originale non sia prevista l autenticazione mutua; segue che solo l identità del client viene garantita mentre altrettanto non avviene per il SIP Proxy o in generale per il Server (questa può essere verificata con altre tecniche come spiegato successivamente). Il protocollo si basa su un meccanismo challange-response dove il proxy invia al client una stringa detta nonce, composta da caratteri generati casualmente, in risposta ad una iniziale richiesta INVITE ricevuta (Figura 2.5). La risposta fornita dall UAC viene generata a partire da username, password, Request-URI, dominio ed ovviamente il nonce. Solitamente viene utilizzato MD5 come algoritmo di hash, ma vi sono diverse possibilità a seconda del centralino e dei client scelti. Figura Challenge message 26

34 Meccanismi di sicurezza per il VoIP Capitolo 2 Secondo quanto dichiarato per le specifiche SIP, la procedura per l autenticazione di un utente ricalca il meccanismo HTTP Digest Authentication secondo lo schema procedurale seguente (Figura 2.6): 1) Alice invia al Proxy un messaggio REGISTER per autenticarsi presso il dominio 2) Il Proxy nega l accesso invitando Alice ad autenticarsi mediante un messaggio 401 UNAUTHORIZED. All interno di questo messaggio incapsula il nonce che Alice dovrà utilizzare per l algoritmo MD5 3) Alice invia una nuova richiesta REGISTER contenente questa volta il risultato di MD5 calcolato usando il nonce ricevuto più i parametri in suo possesso 4) Il Proxy verifica che il digest comunicato da Alice corrisponda con quello che anche lui ha calcolato autonomamente ed in quel caso accetta la registrazione comunicandolo con un messaggio 200 OK Figura HTTP Digest Authentication Secondo il meccanismo proposto, viene garantita l identità del client e si impediscono attacchi replay limitatamente ai messaggi INVITE e REGISTER, non sono protetti i messaggi CANCEL, ACK e BYE. Questo è dovuto al fatto che mentre per i primi lo schema prevede l invio di una risposta contenente un nonce dal server verso il client, i messaggi CANCEL, BYE ed ACK non sono seguiti da alcuna risposta. Per ovviare a ciò è stato proposto che se le credenziali di un utente sono state verificate dopo il messaggio di REGISTER risultino valide anche per tutti i messaggi successivi scambiati tra UAC e UAS. Inoltre non vengono garantite Integrity e Confidentiality per 27

35 Meccanismi di sicurezza per il VoIP Capitolo 2 nessun tipo di messaggio, sono pertanto consigliati ulteriori accorgimenti per impedire ad un intruso di modificare le richieste dei messaggi SIP IP Security (IPSec) IPSec è uno stack protocollare che è stato sviluppato per garantire Data-confidentiality, Dataintegrity e Data-origin authentication nello scambio di pacchetti a livello di IP [12]. Può utilizzare sia tecniche basate sull uso di certificati digitali che meccanismi basati su chiave condivisa. La fase di scambio delle chiavi usa il protocollo Internet Key Exchange (IKE) [13], basato sull algoritmo di Diffie Hellman. Nel caso di trasporto di segnalazione SIP non può essere utilizzato su base end-toend in quanto i nodi intermedi attraversati devono essere in grado di leggere le intestazioni per instradare correttamente i pacchetti. Tuttavia, risulta utile in quanto consente di instaurare comunicazioni sicure su base hop-by-hop tra host o tra host e server. Gli scenari possibili in cui è possibile utilizzare IPSec sono: Rendere sicura una comunicazione tra due nodi SIP o tra reti SIP Rendere sicura una comunicazione tra un UA e una rete SIP In realtà IPSec è più adatto a reti in cui i partecipanti abbiano già una relazione prestabilita di fiducia quali per esempio le VPN. Le specifiche originali di SIP [4] dicono solamente che IPSec può essere utilizzato per proteggere la segnalazione ma non indicano in che modo ciò debba essere realizzato Transport Layer Security (TLS) Nei meccanismi proposti in [4] per proteggere SIP figura anche il protocollo Transport Layer Security (TLS), che può svolgere i compiti di garanzia di autenticazione, riservatezza ed integrità cosi come viene utilizzato in ambito HTTP per la navigazione sicura (HTTPS) (Tabella 2.2). Fornisce sicurezza a livello di trasporto solo nel caso in cui per questo sia scelto Transmission Control Protocol (TCP) [14]. Sfruttando l uso di certificati digitali, questo protocollo può garantire una mutual authentication tra client o tra client e server. In realtà in ambiente SIP per questioni di praticità sono poco usati i certificati lato client in quanto non è sempre possibile o conveniente installarli; pertanto tutto si 28

36 Meccanismi di sicurezza per il VoIP Capitolo 2 riduce ad un autenticazione monodirezionale mediante un certificato del server. Il protocollo si divide in diverse fasi: Negoziazione della chiave crittografica e degli algoritmi data-integrity Scambio della chiave crittografica ed autenticazione secondo il meccanismo a chiave pubblica Scambio di traffico cifrato mediante chiave simmetrica Transport Layer Security (Authentication, Integrity, Privacy) Transport layer (TCP) Network Layer (IP) Tabella Stack Protocollare TLS In ambito SIP solitamente un utente, dopo aver stabilito una connessione sicura con TLS sulla porta 5061 (è quella di default ma può essere modificata), richiede al server il suo certificato. Dopo aver verificato la CA che ha firmato il certificato digitale, il client ricava la chiave pubblica del server e la usa per cifrare la trasmissione della chiave simmetrica [15]. Per avere un autenticazione reciproca è possibile integrare il meccanismo HTTP Digest Authentication spiegato in precedenza. La maggiore limitazione di TLS è che viene utilizzato su base hop-by-hop pertanto quando un terminale inoltra una richiesta ha una falsa sensazione di sicurezza in quanto non può essere certo che il protocollo sia supportato da ogni nodo sul percorso verso il destinatario. Questo accade perché ogni proxy attraversato ha la necessità di leggere l header del messaggio SIP per poter instradare correttamente il pacchetto sulla rete. Dunque il messaggio viene decifrato e successivamente cifrato ad ogni hop. Il protocollo SIP consente di utilizzare il protocollo TLS specificando un indirizzamento denominato SIP Secure (SIPS) con cui si richiede che la segnalazione sia trasportata su tutto il percorso utilizzando TLS. Un mittente può rifiutare di mandare un messaggio se non ha garanzia che suddetto meccanismo di sicurezza sia adottato su tutto il tragitto. Il formato di indirizzamento di SIPS è praticamente identico ad un URI tradizionale SIP, con la sola aggiunta della s in coda: sips:alice@domain.com. 29

37 Meccanismi di sicurezza per il VoIP Capitolo Security Multipurpose Internet Mail Extensions (S/MIME) S/MIME è uno standard introdotto per la protezione delle che sfrutta il concetto di firma digitale e di cifratura a chiave simmetrica ed asimmetrica. È in grado di garantire autenticazione, riservatezza ed integrità dei messaggi che protegge [16] ed è il meccanismo di sicurezza proposto nella stesura originale di SIP. S/MIME permette di rendere sicuro un messaggio SIP e, a differenza di quanto visto per TLS, permette di garantirla su base end-to-end e non solo hop-by-hop. Ogni UA deve possedere un certificato digitale e l identità apposta nel certificato deve corrispondere all URI dell User Agent che lo possiede. Il meccanismo su cui si basa S/MIME prevede che messaggio sia firmato con la chiave privata del mittente ed inviato verso un destinatario allegando al messaggio cifrato il certificato digitale contenente la chiave pubblica. Ovviamente tutto è cifrato con la chiave pubblica del destinatario. Non appena questo riceve il messaggio, lo decifra utilizzando la sua chiave privata e verifica se la firma è corretta utilizzando la chiave pubblica del mittente contenuta nel certificato allegato. Mediante questo procedimento è possibile garantire autenticazione, segretezza ed integrità delle informazioni scambiate. Per funzionare in questo modo è ovviamente necessaria la presenza di una PKI responsabile della chiave pubblica del destinatario; questo il punto più lacunoso del sistema in quando non sono chiariti, nelle diverse specificazioni e negli aggiornamenti di SIP, come questi compiti debbano essere svolti e da chi. In (Figura 2.7) è presente un messaggio SIP dove la parte tra * rappresenta il corpo SDP protetto con S/MIME che non risulta quindi interpretabile durante il transito in rete. Figura Messaggio SIP protetto son S/MIME 30

38 Meccanismi di sicurezza per il VoIP Capitolo Modelli di sicurezza per il Media Plane Proteggere il signaling è fondamentale per una chiamata sicura basata su VoIP; i meccanismi mostrati in precedenza, utilizzati con criterio, portano ad una segnalazione sicura, soprattutto se usati congiuntamente ed in maniera intelligente. Tutto quello fatto a livello di segnalazione però non riguarda lo scambio di flussi multimediali in maniera sicura, problema correlato ed altrettanto importante che va affrontato a parte. Volendo trasportare flussi audio, notoriamente sensibili al ritardo, bisogna prestare altresì attenzione a questo vincolo e scegliere adeguatamente i meccanismi di sicurezza. È possibile utilizzare TLS per garantire un elevata protezione del traffico multimediale in maniera simile a quanto visto per il signaling, ma come detto in precedenza questo richiede un protocollo connection oriented quale TCP che mal si presta ai requisiti real-time tipici del VoIP. Pertanto, benché questo approccio sia possibile a livello teorico, è consigliabile solo su reti di dimensioni ridotte e con un numero limitato di utenti. Al crescere degli stessi l eccessivo overhead introdotto da TCP porta ad un calo della QoS rendendo difficoltosa la comunicazione. Una valida soluzione per utilizzare un sistema di sicurezza simil-tls è proposta in [17], dove viene specificato il protocollo Datagram Transport Layer Security (DTLS) che sfrutta dei meccanismi simili a quelli del TLS nonostante utilizzi UDP. Questo protocollo è stato proposto per il VoIP, tuttavia non è ancora ufficialmente supportato dalla maggior parte dei gestori di telefonia e dai PBXs in quanto non specificatamente ottimizzato per RTP e piuttosto recente (2006). Si sceglie di concentrare l analisi di questa tesi su protocolli di sicurezza a livello media plane largamente implementati e diffusi per il VoIP, per il quale lo standard de facto risulta SRTP Secure Real-Time Transport Protocol (SRTP) Per lo scambio di traffico multimediale, il protocollo maggiormente usato in ambito SIP è senza dubbio Real-Time Transport Protocol (RTP) [18]. Cosi come definito nella sua versione originale, suddetto protocollo si presta ottimamente a trasportare dati in tempo reale su base end-to-end. Tuttavia, benché svolga ottimamente il suo compito, non prevede nella stesura originale, alcun meccanismo di sicurezza. Per ovviare a questa limitazione l IETF ha standardizzato successivamente un nuovo protocollo, di fatto un estensione di RTP, chiamato Secure Real-Time Transport Protocol (SRTP) [19]. Il protocollo offre confidenzialità, integrità, autenticazione e 31

39 Meccanismi di sicurezza per il VoIP Capitolo 2 protezione contro attacchi replay sia per flussi RTP che per quelli Real-Time Control Transport Protocol (RTCP). L'algoritmo scelto per la crittografia è Advanced Encription Standard in Counter- Mode (AES-CTR) con l uso di chiavi a 128 o 256 bit. Questo tipo di algoritmo permette di eseguire i compiti crittografici in parallelo all'elaborazione dei codec audio, riducendo cosi la latenza. La sua forza è proprio in questa caratteristica, riesce a raggiungere throughput elevati pur mantenendo contenuta l estensione dei pacchetti. Come per qualsiasi protocollo di sicurezza, vi è la necessità di utilizzare sistema di key-exchange tramite cui generare una master key da cui sia possibile generare le chiavi di sessione per cifrare il traffico multimediale. Sfortunatamente SRTP non prevede un meccanismo specifico per effettuare tale operazione, rendendo necessaria l integrazione con altri protocolli. In ambito VoIP è possibile raggruppare l insieme dei meccanismi di key-agreement per lo scambio della chiave in due categorie a seconda di dove viene scambiata la chiave: Generazione e scambio delle chiavi realizzato durante la fase di Signaling Generazione e scambio delle chiavi realizzato direttamente a livello di Media Plane Per la prima categoria, sono stati proposti due approcci leggermente differenti, entrambi legati ad SDP: Security DEscriptions for media Streams (SDES) e Key Management Extensions for SDP (KMESDP). Per la seconda categoria invece esistono diverse soluzioni, di cui si vuole citare quella che sembra al giorno d oggi maggiormente candidata a diventare lo standard de facto: Zimmermann Real Time Protocol (ZRTP) Security Descriptions for media Streams (SDES) Questo meccanismo per lo scambio di chiavi, utile ad instaurare una sessione sicura con SRTP, è stato standardizzato nel 2006 e rappresenta ad oggi uno dei più diffusi sistemi di key-agreement per il VoIP [20]. Figura Esempio messaggio SDES 32

40 Meccanismi di sicurezza per il VoIP Capitolo 2 Il funzionamento è piuttosto semplice, prevede l aggiunta di alcuni campi all interno del corpo SDP del messaggio (Figura 2.8): Crypto: identifica la tecnica crittografica da utilizzare Inline: specifica la chiave da utilizzare nell algoritmo crittografico dichiarato nella riga precedente Come si deduce intuitivamente, affinché questo sistema funzioni, è necessario che il corpo del messaggio sia protetto, quindi è necessario che il signaling sia protetto. In caso di mancata sicurezza nello scambio dei messaggi SIP, il protocollo SDES è totalmente compromesso in quanto un intruso può conoscere sia il meccanismo di cifratura utilizzato che la chiave stessa. L utilizzo di SDES è consigliabile solo in canali di comunicazione dove la segnalazione sia protetta con meccanismi quali TLS, dove vi è un autenticazione del server mediante certificato digitale ed una dei client secondo il meccanismo HTTP Digest Authentication spiegati nei paragrafi precedenti. Dopo aver completato la fase di verifica delle identità reciproche, Alice e Bob dichiarano all interno di SDP l algoritmo di crittografia e la chiave concordata. Conclusasi dunque la fase di segnalazione SIP, il traffico multimediale generato successivamente dalle parti è protetto mediante SRTP con la chiave appena scambiata (Figura 2.9). Figura Schema comunicazione sicura con SDES 33

41 Meccanismi di sicurezza per il VoIP Capitolo Key-Management Extensions for SDP (KMESDP) Definito in [21] è stato standardizzato nel 2006 e costituisce una valida alternativa per lo scambio delle chiavi crittografiche necessarie per implementare SRTP. Dal paragrafo precedente si è appreso come SDES estenda i campi di SDP per alloggiarvi le informazioni necessarie allo scambio di chiavi per cifrare i flussi multimediali. È stato altresì sottolineato come tale meccanismo dipenda fortemente da altri protocolli per rendere sicuro il signaling. Il meccanismo qui presentato è stato sviluppato per rendere indipendente la sicurezza tra SIP e RTP, come conseguenza è applicabile anche ad ambienti dove non vi sia alcuna garanzia di sicurezza per il signaling o dove questa sia assicurata solo su base hop-by-hop. Non prevede un meccanismo unico per il key-exchange, al contrario ne consiglia diversi, tutti preesistenti e perfettamente integrabili. Uno dei più utilizzati è Multimedia Internet KEYing (MIKEY), appositamente disegnato per applicazioni multimediali in real-time e pertanto perfettamente conforme alle richieste per SRTP [22]. Così come SDES, anche KMESDP interviene aggiungendo alcune voci al corpo SDP del messaggio, la differenza è che questo fa semplicemente riferimento al protocollo di key-management designato che opera poi indipendentemente. Essendo ZRTP al giorno d oggi la più innovativa e valida soluzione per risolvere il problema dei key-exchange direttamente tra i client, ed essendo risultato la scelta vincente limitatamente ai diversi aspetti analizzati in questa Tesi, il suo funzionamento viene spiegato nel dettaglio nel capitolo seguente. 34

42 Zimmermann Real-time Transport Protocol (ZRTP) Capitolo 3 Capitolo 3 Zimmermann Real-time Transport Protocol (ZRTP) 3.1 Introduzione La scelta di dedicare un intero capitolo a questo argomento è dovuta alla crescente importanza che esso sta assumendo nel panorama VoIP ed al fatto che si è dimostrato il meccanismo in grado di soddisfare tutti i requisiti di sicurezza per il prototipo studiato, la cui realizzazione è descritta nel capitolo 4. Al fine di fornire al lettore informazioni certe, questo capitolo spiega dettagliatamente il metodo riferendosi al documento RFC originale[23]. Come visto nel Capitolo 2, scambiare la chiave necessaria al protocollo SRTP mediante messaggi SIP introduce nuovi problemi di sicurezza. In particolare usare il signaling per il trasporto di un informazione strettamente riservata richiede che lo stesso sia protetto adeguatamente, per evitare che un malintenzionato possa entrare in possesso della chiave di cifratura. Per ovviare al problema della sicurezza della segnalazione, un approccio totalmente indipendente da essa è stato proposto da Phil Zimmermann. La sua idea in pratica consiste nello scambiare le chiavi direttamente tra i peer attraverso l algoritmo Diffie-Hellman a livello media-plane. SIP viene utilizzato solo per identificare le parti coinvolte secondo lo schema spiegato in seguito. Il protocollo non necessita della presenza di alcun meccanismo di PKI o CA, le chiavi vengono generate e scambiate durante le sessioni multimediali, superando così la limitazione di dover interagire con terze parti. Il protocollo è disegnato per integrarsi perfettamente con RTP, al punto che i flussi ZRTP ed RTP vengono multiplexati sulla stessa porta (ZRTP usa ovviamente un suo header in modo da distinguere i due traffici). ZRTP fornisce protezione contro attacchi Man-in-The-Middle (MiTM) e, nel caso in cui a livello di segnalazione sia garantita sicurezza su base end-to-end, assicura anche autenticazione e integrità su pari scala. Un'altra proprietà del protocollo è quella della Perfect Forward Security, che prevede che le chiavi di cifratura siano distrutte al termine di ogni sessione. Questo rappresenta tra l altro un aspetto controverso a livello legale, in quanto gli operatori telefonici sono tenuti per legge a fornire alla magistratura richiedente tutte le registrazioni delle conversazioni avvenute sotto la 35

43 Zimmermann Real-time Transport Protocol (ZRTP) Capitolo 3 loro copertura. Grazie alla proprietà prima citata queste registrazioni sono criptate e assolutamente indecifrabili persino per gli operatori stessi. Questa caratteristica slega l operatore telefonico dalla sicurezza nella conversazione tra gli utenti, che diventano di fatto gli unici responsabili della stessa. 3.2 Funzionamento di ZRTP Figura Schema generazione chiave per SRTP L obiettivo fondamentale del protocollo ZRTP è quello di generare una chiave segreta condivisa da utilizzare per SRTP. Questa si può ottenere secondo diversi meccanismi di scambio, tra i quali quello maggiormente diffuso risulta Diffie-Hellman (adoperato in modalità Finite Field (FFDH) o Elliptic Curve (ECDH)). In generale, come spiegato in seguito, la procedura per la generazione del segreto condiviso è molto sofisticata e prevedere l utilizzo di numerosi parametri, in parte generati autonomamente dai terminali coinvolti ed in parte concordati tra i due mediante lo scambio di informazioni (Figura 3.1). Prima ancora di iniziare lo scambio di messaggi propriamente ZRTP, le 36

44 Zimmermann Real-time Transport Protocol (ZRTP) Capitolo 3 parti possono incapsulare in un frame SIP un parametro che prende il nome di Signaling Secret (SIGS) ottenuto come: SIGS = H (Call-ID To-Tag From-Tag) Dove H indica l operazione di Hash, Call-ID è un identificatore univoco della chiamata generato in maniera casuale e To-Tag e From-Tag sono identificatori delle due parti coinvolte. In realtà questa parte è opzionale e viene computata se il canale SIP è ritenuto affidabile; in ogni caso il valore di SIGS viene ripetuto durate la parte propriamente ZRTP. La prima operazione da compiere per avviare una sessione è quella di fissare i ruoli tra le due parti Alice e Bob identificando: Initiator Responder Di regola l utente che manda il primo messaggio Hello viene eletto ad Initiator mentre l altro assume il ruolo di Responder, un altra possibilità è che il ruolo spetti a chi presenti il valore hv più elevato (hv spiegato nel paragrafo seguente Hash Commitment). Il meccanismo di Key- Agreement in modalità Diffie-Hellman si compone di quattro fasi principali: 1. Discovery 2. Hash Commitment 3. Diffie-Hellman Exchange 4. Switch to SRTP and Confirmation Le operazioni comprese nelle fasi appena elencate vengono svolte da Alice e Bob in parte in autonomia ed in parte in collaborazione, mediante lo scambio di messaggi secondo l ordine mostrato in Figura 3.2 Figura Scambio chiavi con ZRTP 37

45 Zimmermann Real-time Transport Protocol (ZRTP) Capitolo Discovery All interno della fase Discovery i due utenti verificano se l altra parte sia in grado di supportare ZRTP e si scambiano informazioni relative agli algoritmi da usare (non è detto che ogni terminale supporti tutti gli algoritmi, mediante questa fase si cerca un punto d incontro). Queste informazioni sono contenute all interno del messaggio Hello. I campi più significativi contenuti sono: ZID: Si tratta di un identificativo univoco a 96 bit creato al momento dell installazione del software su un terminale Version: Indica quale versione del protocollo ZRTP viene implementata (al momento della stesura di questa tesi, 2013, esiste solo la versione 1.10, ma questo campo servirà per differenziare le versioni future) Hash Algorithms: ognuna delle parti dichiara quali algoritmi supporta, mediante questa negoziazione si raggiunge una scelta condivisa da entrambi (al momento si può usare solamente SHA-256) Cipher Algorithm: ognuna delle parti dichiara quali algoritmi supporta, mediante questa negoziazione si raggiunge una scelta condivisa da entrambi (si utilizza AES disponibile nelle varianti a 128 o 256 bit) Key Agreement Type: questo metodo è fornito per far concordare alle parti quale algoritmo tra utilizzare tra i possibili Hash Commitment Dallo scambio dei messaggi Hello le due parti sono in grado di derivare i protocolli da utilizzare. L Initiator invia al Responder un nuovo messaggio, Commit, che specifica quale funzione di hash, quale cifratura e quale key-exchange. Se presenti, vengono anche scambiate due chiavi rs1 e rs2 detenute dai dispositivi in una memoria cache. Sono chiavi relative a sessioni precedenti associate agli specifici ZID e consentono di realizzare la caratteristica di key continuity propria di ZRTP. Le due chiavi possono o meno combaciare tra i due utenti, a seconda di ciò cambia il modo in cui sono utilizzate per generare la chiave finale, come spiegato successivamente. Per la scelta di quale versione di Diffie-Hellman utilizzare sono disponibili 4 possibilità, divise per tipologia e per lunghezza di p, due per le FFDH e due per ECDH (Tabella 3.1). 38

46 Zimmermann Real-time Transport Protocol (ZRTP) Capitolo 3 Identificativo Parole messaggio Significato DH3K 117 FFDH con p=3072 bit DH2K 85 FFDH con p=2048 bit EC25 37 ECDH con p=256 bit EC38 45 ECDH con p=384 bit Tabella Versioni DH supportate L ordine con cui un utente elenca le modalità supportate corrisponde anche ad un indicatore delle sue preferenze. Per spiegare il funzionamento del protocollo, supponiamo che sia stato scelto FFDH con p=3072 (il meccanismo è ovviamente simile anche in caso di Curve Ellittiche, con le dovute differenze nella scelta dei parametri). Durante lo scambio dei messaggi Hello le due parti hanno concordato i valori relativi alla base ed al modulo da utilizzare per l algoritmo, rispettivamente g e p. A questo punto Bob genera una coppia di chiavi da usare con Diffie-Hellman, una chiave segreta svb ed una pubblica pvb secondo la relazione: pvb=g svb mod p Alice esegue lo stesso tipo di operazione, creando la sua coppia di chiavi sva e pva. Bob calcola anche il risultato di un hash di una concatenazione della sua pvb con informazioni contenute nel messaggio Hello di Alice, chiama il risultato dell operazione hvb e lo invia all interno del messaggio Commit. hvb= H(pvB Alice s Hello) A causa della simmetria di questa fase, è possibile che anche Alice provi ad eseguire la stessa operazione utilizzando la sua chiave privata, ottenendo un nuovo valore hva. Nel caso in cui ciò si verifichi, allora vengono confrontati i due valori, viene scartato quello più basso ed il creatore del valore maggiore viene assunto come Initiator. Una volta ricevuto hvb, Alice lo ricalcola autonomamente a partire dal suo messaggio Hello e dalla chiave pubblica di Bob, dopodiché confronta il risultato con quello ricevuto per sincerarsi che non vi siano stati attacchi MiTM. 39

47 Zimmermann Real-time Transport Protocol (ZRTP) Capitolo Diffie-Hellman Exchange Prima di scambiare messaggi DHPart1 e DHPart2 mostrati in (Figura 3.1), è necessario che Alice e Bob effettuino ulteriori operazioni preliminari. Per garantire autenticità ed integrità dei messaggi, vengono calcolati da entrambi una sequenza di HMACs [24] troncati ai 64 bit più a sinistra utilizzando le seguenti informazioni di partenza: (rs1, rs2): Una coppia di chiavi segrete possedute da Bob e mandate ad Alice all interno del precedente messaggio Commit os: Altri valori segreti generati autonomamente ed in maniera casuale da ciascuna delle parti (non sempre presente) pbxs: Contiene l identificativo del centralino utilizzato nel caso in cui questo campo sia noto, in alternativa viene generato autonomamente o può essere posto a zero da entrambe le parti. auxs: Valore segreto che può essere scambiato durante la segnalazione SIP, generato autonomamente a livello hardware o da altri livelli funzionali. Se scambiato a livello di segnalazione, internamente ad SDP, prende il nome di srtps Alice effettua l operazione H M usando le grandezze appena elencate, ottenendo i valori: rs1-idr= H M (rs1, Responder ) rs2-idr = H M (rs2, Responder ) auxs-idr = H M (auxs, Responder ) pbxs-idr = H M (pbxs, Responder ) Alice incapsula questi risultati all interno del frame DHPart1 insieme alla sua chiave pubblica pva ed invia tutto. Ricevuto il messaggio, Bob controlla che pva 1 e pva (p-1), nel caso in cui ciò non sia verificato il procedimento viene immediatamente terminato. Questo perché per definizione dell algoritmo i valori precedenti non sono accettati e se presenti si assume che siano stati causati da un attacco. Bob effettua le stesse operazioni mostrate per Alice calcolando: 40

48 Zimmermann Real-time Transport Protocol (ZRTP) Capitolo 3 rs1- IDi = H M (rs1, Initiator ) rs2- IDi = H M (rs2, Initiator ) auxs- IDi = H M (auxs, Initiator ) pbxs- IDi = H M (pbxs, Initiator ) In maniera simmetrica a quanto fatto dalla controparte, invia questi parametri incapsulandoli in DHPart2 congiuntamente alla sua chiave pubblica pvb. Alice esegue dunque la stessa verifica per sincerarsi che non vi siano stati attacchi, controllando che siano rispettati pvb 1 e pvb (p-1). Alice calcola ora autonomamente i valori rs1-idi, rs2-idi, auxs-idi, pbxs-idi e li confronta con quelli ricevuti da Bob, questo serve ad assicurarsi che entrambe le parti generino la chiave s0 a partire dagli stessi parametri. Sia Alice che Bob, a partire dai dati che hanno appena condiviso, generano autonomamente due nuove quantità mh e dhr. Essendo che i dati di partenza per effettuare tali calcoli sono gli stessi, è lecito pensare che entrambi gli utenti giungano a risultati coincidenti: mh= H(Alice s Hello Commit DHPart1 DHPart 2) dhr = pva svb mod p = ( g sva mod p) svb mod p = g sva svb mod p Dalla concatenazione dei diversi valori calcolati in precedenza, le parti sono entrambe in grado di generare un nuovo segreto condiviso s0 da cui derivare poi le chiavi necessarie per SRTP. s0= H(counter dhr mh ZIDi ZIDr len(s1) S1 len(s2) S2 len(s3) S3) Per spiegare in che modo vengono scelti i valori di S1, S2 e S3 si segue uno schema decisionale dove vengono determinate le possibili situazioni verificabili e dove i termini (i) ed (r) indicano rispettivamente l appartenenza all Initiator o al Responder (Tabella 3.2). 41

49 Zimmermann Real-time Transport Protocol (ZRTP) Capitolo 3 S1 S2 S3 if(rs1(i)=rs1(r) rs1(i)=rs2(r)) if(auxs(i)=auxs(r)) if(pbxs(i)=pbxs(r)) CASO { { { A S1=rs1(i) S2=auxs S3=pbxs } } } if(rs1(i)!=rs1(r) rs1(i)!=rs2(r)) if(auxs(i)!=auxs(r)) if(pbxs(i)!=pbxs(r)) { { { CASO if(rs2(i)=rs1(r) rs2(i)=rs2(r)) S2=0 S3=0 B { } } S1=rs2(i) } } CASO C if(rs1(i)!=rs1(r) rs1(i)!=rs2(r)) { if(rs2(i)!=rs1(r) rs2(i)!=rs2(r)) { S1=0 } } Tabella Schema decisionare per rs1 e rs2 Nel caso in cui S1, S2 o S3 risultino nulli, il valore len() per il calcolo s0 di è considerato nullo Switch to SRTP and Confirmation Giunti a questo punto è necessario usare il segreto condiviso s0 per generare le chiavi necessarie. ZRTP utilizza un sistema per la derivazione delle chiavi basato su HMAC, che prende il nome di KDF. Vengono generate le chiavi SRTP master key (SRTP-mkey) e SRTP salt (SRTP-msalt), 42

50 Zimmermann Real-time Transport Protocol (ZRTP) Capitolo 3 separate per direzione del flusso. L Initiator ed il Responder utilizzano SRTP-mkeyI e SRTP-msaltI per cifrare e successivamente decifrare i messaggi mandati dall Initiator verso il Responder. SRTPmkeyR e SRTP-msaltR vengono invece usate per la fase duale. La lunghezza delle chiavi è troncata a quella specificatamente richiesta dal profilo SRTP. Le chiavi si ottengono come: SRTP-mkeyR= KDF(s0, vecchia chiave SRTP del Responder, lunghezza chiave AES) SRTP-mkeyI= KDF(s0, vecchia chiave SRTP dell initiator, lunghezza chiave AES) SRTP-msaltR = KDF(s0, vecchia stringa salt del Responder, lunghezza chiave AES) SRTP-msaltI = KDF(s0, vecchia stringa salt dell initiator, lunghezza chiave AES) Le quantità appena trovate vengono utilizzate per derivare le chiavi di sicurezza del protocollo Secure RTCP secondo quanto specificato in [19], senza richiedere la generazione di nuove chiavi mediante negoziazione ZRTP. Viene ora cancellato il valore della chiave rs2 memorizzata in cache, viene aggiornato tale valore sostituendovi il valore di rs1 ed infine rs1 viene nuovamente calcolato a partire da s0: rs2 = rs1 rs1 = KDF(s0, retained secret ) dove retained secret rappresenta proprio il vecchio valore di rs1. In questo modo si ha sempre in memoria le ultime chiavi di sessione garantendo continuità delle chiavi. Ultima operazione da eseguire è il calcolo delle due chiavi ZRTP che vengono usate dalle parti per cifrare i messaggi Confirm1 e Confirm2. Queste chiavi verranno distrutte al termine della sessione corrente in modo da rendere indecifrabile in futuro la telefonata appena conclusasi. ZRTP-keyA = KDF(s0, Vecchia chiave ZRTP del Responder, lunghezza chiave AES) ZRTP-keyB = KDF(s0, Vecchia chiave ZRTP dell initiator, lunghezza chiave AES) Viene dunque cancellata s0 mentre le restanti chiavi verranno cancellate al termine della sessione. Prima di terminare la procedura, deve essere verificato il valore Short Authentication String (SAS), un messaggio composto dagli ultimi 16 o 32 bit di mh, che viene visualizzato sul display di 43

51 Zimmermann Real-time Transport Protocol (ZRTP) Capitolo 3 entrambe le parti comunicanti. Per eseguire l autenticazione, entrambi gli utenti devono leggerne il contenuto. Nel caso in cui questo non combaci, significa che è stato effettuato un attacco MiTM. Il vantaggio dell aver utilizzato un hash per il calcolo di mh è qui evidente, un intruso ha a disposizione un singolo tentativo di intromettersi nella chiamata, se fallisce viene intercettato e la telefonata annullata. Verificato il SAS, Alice e Bob si scambiano un messaggio Confirm contenente una parte cifrata con Cipher Feedback (CFB) [25] che nasconde la durata delle chiavi rs1 e rs2, la verifica del SAS ed altre informazioni. Lo scambio dei messaggi Confirm è effettuato per i seguenti motivi: Le parti confermano che tutta la procedura di Key-Agreement è andata a buon fine e che è stata generata la chiave richiesta per SRTP Le parti garantiscono che non è avvenuto alcun attacco MiTM Consentono lo scambio del messaggio SAS tra gli utenti in maniera sicura 3.3 Short Authentication String (SAS) Come accennato in precedenza, fondamentale ai fini di garantire la prevenzione da un attacco MiTM, è la verifica della stringa Short Authentication String (SAS). Si tratta semplicemente di un messaggio di testo comprensivo di 4 caratteri alfanumerici che vengono visualizzati sui display dei partecipanti alla conversazione. Operativamente questi rappresentano gli ultimi 16 bit di mh (che si ricorda essere il risultato di un operazione di hash tra i messaggi: Alice s Hello, Commit, DHPart1, DHPart2). I due utenti sono invitati a verificare che suddetto valore coincida sui rispettivi dispositivi, in tal caso si è certi che non vi sia stata alcuna intromissione da parte di terzi. ZRTP è disegnato in modo che l invio dei messaggi Confirm possa essere effettuato immediatamente oppure ritardato fino alla verifica del SAS (per sicurezza vi è associato un timer). In questo caso è possibile che il traffico voce tra gli utenti in questi primi istanti sia scambiato in chiaro. Non appena verificato il SAS o comunque non appena scaduto il timeout associato al messaggio Confirm, lo stesso viene inoltrato. ZRTP nasce per liberare il VoIP dalla necessità di un infrastruttura che si occupi della gestione delle chiavi, e per evitare la dipendenza da Certification Authority nel caso di certificati digitali. Il tentativo è quello di rendere la sicurezza del traffico vocale completamente indipendente da tutto ciò che non vi è strettamente inerente. Tuttavia il sistema di verifica del SAS può risultare 44

52 Zimmermann Real-time Transport Protocol (ZRTP) Capitolo 3 inapplicabile in alcuni contesti o si può desiderare utilizzare una PKI già esistente. Il primo caso si verifica per esempio quando a comunicare sono un essere umano ed un server che tentano di stabilire una connessione facente uso di ZRTP. Risulterebbe impossibile per il server verificare il SAS vocalmente, o richiederebbe comunque la presenza di una qualche forma di interfaccia vocale capace di leggere ad alta voce il testo ricevuto. È evidente come questo non sia sempre possibile ed in generale come l approccio SAS appena descritto possa rappresentare un vincolo troppo limitante in un contesto reale. Per gestire queste eccezioni ZRTP prevede una caratteristica opzionale che consente al SAS di essere verificato senza interazione umana. La verifica avviene direttamente tra i dispositivi coinvolti, il SAS viene firmato mediante firma digitale ed il risultato viene inviato all interno dei messaggi Confirm1 e Confirm2. Il sistema adoperato per apporre la firma, la lunghezza della stessa e le chiavi utilizzate per apporla, sono tutti inviati all interno dello stesso messaggio (ovviamente cifrato). Se per esempio il meccanismo designato per il key-exchange è ECDH allora lo stesso, con lo stesso modulo, è utilizzato per firmare il SAS. Addirittura per questioni di rapidità spesso molti dispositivi preferiscono utilizzare questa tecnica invece della verifica mediante interazione umana. Questo perché, nel caso in cui si usino le curve ellittiche, la dimensione della chiave è estremamente ridotta e pertanto la procedura è più rapida. È possibile eseguire la verifica del SAS in un tempo nettamente inferiore rispetto al caso tradizionale, riducendo la latenza della fase di setup della chiamata. Vi è un ultimo caso in cui è possibile considerare sicura la comunicazione anche in caso di mancata verifica del SAS. Se e solo se si ha la certezza assoluta che il signaling sia protetto su base end-toend mediante l uso congiunto dei sistemi spiegati nel Capitolo 2, si può ampliare i campi di SDP aggiungendo un nuovo attributo a = zrtp-hash (Figura 3.3). Figura Integrazione ZRTP in SDP 45

53 Zimmermann Real-time Transport Protocol (ZRTP) Capitolo 3 Mediante ciò possiamo autenticare il successivo procedimento di key-exchange basato su Diffie- Hellman senza la necessità da parte dell utente di verificare il SAS. In questo modo l aver garantito integrità e protezione del signaling su base end-to-end consente altresì di soddisfare tali requisiti sul piano media-plane come accennato in introduzione di capitolo. 3.4 Funzionamento in modalità Pre-shared È prevista dallo standard una modalità di funzionamento semplificata adatta a terminali più semplici con modesta capacità elaborativa. Invece di utilizzare ogni volta il meccanismo Diffie-Hellman visto in precedenza, i terminali usano un segreto condiviso prelevato da una sessione precedente e memorizzato in una memoria cache. Questa tecnica è utile nel caso in cui si voglia riattivare una connessione sicura tra due parti che avevano recentemente realizzato l instaurazione completa di una sessione completando il procedimento Diffie-Hellman. I dispositivi che supportano tale meccanismo lo comunicano alla controparte aggiungendola tra le opzioni per il Key Agreement proposte nel messaggio Hello. Mediante questo procedimento, i dispositivi con processori più limitati non hanno la necessità di realizzare lo scambio di chiavi con Diffie-Hellman ad ogni sessione. In casi estremi di dispositivi talmente semplici da non essere in grado di realizzare Diffie- Hellman, può essere fornito un set di chiavi iniziali da utilizzare. Ovviamente è sconsigliata l adozione di tale sistema, viene fornita esclusivamente per questione di compatibilità e per snellire la procedura nel caso di riconnessioni tra gli stessi utenti, ma il suo utilizzo non garantisce un livello di protezione paragonabile a quello ottenuto con la procedura completa. L Initiator comunica la decisione di utilizzare il meccanismo Pre-shared specificandolo all interno del messaggio Commit. Invece di effettuare il calcolo delle chiavi come mostrato dettagliatamente in precedenza, si utilizza il segreto rs1 relativo ad una conversazione precedente e si calcola una chiave temporanea ottenuta come: preshared-key= H(len(rs1) rs1 len(auxs) auxs len(pbxs) pbxs) Il valore appena ottenuto viene adoperato per creare la chiave s0. Questa sarà ovviamente meno sicura di quella ricavata con il procedimento standard ma garantirà comunque il proseguo dell algoritmo secondo i passi già mostrati in precedenza ed indispensabili per la generazione delle chiavi necessarie a SRTP. La procedura di generazione di s0 segue la regola seguente: 46

54 Zimmermann Real-time Transport Protocol (ZRTP) Capitolo 3 s0= KDF(Preshared-key nonce lunghezza hash) A partire da questa vengono generate quindi, mediante quanto spiegato nel caso generale, le chiavi SRTP master key (SRTP-mkey) e SRTP salt (SRTP-msalt), separate per direzione del flusso, completando la fase di scambio chiavi ZRTP. 47

55 Realizzazione prototipo per test Capitolo 4 Capitolo 4 Realizzazione prototipo per test 4.1 Configurazione rete e dispositivi Una volta compresi i vari aspetti inerenti il mondo VoIP, si è deciso di creare un ambiente dove effettuare dei test per verificare la veridicità di quanto appreso dalla teoria oltre ad eseguire alcune analisi di interesse (Figura 4.1). La scelta del PBX da utilizzare per gestire il traffico VoIP è ricaduta su Asterisk [E], un software opensource sviluppato da Digium [F]. Tale centralino è stato installato e configurato su un PC con processore Pentium 4 con processore da 3ghz, 1gb di RAM e sistema operativo Linux Backtrack versione 5r3. Per testare il funzionamento di una comunicazione VoIP tra diversi utenti, sono state provate diverse applicazioni, al fine di verificare quale risultasse la più completa per effettuare le verifiche di interesse. Ovviamente la scelta è ricaduta su programmi opensource; tale decisione ha consentito di studiare il codice per comprendere pienamente come venissero implementate alcune funzioni di interesse. Per slegare i test da ogni vincolo su hardware utilizzato e sistema operativo di riferimento, si sono effettuate prove in un ambiente più eterogeneo possibile utilizzando: Un Pc con sistema operativo Linux Backtrack e Client VoIP PJSUA Un computer con sistema operativo Windows XP e Client VoIP Jitsi Un computer con sistema operativo Windows Vista e Client Jitsi Uno Smartphone Samsung Galaxy S3 con sistema operativo Android e Client VoIP CSIPSimple Asterisk è un PBX completo, disegnato per essere indipendente da un hardware specifico, consente di soddisfare la quasi totalità delle richieste che si possono avere in una rete VoIP. Supporta 48

56 Realizzazione prototipo per test Capitolo 4 adeguatamente i protocolli più disparati per quel che riguarda segnalazione, sicurezza, trasporto, ecc. Per quanto concerne la segnalazione, implementa esaustivamente il protocollo SIP secondo lo standard [4]. Sono disponibili tutti i sistemi di sicurezza visti nei capitoli precedenti tranne ZRTP (Per i quali test di funzionamento si è adoperato un differente PBX). Figura 4.1 Schema di riferimento del Prototipo Realizzato 4.2 Configurazione Asterisk L organizzazione di Asterisk segue quella classica di un sistema Linux, ed è raggruppata in diversi file e directory. Vengono di seguito specificati i più importanti: /etc/asterisk : questa directory contiene tutti i file di configurazione di Asterisk, come extension.conf, sip.conf, h323.conf e iax.conf /usr/sbin : la directory dei file binari di sistema contiene gli eseguibili e gli script effettivi, tra cui asterisk, astman, astgeney e safe_asterisk 49

57 Realizzazione prototipo per test Capitolo 4 /usr/lib/asterisk : contiene oggetti binari riferiti ad Asterisk specifici della sua architettura /usr/lib/asterisk/modules : contiene i moduli runtime per applicazioni, channel driver, codec, driver per il formato dei file, ecc /usr/include/asterisk : contiene gli header dei file richiesti per la costruzione delle applicazioni, channel driver e altri moduli caricabili /var/lib/asterisk/keys : area per la memorizzazione di chiavi pubbliche e private utilizzate per l autenticazione RSA con Asterisk /var/lib/asterisk/sounds : area per la memorizzazione di audio file, suggerimenti, ecc. utilizzati nelle applicazioni di Asterisk Asterisk presenta una struttura fortemente modulare, che consente all utente di stabilire quali componenti caricare e quali escludere dall esecuzione. Tale scelta è volta ad alleggerire il server consentendone l utilizzo anche su dispositivi dalle risorse limitate. Per capire Asterisk la prima cosa da comprendere è il Dialplan, l entità che instrada tutte le chiamate del sistema, dalla sorgente al destinatario, passando attraverso le varie applicazioni. Il Dialplan è composto da un gruppo di Contesti che sono a loro volta una collezione di Estensioni, cioè istruzioni associate a quel determinato contesto. È possibile specificare l appartenenza di un utente ad un determinato contesto, limitando le operazioni da esso eseguibili. La struttura dei contesti è a sua volta modulare e consente di incorporare all interno di uno le funzioni di un altro secondo una struttura ad albero. Uno degli aspetti fondamentali è quello della sicurezza; è infatti possibile configurare il sistema in modo da limitare ad alcuni utenti certi servizi, rendendoli inaccessibili ad altri ed evitando di conseguenza il pericolo di intrusioni Creazione utenze con funzioni base La creazione delle utenze e le operazioni di configurazione del server Asterisk nel caso di interesse, vanno eseguite sul file SIP.conf. Si tratta del file di configurazione più importante per gli scopi di questa Tesi, ed in generale è il riferimento per la configurazione in ambito SIP-VoIP. Al suo interno è possibile impostare ogni dettaglio del protocollo SIP così come le politiche riguardanti la sicurezza, i parametri di dominio, i codec audio accettati e tanto altro. Per brevità non si mostrano le configurazioni di ogni utente, ma solo quelle di due di essi per avere un riferimento. 50

58 Realizzazione prototipo per test Capitolo 4 Il primo passo è dichiarare gli utenti che verranno usati, avendo l accortezza di specificare altresì i parametri di interesse per i test. La cosa più importante è fissare il contesto di appartenenza, ovvero il set di operazioni che tali utenti sono autorizzati a compiere. Per una comunicazione tra due utenti senza alcuna cifratura del traffico né per la segnalazione né per la voce, è necessaria la seguente configurazione: [max] type=friend host=dynamic dtmfmode=rfc2833 username=max secret=polpo989 context=tesi [gio] type=friend host=dynamic dtmfmode=rfc2833 username=ugo secret=polpo989 context=tesi dove i parametri settati assumono i seguenti significati: [max]: si è creata una nuova registrazione di utente chiamato max type: configurato come friend significa che l utente può fare e ricevere chiamate; per le sole chiamate in uscita si usa type=user, per le sole chiamate in ingresso si usa type=peer host: specifica il tipo di host, nel caso specifico dotato di IP dinamico, scelta che consente la massima mobilità; in alternativa è possibile configurare anche un IP statico dtmfmode: il Dual-tone multi-frequency (in sigla DTMF), detto anche multifrequenza, è un sistema per codificare codici numerici sotto forma di segnali sonori in banda audio. username: specifica l identificativo che il server si aspetta sia fornito da un client mediante il messaggio INVITE secret: indica la password utilizzata da HTTP Digest Authentication per eseguire l autenticazione del client Il passo successivo riguarda la scelta dei parametri di dominio e di autenticazione. Sono possibili numerosissime customizzazioni, vi sono inclusi template per una rapida connessione verso dispositivi VoIP della Digium [F] così come per interfacciarsi ad apparati Cisco [G] o di altri produttori. I parametri che sono mostrati si limitano a quelli indispensabili per eseguire i test sul prototipo: 51

59 Realizzazione prototipo per test Capitolo 4 realm=maxasterisk transport=udp alwaysauthreject = yes domain= realm: deve corrispondere con quanto indicato in fase di registrazione dell UAC, fa parte dei parametri necessari a completare l autenticazione basata su digest transport: consente di fissare il protocollo di trasporto da utilizzare alwaysauthreject: quando viene rifiutata una richiesta INVITE O REGISTER si dichiara sempre che l identificativo usato per tentare l accesso era valido e che la richiesta è stata rifiutata per via di un errore della password. In questo modo si impedisce ad un intruso scoprire quelli che sono gli username SIP validi. domain: indica il nome associato al dominio, può essere un indirizzo IP o un nome Un altra parte interessante è quella delle specifiche audio. Vi è la possibilità di stabilire i codec da usare, le politiche di instradamento dei flussi ed è altresì consentito dichiarare classi di priorità differenziate a secondo dei tipi di traffico [1]. disallow=all allow=ulaw directmedia=yes tos_sip=cs3 tos_audio=ef tos_video=cs0 tos_text=cs0 disallow: esclude tutti I codec audio possibili, questa scelta viene sempre seguita dall autorizzazione di uno o più codec da utilizzare. Può tornare utile per test e per velocizzare la scelta dei codec qualora lato client se ne abbiano a disposizione un set limitato allow: indica di utilizzare uno specifico codec tra quelli disponibili directmedia: di default Asterisk cerca di instradare direttamente i flussi multimediali dal chiamante al chiamato. Alcuni client però non supportano tale caratteristica e richiedono esplicitamente che il traffico sia scambiato con il server. 52

60 Realizzazione prototipo per test Capitolo 4 tos: questo campo consente di differenziare il traffico fissando dei meccanismi di priorità che asterisk si impegna a garantire nel caso di congestione della rete. Sono disponibili 21 livelli di priorità raggruppati in Clear to Send, Assumed Forwarding, Expedited Forwarding Configurazione per Signaling sicuro Con la configurazione base non si ha alcuna garanzia di sicurezza né per la segnalazione né per il traffico generato dalla conversazione telefonica. In primo luogo è necessario rendere sicura la segnalazione mediante l adozione di TLS. Con tale protocollo si incapsulano tutti i messaggi SIP rendendone protetto il contenuto. La configurazione seguente indica il modo ottimale di configurare Asterisk per tali operazioni. Si richiede l utilizzo di un certificato digitale da parte dello stesso server, certificato che va creato e salvato nella directory indicata insieme alla chiave ed alla CA. tlsenable=yes tlsbindaddr= tlscertfile= /etc/asterisk/certificates/newcert.pem tlsprivatekey=/etc/asterisk/certificates/newkey.pem tlscafile=/etc/asterisk/keys/cacert.pem tlscapath=/etc/asterisk/keys tlsclientmethod=tlsv1 tlsenable: indica se è attiva o meno la configurazione TLS tlsbindaddr: indica l indirizzo a cui inoltrare le richieste TLS, se presente un proxy altrimenti è l indirizzo della macchina Asterisk tlscertfile: specifica quale sia il certificato da utilizzare per l autenticazione del server Asterisk tlsprivatekey: specifica quale sia la chiave del certificato tlscafile: specifica quale sia la CA responsabile della firma sul certificato del server tlscapatch: contiene il percorso dove possono essere memorizzate altre CA attendibili tlsclientmethod: specifica la metodologia da utilizzare; può essere tlsv1, sslv2 e sslv3 53

61 Realizzazione prototipo per test Capitolo 4 Per il corretto funzionamento dei client è necessario che anche la loro configurazione sia modificata rispetto a quanto mostrato in precedenza. Deve essere aggiornato il meccanismo di trasporto adoperato in modo da usare TLS e deve essere specificata la porta da utilizzare: transport=tls port= Configurazione per Media Plane sicuro Di default Asterisk viene installato senza supporto per SRTP. Tale mancanza viene evidenziata nel tentare di effettuare una chiamata protetta mediante un messaggio ERROR[10167]: chan_sip.c:27987 setup_srtp: No SRTP module loaded, can't setup SRTP session. Per abilitare tali funzioni è necessario installare la libreria libsrtp e ricompilare il programma caricando il modulo aggiuntivo res_srtp. Effettuata tale operazione e verificato successivamente che il modulo viene caricato, è ora sufficiente aggiungere nelle configurazioni dei client il valore: encryption=yes Altre modifiche vanno effettuate sull estensione associata, come viene spiegato in seguito Configurazione dei contesti All interno di un contesto, come detto in precedenza, risiedono le estensioni, ovvero il set di istruzioni che sono eseguibili dagli appartenenti a suddetto contesto. Avendo dichiarato in SIP.conf che gli utenti adoperano il contesto tesi, è ora necessario specificare le azioni ad esso associate nel file extension.conf. Per la semplice chiamata tra i due utenti le configurazioni necessarie risultano: [tesi] exten => 121,1,Dial(SIP/max) exten => max,1,goto(121,1) 54

62 Realizzazione prototipo per test Capitolo 4 exten => 141,1,Dial(SIP/gio) exten => gio,1,goto(141,1) exten => 600,1,Playback(echomax) exten => 600,n,Echo Gli utenti max e gio possono essere messi in comunicazione tra loro digitando il loro nome su un display alfanumerico o mediante numeri 121 e 141 associati. L opzione Dial() consente all utente chiamante di essere messo in comunicazione con la persona richiesta. La sintassi completa è Dial (Canale/Utente), dove il canale può essere H.323, Zap, SIP,ecc.. mentre il secondo parametro indica quale utente definito in sip.conf si voglia contattare. L opzione goto() permette di muoversi all interno del Dialplan inviando la chiamata ad un altro contesto ed estensione già definiti. Secondo la configurazione proposta digitando 121 la telefonata viene inviata all utente SIP di nome max come specificato in Dial(). Mediante l uso di goto() è possibile contattarlo digitando direttamente il suo nome, perché a tale sequenza in ingresso si viene comunque reindirizzati al Dial() precedente. Al fine di poter valutare la qualità del servizio anche in assenza di un utente da chiamare, si è aggiunto un echo test effettuabile dai client digitando il numero 600. Una voce inviterà a parlare nel microfono e tale messaggio sarà riprodotto con un ritardo pari alla latenza sulla tratta. Il file audio echomax che viene riprodotto deve essere categoricamente in formato *.gsm e memorizzato nella cartella /var/lib/asterisk/sounds/en. Per rendere sicura la comunicazione mediante protocollo SRTP-SDES è necessario modificare il comportamento dei client nel momento in cui viene generata una richiesta di chiamata. Con la configurazione mostrata in seguito si aggiungono all interno dei campi SDP trasportati in SIP le informazioni di interesse per la cifratura. Perché si abbia realmente protezione della voce è indispensabile che la segnalazione adotti TLS per il trasporto, altrimenti questa procedura è inutile. exten => 1XX,1,Set(_SIP_SRTP_SDES=1) exten => 1XX,2,Set(_SIPSRTP=1) exten => 1XX,3,Set(_SIPSRTP_CRYPTO=enable) La configurazione (_SIP_SRTP_SDES=1) e (_SIPSRTP=1) specifica che le chiavi utilizzate da AES saranno da 128 bit. (_SIPSRTP_CRYPTO=enable) aggiunge il campo crypto all interno del corpo SDP dei messaggi trasportati con SIP. 55

63 Realizzazione prototipo per test Capitolo FreeSwitch e configurazione per ZRTP Asterisk non supporta ZRTP. In realtà Philip Zimmermann, inventore del protocollo, aveva proposto in origine una patch per integrare il suo sistema con Asterisk. Sfortunatamente tale integrazione è stata ideata per la distribuzione 1.4, ormai obsoleta ed è stata poi completamente abbandonata. In oltre ricerche in rete hanno evidenziato le numerose limitazioni della stessa. I tentativi di rendere compatibile tale patch sulla versione 10.8 utilizzata nel prototipo si sono dimostrati vani, a causa dei forti cambiamenti apportati al centralino VoIP nel corso degli anni. In particolare Asterisk blocca le richieste ZRTP impedendo ai client di completare la procedura, bloccando così la cifratura della telefonata. È stato quindi necessario ricercare un diverso PBX che potesse consentire di eseguire i test desiderati. La scelta è ricaduta su FreeSwitch, che integra tale funzione a partire dalla distribuzione rilasciata in aprile 2012 (Quindi appena sei mesi dall inizio di questa Tesi Magistrale). Non ci si vuole dilungare nello spiegare dettagliatamente come siano stati creati i nuovi utenti, i nuovi certificati e le nuove configurazioni per suddetto centralino. Il tempo richiesto per tali compiti è stato quasi pari a quello necessario per comprendere ed approfondire il funzionamento di Asterisk. FreeSwitch presenta una struttura nettamente più modulare del suo concorrente, tra le differenze più significative vi è la divisione rigida nelle politiche per utenti interni alla LAN di riferimento ed utenti interfaccianti da altre reti. FreeSwitch adotta una politica differente per la configurazione rispetto ad Asterisk, privilegiando il concetto di appartenenza ad una classe piuttosto che quello di protocollo utilizzato. Non esiste un file simile a sip.conf; la scelta degli indirizzi e delle porte del server, i meccanismi di sicurezza da adottare, la locazione dei certificati e la scelta dei codec, sono tutti definiti in singoli file indipendenti tra loro, il cui contenuto è poi passato per riferimento. Allo stesso modo gli utenti non sono creati in un file unico ma specificati ognuno in un documento esclusivo ed inclusi successivamente con una chiamata dal livello superiore. All interno del file dove viene dichiarato l utente, le azioni che esso può compiere non sono fissate in maniera statica, ma viene indicata la sua appartenenza ad un gruppo, le cui funzioni sono definite in un file a sé stante. Per esempio vi è una rigida divisione per le politiche applicate ad utenti cosiddetti interni alla rete ed utenti esterni al dominio. Questa suddivisione, per certi aspetti un po dispersiva, è però molto utile per differenziare i meccanismi di sicurezza da adottare in base alla provenienza delle chiamate. Volendosi limitare spiegare come abilitare il protocollo ZRTP, senza perdere tempo a mostrare tutte le fasi precedenti, è necessario aggiungere o modificare a seconda dei casi i seguenti parametri: 56

64 Realizzazione prototipo per test Capitolo 4 <Param name= rtp-enable-zrtp value= true /> In questo modo si abilita il supporto per il protocollo nel caso in cui si vogliano creare canali sicuri end-to-server tra un client ed il centralino. Tale modifica va apportata all interno del file switch.conf.xml contenuto nella directory di configurazione del PBX. <action application= set data= zrtp_enrollment=true /> Questa seconda opzione consente al server di essere considerato un MiTM attendibile, la sua funzione dovrebbe essere quella di evitare la modifica del SAS sui dispositivi finali nel caso in cui il traffico multimediale lo attraversi. In realtà si è scoperto che tale aspetto è strettamente legato alla scelta del client, i problemi ad esso relativi non sembrano essere ancora completamente risolti, ed a testimonianza di ciò anche nelle prove effettuate il SAS non corrispondeva sui display dei terminali. L obiettivo dei test era però quello di garantire sicurezza su base end-to-end escludendo quindi il PBX dalla comunicazione multimediale. Per ottenere questo risultato bisogna far sì che lo stesso metta in comunicazione diretta gli utenti escludendosi dal tragitto per i messaggi RTP. Per riuscirci si impostano i valori come segue: <param name= inbound-bypass-media value= true /> <param name= inbound-zrtp-passthru value= true /> Con questa configurazione si riesce ad effettuare la telefonata con sicurezza del media plane end-toend, senza coinvolgere il server nello scambio di messaggi contenenti la voce. 4.4 Creazione certificati digitali per Asterisk L utilizzo di un meccanismo TLS permette di aumentare notevolmente la sicurezza del sistema VoIP. Nel caso in esame interessa creare un sistema per autenticare il server Asterisk quando viene contattato dai client. In questo modo si evita di inoltrare le richieste verso un entità estranea alla rete 57

65 Realizzazione prototipo per test Capitolo 4 che potrebbe entrare in possesso delle credenziali e delle password degli utenti. I punti fondamentali per configurare tale sicurezza con Asterisk sono: 1. Creare un certificato per il server Asterisk 2. Modificare la configurazione del file sip.conf spiegato in precedenza 3. Configurare i client in modo da utilizzare TLS In questo paragrafo viene mostrato come generare correttamente un certificato per il server. Prima ancora di poter creare tale certificato, si deve configurare una Certification Authority. In alternativa è possibile generare certificati auto-firmati ma il livello di sicurezza risulta inferiore. Il prototipo vuole essere attuabile in una configurazione reale, pertanto si decide di creare una CA che potrebbe essere utile per usi futuri sulla rete. Vengono utilizzati i tool disponibili grazie ad openssl per eseguire le operazioni successive. Posizionati nella directory /usr/lib/ssl/misc, viene creata la Certification Authority (Figura 4.2). Figura 4.2 Certification Authority Quello che interessa è la chiave pubblica cacert.pem associata a questa CA. Essa è l unica cosa che deve essere fornita ai client appartenenti alla rete per poter accettare la richiesta di Asterisk. Nel server vanno invece memorizzate suddetta chiave, il certificato creato e la chiave associata al certificato. La posizione dove vanno salvati e la modifica del file sip.conf sono stati indicati mostrati ad inizio capitolo. La parte più importante è quella della generazione del certificato del server. Le informazioni contenute devono corrispondere a quelle reali affinché il client accetti di 58

66 Realizzazione prototipo per test Capitolo 4 connettersi. Bisogna prestare attenzione ad indicare come nome ovvero quello del server Asterisk. Si invoca la creazione del certificato mediante: /CA.sh newreq Vengono generate la chiave privata ed una richiesta di firma del certificato da parte della CA, passo fondamentale per garantirne la validità. Un certificato non siglato non rappresenta alcuna garanzia di identità. Si procede quindi ad apporre la firma al certificato mediante:./ca.sh sign Il certificato è ora firmato e pronto per essere utilizzato da Asterisk per garantire le sue credenziali nei confronti dei client che tentano l accesso (Figura 4.3). Figura Certificato server Asterisk 59

67 Test e valutazioni prestazionali Capitolo 5 Capitolo 5 Test e valutazioni prestazionali 5.1 Analisi procedura autenticazione HTTP Digest Authentication La prima verifica effettuata è stata quella di valutare che lo scambio di informazioni previsto da [4] si realizzasse secondo le regole dichiarate. Secondo lo standard solamente il client deve essere autenticato mediante il meccanismo basato su digest, mentre il server non è tenuto a fornire informazioni né ad autenticarsi presso il client. Sniffando il traffico scambiato sulla rete mediante wireshark si ottiene la seguente sequenza di pacchetti (figura 5.1). Figura 5.1 Squenza messaggi HTTP Digest Authentication I messaggi significativi sono la richiesta di registrazione da parte dell UAC, la risposta del server che richiede la verifica del digest, la risposta del client ed infine la riuscita dell autenticazione. Tale semplice schema permette al server di sincerarsi che l utente sia in possesso del segreto condiviso ed a conoscenza del realm di riferimento. I messaggi SIP trasmessi in chiaro consentono di verificare la presenza di tutti i campi descritti nel Capitolo 2. Sono riconoscibili: Start line, Header fields, Message body (Figura 5.2). In questo caso il corpo del messaggio trasporta le richieste di registrazione. Il sistema di sicurezza adottato si limita ad autenticare i client ma non garantisce affatto confidentiality per i messaggi SIP, né tantomeno influisce sulla riservatezza del traffico multimediale RTP. L interesse di questo lavoro di Tesi, come affermato fino dall introduzione, era 60

68 Test e valutazioni prestazionali Capitolo 5 quello di valutare il livello di sicurezza opportuna per una rete di piccole dimensioni confrontandone l impatto con la QoS. Challenge inviata da Asterisk Response del Client Figura 5.2 Messaggi Challenge-Response Per questo motivo vengono valutate le performance del sistema nelle condizioni in esame, ovvero in assenza di protezione della segnalazione e della voce. Visti gli stringenti vincoli della voce rispetto al ritardo, uno dei parametri che può essere più interessante misurare è il Jitter, ovvero la variazione statistica nel ritardo di ricezione dei pacchetti trasmessi. Si è voluto testare come, al crescere del numero degli utenti partecipanti alla conversazione, varino sia questo che la quantità di traffico generata complessivamente, osservando la situazione da un utente di riferimento. Per quel che concerne l analisi del Jitter vengono indicati i valori massimi e minimi registrati ed il valore medio durante l intera connessione (Tabella 5.1). Nel caso di conferenza con massimo cinque partecipanti come è stato simulato, non è necessario applicare meccanismi di QoS per garantire la qualità della conversazione, essendo il traffico globale comunque limitato. La comunicazione risulta di ottima qualità e non si registrano ritardi considerevoli o perdite di pacchetti. Tale risultato era ovviamente auspicato in quanto Asterisk è 61

69 Test e valutazioni prestazionali Capitolo 5 disegnato per gestire il traffico di reti VoIP di grandi dimensioni ed era improbabile che cosi pochi utenti potessero causare un calo delle performance. Numero Jitter (ms) Quantità utenti MIN AVG MAX traffico (KB) 2 RX 0 1,257 1, TX 6,375 6,375 6,375 60,1 3 RX 0,250 2,386 18,625 78,4 TX 5,875 7,313 8,750 58,8 4 RX 0,5 3,237 29, TX 6,125 7,688 9,250 78,7 5 RX 0,125 3,539 39,750 96,9 TX 6,125 7,625 7,375 98,4 Tabella 5.3 Valutazione Jitter e quantità di traffico L interesse specifico era però valutare l uso dei sistemi di QoS offerti dal PBX per differenziare il trattamento dei flussi di segnalazione e voce in caso di congestione. Pertanto si è provveduto ad effettuare una conferenza tra cinque utenti senza protezioni alcune e generare una quantità considerevole di traffico UDP mediante un demone che andasse a congestionare il canale utilizzato. Sono state analizzate le performance in caso di assenza di meccanismi di QoS, e in caso in cui si scegliesse di privilegiare l audio a scapito della segnalazione. È stato fatto variare il numero di pacchetti UDP inviati verso il server valutandone l impatto sulla comunicazione (Tabella 5.2). QoS Numero pacchetti/sec Jitter (ms) Quantità MIN AVG MAX traffico (KB) RX 0 1,818 4, ,6 TX 6,375 7,167 8, RX 0,125 9,577 33, ,9 TX 6,125 8,982 20, ,6 RX 0,375 12,297 27, ,1 TX 6,250 10,187 14, ,2 62

70 Test e valutazioni prestazionali Capitolo 5 Senza QoS RX 0,250 6,899 22,250 39,0 TX 6,125 8,268 19, ,3 RX 0,250 8,523 24, ,6 TX 6,5 11, ,6 RX 1,250 21, , ,7 TX 10,875 13,969 20, ,1 Tabella 5.4 Valutazione prestazioni applicando QoS In mancanza di accorgimenti tali da garantire QoS, le performance della chiamata sono calate notevolmente così come evidenziato nei grafici ed indicato dal valore di Jitter mostrato nella tabella. Applicare con criterio una differenziazione delle politiche a seconda dei traffici è un primo passo per implementare correttamente un sistema di comunicazione basata su VoIP (Grafico 5.1). Trasmissione Ricezione QoS No QoS QoS No QoS Grafico Valutazione variazione Jitter medio TLS Authentication Si è voluta analizzare la procedura di autenticazione mediante TLS modificando il prototipo secondo la configurazione proposta nel capitolo 4. L applicazione di tale protocollo ha fornito sicurezza alla segnalazione. Si è altresì deciso di garantire l autenticazione del solo server 63

71 Test e valutazioni prestazionali Capitolo 5 utilizzando un certificato digitale firmato da una Cerification Authority ritenuta affidabile. Lato client, a seconda del software utilizzato, in alcuni casi si è dovuto provvedere a copiare manualmente la CA, in altri è stato richiesto se tale CA fosse ritenuta affidabile e la procedura è stata automatica. Va sottolineato come la necessità di copiare fisicamente la CA nel client si sia verificata solo per il software pjsua, più sofisticato e non dotato di interfaccia grafica. Come evidenziato nei capitoli teorici, il meccanismo basato su TLS con autenticazione mutua garantirebbe un maggiore livello di sicurezza; sfortunatamente però in un contesto reale, con una moltitudine di utenti verosimilmente mutevoli in numero, tale approccio risulterebbe difficoltoso. Ragionando sempre in ottica di implementazione reale, mediante l uso di certificati lato server si è migliorata notevolmente la sicurezza, senza la necessità di operare modifiche sui client. Tale fattore non è affatto trascurabile, basti pensare quali sarebbero i costi da sostenere se fosse necessaria una modifica radicale della configurazione dei dispositivi di ogni utente. Avendo pensato il prototipo come riferimento per un caso reale, si è scelto di accontentarsi dell autenticazione server mantenendo così la massima flessibilità. Si valutino la sequenza di messaggi scambiati tra le parti (Figura 5.3); la procedura inizia con un messaggio Hello inviato dal Client, configurato in modo tale da utilizzare TLS per il trasporto. Secondo i parametri settati, l UAC si aspetta che in risposta il server alleghi il suo certificato. Verificato lo stesso, viene effettuato l handshake concordando le chiavi di sicurezza per la sessione. La sequenza dei messaggi scambiati tra le parti è disponibile nella figura seguente. Al semplice scambio di messaggi SIP-REGISTER trasportati da UDP, è sostituita una procedura più raffinata trasportata in toto dal protocollo orientato alla connessione TCP. Figura 5.3 Sequenza messaggi Autenticazione con TLS 64

72 Test e valutazioni prestazionali Capitolo 5 Il certificato inviato dal server è quello creato secondo quanto descritto in Capitolo 4. Ricevuto tale certificato, l UAC controlla se la CA responsabile della firma sia attendibile, se tale requisito è soddisfatto, controlla che l identità dichiarata nel certificato digitale coincida con quella del mittente dello stesso, cioè il server Asterisk. Terminate queste verifiche segue l autenticazione basata su digest per la parte client. Questa non avviene più in chiaro mediante UDP come nel paragrafo precedente; il traffico di segnalazione è cifrato mediante le chiavi scambiate con l handshake TLS e risulta indicato come Application Data protetto Tlsv1. Dal punto di vista della congestione del canale, è chiaro come l utilizzo di TCP porti ad un aumento del traffico di segnalazione dovuto al maggiore overhead introdotto dal protocollo orientato alla connessione. Tale aspetto non costituisce una problematica nel prototipo creato per i test, ma in una rete di telecomunicazioni VoIP di dimensioni maggiori richiede che siano applicate politiche di QoS tali da garantire che siano rispettati i vincoli sul ritardo propri dei diversi flussi. Nella tabella seguente si mostra come la durata del processo di autenticazione realizzata con TLS sia circa dieci volte maggiore rispetto al tempo richiesto per il SIP semplice (Tabella 5.3). Numero utenti HTTP Digest Authentication TLS Authentication 2 0,045 0,1 3 0,024 0,19 4 0,085 0,23 5 0,042 0,3 Tabella 5.5 Confronto durata autenticazione Latenza dell autenticazione Digest Digest TLS Grafico 5.2 Confronto durata autenticazione 65

73 Test e valutazioni prestazionali Capitolo 5 Nel valutare la durata dell autenticazione non si è potuto ovviamente misurare la latenza precisa dell autenticazione HTTP Digest Authentication in quanto tale traffico è ora cifrato e non riconoscibile. Ai tempi indicati in tabella vanno quindi ancora aggiunti quelli propri dello scambio di messaggi SIP. Si ricorda che l uso di TLS è limitato alla protezione della segnalazione SIP. Il traffico voce deve ancora essere protetto e continua ad essere trasportato mediante protocollo UDP. Da un analisi attenta dei traffici si nota però una differenza rispetto al caso mostrato nel paragrafo precedente: senza usare protezione per il livello di trasporto, i messaggi SIP trasportavano in chiaro i campi SDP contenenti le informazioni sui flussi audio. Dalla lettura di tali campi, il traffico vocale veniva identificato chiaramente figurando come traffico multimediale RTP. Aver protetto la segnalazione ha nascosto il contenuto della parte body dei messaggi SIP, non permettendo di interpretare in prima analisi il contenuto dei pacchetti contenenti la voce. Gli aspetti di sicurezza relativi rimangono disgiunti e la telefonata è sempre inviata in chiaro, ma una differenza è comunque osservabile ed è interessante sottolinearlo. Non dimentichiamo che l aver utilizzato TLS garantisce sicurezza su base hop-by-hop. Il metodo proposto è valido specificatamente nelle condizioni di test, dove l unico hop tra le parti chiamanti è il server Asterisk considerato sicuro. Il server crea un canale sicuro con ognuna delle parti partecipanti alla conversazione. I traffici generati da un utente vengono inviati cifrati su un canale, decifrati dal server e quindi di nuovo cifrati per attraversare la tratta verso la destinazione. Se sono presenti più nodi o si interconnettono due reti VoIP gestite da due centralini differenti, è indispensabile creare un canale di comunicazione sicuro tra i due e che gli stessi server siano considerati affidabili. Il meccanismo di autenticazione basato su certificati mostrato per il caso client-server nel capitolo 2 può essere adoperato con successo anche per una comunicazione di tipo server-server. In alternativa esiste un protocollo specifico incaricato di realizzare trunk sicuri specificatamente tra centralini Asterisk. Questo protocollo prende il nome di IAX ed è largamente utilizzato in collaborazione con suddetto PBX. 66

74 Test e valutazioni prestazionali Capitolo Analisi cifratura del Media Plane Essendo che il funzionamento con SDES-SRTP è trattato nel Capitolo 6, ed essendo che come già affermato in questa Tesi ci si concentra su ZRTP, si focalizza questo paragrafo direttamente su questo protocollo. Nel capitolo 3 di questa tesi si è spiegato dettagliatamente la procedura per la generazione e lo scambio di chiavi mediante protocollo ZRTP. Si rimarca come tale algoritmo non rappresenti affatto un algoritmo di sicurezza, ma solo un meccanismo di key-exchange. Il fine di ZRTP è quello di consentire la generazione e lo scambio delle chiavi di sicurezza utilizzate da SRTP per rendere sicura la chiamata tra due utenti. La peculiarità del protocollo ideato da Zimmermann sta nel fatto che la generazione e lo scambio delle chiavi non coinvolgono il signaling. Tutta la procedura viene gestita autonomamente dalle parti coinvolte e si svolge a livello media-plane. Si testa il funzionamento utilizzando come centralino VoIP FreeSwitch mentre i client utilizzano il software Open Source Jitsi. Gli indirizzi delle parti coinvolte sono i seguenti: Server Freeswitch: Client 1002: Client 1009: Configurando il server in modo da non bloccare i messaggi ZRTP, escludendosi dalla conversazione dopo l autenticazione, funziona tutto correttamente e la generazione e lo scambio delle chiavi viene gestito autonomamente dai peer. La comunicazione avviene in maniera diretta tra gli ip e e non coinvolge il PBX (Figura 5.4). Figura 5.4 Sequenza messaggi ZRTP 67

75 Test e valutazioni prestazionali Capitolo 5 Sempre in maniera conforme a quanto affermato nel Capitolo 3, entrambe le parti tentano di agire da Initiator provando ad inoltrare il messaggio Commit. Dal fatto che il successivo messaggio DHPart1 venga inviato da si deduce che sia stato designato come Initiator (il valore hvi da lui computato avrà restituito un risultato più elevato della controparte). Nella figura seguente è mostrato il corpo del messaggio Commit definitivo, dove vengono ufficializzati tutti i meccanismi concordati (Figura 5.5). Figura Verifica utilizzo ECDH Nel caso analizzato la procedura va a buon fine, ricalca precisamente il protocollo e compare da entrambe le parti una stringa SAS coincidente, utile per identificare eventuali attacchi MiTM (Vedi Capitolo 6). Cliccando sul lucchetto a sinistra si conferma la verifica del SAS e si completa lo scambio della chiave rs0 garantendo che non vi siano stati attacchi MiTM (Figura 5.6). Figura Confronto SAS 68

76 Test e valutazioni prestazionali Capitolo 5 Lo scambio delle chiavi va a buon fine e tutto è confermato dal messaggio Conf2ACK. Come si vede dalla figura seguente, fino alla conclusione della procedura ZRTP tutto il traffico figura come RTP (Figura 5.7). Attenzione dunque che la sicurezza della chiamata non è garantita fino alla verifica del SAS e la conversazione in questo intervallo è dunque trasmessa in chiaro. Una volta ricevuta la conferma che le chiavi sono state generate e scambiate in sicurezza, ed è stato verificato il SAS, il successivo traffico è contrassegnato come SRTP e cifrato con la chiave appena concordata. Vi è dunque una parte in cui la conversazione non è protetta, diventa importante sveltire il più possibile la fase ZRTP per evitare di conversare in chiaro. Figura 5.7 Analisi traffico multimediale Valutazione della scelta ottimale per il Key-Exchange La scelta di Jitsi come applicativo è risultata vantaggiosa per questa tesi in quanto di tutti i software testati, questo è risultato uno dei pochi ad essere contemporaneamente opensource e configurabile secondo i requisiti richiesti. Nel dettaglio interessava impostare tutte e quattro le versioni di Diffie- Hellman proposte in [23] per lo scambio di chiavi, per poter valutare le differenze tra i metodi. Nell appendice posta in coda a questo lavoro di Tesi vengono analizzate le motivazioni per cui può essere conveniente effettuare lo scambio di chiavi di cifratura utilizzando le Curve Ellittiche (Vedi Appendice). In particolare viene focalizzata l attenzione sul fatto che la scelta di tali curve nel keyexchange dovrebbe velocizzare la procedura rispetto alla versione FFDD, senza penalizzare la sicurezza del prototipo. Interessa ora verificare che tale ipotesi sia supportabile da risultati sperimentali. Avendo osservato in precedenza che la conversazione resta in chiaro durante l autenticazione ZRTP, si vuole velocizzare il più possibile questa fase. Le possibili scelte offerte da ZRTP per il key-exchange risultano quelle elencate nella tabella seguente (Tabella 5.4). 69

77 Test e valutazioni prestazionali Capitolo 5 Nome Tipo Lunghezza chiave DH2K DH su campi finiti 2048 bit DH3K DH su campi finiti 3072 bit EC25 DH su curve ellittiche 256 bit EC38 DH su curve ellittiche 384 bit Tabella Possibili scelte meccanismo Key-exchange L interesse nelle curve ellittiche è dovuto al fatto che consentono un livello di sicurezza molto più elevato a parità di bit della chiave rispetto al caso a campi finiti. Tra le possibili scelte, EC25 con una chiave da 256 bit garantisce la stessa protezione di FFDH con chiave da 3072 bit, mentre EC38 stessa protezione di FFDH con chiave da Volendo sveltire il più possibile la procedura si ritiene congruo usare chiavi la cui lunghezza sia minore possibile, in relazione al fatto che comunque EC25 e DH3K portano stessa sicurezza. In generale poter usare una chiave molto più breve consente di saturare meno il canale, tutti aspetti fortemente ricercati in un panorama VoIP. I risultati seguenti mostrano il tempo medio della durata della procedura di generazione chiavi ZRTP. I dati riportano la media calcolata sui tempi misurati su 10 prove consecutive senza variazioni delle condizioni del canale (Tabella 5.5). DH2K DH3K EC25 EC38 Durata autenticazione (s) 0,3 1,33 0,22 0,95 Tabella 7.5 Tabella tempi autenticazione Durata autenticazione DH2K DH3K EC25 EC38 Grafico Confronto durata Key-exchange 70

78 Test e valutazioni prestazionali Capitolo 5 Dall osservazione di questi dati, del grafico che ne segue (Grafico 5.3) e dalle considerazioni precedenti, si deduce come usando EC25 si ottenga la stessa sicurezza di DH3K riducendo però di circa sei volte il tempo impiegato per completare la procedura. Il fatto che dalle misurazioni sembri che EC38 impieghi un tempo considerevole, non deve trarre in errore; non va dimenticato che in quel caso si offre una protezione davvero eccellente della comunicazione, paragonabile a standard militari [H]. In conclusione i test mostrano come un compromesso ideale possa essere EC25 per il prototipo, mentre in condizioni di estrema riservatezza della conversazione la scelta di EC38 possa essere conveniente come rapporto tra tempo richiesto e sicurezza offerta. Ovviamente tale possibilità è legata alla disponibilità di risorse dei dispositivi adottati, non sempre sono presenti tutte e quattro le modalità qui analizzate. 5.3 Performance analysis of the impact of security on QoS Assessing the quality of a voice conversation can be a difficult task especially if you need an objective judgment. For decades the Mean Opinion Score (MOS) method has been used in telephone networks to get feedback from users. The MOS criterion was a highly subjective mechanism where a specific number of users was invited to listen to a conversation and provide an assessment on its quality; the MOS result indicated the average obtained from the judgments of the participants. Citing the definition given by the ITU-T in [I]: "The talker should be seated in a quiet room with volume between 30 and 120 m3 and a reverberation time less than 500 ms (preferably in the range ms). The room noise level must be below 30 dba with no dominant peaks in the spectrum." Obviously such an assessment does not lend itself to be a yardstick for the work in question; in particular it would be difficult to use this criterion to judge a VoIP conversation. In any case for compatibility issues many applications on the market assess the voice quality by assigning a score indicated as MOS, which is obtained though by calculation according to certain algorithms chosen by the manufacturer. MOS measurements associate an assessment of the quality of the conversation listened to certain numbers (Table 5.6). 71

79 Test e valutazioni prestazionali Capitolo 5 Mean opinion score (MOS) MOS Quality Noise evaluation 5 Excellent Imperceptible 4 Good Perceptible but not annoying 3 Fair Slightly annoying 2 Poor Annoying 1 Bad Very annoying Table 5.6 MOS rating score Obviously, as often happens in the case of performance measurements, evaluations are closely related to the interpretation made by the manufacturer of the software and may differ depending on the program chosen. After looking for free software as had been set, we became aware of the Finnish company Sevana Oy, IT Solutions and Services [L], which is specialized in softwares for the evaluation of the quality of voice and sound: among the software product suite it also features AQUA, a professional tool for performance evaluation of audio communications. The program is used for professional testings on the evaluation of the sound and the Finnish company cooperates with major European and Asian markets. Logically these tools are not available for free, nor even in downloadable demo versions from their sites. Luckily contacting the company directly and specifying the purposes of this research work, we were provided with a valid license, the software and the collaboration of one of their expert in evaluating how best to configure the program in order to get the finest results for tests of interest. 72

80 Test e valutazioni prestazionali Capitolo Configuration and parameters choice for analysis There is no universally valid configuration to analyze any audio communication: the variation of only one parameter may cause the results to be significantly different; so a meticulous work is needed in order to achieve an optimal configuration that provides consistent data. The following results were obtained after various tests and comparisons, made in collaboration with a professionist of Sevana, who helped a lot in the choice of the configuration for the software. As a result, it is assumed that the final configuration for AQUA is considerable optimal for the evaluation of a conversation between two VoIP users with PCMU 8000 encoding. In order to evaluate the impact of different applicable security systems, call records (about fifteen seconds lenght) were compared, monitoring the quality of the source (client side) and the one received by Asterisk before forwarding to the destination. We observed the behavior in the case in which the congestion of the server was due to proper SIP messages (INVITE) and the case in which was caused by generic UDP traffic. QoS policies, settable on the server, are described in detail in Chapter 4. The part of the configuration of the software, the choice of the parameters and settings of thresholds, has required numerous attempts to obtain the optimum configuration for the cases under consideration. Avoiding details, we mention only the most significant configurations for the purpose of understanding. We configured AQUA in order to analyze typical frequencies of a voice conversation by making sure that the results were proportionate to the type of input data. The range of the analyzed frequencies is therefore between 300 Hz and 3400 Hz. The amplitudes shown in the following graphs are normalized to the maximum value measured. To determine the time lags among the input audio files, the software provides 5 levels of synchronization accuracy; we chose a level 5 to ensure the highest possible accuracy. Using a VAD system we have tried to remove the background noise in periods of silence as much as possible in order to better compare the periods of activity, without the results being heavily penalized by voice s pauses during the call. The following tables show, in addition to the MOS score, an indication of the similarity between the recordings on the client and on the server sides, the measured S / N values and finally the time lag between the provided input recordings Results obtained with simple SIP 73

81 Test e valutazioni prestazionali Capitolo 5 CONDITIONS MOS LIKELIHOOD S/N S/N TIME LAG PERCENTAGE CLIENT SERVER % No congestion 4,76 88,26 64,52 63,45 2,46 Congestion caused by INVITE without QoS 3,81 71,71 48,87 70,03 20,29 SIP Congestion caused by INVITE with QoS 4,56 84,95 66,52 68,86 4,07 Congestion caused by UDP without QoS 3,33 62,64 75,90 62,80 5,13 Congestion caused by UDP with QoS 3,52 66,25 74,08 68,22 8,32 Table Performance Comparison SIP Observing the data collected (Table 5.7), we understand that the quality of a conversation without any protection for signaling and voice traffic is very high. The parameters of likelihood and the time lag indicates that the call has been completed with an excellent quality. Even in case of congestion due to SIP requests, the configuration of QoS oriented to prioritize voice over signaling has ensured optimal performance. The impact on the call of a generic UDP traffic due to congestion instead, did not appear to be limited by the server, as predictable. This traffic is not classifiable by a switchboard; it can be solved with QoS implemented by network s router, but not by Asterisk. The following graph instead shows the way in which the different conditions impact on the frequency domain of voice (Graph 5.4). The application of QoS seems to make curves more smooth, showing more similar audible tones to the client side and the server side. 74

82 Test e valutazioni prestazionali Capitolo 5 No congestion Client Server Congestion caused by INVITE without QoS Congestion caused by INVITE with QoS Client Server Client Server Congestion caused by UDP without QoS Congestion caused by UDP with QoS Client Server Client Server Graph Comparison SIP performance 75

83 Test e valutazioni prestazionali Capitolo Results obtained with SIP-TLS CONDITIONS MOS LIKELIHOOD S/N S/N TIME LAG PERCENTAGE CLIENT SERVER % No congestion 4,96 94,51 71,96 70,79 1,93 Congestion caused by INVITE without QoS 3,05 56,83 66,82 69,67 8,08 SIP TLS Congestion caused by INVITE with QoS 4,42 82,32 67,86 64,74 5,39 Congestion caused by UDP without QoS 2,91 53,88 68,33 67,33 8,04 Congestion caused by UDP with QoS 3,79 71,23 68,18 69,09 2,68 Table Comparison SIP-TLS performance The behaviour in this context is similar to the previous case (Table 5.8). Again priority mechanisms selected on the server are incapable of dealing with congestion not caused by SIP signaling. From a frequency analysis instead, it seems to be present a sort of filtering effect of higher tones of the voice that are no longer reproduced. In this particular case, UDP congestion has extremely worsened the quality, as we can see by both numerical results of the previous tables and by observing of the followings graphs. There is always a low-pass behaviour also shown in absence of signaling security mechanisms (Graph 5.5). No congestion 76

84 Test e valutazioni prestazionali Capitolo Client Server Congestion caused by INVITE without QoS Congestion caused by INVITE with QoS Client Server Client Server Congestion caused by UDP without QoS Congestion caused by UDP without QoS Client 50 Client Server Server Graph Comparison SIP-TLS performance 77

85 Test e valutazioni prestazionali Capitolo Results obtained with SRTP-SDES CONDITIONS MOS LIKELIHOOD S/N S/N TIME LAG PERCENTAGE CLIENT SERVER % No congestion 4,12 77,11 75,56 63,94 3,10 Congestion caused by INVITE without QoS 2,40 42,95 71,15 70,81 5,32 SRTP SDES Congestion caused by INVITE with QoS 4,01 90,4 57,25 56,74 3,58 Congestion caused by UDP without QoS 1,00 14,00 63,45 67,6 9,73 Congestion caused by UDP with QoS 1,86 32,00 66,41 67,45 6,18 Table Comparison SRTP-SDES performance These results clearly show performance degradation of the conversation due to the introduction of RTP encryption (Table 5.9). The average results are much lower than the previous cases. Remember that with SDES-SRTP, except in very rare cases in which the procedure can be managed automatically by end devices, you must first encrypt voice from the client to the server, decrypt and re-encrypt it again on the second trade towards the end-user. All of these operations as carried out quickly, however, employ a time that is unavoidable, causing a decline in the quality of the call. As communication channel deteriorates, the heaviness of the procedure impacts on the quality of the call, especially in absence of appropriate QoS configurations. Also in this case, while it is possible to limit a congestion due to signaling, it results to be not possible in the case of UDP generic traffic. Performances are very bad and the conversation is virtually impossible, which is why the assigned MOS assessment is as low as possible (Graph 5.6). 78

86 Test e valutazioni prestazionali Capitolo 5 No congestion Client Server Congestion caused by INVITE without QoS Congestion caused by INVITE with QoS Client Server Client Server Congestion caused by UDP without QoS Congestion caused by UDP with QoS Client 50 Client Server Server Graph Comparison SRTP-SDES performance 79

87 Test e valutazioni prestazionali Capitolo Results obtained with ZRTP CONDITIONS MOS LIKELIHOOD S/N S/N TIME LAG PERCENTAGE CLIENT SERVER % No congestion 4,72 88,09 63,62 75,74 1,1 ZRTP Congestion caused by INVITE 4,02 75,30 64,97 57,59 4,63 Congestion caused by UDP 3,96 74,34 64,39 72,32 3,80 Table 8 Performance comparison ZRTP First of all, it is important to emphasize that tests performed on ZRTP have compared recorded conversations directly between end users and not between one of them and the server as previously done. This is due to the very nature of the protocol which requires that multimedia traffic does not cross the switchboard for a correct operation. It is also recalled that this test was performed using FreeSwitch as PBX and no longer Asterisk which did not allow the use of ZRTP. Consequently earlier QoS mechanisms have not been implemented. Moreover, giving the fact that RTP traffic no longer crosses the switchboard, this aspect would have been absolutely useless. As hoped by running the tests, ZRTP resulted to be the strongest and more efficient mechanism. With no congestion, the quality of the conversation is optimal with a MOS assessment comparable to the one obtained with a communication made in clear (Table 5.10). In the case in which the server is congested for oversubscribed UDP or specific signaling messages, this problem is no longer about the voice channel between parties. Clients are not affected by the congestion of the switchboard because the communication takes place directly between them without concerning it, according to point-to-point methodology. Avoid having to decrypt and re-encrypt each packet of the conversation makes the procedure much faster and overall performance absolutely superior. From frequency s point of view, it should be noted, however, a strong low-pass behaviour, as shown in the following graphs. Comparing the results shown in graphs with the ones obtained in all previous analyzed cases, we discover that the components centered at higher frequencies have been 80

88 Test e valutazioni prestazionali Capitolo 5 completely removed, reducing the conversation to lower tones sounds (Figure 5.7). Such a behaviour cannot be considered excessively negative in a telephone conversation where people, on the average, speak with soft tones and without shouting. Therefore it can be asserted that the use of ZRTP is better than SDES-SRTP from a point of view of average quality of the conversation. In Chapter 6 we will address issues related to security, where the superiority of the ZRTP protocol over the competitors (limited to the aspects considered) will be stressed again. No congestion Client Server Congestion caused by INVITE Congestion caused by UDP Client 50 Client Server Server Graph Performance comparison ZRTP 81

89 Attacchi alla comunicazione Capitolo 6 Capitolo 6 Attacchi alla comunicazione 6.1 Introduzione Figura Configurazione prototipo per attacchi Nel Capitolo 2 sono stati presentati i meccanismi ed i protocolli comunemente utilizzati per proteggere una rete VoIP. È stato creato un prototipo di una rete utilizzante IP per scambiare traffico vocale, è stato configurato dettagliatamente un PBX e dei client in modo da effettuare 82

90 Attacchi alla comunicazione Capitolo 6 telefonate con diversi livelli di sicurezza. In questo capitolo si vuole testare tali protocolli e si vuole mostrare un approccio completo per attaccare il prototipo. Come logico le prime operazioni da compiere riguarderanno lo studio della topologia della rete, sia essa cablata o dotata di accesso mediante canale wireless. Il crescente uso di apparecchi mobili quali smartphone, laptop e palmari ha fatto si che la maggior parte dei PBX operanti nelle aziende sia interlacciata con la rete wireless. Queste tematiche non vengono approfondite in questa tesi in quanto si tratta di aspetti generici riguardanti l hacking mentre l interesse qui è focalizzato sul VoIP. Esistono una quantità davvero elevata di tipologie di attacchi perpetrabili ad una rete utilizzante IP per lo scambio di voce, per i fini di ricerca di questo lavoro di tesi ci si limita a mostrare gli effetti di quattro di queste: 1. Information Gathering 2. Denial of Service (DoS) 3. Attacchi MiTM all autenticazione 4. Attacchi MiTM alla comunicazione (Eavesdropping) I test seguenti vengono eseguiti da un utente intruso che lancia i suoi attacchi da una macchina con sistema operativo Linux Backtrack versione 5r3 collegato alla stessa rete dove si svolgono le comunicazioni VoIP mediante uno switch secondo la configurazione mostrata in (Figura 6.1). 6.2 Information Gathering La prima cosa da fare per poter attaccare una rete di telecomunicazione VoIP è ottenere informazioni sui client utilizzanti tale tecnologia e scoprire la conformazione della rete IP presente. Esistono numerosissimi tool in grado di effettuare tali operazioni, ciascuno più o meno sofisticato e con un determinato livello di pericolosità. Nel caso specifico di analisi del prototipo configurato, si è scelto di utilizzare uno dei programmi disponibili sulla macchina Backtrack utilizzata per gli attacchi. Tale tool è nmap, potente strumento in grado di identificare i dispositivi presenti sulla rete, oltre a fornirne alcune informazioni significative quali la lista delle porte che risultino aperte. Per 83

91 Attacchi alla comunicazione Capitolo 6 lanciare il programma si digita il comando seguente specificando un range di indirizzi IP che interessa scansionare:./nmap Si sceglie di ottenere informazioni su potenziali client attivi su 255 possibili locazioni, i risultati di tale operazione forniscono in output l identificazione dei tre dispositivi connessi alla rete (Figura 6.2). Vengono identificati tre host e contestualmente è possibile rilevare quali porte siano attive, con particolare interesse a quelle relative ai servizi SIP e SIP-TLS. Client gio Client max Server Asterisk Figura Client trovati sulla rete Come si era affermato nei capitoli iniziali di questo lavoro di Tesi, la natura del VoIP fa sì che tale architettura soffra di tutte le limitazioni della rete che la supporta, ovvero IP, e che sia esposta a tutti gli attacchi perpetrabili alla stessa. Non c è dunque da meravigliarsi del fatto che sia così semplice scoprire quanti e quali utenti potenzialmente siano connessi alla rete. Operativamente il tool nmap utilizza l invio di messaggi ICMP, come tradizionalmente avviene in una rete di telecomunicazioni, per trarne le informazioni di interesse. Ora che sono noti tre dispositivi che potenzialmente utilizzano tecnologia VoIP, con un altro semplice programma si può scoprire se la possibilità di attacco sia concreta. Si sceglie quindi un altro applicativo opensource, smap, sempre contenuto nella distribuzione Linux scelta. Può essere utilizzato in modo da scansionare un range di indirizzi fornendo in output informazioni poco dettagliate, oppure vi è la possibilità di analizzare un host specifico ispezionandolo nel dettaglio e restituendo un maggiore numero di informazioni. Avendo usato già nmap in precedenza, ed avendo già identificato i dispositivi connessi alla rete, sarebbe ridondante eseguire nuovamente una 84

92 Attacchi alla comunicazione Capitolo 6 scansione completa. Pare opportuno focalizzare l attenzione sui tre dispositivi identificati indagandoli nel dettaglio uno alla volta. Anche in questo caso la sintassi del comando è semplice e richiede solo di specificare l indirizzo da analizzare. Per comodità in seguito viene scritto il comando con l ultima cifra dell indirizzamento IP sostituita da una X, cui ovviamente caso per caso va sostituita la locazione precisa di ogni host che interessa analizzare. Si lancia quindi l esecuzione mediante:./smap O X Dall analisi dell output, si nota che sono stati riconosciuti due softphone sugli indirizzi e ed è stato riconosciuto il server Asterisk localizzato sull IP (Figura 6.3). Operativamente per ora non è stato compiuto nessun attacco, ci si è limitati a studiare la rete per capire quali siano gli elementi che la compongono. Nei paragrafi seguenti però tali informazioni torneranno utili per indirizzare correttamente gli attacchi veri e propri che si vogliono effettuare. Client gio Client max Server Asterisk Figura 6.3 Dettagli relativi agli host indentificati Contromisure applicabili Volendo limitare la possibilità che un malintenzionato sfrutti le potenzialità della rete a suo vantaggio, usando il protocollo ICMP a suo favore per attaccare la comunicazione VoIP, si può applicare una politica che limiti lo scambio di tali messaggi. Dunque si sceglie di proteggere il prototipo seguendo questa regola e pertanto si modifica sul server il file /etc/sysctl.conf, disabilitando le risposte alle richieste PING. Questo si ottiene impostando i valori: 85

93 Attacchi alla comunicazione Capitolo 6 net.ipv4.icmp_echo_ignore_broadcast = 1 net.ipv4.icmp_echo_ignore_all = 1 In questo modo si impedisce ad un malintenzionato di raccogliere le informazioni come mostrato in precedenza. Se tutto è configurato correttamente, il blocco di ICMP non influenza il corretto funzionamento del centralino e dei client, ma resta da verificare che altri dispositivi ed applicazioni presenti sul canale condiviso non necessitino di tale servizio per il loro corretto funzionamento. 6.3 Denial of Service Una volta venuti a conoscenza dell indirizzo del server Asterisk e dei due client utilizzati, un primo tipo di attacco effettuabile è un attacco di tipo DoS. Mediante questo non si ha la volontà di intercettare le chiamate o impossessarsi delle credenziali degli utenti, solo quella di impedire che questi riescano ad effettuare la telefonata o che comunque la qualità della stessa sia talmente degradata da renderne fastidioso l ascolto. Come si è visto il protocollo SIP utilizza un insieme di messaggi standard che difficilmente possono essere ignorati da un client o da un server in quanto indispensabili per il corretto svolgimento della telefonata. Sfruttando tali messaggi si può far si che il server o un client accettino richieste fasulle che, se ricevute con frequenza troppo elevata, saturano le risorse degli stessi impedendone il funzionamento INVITE Flood L attacco più semplice, ma dagli effetti devastanti, è quello che prevede il flooding di richieste INVITE. Tali richieste non possono ovviamente essere ignorate né da un client né tantomeno dal server. Viene lanciato dalla macchina attaccante il comando:./inviteflood eth

94 Attacchi alla comunicazione Capitolo 6 Mediante questa sintassi si indica che si vogliono mandare delle richieste INVITE da un utente verso un altro e si specifica nel terzo indirizzo IP quale sia la macchina a cui inoltrare tali richieste. Nonostante né il server né i client conoscano l indirizzo sorgente, sono obbligati ad ascoltare le richieste, in quanto tali messaggi risultano formalmente corretti. L effetto di tale attacco è davvero sorprendente: tutti i dispositivi che lo subiscono crashano irrimediabilmente ed è impossibile effettuare qualsiasi telefonata. Si osservi il funzionamento del server Asterisk in condizioni di attacco mediante un grafico che mostra il rapporto tra il numero di richieste ricevute al secondo e il corrispondente uso del processore (Figura 6.4) Utilizzo CPU (%) Utilizzo CPU Figura 6.4 Saturazione CPU a seguito di attacco Al crescere del numero di richieste, l utilizzo del processore aumenta in maniera esponenziale ed è saturato completamente dopo messaggi INVITE. Ovviamente le risorse usate dal prototipo sono limitate, ma l andamento delle curve nei grafici permette di dedurre che in poco tempo anche con risorse superiori si andrebbe in contro ad un crash del sistema. Nel caso in cui l attacco venga rivolto ad un client, compaiono messaggi di errori che portano al blocco del dispositivo in pochi secondi. Nel caso di attacco al server compaiono una lista di messaggi del tipo (Figura 6.5). Sommerso da tali richieste, Asterisk non solo non riesce a soddisfare una chiamata tra gli utenti usati, ma non consente nemmeno di utilizzare la console per bloccare la sua esecuzione. Figura 6.5 Notifiche richieste su Asterisk 87

95 Attacchi alla comunicazione Capitolo UDP Flood Un secondo tipo di attacco DoS perpetrabile ai danni di una comunicazione VoIP sfrutta le debolezze di User Data Protocol per impedire o deteriorare una corretta comunicazione vocale. Vengono inondati gli host con richieste trasportate con UDP monitorando il diverso comportamento degli stessi. Per questo test si è utilizzato un tool opensource disponibile in rete. Il programma in questione si chiama UDP Unicorn ed è stato scelto sia per la semplicità che per la possibilità di fissare dimensione dei pacchetti ed intervallo di invio. La dimensione è stata fissata a 1024 bit per evitare frammentazione a livello IP, è stato fatto variare il numero di pacchetti inviati al secondo andando da 10 a 100 a 1000, valutando il comportamento del canale dal punto di vista della qualità della conversazione. Il successo di questi attacchi dipende fortemente dalla destinazione degli stessi. Nel test effettuato, i client non sono risultati robusti a sufficienza e sono andati in crash in seguito ad attacchi a loro indirizzati. Ben più robusto si è dimostrato il server Asterisk che, al di là di un ovvio peggioramento della qualità offerta alla conversazione, non è comunque stato bloccato in nessuna delle situazioni esaminate. Il problema maggiore sta nel fatto che la porta UDP per la segnalazione SIP è di default la 5060, né il server né i client rifiutano i pacchetti su questo indirizzo. La scelta spesso adoperata di non apportare modifiche alla configurazione nativa di server e client, lasciando impostata la porta standard, semplifica ulteriormente la probabilità di essere attaccato. Una regola semplice ma efficace consiste nel cambiare questa porta dal valore iniziale, facendo in modo che un possibile intruso non possa lanciare l attacco a colpo sicuro senza prima aver studiato le porte aperte sul server. Ragionando sempre in ottica di implementazione reale del prototipo di test, la soluzione sarebbe quella di cambiare la porta SIP. Tale operazione comporta però un costo in termini di riconfigurazione della maggior parte dei client che in automatico comunicano sulla Come ogni scelta riguardante l attuazione di una determinata politica in una rete di telecomunicazioni, bisogna valutare attentamente il rischio di minacce in rapporto alla complessità dell operazione di riconfigurazione dei dispositivi e prendere la decisione considerata più opportuna RTP Flood Un attacco simile al precedente è quello che prevede di incapsulare non dati generici all interno di UDP, ma specifiche richieste RTP. A differenza del primo, l attacco in questione è propriamente 88

96 Attacchi alla comunicazione Capitolo 6 mirato alle conversazioni voce VoIP e non genericamente ai danni di una comunicazione IP. Mentre in precedenza la porta di attacco era fissata alla 5060 conoscendo le standardizzazioni SIP, per lanciare questo attacco è necessario conoscere la porta specifica utilizzata per il traffico RTP. Asterisk utilizza in maniera random porte comprese tra la e la per questo tipo di traffico. Ogni singola sessione viene avviata su un diverso indirizzo ed è pertanto impossibile conoscere a priori dove lanciare l attacco. Altrettanto vale per i client utilizzati dove è presente un range di possibili scelte come per il server. Per lanciare questo tipo di attacco è quindi necessario conoscere prima la porta UDP usata da RTP. Ipotizzando per semplicità di essere sempre nel caso in cui il traffico multimediale sia trasportato senza protezione, è possibile ottenere tali informazioni semplicemente sniffando il canale con Wireshark. A seconda di come sia settata la voce directmedia su Asterisk, il traffico voce può passare prima dal server o essere scambiato direttamente tra i client. Nel primo caso è interessante scoprire la porta di ascolto RTP di Asterisk e lanciare l attacco verso di lui (Figura 6.6), nel secondo caso si decide di attaccare la porta di uno dei client (Figura 6.7). Figura Traffico multimediale che attraversa il server Figura Traffico multimediale scambiato direttamente tra gli utenti Il procedimento per effettuare l attacco è il medesimo sia che si tratti del server che di uno dei client, bisogna specificare l indirizzo IP ed il numero di porta che si vuole raggiungere. In seguito si simula un attacco mirato ad una conversazione esclusiva tra i peers. La prima operazione da fare è analizzare con Wireshark la porta usata da uno dei client per il traffico RTP (Figura 6.8). Figura Messaggio RTP con indicate porte utilizzate 89

97 Attacchi alla comunicazione Capitolo 6 Dall analisi delle porte si osserva che il client riceve il flusso audio sulla porta Si sceglie quindi di utilizzare tale informazione per indirizzare propriamente l attacco mediante il comando:./rtpflood La sintassi indica oltre all indirizzo IP e la porta da attaccare anche quelli sorgenti del MiTM, rispettivamente e 8000, il restante valore indica invece la quantità di pacchetti RTP da inviare per l attacco. Il risultato è che la comunicazione è disturbata da un forte rumore di sottofondo dovuto alla ricezione dei pacchetti RTP indesiderati. La differenza con l attacco UDP sta nel fatto che in quel caso la conversazione era resa impossibile o eccessivamente ritardata per eccessivo traffico. Questo tipo di attacco non introduce ritardo ma disturba particolarmente la chiamata. A differenza di quanto accaduto con il client, in questo caso Asterisk si dimostra particolarmente robusto a questa tipologia di attacco. Se seguendo la stessa procedura appena mostrata, si identifica la porta RTP usata dal server e si tenta di disturbarla, non si ha nessun risultato Contromisure applicabili Combattere gli attacchi DoS in ambito VoIP è piuttosto difficoltoso. Questo è dovuto al fatto che il protocollo utilizza una serie di indirizzamenti standard universalmente accettati, che sono quindi passibili di attacco. È ovviamente possibile modificare tali scelte sul server, ma la complessità diventa il dover riconfigurare ogni singolo dispositivo con cui poi si effettuano le registrazioni. Bloccare con un firewall tutte le porte UDP è ovviamente inapplicabile; una soluzione utilizzabile solo in caso di rete di piccole dimensioni, che è stata provata sul prototipo, prevede la creazione di una lista di MAC autorizzati, scegliendo che il server ignori qualunque richiesta degli altri. Tale soluzione però risulta difficilmente scalabile in condizioni reali con moltitudine di utenti variabile in numero ed identità. L unica via percorribile risulta ricercare un firewall che monitori perennemente il canale rilevando tentativi di flooding. Sono disponibili diversi strumenti di questo tipo, tra i quali si consigliano Palo Alto Networks [M], Check Point [N], Fortinet [O], che effettuano operazioni di prevenzione e detection rilevando eventuali attacchi e bloccandoli. 90

98 Attacchi alla comunicazione Capitolo Attacchi MiTM all autenticazione ARP Spoof Si propone ora una metodologia per effettuare un attacco di tipo MiTM. Mediante questa operazione, un utente cerca di intromettersi nella comunicazione tra due parti dirottando il traffico in modo che passi attraverso il suo computer. Questo tipo di attacco richiede alcune operazioni preliminari, ma i risultati ottenibili sono certo più stimolanti. Il meccanismo di comunicazione tra host su una rete IP prevede che gli stessi comunichino utilizzando un indirizzamento comprensivo di: Indirizzo IP Indirizzo MAC Per realizzare le comunicazioni i dispositivi inviano in broadcast delle richieste per conoscere gli indirizzi MAC associati agli IP con cui devono comunicare. I messaggi di risposta vengono trasmessi in modalità unicast nella direzione opposta e contengono le informazioni richieste. Il protocollo ARP definisce in che modo effettuare l associazione tra indirizzi di livello network ed indirizzi di livello datalink mediante lo scambio di messaggi ARP. Una volta nota la corrispondenza, la comunicazione può avvenire in maniera direttiva evitando di coinvolgere utenti non invitati a parteciparvi. Per ridurre al minimo il traffico sulla rete, i dispositivi mantengono una cache delle associazioni ARP ricevute in modo da non dover farne continuamente richiesta. Per riuscire ad intercettare le conversazioni, un utente MiTM invia dei falsi messaggi ARP facendo credere di essere il destinatario di comunicazioni che non lo competono. Una volta ricevuti ed interpretati i messaggi, li inoltra verso la reale destinazione che è dunque ignara di quanto accaduto. Tale operazione prende il nome di ARP Poisoning ed è necessaria per eseguire correttamente l attacco. Si consideri quindi il prototipo di rete creato e si ipotizzi la comunicazione tra gli host max e gio così identificati (Tabella 6.1): Utente Indirizzo IP Indirizzo MAC max :25:b3:63:21:ca gio :1b:38:72:6e:4a Asterisk :1f:3c:dc:ac:d7 Utente MiTM :0c:29:3d:90:c7 91

99 Attacchi alla comunicazione Capitolo 6 Tabella Associazione indirizzi IP-MAC Per intercettare una comunicazione con successo, dal computer attaccante vengono mandati in continuazione messaggi ARP che mirano a modificare le tabelle di instradamento sostituendo il reale MAC dei destinatari con il proprio. Nello specifico si cerca di intercettare i pacchetti tra il server e l utente gio, effettuando ARP Poisoning sulla tratta utente-server. Per eseguire tale operazione, dalla macchina dell intruso si lancia il seguente comando:./arpspoof t È necessario ovviamente abilitare l IP Forwarding in modo tale che le richieste siano successivamente inoltrate verso la destinazione dopo l ascolto. In caso contrario la comunicazione verrebbe interrotta dal MiTM svelando l attacco. È ragionevole comprendere come per il corretto funzionamento della procedura, l ARP poisoning debba essere eseguito in maniera bidirezionale contaminando anche la comunicazione dal server verso l utente Cracking Authentication I test degli attacchi DoS avevano come scopo quello di disturbare o interrompere la comunicazione tra due utenti. Si è visto con quanta semplicità si possano ottenere tali risultati; è stato sufficiente usare alcuni semplici tools uniti alle informazioni sniffate dal canale per impedire a due persone di comunicare. Molto più pericoloso è il caso in cui un malintenzionato riesca ad impossessarsi delle credenziali di accesso di uno dei dispositivi della rete. Basti pensare cosa potrebbe accadere in una grande azienda se un alto dirigente comunicasse ad un intruso informazioni riservate. Gli effetti di tale azione potrebbero essere distruttivi, in relazione alle informazioni compromesse. Nei test seguenti si nota l importanza di un efficace sistema di autenticazione ed in particolare la debolezza estrema della semplice autenticazione del client con meccanismo HTTP Digest Authentication utilizzato in diversi contesti. Vengono perpetrati attacchi all autenticazione dell utente max che si autentica con SIP semplice e dell utente gio che sceglie un metodo più sicuro basato su TLS. Si utilizza il tool sipdump disponibile in backtrack e incaricato di intercettare le autenticazioni SIP. La sintassi per lanciare il comando è: 92

100 Attacchi alla comunicazione Capitolo 6./sipdump i eth0 autenticazioni.txt Dove eth0 è l interfaccia di rete utilizzata per l ascolto ed autenticazioni.txt è un file di testo contenente le informazioni ricavate dall attacco. Il risultato che si ottiene dall ascolto dei messaggi scambiati sul canale viene salvato nel file indicato, dove vengono memorizzati i valori delle informazioni contenute nel messaggio mandatp dal Client. Nel dettaglio il messaggio REGISTER contiene un indicazione del realm, l algoritmo MD5 scelto per l operazione di hash, il nome utente, il domino, il nonce ricevuto ed il digest calcolato che viene quindi inviato al server (Figura 6.9). Figura contenuto autenticazioni.txt Come si nota l utente max è stato intercettato facilmente e si conoscono pertanto tutte le sue informazioni significative, mentre gio, avendo protetto la segnalazione, non è stato tracciato e nessun output è registrato nel file autenticazioni.txt. Quindi in prima analisi per la protezione dell autenticazione degli utenti è imprescindibile l utilizzo di TLS almeno per limitare questo tipo di intrusioni. L overhead introdotto dall adozione di TCP a livello di trasporto è largamente ripagata in termini di sicurezza, come viene ora mostrato. Dall autenticazione SIP intercettata si ottengono le informazioni di interesse per sottrarre l identità della parte in questione. Nella sezione teorica dei primi capitoli è stato spiegato come funziona il meccanismo di autenticazione basato su digest, si è ora in possesso del risultato di tale operazione indicato dalla stringa alfanumerica 09397c3921fc7f8305f1821e1bff6044 e di tutti i parametri che sono stati mandati in ingresso ad MD5 per generarla (ovviamente tutti tranne la password). Quello che si vuole ottenere è scoprire quale sia la password che, utilizzata congiuntamente agli altri valori, fornisce lo stesso risultato trasmesso dal server. Viene utilizzato un attacco a forza bruta dopo aver creato un dizionario di riferimento. Un altro tool presente in backtrack, crunch, fornisce gli strumenti per la creazione del dizionario. Il programma consente di creare un file contenente tutte le possibili combinazioni di lettere, simboli e numeri di qualsiasi dimensione voluta. Ovviamente la complessità del dizionario è proporzionale all insieme dei parametri dati in ingresso ed alla lunghezza della stringa richiesta in uscita. Vista la limitatezza delle risorse hardware, si sono fissate la lunghezza dei termini del dizionario in otto caratteri (corrispondente alla reale lunghezza della 93

101 Attacchi alla comunicazione Capitolo 6 password) e si è fornito al programma le sole lettere e numeri {a,l,m,o,p,x,8,9} (tale scelta comprende i caratteri realmente presenti nella password ed i caratteri del nome utente). È ovvio che in questo modo si sceglie di effettuare i test in casi particolarmente vantaggiosi, ma è altresì vero che nella maggior parte dei casi le password scelte dagli utenti sono altrettanto semplici e con tools più potenti e risorse computazionali superiori si ottengono risultati equivalenti a quelli proposti in tempi comunque finiti. Si prosegue dunque a creare il dizionario contenente tutte le possibili combinazioni alfanumeriche esistenti a partire dal set di caratteri in ingresso. Tale dizionario viene memorizzato in un file testuale dizionario.txt che servirà in seguito per crackare la password dell utente. Si provvede alla creazione mediante il comando:./crunch 8 8 almopx89 o dizionario.txt I due 8 indicano la lunghezza minima e massima di tutte le parole del dizionario, come detto la si fissa in 8 caratteri per brevità. Con le risorse a disposizione, il programma impiega circa trenta secondi a creare un file di testo di 144MB con 2 24 = righe corrispondenti a tutte le possibili combinazioni dei caratteri di ingresso {a,l,m,o,p,x,8,9}. Preparato il set di chiavi da testare, si torna ad utilizzare il programma sipcrack e si specifica allo stesso di utilizzare il dizionario creato per scoprire la password di max mediante il comando:./sipcrack w dizionario.txt autenticazioni.txt in appena nove secondi vengono provate chiavi (trovata quella giusta il procedimento termina) fornite dal dizionario fino a scoprire la password corretta (Figura 6.10). Figura 6.10 Ottenimento password cercata 94

102 Attacchi alla comunicazione Capitolo 6 Ora il malintenzionato possiede sia il nome utente che la password di max e pertanto può connettersi, effettuare e ricevere chiamate, controllare eventuali caselle Voic o scambiare messaggi testuali rubandone l identità Contromisure applicabili È stata dunque dimostrata l effettiva inconsistenza dell autenticazione SIP che era stata anticipata nel capitolo 2. La cifratura della segnalazione è pertanto indispensabile per garantire la sicurezza del prototipo realizzato. Le scelte possibili per realizzarla sono due: 1. Risolvere il problema mediante la creazione di un canale sicuro grazie ad una Virtual Private Network (VPN) utilizzando poi IPSec. 2. Risolvere il problema cifrando solo la segnalazione mediante TLS. La prima scelta comporta non solo la cifratura dell autenticazione, ma di ogni pacchetto che viaggia sul canale. Tutto viene realizzato a livello di rete e la protezione è garantita sia alla segnalazione che al traffico multimediale. Questa scelta ha il vantaggio di semplificare notevolmente i problemi e di non introdurre eccessivo overhead, oltre ad essere trasparente alle applicazioni. La scelta di TLS è quella adottata in sede di sperimentazione, in quanto l interesse è quello di continuare a differenziare il signaling dal media plane in modo da poter altresì soddisfare in maniera mirata i requisiti di QoS di due traffici intrinsecamente diversi. Con questo protocollo si risolve il problema degli attacchi mirati all autenticazione proteggendo sia server che client grazie ad una segnalazione sicura, demandando ad SRTP la cifratura della conversazione. Ovviamente tale scelta porta con sé la necessità vista nel capitolo 4 di dover creare i certificati per il server e di dover riconfigurare i dispositivi. Si aggiunge un certo overhead ai messaggi scambiati, ma avendo visto la fragilità di HTTP Digest Authentication appare chiaro che ne valga la pena. 95

103 Attacchi alla comunicazione Capitolo Attacchi MiTM alla comunicazione (Eavesdropping) L eavesdropping è un attacco con cui un intruso cerca di intercettare passivamente i messaggi scambiati sul canale da due o più utenti. Nello specifico in questo contesto si utilizza l ARP Spoofing per reindirizzare i flussi scambiati tra gli utenti in modo che attraversino prima il dispositivo da cui si lancia l attacco. In questo modo è possibile, a seconda di quello che si desidera fare, registrare la conversazione, ascoltarla o disturbarla aggiungendo una sorgente audio indesiderata. Nel seguito vengono mostrati attacchi eseguiti nelle diverse condizioni possibili: Nessuna protezione né per segnalazione né per traffico voce Protezione segnalazione con TLS e nessuna protezione per traffico voce Protezione segnalazione con TLS e protezione voce con SDES-SRTP Protezione segnalazione con TLS e protezione voce con ZRTP-SRTP Nessuna protezione né per segnalazione né per traffico voce Si avvii il software Wireshark sul terminale utilizzato per lanciare l attacco e lo si configuri per ascoltare il canale di comunicazione utilizzato dagli utenti. Sempre dallo stesso dispositivo si lanci l ARP Poisoning per la tratta di collegamento tra l utente gio ed il server. Ora possono essere avviati i software VoIP degli utenti ed instaurata una chiamata tra le parti. Il traffico RTP associato alla conversazione, così come i messaggi di segnalazione, vengono reindirizzati sulla macchina del MiTM (Figura 6.11). Figura Messaggi ARP 96

104 Attacchi alla comunicazione Capitolo 6 Alle prime richieste ARP fa seguito la risposta dei dispositivi realmente destinatari delle stesse, dopodiché si vede come il canale venga saturato dalle ARP fasulle del MiTM. Il programma rileva un conflitto di indirizzo MAC in quanto l attaccante dichiara di essere destinatario di traffici diretti verso due IP differenti, questo ovviamente è voluto e in ogni caso non costituisce problema. Dunque ogni comunicazione tra il client gio ed il server attraverserà prima la macchina da cui viene lanciato l ARP Poisoning e, se i messaggi sono trasmessi in chiaro, il loro contenuto sarà facilmente leggibile dalla stessa. In questo primo test non sono stati adottati protocolli di sicurezza né per la segnalazione né per il traffico multimediale generato. Mediante la lettura dei messaggi SIP, Wireshark è in grado di riconoscere come RTP i flussi audio trasportati da UDP. Questo avviene grazie ai campi SDP trasportati da SIP in chiaro (Figura 6.12). Figura Traffico voce in chiaro Senza nemmeno l ausilio di programmi specifici per l hacking di comunicazioni VoIP, lo stesso Wireshark è dotato di uno strumento molto potente in grado di decodificare i flussi multimediali identificati, restituendo la registrazione della chiamata vocale effettuata tra le parti. Sfruttando tale caratteristica si riesce ad identificare chiaramente la conversazione effettuata tra l utente max e la controparte. Attenzione che anche nel caso in cui uno dei due utenti utilizzi cifratura per la voce nella tratta che lo separa dal server, tale protezione viene vanificata se la stessa tecnica non è ripetuta nella seconda tratta, essendo che SDES-SRTP opera prevalentemente su base hop-by-hop. Pertanto il livello di protezione generale del sistema è determinato dall elemento più debole che vi appartiene. Il risultato estrapolato dai pacchetti intercettati è mostrato nella figura seguente e corrisponde alla conversazione avvenuta tra i client (Figura 6.13). Figura Conversazione ascoltata 97

105 Attacchi alla comunicazione Capitolo Protezione segnalazione con TLS e nessuna protezione per traffico voce Come già era stato osservato nel capitolo precedente, la protezione della segnalazione mediante TLS non comporta alcuna cifratura del traffico multimediale. In realtà si è altresì anticipato come una leggera differenza sia presente: i campi SDP della segnalazione non sono più visibili e di conseguenza Wireshark non riesce più ad associare ai messaggi UDP un traffico voce. Attenzione, questo non vuol dire affatto che si è effettuata una cifratura di tali messaggi, ma solo che non è più sufficiente il solo uso di Wireshark per ottenere i risultati precedenti. Dopo aver tentato senza successo di ascoltare la comunicazione con alcuni strumenti consigliati in rete, si è trovato il software Cain & Abel [P] che ha permesso di ottenere i risultati aspettati dalle considerazioni teoriche. Tale applicativo è disponibile per Windows XP, pertanto si è deciso di lanciare l attacco da una delle macchina con indirizzo collegata allo switch che interconnette gli altri dispositivi del prototipo. Non si spiega il funzionamento dettagliato del software, si mostrano solo i punti fondamentali per ascoltare la chiamata tra gli utenti in esame. Dopo aver identificato mediante sniffing del canale quali siano i dispositivi presenti sullo stesso, si lancia l ARP Poisonig (Figura 6.14) sulla tratta di interesse ovvero tra il client gio ed il server Asterisk (equivalentemente a quanto fatto con backtrack ed arpspoof). Figura ARP Poisoning Si procede dunque a connettere gli utenti al server mediante autenticazione TLS e si avvia una telefonata. Il software automaticamente registra la conversazione voce tra gli utenti e, una volta terminata la stessa, il risultato viene memorizzato in un file audio in formato mp3 che resta disponibile per eventuali successive manipolazioni (Figura 6.15). 98

106 Attacchi alla comunicazione Capitolo 6 Figura 6.15 Registrazione conversazione Anche in questo caso il risultato è netto: la conversazione non ha alcuna protezione e l iniziale impossibilità di ascoltarla con Wireshark dovuta alla cifratura della segnalazione è stata superata con l ausilio del nuovo applicativo. È possibile ascoltare la conversazione effettuata dalle parti che viene mostrata divisa per direzione di provenienza (Figura 6.16). Figura 6.16 Conversazione intercettata Un altro tipo di attacco perpetrabile ad un sistema di comunicazione VoIP è quello del Voice Injection che, prevede di intromettersi attivamente nella conversazione tra le parti al fine di disturbarla o modificare quello che viene detto. Per fare questo è necessario procedere come visto in precedenza ad effettuare un ARP poisoning, in modo da reindirizzare le richieste verso il MiTM. Tale operazione è imprescindibile per intromettersi nella conversazione per disturbarla. In questo contesto si sceglie di disturbare la telefonata aggiungendo un file audio che viene allacciato al canale utilizzato dagli utenti. Per non essere banali, e restare in tema con il compito svolto, si sceglie di disturbare la conversazione riproducendo sullo stesso il brano Come on fell the noise di una nota rock band americana. 99

107 Attacchi alla comunicazione Capitolo 6 Dall osservazione del traffico mediante Wireshark, si entra in possesso delle informazioni necessarie sulle porte utilizzate dalle parti per la conversazione (Figura 6.17). Figura 6.17 Identificazione porte Utilizzando un altro applicativo disponibile su Backtrack, rtpmixsound, ci si intromette sul canale aggiungendo la musica di sottofondo indesiderata. Il programma effettua un mixaggio della conversazione in atto tra i partecipanti con il file audio desiderato:./rtpmixsound i eth0 a A b B cmonfeelnoise.wav Dove gli indirizzi IP e le porte sono quelle utilizzate dai client per la conversazione ed il file audio è quello scelto per il disturbo. Il risultato è che le parti non riescono a conversare agevolmente a causa del MiTM che, con l aggiunta di una sorgente di comunicazione, disturba gli utenti(figura 6.18). Nei casi reali più che disturbare la chiamata può interessare scambiare informazioni fasulle sul canale cercando di alterare una conversazione. Il procedimento per ottenere tale risultato è ovviamente lo stesso. Figura Introduzione musica Protezione segnalazione con TLS e protezione voce con SDES-SRTP 100

108 Attacchi alla comunicazione Capitolo 6 Ora si osserva cosa accade quando realmente viene applicato un sistema di sicurezza per il media plane. Nello specifico in questo caso si è utilizzato SDES-SRTP ovvero si è usato il canale sicuro offerto per la segnalazione grazie a TLS per includere nei messaggi SIP la chiave crittografica da utilizzare per garantire la sicurezza. Come spiegato nel capitolo 2 tale sistema prevede l aggiunta di un campo nel corpo SDP trasportato nella segnalazione. Essendo il prototipo limitato ad un hop tra sorgente e destinazione ed essendo tale hop il server Asterisk sicuro, si assume che TLS costituisca un valido sistema di sicurezza e che dunque la chiave di cifratura sia scambiata senza intromissioni. Come per il caso precedente si sceglie di utilizzare Cain & Abel per gli attacchi e si segue la procedura di ARP Spoofing già spiegata in precedenza. Dall osservazione mediante Wireshark si nota come i traffici siano reindirizzati verso il MiTM come richiesto. Secondo quanto appreso dalla teoria non dovrebbe essere possibile ascoltare la chiamata tra gli utenti. Da un analisi con Wireshark risulta anche in questo caso che il traffico viene marchiato come UDP, senza specificare cosa sia trasportato, questo perché la cifratura riguarda solo il il payload (Figura 6.19). Figura Traffico multimediale identificato UDP La telefonata viene registrata così come nel caso di assenza di protezione, ma a differenza di quanto mostrato in mancanza di cifratura, il risultato di tale registrazione è solo ed esclusivamente rumore (Figura 6.20). Non vi è traccia alcuna della conversazione effettuata e si assume quindi che la cifratura abbia eseguito correttamente il suo compito. Figura 6.20 Risultato della cifratura della voce Protezione segnalazione con TLS e protezione voce con ZRTP-SRTP 101

109 Attacchi alla comunicazione Capitolo 6 Il grande vantaggio di ZRTP è che consente di slegare completamente la sicurezza della conversazione da quella della segnalazione. Si può scegliere o meno di proteggere SIP mediante TLS, tale scelta è a discrezione dell utente finale. In ogni caso anche in mancanza di protezione della segnalazione, un intromissione dovrebbe essere rilevata da una variazione nel SAS. In questo test per semplicità si è scelto di inviare la segnalazione in chiaro. Si ricorda che a differenza del caso SDES questa procedura viene effettuata direttamente dai client gestendo autonomamente la generazione e lo scambio delle chiavi su base end-to-end. Eseguendo la procedura di attacco in maniera analoga a quanto fatto nei casi precedenti, si osserva come sia possibile ascoltare la prima parte della conversazione tra le parti contraddistinta come traffico in chiaro RTP (Figura 6.21). Figura 6.21 Traffico voce iniziale in chiaro Questa prima fase è precedente alla verifica del SAS e si desidera ovviamente che termini il prima possibile per evitare di conversare senza protezione. Come mostrato nella figura seguente, sui display degli utenti viene visualizzato un messaggio differente, a testimonianza del fatto che è stato rilevato un attacco MiTM alla comunicazione (Figura 6.22). Figura Identificazione attacco Realizzata la probabile minaccia MiTM, i due utenti possono quindi scegliere di concludere la chiamata. Ovviamente nel caso in cui si decida di proseguire, il protocollo ZRTP conclude 102

110 Attacchi alla comunicazione Capitolo 6 comunque la procedura di scambio chiavi a seguito della scadenza del timer associato al SAS e cifra la comunicazione vocale grazie a SRTP. Dunque l intromissione è stata rilevata e la conversazione è stata comunque protetta come desiderabile in un efficiente sistema di telecomunicazione VoIP. In seguito si mostra come la prima parte della telefonata sia effettuata in chiaro, una volta scaduto il timer invece entra in gioco SRTP e si percepisce solo ed esclusivamente rumore come per il caso SRTP-SDES (Figura 6.23). Figura 6.23 Risultato ascolto conversazione con ZRTP 103