Mon réseau d’entreprise

12.6 Le Bluetooth

Précédent   Suivant

Les périphériques Bluetooth sont maintenant très répandus. La plupart des téléphones gsm, beaucoup d’ordinateurs portables, des boîtiers gps, des oreillettes… Ces équipements numériques sont dotés de capacités réseaux. La pile protocolaire Bluetooth permet donc de mettre en place des réseaux personnels. D’autres réseaux personnels voient le jour, comme zigbee, mais ne sont pas répandus dans le grand public.

Le réseau Bluetooth permet non seulement de synchroniser le téléphone portable et l’ordinateur mais aussi de nombreuses autres applications simples, comme le contrôle du vérouillage d’un ordinateur, ou plus complexes, comme la communication téléphonique à travers l’interface Bluetooth.

Le monde de l’embarqué, de l’internet des objets relance les développemnets autour du Bluetooth.

12.6.1 Technologie Bluetooth

Le standard Bluetooth est défini par l’IEEE (Working Group for Wireless Personal Area Networks (WPANs)) sous les numéros 802.15.X (X compris entre 1 et 4).

Les éléments fondamentaux d’un produit Bluetooth sont définis dans les deux premières couches protocolaires, la couche radio et la couche bande de base, qui assurent, en particulier, le contrôle du saut de fréquence et la synchronisation des horloges.

La couche radio utilise la bande de fréquence ISM (2,4GHz, la même que le WiFi). Deux modulations sont définies : une modulation obligatoire qui utilise une modulation de fréquence binaire et une modulation optionnelle de phase (PSK à 4 et 8 symboles). La communication utilise des sauts de fréquences sur 79 canaux et un canal est réservé pour la recherche (scan).

Une version simplifiée de la pile protocolaire est présentée dans la table 12.6.1.

L’interface HCI sépare la partie matérielle de la partie logicielle. Les communications sont facilement enregistrables sur l’un des périphériques de la communication et il est aisé de l’analyser, par exemple avec wireshark.

Au niveau applicatif, il est possible d’utiliser les commandes Hayes pour piloter la liaison numérique ; le protocole OBEX gère les échanges d’objets (comme les messages, les relevés d’appels, les contacts…) ; la couche IP fournit un support standard pour les applications ; et bien sûr, il est possible d’utiliser les supports de téléphonie ou audio.

12.6.1.1 La couche physique

Le Bluetooth est géré au niveau matériel et utilise la bande de fréquence ISM* (Industrial, Scientific and Medical) 2,4 GHz dont l’exploitation ne nécessite pas de licence. Cette bande de fréquences est comprise entre 2 400 et 2 483,5 MHz.

Deux modulations sont définies : une modulation obligatoire utilise une modulation de fréquence binaire pour minimiser la complexité de l’émetteur ; une modulation optionnelle utilise une modulation de phase (PSK à 4 et 8 symboles). La rapidité de modulation est de 1 Mbaud pour toutes les modulations. La transmission duplex utilise une division temporelle. Les 79 canaux RF sont numérotés de 0 à 78 et séparés par 1 MHz en commençant par 2 402 MHz. La transmission utilise les sauts de fréquence. La période est de 625 s, ce qui permet 1 600 sauts par seconde.

12.6.1.2 La couche HCI

Cette couche fournit une méthode uniforme pour accéder aux couches matérielles. Son rôle de séparation permet un développement indépendant du matériel et du logiciel.

L’outil hcitool permet de manipuler la couche hci. Les premières commandes sont :

dev

liste les interfaces Bluetooth de l’ordinateur :

hcitool dev
Devices:
         hci0   00:15:83:41:4A:6D

Le périphérique Bluetooth a une adresse similaire à une adresse Ethernet. Les trois premiers octets identifient le fabricant.

scan

permet de chercher les interfaces en mode découvrables. Si un équipement est découvrable (téléphone ou station), alors la commande va l’afficher :

