Die kryptografische Schlüsselverwaltung ist das operative Rückgrat sicherer Bluetooth-Beacon-Bereitstellungen. Während die Beacon-Hardware und das RF-Design die meiste Engineering-Aufmerksamkeit erhalten, entscheiden Schlüssel-Provisionierung, Rotationspläne und Widerrufsverfahren darüber, ob eine Flotte von 10.000 Beacons nach zwei Jahren im Feld sicher bleibt. Dieser Artikel bietet eine praxisnahe Engineering-Anleitung zur Verwaltung von Verschlüsselungsschlüsseln in großskaligen Beacon-Bereitstellungen.
Schlüsseltypen in Beacon-Systemen
| Schlüsseltyp | Zweck | Typische Größe | Rotationshäufigkeit |
|---|---|---|---|
| EID Identity Key | Erzeugt ephemere IDs für ADV | 128 bits (AES-128) | Täglich |
| EIRK (Identity Resolving Key) | Löst RPA auf echte Identität auf | 128 bits | Nie (einmalig provisioniert) |
| EAD Session Key | Verschlüsselt ADV-Payload (BT 5.4+) | 128 bits | Pro Sitzung oder täglich |
| OOB Pairing Key | LE Secure Connections Pairing | 256 bits (ECDSA P-256) | Pro Bereitstellung |
| Firmware Signing Key | OTA-Image-Verifikation | 256 bits (ECDSA P-256 private) | Nie (server-seitig) |
EID-Schlüsselrotation: Die tägliche Erneuerungs-Herausforderung
Ephemere IDs (EID) erfordern eine synchronisierte Schlüsselrotation zwischen Beacon und Server. Der Beacon erzeugt täglich eine neue ADV-Identität mittels einer zeitbasierten Ableitung aus dem Master-Schlüssel. Wenn die Uhren von Beacon und Server um mehr als ±12 Stunden driften, schlägt die EID-Auflösung fehl.
// EID-Ableitung (vereinfacht, basierend auf der iBeacon-EID-Spezifikation)
// Beacon-Seite (läuft um Mitternacht UTC):
def derive_eid(master_key, day_counter):
# PRK = HMAC-SHA256(master_key, day_counter)
prk = hmac_sha256(master_key, struct.pack('>I', day_counter))
# EID = AES-128-ECB(prk[0:16], 0x00000000...)
eid = aes128_ecb(prk[0:16], b'\x00' * 16)
return eid[0:4] # 4-Byte-EID für ADV
// Server-Seite (gleiche Ableitung, vorab berechnete Nachschlagetabelle):
// Tag 20010: EID = 0xA3F1BC02
// Tag 20011: EID = 0x7E44D819
// Tag 20012: EID = 0x12CF95A0
Uhrdrift-Management: BLE-Beacons verwenden typischerweise 32,768-kHz-Quarzoszillatoren mit einer Genauigkeit von ±20 ppm. Über 365 Tage beträgt die maximale Drift = 20e-6 × 86400 × 365 = ±631 Sekunden (~10,5 Minuten). Das liegt innerhalb der ±12-Stunden-Toleranz für tägliche EIDs, aber wöchentliche oder monatliche Rotationsfenster erfordern eine periodische Zeitsynchronisation über eine BLE-Verbindung.
Schlüsselverteilung: Sichere Provisioning-Workflows
Das Vorab-Provisionieren von Schlüsseln für 10.000+ Beacons erfordert einen sicheren, prüfbaren Workflow. Drei Ansätze mit Kompromissen:
| Methode | Geschwindigkeit | Sicherheit | Skalierbarkeit |
|---|---|---|---|
| Vorab-Provisionierung (Werkblitz) | Schnell (Batch) | Hoch (physischer Zugriff kontrolliert) | Begrenzt durch Schlüssel-Eindeutigkeit |
| OTA-Provisionierung (BLE) | ~10 s/Beacon | Mittel (MANA während des Fensters möglich) | 10K Einheiten in ~28 Stunden |
| NFC-Tap-Provisionierung | ~2 s/Beacon | Hoch (physische Nähe) | 10K Einheiten in ~6 Stunden |
NFC-Tap-Provisionierung wird für sicherheitskritische Bereitstellungen empfohlen. Die Provisioning-Station schreibt den EID-Master-Schlüssel, den EIRK und den EAD-Session-Schlüssel in den sicheren Flash des Beacons (Protected Storage auf nRF52) über NFC. Der Beacon wechselt sofort in den sicheren Modus und kann ohne Werkreset nicht neu provisioniert werden.
Schlüsselwiderruf: Umgang mit kompromittierten Beacons
Wenn ein Beacon physisch gestohlen wird oder sein Schlüsselmaterial als kompromittiert gilt, muss der Flottenmanager seine Schlüssel widerrufen. Widerrufsstrategien:
- Individueller Widerruf: Den EIRK des Beacons zu einer Blacklist im Server hinzufügen. Kosten: O(1)-Nachschlage pro ADV-Paket. Skaliert auf ~100.000 Einträge, bevor eine Bloom-Filter-Optimierung nötig wird.
- Segmentierte Schlüsselrotation: Flotte in Schlüsselsegmente (A/B/C) unterteilt. Wenn Segment B kompromittiert ist, nur Schlüssel für Segment B rotieren (20 % der Flotte). Nicht betroffene Beacons arbeiten weiter.
- Globale Schlüsselrotation: Notfall-Rotation aller Flottenschlüssel. Erfordert Neu-Provisionierung aller Beacons. Kosten: ~28 Stunden für 10K Einheiten über BLE OTA. Reserviert für katastrophalen Kompromiss.
Sichere Schlüsselspeicherung auf dem Beacon
Schlüsselmaterial muss in hardware-geschütztem Speicher abgelegt werden, um Extraktion über JTAG, SWD oder Firmware-Dump zu verhindern. nRF52 Secure Debug (nRF52840+) deaktiviert den Debug-Zugriff nach der Provisionierung dauerhaft. Alternative Schutzmaßnahmen:
| Speichermethode | Extraktionsschwierigkeit | Plattformen |
|---|---|---|
| KMU (Key Management Unit) | Praktisch unmöglich (Hardware-AES-Engine) | nRF52840, nRF5340 |
| Protected Flash (ACL) | Schwierig (erfordert Firmware-Exploit) | nRF52-Serie |
| ESP32 Flash Encryption | Mittel (Schlüssel im efuse, brennbar) | ESP32, ESP32-C3 |
| Plain Flash (kein Schutz) | Einfach (SWD-Read) | Beliebig (nicht empfohlen) |
Schlüssellebenszyklus: Von der Provisionierung bis zur Außerbetriebnahme
- Generierung: Keyserver erzeugt eindeutige Schlüssel pro Beacon (oder pro Segment). Master-Schlüssel verwenden CSPRNG (nicht pseudo-zufälliges LFSR).
- Provisionierung: Schlüssel über NFC/BLE in den Beacon geschrieben. Secure Debug aktiviert → Schlüssel geschrieben → Secure Debug dauerhaft deaktiviert.
- Aktiver Einsatz: Beacon leitet tägliche EIDs ab, verschlüsselt ADV mit EAD-Schlüsseln. Server hält synchronisierte Schlüsseldatenbank.
- Rotation: Periodische Schlüsselrotation (empfohlen: vierteljährlich für Master-Schlüssel, täglich für EID-Session-Schlüssel).
- Widerruf: EIRK eines kompromittierten Beacons zur Server-Blacklist hinzufügen. Gateway-Firmware aktualisiert, um blacklistete EIRKs abzulehnen.
- Außerbetriebnahme: Beacon physisch zurückgegeben. Sicheres Löschen (Flash-Wipe + Werkreset). Schlüssel aus Server-Datenbank entfernt.
Flottenweite Schlüsselverwaltungs-Architektur
Für Bereitstellungen mit mehr als 1.000 Beacons wird ein dedizierter Key Management Service (KMS) notwendig. Architektur-Komponenten:
- Keyserver: HSM-gestützte Schlüsselgenerierung und -speicherung. REST-API für Beacon-Provisionierung und Gateway-Schlüsselverteilung.
- Provisioning-Agent: CLI/Python-Tool, das über NFC/BLE mit Beacons kommuniziert, um Schlüssel einzuspeisen. Protokolliert jedes Provisioning-Ereignis mit Beacon-Seriennummer, Zeitstempel und Operator-ID.
- Gateway-Key-Sync: Gateways rufen periodisch Rotationspläne und Blacklisten vom Keyserver über HTTPS (mTLS gegenseitige Authentifizierung) ab.
- Audit-Logger: Unveränderliches Protokoll aller Schlüsseloperationen (provisionieren, rotieren, widerrufen). In einer Nur-Anhängen-Datenbank für Compliance gespeichert.
Die kryptografische Schlüsselverwaltung für Bluetooth Beacon-Flotten ist der Unterschied zwischen einer Bereitstellung, die graceful degradiert, und einer, die nach 12 Monaten zur Sicherheitslast wird. Die Kombination aus täglicher EID-Rotation, NFC-Provisionierung, hardware-geschütztem Speicher und segmentiertem Widerruf bietet Defense-in-Depth in Flottengröße. Unser Team bietet Architektur-Design für Schlüsselverwaltung und Provisioning-Automatisierung für Bluetooth Beacon-Bereitstellungen — kontaktieren Sie uns für eine technische Beratung.
