Progettazione e sviluppo di un prototipo per la

Transcript

•
UNIVERSITÀ POLITECNICA DELLE MARCHE
FACOLTÀ DI INGEGNERIA
Corso di Laurea Specialistica in Ingegneria Informatica
Progettazione e sviluppo di un prototipo per la
comunicazione sicura attraverso il canale GSM-Voce
TESI DI LAUREA
Relatore:
Tesi di Laurea di:
Chiar.mo Prof. Aldo Franco Dragoni
Anno Accademico 2010-2011
Gianluigi Biancucci
Indice
1. Il Progetto
1.1 Introduzione
1.2 Obbiettivi
1.3 Descrizione preliminare
2. Environment tecnologico del progetto di ricerca
2.1 Il canale GSM
2.1.1 Codifica vocale GSM
2.1.2 Adaptive Multi Rate
2.1.3 Linear Predictive Coding
2.1.4 Codifica ACELP
2.1.5 ACELP in dettaglio
2.2 Bluetooth
2.2.1 Bluetooth Hands Free Profile
2.3 Crittografia
2.3.1 Scambio di chiavi ed autenticazione
2.4 Modulazione digitale
2.4.1 Amplitude-shift Keying (ASK)
2.4.2 Frequency-shift Keying (FSK)
2.4.3 Phase-shift Keying (PSK)
3. Le soluzioni attualmente presenti nel mercato
3.1 La situazione attuale
3.2 Un esempio: TopSec Mobile
3.2.1 Autenticazione
2
3.2.2 Osservazioni
4. Il lavoro svolto
4.1 Tutela del segreto aziendale
4.2 La codifica della voce
4.3 Cifratura ed Autenticazione
4.4 La comunicazione con il cellulare
4.5 Modulazione e Demodulazione
5. Il prototipo realizzato: implementazione
5.1 Sviluppo Bluetooth: il punto della situazione
5.1.1 Gnu/Linux e BlueTooth Hands-Free Profile
5.1.2 Configurazione e Test
5.2 La piattaforma di sviluppo
5.3 L'implementazione software sviluppata
6.Test Effettuati
6.1 Banda di frequenze garantita dall'encoder GSM
6.1.1 Metodologia di Test
6.1.2 Risultati
6.2 Il test del prototipo sviluppato
6.2.2 Risultati
7. Conclusioni e sviluppi futuri
Appendice A
Bibliografia
Ringraziamenti
3
4
“No, la nostra scienza non è un’illusione.
Sarebbe invece un’illusione credere di poter ottenere da altre fonti ciò che essa non è
in grado di darci.”
(S. Freud)
5
Capitolo 1
Il Progetto
1. Il Progetto
1.1
Introduzione
La rete di comunicazione più utilizzata a livello globale è sicuramente il
canale GSM-Voce. Sfortunatamente queste reti sono affette da seri problemi di
vulnerabilità agli attacchi “hardware-based” rendendo quindi la comunicazione
facile da intercettare in determinati scenari1.
Sebbene sia stata provata l'efficacia degli algoritmi di cifratura utilizzati nel
canale GSM-Voce2 , la confidenzialità del traffico è assicurata solamente
attraverso il canale radio:
il traffico vocale infatti è trasmesso in chiaro
attraverso le “core networks” (ovvero la sottorete della struttura GSM, posta a
terra, che permette l'instradamento delle chiamate da dispositivi mobile verso la
1 M. Toorani, A. A. Beheshti Shirazi, (2008), “Solutions to the GSM Security Weaknesses”, The Second
International Conference on Next Generation Mobile Applications, Services and Technologies
2 C. Lo, Y. Chen, (1999), “Secure communication mechanisms for GSM networks”, IEEE
Transactions on Consumer Electronics, Vol 45.
6
Capitolo 1
Il Progetto
rete PSTN classica od in roaming).
Ovviamente questa problematica potrebbe portare alla possibilità di accessi non
autorizzati a conversazioni GSM-GSM nel qual caso la confidenzialità della
comunicazione non è controllata dall'utente ma dall'operatore di rete.
Uno scenario in cui la sicurezza della comunicazione è delegata all'utente
è preferibile in molte applicazioni (militare, spionaggio industriale, etc...): per
realizzare ciò è necessario che la trasmissione sia cifrata prima di essere
trasmessa nella rete GSM-Voce. [Figura 1.1].
Voice
Encryption
Gsm
Compression
GSM
Communication Network
Voice
Decryption
Gsm
Decompression
Figura 1.1: Cifratura lato utente
Anche il canale GSM-Dati può essere utilizzato per instaurare una conversazione
cifrata, (e ne esistono alcuni esempi di dispositivi in commercio) ma questo
approccio soffre di alcuni svantaggi3:
•
Il canale GSM-Dati soffre di alcuni evidenti problemi di interoperabilità
attraverso le reti internazionali4
3 N.N. Katugampala, K.T.Al-Naimi, S. Villeie, A. Kondoz, (2004), “Real time data transmission
over GSM voice channel for secure voice and data applications”, IEE Secure Mobile Communications
Forum: Exploring the technical Challenges in Secure GSM and WLAN
4 Michael Street, (2003), “Interoperability and international operation: An introduction to endto-end mobile security”, IEEE Secure GSM and Beyond: End to End Security for Mobile
Communications.
7
Capitolo 1
Il Progetto
•
Il canale GSM-Dati richiede in media il doppio del tempo per instaurare
una comunicazione rispetto alla linea voce.
Risulta quindi evidente come lo sviluppo di un dispositivo con tali
caratteristiche possa portare dei vantaggi tangibili e colmare le lacune principali
di cui soffrono gli attuali dispositivi che operano all'interno dello stesso
contesto.
8
Capitolo 1
Il Progetto
1.2 Obbiettivi
L'obbiettivo finale del progetto, all'interno del quale il mio lavoro di
tirocinio si colloca, è quello di sviluppare un dispositivo che agisca da interfaccia
tra l'utente ed un qualsiasi cellulare instaurando così una comunicazione cifrata
attraverso il canale GSM-Voce. Il dispositivo dovrà quindi essere in grado di
interfacciarsi correttamente con il telefono,
gestire
in maniera ideale la
cifratura e l'autenticazione tra i due dispositivi, garantendo al tempo stesso una
comunicazione fluida e priva di errori [Figura 1.2].
INPUT
SPEECH
DEVICE A
GSM
OUTPUT
SPEECH
DEVICE B
Figura 1.2: Il dispositivo oggetto di ricerca
La realizzazione di un tale obbiettivo obbliga uno studio interdisciplinare
del problema, spaziando da argomenti di informatica ad argomenti di
telecomunicazioni e passando per argomenti tipici dell'elettronica; risulta quindi
chiaro come un progetto di tale portata non possa essere iniziato e concluso
nell'ambito di un tirocinio universitario ma richiede maggior tempo e sforzi di
9
Capitolo 1
Il Progetto
ricerca.
In particolare, il lavoro da me svolto ( di cui questa tesi ne è il resoconto e
la conclusione ) si colloca nella fase di avvio del progetto: l'obbiettivo è stato
quello di discernere le problematiche principali relativamente a differenti ambiti
di studio interdisciplinari, per poi passare in un secondo momento allo sviluppo
di un prototipo utile come “proof-of-concept” delle soluzioni prospettate.
10
Capitolo 1
Il Progetto
1.3 Descrizione preliminare
Vediamo ora di descrivere ad un primo livello di dettaglio il dispositivo in
questione; mostrando quali sono i contesti tecnologici e di ricerca che uno
studio di questo tipo va a toccare.
Come detto in precedenza, il dispositivo dovrà fungere da interfaccia tra
l'utente ed il cellulare instaurando una comunicazione cifrata fluida e priva di
errori.
Un primo vincolo che caratterizzerà lo studio è il canale dove verrà instaurata la
comunicazione: si è scelto l'utilizzo del canale GSM-Voce invece di quello dati a
causa dei problemi già documentati di cui una comunicazione su questo canale
soffre.
Oltre a ciò, il telefono cellulare connesso al nostro dispositivo è visto dallo stesso
come una black-box nella quale non possiamo intervenire ma unicamente
interfacciarci in modo corretto.
Per raggiungere un tale risultato si è scelto inoltre di effettuare il cifraggio
in maniera digitale: ciò ci permette di avere una robustezza maggiore rispetto ai
classici scrambler5 analogici e di riutilizzare il know-how e la letteratura esistente
in diversi ambiti. D'altro canto, questa strada comporta scelte più onerose a
livello computazionale e di conversione dei segnali come vedremo in seguito.
Ad una prima analisi, si può evidenziare come per instaurare la
comunicazione il dispositivo deve svolgere le seguenti attività [Figura 1.3]:
•
Conversione della voce in un segnale digitale tramite un codec low-rate
•
Suddivisione in pacchetti e cifratura dello stream vocale
5 Advances in Digital Speech Transmission (Martin, Ulrich)
11
Capitolo 1
Il Progetto
•
Modulazione e conversione D/A dei singoli pacchetti cifrati in una forma
d'onda analogica.
•
Invio del segnale analogico al telefono tramite una interfaccia universale
(wired o wireless)
DEVICE A
Speech
Encoder
INPUT
SPEECH
1011000...
Data
Encryption
1101001...
Data
Modulation
GSM
DEVICE B
Data
Demodulation
1101001...
Data
Decryption
1011000...
Speech
Decoder
OUTPUT
SPEECH
Figura 1.3: Blocchi funzionali del dispositivo quando agisce come
mittente o ricevente
Quanto appena detto è valido relativamente ad un dispositivo che agisce da
mittente: ovviamente la logica funzionale dello stesso dispositivo quando agisce
da ricevente è, come si può notare in figura, esattamente inversa.
Per comprendere appieno le scelte effettuate durante lo sviluppo del
primo prototipo è necessario innanzitutto introdurre l'environment tecnologico
in cui la ricerca si colloca, al fine di valutare le tecnologie da utilizzare ed i vincoli
da superare.
12
Capitolo 2
Environment tecnologico del progetto di ricerca
2. Environment tecnologico del progetto di ricerca
2.1 Il canale GSM
Il GSM (Global System for Mobile Communications) è uno standard
sviluppato dall'Istituto Europeo per le Telecomunicazioni (ETSI) per descrivere le
tecnologia di seconda generazione delle reti cellulari. Sviluppato inizialmente
come rimpiazzo delle reti di prima generazione analogiche, lo standard GSM
definisce una linea digitale, a commutazione di circuito, ottimizzata per
comunicazioni vocali full-duplex. Lo standard è stato esteso nel tempo
aggiungendo dapprima una linea per lo scambio di dati che funzionasse sopra
l'infrastruttura a commutazione di circuito della rete GSM (CSD), in seguito la
possibilità di una connessione a commutazione di pacchetto per lo scambio di
dati e l'accesso ad internet (GPRS) con velocità sempre crescenti (EDGE).
13
Capitolo 2
Lo scambio di dati tramite protocollo GSM-CSD è oggigiorno ormai in disuso.
Il GSM è una rete cellulare, questo significa che i telefoni si connettono
alla rete cercando delle celle nelle immediate vicinanze. Il diametro e la
distribuzione di queste celle cambia a seconda della conformazione geografica e
della densità di abitanti del luogo. La trasmissione tra il telefono è limitata ad un
massimo di 2 watt di potenza ed a quattro bande di frequenza 850/900 Mhz e
1800/1900 Mhz.
La struttura tipica di una rete GSM è quella mostrata in figura 2.1.
Figura 2.1 : Infrastruttura GSM
Si possono evidenziare le seguenti sottosezioni della rete:
•
Mobile Stations (MS): coincide con i dispositivi terminali con cui si
interfacciano le utenze
•
Base Station Subsystem: é la componente che caratterizza la rete
cellulare rispetto alle reti cablate ed implementa la comunicazione tra il
14
Capitolo 2
terminale mobile e la rete di trasporto interna. Questa comprende la BTS
(Base Transceiver Station ) che funge da interfaccia radio tra i terminali
mobili ed il BSC (Base Station Controller) che rappresenta il “cervello”
della rete GSM gestendo tutti gli aspetti del protocollo e la
comunicazione tra interfaccia radio e rete fissa
•
Core Network: rappresenta la componente di rete fissa che si interfaccia
con la rete cellulare. Questa è suddivisa in NSS (Network Subsystem) che
è la sottorete che instrada i dati verso la rete di telefonia PSTN classica, e
nella GPRS Core network , ovvero la parte di rete opzionale che
implementa la commutazione di pacchetto per l'accesso ad internet.
Come già sottolineato in precedenza (Vedi Sez. 1.1), la sicurezza della
comunicazione è garantita tra la stazione mobile e la BSS, mentre tra la BSS ed il
resto della rete la comunicazione viaggia in chiaro.
Risulta evidente l'esigenza di cifrare la comunicazione lato utente al fine di
evitare attacchi di tipo man-in-the-middle1 che accedono ai dati in chiaro.
Essendo la linea GSM una linea digitale, Il vincolo principale affinchè il
nostro stream vocale cifrato venga inviato e ricevuto correttamente attraverso il
canale GSM-Voce, è posto nell'algoritmo di codifica e compressione della voce
presente nelle mobile stations. Analizziamo ora in dettaglio questo aspetto.
1 http://en.wikipedia.org/wiki/Man-in-the-middle_attack
15
Capitolo 2
2.1.1 Codifica vocale GSM
La voce, intesa come suono generato dalla vibrazione delle corde vocali,
viene convertita in un segnale elettrico dal trasduttore presente nel telefono
(microfono). Questo segnale elettrico (analogico) viene successivamente
convertito e campionanto in digitale dall'Analog-Digital
Converter (ADC)
integrato nel telefono per poi essere compresso dal codec vocale GSM ed inviato
sulla linea GSM-Voce [Figura 2.2].
INPUT
SPEECH
ADC
Audio Converter
PCM Audio
Stream
8Khz Sampling rate
13 bit per Sample
GSM Codec
Compression
GSM
Figura 2.2: Flusso vocale all'intero di un cellulare
Il segnale in uscita dall'ADC utilizza la codifica Pulse Code Modulation
(PCM). Attraverso questa codifica viene rappresentato il parlato in un numero
fisso di campioni al secondo. Poichè il campionamento avviene ad 8 Khz è
necessario rispettare il teorema del campionamento di nyquist-shannon:
f c >2f s
dove fc è la frequenza di campionamento e fs è la più alta frequenza del segnale.
Affinchè ciò avvenga, viene applicato nello stadio pre-campionamento un filtro
anti-aliasing passa banda 200-3400Hz secondo le ultime specifiche GSM 06.90
16
Capitolo 2
( 1998 ) e viene codificato ogni sample con 13 bit.
Figura 2.3: Codifica PCM del segnale vocale
Il segnale risultante, con un bit-rate di 104 kbps, viene poi compresso
attraverso il codec vocale GSM [Figura 2.2]. Lo standard GSM, evolutosi nel corso
del tempo, includeva inizialmente 2 codec vocali: Full-Rate (FR) (GSM 06.10) e
Half-Rate (HR) (GSM 06.20). E' stato poi aggiunto il codec Enhanced Full Rate
(EFR) e con lo standard GSM 06.90 sono state incluse le codifiche Adaptive Multi
Rate (AMR) che consentono di ottenere un bit-rate variabile, anche inferiore
rispetto agli standard precedenti e con una qualità audio migliore [Tabella 2.4].
Codec
Bit Rate (Kbit/s)
Codec Type
Full Rate
13
RTE-LTP
Half Rate
5.6
VSELP
Enhanced Full Rate
12.2
ACELP
AMR 12.2
12.2
ACELP
AMR 10.2
10.2
ACELP
AMR 7.95
7.95
ACELP
AMR 7.4
7.4
ACELP
AMR 6.7
6.7
ACELP
AMR 5.9
5.9
ACELP
AMR 5.15
5.15
ACELP
AMR 4.75
4.75
ACELP
Tabella 2.4: Codec supportati dallo standard GSM 06.90 e successivi
Poiché dallo standard GSM 06.90 del 1998 tutti i telefoni cellulari utilizzano la
codifica AMR, analizzeremo qui di seguito questo tipo di codec, sapendo che
17
Capitolo 2
sarà proprio questo codec l'incaricato di comprimere lo stream audio criptato in
uscita dal nostro dispositivo.
18
Capitolo 2
2.1.2 Adaptive Multi Rate
Il codec AMR (chiamato anche AMR Narrow Band, AMR-NB) rappresenta
lo stato dell'arte in fatto di codificatori vocali per reti radiomobili, è stato
introdotto come standard per le reti di terza generazione per poi diventare uno
standard anche per le reti GSM (GSM 06.90). L'Adaptive Multi Rate è un sistema
di codifica di tipo multimodale, offrendo otto diverse frequenze di cifra possibili
(12.2 Kbit/s , 10.2 Kbit/s , 7.95 Kbit/s , 7.40 Kbit/s , 6.70 Kbit/s , 5.90 Kbit/s ,
5.15 Kbit/s , 4.75 Kbit/s ), con la possibilità, durante la trasmissione di cambiare
da un rate a un altro agendo sulla codifica di canale.
Questa caratteristica è chiamata Discontinuous Transmission (DTX) 2.
Per risparmiare bandwith, durante i periodi di silenzio, questo tipo di codifica
utilizza tecniche di Voice Detection2 e Confort Noise Generation2 per sostituire ai
periodi di silenzio del rumore artificiale che risulta più confortevole all'orecchio
umano evitando così agli utenti di confondere un periodo di silenzio con
l'assenza della comunicazione.
L' Adaptive Multi Rate è un codec ibrido ( questo significa che lavora sia nel
dominio della frequenza che nel dominio del tempo come vedremo in seguito)
ed utilizza il codificatore Algebraic Code Excited Linear Prediction (ACELP) per
comprimere il segnale vocale PCM 8KHz/13bit filtrato tra 200-3400Hz di cui
abbiamo parlato in precedenza.
Prima di presentare il codificatore ACELP, è necessario introdurre lo
schema di analisi Linear Predictive Coding sul quale questo si basa, ovvero la
codifica della voce basata sulla predizione lineare.
2 GSM, GPRS and edge performance: evolution towards 3G/UMTS, Halonen, Romero
19
Capitolo 2
2.1.3 Linear Predictive Coding
L'idea alla base dell'analisi predittiva è che un campione di parlato è
rappresentabile come combinazione lineare dei campioni ad esso precedenti:
p
s( n)≃̂s (n)=a1 s( n−1)+a 2 s (n−2)+...+a p s( n− p)=∑ a k s(n−k )
k =1
dove
s( n) rappresenta l'n-esimo campione,
̂s (n) rappresenta invece la sua
stima, come combinazione lineare dei coefficienti precedenti. Definiamo invece
con e (n) l'errore di predizione dato da:
e (n)=s (n)−̂s ( n)
Il calcolo dei singoli coefficienti
a k (determinati in maniera ottima)
contengono l'informazione spettrale del segnale in ingresso e permettono la
ricostruzione del segnale attraverso un Filtro Infinite Impulse Response3.
L’ipotesi principale per applicare l’analisi LPC al parlato è il fatto che questo si
mantenga ,all’incirca stazionario per un periodo di tempo; si può dimostrare che
avendo in ingresso un segnale campionato a 8 KHz , la stazionarietà sarà
mantenuta per circa 80-130 campioni, ovvero 10-16 ms. Quindi, una volta
segmentato il segnale in intervalli (lo standard GSM-AMR utilizza intervalli di 160
campioni, 20 ms), verrà applicata a ciascun vettore un’analisi di predizione
lineare, con un numero di coefficienti k solitamente variabile tra 8 e 14, (lo
standard LPC-10 ne utilizza 10 così come il codec AMR).
3 http://it.wikipedia.org/wiki/Infinite_impulse_response
20
Capitolo 2
2.1.4 Codifica ACELP
La codifica ACELP rappresenta lo stato dell'arte in fatto di codificatori
vocali, permettendo di creare segnali di buona qualità con bit-rate nell'ordine
dei 4 Kbit/s. L'Algebraic Code Exicited Linear Prediction è basato, come si può
intuire dal nome, su algoritmi di predizione lineare.
La particolarità di questo metodo sta nel come viene trattato il residuo di
predizione o errore di predizione
e (n) . Nella codifica predittiva infatti, se
l'errore residuo fosse usato come eccitazione del filtro in ricezione, si otterrebbe
un segnale identico all'originale. Di conseguenza se l'eccitazione si avvicinasse di
molto al residuo di predizione, allora il segnale ricostruito avrebbe comunque
una qualità molto elevata.
L'innovazione della codifica ACELP è avere già a disposizione delle possibili
eccitazioni ed inviare quella che più si avvicina al residue del segnale predetto al
mittente.
In questo caso quindi non sarà più necessario spedire il residuo ma solo un
indirizzo ad una parola in un elenco o codebook, ovviamente noto anche al
ricevitore.
La codifica ACELP si pone in un panorama più ampio di codificatori Analysis-bySynthesis, questi codificatori si appoggiano tutti sullo schema LPC, tuttavia in
essi si pone il problema di una buona qualità del parlato, quindi useranno alcune
operazioni per trattare anche il residuo di predizione. A questo proposito, i
codificatori Analysis-by-Synthesis usano due filtri di predizione, uno a breve
termine, per eliminare la prima ridondanza tra campioni vicini, generata dalle
tipiche variazioni dello spettro del segnale vocale (le formanti), e uno a lungo
termine per trovare una possibile ridondanza tra campioni lontani.
21
Capitolo 2
Figura 2.4: predittori LPC in cascata nello schema Analysis by Synthesis
L’azione combinata dei due predittori permette di avere come risultato un
residuo di predizione che può essere rappresentato e trasmesso in modo
efficiente. In figura (2.5) si mostra un esempio del codificatore Analysis-bySynthesis. Si noti che la pesatura dell’errore viene effettuata per
motivi
psicoacustici, infatti, si cercherà di distribuire l’errore dove è meno percettibile
per l’udito umano.
Figura 2.5: Esempio di codificatore Analysis by Synthesis
22
Capitolo 2
2.1.5 ACELP nel dettaglio
Il codificatore ACELP si basa su uno schema di funzionamento CELP, code
Excited Linear Prediction, e differisce da quest'ultimo solo nel modo in cui viene
scelta l'eccitazione relativa al segnale uscente dai due blocchi di analisi
predittiva (LPC, Short Term predictor).
Figura 2.6: codificatore ACELP (AMR GSM 09.60 )
Il sistema riceve in ingresso il segnale PCM descritto in precedenza suddiviso in
segmenti temporali di 160 campioni (20ms) suddivisi in di 40 campioni.
Il primo passo sarà l'analisi LPC in sottofinestre da 40 campioni sulle quali
verranno calcolati i coefficienti
a k , successivamente verrà effettuata l'analisi
LTP che prenderà in input i 40 campioni attuali ed i precedenti per generare il
filtro di predizione a lungo termine sulla finestra da 160 campioni.
23
Capitolo 2
Verrà quindi calcolato l'errore residuo
e ' (n) decorrelato da dal segnale di
pitch (ma dipendente dall'eccitazione di pitch precedente).
L'ultimo passo della codifica ACELP è la ricerca nel codebook del errore residuo
da inviare che sia più simile al residuo attuale minimizzato ( tramite il filtro
W (z ) ).
Concludendo, quanto detto fino ad ora, mostra a livello generale lo
studio effettuato sulle codifiche GSM che, nel corso del progetto di ricerca, è
state dettagliato, approfondito e focalizzato a raggiungere specifici obbiettivi di
sviluppo.
24
Capitolo 2
2.2 Bluetooth
L'idea alla base del progetto è quella di interfacciare il dispositivo in fase
di studio con il telefono cellulare tramite una connessione Bluetooth4.
Analizziamo brevemente le caratteristiche fondamentali del protocollo.
Il Bluetooth (BT) è uno standard per la comunicazione wireless a corta distanza
per reti personali senza fili (Wireless Personal Area Network – WPAN) con alti
livelli di sicurezza. E' un protocollo open, ma proprietario poiché richiede
l'acquisto di licenze per poter essere implementato.
Il Bluetooth usa il Frequency-Hopping spread spectrum5 per inviare i dati tramite
il modulo radio: il dato da inviare viene suddiviso e trasmesso su 79 bande da 1
mhz ognuna compresa tra i 2402 ed i 2480 -Mhz.
Il protocollo è basato sullo scambio di pacchetto con un data-rate massimo nella
versione 3.0 di 24 Mbit/s ed un raggio di copertura massimo di 10 metri.
L'infrastruttura di una rete Bluetooth non è omogenea, ma ha un architettura di
tipo master-slave, dove ogni master può essere connesso con un massimo di 7
slave definendo così una piconet. Lo scambio di pacchetti è basato sul clock
definito dal master, che tutti i device connessi nella piconet condividono.
Il ruolo master-slave in una piconet non è immutabile ma un dispositivo può
decidere di passare da master a slave per ragioni specifiche.
Lo scheduling della comunicazione all'interno del master, è effettuato attraverso
algoritmi similial round-robin6 per evitare la starvation6.
Il Bluetooth utilizza un algoritmo basato sul SAFER+7 per autenticare i dispositivi
e generare la chiave simmetrica di comunicazione. La generazione della chiave è
4
5
6
7
Http://www.bluetooth.org
Spread Spectrum Signals for Digital Communications, Proakis
I moderni sistemi operativi, tenenbaum
http://en.wikipedia.org/wiki/SAFER
25
Capitolo 2
basata sul PIN , codice che deve essere inserito in entrambi i telefoni prima di
avviare la comunicazione. Durante questo meccanisco di pairing, viene generata
la master Key usata per la comunicazione simmetrica.
Dallo standard 2.1 la sicurezza è garantita anche laddove in precedenza vi
erano evidenti lacune (es. un attacco XOR portanto per un sufficente periodo di
tempo poteva facilmente trovare la chiave in quanto la validità della stessa è
limitata nel tempo.)
Una caratteristica fondamentale dello stack Bluetooth sono i profili: per usare la
tecnologia Bluetooth infatti, un dispositivo, deve essere in grado di interpretare
correttamente specifici profili Bluetooth. Questi sono definizioni di possibili
applicazioni e specifici comportamenti che il dispositivo usa per comunicare con
gli altri dispositivi Bluetooth.
L'aderenza a determinati profili permette di risparmiare tempo per trasmettere i
parametri della comunicazione ed aiutano gli sviluppatori di applicazioni che
fanno uso di dispositivi Bluetooth a lavorare con standard già definiti e
circoscritti.
I profili sono definiti nel livello application dello stack Bluetooth mentre i layer
PHY e MAC sono standardizzati nell' IEEE 802.15, che si pone l'obbiettivo di
definire uno standard per le reti PAN .
26
Capitolo 2
Figura 2.7 : Bluetooth stack
L'utilizzo dei profili permette di definire una lista dettagliata delle applicazioni
per cui sono impiegati i dispositivi Bluetooth; vediamo in breve le più
importanti:
•
Utilizzo di un auricolare Bluetooth collegato ad un telefono per gestire la
comunicazione GSM (HFP)
•
Controllo e comunicazione wireless di un cellulare attraverso un
Bluetooth car stero system
•
Streaming dell'audio da un dispositivo BT-Compliant ad un auricolare
Bluetooth (AD2P)
•
Comunicazione di rete wireless tra PC in uno spazio ristretto.
•
E molti altri...
Il primo profilo, in particolare, è sicuramente adatto all'utilizzo nel dispositivo
oggetto di ricerca. HFP, Hands Free Profile, espone tutte le primitive necessarie
per controllare e gestire la chiamata sulla rete GSM-Voce, e garantisce grazie agli
27
Capitolo 2
standard Bluetooth sicurezza ed affidabilità.
28
Capitolo 2
2.2.1 Bluetooth Hands Free Profile
E' interessante ai fini della ricerca, vedere più in dettaglio il
funzionamento del profilo HFP, quali funzioni espone e quali garanzie ci porta.
Il profilo HFP, nelle sue specifiche 1.6, definisce il set minimo di funzioni affinchè
un telefono cellulare possa essere usato insieme ad un dispositivo hands-free
attraverso un collegamento Bluetooth che fornisce gli strumenti sia per il
controllo del cellulare che per la gestione della connessione vocale tra i due
dispositivi. Questo prevede infatti un collegamento full-duplex tra il dispositivo
ed il telefono, con il supporto ai comandi basilari AT Commands GSM 07.07 .
L'utilizzo tipico di una configurazione HFP è mostrato dalla seguente
figura:
Figura 2.8: Scenario di utilizzo tipico dell'HFP
I seguenti ruoli sono definiti in questo profilo:
•
Audio Gateway (AG) – il dispositivo che funge da audio gateway sia per
l'input che per l'output (es. Celullare)
•
Hands-Free unit (HF) – il dispositovo che funge da input ed output audio
remoto e da meccanismo remoto di controllo dell'audio gateway.
Possiamo vedere in figura 2.9 i layer dello stack Bluetooth da cui il profilo HFP
29
Capitolo 2
dipende.
Figura 2.9: Dipendenze del profilo HFP
Come indicato nella figura, il profilo HFP utilizza gli AT-Commands esposti dal
Serial Port Profile8 che integra tutte le funzioni di una porta seriale.
Gli AT-Commands (o Hayes command set) sono
uno specifico insieme di
comandi sviluppato originariamente per il modem “Hayes Smartmodem” che,
all'atto pratico, consentono di controllare la comunicazione attraverso delle
primitive per rispondere, chiudere la chiamata, alzare il volume, selezionare
numeri dalla rubrica, ed altro ancora.
In particolare, la seguente figura mostra le entità utilizzate nel profilo in
entrambi i lati.
8 BLUETOOTH SPECIFICATION- Serial Port Profile
30
Capitolo 2
Figura 2.10: HFP protocol stack, entità utilizzate in entrambi i dispositivi
I livelli Baseband, LMP, L2CAP fanno parte dell'OSI layer 1 e 29, RFCOMM è
l'entitià di emulazione della porta seriale Bluetooth. SDP implementa il Service
Discovery Protocol10.
L' Audio Port Emulation layer è l'entità preposta all'emulazione audio nel
gateway (il telefono cellulare); l'audio driver è invece il driver software nell'unità
hands-free (l'auricolare).
Entrambi gli stack si basano sulle funzionalità comuni esposte dal Serial Port
Profile.
Il profilo gestisce un audio mono, fornendo al telefono attraverso il layer
SCO11 (Synchronous Connection Oriented) il segnale audio PCM al GSM
Baseband processor che poi si occuperà di covertirlo ed inviarlo attraverso la
rete.
A livello di progetto, l'utilizzo di tale tecnologia non comporta quindi ulteriori
9 http://en.wikipedia.org/wiki/OSI_model
10 BLUETOOTH SPECIFICATION- Service Discovery Protocol
11 BLUETOOTH SPECIFICATION- Synchronous Connection Oriented Protocol
31
Capitolo 2
problematiche implementative in quanto il link Bluetooth può essere
considerato come un collegamento diretto, senza perdite e totalmente
trasparente lato telefono [Figura 2.11].
INPUT
SPEECH
BT
ADC
Audio Converter
PCM Audio
Stream
GSM Codec
Compression
PCM Audio
From Bluetooth
Device
Device
GSM
Figura 2.11: Il flusso audio non subisce modifica durante il collegamento Bluetooth
32
Capitolo 2
2.3 Crittografia
I classici voice scramblers offrono una minima sicurezza contro ogni
attacco aggressivo.
I classici metodi di scrambling sono:
•
Time Domain Scrambling : manipolazione di blocchi di tempo delimitati
del segnale trasmesso con un ritardo della trasmissione proporzionale
alla dimensione del blocco.
•
Frequency Domanin Scrambling: inversione delle alte e basse frequenze
senza alterare le caratteristiche della voce
Entrambe le tecniche possono essere rotte con uno sforzo relativamente basso.
Si è scelto quindi un approccio di tipo digitale, verso la cifratura dei dati,
evitando scrambler analogici di qualsiasi tipo.
Risulta semplice la scelta dell'algoritmo di crittografia visto l'ampio numero di
algoritmi a disposizione. In questo caso, (almeno in questa fase di avvio del
progetto) si è scelto di puntare su di un algoritmo AES (Advanced Encryption
Standard)
12
con chiave di crittografia a 256 bit, che garantisce un alto livello di
sicurezza in quanto non presenta, ad oggi, vulnerabilità intrinseche
nell'algoritmo.
La scelta di una crittografia digitale però, comporta una doppia
conversione del segnale come mostranto in figura:
12 http://www.aes.org/standards/
33
Capitolo 2
DEVICE A
A/D
Conversion
INPUT
SPEECH
1011000...
Data
Encryption
11001...
Modulation
+
D/A Conversion
GSM
Figura 2.12 : conversione Analogico/Digitale in ingresso ed in uscita
Questo complica inevitabilmente lo sviluppo del progetto, introducendo
necessità di politiche di key-agreement, di codifica della voce in entrata e di
modulazione del segnale digitale in uscita verso il telefono. Sono queste
problematiche
che
in
parte
abbiamo
affrontato
e
approfondiremo
successivamente.
34
Capitolo 2
2.3.1 Scambio di chiavi ed autenticazione
Lo studio di un sistema di autenticazione e di un algoritmo di scambio di
chiavi efficace per instaurare una comunicazione criptata e fluida tra i due
dispositivi è sicuramente un argomento che presuppone che i precedenti step, in
particolare la corretta ricezione dei dati attraverso il canale GSM-Voce, siano già
ampiamente sviluppati e collaudati con risultati positivi. Risulta quindi evidente
che questo sottoinsieme del progetto di ricerca non possa essere approfondito e
discusso in maniera adeguata a questo livello di sviluppo.
Mostriamo comunque qui di seguito l'algoritmo di scambio delle chiavi che si
pensa di poter utilizzare, ovvero il Diffie-Hellmann.
Lo scambio di chiavi Diffie-Hellman è un protocollo crittografico che
consente a due entità di stabilire una chiave condivisa e segreta utilizzando un
canale di comunicazione insicuro (pubblico) senza la necessità che le due parti si
siano scambiate informazioni o si siano incontrate in precedenza. La chiave
ottenuta mediante questo protocollo può essere successivamente impiegata per
criptare le comunicazioni successive tramite uno schema di crittografia
simmetrica.
35
Capitolo 2
Figura 2.13 : Algoritmo per lo scambio di chiavi Diffie Hellman
Nell'implementazione originale
del protocollo si considera inizialmente un
numero g, generatore del gruppo moltiplicativo degli interi modulo p, dove p è
un numero primo. Uno dei due interlocutori, ad esempio Alice, sceglie un
numero casuale a e calcola il valore A = ga mod p (dove mod indica l'operazione
modulo, ovvero il resto della divisione intera) e lo invia attraverso il canale
pubblico a Bob (l'altro interlocutore), assieme ai valori g e p. Bob da parte sua
sceglie un numero casuale b, calcola B = gb mod p e lo invia ad Alice. A questo
a
punto Alice calcola KA = B mod p, mentre Bob calcola KB = Ab mod p.
a
I valori calcolati sono gli stessi, in quanto B = gba e Ab = gab .
A questo punto i due interlocutori sono entrambi in possesso della chiave
segreta e possono cominciare ad usarla per cifrare le comunicazioni successive.
Un attaccante può benissimo ascoltare tutto lo scambio, ma per calcolare i valori
a e b avrebbe bisogno di risolvere l'operazione del logaritmo discreto, che è
computazionalmente onerosa e richiede parecchio tempo (sicuramente molto
36
Capitolo 2
più del tempo di conversazione tra i 2 interlocutori).
Per migliorare l'affidabilità dell'algoritmo Diffie Hellman è necessario scegliere
accuratamente
il
numero
casuale
privato,
ed
è
importante
inoltre
l'autenticazione delle due parti che vogliono comunicare.
Questi argomenti non saranno approfonditi in questo trattato.
37
Capitolo 2
2.4 Modulazione digitale
Con il termine di modulazione digitale (o numerica) si indica una tecnica
di modulazione utilizzata nelle trasmissioni digitali da un particolare
sottosistema di modulazione/demodulazione in cui il segnale modulante
rappresenta un'informazione in formato binario, cioè tale da assumere solo due
possibili valori (esempio 0 o 1, -1 o +1) o una stringa di questi.
I principi della modulazione numerica sono diversi da quelli della
modulazione analogica anche se i risultati sono simili: di fatto questo tipo di
modulazione realizza una conversione dati da digitale ad analogico per la
trasmissione sul canale. Tale conversione è ottenuta, in prima approssimazione,
attraverso una mappatura biunivoca tra sequenze di bit in ingresso al
modulatore numerico (segnale modulante) e un insieme di forme d'onda
analogiche di energia (segnale portante), scelte secondo opportuni criteri, in
uscita sul canale dette simboli e che definiscono il cosiddetto alfabeto di simboli.
La cardinalità dell'alfabeto, cioè il numero totale di simboli o forme d'onda,
dipende dal numero di bit trasmessi in una sequenza o periodo di simbolo
,ovvero dalla lunghezza L di questa: sono cioè possibili 2^L sequenze di bit e
quindi M=2^L forme d'onda o simboli per codificarle in analogico.
Figura 2.14 : esempio di modulazione numerica
38
Capitolo 2
In trasmissione sul canale si avrà quindi una concatenazione o sequenza di
simboli cioè di forme d'onda analogiche trasmesse con tempo di simbolo pari a
Ts ovvero una banda approssimativamente pari a 1/Ts, tasso di emissione dei
simboli (symbol rate) pari a 1/Ts e dunque tasso complessivo di emissione di bit
(bit-rate) pari a L*1/Ts.
In ricezione il demodulatore/decisore opererà come al solito in maniera inversa:
dopo un'operazione di decisione in cui dal simbolo ricevuto (che è affetto da
errore in virtù della presenza di rumore additivo di tipo aleatorio sul canale)
deciderà quale simbolo dell'alfabeto è stato trasmesso attraverso criteri di
decisione specifici partire dalla forma d'onda analogica decodificata verrà
ripristinata l'originaria sequenza di bit tramite un mappaggio inverso. A generare
potenziali errori in ricezione concorre anche il fenomeno dell'interferenza
intersimbolica.
I principali tipi di modulazione digitale sono:
•
Amplitude-shift keying (ASK): modulazione digitale di ampiezza;
•
Frequency-shift keying (FSK): modulazione digitale di frequenza;
•
Phase-shift keying (PSK): modulazione digitale di fase.
39
Capitolo 2
2.4.1 Amplitude-shift Keying
L'Amplitude-shift keying è un metodo di modulazione che rappresenta i
dati digitali come variazione in ampiezza dell'onda portante. Ogni schema di
modulazione usa un numero finito di segnali distinti per rappresentare il dato
digitale. L'ASK usa un numero finito di ampiezze , ognuna assegnata ad un
pattern unico di bits. Solitamente ogni ampiezza codifica un ugual numero di
bits. Ogni pattern definisce un simbolo che è rappresentato da una particolare
ampiezza. Il demodulatore, che è sviluppato specificatamente sopra il set di
simboli specificato nel modulatore, effettua un re-mapping nell'alfabeto dei
simboli valutando l'ampiezza del segnale ricevuto. Frequenza e fase del segnale
modulato sono mantenute costanti.
Figura 2.15: Modulazione ASK
Questo tipo di modulazione è particolarmente sensibile al rumore atmosferico,
alle distorsioni, ed a specifiche condizioni di propagazione. Un aspetto positivo è
che invece sono tecniche solitamente computazionalmente poco onerose.
Inoltre, si ha che:
40
Capitolo 2
fc >> fm
Ovvero la frequenza del segnale portante fc deve essere molto maggiore del
segnale modulante fm : ciò è necessario per avere una risoluzione adeguata del
segnale modulato. Poichè il segnale modulante è uno stream digitale, possiamo
intuitivamente sovrapporre la nozione di frequenza modulante con quella di bitrate del segnale modulante (supponendo che si sta lavorando con stream
continuo). Questa condizione implica un bit-rate del segnale modulante molto
inferiore alla frequenza del segnale modulato. In questo caso il symbol-rate del
segnale modulato può essere incrementato aumentando i livelli discreti di
ampiezza, ma in questo caso aumenta anche la sovrapposizione dell'errore.
41
Capitolo 2
2.4.2 Frequency-shift keying
Frequenzy-shift keying (FSK) è uno schema di modulazione in frequenza
nel quale le informazioni sono trasmesse attraverso cambiamenti discreti di
frequenza di un segnale portante. La tipologia di modulazione più semplice è
quella binaria (BFSK). BFSK usa una coppia di frequenze discrete per trasmettere
informazioni binarie. Con questo schema, l'uno è chiamato “mark frequency” e
lo 0 è chiamato “space frequency”. Ampiezza e fase del segnale modulato
restano costanti per tutto il tempo.
Figura 2.16: Modulazione FSK
Questo tipo di modulazione è più robusto rispetto alla modulazione in ampiezza
al rumore ed alle distorsioni, anche se computazionalmente più oneroso da
implementare.
Anche in questo caso le frequenze scelte come set di simboli delle portanti
devono essere maggiori a quella del segnale modulante, anche se periodo e
numero di simboli scelti dipendono principalmente dal mezzo trasmissivo e dalla
risoluzione a cui il demodulatore può lavorare.
42
Capitolo 2
Solitamente Inoltre :
f1 > fm
la mark frequency f1 viene scelta maggiore rispetto a quella del segnale
modulante (con le altre frequenze scelte in accordo). Anche in questo caso
sostituendo il concetto di frequenza del segnale modulante con quella di bit-rate
in ingresso del segnale digitale, risulta ovvio che si avrà un bit-rate gestibile del
segnale modulante inferiore alla frequenza della portante. In questo caso però
l'utilizzo di diverse frequenze può sopperire all'eventualmente basso symbolrate poiché questo tipo di modulazione è meno soggetta a disturbi e distorsioni.
43
Capitolo 2
2.4.3 Phase Shift Keying
Questo tipo di modulazione, trasmette i dati digitali modificando la fase
della portante. Ogni schema di modulazione digitale usa un numero finito di
segnali distinti per rappresentare il dato digitale. PSK usa un numero finito di fasi
ognuna assegnata ad uno specifico pattern di bit. Solitamente ogni fase codifica
uno stesso numero di bit. E come in precedenza ogni pattern rappresenta un
simbolo caratterizzato da una particolare fase. Il demodulatore, anche qui
sviluppato specificatamente per un particolare symbol-set definito dal
modulatore, determinando lafase del segnale ricevuto mappa il simbolo che
rappresenta in uno specifico pattern di bit.
Una corretta demodulazione implica che il ricevitore sia capace di comparare la
fase del segnale ricevuto a quella di un segnale di riferimento.
Figura 2.17: Modulazione PSK
In questo caso ampiezza e frequenza del segnale portante sono mantenute
costanti e solitamente richiede apparati riceventi più onerosi rispetto alle altre
due modulazioni per ricevere e demodulare correttamente il segnale. La
44
Capitolo 2
demodulazione si complica ulteriormente se vengono sovrapposti disturbi a
frequenza simile a quella della portante.
45
Capitolo 3
Le soluzioni attualmente presenti nel mercato
3. Le soluzioni attualmente presenti nel mercato
3.1 La situazione attuale
Lo scenario attuale di mercato, per la comunicazione criptata su rete
cellulare, si divide in due macro categorie:
•
Criptofonini
•
Dispositivi esterni
La prima soluzione, quella dei criptofonini, consiste in un telefono cellulare, al
cui interno sono integrati i meccanismi di cifratura ed autenticazione dele
utenze.
La seconda invece, è quella in cui rientra il nostro caso di studio, con però una
differenza sostanziale: attualmente i dispositivi in vendita sfruttano tutti la
connessione GSM-Dati, al posto della linea voce. E questo, come abbiamo visto
nel primo capitolo, può comportare problemi di interoperabilità tra le reti
46
Capitolo 3
internazionali oltre che un tempo superiore di instradamento della chiamata.
Questa implementazione d'altronde, è stata la prima a raggiungere il mercato
anche grazie al fatto che appoggiandosi alla classica rete dati, è possibile il
riutilizzo di tecnologie e di una letteratura già approfondita da tempo (cosa
impossibile nel nostro caso). Il funzionamento di questo tipo di dispositivi si può
accomunare ad applicazioni che permettono di telefonare tramite internet (es.
Skype).
Vediamo ora un esempio di un tale dispositivo.
47
Capitolo 3
3.2 Un esempio: TopSec Mobile
L'oggetto in questione, prodotto dalla Rohde & Schwarz, ha delle
caratteristiche
di
funzionamento
del
tutto
simili
alle
nostre,
come
precedentemente accennato.
Figura 3.1: TopSec Mobile
Dalla documentazione reperibile online, è interessante evidenziare le seguenti
caratteristiche principali:
•
Algoritmo di cifraggio AES-256bit Hardware
•
Connessione Bluetooth 2.0 tra il dispositivo ed il telefono
•
Sistema di autenticazione: Diffie-Hellman key agreement protocol
•
Utilizzo della connessione dati GSM-CSD a 9.6Kbps ( circuit switched data:
connessione continua e timeslot riservati ) con i protocolli ITU-T V.110 o
V.32 per la comunicazione e l'handshake di sicurezza tra i due dispositivi.
48
Capitolo 3
Figura 3.2: Il dispositvo della
Rohde & Schwarz
Per iniziare una chiamata deve essere selezionato un numero telefonico
nella rubrica del dispositivo (inserito in precedenza). Fatto ciò l'utente deve
aspettare che l'handshake con il dispositivo destinatario sia terminato (indicato
da delle icone in movimento sul display); quando i due dispositivi sono
accoppiati sul display appare un codice di sicurezza a 4 cifre e la comunicazione
puo' iniziare.
Quando si riceve una chiamata il funzionamento è speculare.
Più specificatamente:
•
Quando viene selezionato un numero dalla rubrica il dispositivo A, che
deve comunicare con B, avvia una connessione dati (GSM-CSD) codificata
con il protocollo ITU-T V.110 o V.32.
•
Tramite il Diffie-Hellman key agreement protocol viene generata una
chiave simmetrica K (valida solo per la chiamata attuale) a partire da due
49
Capitolo 3
numeri P e G presenti in ogni gruppo di dispositivi che vogliono
comunicare: questi due valori sono inseriti al momento della costruzione
del dispositivo e non possono essere letti in alcun modo.
•
Una volta che l'handshake è completato, su entrambi i display dei
dispositivi comunicanti, appare un codice di 4 cifre che altro non è che
l'hash della chiave K.
•
La comunicazione viene criptata con la chiave simmetrica K che viene
distrutta al termine.
50
Capitolo 3
3.2.1 Autenticazione
I dispositivi TopSec Mobile si affidano ad un approccio ibrido per la
crittografia che combina algoritmi asimmetrici per lo scambio chiavi ed
autenticazione ad algoritmi simmetrici per la cifratura delle informazioni.
Lo scambio chiavi è effettuato tramite l'algoritmo Diffie Hellman già dettagliato
in precedenza [Figura 3.3].
Figura 3.3: Implementazione del Diffie Hellman
Come accennato in precedenza, l'algoritmo Diffie Hellman potrebbe essere
suscettibile ad attacchi di tipo man-in-the-middle. Questi attacchi, comunque,
implicano importanti sforzi e richiedono, per esempio, che l'attaccante abbia
accesso al link di comunicazione tra i due device partner. Per ovviare a questo
problema viene utilizzato un ulteriore sistema di certificazione: viene generato
un hash-code a 4 cifre a partire dalla chiave simmetrica privata. Questo codice
51
Capitolo 3
sarà identico in entrambi i device solo se, presumibilmente, non è presente
nessun malintenzionato nel mezzo. Questo perchè, nel caso di un attacco manin-the-middle, i due device comunicano con l'entità intrusa, generando due
chiavi K1 e K2 differenti tra loro. Il codice di hash a 4 cifre di due chiavi differenti
sarà anch'esso differente e permetterà di controllare che non ci siano problemi
di affidabilità.
Un ulteriore misura implementata per evitare attacchi di questo tipo, è la
creazione si sistemi crittografici protetti, ovvero un gruppo di utenze con un
numero ristretto e ben definito di partecipanti. Questo necessita di un'entità di
certificazione centralizzata ed esterna: relativamente a questo prodotto della
Rohde & Schwarz, il ruolo è assunto da un dispositivo “TopSec Administrator”.
Tutti i dispositivi TopSec che appartengono ad un gruppo, ricevono un certificato
dall'amministratore che li identifica come membri di un sistema chiuso.
L'informazione più importante che contiene il certificato è l'ID del dispositivo e
la sua chiave di autenticazione pubblica associata [figura sottostante].
52
Capitolo 3
Figura 3.4: verifica del certificato
Il certificato contiene inoltre una firma digitale. Per creare una firma digitale,
l'amministratore genera una coppia di chiavi, una pubblica ed una privata. La
chiave privata STC è usata per aggiungere la firma digitale al valore di hash del
certificato. STC rimane nel dispositivo amministratore: è la componente più
confidenziale in un sistema chiuso. La firma digitale ed il certificato possono
essere autenticati attraverso la chiave pubblica PTC .
Durante il processo di inizializzazione, i dispositivi TopSec che appartengono ad
un sistema chiuso generano un ulteriore coppia di chiavi usata per
l'autenticazione. La chiave di autenticazione privata S-1U rimane nel device
53
Capitolo 3
TopSec. La chiave di autenticazione pubblica PU è parte del certificato. Oltre al
certificato stesso, i dispositivi ricevono la chiave pubblica Ptc per verificare i
certificati.
I dispositivi che sono membri di un gruppo chiuso possono ricevere
aggiornamenti di certificati e chiavi pubbliche associate “over-the-air”.
Inoltre i dispositivi che appartengono allo stesso sistema possono
automaticamente autenticare gli altri.
Come primo passo viene verificato il certificato del dispositivo “partner”. A
questo fa seguito un algoritmo combinato di scambio chiavi e autenticazione
[Figura 3.5]
Figura 3.5: Algoritmo combinato di scambio chiavi ed autenticazione
Sarà quindi stabilita una connessione cifrata solo se la procedura ha avuto
successo.I due partner possono inoltre autenticarsi a vicenda usando il codice di
54
Capitolo 3
sicurezza a 4 cifre.
Se uno di questi dispositivi viene perso sono state adottate alcune misure
per prevenire l'utilizzo non autorizzato.
In questo caso il dispositivo smarrito viene inserito in una black-list dal TopSec
Administrator. La lista viene inviata agli altri dispositivi dello stesso gruppo
attraverso un canale di comunicazione sicuro. All'atto dell'autenticazione il
dispositivo controlla se il partner è presente o meno nella black list e, se così
fosse, chiude la comunicazione.
55
Capitolo 3
3.2.2 Osservazioni
L'analisi di questo dispositivo ci offre sicuramente degli spunti interessanti
per quanto riguarda i sistemi di autenticazione adottati ed un eventuale riutilizzo delle tecnologie.
In primo luogo, il protocollo di scambio chiavi è lo stesso che si era ipotizzato
inizialmente nell'ambito del progetto di ricerca. A questo protocollo è stato
aggiunto un, prevedibile, sistema si certificazione fondamentale nel caso si
voglia garantire la sicurezza delle utenze sopratutto in scenari mission-critical
come possono essere quelli militari o di spionaggio industriale.
Una differenza sostanziale è l'utilizzo della linea dati della rete GSM-CSD, a
commutazione di circuito, che differisce dalla classica rete a commutazione di
pacchetto (es. GPRS, internet) , ma semplifica, rispetto alla linea voce, tutte le
operazioni di formattazione ed invio dello stream audio digitale criptato, in
quanto è “sufficiente” renderlo conforme agli standard ITU-T ed inviarlo al
modem GSM.
Nel nostro caso invece, come accennato in precedenza, la differenza sostanziale
sta nel fatto che non abbiamo a disposizione la linea dati, ma la linea voce la
quale riceve uno stream analogico grezzo, senza standard che ci aiutano a
gestire la sincronia o la comunicazione tra i dispositivi.
Un ulteriore similitudine col nostro progetto sta nella connessione di
interfaccia al telefono: in entrambi i casi si è puntato sull'utilizzo dell' Hands Free
Profile Bluetooth che si rivela una scelta obbligata in questo contesto.
In conclusione l'analisi di questo dispositivo ( preso come esempio visto
che sul mercato ce ne sono altri del tutto simili) permette di sottolineare sia gli
56
Capitolo 3
aspetti del progetto sui cui è già presente una buona letteratura, sia aspetti che
ad ora non sono stati affrontati o sviluppati.
57
Capitolo 4
Il lavoro svolto
4. Il lavoro svolto
A partire dalle problematiche e dall'environment tecnologico in cui il
progetto si pone, in questo capitolo verranno descritte le scelte effettuate ed
alcune soluzioni utilizzate per aggirare i principali problemi che abbiamo
incontrato durante il dettaglio dell'intero processo.
DEVICE A
Speech
Encoder
INPUT
SPEECH
1011000...
Data
Encryption
1101001...
Data
Modulation
GSM
DEVICE B
Data
Demodulation
1101001...
Data
Decryption
1011000...
Speech
Decoder
OUTPUT
SPEECH
Figura 4.1: processo di comunicazione tra i due dispositivi
58
Capitolo 4
Il lavoro svolto
4.1 Tutela del segreto aziendale
Le scelte effettuate e le soluzione che verranno prospettate, a cui si
accennava in precedenza, saranno riportate senza approfondimenti tecnici
specifici in questi e nei prossimi capitoli. Questo in quanto le soluzioni sviluppate
rispetto ai problemi elencati nei capitoli predenti non possono essere
completamente dettagliate in questa sede al fine di mantenere il riserbo
necessario per tutelare il segreto aziendale
59
Capitolo 4
Il lavoro svolto
4.2 La codifica della voce
Nel prototipo realizzato (dettagliato nel capitolo successivo) si è
implementato un algoritmo di codifica della voce che permette di ottenere un
buona qualità ad un bit-rate relativamente basso.
60
Capitolo 4
Il lavoro svolto
4.3 Cifratura ed Autenticazione
Per quanto riguarda la cifratura si è utilizzato lo standard AES-256
accennato in precedenza con il quale è stata cifrato lo stream digitale
contenente la voce in chiaro. Questo è stato suddiviso in pacchetti di
dimensione fissa e viene cifrato ogni pacchetto.
Per il momento, e per i motivi accennati nel capitolo 2.3.1, non sono state
implementate politiche di autenticazione e scambio di chiavi nel prototipo
realizzato.
61
Capitolo 4
Il lavoro svolto
4.4 Comunicazione tra il prototipo ed il cellulare
L'obbiettivo finale del progetto sarà quello di avere il nostro dispositivo
che si interfaccia con il telefono via Bluetooth. All'atto dello sviluppo però
abbiamo due possibilità:
•
Utilizzare una connessione analogica diretta (un cavo jack da 3.5mm tra il
prototipo ed il telefono)
•
Utilizzare una connessione Bluetooth.
Abbiamo visto che dal punto di vista teorico della manipolazione del segnale,
entrambe le alternative non comportano problematiche particolari.
Per quanto riguarda la scelta realativamente alla piattaforma di sviluppo
rimandiamo al prossimo capitolo.
62
Capitolo 4
Il lavoro svolto
4.5 Modulazione e demodulazione
Per quanto visto in precedenza, emerge chiaramente la necessità di
convertire lo stream digitale criptato in un segnale analogico che abbia le
caratteristiche fondamentali viste nel capitolo 2.1:
DEVICE A
INPUT
SPEECH
Speech
Encoder
1011000...
ADC
Audio Converter
Data
Encryption
1101001...
PCM Audio
Stream
Data
Modulation
GSM Codec
Compression
PCM Audio
From Bluetooth
Device
GSM
Figura 4.2 : Rappresentazione di tutti i passaggi A/D del segnale vocale
Un attento reverse engineering dei processi che compongono la codifica AMR
infatti è fondamentale affinché il dato che vogliamo inviare passi il più possibile
inalterato attraverso il processo di compressione ed invio sulla rete GSM-Voce.
Ecco quindi la necessità di generare un segnale analogico modulato con alcune
specifiche caratteristiche affinchè possa essere ricevuto correttamente
attraverso la rete.
63
Capitolo 4
Il lavoro svolto
La necessità di questo passaggio è indipendente dall'utilizzo o meno di una
connessione Bluetooth: come abbiamo visto infatti sia che il segnale analogico
modulato venga campionato dall'encoder GSM o dal protocollo di comunizione
Bluetooth, si otterrà uno stesso segnale risultante (o con differenze trascurabili).
Questa fase dello sviluppo è sicuramente il nocciolo del progetto: una corretta
modulazione del segnale pone le basi per una compressione senza perdite di
informazione permettendo quindi di ottenere un canale comunicazione
sufficientemente solido sopra il GSM-Voce.
Nello sviluppo del prototipo è stata questa una fase cruciale, molte soluzioni
sono state provate, e infine, la soluzione migliore è risultata essere una
modulazione basata su di un set di simboli che differiscono in frequenza
secondo determinati criteri e pattern, che per i motivi di riservatezza
precedentemente accennati non saranno specificati in questa sede.
Per quanto riguarda la modulazione in ampiezza, questa non è stata adottata per
molteplici motivi:
•
Come evidenziato nel capitolo 2, la modulazione in ampiezza è
sicuramente la meno adatta per quanto riguarda i disturbi e le
interferenze che sovrapponendosi rendono inservibile , al ricevitore, il
segnale.
•
A causa delle caratteristiche del coder ACELP, il guadagno viene
normalizzato così come la potenza media che viene mantenuta costante,
motivo questo che rende completamente inefficace la modulazione in
ampiezza.
•
Un ulteriore motivo per cui la modulazione in ampiezza non è stata
impiegata è data dal basso symbol-rate garantito (vd capitolo 2.4.1).
64
Capitolo 4
Il lavoro svolto
Figura 4.3: Un esempio di come un segnale modulato in ampiezza (sopra)
venga ricevuto completamente normalizzato al destinario (sotto)
Per quanto riguarda invece la modulazione PSK, questa non è stata utilizzata
poiché, sempre a causa del particolare coder ACELP dello standard GSM-AMR
06.90, i cambi repentini del segnale vengono eliminati, rendendo impossibile ,
lato ricevitore, distinguere gli instanti in cui avviene un cambio di fase.
Vedremo nel capitolo successivo i risultati pratici che sono stati raggiunti.
65
Capitolo 5
Il prototipo realizzato: implementazione
5. Il prototipo realizzato: implementazione
L'obbiettivo è quello di costruire una piattaforma di sviluppo e test
composta da 2 PC x86 (in virtù della flessibilità che questa architettura ci
garantisce) su cui sviluppare tutti i blocchi funzionali precedentemente descritti
(encoding, crittografia, ...).
Questi, inoltre, utilizzando un servizio Bluetooth basato sul profilo HFP (in
particolare il servizio di Audio Gateway ) dovranno connettersi a due telefoni
attraverso i quali verrà inviato e ricevuto lo stream vocale criptato nel canale
GSM-Voce.
Il sistema operativo dei due PC è consigliabile essere basato su Gnu/Linux, in
particolare una distribuzione Debian vista l'immediata portabilità su piattaforma
ARM. Allo stesso modo l'utilizzo del servizio di Audio Gateway è il modo più
immediato per utilizzare il PC come un ipotetico auricolare Bluetooth, attraverso
66
Capitolo 5
lo stesso profilo HFP che poi con tutta probabilità sarà utilizzato nel dispositivo
finale.
Il primo passo per stabilire la piattaforma di sviluppo è quello di capire come
interfacciarsi con i telefoni: vediamo a questo proposito la situazione attuale per
lo sviluppo di applicazioni ed utilizzo di servizi Bluetooth.
67
Capitolo 5
5.1 Sviluppo Bluetooth: il punto della situazione
Verrà esposto qui di seguito un breve riassunto delle carettistiche e
possibilità di sviluppo utilizzando le funzioni esposte dallo stack bluetooth su
varie piattaforme.
Windows:
•
Microsoft Bluetooth API. Disponibili da WinXP SP1 in poi.
•
Sviluppo possibile utilizzando le socket o accedendo direttamente
all'hardware
•
Possibilità di sviluppare in C/C++ o anche .NET
Pro: Buona documentazione, Profilo Audio gateway già implementato e
funzionante
Contro: librerie chiuse, impossibile frapporsi tra microfono e applicazione che
gestisce l'audio gateway per crittare lo stream audio (re-implementare tutto),
piattaforma finale linux-based
Linux:
•
Bluez implementa le API per lo sviluppo sotto linux.
•
Sviluppo in C/C++
Pro: Free software, accesso diretto alle librerie di sistema, Controllo
approfondito di tutte le parti dell'hardware
Contro: Documentazione praticamente assente, servizio di audio-gateway non
implementato in maniera nativa, sviluppo più verboso e prolungato rispetto ad
68
Capitolo 5
altri linguaggi (C/C++)
Java (Cross-platform):
•
API JSR-82 rappresentano ambiente di sviluppo ufficiale per il BlueTooth.
Pro: Multipiattaforma, Buona Documentazione
Contro: Fornisce un controllo limitato sull'hardware rispetto alle altre alternative
di sviluppo, prestazioni inferiori
Per le sue caratteristiche e la facile portabilità su architetture ARM, si è deciso di
utilizzare GNU/Linux come S.O. su cui implementare le varie funzionalità del
prototipo.
Vediamo in particolare se è possibile utilizzare il profilo Bluetooth HFP in questo
sistema operativo.
69
Capitolo 5
5.1.1 Gnu/Linux e BlueTooth Hands-Free Profile
Bluez, lo stack Bluetooth free del kernel linux, non ha una propria
implementazione del servizio HSP o dell' Audio Service Gateway Profile: fino al
2010 non vi era possibilità di utilizzare una Linux-box come Gateway Audio, solo
successivamente è stata introdotta questa possibilità attraverso l'introduzione
del supporto in Bluez e tramite l'utilizzo di oFono (www.ofono.org): un tool per
la gestione di modem remoti GSM/CDMA.
Entrando più nel dettaglio, è stato creata una nuova API di Bluez (Appendice A)
che sfrutta la fd-passing feature del DBUS 1.3+ (File-Descriptor passing).
Questa nuova API sfrutta il concetto di Agenti: in questo caso è oFono a giocare
il ruolo di Agente.
Relativamente al servizio HFP il ruolo dell' Agente è quello di gestire gli ATCommands mentre Bluez si occuperà solamente di gestire le connessione
RFCOMM e SCO.
La socket per l'accesso all'RFCOMM è passata all'agente in oFono tramite DBUS:
questa è utilizzata da oFono per mandare e ricevere gli AT-Commands per
stabilire una Service Level Connection (ad esempio completare la procedura di
handshake). Se la procedura ha successo, sarà possibile effettuare e rispondere
alle chiamate tramite oFono: il telefono sarà visto come un qualsiasi altro
modem gestito da oFono.
70
Capitolo 5
5.1.2 Configurazione e Test
-Installazione pacchetti
Per configurare un sistema Gnu/Linux a questo scopo è necessario avere
installato:
1-Pulseaudio 0.9.2+
2-DBus 1.3+
3-oFono 0.27+
4-Blueman (o tool equivalente)
-Configurare Bluez
E' necessario abilitare la modalità gateway in Bluez, per fare questo è sufficente
editare il file:
sudo nano /etc/bluetooth/audio.conf
inserendo nella sezione [General]:
Enable=Gateway
-Accoppiare i Dispositivi
Assicurarsi di avere accoppiato ed autorizzato il telefono al pc tramite blueman.
-Stabilire la connessione
Utilizzare lo script list-modems presente nella release di oFono per elencare i
dispositivi bluetooth accoppiati con il pc:
./list-modems
[ /hfp/000272AF710E_9BBEADE9E9D9 ]
Name = LG-P990
Powered = 0
Lockdown = 0
Interfaces =
Online = 0
71
Capitolo 5
Features =
Successivamente è necessario abilitare e collegarsi al modem del relativo
telefono sempre attraverso un script in python di oFono:
./enable-modem
Connecting modem /hfp/000272AF710E_9BBEADE9E9D9...
-Configurare un Loopback Audio tramite Pulseaudio:
Prima di effettuare la chiamata, è necessario instaurare un loopback audio tra i
moduli bluetooh ed alsa affinchè sia possibile ascoltare le chiamata negli
speaker e parlare attraverso il microfono del pc.
Innanzitutto bisogna trovare i device che espongono le funzionalità di Source e
Sink audio:
pacmd list-sources
pacmd list-sink
l'output di questi due comandi ci fornirà gli ID dei device di Source e Sink Audio
da collegare in loopback; saranno del tipo:
bluez_source.00_02_42_4F_71_01
alsa_output.pci-0000_00_1b.0.analog-stereo
bluez_sink.00_02_42_4F_71_01
alsa_input.pci-0000_00_1b.0.analog-stereo
Effettuiamo il loopback tramite modules-loopback:
pactl load-module module-loopback sink=alsa_output.pci0000_00_1b.0.analog-stereo source=bluez_source.00_02_72_AF_71_0E &&
pactl load-module module-loopback source=alsa_input.pci0000_00_1b.0.analog-stereo sink=bluez_sink.00_02_72_AF_71_0E
-Instradiamo la chiamata
Utilizzando un ulteriore python script di oFono, effettuiamo la chiamata di test :
72
Capitolo 5
./dial-number [number-to-dial]
Se tutto è andato per il verso giusto, saremmo in grado di utilizzare il nostro pc
alla stregua di un auricolare bluetooth.
Dai test effettuati emerge in maniera evidente che lo stato di questo supporto è
ancora embrionale e presenta alcune problematiche.
La chiamata infatti viene instradata correttamente, il telefono rileva il pc come
fosse un auricolare Bluetooth ma non si riesce nè a sentire nè ad inviare alcuno
stream audio: la soluzione per questo problema è nota (basterebbe instaurare
un loopback audio specifico) ed in teoria, risolvibile anche se da approfondire.
73
Capitolo 5
5.2 La piattaforma di sviluppo
La piattaforma di sviluppo del prototipo, utile come proof-of-concept
delle soluzioni prospettate sino ad ora, è stata creata effettuando alcune
semplificazioni iniziali che permettono di concentrarsi unicamente sui moduli
che costituiscono il core del progetto di ricerca:
HALF DUPLEX COMMUNICATION
PC1 - SENDER
INPUT
SPEECH
LINE IN
1011000...
Speech
Encoder
Data
Encryption
1101001...
Data
Modulation
MIC IN
AUDIO OUT
3,5mm jack
GSM
PC2 - RECEIVER
LINE IN
HEADPHONES OUT
Data
Demodulation
1101001...
Data
Decryption
1011000...
Speech
Decoder
AUDIO OUT
OUTPUT
SPEECH
3,5mm jack
Figura 5.1: ambiente di test
•
Utilizzo di due PC che attuano una comunicazione Half-duplex che
permetta di testare direttamente la codifica - decodifica del segnale
cifrato senza preoccuparci inizialmente delle politiche di autenticazione,
sincronizzazione della comunicazione, e di altri aspetti che verrano
valutati solo in seguito nello sviluppo del progetto.
74
Capitolo 5
•
Sviluppo di tutti i blocchi funzionali evidenziati in figura via software. In
particolare è scelto il C++ come linguaggio di programmazione vista la
quantità di librerie e di documentazione presente.
•
Entrambe sono macchine Gnu/linux che garantiscono una più semplice
portabilità del codice nel dispositivo finale Avere un buon esisto con
questa piattaforma di test significa, a mio avviso, aver già completato la
gran parte del progetto.
•
Per quanto detto nel paragrafo precedente, si è preferito evitare di
utilizzare la connessione Bluetooth tra i pc ed i telefoni, in favore di di due
cavi adattatori jack da 3.5mm. Questa scelta, come spiegato, non
comporta alcun tipo di modifica nello sviluppo delle altre componenti.
75
Capitolo 5
5.3 L'implementazione software sviluppata
Il software sviluppato implementa le funzionalità precedentemente
descritte in maggiore dettaglio nel capitolo 4, con le ipotesi di semplificazione
stilate all'atto della definizione della piattaforma di sviluppo.
Figura 5.2: Interfaccia del software sviluppato
Nello specifico [figura 5.2] il testing del prototipo è molto semplice da attuare. In
entrambi i PC è presente una copia del software sviluppato, che implementa le
funzionalità sia del mittente che del ricevitore.
Come si può facilmente intuire dalla figura precedente, molto
banalmente ogni tasto rappresenta una funzione implementata nel mittente o
nel ricevitore, in particolare:
76
Capitolo 5
Lato mittente:
• Record: viene registrato attraverso il codec low-rate descritto nel capitolo
4.2 un file audio raw contente una frase di test.
• Encrypt: prendendo l'audio appena registrato in input viene suddiviso in
pacchetti ed ogni singolo pacchetto viene criptato in AES-256. La chiave
attualmente utilizzata nella cifratura viene mostrata nella linea di testo in
alto e generata in maniera random ad ogni avvio dell'applicazione. E'
inoltre possibile impostare tramite il tasto “SET” una chiave a propria
scelta.
• Modulate: prendendo il file audio suddiviso in pacchetti e criptato, viene
modulato secondo le specifiche descritte nel capitolo 4.5 e ripodotto
nella linea audio-out del pc mittente.
• Add Sync Header: prima della modulazione, è possibile (e consigliabile)
aggiungere un header di sincronia: questo permette al PC simulante il
dispositivo ricevente di capire dove inizia in maniera più precisa il dato da
demodulare.
• One Click Sender Test: tutte queste operazioni possono essere eseguite
atomicamente o in sequenza in maniera automatica utilizzando questa
funzione.
Il segnale modulato, in uscita dal PC mittente, verrà così inviato dal telefono
connesso alla sua uscita audio verso la rete GSM passando attraverso il codec di
compressione GSM-AMR. Il telefono in ascolto, con il quale era stata
precedentemente avviata una chiamata, attraverso l'audio out dello stesso
invierà il segnale ricevuto dalla rete GSM al PC ricevente tramite l'ingresso linea.
77
Capitolo 5
Nel pc ricevente, allo stesso modo, sono state implementate le seguenti
funzionalità:
• Record: il segnale in uscita dal telefono viene registrato stavolta con un
codec ad elevata qualità per cercare di ottimizzare il processo di
demodulazione.
• Remove Sync Header: prima della demodulazione, è necessario
sincronizzare il segnale registrato al fine di capire in maniera più precisa
dove inizia il dato da demodulare.
• Demodulate: prendendo il file audio così registrato e sincronizzato viene
demodulato secondo le specifiche descritte nel capitolo 4.5.
• Decrypt: prendendo lo stream digitale appena demodulato, questo viene
suddiviso in pacchetti ed ogni singolo pacchetto viene decriptato in AES256 settando manualmente la chiave simmetrica generata dal mittente.
• One Click Receiver Test: tutte queste operazioni possono essere eseguite
atomicamente o in sequenza in maniera automatica utilizzando questa
funzione.
Vediamo ora nel capitolo seguente i risultati di alcuni test.
78
Capitolo 6
Test Effettuati
6. Test Effettuati
6.1 Rilevazione della banda di frequenze garantita dall'encoder
GSM-Voce
Dopo aver stabilito una piattaforma di sviluppo funzionale ai nostri scopi
risulta utile verificare che la banda di frequenze garantita dall'encoder GSMAMR sia effettivamente quella che ci aspettiamo.
79
Capitolo 6
Test Effettuati
Per verificare che la banda di frequenze garantita dall'encoder GSM-AMR
sia effettivamente quella che ci aspettiamo dal capitolo 2.1 (200-3400hz) si è
utilizzata la prima piattaforma di sviluppo descritta in precedenza, attraverso la
quale viene inviato un segnale di test. Successivamente tramite un confronto tra
lo spettro del segnale originale e quello ricevuto dal destinatario, vengono
valutati eventuali tagli in frequenza.
PC1 - SENDER
INPUT
SPEECH
LINE IN
1011000...
Speech
Encoder
Data
Encryption
1101001...
Data
Modulation
MIC IN
AUDIO OUT
3,5mm jack
GSM
PC2 - RECEIVER
LINE IN
HEADPHONES OUT
Data
Demodulation
1101001...
Data
Decryption
1011000...
Speech
Decoder
AUDIO OUT
OUTPUT
SPEECH
3,5mm jack
Figura 6.1: piattaforma di test
Oltre all'analisi spettrale del segnale originale e di quello ricevuto viene anche
analizzato lo spettro del segnale una volta acquisito dal telefono chiamante per
80
Capitolo 6
Test Effettuati
verificare la qualità del collegamento analogico tra PC e Telefono attraverso il
cavo jack da 3,5 mm.
Nel test sono stati utilizzati un telefono Android ed un Iphone 4 entrambi
forzati ad utilizzare unicamente la linea GSM.
Il S.O. Utilizzato su entrambi i PC è Debian Stable 64 bit, con scheda audio
realtek hd.
Come segnale di test, si è utilizzato un file audio Wav con compressione
lossless campionato a 44Khz e 16 bit, che spazza tutte le frequenze dell'udibile
(da 20 hz ai 20 Khz) in maniera lineare.
Qui di seguito possiamo vedere lo spettro del segnale in scala logaritmica:
Figura 6.2: segnale di test
Un segnale di questo tipo ci permette di visualizzare in maniera chiara a
81
Capitolo 6
Test Effettuati
quale frequenza vengono effettuati i tagli dall'encoder GSM.
Confrontiamo quindi lo spettro del segnale originale con quello acquisito
dal telefono chiamante tramite collegamento analogico con jack da 3.5 mm.
In basso possiamo vedere il segnale acquisito dal telefono mentre in alto il
segnale originale:
Figura 6.3: Confronto tra il segnale originale e quelle
ricevuto dal telefono mittente
82
Capitolo 6
Test Effettuati
Possiamo facilmente vedere che, tranne per un leggero rumore di fondo, tutto il
segnale viene acquisito correttamente dal telefono chiamante.
Vediamo adesso lo spettro del segnale ricevuto dal secondo telefono
attraverso la rete GSM, confrontato con lo spettro del segnale origianale:
Figura 6.4: Spettro del segnale originale (Sopra), Spettro del
segnale ricevuto tramite GSM (sotto).
83
Capitolo 6
Test Effettuati
Risulta evidente il taglio effettuato dall'enconder GSM (segnale in basso)
se confrontato con il segnale originale ( in alto).
Solo una porzione della banda di frequenze viene trasmessa. In particolare:
84
Capitolo 6
Test Effettuati
Figura 6.5: verifica della banda del segnale ricevuto
85
Capitolo 6
Test Effettuati
Vengono infatti tagliate tutte le frequenze inferiori a 200 Hz e superiori ai
3400hz che è esattamente quello che ci aspettavamo.
86
Capitolo 6
Test Effettuati
6.2 Il Test del prototipo effettuato
Si riporta qui di seguito, il test del prototipo sviluppato. La piattaforma di
test è quella ampiamente descritta in precedenza.
87
Capitolo 6
Test Effettuati
PC1 - SENDER
INPUT
SPEECH
Speech
Encoder
LINE IN
1011000...
Data
Encryption
1101001...
A
Data
Modulation
MIC IN
AUDIO OUT
A'
3,5mm jack
GSM
PC2 - RECEIVER
LINE IN
HEADPHONES OUT
Data
Demodulation
3,5mm jack
1101001...
Data
Decryption
1011000...
B
Speech
Decoder
AUDIO OUT
OUTPUT
SPEECH
C
Figura 6.6: piattaforma di test con evidenziati i punti di confronto dei segnali
Gli stage A,B,C rappresentano i punti di rilevazione e confronto del segnale
all'interno di questo test: attraverso l'applicazione sviluppata, oggetto del
capitolo 5.3, si registra lato mittente lo stream vocale, che verra codificato
attraverso un codec low-rate. Il file così generato contenente la voce in chiaro
( stage A) ed una volta cifrato (stage A') verrà confrontato con i corrispettivi file
ricevuti e registrati lato mittente (stage B e C).
Dovrà risultare quindi che A è il più possibile uguale a C e che A' sia il più
possibile uguale a B.
88
Capitolo 6
Test Effettuati
6.2.2 Risultati del test
Nella figura seguente possiamo vedere il confronto tra la rappresentazione
temporale in ampiezza de:
•
Il segnale vocale registrato in chiaro (stage A, Figura 6.x in alto)
•
Lo stesso segnale inviato e ricevuto in chiaro in una classica chiamata
GSM (Figura 6.x in mezzo)
•
Lo stesso segnale ricevuto dal prototipo destinatario dopo aver
attraversato tutti i processi di codifica, cifraggio, modulazione, invio sulla
rete GSM, demodulazione, decifraggio (stage C, figura 6.x in basso).
Figura 6.7: (sopra)Il segnale vocale in chiaro
(in mezzo)lo stesso segnale ricevuto tramite GSM
(sotto) Il segnale vocale rilevato allo stage C
Si nota chiaramente come il segnale originale, un piccolo sample vocale di
brevissima durata, venga ricevuto dal prototipo destinatario in maniera quasi
89
Capitolo 6
Test Effettuati
identifica all'originale.
In corrispondenza delle rette di colore rosso sono evidenziati alcuni tratti in cui il
segnale ricevuto differisce da quello originale: ciò significa che uno o più bit di
quei pacchetti sono stati demodulati in maniera sbagliata producendo così una
decrittazione erronea di quel pacchetto.
Verifichiamo ora il Bit Error Rate misurato:
Signals
Confronto segnali
Stage A'-B
Confronto segnali
Stage A-C
Total Bits
Error Bits
23296
16
23296
1664
BER
6.8*104
7.1*102
Risulta evidente che confrontando i segnali A'-B (a valle del cifraggio lato
mittente e a monte del decifraggio lato ricevitore) il BER è molto inferiore
rispetto al confronto tra i segnali A-C (a monte del cifraggio lato mittente ed a
valle del decifraggio lato ricevitore) poiché un numero sufficiente ma limitato di
bit interpretati male dal demodulatore comporta, dopo il decifraggio lato
ricevente, la perdita di tutti i bit che compongono il pacchetto.
90
Conclusioni
Conclusioni
91
Conclusioni
Sebbene sia stato raggiunto un risultato incoraggiante in questa fase di
avvio del progetto di ricerca, questo prototipo non vuole porsi come qualcosa di
definitivo bensìha avuto lo scopo di validare alcune teorie e testare alcune
soluzioni prospettate.
Molto lavoro c'è ancora da fare, in quanto il modulatore attuale non garantisce
un bit-rate tale da sostenere una comunicazione fluida e senza lag. Tutte la
politiche di certificazione, scambio chiavi ed autorizzazione non sono state
implementate e dovranno essere valutate in seguito.
La sfida più imminente da affrontare rimane la stessa che si è affrontata
sino ad ora: l'ottimizzazione del modulatore al fine di renderlo sempre più
robusto ed efficace, che inoltre implementi meccanismi auto-sincronizzanti
garantendo un rate di errore sempre più basso per streaming di durata sempre
maggiore.
91
Conclusioni
Appendice A
- Bluez HandsfreeGateway API -
1 Gateway hierarchy
2 ========================
3
4 Service
org.bluez
5 Interface
org.bluez.HandsfreeGateway
6 Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
7
8 This interface is available for remote devices which can function in the Audio
9 Gateway role of the HFP profiles. It is intended to be used with external
10 telephony stacks / handlers of the HFP protocol.
11
12 Methods
void Connect()
13
14
Connect to the AG service on the remote device.
15
16
void Disconnect()
17
18
Disconnect from the AG service on the remote device
19
20
dict GetProperties()
21
22
Returns all properties for the interface. See the
23
properties section for available properties.
24
25
void RegisterAgent(object path)
26
27
The object path defines the path the of the agent
28
that will be called when a new Handsfree connection
29
is established.
30
31
If an application disconnects from the bus all of its
32
registered agents will be removed.
33
34
void UnregisterAgent(object path)
35
36
This unregisters the agent that has been previously
37
registered. The object path parameter must match the
38
same value that has been used on registration.
92
Conclusioni
39
40 Signals
PropertyChanged(string name, variant value)
41
42
This signal indicates a changed value of the given
43
property.
44
45 Properties
string State [readonly]
46
47
Indicates the state of the connection. Possible
48
values are:
49
"disconnected"
50
"connecting"
51
"connected"
52
"playing"
53
54 HandsfreeAgent hierarchy
55 ===============
56
57 Service
unique name
58 Interface
org.bluez.HandsfreeAgent
59 Object path freely definable
60
61 Methods
void NewConnection(filedescriptor fd)
62
63
This method gets called whenever a new handsfree
64
connection has been established. The objectpath
65
contains the object path of the remote device. This
66
method assumes that DBus daemon with file descriptor
67
passing capability is being used.
68
69
The agent should only return successfully once the
70
establishment of the service level connection (SLC)
71
has been completed. In the case of Handsfree this
72
means that BRSF exchange has been performed and
73
necessary initialization has been done.
74
75
Possible Errors: org.bluez.Error.InvalidArguments
76
org.bluez.Error.Failed
77
78
void Release()
79
80
This method gets called whenever the service daemon
81
unregisters the agent or whenever the Adapter where
82
the HandsfreeAgent registers itself is removed.
92
Conclusioni
93
Conclusioni
Bibliografia e Webgrafia
1. Advances in Digital Speech Transmission (Martin, Ulrich)
2. Voice and Audio Compression for Wireless Communications (Hanzo,
Claire)
3. GSM, GPRS and edge performance (Halonen, Romero)
4. Wireless communications and networking - Vijay Kumar Garg
5. Sistemi di cifratura. Storia, principi, algoritmi e tecniche (De Rosa)
6. Cryptographic engineering (Koc)
7. http://www.bluetooth.org
8. http://www.eetimes.com/electronics-news/4139026/Sorting-ThroughGSM-Codecs-A-Tutorial
9. http://www.telecomabc.com
10. http://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec
11. http://www.vocal.com/data_sheets/gsmamr.pdf
12. http://www.etsi.org/deliver/etsi_en/301700_301799/301704/07.01.00_
40/en_301704v070100o.pdf
94
Conclusioni
Ringraziamenti
In primo luogo, un doveroso ringraziamento va al relatore di questo lavoro di
tesi, il Professor Aldo Franco Dragoni, per l’aiuto e la grande libertà concessami,
ma soprattutto per la cordialità e la stima mostrata nei miei confronti.
Un grazie di cuore va alla mia ragazza, per aver sempre creduto in me ed avermi
aiutato ad affrontare con serenità questa grande cavalcata.
Il mio debito di riconoscenza verso la mia famiglia è più grande che mai, non
potrò mai ringraziare adeguatamente i miei genitori o mio fratello: i primi, per
avermi sempre supportato durante il corso degli studi e per avermi dato la
possibilità di realizzare tutti gli obbiettivi che mi sono posto; mio fratello, per
aver sempre appoggiato ogni mia scelta ed aver fatto di tutto per aiutarmi in
ogni occasione in cui ne avevo bisogno.
95

Progettazione e sviluppo di un prototipo per la

Transcript

Documenti analoghi

Visualizza il PDF dell`indice

I Fiori delle Fate delle Acque capitolo n.1 di una

Indice - Infinito Edizioni

determina - Comune di Vicenza

Techsolo TC-B16: scheda audio 5.1

DIRITTO AMMINISTRATIVO

qui

indice generale

Dinamica coerente di un condensato di Bose

rilevatore onde celebrali portatile con bluetooth fascia