Prefazione


Negli ultimi decenni il progresso della microelettronica ha portato dispositivi quali sistemi desktop, palmari, notebook, cellulari, cordless, HI-FI  a diventare ampiamente diffusi nella vita di tutti i giorni.
Fino a qualche anno fa, il collegamento di questi dispositivi,ove possibile, era realizzato solamente per mezzo di scomodi e antiestetici cavi.
Tecnologie introdotte recentemente, realizzano collegamenti invisibili tra dispositivi, basandosi o sull'utilizzo di raggi infrarossi, come accade nella tecnologia IrDA o sull'uso di radio frequenze, come nelle reti wireless.
Lo svantaggio principale della tecnologia IrDA è legato alla necessità di dover posizionare i dispositivi da connettere, in modo che siano tra loro visibili.
Agli inizi degli anni '90 Ericsson avviò un progetto di ricerca al fine di realizzare un sistema di comunicazione basato sulle onde radio.
L'argomento si dimostrò talmente vasto da spingere la multinazionale a coinvolgere anche altri partner di rilievo, quali Nokia, IBM, Toshiba, Intel, dando così vita nel 1998 al SIG (Special Industry Gruop).
L’obiettivo di questo gruppo era di riuscire a sviluppare e promuovere una soluzione globale per le comunicazioni wireless operante nella banda ISM (Industrial Scientific Medicine band) 2.4 GHz.
Il nome Bluetooth fu suggerito dalle gesta eroiche del re danese Harald Blåtand, nome che tradotto in inglese è diventato Bluetooh. Infatti come questo re unì nel 10° secolo le popolazioni scandinave, così  la tecnologia Bluetooth doveva essere in grado di unire e far comunicare dispositivi tra loro diversi.
Nel dicembre del 1999 al gruppo si aggiunsero altre quattro multinazionali: 3COM, Lucent, Microsoft e Motorola.
Tutto il clamore prodotto da questa nuova tecnologia, spinse l'IEEE a standardizzare tale soluzione sotto il nome di 802.15, aggiungendola di fatto, alla famiglia degli standard 802.x per le reti locali, come standard per le reti personali.
Bluetooth è nato essenzialmente come uno stack di protocolli per la connettività wireless dei dispositivi prima citati ed ha, oggi, l'ambizione di creare le cosiddette WPAN (Wireless Personal Area Network), ovvero microambienti nei quali dispositivi tra loro diversi, come gli elettrodomestici ed i PC, possano interagire tra loro in modo del tutto trasparente all'utente.
Gli scenari applicativi sono i più disparati e vanno dalla possibilità di scambiare informazioni in modo automatico tra un PDA (Personal Digital Assistant) e un desktop, fino alla possibilità di utilizzare un telefonino con scheda Bluetooth come telecomando universale, per comandare un certo insieme di dispositivi elettronici presenti in una certa area.
La massima potenza prevista per un dispositivo non permette trasmissioni oltre i 100 metri. Nella realtà, poiché questa tecnologia è particolarmente sfruttata in dispositivi portatili in cui il consumo energetico è un fattore cruciale, la potenza di trasmissione dei dispositivi non permette l'invio di dati oltre i 10 metri.
In Bluetooth, sono previsti due tipi di canali per la trasmissione delle informazioni. I canali sincroni permettono trasmissione simmetrica della voce nelle due direzioni con una velocità di 64 kb/s, mentre quelli asincroni prevedono due diverse modalità di funzionamento.
Nel caso di trasmissione asincrona non simmetrica è prevista una velocità di trasferimento massima di 723.2 kb/s in una direzione e 57.6 kb/s nell'altra. Nel caso di trasmissione asincrona simmetrica la massima velocità di trasferimento è di 433.9 kb/s.



1. Introduzione

L'obiettivo di questa tesina è fornire una panoramica globale sulle reti Bluetooth, ma particolare attenzione è rivolta durante la trattazione agli aspetti della sicurezza.
Nel capitolo 2 sono descritti brevemente i protocolli fondamentali utilizzati, allo scopo di permettere una maggiore comprensione degli aspetti specifici della sicurezza, descritti nel capitolo 3.
Il capitolo 3 può essere diviso logicamente in 3 parti. Nella prima sono descritte in dettaglio le procedure e gli algoritmi utilizzati per garantire la sicurezza delle trasmissioni. Nella seconda parte sono presentati alcuni degli attacchi conosciuti per le reti Bluetooth e infine nella terza sono evidenziate le possibili vulnerabilità dei dispositivi, a cui i produttori devono prestare particolare attenzione in fase di progettazione.  


2. Protocolli in Bluetooth

I protocolli in Bluetooth si possono dividere in due grandi categorie:

• protocolli di trasporto;
• protocolli middleware.
   

I protocolli di trasporto sono in realtà protocolli sviluppati ad hoc per la tecnologia Bluetooth ed intervengono in tutti gli scambi di dati tra due dispositivi.
I protocolli middleware comprendono, invece, sia protocolli specifici della tecnologia Bluetooth, che altri adottati per fornire supporto ad applicazioni già esistenti.
La figura mostra in dettaglio i vari protocolli dello stack.

Una breve descrizione di ognuno dei protocolli indicati nella figura è fornita nei paragrafi dal 2.1 al 2.8.
Il paragrafo 2.9 elenca i vari protocolli middleware, evidenziati nella figura come Altri protocolli, adottati in Bluetooth al solo scopo di supportare le numerose applicazioni già esistenti ed ampiamente diffuse.


2.1 Radio

Il protocollo radio definisce le caratteristiche tecniche del sistema di trasmissione radio dei dispositivi Bluetooth.
Il modulo radio opera nella banda ISM (Industrial Scientific Medicine band) 2.4GHz ed utilizza la tecnica del salto di frequenza per evitare interferenze tra dispositivi che iniziano contemporaneamente una trasmissione.
Questa tecnica consiste nel cambiare periodicamente in modo pseudo-casuale la frequenza di trasmissione, scegliendo il canale su cui trasmettere tra uno dei 79 disponibili, a partire dalla frequenza di 2.402 MHz. 
Le 79 possibili frequenze, previste dallo standard, sono (2.402+k) MHz per k = 0, 1, 2, ……., 78.
Limitazioni sul range di frequenze sono presenti in varie nazioni, così speciali algoritmi per il salto di frequenza sono progettati per i dispositivi a loro destinati.
Per esempio in Francia i canali disponibili sono 23 e le relative frequenze sono (2.454+k) MHz con k=0, ..., 22. 
La sequenza di frequency hopping è unica per una rete Bluetooth (detta Piconet) ed è determinata dall'indirizzo del dispositivo Master della rete; 
 

I dispositivi Bluetooth si possono dividere in 3 gruppi, in base alla potenza del loro modulo radio.

2.2 Baseband
 
Il protocollo baseband definisce le procedure chiavi che rendono possibile la comunicazione tra i vari dispositivi di una rete Bluetooth, chiamata piconet.
In particolare il protocollo è responsabile della sincronizzazione delle unità Bluetooth, della selezione della frequenza di hopping, della correzione degli errori, del controllo del flusso, e della sicurezza delle trasmissioni.
Il protocollo definisce, inoltre, come le piconet vanno costruite, come sono strutturati i link e come possono essere trasmesse risorse che andranno poi condivise dai vari dispositivi.

2.2.1 Piconet

In Bluetooth, una piconet è una rete wireless, che permette lo scambio di informazioni ai dispositivi che la compongono. Una tale rete è costruita dinamicamente senza alcun intervento esterno man mano che nuovi dispositivi sono ad essa aggiunti.
Una piconet contiene almeno un dispositivo master e al più sette dispositivi slave, con cui il master comunica attivamente.
I dispositivi sono sempre prodotti in modo da poter operare sia da master che da slave. La loro esatta modalità di funzionamento è decisa solo nel momento in cui la piconet è effettivamente costituita.
Tra i vari compiti del dispositivo master troviamo:

• l’assegnamento agli slave, con cui comunica attivamente, di un indirizzo univoco all’interno della piconet, detto active member address (AM_ADDR);
• l’istante di tempo in cui ciascuno slave presente nella rete può iniziare a trasmettere.

Oltre ai dispositivi slave, con il master possono essere registrati anche al più 255 dispositivi parked, cioè dispositivi che possono essere invitati, se necessario, a diventare attivi.
Se un dispositivo Bluetooth non è associato ad una piconet, si dice che è in modalità stand-by.
La figura mostra un esempio di piconet

Come già detto, le piconet sono reti wireless, cioè reti, che utilizzano per la trasmissione, radio frequenze. Questo comporta, che nel caso di piconet tra loro vicine, uno stesso dispositivo può essere contemporaneamente membro di due o più piconet e in tal caso si parla di scatternet.


 

2.2.2 Canale fisico

