1.1 Modalità di funzionamento

Transcript

1 1.1 Modalità di funzionamento Nel seguito saranno analizzate le differenti modalità di funzionamento di un dispositivo Bluetooth e le procedure che un dispositivo può svolgere all interno di una rete. Come si vedrà nel seguito, le procedure di localizzazione e di connessione, sono particolarmente critiche per la sicurezza dell intera rete. Le modalità di funzionamento, che interessano da vicino gli aspetti della sicurezza, sono le seguenti: Inquiry procedure: si tratta di una procedura utilizzata per localizzare eventuali dispositivi bluetooth presenti all interno dell area di copertura del segnale radio (raggio di cella). E una procedura asimmetrica: un dispositivo (inquiry device) esegue la ricerca inviando alcuni pacchetti di inquiry request per localizzare i dispositivi nelle vicinanze. Un dispositivo che può essere raggiunto da una inquiry request, prende il nome di discoverable device, e periodicamente ascolta e risponde alle inquiry requests. Paging procedure: e una procedura asimmetrica con cui un dispositivo invita un altro dispositivo bluetooth a partecipare alla sottorete, e ad instaurare una connessione. Il dispositivo con il quale si vuole instaurare una connessione deve essere stato precedentemente localizzato con successo. Connected mode: quando due dispositivi hanno instaurato con successo una connessione, esiste un canale fisico della rete e dei collegamenti logici tra le unità, attraverso i quali possono scambiare dati. Sniff mode: modalità di funzionamento a basso consumo, in cui un dispositivo slave si attiva per la ricezione di messaggi provenienti dall entità master solo ad intervalli prefissati.

2 Hold mode: modalità di funzionamento a basso consumo, in cui un dispositivo slave non comunica per un certo intervallo temporale. Park mode: modalità di funzionamento a basso consumo energetico in cui un dispositivo slave si parcheggia fino alla ricezione di un particolare pacchetto. Queste modalità di funzionamento sono relative ad una singola rete: un dispositivo che partecipa a più sottoreti, può assumere ruoli differenti e differenti modalità di funzionamento. 1.2 Specifiche del Livello Link Manager I livelli Link Manager di due dispositivi Bluetooth, collegati mediante un unità di trasporto logico ACL, comunicano con il protocollo del livello Link Manager (LMP: link manager protocol). Il protocollo è costituito da una serie di messaggi, trasportati su di un collegamento logico ACL-C, che sono utilizzati per controllare e negoziare gli aspetti che riguardano l operazione di connessione (hand shaking) di due dispositivi Bluetooth. I collegamenti logici ACL-C non garantiscono un tempo di consegna o di riscontro di un pacchetto: per ovviare a cio, le procedure del livello LMP durante la fase di sincronizzazione di due dispositivi trasmettono anche un parametro relativo al clock dei dispositivi. Ad ogni LMP-PDU è assegnato un opcode, di 7 o 15 bits, il quale identifica univocamente le differenti tipologie di PDU.

3 LSB MSB T I D OpCode PAYLOAD 7 bits Figura 1: LMP-PDU con un opcode di 7 bits. Quando i bits dell opcode assumono un valore compreso tra 124 e 127, e utilizzato un byte del payload per avere un opcode di 15 bits. LSB MSB T I D Escape OpCode Extended OpCode PAYLOAD 7 bits 8 bits Figura 2: LMP-PDU con un opcode di 15 bits. Altri parametri presenti nella PDU sono posizionati nel payload immediatamente dopo l opcode. I messaggi LMP vengono trasmessi utilizzando i pacchetti DM1, inoltre se vengono utilizzati collegamenti SCO e la lunghezza del payload è minore di 9 byte possono essere usati i pacchetti DV. Il protocollo LMP opera utilizzando le trattative. Una trattativa è una serie di messaggi connessi scambiati per ottenere uno specifico scopo. Tutte le PDU che fanno parte della stessa trattativa assumono il medesimo valore dell identificatore di transizione, indicato nel campo TID della LMP-PDU.

