Le déploiement de beacons dans des environnements de production introduit des surfaces d’attaque que de nombreux tutoriels de protocole BLE ignorent. Cet article analyse des menaces pratiques — spoofing d’adresse, écoute clandestine de paquets ADV et attaques par rejeu — et fournit des contre-mesures d’ingénierie avec des marges de sécurité quantitatives. Le public visé : ingénieurs RF et praticiens de la sécurité embarquée déployant des beacons dans des scénarios de vente au détail, industriels et de suivi d’actifs.

Modèle de menace : ce qu’un attaquant peut réellement faire

Le BLE est conçu pour la commodité basse consommation, pas pour des fortifications cryptographiques. Comprendre le paysage de menace réaliste est le point de départ de tout déploiement :

Type d’attaqueCoucheÉquipement requisDifficultéImpact
Spoofing d’adresse MACLink LayerDongle USB ($20) + hcitoolFaibleFaux rapports de présence
Sniffing de paquets ADVLink LayerUbertooth / nRF Sniffer ($50)Faible-MoyenSuivi de localisation, fuite d’ID d’actif
Attaque par rejeuApplicationCapture + réémissionMoyenEntrée non autorisée en zone
MitM (connexion)L2CAP2x dongles + commandes BT VS HCIÉlevéeInterception de données
Brouillage (Jamming)PHYSDR ($300+) ou firmware modifiéMoyenDoS du beacon

Spoofing d’adresse MAC : détection et mitigation

Les adresses BLE existent en quatre types (Publique, Aléatoire statique, Aléatoire privée résolvable (RPA), Aléatoire privée non résolvable). La plupart des beacons de production utilisent des adresses Publiques ou Aléatoires statiques — toutes deux trivialement spoofables. Un attaquant avec un dongle USB à $20 peut cloner le MAC d’un beacon et injecter de faux paquets ADV :

# Attacker: spoofing a beacon's MAC

sudo hciconfig hci0 down

sudo hciconfig hci0 leadrand # or set static BD_ADDR

sudo hciconfig hci0 up

hcitool -i hci0 cmd 0x08 0x0008 # set ADV data

hcitool -i hci0 cmd 0x08 0x000a # enable ADV

Stratégie de détection : Corréler par empreinte RSSI. Si la même MAC apparaît à -45 dBm en Zone A et -82 dBm en Zone B en moins de 3 secondes, c’est un spoof. Implémentation côté serveur :

MAX_SPEED_MS = 30  # m/s (human running)

MIN_RSSI_DELTA = 25 # dBm for physically distinct positions

def detect_spoofing(mac, rssi, gateway_id, timestamp):

prev = db.get_last_seen(mac)

if prev:

time_delta = timestamp - prev['ts']

rssi_delta = abs(rssi - prev['rssi'])

# Physical impossibilty: RSSI jump >25dBm in <2s

if time_delta < 2.0 and rssi_delta > MIN_RSSI_DELTA:

return "SPOOF_DETECTED"

return "OK"

Écoute clandestine de paquets ADV : analyse de fuite d’information

Les paquets ADV sont diffusés en texte clair. Tout écouteur passif à portée capture :

  • Adresse MAC du beacon (identité de l’appareil)
  • Charge utile des données ADV (y compris les données constructeur personnalisées)
  • RSSI (implicitement, au récepteur)

Quantification du risque : Un sniffer nRF52840 capture 100 % des paquets ADV des beacons dans un rayon de 40 mètres (air libre, TX 0 dBm). L’attaquant extrait les ID d’actifs, les versions de firmware et — le cas échéant — les balises de localisation non chiffrées.

Contre-mesure 1 : Retirer les identifiants de la charge utile ADV. Utiliser des ID éphémères (EID) tournés quotidiennement via un secret partagé :

# Beacon: daily EID rotation

import hmac, hashlib, time