Il canale utilizzato in Bluetooth per le trasmissioni è definito come la sequenza pseudo-casuale dei salti di frequenza seguiti in modo sincrono dai membri della piconet.
La sequenza dei salti è unica per una certa piconet ed è determinata dall'indirizzo Bluetooth (BD_ADDR) del dispositivo master e dal suo clock.
Il canale è diviso in time slots dove l'inizio di ciascuno di essi coincide con un salto di frequenza.
Il tasso nominale a cui è si verificano i salti è di 1600 hops/sec, ovvero ogni slot ha una lunghezza di 0.625 ms. 
Gli slot sono numerati in funzione del clock del dispositivo master e il range della numerazione loro assegnata va da 0 a 2²⁷ -1.
 
Sia i dispositivi master, che quelli slave possono trasmettere pacchetti solo in time slot.
Per la trasmissione è utilizzato uno schema time-division duplex (TDD) dove master e slave si alternano nella trasmissione.
Il master trasmette negli slot con numero pari, mentre gli slave in quelli con numero dispari.

L'inizio della trasmissione di un pacchetto coincide sempre con l'inizio di uno slot e durante la trasmissione di un pacchetto non avvengono mai salti di frequenza.

In Bluetooth è possibile anche trasmettere pacchetti multislot, cioè pacchetti che possono occupare, viste le loro dimensioni, anche 5 slot.
Durante la trasmissione di un tale tipo di pacchetto non avvengono salti di frequenza all'inizio di ciascuno slot, ma alla fine della trasmissione si parte con la frequenza che si sarebbe usata, se fossero stati trasmessi solo pacchetti di dimensione pari ad uno slot.

Un dispositivo slave può trasmettere solo dopo che ha ricevuto una trasmissione del dispositivo master.
Nel caso di una scatternet, il nodo slave appartenente alle diverse piconet, costituenti la scatternet, può trasmettere solo in una per volta.

Per mantenere la sincronizzazione dei salti di frequenza, i dispositivi slave sfruttano la conoscenza del clock del master e la lunghezza degli slot (0.625 ms). Da qui, in ogni momento, gli slave mantengono l'offset tra il proprio clock e quello del master.
 

2.2.3 Link Fisici

Una piconet Bluetooth supporta due tipi di link tra master e slave:
 

• Synchronous Connection-Oriented (SCO) link;
• Asynchronous Connection Less (ACL) link.

In genere, tra un master e uno slave, il tipo di link usato è senza connessione ed asincrono (ACL), ma sono anche supportati fino a tre link orientati alla connessione e sincroni (SCO).
Un link SCO è un link point-to-point tra un master e un singolo slave. 
Il master mantiene un link SCO usando a intervalli regolari slot riservati.
Diversamente, un link ACL è un link poit-to-multipoint tra il master e tutti gli slave che partecipano alla piconet.


2.2.3.1 Link SCO

Un link SCO è un link point-to-point simmetrico tra il master e uno specifico slave di una piconet. Un link di questo tipo è considerato come una connessione circuit-switched, in quanto per la trasmissione sono utilizzati solo slot riservati. 
Su link di questo tipo possono essere inviate informazioni come la voce, per le quali il ritardo è un parametro cruciale per la qualità del servizio fornito.
Il master può supportare fino a 3 link di tipo SCO allo stesso slave o a dispositivi slave differenti. Diversamente uno slave può supportare fino a tre link SCO con lo stesso master oppure 2 con master differenti. Puntando più suI ritardo che sulla affidabilità delle trasmissioni, i pacchetti di tipo SCO non sono mai ritrasmessi in caso di errore.

Il master trasmetterà allo slave pacchetti SCO a intervalli regolari negli slot riservati master-to-slave. L'intervallo di tempo che intercorre tra due trasmissioni di questo tipo è detto SCO interval, T_SCO.
Ad uno slave SCO è sempre permesso rispondere con pacchetti SCO nel successivo slot slave-to-master.


Un link SCO è stabilito dal master con l'invio di un messaggio SCO di setup per mezzo del protocollo LM, Questo messaggio conterrà parametri importanti per il timing come lo SCO interval, T_SCO, e l'offset, D_SCO, per specificare slot riservati.

Per prevenire problemi legati al wrap-round del clock, un flag di inizializzazione nel messaggio di setup specifica il tipo di inizializzazione usato (1 o 2), in modo che lo slave possa applicare il corretto metodo di inizializzazione.
Il master usa il metodo 1, quando il bit più significativo del proprio clock (CLK₂₇) è 0, mentre utilizza il metodo 2 se tale bit è 1.
Gli slot SCO master-to-slave riservati saranno inizializzati sugli slot per cui il clock soddisfa la seguente equazione:

Gli slot SCO slave-to-master seguiranno direttamente gli slot riservati master-to-slave.
Dopo l'inizializzazione, il valore del clock CLK(k+1) per il prossimo slot SCO master-to-slave è ottenuto sommando al valore del clock del corrente slot SCO master-to slave, il fissato intervallo T_SCO :

2.2.3.2 Link ACL

Negli slot non riservati a link SCO, il master può scambiare pacchetti con qualunque slave.
I link ACL forniscono una connessione packet-switched tra il master e tutti gli slave attivi nella piconet.
Tra il master e uno dato slave può esistere solo un link ACL. Per i pacchetti ACL è permessa anche la ritrasmissione per garantire l'integrità dei dati trasmessi.  

Ad uno slave è permesso inviare un pacchetto ACL nello slot slave-to-master se e solo se è stato indirizzato nel precedente slot master-to-slave.
Se lo slave fallisce nel decodificare l'indirizzo slave nel header del pacchetto, a questo non è permesso trasmettere.
Se un pacchetto non è indirizzato ad uno specifico slave, esso è considerato inviato in broadcast e quindi tutti gli slave possono leggerlo.
Se non ci sono dati da inviare sul link ACL e non è richiesto polling allora nessuna trasmissione prenderà luogo.

2.2.4 Error Correction

Ci sono due schemi di correzione degli errori in Bluetooth:

• 1/3 rate FEC;
• 2/3 rate FEC.

Lo scopo dello schema FEC (Forward Error Correction) è ridurre il numero di ritrasmissioni.
Comunque, in un ragionevole ambiente error-free, FEC aggiunge overhead non necessario, riducendo di conseguenza il throughput. Per questo motivo nei pacchetti è possibile non includere alcuna correzione degli errori per i dati trasmessi.
L'header di un pacchetto trasporta importanti informazioni sul link. Per questo motivo è sempre protetto da un 1/3 rate FEC, in modo da poter riconoscere più bit ricevuti con errore.

2.2.4.1 FEC CODE: rate 1/3

Per la trasmissione dell'header è usato, come codice FEC, la ritrasmissione per 3 volte dello stesso bit. Questo stesso tipo di codice è usato, per esempio, per proteggere le informazioni prodotte da una trasmissione vocale.
La figura mostra più in dettagli lo schema di codifica.

2.2.4.2 FEC CODE: rate 2/3

Per lo schema FEC CODE: rate 2/3 è utilizzato un codice di Hamming accorciato (15,10). Il polinomio generatore è g(D)= (D + 1)(D⁴ + D + 1)
Il LFSR, che genera questo codice è così definito:


 

Inizialmente tutti i registri sono settati a 0. I 10 bit dell'informazione sono caricati sequenzialmente nel LFSR con gli switch S1 e S2 posti in posizione 1.
Dopo che l'ultimo bit è stato caricato, gli switch S1 e S2 sono settati in posizione 2 e i 5 bit di parità sono dati in output e concatenati ai 10 contenenti l'informazione.
Di conseguenza, ogni blocco di informazioni di 10 bit è codificato in una parola a 15 bit. Questo codice può correggere singoli errori e riconoscere tutti i doppi errori.
Dal momento che il codificatore opera con segmenti di informazioni di lunghezza 10, in caso di necessità, sono usati bit di riempimento con valore 0. 

2.3 Link Manager

Il Link Manager Protocol (LMP) è un protocollo responsabile delle transazioni tra i dispositivi di una piconet. Tra i suoi compiti principali troviamo il settaggio delle proprietà del link esistente tra due dispositivi e l’autenticazione di questi ultimi per permettere la realizzazione di un canale cifrato.  

Come evidenziato dalla figura il protocollo link manager si basa sull'interfaccia fornita dal link control (LC) parte integrante del protocollo baseband, che a sua volta sfrutta l'interfaccia fornita dal sistema di trasmissione radio RF. Per questo il link manager protocol non è responsabile della correzione dell'errore o della ritrasmissione dei pacchetti in caso di errore. 
L’autenticazione dei due dispositivi Bluetooth agli estremi di un link avviene per mezzo di un meccanismo di challenge-response definito da questo protocollo.
Tra i compiti del Link Manager Protocol troviamo l’apprendimento delle funzionalità offerte dal LMP all’altro estremo del link e la verifica periodica della raggiungibilità dell’altro dispositivo per mezzo di operazioni di polling. Un dispositivo per poter comunicare con un altro ha bisogno di conoscere le funzionalità di questo ultimo, come il supporto dei link SCO e la dimensione massima dei pacchetti accettati in input.
I messaggi del Link Manager hanno priorità superiore a qualunque dato utente da trasferire.
Questo comporta, che se il Link Manager ha bisogno di inviare un messaggio, questo non sarà ritardato da traffico L2CAP, anche se può essere ritardato da ritrasmissioni di pacchetti baseband. 