4 Il TID assume il valore 0 se la transizione viene iniziata dal dispositivo master, assume il valore 1 se la trattativa viene iniziata dal dispositivo slave. Il timeout, che regola il tempo in cui un dispositivo attende la risposta ad un pacchetto inviato, assume il valore di 30s superato il quale il dispositivo assume che la procedura sia fallita. Questo parametro e rilevante ai fini della sicurezza. Un valore di timeout troppo lungo consente infatti ad un utente non autorizzato di fare piu prove di trasmissione, prima che venga considerata fallita l intera procedura. E necessario ricordare che un attacco di questo tipo (Denial of Service) porta alla saturazione della unita e in pratica, al suo non funzionamento. I messaggi generali di risposta definiti nello standard Bluetooth sono quattro, e sono utilizzati come risposta alle altre PDU in differenti tipologie di procedure. Questi messaggi, che si differenziano dal contenuto della PDU, vengono illustrati nella seguente tabella. Nelle specifiche Bluetooth sono indicate le funzioni che il Link Manager può gestire, alcune di queste funzioni devono essere obbligatoriamente gestite dal link manager, mentre il supporto delle rimanti funzioni è del tutto opzionale. Lo standard Bluetooth prevede che in un architettura di rete in cui operi un elemento Bluetooth siano previste e regolate le seguenti procedure: Procedure di controllo della connessione: instaurazione, abbattimento, controllo della potenza, AFH, classificazione del canale, supervisione del collegamento, cambio della qualità che regola il data rete (CQDDR), QoS, parametri dello schema di paging, controllo pacchetti multi-slot. Procedure di Sicurezza: autenticazione, cambio link key, cambio tipologia link key, criptazione, negoziazione dimensioni chiave criptazione.

5 Procedure di richiesta informazioni: accuratezza temporale, clock offset, versione LMP, funzioni supportate, richiesta del nome. Procedure per lo scambio di ruoli dei dispositivi: slot offset, scambio ruoli. Procedure riguardanti le differenti modalità operative: hold mode, park state, sniff mode. Procedure riguardanti le unità di trasporto logico: unità trasporto logico SCO, unità trasporto logico esco. NUMERO FUNZIONE BYTE BIT 0 Pacchetto 3 slot Pacchetto 5 slot Criptazione Slot offset Timing accuracy Scambio Ruoli Hold mode Sniff mode Modalità Park Richiesta controllo potenza CQDDR Collegamento SCO Pacchetto HV Pacchetto HV µ-law log dati sincroni A-law log dati sincroni CVSD dati sincroni Negoziazioni parametri paging Controllo potenza Dati sincroni trasparenti Controllo flusso lag (LSB) 2 4

6 21 Controllo flusso lag (bit centrale) Controllo flusso lag (MSB) Criptazione traffico broadcast Riservato Riservato Riservato Enhanced inquiry scan Inquiry scan interlacciato Page scan interlacciato RSSI con risultati inquiry Collegamento SCO extended Pacchetto EV Pacchetto EV Riservato Capacita AFH slave Classificazione AFH slave Riservato Riservato Capacita AFH master Classificazione AFH master Funzioni extended 7 7 Tabella 1: Definizione feature mask. E importante considerare che ognuna delle procedure menzionate, può essere fonte di insicurezza del sistema. Nel seguito si analizzeranno nel dettaglio le procedure riguardanti le fasi di instaurazione di una connessione. Esaminiamo ora, la procedura che il Link Manager utilizza per stabilire una connessione tra due dispositivi Bluetooth. Dopo aver effettuato la procedura di paging, il protocollo LMP esegue alcune procedure per richiedere il clock offset, la versione del LMP, le funzioni supportate, richiesta del nome del dispositivo e la richiesta sulla procedura di detach.

