Un BLE Tag est peu coûteux jusqu’à ce que vous en ayez dix mille. Au moment où la flotte sort d’usine, chaque tag doit déjà porter une identité unique et digne de confiance — sinon votre système de « suivi d’actifs » est en réalité un « spam de beacons anonymes » que n’importe qui peut cloner. Le provisioning de masse et l’enrollement sécurisé sont les étapes ingrates qui décident si vos tags sont des actifs ou des passifs.
Voici le guide de l’ingénieur pour mettre la confiance par appareil dans des millions de tags : injection de clés, stockage secure element vs SoC, flux d’usine, onboarding zero-touch et rotation du cycle de vie.
Deux phases, une chaîne de confiance
- Provisioning de fabrication : une fois, à la ligne, où le tag obtient son identité (paire de clés, serial, attestation).
- Enrollement sur le terrain : quand le tag rejoint pour la première fois le système client, liant l’identité d’usine à un tenant, un site et une politique.
Les confondre est l’erreur classique. On n’invente pas la confiance sur le terrain si l’usine a expédié une clé vide ou partagée.
Identité par appareil : ce qui va dedans
Chaque tag a besoin de :
- Une paire de clés unique (ECDSA P-256 ou Ed25519) — la clé privée ne quitte jamais l’appareil.
- Une identité publique vérifiable par le serveur : clé publique brute, ou certificat X.509 signé par la racine de flotte.
- Un serial / EUI-64 lié à cette clé, écrit dans le même stockage sécurisé.
- Optionnel : un secret dérivé de PUF de la variation de silicium, pour l’anti-clonage.
Un tag qui n’émet qu’un MAC aléatoire sans identité signée est trivialement spoofable. La clé publique signée est ce qui rend « ce tag est le serial X » une affirmation que le serveur peut croire.
Secure element vs stockage SoC
| Option | Risque extraction | Coût | Flexibilité | Provisioning |
|---|---|---|---|---|
| Clé SoC en flash | Haut (lecture/JTAG) | Bas | Haute | Sceller OTP/eFuse |
| Clé SoC en eFuse | Moyen (décapsuler) | Bas | Moyenne | Gravure unique |
| Secure element discret | Très bas | +0,30–1 $ | Basse | Personnaliser à l’usine |
| PUF + SoC | Bas (pas de clé au repos) | Moyen | Moyenne | Dériver au boot |
Pour les tags d’actifs hors de votre contrôle, un secure element ou PUF vaut son coût. Une clé flash plate ne convient qu’aux déploiements clos et physiquement sûrs.
Le flux de provisioning d’usine
La station d’injection est là où naît la confiance. Un flux minimal et auditable :
1. SoC démarre en mode provisioning (JTAG ouvert, debug activé)
2. TRNG sur puce génère la paire (kp_priv, kp_pub)
3. Station écrit serial + kp_pub dans OTP/eFuse ou secure element
4. Station signe (serial, kp_pub) avec PLANT_KEY -> jeton d'attestation
5. Station scelle le device : lock debug, lock OTP, désactive re-provision
6. Device renvoie attestation sur challenge -> station loggue dans audit HSMRègle critique : la clé privée est générée sur l’appareil, jamais sur la station. Si la station détient des clés privées, une station volée = une flotte clonée. La PLANT_KEY qui signe les attestations vit dans un HSM, pas sur un laptop.
Confiance dans la chaîne d’approvisionnement
Le jeton d’attestation permet au serveur d’enrollement de prouver qu’un tag vient de votre ligne, pas d’un contrefacteur. Enchaînez-la :
DEVICE_KEY signé par PLANT_KEY signé par FLEET_ROOTGardez un manifeste signé (serial, hash de pubkey, lot, timestamp) dans un log d’audit append-only soutenu par le HSM. Si un lot est compromis, vous pouvez borner la révocation à ce lot au lieu de toute la flotte.
Enrollement zero-touch sur le terrain
Le tag doit s’enroler seul la première fois qu’il est alimenté sur le site client :
tag sous tension -> émet ENROLLMENT_ADV (serial, nonce, attestation)
gateway entend -> proxy (serial, attestation) vers ENROLLMENT_SERVER
serveur vérifie : attestation valide ? serial inutilisé ? non révoqué ?
serveur émet : liaison tenant + clé de session par tag + politique
serveur retourne -> gateway transfère -> tag stocke liaison, mode NORMALAucun technicien ne scanne un QR par tag. Le « challenge » dans l’advertisement empêche le replay d’une trame d’enrollement capturée.
Esquisse du protocole d’enrollement
def enroll(tag_adv, server):
serial, nonce, attest = parse(tag_adv)
if not verify_attest(attest, serial, PLANT_PUB): return REJECT
if serial in revoked_list: return REJECT
if serial in enrolled_set: return ALREADY
session_key = HKDF(nonce, server_seed)
policy = lookup_policy(serial) # site, classe d'actif
binding = sign((serial, tenant, policy), FLEET_KEY)
log_enroll(serial, tenant, now())
return (session_key, binding, policy)La clé de session est par tag et rotée ; la clé device à long terme ne sert qu’à prouver l’identité à l’enrollement et aux ré-attestations périodiques.
Rotation des clés et cycle de vie
La clé d’identité du tag peut rester fixe, mais ses clés de session/chiffrement doivent tourner :
- Rotation à chaque ré-enrollement (le tag change de site/tenant).
- Révocation à distance : le serial d’un tag compromis va dans une CRL poussée aux gateways ; il est alors ignoré.
- Ré-attestation périodique (ex. tous les 90 jours) reprouve que le device a encore sa clé, attrapant les clones qui ont réutilisé une identité publique fuitée sans la clé privée.
Débit par lot
Le provisioning de masse est un problème de ligne. Chiffres d’une ligne typique :
| Étape | Temps par tag | Débit (1 station) |
|---|---|---|
| Gen + écriture clé | 40 ms | ~25/s |
| Attester + sceller | 60 ms | ~16/s |
| Commit log audit | 20 ms | ~50/s |
| Bout en bout | ~120 ms | ~8/s ≈ 29k/h |
Parallélisez sur plusieurs stations pour atteindre six chiffres par quart. Le goulot est presque toujours le taux de signature HSM, pas le SoC.
Anti-clonage sur le terrain
Même avec des clés enrollées, un clone acharné peut rejouer une trame capturée. Défenses :
- PUF challenge-response : le serveur envoie un défi aléatoire ; seul le silicium authentique répond juste (pas de clé à extraire).
- Cible mouvante : faites tourner l’identité annoncée ou utilisez des adresses anonymes rotatives (voir article anti-tracking).
- Vérification comportementale : un clone qui ne bouge jamais ou à une vitesse impossible est détectable au serveur.
Erreurs qui coulent une flotte
- Clé partagée entre tags — une fuite compromet tout ; révocation impossible.
- Serials en clair sans signature — trivialement spoofés.
- Pas d’attestation — les contrefaçons s’enrollent comme réelles.
- Devices re-provisionnables sur le terrain — un tag trouvé est reflashé et ré-enrollé.
- PLANT_KEY sans HSM — la clé de signature sur un laptop est un passif.
Checklist OEM
- [ ] Paire de clés unique par tag, clé privée générée sur l’appareil
- [ ] Stockage sécurisé scellé (eFuse/secure element/PUF) avant expédition
- [ ] Attestation enchaînée à la racine de flotte, log d’audit append-only
- [ ] Enrollement zero-touch avec nonce de challenge
- [ ] Rotation de clé de session par tag + révocation CRL
- [ ] Ré-attestation périodique activée
- [ ] PLANT_KEY dans HSM, débit dimensionné au volume
Un BLE Tag bien fait est fiable dès la sortie de la boîte et le reste toute sa vie. Rater le provisioning, c’est avoir expédié dix mille beacons anonymes.