2.4 Host Controller Interface (HCI) 

Come suggerisce il nome, l’host controller interface non è un vero e proprio protocollo, ma è piuttosto un’interfaccia standardizzata, grazie alla quale dispositivi host possono accedere agli strati più bassi dello stack Bluetooth.
Attraverso l’HCI un host può inviare dati agli altri dispositivi e ricevere informazioni dalle altre unità presenti nella piconet.
Con questa interfaccia un host può, ordinare al suo strato baseband di creare un link ad uno specifico dispositivo Bluetooth, eseguire richieste di inquiry, richieste di autenticazione, passare una chiave per il link, ed effettuare una richiesta di attivazione di una modalità low power.



2.5 Logical Link Control and Adaption Protocol

Il protocollo Logical Link Control and Adaption lavora sfruttando l'interfaccia fornita dal protocollo Baseband e risiede, come evidenzia la figura, a livello data link.

L2CAP fornisce per la trasmissione dei dati sia un servizio orientato alla connessione che uno non connesso. Tra le sue varie funzionalità troviamo:

• multiplexing;
• segmentazione;
• riassemblaggio;
• astrazione di group.
   

Le richieste per questo protocollo sono:

• semplicità;
• basso overhead.

Questi requisiti permettono alle implementazioni di L2CAP di poter essere applicate anche a dispositivi con limitate risorse di calcolo e di ottenere una sufficiente larghezza di banda nello scambio delle informazioni. 
 

L2CAP supporta il multiplexing di più protocolli di alto livello sul protocollo Baseband. Da solo il protocollo Baseband non avrebbe modo di distinguere a quale protocollo di alto livello un pacchetto è destinato.

L2CAP fornisce anche funzioni di frammentazione e riassemblaggio dei pacchetti. Infatti il protocollo Baseband richiede che i pacchetti ricevuti non abbiano una dimensione superiore a 341 bytes. Da qui i pacchetti inviati, se necessario, vanno prima frammentati e poi passati allo strato inferiore. Allo stesso modo anche i pacchetti ricevuti, se frammentati, vanno prima riassemblati e poi trasmessi agli strati superiori.
 

Un ulteriore funzione di questo protocollo è la negoziazione con il dispositivo all'altro capo del link della qualità del servizio richiesto (QoS).   
 

Molti protocolli includono il concetto di gruppi di indirizzi. Il protocollo Baseband, per esempio, supporta il concetto di piconet, ovvero un gruppo di dispositivi sincronizzati nel salto di frequenza sulla base dello stesso clock. L'astrazione di group del protocollo L2CAP permette di mappare gruppi di protocolli sulla piconet in modo efficiente. Senza questa astrazione gli strati superiori dovrebbero interfacciarsi direttamente con gli strati Baseband e Link Manager.

 

2.6 Service Discovery Protocol (SDP)

Attraverso il protocollo Service Discovery, un dispositivo Bluetooth può richiedere ad un altro dispositivo informazioni sui servizi offerti e sul modo in cui può accedere ad essi.
Il SDP fornisce solo informazioni circa i servizi, ma non l’accesso diretto.
Un dispositivo, una volta apprese informazioni sulle modalità di accesso al servizio desiderato, vi accede nel modo indicatogli.
SDP è ottimizzato per essere usato da dispositivi di capacità limitate.
Per descrivere i servizi e i loro attributi sono usati identificatori universalmente univoci (UUID) a 128 bit, in un modo che non richiede l’esistenza di un’autorità centrale per la registrazione dei servizi.
 

2.7 RFCOMM Protocol 

Il protocollo RFCOMM è stato introdotto per fornire un’interfaccia seriale agli strati di trasporto Bluetooth.
In particolare, RFCOMM emula i segnali dei nove dei fili di un cavo seriale RS-232 di interconnessione, basandosi sullo standard ETSI 07.10, che permette emulazione e multiplexing di varie porte seriali su un singolo trasporto. 
RFCOMM permette, quindi, ad un’applicazione sviluppata per operare attraverso interfaccia seriale di operare su link Bluetooth. Supporta fino a 60 connessioni simultanee tra due dispositivi, anche se il numero esatto dipende dalla particolare implementazione.


2.8 Telephony Control Signaling

Il Telephony control può essere fornito sfruttando l’insieme di comandi AT.
Dal momento che i comandi AT sono stati sviluppati per essere passati attraverso linee seriali, i dispositivi Bluetooth usano per inviare e ricevere tali segnali il protocollo RFCOMM.
Oltre a questo protocollo di controllo detto TCS-AT è stato sviluppato anche TCS-BIN (BIN sta per Binary encoding of Information) che opera basandosi sull’interfaccia fornita da L2CAP.
Diversamente da TCS-AT, TCS-BIN supporta comunicazioni point-to-multipoint permettendo, per esempio, ad una base cordless per telefoni portabili di passare il segnale dello squillo di una chiamata in arrivo ai vari terminali ad essa associati.
 

2.9 Altri Protocolli

Per supportare varie applicazioni e vari standard industriali in Bluetooth, sono stati adottati vari protocolli che operano basandosi sull'interfaccia fornita da RFCOMM.
Tali protocolli includono: 

• il Point-to-Point Protocol (PPP) dell’IETF per comunicazioni IP su linee seriali; 
• l’Object Exchange Protocol (OBEX) che fornisce scambio di oggetti simile a HTTP;
• l’Infrared Mobile Communications Protocol (IrMC) che denisce il modo in cui telefoni mobili e dispositivi di comunicazione possono scambiarsi dati. Per maggiori dettagli è possibile visitare il sito: http://www.irda.org/standards/standards.asp.

3 Sicurezza in Bluetooth

La tecnologia Bluetooth, come detto finora, permette comunicazioni di tipo peer to peer a dispositivi che risiedono in una area limitata.
Allo scopo di fornire protezione e confidenzialità ai dati, il sistema prevede misure di sicurezza sia a livello applicazione, che a livello link.
A livello link, la sicurezza è garantita per mezzo di quattro entità: un indirizzo pubblico, unico per ciascun dispositivo, due chiavi segrete e un numero casuale differente per ogni nuova transazione. Nella figura sono indicate le loro lunghezze: 

L’indirizzo Bluetooth di un dispositivo (BD_ADDR) è un indirizzo IEEE a 48 bit, unico per tutti i dispositivi. Le chiavi segrete sono derivate durante il processo di inizializzazione.
Normalmente, l’encryption key tra due dispositivi è ottenuta dalla chiave di autenticazione, che coincide con la chiave associata al loro link, detta link key, con lunghezza 128 bit. 
In casi particolari, quando il dispositivo master della piconet vuole trasmettere contemporaneamente a più slave le stesse informazioni, allora l'encryption key è calcolata da una link key temporanea, detta master key, generata dal master e con la quale sono sostituite temporaneamente le link key già fissate tra il master e ogni slave.  
Per l’algoritmo di autenticazione, la lunghezza della chiave è di 128 bit, ma per quello di cifratura può variare da un minimo di un ottetto ad un massimo di 16 ottetti.
La taglia della chiave di cifratura è configurabile per due motivi. In primo luogo, disponendo di un algoritmo la cui è chiave di cifratura è variabile in lunghezza, è possibile superare le limitazioni imposte da alcuni stati sull’esportazione degli algoritmi di cifratura. La seconda ragione è legata alla possibilità di aggiornare facilmente nel tempo la lunghezza della chiave senza dover ridisegnare l’algoritmo di cifratura.
La chiave di cifratura è totalmente differente dalla chiave di autenticazione.
Ogniqualvolta la cifratura è attivata, una nuova chiave è generata. Perciò il tempo di vita della chiave di cifratura non necessariamente coincide con il tempo di vita della chiave di autenticazione.
 
Ogni dispositivo Bluetooth possiede un generatore pseudo-casuale per la generazione dei numeri casuali necessari alle funzioni legate alla sicurezza.
Idealmente un generatore di numeri casuali dovrebbe essere basato su un processo fisico intrinsecamente casuale, ma per ragioni pratiche è utilizzato un generatore pseudo-casuale.
In Bluetooth, l’unica richiesta circa i numeri casuali è che essi siano non-repeating, e randomly generated.
Non-repeating significa che è difficile, che durante il tempo di vita dell’autentication key, uno stesso numero venga generato più di una volta.
Randomly generated significa che è difficile predire il prossimo valore generato con una probabilità più grande di 1/2^L, se la lunghezza della chiave è di L bit.

La sicurezza è garantita dall'esecuzione di vari passi che possiamo dividere in 3 fasi. Supponiamo di avere 2 soli dispositivi che vogliono comunicare.