7 In seguito, un dispositivo, che desidera creare una connessione che coinvolga gli stati superiori al LM, invia una LMP_host_connection_req PDU al dispositivo con il quale vuole connettersi. Questo dispositivo può accettare o rifiutare la connessione inviando un LMP_accepted PDU o una LMP_not_accepted PDU. Se il dispositivo slave necessita di eseguire l operazione d inversione dei ruoli prima di stabilire la connessione, risponde alla LMP_host_connection_req PDU inviando LMP_slot_offset PDU e la LMP_switch_req PDU. Se la LMP_host_connection_req PDU viene accetta prima di stabilire la connessione è possibile utilizzare le procedure di autenticazione e criptazione. Una volta che i due dispositivi inviano la LMP_setup_complete PDU, la connessione si considera stabilita con successo. Master Slave Procedura page livello BASEBAND Procedure LMP richiesta clock offset, versione LMP, funzioni supportate, nome del dispositivo e detach LMP_host_connection_req LMP_accepted / LMP_not_accepted Procedure LMP autenticazione e criptazione LMP_setup_complete LMP_setup_complete Figura 3: instaurazione di una connessione. Una connessione Bluetooth può essere interrotta in qualsiasi momento sia dal dispositivo master che da dispositivo slave. Il LM del dispositivo che vuole interrompere la connessione effettua i seguenti passi:

8 1. inizialmente interrompe (pause) il traffico dati scambiato su di un collegamento ACL-U; 2. quando il traffico e bloccato, il dispositivo invia un particolare messaggio (LMP_detach PDU) avviando nel contempo un timer; 3. se la risposta alla PDU arriva prima dello scadere del timer la connessione verrà interrotta immediatamente, altrimenti la connessione verrà comunque interrotta allo scadere del timer. 1.3 Specifiche dell interfaccia HCI L interfaccia HCI (host controller interface) fornisce un unico metodo d interfacciamento per accedere alle funzionalita proprie del Bluetooth Controller. L interfaccia HCI permette la comunicazione tra i più bassi strati del software, che costituiscono il Bluetooth Host, ed il Baseband Controller ed il Link Manager i quali si trovano nel Bluetooth Controller; per poter svolgere questo ruolo l HCI è costituito da una parte software, HCI Driver, e da una parte firmware, HCI firmware. Tra lo strato HCI Driver e lo strato HCI Firmware possono esistere diversi strati intermedi chiamati Host Controller Transport Layer che permettono il trasferimento dei dati.

