Zielgruppe: Dieser Artikel richtet sich an Einkäufer von Schulministerien, IT-Sicherheitsverantwortliche von Markeninhabern und OEM-Programmmanager, die in ihrer RFP genau diese Frage beantworten müssen: "wie erkennt der Lesestift, dass er mit unserer Cloud spricht und nicht mit einem Proxy?". Wir erläutern SPKI-Hash-Pinning, den Rotationszyklus des Pin-Sets, die Telemetrie, die uns meldet, wenn ein Stift versucht hat, mit dem falschen Endpunkt zu sprechen, sowie den Incident-Response-Playbook, den unser Sicherheitsteam quer über die 11 SKUs der Smart-Reading-Pen-Baureihe (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6) einsetzt.
Ein Lesestift ist nur 22 % seiner Wachzeit online – er schläft mit 0,06 mA und wacht bei Scan, Nutzertastendruck und OTA-Watchdog auf. Wenn er aufwacht, hat er 9 bis 16 Sekunden Zeit, um mit der Cloud zu kommunizieren, den Status zu synchronisieren und wieder zu schlafen. Dieses 9-bis-16-Sekunden-Fenster ist genau das Zeitfenster, das ein Unternehmens-MITM-Proxy ausnutzen will. Wir sichern den Kanal mit SPKI-Hash-Pinning bei jedem TLS-Handshake. Dieser Artikel ist das Engineering-Deep-Dive.
Einkaufstipp: Wenn Sie zwei Anbieter anhand von "TLS 1.3-Unterstützung" vergleichen, ist das kein Differenzierungsmerkmal – das beherrschen beide. Der Unterschied liegt darin, ob der Stift die Verbindung verweigert, wenn sich das Cloud-Zertifikat unerwartet ändert. Fragen Sie nach dem Rotationszyklus des produktiven Pin-Sets und nach dem Zugangscode für das Field-Debug-Menü. Ein Anbieter, der zögert, pinnt nicht.
1. Warum Standard-TLS auf einem Embedded-Gerät nicht ausreicht
Ein Lesestift kann die WebPKI nicht wie ein Browser nutzen. Es gibt keinen automatischen Update-Kanal für den Trust-Store, keine Google-CRL-Pipeline, keine Apple-Push-Benachrichtigung. Wenn wir den Stift mit dem Mozilla-CA-Bundle ausliefern würden, würde eine CA-Kompromittierung in einer der 140 Wurzeln im Bundle einen Rückruf von 47 000+ Stiften erforderlich machen. Daher liefern wir kein CA-Bundle aus. Wir liefern ein Pin-Set: eine kurze Liste von SPKI-Hashes, die das Gerät als Identitätsnachweis akzeptiert.
Wenn der Stift versucht, den Cloud-MQTT-Endpunkt unter mqtt-eu.smartreadingpen.com zu erreichen, liefert der TLS-Handshake ein Serverzertifikat zurück. Der Lesestift berechnet den SHA-256 der SubjectPublicKeyInfo (öffentliche Schlüssel-Bytes) des Zertifikats und vergleicht diesen Hash mit dem im Secure Element gespeicherten Pin-Set. Stimmt der Hash überein, wird die Verbindung aufgebaut; andernfalls wird sie abgewiesen und das Ereignis protokolliert.
| Cloud-Endpunkt | Zertifikat | SPKI-Hash (SHA-256, erste 32 Bytes) |
|---|---|---|
mqtt-eu.smartreadingpen.com |
Let's Encrypt R3 cross-signed | d2 5e 7e 40 6f 4d c6 a5 4b 2a bc d0 f2 a5 8b 80 c8 9b a6 1f 18 b7 81 9e 76 67 50 da 8c e4 0d 3c |
mqtt-us.smartreadingpen.com |
ISRG Root X1 (selbstsigniert) | 96 bc ec 06 26 49 76 f3 7d 63 75 c2 bb c1 df e6 9c a0 47 b7 6d a3 95 65 4c 6d 4d 6e 5d 2c 21 4b |
ota-eu.smartreadingpen.com |
ISRG Root X1 (selbstsigniert) | 96 bc ec 06 26 49 76 f3 7d 63 75 c2 bb c1 df e6 9c a0 47 b7 6d a3 95 65 4c 6d 4d 6e 5d 2c 21 4b |
ota-asia.smartreadingpen.com |
DigiCert Global G2 | 15 96 09 49 e3 a8 9c 89 1d 33 0f 9c 2d 1f c8 60 d6 89 d9 d0 1a 04 6c 8a 4c 4f 1d e2 e7 7c ec ff |
Das Muster mit zwei gepinnten Hashes ist bewusst gewählt: Jeder Endpunkt wird gleichzeitig gegen zwei SPKI-Hashes gepinnt, das aktuelle Produktivzertifikat und das Zertifikat, auf das wir als Nächstes wechseln wollen. Eine Rotation führt nie zu einem Feldrückruf.
2. Das Pin-Set-Layout im Gerät
Ein typisches Pin-Set auf einem L5 oder Q8 sieht im NVM so aus:
pin-set[0] = SPKI-Hash (primär) = 15 96 09 ...
pin-set[1] = SPKI-Hash (Backup) = 96 bc ec ...
pin-set[2] = Ablauf (Epoche 1747) = 2027-01-15
pin-set[3] = Flags = PIN_REQUIRED | PIN_LOG_ON_MISS
pin-set[4] = Sperrliste (CRL) = 1 Eintrag
pin-set[5] = max. Kettenlänge = 3
Flags sind die operativen Hebel. PIN_REQUIRED weist den Handshake bei Missmatch ab. PIN_LOG_ON_MISS schreibt den abweichenden SHA-256 und die Quell-IP in den NVRAM für die nächste Synchronisation. PIN_LOG_ONLY akzeptiert die Verbindung, protokolliert den Missmatch aber zur Diagnose. Das Flag PIN_REQUIRED ist auf jedem SKU standardmäßig aktiv; PIN_LOG_ONLY haben wir für QA-Builds reserviert.
3. Der Rotationszyklus
Pins halten nicht ewig. Zwei Uhren steuern die Rotation: ein hartes Ablaufdatum (Epoche) und ein Notfall-Auslöser (CA-Kompromittierung, Gerätewechsel). Der Zyklus ist konservativ, weil wir uns keinen Feldrückruf leisten können.
| Pin-Set | Owner | Hartes Ablaufdatum | Weiche Überprüfung | Notfall-Auslöser | Mechanismus |
|---|---|---|---|---|---|
| Cloud MQTT primär | Cloud-Team | 24 Monate | 18 Monate | CA-Kompromittierung, MITM-Telemetrie | Firmware-OTA + SE-Re-Flash |
| Cloud-MQTT-Backup | Cloud-Team | 24 Monate | 18 Monate | n/a (rotiert immer mit) | Firmware-OTA |
| OTA-Server | OTA-Team | 12 Monate | 9 Monate | Manipulation der OTA-Kette | Firmware-OTA + SE |
| OEM-Portal | OEM (nur Muster A) | 12 Monate | 9 Monate | OEM-Anfrage | OEM-HSM-Seite |
| Crash-Reporter | Cloud-Team | 36 Monate | 24 Monate | Ablauf des TLS-Zertifikats | Firmware-OTA |
Bei über 47.000 ausgelieferten Stiften haben wir das Cloud-MQTT-Pin-Set dreimal rotiert: 2023 (Let's-Set-Import quer signiert), 2024 (nur ISRG-Root-X1) und 2025 (DigiCert-Intermediate). Die Abdeckung jeder Rotation lag bei 99,6 % innerhalb von 14 Tagen; die verbleibenden Stifte wurden innerhalb von 45 Tagen per Offline-OTA über die Schul-Desktop-Ladestation synchronisiert.
4. Feld-Telemetrie: So erkennen wir eine Pin-Fehlübereinstimmung
Der Stift versagt bei einer Pin-Prüfung nie stillschweigend. Jede Nichtübereinstimmung wird im NVRAM mit Folgendem protokolliert: timestamp (RTC), der versuchte SPKI-Hash, der Endpoint-Hostname, die aufgelöste IP, die Tiefe der Zertifikatskette und die lokale Netzwerk-SSID (falls per WLAN verbunden). Beim nächsten erfolgreichen Boot-Vorgang – in der Regel innerhalb von 9 Stunden – wird der Log-Eintrag über den Telemetrie-Kanal des Unternehmens an das Backend hochgeladen.
Zusammenfassung der Pin-Prüfungs-Telemetrie für über 47.000 ausgelieferte Stifte im Jahr bis 2026-06:
| Ereignis | Anzahl | % der Flotte | Median pro Stift | Aktion |
|---|---|---|---|---|
| Erfolgreicher Handshake | 12,4 Mio. | 99,85 % | 264 | normal |
| PIN-Abweichung (auffälliger SPKI-Hash) | 18 240 | 0,13 % | 0,39 | überprüft |
| PIN-Abweichung + verkettete Abweichung | 184 | 118 | 118 | eskaliert |
| Erzwungene Rotation nach Vorfall | 2 | — | — | Post-Mortem eingereicht |
Die 184 verketteten Abweichungen im bis Juni 2026 endenden Jahr sind die interessanten Fälle. Diese stammen von Unternehmens-Proxys, die das Zertifikat im laufenden Betrieb neu signiert haben. Jede dieser Abweichungen hat innerhalb von 48 Stunden ein Support-Ticket an die IT-Abteilung der Schule ausgelöst. Keine führte zu einem Datenleck, da der TLS-Handshake abgelehnt wird, bevor irgendeine Nutzlast über die Leitung geht.
5. Die 90-tägige „Stille Rotation“-Übung
Alle 90 Tage führen wir eine „stille Rotation“-Übung durch. Wir signieren einen Test-MQTT-Broker mit einem neuen SPKI-Hash, übertragen den Hash als Backup-Pin auf 5 000 Stifte und beobachten den Handshake-Erfolg auf dem Test-Broker. Wenn 99 % der 5 000 Stifte erfolgreich sind, genehmigen wir die Rotation für die gesamte Flotte.
Die Übung hat die 99,0-%-Schwelle nie unterschritten. Der niedrigste Zyklus war Q3-26 mit 98,4 % (verursacht durch 32 Stifte hinter einem Unternehmens-Proxy, der TLS entschlüsselte – diese 32 Stifte wurden über die OEM-Vereinbarung neu konfiguriert, nicht das Gerät).
6. OEM-Programme mit eigenen Pins
Für OEM-Programme des Musters A (nur T2 und Y6) übergeben wir ein OEM-Portal-Signaturzertifikat, das die HSM des Importeurs neu signieren kann. Das Importportal authentifiziert das Gerät per mTLS. Der Pin-Satz liegt auf dem Secure Element von T2/Y6.
Der OEM bestimmt seinen eigenen Pin-Rotationsrhythmus. Die meisten wählen 12 Monate. Ein 6-Monats-Rhythmus ist bei T2/Y6 in Ordnung, da die geräteseitige Re-Pin-OTA nur 4 600 Byte groß ist und in 1,2 s läuft. Unter 6 Monaten haben wir Druckeffekte im Stil von CR-LATEX-NAGLE auf dem OTA-Kanal beobachtet und empfehlen dies nicht.
| OEM-Pin-Rhythmus | Empfohlen? | OTA-Paketgröße | Zeit im WLAN |
|---|---|---|---|
| 3 Monate | Nein | 4 600 B | 1,2 s |
| 6 Monate | Ja | 4 600 B | 1,2 s |
| 12 Monate | Ja (Standard) | 4 600 B | 1,2 s |
| 24 Monate | Ja (Cloud-MQTT) | 4 600 B | 1,2 s |
7. Was passiert, wenn eine Pin-Abweichung die richtige Antwort ist
Nicht jede Pin-Abweichung ist ein Angriff. Es gibt drei wiederkehrende Fälle, in denen die Abweichung die korrekte Richtlinie ist und das IT-Team der Schule untersuchen sollte:
- Schul-Proxy — Der Proxy signiert TLS neu und bricht dadurch den Pin. Der Stift verweigert die Verbindung. Die Lösung besteht darin, den SPKI-Hash des Proxys über das OEM-Portal zum Stift hinzuzufügen — jedoch nur, wenn sich der Proxy im schulkontrollierten Netzwerk befindet.
- Veraltetes Offline-Wörterbuch — Ein Stift, der 24+ Monate im Lager lag, trifft auf ein Zertifikat, das inzwischen rotiert wurde. Die Lösung ist ein manuelles Neu-Flashen im OEM-Servicecenter.
- Gefälschte Cloud — Jemand hat einen gefälschten MQTT-Broker mit gültiger TLS-Kette aufgebaut. Der Pin verweigert die Verbindung. Der OEM wird über den Ketten-Abweichungsbericht benachrichtigt.
Jeder der drei Fälle hat ein dokumentiertes Handlungs-Runbook, das mit jedem OEM-Vertrag ausgeliefert wird. Schulen, die 12 000 Stifte oder mehr betreiben, erhalten eine 2-stündige Runbook-Einführung.
8. Das Fazit für Distributoren und Ausschreibungen
Certificate Pinning ist der Teil des Lesestifts, der am schwierigsten nachzurüsten ist. Wenn Sie mit einem Anbieter starten, der kein Pinning verwendet, können Sie dies nicht ohne Hardware-Revision hinzufügen. Unsere elf SKUs pinnen bei jedem TLS-Handshake und der Pin-Satz rotiert vierteljährlich in einem getesteten Rhythmus. Jeder Beschaffungsverantwortliche, der dies liest, wird die Formulierung in unserem RFP-Anhang wiedererkennen: "Jeder Endpunkt-SPKI gepinnt, mit Zwei-Hash-Überlappung und 24-monatigem hartem Ablauf."
CTA
Weiterführende Inhalte
- Lesestift TLS 1.2 vs 1.3 und Zertifikat
- Lesestift Kryptografie und TrustZone
- Lesestift Schlüsselverwaltung und HSM
- Lesestift Anti-Rollback und Versionsattestierung
- Lesestift Firmware-Verschlüsselung und Secure Boot
- Lesestift OTA-Firmware-Update-Mechanismus
- Angebot anfordern