# hcitool scan
Scanning ...
        00:15:83:41:9F:7D      chip

name

permet d’obtenir le nom d’un périphérique dont l’adresse est connue :

# hcitool name 00:15:83:41:9F:7D
chip

inq

fournit, pour chaque périphérique distant la classe et l’offset temporel. La classe permet de savoir les caractéristiques du périphérique.

# hcitool inq
Inquiring ...
        00:15:83:41:9F:7D      clock offset: 0x7aa1    class: 0x000104

L’interface bluetooth se manipule comme une interface réseau. Pour cela, l’outil est hciconfig. Il permet d’activer ou de désactiver une interface, de la passer en mode découvrable :

sans commande

affiche la configuration courante :

# hciconfig hci0
hci0:   Type: Primary Bus: USB
        BD Address: 00:15:83:41:49:E2 ACL MTU: 310:10    SCO MTU: 64:8
        UP RUNNING
        RX bytes:1088 acl:0 sco:0 events:57 errors:0
        TX bytes:2661 acl:0 sco:0 commands:56 errors:0

L’interface est active.

down

désactive l’interface :

root@belial:~# hciconfig hci0 down
root@belial:~# hciconfig hci0
hci0:   Type: Primary Bus: USB
        BD Address: 00:15:83:41:49:E2 ACL MTU: 310:10    SCO MTU: 64:8
        DOWN
        RX bytes:1088 acl:0 sco:0 events:57 errors:0
        TX bytes:2661 acl:0 sco:0 commands:56 errors:0

up

la remet en service ;

piscan

autorise la découverte :

# hciconfig hci0 piscan

noscan

désactive le mode découverte :

hciconfig hci0 noscan

La capture de l’adresse bluetooth fournit un point d’entrée à un potentiel attaquant. Cette adresse lui fournit le nom du fabricant et potentiellement le modèle de l’appareil. Avec les systèmes privatifs, il suffit alors d’avoir une attaque disponible dans son catalogue.

Le mode découvrable et l’activation du périphérique par le système sont indépendants. Il est donc possible d’avoir un périphérique désactivé qui répond aux requêtes de détections.

La commande hcidump permet d’enregistrer la communication entre le périphérique bluetooth et le système d’exploitation. Pas les communications entre deux périphériques. Ainsi, par exemple, les requêtes de découvertes sont répondues directement par le périphérique. Le système d’exploitation n’est pas informé de la découverte.

Le système d’exploitation ne peut pas détecter les requètes.

Voici une capture, enregistrée dans un ficher puis relu.

root@goblin:~# hcidump -w /tmp/hci.cap
HCI sniffer - Bluetooth packet analyzer ver 5.43
btsnoop version: 1 datalink type: 1002
device: hci0 snap_len: 1500 filter: 0x0
root@goblin:~# hcidump -r /tmp/hci.cap
HCI sniffer - Bluetooth packet analyzer ver 5.50
btsnoop version: 1 datalink type: 1002
< HCI Command: Inquiry (0x01|0x0001) plen 5
    lap 0x9e8b33 len 8 num 0
> HCI Event: Command Status (0x0f) plen 4
    Inquiry (0x01|0x0001) status 0x00 ncmd 1
> HCI Event: Extended Inquiry Result (0x2f) plen 255
    bdaddr 00:15:83:41:49:E2 mode 1 clkoffset 0x625b class 0x000104 rssi -68
    Complete local name: 'belial'
    TX power level: 4
    Unknown type 0x10 with 8 bytes data
    Complete service classes: 0x1800 0x1801 0x110e 0x110c
> HCI Event: Extended Inquiry Result (0x2f) plen 255
    bdaddr 00:15:83:41:49:E2 mode 1 clkoffset 0x625b class 0x000104 rssi -70
    Complete local name: 'belial'
    TX power level: 4
    Unknown type 0x10 with 8 bytes data
    Complete service classes: 0x1800 0x1801 0x110e 0x110c

