La plupart des produits BLE Tag sont livrés comme de simples beacons publicitaires : le téléphone les scanne, lit la charge utile et s’en va. Ce modèle échoue dès que tu veux configurer l’étiquette, la faire sonner, pousser un firmware ou lire des capteurs tamponnés. Il te faut alors une vraie connexion GATT, et la gestion de la connexion devient le point dur. Cet article dépasse le marketing : appairage, liaison, LE Secure Connections, conception GATT, paramètres de connexion et les bizarreries iOS/Android qui cassent vraiment les livraisons.
Appairage vs Liaison
L’appairage est la poignée de main live qui génère la LTK. La liaison (bonding) est l’appairage plus la persistance de cette LTK (et IRK/CSRK) en flash, pour reprendre le chiffrement sans réappairage. Une étiquette qui appaire sans lier force un réappairage à chaque relance de l’app, ce qui est inacceptable pour un traceur grand public.
Legacy Pairing vs LE Secure Connections
Legacy Pairing (4.0 à 4.1) dérive la LTK d’une clé temporaire et reste vulnérable à l’écoute passive : capture une fois l’échange et tu obtiens la LTK. LE Secure Connections (4.2+) négocie d’abord un ECDH P-256, si bien que la LTK ne passe jamais sur l’air. Pour toute étiquette portant position ou identité, Secure Connections est la seule base acceptable.
| Caractéristique | Legacy Pairing | LE Secure Connections |
|---|---|---|
| Accord de clé | Temporary Key | ECDH P-256 |
| Écoute passive | LTK récupérable | Sûr |
| MITM (Numeric Comparison) | Non | Oui |
| Version min. | 4.0 | 4.2 |
Modèles d’association
Le modèle d’association décide comment l’utilisateur confirme le lien. Just Works est silencieux mais sans protection MITM, correct pour un traceur mais risqué pour une serrure. Numeric Comparison (Secure Connections uniquement) affiche un code à 6 chiffres des deux côtés.
| Modèle | Action utilisateur | MITM | Usage typique |
|---|---|---|---|
| Just Works | Aucune | Non | Traceurs, faible valeur |
| Passkey Entry | 6 chiffres | Oui | Config industriel |
| Numeric Comparison | Confirmer code | Oui | Étiquettes sûres |
| OOB | Tap/NFC | Oui | Provisioning |
Hiérarchie des clés
Après l’appairage, la pile stocke : LTK (chiffrement de lien 128 bits), IRK (adresse privée résolvable), CSRK (écritures signées authentifiées) et graines ER/DHK. L’IRK est ce qui permet à un téléphone appairé de reconnaître l’étiquette après rotation d’adresse.
Conception du service GATT
Un GATT pragmatique pour traceur :
| UUID | Service / Caract. | Propriété |
|---|---|---|
| 0x180F | Battery Service | Read |
| 0x180A | Device Information | Read |
| 0x2A06 | Alert Level (Find Me) | Write |
| Fxxx | Config (intervalle, TX power) | Read/Write |
| Fxxx | Bouton / dernier appui | Notify |
| Fxxx | Firmware revision | Read |
Garde la caractéristique de config protégée derrière la liaison ; sinon, n’importe qui à portée réécrit le TX power et annule les limites de portée.
Paramètres de connexion
Trois valeurs gouvernent toute connexion :
- Connection Interval : 7.5 ms à 4000 ms. iOS limite le minimum négocié à ~20 ms en pratique.
- Slave Latency : 0 à 499 événements que l’étiquette peut sauter.
- Supervision Timeout : 100 ms à 32000 ms ; doit dépasser (1 + latency) x interval x 2.
Profil basse conso : interval 1000 ms, latency 9, timeout 11 s signifie que l’étiquette saute 9 événements sur 10, se réveillant environ une fois par seconde. Le courant moyen passe de la plage mA (connecté, 30 ms) à la dizaine de uA.
Reconnexion sans vider la batterie
Les étiquettes purement publicitaires émettent une adresse statique ou aléatoire ; un téléphone appairé ne les retrouve pas fiablement après rotation d’adresse. Utilise une Resolvable Private Address générée depuis l’IRK, annonce avec White List active et laisse le téléphone appairé résoudre la RPA. La taille de la White List sur les SoC courants est de 8 à 32 entrées, suffisant pour un téléphone et quelques gateways.
Bizarreries iOS / Android qui cassent les livraisons
- iOS : le scan en arrière-plan de CoreBluetooth ne matche que les services dont l’UUID figure dans l’advertisement. Si l’étiquette masque l’UUID de service, l’app ne se réveille pas en arrière-plan. Les intervalles < ~20 ms sont rejetés. ANCS exige une connexion appairée pour délivrer les alertes.
- Android 12+ : BLUETOOTH_CONNECT et BLUETOOTH_SCAN sont des permissions runtime ; sans elles le scan renvoie vide. Il faut gérer l’invite « détecter appareils à proximité » et la limitation du scan arrière-plan (~1/h pour les apps en cache).
- Les deux : garder la connexion en continu brûle le CR2032 en quelques jours. Connecte à la demande, puis déconnecte.
Compromis de puissance
| Mode | Courant typique | Durée CR2032 |
|---|---|---|
| Publicité seule (200 ms) | ~5 à 15 uA | 1 à 3 ans |
| Connecté, 30 ms | rafales 1 à 3 mA | jours à semaines |
| Connecté à la demande | dizaine de uA | 1 à 2 ans |
Règle : par défaut publicité seule. Ouvre une connexion uniquement pour config, alerte ou OTA, puis ferme-la.
Pièges
- Appairage sans liaison conduit à une boucle de réappairage à chaque lancement.
- Legacy Pairing sur étiquette de position fuit une LTK récupérable.
- Adresse aléatoire statique sans IRK signifie que le téléphone appairé ne trouve pas l’étiquette.
- Garder la connexion « au cas où » tue la batterie.
- Masquer l’UUID de service sous iOS bloque le réveil arrière-plan.
Bien gérer la connexion est ce qui sépare une étiquette de démo d’un produit réellement livrable. Pour les designs de référence qui implémentent déjà Secure Connections et un GATT sain, voir notre ligne de module Bluetooth et la famille plus large BLE Tag.