Nella prima fase i due dispositivi generano ciascuno una unit key. Questa chiave è generata da un dispositivo al momento della sua prima accensione ed è poi memorizzata in una propria memoria non volatile, per essere utilizzata anche in futuro.
La seconda fase inizia con il primo handshake tra i due dispositivi. In essa avviene la generazione dell'initialization key, l'autenticazione dei dispositivi sulla base di questa chiave e lo scambio della link key da usare nelle iterazioni successive.
La terza fase è caratterizzata da ulteriori handshake che permettono ai due dispositivi di trasmettere successivamente solo informazioni cifrate.
Le operazioni di questa fase sono l'autenticazione sulla base della chiave K_AB e la generazione della encryption key usata per cifrare tutte le comunicazioni tra i due dispositivi.





Le link key utilizzate in Bluetooth sono numeri casuali a 128 bit. Queste chiavi sono condivise da due o più dispositivi e sono alla base della sicurezza delle loro transazioni. Sono utilizzate sia in fase di autenticazione, che per la generazione dell’encryption key.
E’ possibile dividere le link key in due classi: link key semipermanenti e link key temporanee.
 
Una link key semipermanente, una volta generata, è memorizzata in una memoria non volatile e può essere utilizzata anche dopo che la corrente sessione è terminata; quindi anche in più fasi di autenticazione. Le link key temporanee, invece, hanno un tempo di vita che è limitato da quello della sessione in cui sono state generate.
 
A seconda del tipo di applicazione, le link key possono essere:

•  unit key, K_A;
•  combination key, K_AB;
•  master key, K_master;
•  initialization key, K_init.
   

Una unit key, K_A, è generata da un dispositivo A, quando è avviato per la prima volta. Una volta creata, è memorizzata in una memoria non volatile ed è modificata solo in casi eccezionali.  

Una combination key, K_AB, è ottenuta da informazioni prodotte da due unità, A e B. Questa chiave è generata per ogni coppia di dispositivi quando è necessaria maggiore sicurezza. L'uso di queste chiavi comporta un maggiore spreco di memoria in quanto ciascun dispositivo dovrà memorizzare una combination key per ogni sua connessione.
 
Una initialization key, K_init, è usata come link key durante il processo di inizializzazione, quando non è stata ancora definita e scambiata una unit key o una combination key, da usare come link key, oppure nel caso in cui una link key precedente è stata persa.
Una tale chiave è necessaria quando due dispositivi entrano in contatto per la prima volta, in modo da garantire la protezione dei parametri fondamentali dell’inizializzazione.

Una master key, K_master, è usata quando il dispositivo master vuole trasmettere contemporaneamente a vari dispositivi. Una chiave di questo tipo sostituisce momentaneamente la link key della corrente sessione.
 

3.1 Generazione unit key

Una unit key è generata per mezzo dell'algoritmo E₂₁, in un dispositivo, quando è avviato per la prima volta. 
Una volta creata, essa è memorizzata in una memoria non volatile ed è raramente modificata.
All'algoritmo E₂₁ è passato l'indirizzo Bluetooth del dispositivo, BD_ADDR, e un numero casuale RAND a 128 bit.

3.2 Generazione initialization key

Quando due dispositivi Bluetooth entrano in contatto per la prima volta, uno dei due (il richiedente, unità B) prova a raggiungere l'altro (il verificatore, unità A).
Il richiedente deve dimostrare al verificatore di essere un dispositivo autorizzato, ovvero condivide con esso uno stesso PIN. Per fare questo viene prima di tutto generata una initialization key in entrambi i dispositivi, sulla base di questo PIN, e poi è avviata la fase di autenticazione in cui A accerta che B condivide con se una stessa link key, che in questa fase coincide con l'initialization key appena generata.
Normalmente i PIN usati sono numeri di 4 cifre decimali, inseriti dall'utente nei dispositivi o via software o per mezzo di una tastiera. Potenzialmente un PIN può essere lungo anche 128 bit. In tale caso, per l'inserimento nei due dispositivi si può ricorrere ad un protocollo come quello di Diffie-Hellmann per lo scambio delle chiavi.
Nel caso peggiore, quando uno dei due dispositivi ha una limitata capacità di memoria il suo PIN può essere fisso, cioè scelto dal produttore in fase di costruzione. Nel caso in cui nessun PIN è disponibile allora  il valore di default è zero.


L'initialization key è generata per mezzo dell’algoritmo E₂₂ a cui sono dati in input il codice PIN, la lunghezza in ottetti del PIN, L, e un numero casuale IN_RAND.
L’output dell’algoritmo E₂₂ è usato per lo scambio della chiave durante la generazione della link key. Terminata la fase di autenticazione l’initialization key è scartata.

Durante la generazione dell’initialization key, il PIN è aumentato con l'indirizzo BD_ADDR di uno dei due dispositivi. Per maggiori dettagli vedi paragrafo 3.7.3.
Se un’unità ha un PIN fisso stabilito dal produttore, allora, nel calcolo dell'initialization key, è usato l’indirizzo dell’altra unità.
Se entrambe le unità hanno un PIN variabile scelto dall’utente, allora è usato l’indirizzo del dispositivo che ha ricevuto il numero casuale, IN_RAND.
Se entrambi i dispositivi hanno un PIN fisso, questi non possono essere accoppiati.
Dal momento che la lunghezza del PIN usato dall’algoritmo non può eccedere i 16 ottetti è possibile che non tutto l’indirizzo BD_ADDR sia usato.
Con questa procedura si garantisce la dipendenza della chiave di inizializzazione, K_init, dall’identità del dispositivo con PIN variabile.


3.3 Autenticazione

Lo schema di autenticazione è lo stesso sia nella fase 2 che nella fase 3. La differenza è nella chiave associata al link. Nella fase 2, la chiave usata è la chiave temporanea K_init, nella terza è usata la link key K_AB decisa dai due dispositivi.
Il processo di autenticazione si basa su uno schema di challenge-response in cui un dispositivo verificatore accerta che uno richiedente condivida con se una certa chiave segreta.
Nello schema utilizzato, il verificatore A sfida il richiedente B, inviandogli un numero casuale, AU_RAND_A. 
Entrambi i dispositivi basano l’autenticazione sull’algoritmo E₁, che ritorna come risultato i valori SRES e ACO (Authenticated Ciphering Offset) prendendo in input:

• un numero casuale AU_RAND_A prodotto dal dispositivo verificatore A;
• l’indirizzo Bluetooth del dispositivo B, che richiede di essere autenticato;
• l’attuale link key.

Dopo che le parti hanno ottenuto questi valori, il dispositivo richiedente invia a quello verificatore il valore SRES.
Il verificatore considera superata l'autenticazione solo se il proprio valore SRES' calcolato, coincide con quello ricevuto dal richiedente.

La figura mostra i messaggi scambiati tra le parti in fase di autenticazione.

Più in dettaglio:

In Bluetooth, il verificatore non necessariamente è il master della piconet, ma è l’applicazione a decidere quale dispositivo debba operare da verificatore.
Per esempio, alcune applicazioni richiedono solamente autenticazione in una direzione, ma molte altre richiedono una mutua autenticazione.
In questo ultimo tipo di autenticazione, dopo che un dispositivo A ha autenticato un dispositivo B, il dispositivo B deve autenticare il dispositivo A.
 
Per evitare che un dispositivo, che non conosce la chiave, possa tentare di scoprirla, compiendo in poco tempo, più tentativi di autenticazione con chiavi diverse, è previsto un piccolo accorgimento. Dopo che un'autenticazione è fallita con un certo dispositivo, il verificatore stabilisce per esso un tempo di attesa, prima che questi possa effettuare una nuova richiesta di autenticazione. Questo tempo di attesa è incrementato esponenzialmente per ogni fallimento fino ad un massimo stabilito ed è ridotto, quando non si verificano ulteriori fallimenti, sempre esponenzialmente fino al raggiungimento del valore 0.
 
Per ridurre le vulnerabilità del sistema anche ad attacchi denial of service, è previsto che ciascun dispositivo mantenga in una lista, per ciascuna unità con cui è entrato in contatto, un tempo di attesa, che dovrà trascorrere, prima che con questi ci possa essere un nuovo contatto.
Chiaramente la taglia della lista è limitata dalla capacità di memoria del dispositivo.
 

3.4 Scambio della link key

La link key tra due dispositivi dipende dal grado di sicurezza richiesto e dalla capacità di memoria dei dispositivi.  
La chiave associata al loro link può essere:

• la unit key di uno di essi;
• una combination key ottenuta da informazioni prodotte da entrambi i dispositivi.

