Questa sezione si occupa di descrivere i moduli principali di PJSIP, coin- volti nel sottosistema di autenticazione e cifratura dell’architettura ABPS. Nella figura che segue sono evidenziati le componenti della libreria che svol- gono tale compito:
91
Client ABPS in Symbian
Come accennato in precedenza, allo stato attuale non esiste alcuna im- plementazione completa del client ABPS per Symbian OS.
Manca ad esempio la parte che si occupa della gestione del multi-homing; il modulo di autenticazione era parzialmente implementato, ma soffriva di numerosi problemi che verranno trattati nell’apposita sezione.
Symbian OS stesso presenta molte differenze dai sistemi operativi pi´u comuni come Linux e Windows, in particolare per quanto riguarda la gestione della rete e il supporto per i thread.
Inoltre, il codice sorgente ´e stato rilasciato da poco e sono scarsi gli stru- menti di supporto allo sviluppo: l’SDK Nokia (System Developement Kit), funziona solo in ambiente Windows cos´ı come il simulatore, che ´e afflitto da performance scarsissime e offre il supporto per una sola interfaccia di rete.
Nello sviluppo per il sistema operativo Symbian pertanto, si sono adottate alcune scelte tecniche diverse rispetto alle implementazioni esistenti.
In particolare ´e stato deciso di accorpare il client SIP con il proxy client ABPS.
Lo User Agent ABPS ´e implementato all’interno del file ua.cpp
Modulo di Registrazione
Il modulo di registrazione ´e quella componente della libreria PJSIP, im- plementata nel file sip reg.c, che si occupa del processo di registrazione di un client verso un server SIP.
Al momento dell’attivazione di un determinato account presente nel client, questo modulo ´e deputato alla creazione dei messaggi REGISTER as- socciati, e alla gestione dei SIP Response relativi. In particolare, quando il server risponde con un errore di tipo 401/407, richiedendo un’autenticazione di tipo challenge-response, questo modulo si appoggia a quello di autenti- cazione (sip auth.c) per costruire il corretto response da inserire all’interno della successiva REGISTER.
92 Progettazione e Sviluppo
Se la registrazione effettuata con successo, ´e avvenuta verso un proxy server ABPS, allora viene caricato anche il modulo relativo (mod abps), che si occuper´a della firma dei messaggi SIP/ABPS.
Modulo di Autenticazione
Le funzioni di supporto all’autenticazione del client si trovano nel mo- dulo sip auth client.c, che ´e stato opportunamente esteso per implementa- re, oltre alla classica autenticazione HTTP/Digest descritta in precedenza e disponibile in PJSIP, anche quella relativa al sistema ABPS.
I messaggi tra client e server proxy, scambiati successivamente ad un’au- tenticazione avvenuta con successo, dovranno essere opportunamente modifi- cati per aggiungere ai pacchetti SIP i campi relativi al protocollo SIP/APBS. Queste estensioni sono implementate all’iterno del file sip auth msg.c e contengono i campi descritti in precedenza:
• Proxyclientid: identifica univocamente il client all’iterno del sistema ABPS.
• Seqnum: numero di sequenza relativo ai pacchetti del protocollo SIP/ABPS.
• Fingerprint: hash del messaggio calcolato in funzione della chiave di sessione condivisa.
Il modulo ABPS
Questo modulo viene caricato successivamente all’avvenuta registrazione verso un proxy server ABPS. Il client a questo punto ´e in possesso della chiave condivisa (session key ia), per poter firmare i messaggi.
Questo modulo, che ha priorit´a di livello applicazione
(PJSIP MOD PRIORITY APPLICATION), intercetta ogni messaggio SIP diretto verso il proxy server ABPS o ricevuto da quest’ultimo.
93
Se si tratta di un messaggio diretto al proxy server allora vengono aggiunti i campi relativi al protocollo SIP/ABPS, tra cui il fingerprint associato al messaggio stesso.
Se il messaggio proviene dal proxy, il modulo si occupa di accertarne l’autenticit´a attraverso il calcolo del fingerprint e, qualora questo superi il controllo, di inoltrarlo verso l’applicazione User Agent.
Costruzione dell’INVITE
L’header SDP all’interno del messaggio INVITE, deve essere esteso per includere lo Zrtp Hello Hash, ovvero l’hash del primo messaggio di Hello relativo al protocollo ZRTP, che verr´a avviato in seguito, preliminarmente alla costruzione del canale sicuro SRTP.
Come spiegato in precedenza, questa operazione serve ad evitare attacchi di tipo MiTM, realizzando uno scambio di chiavi in modalit´a Diffie-Helmann, autenticato grazie all’avvenuto scambio dell’hash. Quest’ultimo infatti per- mette, ad entrambe le parti coinvolte nel protocollo, di accertare l’autenticit´a dei primi messaggi ZRTP scambiati, essendo entrambi a conoscenza del valore hash di questi, prima che inizi il vero e proprio scambio di chiavi.
L’integrit´a dello Zrtp Hello Hash ´e garantita in quanto lo scambio av- viene attraverso messaggi del protocollo SIP/ABPS, che sono a loro volta autenticati grazie alla chiave di sessione condivisa (session key ia) scambiata in precedenza.
Il file sdp.c, che contiene le funzioni di supporto al protocollo SDP, ´e stato esteso per permettere l’aggiunta del campo zrtp-hash.
Transport SRTP
La trasmissione dei messaggi in PJSIP, avviene attraverso l’utilizzo di moduli denominati Transport, ognuno dei quali si occupa della gestione di un determinato protocollo, come ad esempio UDP (transport udp.c) e TCP (transport tcp.c).
94 Progettazione e Sviluppo
I Transport sono moduli indipendenti l’uno dall’altro, ma spesso coope- rano tra loro attraverso chiamate in sequenza che replicano la gerarchia dei protocolli.
Un esempio concreto ´e il Transport SRTP (transport srtp.c), che si oc- cupa di cifrare i datagram RTP, costruiti dal livello multimediale, e di tra- smettere i pacchetti SRTP creati attraverso il sottostante Transport UDP.