Le format du fichier de capture est défini par la librairie pcap sur le site de tcpdum. La capture peut être faite par un logiciel (tcpdump, tshark, hcidump ou wireshark) et étudié par un autre.

Le bluetooth est très utilisé dans l’embarqué. Tous ces logiciels ne seront pas forcément disponibles. Il ne faut donc négliger aucun.

Il est donc possible d’utiliser tcpdump, tshark ou wireshark directement sur le périphérique bluetooth. Pour tshark, par exemple, la commande tshark --list-interfaces va renvoyer la liste des périphériques de captures, dont bluetooth0, par exemple. Pour wireshark, la liste des interfaces de capture est présentée lors de l’ouverture de la fenêtre dans la figure 12.11.

 tshark -i bluetooth0
Capturing on 'bluetooth0'
1   0.000000         host ? controller   HCI_CMD 4 Sent Reset
2   0.127290   controller ? host         HCI_EVT 7 Rcvd Command
Complete (Reset)
...

12.6.1.3 La couche L2CAP

La couche L2CAP (Logical Link Control & Adaptation Protocol) fournit les services de multiplexage des protocoles de niveau supérieur et la segmentation et le réassemblage des paquets ainsi que le transport des informations de qualité de service. Les protocoles de haut niveau peuvent ainsi transmettre et recevoir des paquets jusqu’à 64 Ko. Elle autorise un contrôle de flux par canal de communication. La couche L2CAP utilise des canaux logiques.

Il est possible d’utiliser des outils simples permettant d’utiliser directement cette couche. La commande l2ping, du paquet bluez, permet de vérifier la disponibilité d’un équipement. Les équipements Bluetooth disposent d’une adresse MAC qui identifie l’équipement.

La commande l2ping permet de vérifier la présence de l’interface distante.

12.6.2 Contrôleur Bluetooth

Pour être plus complet en Bluetooth, une nouvelle commande a fait son apparition : bluetoothctl. C’est une alternative aux commandes précédentes (hciconfig et hcitool). Quand on lance la commande, elle affiche l’adresse bluetooth du controleur physique et une liste de partenaires connus (ici, probablement vide). C’est une commande interactive. Elle a son intérêt mais souffre de ne pas pouvoir être intégrée dans des scripts automatiques.