Se uno dei due dispositivi ha una limitata capacità di memoria, allora il dispositivo con limitate risorse può evitare di memorizzare per ogni dispositivo con cui è connesso una link key diversa, utilizzando semplicemente per tutte le connessioni la propria unit key come link key.
Se la link key tra due dispositivi è la unit key di uno dei due, allora il dispositivo che la fornisce ne trasmette lo XOR bit a bit con l'attuale link key, che nella fase 2 coincide con l'initialization key.
Nell’esempio mostrato nella figura sotto, la unit key dell’unità A, K_A, deve essere utilizzata come link key per la connessione tra A e B, supponendo che tra i due la link key attuale sia l'initialization key, creata in fase di autenticazione. In tale situazione l’unità A invia all’unità B lo XOR bit a bit della propria unit key, K_A, con l'attuale link key, K_init. Il dispositivo B può ottenere la chiave K_A, effettuando lo XOR bit a bit della sequenza ricevuta con l'attuale link key, K_init, condivisa con il dispositivo A. 

Diversamente una link key tra due dispositivi può essere una combination key ottenuta da informazioni prodotte dai due.
Per prima cosa le due unità generano ciascuno un numero casuale.
L’unità A produce il numero casuale LK_RAND_A, mentre B, LK_RAND_B.
Come secondo passo entrambi utilizzano l’algoritmo E₂₁, a cui danno in input il proprio numero casuale generato e il proprio indirizzo Bluetooth, BD_ADDR.
Gli output prodotti dall’algoritmo per i due dispositivi sono rispettivamente:
 
        LK_K_A = E₂₁ (LK_RAND_A, BD_ADDR_A),
 
        LK_K_B = E₂₁ (LK_RAND_B, BD_ADDR_B).
 
Questi numeri rappresentano il contributo dei due dispositivi alla generazione della combination key.
I due numeri casuali precedentemente generati sono scambiati in modo sicuro sul link trasmettendo di essi lo XOR bit a bit con l’attuale link key, K.
Perciò, A invierà a B:
 
        K Å LK_RAND_A,
 
mentre B invierà ad A:

        K Å LK_RAND_B.
 
Chiaramente, se questo tipo di chiave è prodotta durante la fase di inizializzazione, allora K=K_init.
 
Una volta che i numeri casuali sono stati mutuamente scambiati, ogni unità ricalcola il contributo alla generazione della chiave, dell’altro dispositivo.
Questo è possibile, perché ogni unità conosce l’indirizzo Bluetooth dell’altro dispositivo e può ottenere il numero casuale generato da quest'ultimo, effettuando lo XOR bit a bit tra il valore ricevuto e la chiave K associata al link.
 
A calcolerà:
 
        LK_K_B = E₂₁ (LK_RAND_B, BD_ADDR_B),
 
mentre B:
 
        LK_K_A = E₂₁ (LK_RAND_A, BD_ADDR_A).
 
Alla fine i due dispositivi ottengono la combination key, K_AB, eseguendo lo XOR bit a bit di LK_K_A e LK_K_B.
 
        Combination key = LK_K_A Å LK_K_B.
 
Derivata la nuova combination key, le parti avvieranno una mutua autenticazione per confermare il successo della transazione.
Solo dopo che le parti sono sicure del successo nello scambio, provvederanno a scartare la precedente link key.
La figura mostra in dettaglio lo scambio di messaggi tra i due dispositivi coinvolti nella generazione della chiave.
 

3.5 Generazione master key 

Una master key è una chiave temporanea utilizzata per rimpiazzare la corrente link key, quando il master della piconet vuole trasmettere simultaneamente la stessa informazione a più dispositivi riceventi.
Per prima cosa il master crea una link key da due numeri casuali, RAND1 e RAND2, a 128 bit applicando l’algoritmo E₂₂.
 
K_master = E₂₂ (RAND1, RAND2, 16)

Chiaramente la chiave K_master prodotta è un numero casuale.
La ragione, per cui è utilizzato l'output dell'algoritmo E₂₂ e non direttamente un numero casuale, è per evitare potenziali problemi che possono insorgere da implementazioni scadenti di generatori pseudo-casuali nei dispositivi.
 
Creata la chiave K_master, il dispositivo master trasmette allo slave un terzo numero casuale, detto RAND.
Utilizzando l’algoritmo E₂₂ con la corrente link key e RAND come input, sia il master che lo slave calcolano un valore, detto overlay, OVL, a 128 bit.
Il master invia lo XOR bit a bit dell’overlay e la nuova link key, K_master, allo slave.
Lo slave conoscendo l’overlay, può così ricalcolare K_master effettuando lo XOR bit a bit del numero ricevuto e l'overlay calcolato.
Per confermare il successo di questa transazione, le unità eseguono una mutua autenticazione usando la nuova link key.
La procedura è ripetuta dal master per ogni slave che riceverà così la nuova link key.

I valori ACO prodotti durante l’autenticazione non rimpiazzano il corrente ACO, in quanto quest'ultimo è necessario al master per ricalcolare la chiave di cifratura quando deciderà di riutilizzare la precedente link key.

Dopo la distribuzione della master key, K_master, il master invia a tutti i dispositivi lo stesso numero casuale EN_RAND, con cui produrre la chiave K_C usata per la generazione della nuova encryption key.
La chiave  K_C è ottenuta da ciascun dispositivo, applicando l’algoritmo E₃.
 
        K_C = E₃ (K_master, EN_RAND, COF)
 
Il valore COF è derivato dall’indirizzo Bluetooth del master, BD_ADDR.

        COF = BD_ADDR U BD_ADDR

dove X U Y denota la concatenazione delle stringhe X e Y.
 
La figura mostra lo scambio di messaggi tra due dispositivi:

3.6 Encryption  

In Bluetooth, le informazioni utente sono protette cifrando prima della trasmissione il campo payload dei pacchetti, ovvero il campo che contiene le vere e proprie informazioni da trasmettere.
La cifratura è ottenuta per mezzo dello stream cipher E₀, risincronizzato per ogni nuovo payload trasmesso.
Questo stream cipher consiste sostanzialmente di 3 parti. La prima esegue l’inizializzazione, ovvero genera la chiave per il payload, la seconda genera i bit del key stream e la terza esegue la cifratura o la decifratura delle informazioni trasmesse come XOR bit a bit tra ogni bit del testo in chiaro/cifrato e ogni bit generato dal key stream generator.
 

Il payload key generator combina semplicemente i bit in input in un appropriato ordine e li shifta nei 4 LFSR del key stream generator. Maggiori dettagli dell'algoritmo sono specificati nel paragrafo 3.7.1.
 

3.6.1 Negoziazione della lunghezza della chiave di cifratura

Ogni dispositivo Bluetooth, che implementa il protocollo Baseband, ha bisogno di un parametro, L_max, che definisce la massima lunghezza, in ottetti, permessa ad una chiave di cifratura. 1≤L_max≤16.
Per ciascuna applicazione è definito un valore L_min, che rappresenta la dimensione minima consentita alla chiave di cifratura.
Prima della generazioni della chiave, i dispositivi devono negoziare la sua dimensione.
All’inizio della negoziazione il dispositivo master, M, suggerisce a quello slave, S, un valore L_sug(M). Inizialmente il valore L_max(M) è uguale a L_sug(M).
Se L_min(S) ≤ L_sug(M) e lo slave supporta la lunghezza suggerita, allora conferma la lunghezza al master, altrimenti gli suggerisce un valore L_sug(S)<L_sug(M). Questo valore dovrebbe essere uguale alla più grande delle lunghezze supportate, ma minore di quella suggerita dal master. A questo punto il master esegue gli stessi test visti per il dispositivo slave.
La procedura è iterata finché o si raggiunge un accordo o le parti riscontrano una impossibilità nel continuare.


3.7 Algoritmi

3.7.1 E₀

Ogni payload di un pacchetto è cifrato separatamente. 
L’algoritmo stream cipher E₀ prende in input:

• una chiave K_C a 128 bit usata per la generazione della vera e propria encryption key;
• i 48 bit dell’indirizzo Bluetooth del master;
• i 26 bit del clock sempre del master, CLK_26-1.
   

La chiave K_C è calcolata per mezzo dell’algoritmo E₃, dandogli in input la chiave associata attualmente al link, un valore COF (Ciphering OFfset) a 96 bit e un numero casuale a 128 bit, EN_RAND_A, scelto dal dispositivo master, A, e inviato da quest’ultimo in chiaro al dispositivo slave.
Per calcolare il valore COF esistono due modi a seconda del tipo di link key usata.
 

    X U Y := X concatenato Y

Ovvero, se la link key è una master key, allora il valore COF è ottenuto concatenando due volte l'indirizzo del master, altrimenti esso è settato al risultato ACO, ottenuto in fase di autenticazione dall'applicazione dell'algoritmo E₁.
Ogniqualvolta il link manager attiva la cifratura, avviene una esplicita chiamata all’algoritmo E₃ e l’encryption key è modificata. 

