Un Bluetooth Beacon est un haut-parleur dans une salle pleine de monde : il diffuse le meme paquet a tous ceux qui sont a portee, sans appairage et sans authentification par defaut. Cette ouverture est ce qui rend les beacons bon marche et faciles a deployer, mais elle signifie aussi que n’importe qui avec un telephone peut lire, cloner ou falsifier votre trafic de beacon. Cet article cartographie le modele de menace reel d’un Bluetooth Beacon et les controles d’ingenierie qui arretent vraiment un attaquant.
Pourquoi un beacon est expose par conception
Un beacon annonce pour etre entendu. Les paquets d’advertising sont lisibles par tout scanner, et la charge utile (UUID/Major/Minor iBeacon, namespace/instance Eddystone ou un MSD propre) est envoyee en clair sauf si vous la chiffrez expressement. Aucune cle n’est negociee a l’advertising, donc la radio ne distingue pas une passerelle legitime d’un telephone d’inconnu.
Le modele de menace
| Menace | Ce que fait l’attaquant | Ce que ca casse |
|---|---|---|
| Ecoute | Journalise l’advertising passivement | Vie privee, fuite de position |
| Usurpation | Emet un faux beacon avec vos ID | Fraude de presence, abus de declencheur |
| Replay | Capture un paquet valide, le rejoue | Illusion « toujours la » |
| MITM / fausse passerelle | Usurpe le lien montant | Injection, falsification |
Ecoute : le clair trahit la position
Une trame iBeacon standard porte un UUID fixe plus Major/Minor qui codent souvent etage, zone ou classe d’actif. Un attaquant dans le hall journalise les UUID et construit en une apres-midi une carte de vos zones. Mitigations : utilisez des ID opaques et rotatifs ; n’inserez jamais de donnees significatives dans les champs statiques ; gardez le vrai mapping cote serveur.
Usurpation : fausse presence
Comme l’ID du beacon est public, un attaquant emet le meme UUID/Major/Minor depuis un board a 10 dollars et votre systeme croit qu’un actif (ou un client) est la ou il n’est pas. Retail : faux evenements « fidelite presente ». Logistique : palettes fantomes. La solution est l’authenticite : le recepteur doit verifier cryptographiquement que le paquet vient d’un detenteur de cle, pas seulement que l’ID correspond.
Replay : capturer et rejouer
Le replay est l’attaque la plus simple et la plus facile a negliger. Un attaquant enregistre aujourd’hui un paquet valide et le rejoue la semaine prochaine pour pretendre que le beacon « est toujours la ». Une trame iBeacon brute n’a ni horodatage ni nonce, donc le recepteur ne distingue pas le vieux du neuf. Un horodatage signe le bat.
MITM et la fausse passerelle
Si votre beacon parle a une passerelle via un lien non chiffre, une fausse passerelle peut injecter ou modifier les lectures. Pareil si le lien passerelle-vers-nuage n’est pas authentifie. Chaque saut a besoin de sa propre integrite et, si la donnee est sensible, de confidentialite.
Controles cryptographiques qui marchent
Advertising chiffre. Mettez la charge utile significative dans un blob chiffre (AES-CCM sous LE Secure Connections ou une cle pre-partagee). La radio diffuse toujours, mais seuls les detenteurs de cle peuvent lire.
Beacons signes. Marquez chaque paquet d’une signature ECDSA sur la charge plus un horodatage. Le recepteur verifie avant de faire confiance :
def signer_beacon(charge, ts, cle_privee):
msg = charge + ts # ts = compteur grossier ou unix time
sig = ecdsa_sign(msg, cle_privee) # P-256 ou Ed25519
return charge + ts + sig
def verifier_beacon(annonce, cle_pub, fenetre):
charge, ts, sig = separer(annonce)
if maintenant() - ts > fenetre: # ex. 60 s
return REPLAY_DETECTE
return ecdsa_verifier(charge + ts, sig, cle_pub)ID volatils rotatifs. Refletez le modele de confidentialite des adresses privées resolubles : diffusez un ID rotatif derive de cle que seul votre serveur peut resoudre. Un espion voit un ID different toutes les quelques minutes et ne peut pas suivre.
Horodatage + nonce anti-replay. Un compteur monotone ou un horodatage grossier dans l’enveloppe signee rend chaque paquet unique et efemere.
Securite vs cout
| Schema | Confidentialite | Integrite | Resist. replay | Cout energie | Compatibilite |
|---|---|---|---|---|---|
| Clair | Aucune | Aucune | Aucune | Aucun | Universel |
| ID rotatif | Faible | Aucune | Partielle | Faible | Universel |
| Signe | Aucune | Forte | Oui (temps) | Moyen | Besoin verif. |
| Chiffre | Forte | Forte | Oui (nonce) | Haut | Besoin cle |
Provisionnement de cle et racine materielle
La signature n’est fiable que comme la cle privee. Stockez-la dans un secure element ou derivez-la d’un PUF pour qu’elle ne soit pas lisible depuis l’image firmware. C’est la meme discipline de root-of-trust que le secure boot : l’identite du beacon est gravee a l’usine, pas chargee du flash a l’execution.
Detection operationnelle
Memoire chiffree, surveillez l’air :
- Anomalie RSSI : un beacon qui lit soudain +20 dB plus fort suggere un usurpateur proche.
- Un meme ID depuis deux endroits a la fois : physiquement impossible – signalez.
- Liste blanche de passerelles : acceptez seulement les uplinks de certificats connus.
Normes sur lesquelles s’appuyer
Apple Find My et la spec multiplateforme Detecting Unwanted Location Trackers definissent des comportements anti-traque (alertes de separation, bip) a imiter pour les etiquettes grand public. Device Provisioning Protocol (DPP) donne un onboarding propre aux passerelles.
Checklist OEM
1. Decidez du modele de menace avant de choisir un schema – la plupart des deploiements ont besoin de signe, pas de chiffre.
2. Stockez les cles dans un secure element / PUF, jamais dans le flash applicatif.
3. Ajoutez horodatage ou compteur a chaque paquet ; verifiez la fenetre.
4. Faites tourner les ID publics selon un calendrier que le serveur resout.
5. Livrez un moyen de revoquer et re-cler une beacon compromise.
Un Bluetooth Beacon gagne la confiance comme tout le reste : en prouvant, a chaque paquet, qu’il est bien celui qu’il pretend etre.