Sur chaque PC, il faut regarder dans quel état se trouve le périphérique (show), activer le mode découvrable (discoverable on et lancer le scan (scan on) :

stud@laurel:~$ bluetoothctl
[NEW] Controller 00:15:83:41:4A:6D laurel [default]
[NEW] Device 00:15:83:41:A0:47 hardy
[bluetooth]# show
Controller 00:15:83:41:4A:6D
        Name: laurel
        Alias: laurel
        Class: 0x000104
        Powered: yes
...
        Modalias: usb:v1D6Bp0246d052B
        Discovering: no
[bluetooth]# discoverable on
Changing discoverable on succeeded
[CHG] Controller 00:15:83:41:4A:6D Discoverable: yes
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:15:83:41:4A:6D Discovering: yes
[NEW] Device 00:15:83:41:A0:47 hardy
[bluetooth]# quit
[DEL] Controller 00:15:83:41:4A:6D laurel [default]
stud@laurel:~$

La commande show montre dans quel état se trouve l’adaptateur. Il faut qu’il soit en fonctionnement (Powered: yes). Lors de la phase de découverte, il va afficher les évènements reçus et indiquer une nouveauté (NEW), un changement (CHG) ou une disparition (DEL). La disparition d’un périphérique distant signifie qu’il n’a plus été vu depuis un certain temps. La commande devices permet de résumer les équipements distants découverts.

12.6.3 Appariement

Pour certains protocoles bluetooth, il faut apparier les équipements. Entre deux PC, il faut lancer l’interface bluetoothctl. Nous allons sur chaque PC, activer l’agent bluetooth, passer en mode découvrable et autoriser l’appariement, puis lancer le scan. Enfin, nous lancerons la demande pair :

[bluetooth]# agent on
Agent registered
[bluetooth]# default-agent
Default agent request successful
[bluetooth]# discoverable on
Changing discoverable on succeeded
[CHG] Controller 00:15:83:41:9F:7D Discoverable: yes
[bluetooth]# pairable on
Changing pairable on succeeded
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:15:83:41:9F:7D Discovering: yes
[CHG] Device 00:15:83:41:9E:FC Name: dale
[bluetooth]# pair 00:15:83:41:9E:FC
Attempting to pair with 00:15:83:41:9E:FC
Failed to pair: org.bluez.Error.ConnectionAttemptFailed
[bluetooth]# pair 00:15:83:41:9E:FC
Attempting to pair with 00:15:83:41:9E:FC
[CHG] Device 00:15:83:41:9E:FC Connected: yes
Request confirmation
[agent] Confirm passkey 724293 (yes/no): yes
...
[CHG] Device 00:15:83:41:9E:FC Paired: yes
Pairing successful
[CHG] Device 00:15:83:41:9E:FC ServicesResolved: no
[CHG] Device 00:15:83:41:9E:FC Connected: no

Nous avons mis la clef bluetooth dans un état correct. Certains éléments sont peut-être déjà en place et donc, sont dépendant de lhistoire récente. Après un certain temps, l’un des deux Pcs finit par voir l’autre. Il est alors possible de tenter la connexion. Il faut parfois plusieurs tentatives pour que l’appariement soit réussi. Selon le contexte, il suffit de voir le même nombre sur les deux équipements et répondre yes ou d’entrer le nombre sur un des équipements.

Pour apparier un téléphone Lineageos (Android devrait être similaire), il y a deux méthodes : apparier depuis le téléphone ou depuis le PC. Depuis le PC, il faut que celui-ci connaisse le téléphone (commande devices puis faire pair btaddr. Dans l’autre sens, il faut aller dans la partie bluetooth, faire une recherche (le PC doit être en mode découvrable), puis tenter un appariement : figure 12.12.

[bluetooth]# discoverable on
Changing discoverable on succeeded
[CHG] Controller 00:15:83:41:4A:6D Discoverable: yes
[bluetooth]# agent on
Agent registered
[bluetooth]# default-agent
Default agent request successful
[NEW] Device 42:AF:30:03:AF:42 alf6
Request confirmation
[agent] Confirm passkey 993539 (yes/no): yes
[CHG] Device 42:AF:30:03:AF:42 Modalias: bluetooth:v0...
[CHG] Device 42:AF:30:03:AF:42 UUIDs: 000...

Ceci montre la session sur le PC. Le téléphone devant trouver le PC, celui ci doit être découvrable. L’agent doit être actif. Ensuite, il faut lancer la demande sur le téléphone. Éventuellement, il faut essayer plusieurs fois. Dans cet exemple, il faut écrire yes sur le PC et cliquer sur le téléphone.

12.6.4 Les services

SDP signifie Service Discovery Protocol. Ce protocole permet à un appareil Bluetooth de rechercher d’autres appareils et d’identifier les services disponibles.

En Lançant la commande sdptool browse btaddr, les services offerts s’affichent.

$ sdptool browse $TELEPHONE
Browsing 42:AF:30:03:AF:42 ...
Service RecHandle: 0x10000
Service Class ID List:
  "Generic Attribute" (0x1801)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 31
  "ATT" (0x0007)
    uint16: 0x0001
    uint16: 0x0003

Service RecHandle: 0x10001
Service Class ID List:
  "Generic Access" (0x1800)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 31
  "ATT" (0x0007)
    uint16: 0x0014
    uint16: 0x001a

Service Name: Headset Gateway
Service RecHandle: 0x10003
Service Class ID List:
  "Headset Audio Gateway" (0x1112)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 2
Profile Descriptor List:
  "Headset" (0x1108)
    Version: 0x0102

Service Name: Handsfree Gateway
...

Service Name: AV Remote Control Target
...

Service Name: Android Network Access Point
...

Service Name: CrossWords
...

Service Name: SIM Access
...

Dans cet exemple, nous pouvons voir que le téléphone peut partager sa connexion réseau, utiliser un kit mail libre. Nous pouvons voir aussi que le jeu CrossWords a ajouté son propre service pour pouvoir jouer en réseau avec d’autres téléphones.

Les applications qui ouvrent des services réseaux offrent de nouveaux points d’accès aux brigands.

12.6.5 OBEX

OBEX signifie Object Exchange. Ce service permet de transférer des objets grâce à OBEX, protocole d’échange développé pour l’IrDA. C’est le protocole qui est utilisé par nautilus pour échanger des fichiers avec le téléphone ou d’autres applications comme obexfs. Malheureusement ce protocole est peu utilisé par les fabricants qui préfèrent contraindre le client a utiliser leur application.

12.6.5.1 OBEX push

Cherchez, avec la commande sdptool, le service OBJECT PUSH, cela doit ressembler à cela :

Service Name: OBEX OPP
Service RecHandle: 0x1000b
Service Class ID List:
  "OBEX Object Push" (0x1105)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 12
  "OBEX" (0x0008)
Profile Descriptor List:
  "OBEX Object Push" (0x1105)
    Version: 0x0100

Vérifiez le numéro du canal à utiliser, ici 12. Établissez la connexion rfcomm sur ce canal :

root@hermes:~# rfcomm bind 12 btaddr 12

Vous pouvez vérifier la connexion en utilisant la commande rfcomm -a.

Trouvez une image sur le PC, au besoin faites une capture d’écran ou sauvez une image de firefox. Nous allons utiliser ussp-push (au besoin, installez le) pour pousser le fichier du PC vers le téléphone.

root@hermes:~# ussp-push /dev/rfcomm12 foo.png bar.png
name=foo.png, size=12973
Connection established

Vous pouvez accepter la réception, puis vérifier que le fichier est bien arrivé. Vous pouvez alors couper la communication rfcomm (rfcomm release 12).

Pour l’envoi du mobile vers le PC, nous allons utiliser obexpushd :

obexpushd -n -B

Allez sur le téléphone, envoyez un fichier vers votre PC. Vérifiez la transmission.

12.6.5.2 Obex FTP

Vérifiez que le service obex ftp est disponible sur votre téléphone avec sdptool.

S’il n’est pas activé, utilisez la documentation de votre téléphone pour l’activer. Pour Android, Google ayant décidé de le retirer du système, il faut payer une application en argent ou par la pub. Allez dans le store, cherchez obex, installez Bluetooth File Transfert de Medieval software. Après l’avoir téléchargée, vous devez la lancer. Le service obex ftp devrait être actif. N’hésitez pas à supprimer l’application à la fin du TP.

Entrez la commande :

obexftp -b btaddr -l

Vous pouvez alors lister les répertoires et echanger des fichiers. Il est plus simple cependant de faire apparaître le contenu du téléphone directement sur votre système.

=> obexfs -b btaddr /tmp/obfs
=> ls /tmp/obfs
Clips vidéo/ Fichiers aud./ Icônes/ Sons/
Enreg./      Fich. reçus/ Photos/ Thèmes/

L’établissement de cette communication permet de monter le système de fichiers du téléphone sur l’ordinateur en utilisant le module fuse qui permet de monter des systèmes de fichiers dans la partie utilisateur.

Entrez la commande ls -lR /tmp/obfs, vous avez l’arborescence de votre téléphone.

Quel est le nom du répertoire des photos de votre téléphone ?

Quel est le nom du répertoire des sonneries de votre téléphone ?

Ajoutez une photo et une sonnerie, visualisez la photo sur votre téléphone, vérifiez que vous pouvez utiliser la sonnerie.

Note : vous avez des images et des fichiers sons dans /usr/share

Précédent   Suivant