Nell’algoritmo E₀, la chiave K_C è modificata nella vera e propria encryption key K’_C.
Il clock è incrementato per ogni slot e l’algoritmo E₀ è reinizializzato all’inizio della trasmissione di ogni nuovo pacchetto. Avendo un valore di clock diverso, CLK_26-1, per ogni pacchetto trasmesso, il keystream prodotto è diverso.
L’algoritmo E₀ genera un keystream binario K_Cipher che è sommato modulo 2 ai dati da cifrare o da decifrare.
Come evidenzia la figura, cifratura e decifratura sono operazioni equivalenti.

La figura mostra la struttura dell’algoritmo.

Il sistema usa 4 Linear Feedback Shift Register (LFSR) il cui output è combinato da una macchina a stati finiti con 16 stati, detta summation combiner logic.

L’output prodotto da questa macchina è la key stream usata per la cifratura o la decifratura oppure in fase di inizializzazione è il valore  con cui sono inizializzati i registri.
 
I 4 Linear Feedback Shift Register (LSFR₁,….., LSFR₄) sono, rispettivamente, di lunghezza 25, 31, 33, 39 e i loro polinomi delle connessioni sono tutti primitivi e così definiti:

Denotiamo con x_tⁱ lo t-esimo bit in LSFR_i. 
Dalla quadrupla ottenuta a tempo t, x_t¹,..., x_t⁴, si deriva il valore y_t = x_t¹+…+ x_t⁴,
dove  y_t può avere valore 0,1, 2, 3 o 4, essendo risultato di una somma su interi.

L’output del summation generator, presente nell’algoritmo, è dato dalle seguenti equazioni:

dove T₁[.] e T₂[.] sono due biezioni sul campo GF(4).

Supponiamo che GF(4) sia generato dal polinomio irriducibile x² + x + 1 e a sia uno zero di questo polinomio in GF(4).

T₁ e T₂ sono così definite:

E’ possibile scrivere gli elementi di GF(4) come vettori binari.

e definire alternativamente T₁ e T₂:

3.7.1.1 Inizializzazione dei Linear Feedback Shift Register

Per poter utilizzare l’algoritmo è necessario per prima cosa inizializzare i 4 LFSR e i 4 bit contenuti nei registri c_t e c_t-1,che possono essere interpretati come gli stati di un automa a stati finiti.
I 132 bit iniziali, necessari all’inizializzazione di tutti registri del sistema, (128 per gli LFSR, e 4 per c_t e c_t-1) sono ottenuti dai parametri passati in input all’algoritmo e usando lo stesso generatore. In particolare essi sono ricavati dalla chiave K_C, dal numero casuale a 128 bit EN_RAND, dall’indirizzo Bluetooth a 48 bit del master e dal suo clock a 26 bit.
 
Denotiamo con X[i] lo i-esimo ottetto di una sequenza binaria X.
Definiamo il bit 0 di X come il bit LSB della sequenza.
Quindi il LSB di X[i] corrisponde al bit 8i della sequenza X, mentre il MSB di X[i] è il bit 8i+7 di X.

La figura illustra la struttura dei 4 LFSR.
 

I bit passati ai registri sono presi dai parametri di input nel seguente ordine (*) :

dove: 

        CL[0]_L = CL₃, ..., CL₀
        CL[0]_U = CL₇, ..., CL₄ 
 
Tutti i bit sono shiftati nei registri iniziando con il LSB. Ovvero per il terzo ottetto dell'indirizzo, ADR[2], prima è inserito ADR₁₆ e poi ADR₁₇. 
Inoltre CL₀ corrisponde a CLK₁, ..., CL₂₅ corrisponde a CLK₂₆.
Come si può osservare dalla figura x_tⁱ, i=1, ..., 4 sono presi dalle posizioni 24, 24, 32 e 32 rispettivamente di LFSR₁, LFSR₂, LFSR₃, LFSR₄ (considerando la posizione più a sinistra come 1).

E' da notare che l'attuale chiave K_C, ottenuta dall'algoritmo E₃, è lunga 128 bit, ma l'effettiva lunghezza dell'encryption key utilizzata in E₀ può variare da un minimo di 8 ad un massimo di 128 bit. 
In E₀ la lunghezza della chiave è ridotta da un'operazione modulo tra K_C ed un polinomio di grado opportuno.
La chiave di cifratura effettiva K’_C, di lunghezza L ottetti, con 1≤L≤16 è ottenuta dalla chiave K_C, in questo modo:

        K’_C(x) = g₂^(L)(x) (K_C(x) mod g₁^(L)(x))

dove g₁^(L)(x) è polinomio di grado 8L, mentre g₂^(L)(x) è di grado al più 128-8L.

I coefficienti dei due polinomi sono indicati nella seguente tabella in notazione esadecimale.

Vediamo in dettaglio i passi per inizializzare il sistema.

Finita la fase di inizializzazione, l'output del summation combiner è usato per la cifratura o la decifratura del payload da trattare.
Il primo bit usato per la cifratura o la decifratura è prodotto a tempo t=240 e il sistema continuerà a produrre in ogni istante successivo un bit per ogni bit del payload da cifrare o decifrare.
 

3.7.2 E₁

La funzione di autenticazione E₁ usa una versione migliorata del cifrario a blocchi SAFER-SK128, detta SAFER+, proposta dalla Cylink Corp. nel 1997 al NIST quale possibile Advanced Encryption Standard (AES). 
Denotiamo il cifrario a blocchi con A_r, che mappa input x, a 128 bit, su output t, a 128 bit, usando una chiave K a 128 bit.
 

A_r : {0, 1}¹²⁸ × {0, 1}¹²⁸ →  {0, 1}¹²⁸
 
(K, x) → t
 
La funzione E₁ è così definita:
 
E₁: {0, 1}¹²⁸ × {0, 1}¹²⁸ × {0, 1}⁴⁸ →  {0, 1}³² × {0, 1}⁹⁶
 
(K,  RAND,  address) → (SRES, ACO)
 
dove:     SRES = Hash(K, RAND, address, 6)[0, …, 3]; 

               Hash è una funzione hash con chiave, così definita:

               Hash: {0, 1}¹²⁸ × {0, 1}¹²⁸ × {0, 1}^8×L × {6, 12} → {0, 1}¹²⁸
 
               (K, I₁, I₂, L) → A’_r([ ], [E(I₂, L) +₁₆ (A_r (K, I₁) Å₁₆ I₁)])  
               
                +₁₆ := somma orientata ai byte mod 256 sui 16 byte di input
 

                Å₁₆ := XOR byte to byte sui 16 byte di input      

                E: {0, 1} ^8×L × {6, 12} →  {0, 1}^8×16
 
                (X[0, …, L-1], L) →  (X[i mod L)] per i = 0, …, 15
 
                è un’espansione della parola X a L ottetti in una parola a 128 bit.
 

La chiave è ottenuta dalla chiave K così:

La figura presenta un flowchart della struttura della funzione E₁.

Il parametro ACO (Authenticated Ciphering Offeset) è utilizzato dalla funzione E₃ per la generazione della chiave K_C, necessaria per la generazione dell'encryption key, ed è ottenuto dall’output della funzione hash prendendo i suoi 12 byte più significativi.
 
ACO = Hash(K,RAND, address, 6)[4, …, 15]
 
 
La funzione A_r consiste di un insieme di 8 round e di un meccanismo parallelo per la generazione delle sottochiavi K_p[j] da usare in ognuno di essi, con p=1,2, ..., 17.
In ciascun round sono utilizzate due sottochiavi di 16 ottetti.
La funzione dà in output un valore a 128 bit, prendendo in input un numero casuale e una chiave a 128 bit.
Una versione leggermente modificata di A_r è detta A’_r ed è caratterizzata per il fatto che l’input del round 1 è sommato all’input del round 3.
 
Le computazioni in ogni round sono una composizione di round key, sostituzioni, cifrature con la successiva chiave del round e Pseudo Trasformata di Hadarm.
Le computazioni effettuate in un round generico sono mostrate nella figura.

Le sottochiavi per i round r, r = 1, 2, ., 8 sono denotate:
 
K_2r-1 [j], K_2r[j] con  j = 0,1, …, 15.
Alla fine, dopo l’ultimo round, K₁₇[j] è applicata in modo simile alle chiavi di indice dispari.

Nella figura sopra sono evidenziate due S-BOX , e ed l, utilizzate per introdurre non linearità nell’algoritmo e così definite:
 
e, l : {0, …, 255} → {0, …, 255}
 
e : i → (45ⁱ mod 257)mod 256
 
l : i → j dove i=e(j)
 
 
La figura mostra come sono calcolate le sottochiavi necessarie nei vari round.

I vettori B₂, B₃, …, B₁₇ sono calcolati in accordo alla seguente equazione:

3.7.3 E₂

La chiave usata per l’autenticazione è ottenuta per mezzo della procedura E₂, la cui struttura è descritta nella seguente figura.

Come mostrato, sono previste due diverse modalità operative per la procedura.

