Ein BLE-Tag ist günstig — bis man zehntausend hat. In dem Moment, in dem die Flotte das Werk verlässt, muss jedes Tag bereits eine einzigartige, vertrauenswürdige Identität tragen. Sonst ist Ihr „Asset-Tracking“-System in Wahrheit ein „anonymer Beacon-Spam“, den jeder klonen kann. Massen-Provisionierung und sicheres Enrollment sind die unspektakulären Schritte, die entscheiden, ob Tags ein Asset oder eine Last sind.
Dies ist die Ingenieur-Anleitung, Geräte-vertrauen in Millionen Tags zu bringen: Key-Injektion, Secure-Element vs SoC-Speicher, Fabrikfluss, Zero-Touch-Onboarding und Lifecycle-Rotation.
Zwei Phasen, eine Vertrauenskette
- Fertigungs-Provisionierung: einmal, an der Linie, wo das Tag seine Identität erhält (Schlüsselpaar, Seriennummer, Attestierung).
- Feld-Enrollment: wenn das Tag erstmals an des Kunden System join, bindet die Werk-Identität an Tenant, Site und Policy.
Beides zu verwechseln ist der klassische Fehler. Vertrauen im Feld zu erfinden geht nicht, wenn das Werk einen leeren oder geteilten Key auslieferte.
Geräte-Identität: was hineinkommt
Jedes Tag braucht:
- Ein einzigartiges Schlüsselpaar (ECDSA P-256 oder Ed25519) — Private Key verlässt das Gerät nie.
- Eine öffentliche Identität, die der Server verifizieren kann: roher Public Key oder X.509-Zertifikat, von der Flotten-Root signiert.
- Eine Seriennummer / EUI-64, an diesen Key gebunden, im selben Secure Store.
- Optional ein PUF-abgeleitetes Secret aus Siliziumvarianz, für Anti-Cloning.
Ein Tag, das nur eine zufällige MAC ohne signierte Identität sendet, ist trivial spoofbar. Der signierte Public Key macht „dieses Tag ist Serie X“ zur vom Server vertrauenswürdigen Aussage.
Secure Element vs SoC-Speicher
| Option | Key-Extraktion | Stückkosten | Flexibilität | Provisionierung |
|---|---|---|---|---|
| SoC-Key in Flash | Hoch (Read/JTAG) | Niedrig | Hoch | OTP/eFuse siegeln |
| SoC-Key in eFuse | Mittel (Decap) | Niedrig | Mittel | Einmal brennen |
| Diskretes Secure Element | Sehr niedrig | +$0,30–1 | Niedrig | In Plant personalisieren |
| PUF + SoC | Niedrig (kein Key at rest) | Mittel | Mittel | Boot ableiten |
Für Asset-Tags außerhalb der Kontrolle lohnt ein Secure Element oder PUF. Ein plain Flash-Key taugt nur für geschlossene, physisch gesicherte Setups.
Der Fabrik-Provisionierungsfluss
Die Injektionsstation ist die Geburt des Vertrauens. Ein minimaler, auditierbarer Fluss:
1. SoC bootet im Provisioning-Modus (JTAG offen, Debug an)
2. On-chip TRNG erzeugt Schlüsselpaar (kp_priv, kp_pub)
3. Station schreibt Serial + kp_pub in OTP/eFuse oder Secure Element
4. Station signiert (Serial, kp_pub) mit PLANT_KEY -> Attest-Token
5. Station siegelt Device: Debug lock, OTP lock, Re-Provision aus
6. Device liefert Attest auf Challenge -> Station loggt in HSM-AuditKardinalregel: der Private Key wird auf dem Device generiert, nie auf der Station. Hat die Station Private Keys, ist eine gestohlene Station = geklonte Flotte. Der PLANT_KEY, der Attests signiert, liegt im HSM, nicht auf dem Laptop.
Supply-Chain-Vertrauen
Das Attest-Token lässt den Enrollment-Server beweisen, dass ein Tag von der eigenen Linie stammt, nicht vom Fälscher. Verkette es:
DEVICE_KEY signiert von PLANT_KEY signiert von FLEET_ROOTHalte ein signiertes Manifest (Serial, Pubkey-Hash, Batch, Timestamp) in einem append-only Audit-Log, das vom HSM gestützt wird. Ist ein Batch kompromittiert, kannst du die Revocation auf diesen Batch scope-en statt auf die ganze Flotte.
Zero-Touch Feld-Enrollment
Das Tag soll sich selbst enrollen, wenn es am Kunden-Site erstmals Strom bekommt:
tag an -> sendet ENROLLMENT_ADV (serial, nonce, attest)
gateway hoert -> proxy (serial, attest) an ENROLLMENT_SERVER
server prueft: attest gueltig? serial ungenutzt? nicht revoziert?
server ausgabe: tenant-binding + session-key pro tag + policy
server retour -> gateway forward -> tag speichert binding, NORMAL-modusKein Techniker scannt pro Tag einen QR-Code. Die „Challenge“ in der Advertisement verhindert Replay eines aufgezeichneten Enrollment-Frames.
Enrollment-Protokoll-Skizze
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, asset-klasse
binding = sign((serial, tenant, policy), FLEET_KEY)
log_enroll(serial, tenant, now())
return (session_key, binding, policy)Der Session-Key ist pro Tag und rotiert; der langfristige Device-Key dient nur am Enrollment und bei periodischer Re-Attestierung der Identitätsprobe.
Key-Rotation und Lifecycle
Der Identity-Key des Tags kann fix bleiben, aber seine Session/Verschlüsselungs-Keys müssen rotieren:
- Rotation bei jedem Re-Enrollment (Tag wechselt Site/Tenant).
- Remote Revocation unterstützen: Serial eines kompromittierten Tags auf eine CRL, an Gateways gepusht; danach ignoriert.
- Periodische Re-Attestierung (z. B. alle 90 Tage) beweist neu, dass das Device seinen Key noch hält, und fängt Clones, die eine geleakte Public Identität ohne Private Key wiederverwendeten.
Batch-Durchsatz
Massen-Provisionierung ist ein Linienproblem. Zahlen einer typischen Linie:
| Schritt | Zeit pro Tag | Durchsatz (1 Station) |
|---|---|---|
| Key gen + write | 40 ms | ~25/s |
| Attest + siegeln | 60 ms | ~16/s |
| Audit-Log commit | 20 ms | ~50/s |
| Ende-zu-Ende | ~120 ms | ~8/s ≈ 29k/Std |
Parallelisiere über Stationen für sechs Stellen pro Schicht. Der Flaschenhals ist fast immer die HSM-Sign-Rate, nicht der SoC.
Anti-Cloning im Feld
Selbst mit enrollten Keys kann ein hartnäckiger Clone einen aufgezeichneten Frame replayen. Gegenmaßnahmen:
- PUF Challenge-Response: Server sendet Zufalls-Challenge; nur echtes Silizium antwortet richtig (kein Key zum Extrahieren).
- Moving Target: rotiere die angekündigte Identität oder nutze rotierende anonyme Adressen (siehe Anti-Tracking-Artikel).
- Verhaltens-Check: ein Clone, der sich nie bewegt oder unmöglich schnell bewegt, ist am Server erkennbar.
Fehler, die eine Flotte versenken
- Geteilter Key über Tags — ein Leck kompromittiert alle; Revocation unmöglich.
- Klartext-Serial ohne Signatur — trivial spoofbar.
- Keine Attestierung — Fälschungen enrollen als echt.
- Im Feld re-provisionierbare Devices — gefundenes Tag wird reflasht und re-enrolled.
- HSM-freier PLANT_KEY — der Sign-Key auf dem Laptop ist eine Last.
OEM-Checkliste
- [ ] Einzigartiges Schlüsselpaar pro Tag, Private Key auf Device generiert
- [ ] Secure Store gesiegelt (eFuse/Secure Element/PUF) vor Versand
- [ ] Attestierung an Flotten-Root verkettet, Audit-Log append-only
- [ ] Zero-Touch-Enrollment mit Challenge-Nonce
- [ ] Session-Key-Rotation pro Tag + CRL-Revocation
- [ ] Periodische Re-Attestierung aktiv
- [ ] PLANT_KEY im HSM, Durchsatz auf Volumen dimensioniert
Ein richtig gemachtes BLE-Tag ist vertrauenswürdig, sobald es die Box verlässt, und bleibt es über sein ganzes Leben. Provisionierung verpfuscht heißt: zehntausend anonyme Beacons verschiffen.