DAILY_KEY = hmac.new(SECRET, str(int(time.time())//86400).encode(), hashlib.sha256).digest()[:8]

# ADV manufacturer data = DAILY_KEY[:4] + rotating_counter[:4]

# Server resolves: lookup table of EID -> asset_id

Contre-mesure 2 : Minimiser la charge utile ADV. N’incluez pas les numéros de série d’actif, les versions de firmware ou des chaînes lisibles par l’homme dans les données ADV. Utilisez un encodage binaire compact avec un nonce tournant.

Attaques par rejeu : empêcher l’entrée non autorisée en zone

Dans le contrôle d’accès par proximité (ex. « déverrouiller la porte lorsqu’un beacon avec l’ID X est à moins de 1 mètre »), un attaquant capture un paquet ADV valide et le rejoue plus tard. Sans challenge-response borné dans le temps, le système accorde l’accès.

Mitigation : challenge-response signé. Au lieu d’une détection passive ADV uniquement, la gateway initie une connexion et demande une réponse signée :

MéthodeNiveau de sécuritéCoût énergétique (μAh suppl. / événement)Latence
ADV seul (sans auth)Aucun (spoofable)00 ms
ADV + connexion + lecture char. signéeMoyen (ECDSA P-256)~180 μAh~120 ms
ADV chiffré (LE Secure Connections OOB)Élevé~60 μAh (sans connexion requise)~15 ms

LE Secure Connections avec appariement Out-of-Band (OOB) distribue un secret partagé via NFC ou une clé pré-partagée. Le beacon chiffre l’ADV en utilisant AES-CCM avec un IV tournant. La gateway déchiffre et valide l’horodatage dans ±500 ms pour empêcher le rejeu.

Publicité chiffrée : LE Secure Connections et au-delà

Bluetooth 5.4 a introduit les données de publicité chiffrées (EAD). Le beacon et la gateway partagent une clé secrète (distribuée via GATT après appariement sécurisé). Les paquets ADV transportent des charges utiles chiffrées AES-128-CCM. Même sniffés, la charge utile est indéchiffrable sans la clé.

Implémentation sur nRF52 (SoftDevice S140) :

// Configure EAD in SoftDevice

ble_ead_config_t ead_config = {

.p_key = pre_shared_key_16byte,

.key_id = 1,

.nonce_mode = BLE_EAD_NONCE_INCREMENTING

};

sd_ble_ead_enable(&ead_config);

// ADV data now encrypted

ble_advdata_t advdata = { .p_ead_data = &encrypted_payload };

Impact sur les performances : EAD ajoute ~8 octets de surcoût par paquet ADV. Avec la limite ADV de 31 octets, il reste 23 octets pour la charge utile réelle. Planifiez la fragmentation des messages si votre charge utile dépasse cela.

Sécurité physique : détection d’effraction

Au-delà des attaques RF, la falsification physique du beacon est une menace réelle dans les déploiements de vente au détail et d’entrepôt. Contre-mesures :

  • Interrupteur d’intrusion de boîtier : Le reed switch magnétique déclenche l’effacement du MCU (interruption GPIO → effacement des clés BLE en flash)
  • Époxy à effacement UV : EncapSulez le PCB ; le retrait physique expose la puce aux UV, corrompant les clés stockées
  • Heartbeat actif : Le beacon envoie un message signé « alive » toutes les 15 minutes ; 3 heartbeats consécutifs manquants déclenchent une alerte

Sécurité vs puissance : compromis quantitatif

Niveau de sécuritéIntervalle ADVPuissance TXDurée de vie pile (CR2477)Spoofable ?
Aucun (ADV en texte clair)100 ms0 dBm14 moisOui
Basique (rotation EID)500 ms0 dBm28 moisDifficile (nécessite compromis de clé)
Moyen (connexion signée ECDSA)1000 ms0 dBm18 moisNon (nécessite clé privée)
Élevé (EAD + appariement sécurisé)500 ms-8 dBm36 moisNon (AES-CCM chiffré)

L’équilibre de production optimal : rotation EID + chiffrement EAD, avec un intervalle ADV de 500 ms. Cela atteint une sécurité forte avec une durée de vie de pile de 28+ mois sur CR2477.

Checklist de déploiement

  • ✅ Tourner les clés EID quotidiennement via OTA (ou pré-provisionner une fenêtre de clés de 90 jours)
  • ✅ Activer EAD (Bluetooth 5.4+) pour les charges utiles sensibles
  • ✅ Valider la cohérence RSSI côté serveur pour détecter le spoofing MAC
  • ✅ Utiliser des adresses MAC aléatoires (adresse privée résolvable) avec rotation de 15 minutes
  • ✅ Pour le contrôle d’accès : exiger un challenge-response signé (pas une présence ADV seule)
  • ✅ Sécuriser physiquement le beacon (interrupteur d’effraction + époxy à effacement UV)

La sécurité pour les déploiements de Bluetooth Beacon n’est pas optionnelle en 2026 — c’est une exigence de conception. Les techniques ci-dessus (rotation EID, chiffrement EAD, empreinte RSSI et challenge-response signé) offrent une défense en profondeur contre les vecteurs d’attaque les plus courants. Notre équipe d’ingénierie peut assister à l’implémentation de firmware de beacon sécurisé et à la revue de sécurité de votre architecture de déploiement. Contactez-nous pour une analyse technique approfondie de votre cas d’usage impliquant des Bluetooth Beacon.