Nel modo 1, la funzione E₂ produce una link key a 128 bit, prendendo in input un numero casuale a 128 bit, RAND, e un indirizzo Bluetooth a 48 bit. Questa modalità è utilizzata quando si creano unit key e combination key.

Nel modo 2, la funzione E₂, produce una link key di 128 ottetti, prendendo in input un numero casuale a 128 bit, RAND, e un PIN' a  L' ottetti.
Questo ultima modalità è usata per creare la chiave di inizializzazione ed ogniqualvolta non è creata una master key. Quando una initialization key è generata, il PIN del dispositivo è espanso con il BD_ADDR ottenendo il PIN' indicato nella figura. 
Per entrambe le modalità, l’algoritmo genera la chiave sfruttando la funzione crittografica A'_r.

Formalmente E₂, denotata E₂₁ per il modo 1, è così definita:
 
            E₂₁ : {0, 1}¹²⁸ × {0, 1}⁴⁸ → {0, 1}¹²⁸
 
            (RAND, address) → A’_r(X, Y)
 
dove per la modalità 1

           

Vediamo ora più in dettaglio come è strutturato l’algoritmo E₂ per la modalità 2, denotato E₂₂.

Sia L la lunghezza in ottetti del PIN scelto dall’utente. L’espansione usata è così definita:

            E₂₂: {0, 1}^8L’ × {0, 1}¹²⁸ × {1, 2, …, 16} →{0, 1}¹²⁸

            (PIN’, RAND, L’) → A’_r(X, Y)

dove:   
 

e

             L’ = min {16, L+6} è la lunghezza di PIN’ in ottetti.

3.7.4 E₃

La chiave di cifratura K_C usata dall’algoritmo E₀ è generata dall’algoritmo E₃, che è costruito sulla base della funzione A’_r.

Formalmente:

        E₃ : {0, 1}¹²⁸ × {0, 1}¹²⁸ × {0, 1}⁹⁶ → {0, 1}128
 
                (K, RAND, COF) → Hash (K, RAND, COF, 12)
 
                dove Hash è la stessa funzione hash usata in E₁.

La chiave prodotta è a 128 bit.

In E₀  prima dell’uso, la chiave di cifratura K_C è accorciata alla corretta lunghezza. Dettagli maggiori per tale operazione sono indicati nel paragrafo dedicato all'algoritmo E₀.

.

 

3.8 Attacchi alla sicurezza

3.8.1 Attacchi all'autenticazione
 
Per mezzo dell'autenticazione, due dispositivi possono verificare che entrambi condividono una stessa link key.  

Se la link key è una initialization key, allora l'unica informazione segreta usata nella sua generazione è il PIN. Questo codice normalmente è un parola chiave di 4 numeri decimali. Quindi sono possibili solo 10.000 valori diversi e un attacco di forza bruta è realizzabile a tutti gli effetti.
Se il PIN non è fornito ai dispositivi da un utente, perché, per esempio, troppo lungo, allora tra i due dispositivi è usato uno schema di accordo su una chiave come quello di Diffie-Hellmann. In questo caso, eventuali punti deboli vanno ricercati nel particolare metodo usato.


Diversi problemi possono sorgere se i dispositivi hanno una limitata capacità di memoria. Infatti, in una tale situazione, il dispositivo con limitata capacità usa la propria unit key come link key.
In questo scenario, se un dispositivo A comunica prima con un dispositivo B e poi con un altro C, e in entrambi i casi è usata come link key la unit key di A, allora i tre dispositivi usano la stessa chiave e possono impersonare uno qualunque dei tre ed intercettare la comunicazione tra gli altri due.
Se B vuole impersonare C, prima che tra A e C ci sia stato un contatto, allora deve stabilire una nuova comunicazione con A e usare in questa fase come link key, la unit key di A e come proprio indirizzo, l'indirizzo di C.
Diversamente se A e C stanno già comunicando, B avrà bisogno, per impersonare C, della chiave di cifratura usata dai due. Per costruirla saranno necessari la unit key di A (usata in questa situazione come link key), l'ACO generato nella procedura di autenticazione tra A e C e il numero casuale scambiato da i due per creare la chiave di cifratura.
Se B ha la unit key di A, allora può ottenere le informazioni necessarie per produrre il valore ACO e il numero casuale semplicemente intercettando tutte le trasmissioni iniziali tra A e C. Al dispositivo B resta solo da calcolare la sequenza dei salti di frequenza. 
 

3.8.2 Attacchi alla cifratura

Per riuscire a decifrare correttamente una comunicazione tra due dispositivi, un attaccante deve per prima cosa conoscere la chiave usata per la cifratura, la cui lunghezza può variare da 8 a 128 bit, in base al grado di sicurezza richiesto.
In genere, la lunghezza minima della chiave è stabilita dallo strato applicazione allo scopo di evitare che l'uso di una chiave troppo corta possa pregiudicare la sicurezza delle informazioni trasmesse.
Una volta che l'attaccante è entrato in possesso della chiave di cifratura non può automaticamente decifrare una trasmissione, deve infatti riuscire a sincronizzarsi con il clock del master, che è utilizzato anche nell'inizializzazione dello stream cipher E₀.
Dal momento che la sola informazione segreta su cui è calcolata la chiave di cifratura è la link key, perchè i numeri casuali sono sempre trasmessi in chiaro sul canale, la conoscenza della link key e l'intercettazione di tutte le trasmissioni durante la fase di autenticazione sono sufficienti per decifrare le informazioni scambiate dai dispositivi.

Un altro tipo di attacco sfrutta la debolezza introdotta da codici PIN troppi corti.
In genere la lunghezza dei PIN utilizzati è di 4 numeri decimali. Da qui, se un attaccante inizia ad intercettare le comunicazioni dal primo handshake, potrebbe con un attacco di forza bruta sul PIN, riuscire a dedurre tutti i parametri utilizzati per la generazione della chiave di inizializzazione K_init.

3.8.3 Attacchi alla comunicazione

Un primo attacco che si può compiere alla comunicazione è legato alla possibilità di riuscire a impersonare un altro dispositivo.
Il frame di un pacchetto Bluetooth può essere modificato in tre parti:

• i tre bit del member address;
• il bit di acknoledgement;
• gli otto bit dell'error check per l'header.

Modificando questi 3 campi di un pacchetto un attaccante può inviare un pacchetto ad un altro dispositivo impersonandone un terzo.

Altri comuni attacchi includono la possibilità di compiere intercettazioni e la modifica di bit.
Con uno scanner, se la chiamata è non cifrata l'attaccante può ascoltare tutta la trasmissione tra due dispositivi. Con la modifica di bit invece un attaccante non entra in possesso di alcuna informazione trasmessa da un altro dispositivo, ma è grado di impedire ad esso qualunque trasmissione di informazione.

Un altro possibile attacco in Bluetooth è un attacco di replay in cui un dispositivo attaccante registra una conversazione tra due dispositivi in un certo istante e la ritrasmette successivamente impersonando chi l'ha trasmessa.
Per esempio, se le informazioni trasmesse sono da un PDA, A, ad un router wireless, B, di una banca e riguardano una transazione bancaria, un attaccante potrebbe prendere una copia bit per bit dell'informazione inviata da A a B e reinviarla alla banca multiple volte portando quest'ultima a eseguire più volte la stessa operazione.
Per un attacco di questo tipo, l'attaccante deve essere, però, in grado di riuscire a registrare le informazioni trasmesse da A su tutti e 79 i canali utilizzati in Bluetooth.
In realtà un attacco di questo tipo è tutt'altro che semplice.
Per prima cosa le apparecchiature che permettono di monitorare contemporaneamente 79 canali sono poche diffuse, inoltre anche se l'attaccante disponesse di una registrazione parallela di tutti i canali gli resterebbe comunque il gravoso compito di stabilire in ogni slot su quale canale è avvenuta la trasmissione delle informazioni della transizione. 

 

3.8.4 Attacchi al canale

Sebbene un attacco ad uno schema di comunicazione, basato su salti di frequenza sia estremamente difficile, in Bluetooth è possibile trovare a tale riguardo punti deboli.
Le parti fondamentali di uno schema di comunicazione basato sui salti di frequenza sono:

• il clock;
• la capacità di trasmissione di un dispositivo in ogni direzione;
• il sistema di trasmissione radio.
   

Ogni dispositivo Bluetooth possiede un clock a 28 bit che non è mai né spento né modificato. La frequenza del clock è di 3.200 tick per secondo, cioè un tick si verifica ogni 312 msec che corrisponde ad un clock rate di 3.2 KHz. L'accuratezza del clock normalmente è di ±20 parti per milione (ppm), ma scende a ± 250 ppm se il dispositivo è in modalità a bassa potenza. 

Un attaccante usando un laser a bassa energia (LEL) o impulsi elettromagnetici (EMP) può disturbare il clock del dispositivo rendendo impossibile sia la trasmissione che la ricezione di informazioni.
Entrambi gli attacchi sono estremamente rari e i rischi ad essi legati sono abbastanza limitati.

