Un BLE Tag n’est digne de confiance que dans la mesure où l’on peut prouver qu’il est authentique. Si n’importe quelle carte bon marché répond avec la même MAC et le même payload, votre suivi d’assets, votre contrôle d’accès ou votre paiement s’effondre. Cet article explique comment faire qu’un BLE Tag résiste au clonage et au spoofing : challenge-response, clés PUF, identités rotatives et attestation.

Pourquoi le clonage fonctionne

Un BLE Tag diffuse une identité. Un copycat qui rejoue la même publicité ou répond une connexion avec la même clé statique est impossible à distinguer pour un lecteur naïf. La défense est cryptographique : le tag doit prouver la possession d’un secret qu’il ne peut fuiter.

Challenge-response avec ECDH

Le lecteur émet un nonce aléatoire et le BLE Tag doit renvoyer une signature dessus :

resp = Sign(sk, nonce || reader_id)

La clé privée sk ne quitte jamais le secure element. Un clone sans sk ne peut pas produire un resp valide et est rejeté. Utilisez ECDSA P-256 ou Ed25519 ; couplé à ECDH pour une clé de session éphémère et forward-secret.

PUF : une clé illisible et incopiable

Une fonction physiquement non clonable dérive une clé unique de la variation du silicium. La clé PUF du BLE Tag n’est jamais stockée en flash, donc vider la puce ne donne rien. Chaque appareil obtient une clé différente sans base d’enrôlement à violer.

Identités rotatives et anti-replay

Les publicités statiques s’enregistrent et se rejouent trivialement. Faites tourner l’ID rotatif annoncé sur un intervalle court :

ID_i = Truncate(HMAC(k, T_i), n)

où T_i est une fenêtre temporelle. Un lecteur valide sur la fenêtre courante et la précédente. Une publicité capturée devient inutile quelques minutes plus tard. Combinez avec un compteur monotone pour tuer le replay.

Attestation et confiance de flotte

Pour une flotte gérée, le BLE Tag doit attester son firmware et son identité. Un blob d’attestation signé, vérifié contre une racine gravée dans le lecteur, prouve que l’unité exécute un firmware intact — bloquant clones et appareils rootés.

Attaques de portée et de relais

La crypto n’arrête pas un relais : un attaquant étend la portée avec deux proxys pour que le tag « apparaisse » près du lecteur. Atténuer avec du distance-bounding (contrôle du temps aller-retour) et en liant la transaction à une courte fenêtre de proximité physique.

Checklist pratique

  • Stockez les clés dans un secure element ou PUF, jamais en flash en clair.
  • Utilisez le challenge-response, jamais de secrets partagés statiques.
  • Faites tourner les ID annoncés sur un intervalle court avec compteurs anti-replay.
  • Attestez le firmware contre une chaîne de confiance enracinée.
  • Ajoutez du distance-bounding là où le relais est une menace réelle.

Un BLE Tag bien défendu rend le clonage économiquement sans intérêt : l’attaquant a besoin du silicium, pas seulement des octets.