9 Figura 4: Strati protocollari del HCI. Nel caso del varco elettronico, oggetto del presente studio, normalmente ci saranno contemporaneamente attivi tre dispositivi Bluetooth: il varco o il bastone, collegati con il palmare (primo dispositivo interessato attivamente per la gestione della sicurezza, e il punto di accesso rilevamento (punto fondamentale perche porta verso il mondo esterno). Nel seguito si prenderanno in esame due dispositivi Bluetooth attori attivi di una microrete basata su Bluetooth. Tipologia di Comando o Evento Eventi Generici Setup Dispositivo Descrizione Eventi dovuti a comandi multipli o eventi che possono accadere in qualsiasi momento. Comandi utilizzati per far funzionare il Controller in uno stato noto.

10 Controllo di Flusso Controller Controllo del flusso di dati tra Host e Controller Informazioni Controller Permettono all Host di scoprire informazioni riguardanti il dispositivo. Configurazione Controller Permettono la configurazione dei parametri globali Rivelamento Dispositivo Comandi ed eventi che permettono di rilevare altri dispositivi raggiungibili nelle vicinanze. Setup Connessione Comandi ed eventi che permettono la connessione con un altro dispositivo. Informazioni Dispositivo Remoto Eventi e comandi che permettono di scoprire la configurazione di un dispositivo remoto. Connessioni Sincrone Eventi e Comandi che permettono di creare connessioni di tipo sincrono. Stato delle Connessioni Permettono la configurazione di un collegamento. Struttura Rete Permettono di conoscere e riconfigurare la struttura di una rete. Qualità del Servizio Permette di configurare i parametri relativi alla qualità del servizio. Collegamenti Fisici Permettono la configurazione dei collegamenti fisici. Controllo Flusso Host Comandi ed eventi che permettono il controllo del flusso d informazioni verso l Host. Informazioni Collegamento Permette di conoscere le informazioni riguardanti un collegamento. Autenticazione e Criptazione Permettono l autenticazione di un dispositivo e la criptazione dei dati trasmessi sul collegamento. Prove Comandi ed eventi che permettono di far funzionare il dispositivo nella modalità di test. Durante una comunicazione, all interno di uno dei due dispositivi, l HCI Driver del Bluetooth Host trasferisce dati e comandi con il HCI Firmware nell hardware del dispositivo Bluetooth, mentre l Host Control Transport Layer Driver permette la comunicazione tra i due strati del HCI. Indipendentemente dall Host Control Transport Layer utilizzato, l host Bluetooth riceverà delle notifiche, di tipo asincrono, degli eventi HCI.

11 Gli eventi HCI sono utilizzati per segnalare all Host il verificarsi di un evento; per poter risalire alla natura dell evento, l host deve esaminare il pacchetto che viene associato alla notifica dell evento. Oltre alla notifica degli eventi nell HCI sono utilizzati una serie di comandi per utilizzare le funzioni del Bluetooth Controller. Questi comandi sono raggruppati in base alla funzione svolta, in gruppi logici. Tabella 2: Comandi ed eventi dell'interfaccia HCI. Per l esecuzione di un comando s impiega una quantità di tempo variabile, in base alla tipologia del comando, per essere completato; il risultato di un comando viene comunicato all Host attraverso un evento. Nei pacchetti HCI, se non viene diversamente specificato, i dati sono nel formato Little Endian binario ed esadecimale. I parametri sotto forma di vettore vengono specificati utilizzando la notazione: ParameterA[i]. Il numero gli elementi in un parametro rappresentato sotto forma di vettore non è fisso; mentre i comandi ed i parametri non rappresentati con l utilizzo di vettore hanno una dimensione fissa. Le specifiche di Bluetooth definiscono quattro tipologie di pacchetti HCI: Pacchetto HCI Command: viene utilizzato per inviare comandi provenienti dall Host, al Controller Bluetooth. Il controller deve essere in grado di ricevere un pacchetto comandi HCI che contenga fino a 255 bytes di dati, escluso l header del pacchetto comandi HCI.

12 OpCode Parameter Parameter 0 OCF OGF Total Length Parameter 1 Parameter Parameter N-1 Parameter N Figura 5: Pacchetto HCI Command. Attraverso i 2 bytes del campo opcode è possibile identificare univocamente la tipologia di comando; questo campo risulta diviso in due sottocampi: OCF (OpCode Command Field)e OGF (OpCode Group Field). Il campo OGF è riservato per i comandi specifici del produttore. Nel campo Parameter Total Length è indicata la lunghezza in ottetti di tutti i parametri contenuti nel pacchetto. Nel campo Parameter 0-N sono riportati i parametri associati ad uno specifico comando. Ogni comando richiede uno specifico numero di parametri la cui lunghezza varia in funzione del comando. Pacchetto HCI ACL Data: Viene utilizzato per scambiare dati tra l Host ed il Controller.

13 Connection Handle PB Flag BC Flag Data Total Length Data Figura 6: Pacchetto HCI ACL Data. Il campo Connection Handle di 12 bits viene utilizzato per la trasmissione di un pacchetto dati o di un segmento. Il campo PB Flag (Packet_Boundary_Flag) è composto da 2 bits: la combinazione di valori dei bits 00 e 11 è riservata per usi futuri, mentre con la combinazione 01 s indica un pacchetto che contiene un frammento di un messaggio di livello superiore; con la combinazione 10 s indica il primo pacchetto di un messaggio di livello superiore. Il campo BC Flag (Broadcast_Flag) di 2 bits viene utilizzato per indicare i dispositivi a cui è rivolto un messaggio broadcast. Nel campo Data Total Length viene indicata la lunghezza in ottetti dei dati trasportati nel pacchetto Connection Handle Reserved Data Total Length DATA Figura 7: Pacchetto HCI Synchrounous Data. Pacchetto HCI Event: viene utilizzato dal controller per notificare all Host l accadimento di un evento.

14 Event Code Parameter Total Length Event Parameter 0 Event Parameter 1 Event Parameter 2 Event Parameter 3 Event Parameter N-1 Event Parameter N Figura 8: Pacchetto HCI Event. Il campo Event Code di 1 byte è utilizzato per identificare univocamente le differenti tipologie di eventi. Nel campo Parameter Total Length è indicata la lunghezza in ottetti di tutti i parametri contenuti nel pacchetto. Nel campo Event Parameter 0-N vengono riportati i parametri associati ad uno specifico evento. 1.4 Specifiche del livello L2CAP Lo strato L2CAP (logical link control and adaptation protocol) fornisce servizi dati orientati e/o non orientati alla connessione, permettendo la ricezione e la trasmissione, con gli strati protocollari superiori, di pacchetti dati di lunghezza massima di 64 kilobytes.

15 Lo strato L2CAP svolge le funzioni di multiplexing, segmentazione e riassemblaggio, controllo di flusso, controllo degli errori e gestione di gruppi di collegamenti. Nella prossima figura vengono illustrati i blocchi architetturali che compongo lo strato L2CAP. Livelli Superiori Data Data Data Dati Controllo CONTROLLO SDU Segmentazione ( Riassemblaggio ) Livello L2CAP Resource Manager Ritrasmissione e Controllo Flusso Channel Manager Incapsulamento e Programmazione COMANDI PDU Frammentazione ( Ricombinazione ) FRAMMENTI Livelli Inferiori Figura 9: Blocchi architetturali del livello L2CAP. Il Channel Manager svolge le funzioni del piano di controllo; e responsabile delle segnalazioni interne al livello, e delle segnalazioni con il livello superiore ed inferiore. Il livello L2CAP gestisce il multiplexing poiché il protocollo Baseband non supporta nessun campo di tipo Type, con il quale è possibile identificare i protocolli di livello superiore che vengono multiplati su di esso. La funzione di segmentazione e quella di riassemblaggio permettono, ad ogni singola applicazione che utilizza il livello L2CAP, di controllare la lunghezza delle trame di trasporto.

16 Lo strato fornisce anche il servizio di controllo di flusso: quando diversi flussi dati sono trasportati sul medesimo collegamento logico L2CAP, utilizzando canali L2CAP separati, ogni canale può richiedere un controllo di flusso diverso. Per quanto riguarda il servizio di controllo d errore, esso è opzionale. E stato comunque previsto per soddisfare le richieste delle applicazioni che, per poter funzionare correttamente, richiedono tassi di errori inferiori rispetto a quelli che possono essere offerti dal livello Baseband. La funzione di ritrasmissione, anch essa opzionale, permette di evitare la perdita dei pacchetti trasportati. Le funzioni di frammentazione e ricombinazione, sono necessarie poiché gli strati più bassi dell architettura hanno una capacità di trasporto limitata e possono richiedere che la dimensione dei frammenti sia differente da quella creata della segmentazione L2CAP. Lo strato protocollare L2CAP non gestisce il trasporto di dati audio o il trasporto trasparente di dati sincroni, destinati alle unità di trasporto logico SCO ed esco; inoltre lo strato non supporta una tipologia di canale multicast affidabile. La comunicazione tra i livelli L2CAP di due dispositivi Bluetooth avviene attraverso dei canali logici chiamati canali L2CAP. I canali L2CAP vengono mappati con collegamenti logici L2CAP, i quali a loro volta utilizzano le unità di trasporto logico ACL. Ogni punto terminale di un canale L2CAP viene identificato da un channel identifier (CID). Le specifiche Bluetooth definiscono tre tipologie di canali L2CAP: Canali orientati alla connessione. Canali non orientati alla connessione. Canali di segnalazione.

17 Inoltre le specifiche Bluetooth prevedono che ogni canale L2CAP possa operare in tre diverse modalità di funzionamento, in base alle richieste degli strati protocollari superiori. Modalità di funzionamento Le modalità di funzionamento sono: Modalità base L2CAP. Modalità di controllo del flusso. Modalità di ritrasmissione. Le modalità vengono selezionate durante la procedura di configurazione del canale L2CAP; come default viene assunta la modalità di funzionamento base, in cui sono disponibile i servizi basilari del livello L2CAP. Nelle modalità di controllo del flusso e di ritrasmissione, le PDU scambiate tra i dispositivi sono numerate e riscontrate. Il numero di sequenza permette di controllare la memorizzazione delle PDU. Il controllo di flusso è effettuato dimensionando opportunamente le finestra di TX e attraverso il metodo del Token Bucket. Nella modalità di controllo del flusso non avviene nessuna ritrasmissione delle PDU, ma è possibile scoprire, e segnalare, le PDU che vengono perdute. Nella modalità di funzionamento in ritrasmissione, per assicurare che tutte le PDU siano consegnate al destinatario, viene utilizzato un timer, se non si riceve un riscontro prima dello scadere del timer la PDU viene considerata non riscontrata e va ritrasmessa. Per gestire le ritrasmissione viene utilizza un meccanismo Go_Back_N, che permette la semplificazione del meccanismo di ritrasmissione e di ridurre i requisiti di buffering.

18 In base alla tipologia, ed in base alla modalità di funzionamento, del canale L2CAP le specifiche Bluetooth prevedono l utilizzo di differenti formati di pacchetti L2CAP. Canale orientato alla connessione in modalità di funzionamento base L2CAP: La L2CAP PDU, nella modalità di funzionamento L2CAP base e su di un canale orientato alla connessione, viene indicato col nome di B-frame. Il campo Length di 16 bits, indica le dimensione in ottetti delle informazioni trasportate nel payload; la lunghezza massima del payload può essere di ottetti; inoltre la verifica della lunghezza del payload, in ricezione permette un semplice test d integrità dei dati ricevuti. Nel campo Channel ID di 16 bits viene indicato il CID che identifica il punto terminale del canale a cui è destinato il pacchetto. Il campo Information payload ha una dimensione compresa tra 0 e ottetti; e contiene l informazione ricevuta dai livelli superiori o destinata ai livelli superiori. Header L2CAP Base Length Channel ID Information payload LSB 16 bits 16 bits MSB Figura 10: Formato B-frame PDU. Canale non orientato alla connessione in modalità di funzionamento base L2CAP: La L2CAP PDU, nella modalità di funzionamento L2CAP base e su di un canale non orientato alla connessione, viene indicato col nome di G-frame.

19 Length Channel ID PSM Information payload LSB 16 bits 16 bits 16 bits MSB Figura 11: Formato G-frame PDU. Il campo Length di 16 bits, indica le dimensioni in ottetti del campo PSM e delle informazioni trasportate nel payload. Il campo Channel ID di 16 bits assume il valore 0x0002, che viene riservato al traffico non orientato alla connessione. Il campo Protocol / Sevice Multiplexer (PSM) ha una dimensione minima di 2 ottetti, i calori che può assumere si dividono in due categorie: la prima categoria di valori viene assegnata dal Bluetooth SIG e serve ad indicare i protocolli; la seconda categoria di valori viene assegnata dinamicamente e viene usata in congiunzione al Service Discovery Protocol (SDP), questa categoria di valori può essere utilizzata per supportare delle implementazioni multiple di un particolare protocollo. Il campo Information payload ha una dimensione compresa tra 0 e ottetti; e contiene l informazione che deve essere distribuita a tutti i membri della micro rete. Canale orientato alla connessione in modalità di funzionamento di ritrasmissione \ controllo del flusso: Le specifiche prevedono l utilizzo di due tipologie di L2CAP PDU: la prima tipologia prende il nome di I-frame (information frames) e viene utilizzata per il trasferimento d informazioni tra due entità L2CAP; la seconda tipologia

20 prende il nome di S-frame (supervisory frames) e viene utilizzata per riscontrare le PDU I-frame e per chiederne la ritrasmissione. S-frame Length Channel ID Control FCS LSB 16 bits 16 bits 16 bits 16 bits MSB I-frame Length Channel ID Control L2CAP SDU Length Information payload LSB 16 bits 16 bits 16 bits 0-16 bits 16 bits FCS MSB Figura 12: Formato S-frame ed I-frame PDU. Il campo Length di 16 bits, indica le dimensione in ottetti dell intera L2CAP PDU, escluso il campo Length ed il campo Channel ID. Nel campo Channel ID di 16 bits viene indicato il CID. Il contenuto del campo Control, di 16 bits, differisce per le due diverse tipologie di PDU. Con X viene indicato un bit riservato, che deve essere codificato con uno 0. Frame I S SAR X X BIT ReqSeq R TxSeq 0 ReqSeq R X X X S 0 1 Figura 13: Formato del campo Control.

21 Il sottocampo TxSeq (Send Sequence Number) di 6 bits viene utilizzato per numerare ciascun I-frame, permettendo la numerazione e ritrasmissione. Il sottocampo ReqSeq (Receive Sequence Number) di 6 bits serve per riscontrare un I-frame, inoltre può essere utilizzato per indicare quale PDU debba essere ritrasmessa. Il sottocampo costituito dal bit R (Retrasmission Disable) viene utilizzato per implementare il controllo del flusso. Con il sottocampo SAR (Segmentation and Reassembly) di due bit, s indica se una PDU è segmentata, e per le PDU segmentate questo sottocampo indica la parte del frammento. Con il sottocampo S (Supervisory function) di 2 bit, si distingue tra due tipologie di PDU, una in cui il ricevitore è pronto, ed una in cui una PDU non è stata trasmessa correttamente. Il campo L2CAP SDU length costituito da 2 ottetti, è presente solamente nelle PDU I-frame che trasportano il primo segmento di una SDU, questo campo viene utilizzato per indicare la lunghezza in ottetti dell intera SDU. Il campo Information payload contiene l informazione trasportata nella PDU. Il campo FCS (Frame Check Sequence) costituito da 2 ottetti, contiene la sequenza di controllo del frame, la quale viene costruita utilizzando il polinomio generatore g(d)=d 16 + D 15 + D Canale di segnalazione: Su questo canale vengono scambiate L2CAP PDU che contengono dei comandi di segnalazione, queste PDU vengono indicate con il nome di C-

22 frame. Su di un singolo C-frame possono essere inviati anche comandi multipli. Tutti i comandi hanno una struttura basata su richieste e risposte. Length Channel ID Commands LSB 16 bits 16 bits MSB Figura 24: Formato del C-frame. Tutti i comandi vengono inviati utilizzando, nel campo Channel ID, il valore riservato di CID 0x0001. LSB Ottetto 0 Ottetto 1 Ottetto 2 Ottetto 3 MSB Code Identifier Length Data Figura 35: Formato del campo Command. Il campo Commands è costituito da diversi sottocampi. Con il sottocampo Code, delle dimensioni di 1 ottetto, s identifica il tipo di comando. Il sottocampo Identifier, delle dimensioni di 1 ottetto, assume il medesimo valore nella richiesta e nella risposta di un comando, alle richieste e risposte di comandi diversi viene assegnato un valore diverso di questo sottocampo. Con il sottocampo Length, delle dimensioni di 2 ottetti, vengono indicate le dimensioni in ottetti del sottocampo Data.

23 Il sottocampo Data può avere una lunghezza variabile. 1.5 Specifiche del SDP Il Service Discovery Protocol (SDP) fornisce, alle applicazioni, un mezzo per scoprire quali sono i servizi disponibili, e permette di determinare quale sono le caratteristiche dei servizi disponibili. Questo tipo di protocollo è particolarmente utile nell ambito Bluetooth, poiché questa tecnologia lavora con dispositivi mobili, e quindi anche i servizi disponibili variano dinamicamente in base alla vicinanza dei dispositivi che possono erogare un servizio. Lo scopo di questo protocollo è permettere ad un utente Bluetooth di verificare la disponibilità di uno specifico servizio, oppure di ricercare specifiche categorie di servizi di cui si necessita, o scoprire tutti i possibili servizi disponibili senza nessuna conoscenza a priori di essi. Inoltre il protocollo SDP fornisce un mezzo, attraverso l utilizzo di opportuni meccanismi, per entrare a conoscenza della disponibilità di un nuovo servizio, non appena esso diventa disponibile, e per entrare a conoscenza della non disponibilità di un servizio a causa dell irraggiungibilità radio di un dispositivo. Il Protocollo SDP si basa su di un modello richiesta/risposta, dove ogni operazione è costituita da PDU di richiesta e una PDU di risposta.

24 Applicazione Utente Applicazione Servente SDP Utente Richiesta SDP Risposta SDP SDP Servente Figura 46: Schema d'interazione SDP tra utente e servente. Il protocollo SDP fornisce un meccanismo per scoprire i servizi disponibili ed i loro attributi, ma non fornisce un meccanismo per utilizzare questi servizi; quindi un utente, che decide di utilizzare un servizio, deve aprire un apposita connessione con il servente per utilizzare il servizio. I serventi SDP che sono raggiungibili da un utente SDP possono cambiare dinamicamente, in base alla distanze radio dei dispositivi; all interno di ciascun server si trova una lista di servizi disponibili con le caratteristiche ad essi associati. Tutte le informazioni riguardanti un servizio, messo a disposizione da un server SDP, sono contenute in un singolo archivio,che prende il nome di service record.

25 Service Record Attributo Servizio 1 Attributo Servizio 2 Attributo Servizio 3 Attributo Servizio N Figura17: Service Record. All interno del dispositivo servente ciascun service record viene univocamente identificato attraverso un numero di 32 bits, che viene chiamato handle. Una volta che un utente instaura una connessione con il servente,non ha modo di sapere se un service record viene rimosso dal servente; è quindi importante che il servente non assegni l handle assegnato ad un vecchio service record ad uno nuovo finché vi sono connessioni attive con degli utenti. Il service record contiene tutti gli attributi che caratterizzano un servizio; ciascun attributo è composto da due campi informativi: il campo ID Attributo ed il campo Valore Attributo. Il campo ID Attributo è un intero di 16 bits, che serve a distinguere ciascun attributo servizio dagli altri attributi servizio all interno del service record. Il campo Valore Attributo è di lunghezza variabile, il suo significato viene a dipendere dal ID Attributo ad esso associato e dalla classe di servizio a cui appartiene il service record. Attributo Servizio ID Attributo Valore Attributo Figura18 : Attributo Servizio.

26 Ogni servizio rappresenta un esempio di una classe di servizio. Le specifiche di una classe di servizio definiscono tutti i possibili ID Attributo, per una classe di servizio, ed assegnano un significato all attributo associato a ciascun ID Attributo. Tutti i servizi che appartengono alla medesima classe di servizio assegnano il medesimo significato a ciascun particolare ID Attributo. A ciascuna classe di servizio viene inoltre assegnato un identificatore unico. Questo identificatore della classe di servizio viene indicato con la sigla UUID; questo identificatore, universalmente unico, è costituito da un numero di 128 bits. Normalmente un utente ricerca un servizio, che offre caratteristiche desiderate, nei dispositivi serventi attraverso l utilizzo dell identificare UUID dello specifico servizio; tuttavia in alcune circostanze un utente desidera conoscere tutti i servizi, che sono descritti attraverso i server records di un server SDP, senza nessuna conoscenza a priori delle caratteristiche dei servizi, questa operazione prende il nome di browsing. Un utente che esegue l operazione di browsing, in un server SDP ottiene la lista dei servizi offerti, che vengono rappresentati secondo una struttura ad albero basata sulla divisione in classi di servizi. Figura 19: Esempio di Browsing.

27 Esaminiamo la struttura della SDP PDU. Header Parameters PDU ID Transaction ID Parameter Length Parameter 1 Parameter 2 Parameter N 1 Byte 2 Bytes 2 Bytes Parameter Length Bytes Figura 205: SDP PDU. La PDU è costituita da un intestazione (header) seguita da parametri specifici della PDU (parameters). L intestazione contiene tre campi: Il campo contenente l identificativo della PDU (PDU ID). Il campo contenente l identificativo di transizione, che identifica univocamente la PDU di richiesta e risposta di una transizione SDP (transaction ID). Il campo contenente la lunghezza in bytes di tutti i paramet