I dispositivi che operano in reti wireless sono capaci di trasmettere informazioni in ogni direzione.
Le potenzialità offerte da una propagazione in ogni direzione è anche un punto di debolezza dei sistemi che la utilizzano. Infatti, se da un lato essa permette ad un dispositivo di trasmettere in modo semplice informazioni ad altri dispositivi, dall'altra presenta lo svantaggio di estendere anche il campo d'azione di un attaccante.
Come si sa le onde radio si propagano oltre le porte, le pareti, le finestre degli edifici e danno di conseguenza la possibilità ad un attaccante di intercettare trasmissioni, acquisire informazioni sulla rete rimanendo a debita distanza dalla rete anche per molto tempo.
Contromisure per questo tipo di attacco si basano sull'imporre limitazioni alla potenza di trasmissione dei dispositivi oppure a porre limiti fisici tra la rete e un potenziale attaccante.


Interferenze agli schemi di gestione della potenza di trasmissione possono compromettere il funzionamento del modulo per la selezione della frequenza usata (FSM Frequency Selection Module), con conseguente interessamento di tutte le funzioni della piconet.
Dispositivi in uno stato connesso possono modificare la potenza di trasmissione nella piconet, per un certo link e chiedere al dispositivo all'altro capo del collegamento di modificare la propria potenza di trasmissione in base alla qualità del link di comunicazione.
Se un attaccante è in grado di danneggiare o disturbare il sistema di gestione della potenza di uno qualunque dei dispositivi, allora può porre la piconet in uno stato di caos.
Senza la corretta potenza il FSM non può operare correttamente e il sistema di salto della frequenza è ostacolato o degradato nelle sue funzioni. 

 

3.9 Vulnerabilità in Bluetooth

Per valutare il grado di sicurezza offerto da reti Buetooth, è possibile utilizzare a tale scopo la tecnica VERDICT  (Validation Exposure Randomness Deallocation Improper Conditions Taxonomy) con la quale è possibile scoprire le vulnerabilità presenti in un sistema e quindi risolverle nella progettazione dei dispositivi. 
Questa tecnica valuta un sistema, analizzandone quattro caratteristiche fondamentali:

• convalida;
• esposizione;
• casualità;
• deallocazione.

La convalida di un codice garantisce che nessuna operazione in un sistema possa portare ad un buffer overflow. A tale scopo vanno controllate tutte le condizioni critiche ed i particolari input che si possono ricevere. 
L'esposizione permette ad un sistema la rivelazione dei dispositivi presenti in una rete.  Un'esposizione impropria può essere sfruttata da un attaccante per agire impropriamente in una rete da una opportuna distanza di sicurezza.
La casualità è un altra importante caratteristica per i computer e per i protocolli di sicurezza, in quanto numeri casuali sono spesso utilizzati nella generazione di chiavi e sono parte integrante di molti schemi di sicurezza. Per tale motivo, i numeri casuali dovrebbero essere sempre generati da semi sufficientemente casuali.
La deallocazione è un aspetto importante della sicurezza. Un sistema deve essere sempre in grado di deallocare le risorse impegnate in precedenti utilizzi.
 

3.9.1 Convalida impropria

La maggior parte delle vulnerabilità presenti sia in reti tradizionali che wireless è causata dalla presenza di convalida impropria. Vediamo in dettaglio a tale riguardo le vulnerabilità presenti in Bluetooth.

1. Convalida degli indirizzi dei dispositivi. Un dispositivo Bluetooth è identificato univocamente da un indirizzo a 48 bit. Il suo formato è simile a quello degli indirizzi IEEE 802.3 ed a quelli usati nelle reti Ethernet. Se un utente è in grado di modificare l'indirizzo Bluetooth di un proprio dispositivo, allora è possibile avere in una piconet due dispositivi con uno stesso indirizzo e quindi un attacco simile all'IP spoofing.
2. Stati invalidi (Link Control). Per il link control di un dispositivo Bluetooth sono previsti 9 stati dei quali 2 sono stati principali: STANDBY e CONNECTION e 7 sono sottostati: page, page scan, inquiry, inquiry scan, master response, slave response, inquiry response. Per rappresentarli è sufficiente un bit per i due stati principali e 3 per gli altri 7. Chi progetta sistemi Bluetooth deve garantire che l'ottavo possibile stato, non associato ad alcun effettivo stato, non sia mai raggiunto e se è raggiunto per una qualche ragione, allora deve essere prevista anche una transizione in uno stato sicuro. Infatti, se ciò non accadesse, allora sarebbe possibile per un attaccante condurre il sistema in uno stato di instabilità sfruttandone i comportamenti errati.

3. Stati invalidi (Modalità di cifratura). Se un dispositivo slave ha ricevuto una master key, allora ci sono 3 possibili combinazioni per la cifratura.

In questo caso tutte le unità usano una stessa link key, la master key. E' possibile rappresentare i 3 stati con due bit anche se è possibile rappresentarne un quarto. Il quarto stato non dovrebbe mai essere raggiunto, perché in esso tutto il traffico broadcast è cifrato prima della trasmissione, ma quello point-to-point è inviato sul link in chiaro. 
 

4. Chiavi di cifratura.  Secondo la specifica Bluetooth il dispositivo master di una piconet non può usare differenti chiavi di cifratura per messaggi broadcast e unicast. Il master può indicare a vari dispositivi slave di usare una comune link key e quindi indirettamente di usare una comune chiave di cifratura. Questo può rendere possibile l'ascolto delle trasmissioni di tutti i dispositivi.

3.9.2 Esposizione impropria

Nel protocollo Bluetooth sono presenti due esposizioni improprie. La prima riguarda la non segretezza della link key, la seconda la possibilità per un dispositivo di passare dal ruolo di master a quello di slave di una piconet.

4. Non segretezza della link key.  Vedi paragrafo 3.8.1
5. Switching Master-Slave. La seconda vulnerabilità è legata alla capacità di un dispositivo di compiere lo switching (MS switching) dal ruolo di master al ruolo di slave. Ci sono tre situazioni in cui è necessaria una tale operazione. La prima si ha quando un'unità compie il paging sul dispositivo master di un'esistente piconet, perché vuole entrare a fare parte di tale rete. Per definizione l'unità che esegue l'operazione di paging è il master di una particolare piconet, composta dallo stesso dispositivo e dal master coinvolto. La seconda situazione si ha quando un dispositivo vuole creare una nuova piconet di cui esso è master e il corrente master sia suo slave. Questo caso comporta per il master di una piconet un doppio ruolo; master della sua piconet e slave di un'altra. La terza situazione riguarda la possibilità per un dispositivo slave di riuscire a prendere il controllo completo di un'esistente piconet. Una tale operazione comporta per tutti gli slave il passaggio alla nuova piconet, quindi notevole spreco di tempo nella sicronizzazione di tutti gli slave. Una possibile alternativa è sfruttare le informazioni di timing del vecchio master. La vulnerabilità introdotta dall'operazione di switching è legata al blocco della cifratura di qualunque trasmissione ogniqualvolta un MS switching è avviato. Ciò significa, che se dei dispositivi stanno ancora trasmettendo al master della piconet, mentre un dispositivo attaccante si presenta come un dispositivo, che vuole prendere possesso della corrente piconet, questo sarà in grado di ascoltare tutto il traffico sulla rete per tutto il tempo richiesto dal master per trasferire le informazioni di sincronizzazione.  
    

3.9.3 Casualità impropria

Come già detto nella sezione 3, in Bluetooth l'unica richiesta per i numeri casuali è che essi siano non repeteating e randomly generated. A tale scopo i progettisti hardware dovrebbero garantire che i semi utilizzati nella generazione di numeri casuali siano sufficientemente casuali. 
Una vulnerabilità legata ai numeri casuali è dovuta al trasferimento in chiaro di numeri casuali usati nella generazione di chiavi e in procedure di autenticazione.
 

3.9.4 Deallocazione impropria

La deallocazione impropria di risorse utilizzate in precedenza può agevolare un attaccante in successivi attacchi. 
Consideriamo il caso dell' autenticazione dopo la cifratura. Il comando HCI Authentication Requested è usato per tentare di autenticare un dispositivo remoto associato con uno specificato Connection Handle. Un Connection Handle è un identificatore a 12 bit che è usato per indirizzare unicamente una connessione dati/voce da un dispositivo Bluetooth ad un altro. Un Connection Handle può essere immaginato come un identificatore che identifica un canale che connette due dispositivi Bluetooth. Purtroppo o il master o lo slave potrebbero non pubblicizzare tale comando con un Connection Handle corrispondente ad un link cifrato.  
Nel caso di fallimento nell'autenticazione, l'Host Controller o il Link Manager potrebbero non eliminare automaticamente il link con un'operazione di Disconnect. Da qui un attaccante potrebbe non autenticarsi dopo un attacco di spoofing su un link cifrato ed essere agevolato nell'attacco.