Reading Pen TLS 1.2 vs. 1.3 und Zertifikatsverwaltung: Handshake-Latenz, Akku und Provisioning-Kosten

Zielgruppe: Dieser Artikel richtet sich an OEM-Firmware-Ingenieure, MDM-Sicherheitsarchitekten und Compliance-Verantwortliche, die die TLS-Version, Cipher Suite und Zertifikatskette für eine Flotte von Kinder-Lesestiften rechtfertigen müssen. Er benchmarkt TLS 1.2 (RFC 5246), TLS 1.3 (RFC 8446) und DTLS 1.3 über alle 11 aktiven SKUs (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6), mit gemessener Handshake-Latenz, Akkuverbrauch und BOM-Auswirkung der Zertifikatsspeicherung.

Ein EU-Pilotprojekt 2025 setzte 5.000 Lesestifte hinter einer Palo-Alto-PA-5220-Firewall einer Schule ein. Das MDM-Team schrieb ausschließlich TLS 1.3 sowie ECDSA-256-Serverzertifikate vor. Unsere Firmware der ersten Generation 3.1.2 auf F8 unterstützte serverseitig TLS 1.3, verfügte jedoch nicht über ECDSA-Client-Zertifikate, sondern nur über RSA-2048. Das Ergebnis: Jeder Stift scheiterte beim ersten Handshake-Versuch und wiederholte ihn mit einem halb funktionsfähigen TLS-1.2-Fallback. Der Handshake dauerte 4,6 s und verbrauchte 18 mAh pro Stift und Tag. Nachdem wir die Firmware 3.3.1 mit ECDSA-P256-Client-Unterstützung auf Q8 und T2 ausgeliefert hatten, sank der Handshake auf 0,95 s und der Akkuverbrauch auf 3,1 mAh pro Tag.

Dieser Artikel ist die Engineering-Referenz, die wir uns am Tag 1 dieses Rollouts gewünscht hätten. Er basiert auf Produktionsmessungen an 11 SKUs und unserem internen Factory-Acceptance-Test.

1. Warum TLS bei einem Lesestift wichtig ist

Ein Lesestift ist ein „vernetztes Kinderprodukt“. Gemäß DSGVO Art. 32, COPPA §312 und PIPL Art. 51 verarbeitet der Stift personenbezogene Daten Minderjähriger. Die Verpflichtung zur Verschlüsselung in Transit ist nicht verhandelbar. Wir beenden TLS immer am Cloud-Broker (MQTT 8883, HTTPS 443) und am OTA-Downloadserver. Die Firmware weigert sich, einen Build mit tls=false.

Zwei Protokollversionen sind in Produktion:

• TLS 1.2 — unterstützt auf jedem SKU mit einem Wi-Fi-Chip (alle 11). Pflicht-Baseline. Cipher Suites: ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256.
• TLS 1.3 — unterstützt auf K7, KF1, L5, Q8, T2, Y6. Cipher Suites: TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256. 0-RTT-Daten bei Resume.
• DTLS 1.3 — unterstützt nur auf Q8, T2. Verwendung für CoAP-over-DTLS.

2. Die TLS-Unterstützungsmatrix der 11 SKUs

Einige weniger offensichtliche Fakten in dieser Tabelle. Erstens, DTLS (Datagram TLS) wird nur für CoAP benötigt; die meisten Stifte nutzen TCP+TLS. Zweitens ist ein Secure Element (Microchip ATECC608B oder NXP SE050) bei Q8 und T2 optional – die Hinzunahme kostet 0,62 $ pro Einheit und speichert private Schlüssel in manipulationssicherer Hardware. Wir schreiben das Secure Element für jeden Stift vor, der nach Deutschland, Frankreich oder Kalifornien (CCPA) geliefert wird, wo Manipulationsrisiken nicht unerheblich sind. Drittens ist der Hardware-RNG wichtig: Ein TRNG (True Random Number Generator) umgeht die statistische Schwäche von Software-RNG-Seeds, die den BK7251 rev A im Jahr 2022 betraf.

Käuferhinweis: Wenn Ihr Compliance-Team FIPS 140-2 oder Common Criteria EAL4+ verlangt, müssen Sie Q8 oder T2 mit dem ATECC608B Secure Element bestellen. Die anderen 9 SKUs können diese Zertifizierungen nicht erfüllen, da der private Schlüssel im unverschlüsselten Flash gespeichert wird.

3. Der TLS 1.2 vs. 1.3 Handshake, gemessen

Ein TLS 1.2 ECDHE-RSA-AES128-GCM-SHA256 Handshake benötigt zwei Round-Trips plus die Zertifikatsverifikation. TLS 1.3 mit ECDHE-ECDSA-P256 benötigt einen Round-Trip plus eine verschlüsselte Zertifikatsverifikation. In einer sauberen Wi-Fi-Verbindung ergeben sich folgende Echtzeitwerte:

Die Werte relativieren sich, wenn man nach SKU aufschlüsselt:

Ein 1-RTT-Handshake auf TLS 1.3 spart 58 % der Latenz eines TLS 1.2 RSA-Handshakes. Bei einem batteriebetriebenen Pen ist die Energieeinsparung noch wichtiger: Das Funkmodul bleibt bei TLS 1.2 etwa 1,5-mal länger aktiv.

4. RSA vs. ECDSA – Die BOM-Perspektive

Zertifikate werden im Firmware-Image oder in einem dedizierten Secure Element gespeichert. Größen:

ECDSA-P256-Zertifikate sind 54 % kleiner als RSA-2048 und werden in 57 % weniger CPU-Zeit verifiziert. Bei einer Flotte von 10.000 Pens summiert sich die Flash-Einsparung pro Pen: 10.000 × 562 B = 5,6 MB kumulative OTA-Bandbreite, die pro Zertifikatsrotation eingespart wird.

Die BOM-Realität ist, dass ECDSA-Ketten auf der Cloud-Seite geringfügig teurer in der Verwaltung sind. AWS IoT, Azure IoT Hub und die meisten Enterprise-PKIs verlangen für beide Schlüsseltypen ungefähr dasselbe, daher empfehlen wir ECDSA-P256 für alle neuen Bereitstellungen.

5. Zertifikatsbereitstellung im ICT

Ein Lesestift benötigt ein eindeutiges Client-Zertifikat, um sich gegenüber der Cloud zu authentifizieren. Unsere In-Circuit-Test-Prozedur (ICT) führt Folgendes aus:

1. Stift tritt dem Bereitstellungs-VLAN bei.
2. Stift ruft den SCEP-Endpunkt der Factory-CA per HTTPS mit einer CSR (PKCS#10) auf.
3. CA signiert die CSR mit 10-jähriger Gültigkeit.
4. Signiertes Zertifikat wird in den NVM-Sektor des Stifts geschrieben.
5. Stift startet neu und versucht den TLS-Handshake mit dem MQTT-Broker.

Der CA-Signaturdurchsatz auf einem Raspberry Pi 4 beträgt 3,4 Zertifikate/Sekunde. Bei einer ICT-Taktrate von 60 Sekunden pro Einheit ist die Zertifikatsbereitstellung nur bei sehr großen Chargen der Engpass. Wir verwenden ein 4-Knoten-Signaturcluster, um 12 Zertifikate pro Sekunde für Ausschreibungen über 20.000 Einheiten zu erreichen.

Für die Werkshallenkosten beträgt der Zertifikatslebenszyklus 0,10 $ pro Einheit (RSA-2048) oder 0,06 $ pro Einheit (ECDSA-P256). Die Differenz von 38 % ist einer der Gründe, warum wir ECDSA empfehlen.

6. Zertifikatsrotationsstrategien

Drei Rotationszyklen werden in Kundenflotten eingesetzt:

• Jährliche Rotation — die meisten Schul-MDMs. Erneuerung über OTA. Kompatibel mit allen 11 SKUs.
• 90-Tage-Rotation — Hochsicherheitsbezirke, Tochtergesellschaften im Finanzsektor. Erfordert Q8, T2 mit ATECC608B; der private Schlüssel kann nicht extrahiert werden.
• Rotation auf Abruf — Reaktion auf Kompromittierung. Wir erzwingen die Rotation per OTA in 18 Minuten, einschließlich Download + Installation + Neustart.

OCSP-Stapling und CRL-Prüfung sind standardmäßig auf Q8, T2-Firmware 3.3.1+ aktiviert. Der Stift verifiziert die Serverzertifikatskette und prüft die gestapelte OCSP-Antwort. Bei einer Flotte von 100.000 Stiften muss der OCSP-Responder 100.000 tägliche Anfragen bedienen – wir betreiben einen Anycast-basierten OCSP-Responder mit 4 PoPs, um p99 unter 80 ms zu halten.

7. Standard-Cipher-Suites

Die werksseitige Standard-Cipher-Suite-Liste ist in unserer [Compliance Manual] dokumentiert. Die vollständige Reihenfolge auf L5/Q8/T2/Y6:

TLS 1.3:
  TLS_AES_128_GCM_SHA256         (Priorität 1)
  TLS_AES_256_GCM_SHA384         (Priorität 2)
  TLS_CHACHA20_POLY1305_SHA256   (Priorität 3, Fallback)

TLS 1.2:
  ECDHE-ECDSA-AES128-GCM-SHA256  (Priorität 1)
  ECDHE-RSA-AES128-GCM-SHA256    (Priorität 2)
  ECDHE-ECDSA-AES256-GCM-SHA384  (Priorität 3)
  ECDHE-RSA-AES256-GCM-SHA384    (Priorität 4)

Wir aktivieren niemals AES-CBC, RC4, MD5, SHA-1, 3DES oder Export-Grade-Cipher. Ein Schulbezirk, der einen TLS-Scanner (testssl.sh, Qualys SSL Labs) gegen den Broker-Endpunkt des Stifts ausführt, sieht nur die grünen Cipher-Suites.

8. 0-RTT-Daten: Eine subtile Falle

TLS 1.3 führt 0-RTT-Daten ein – der Client kann Anwendungsbytes bereits im allerersten Flug senden, vor der Finished-Nachricht des Servers. Bei einem Lesestift spart dies 240 ms beim Resume, aber 0-RTT-Daten sind anfällig für Replay-Angriffe. Ein Angreifer, der den ersten Flug abfängt, kann ihn innerhalb der Session-Ticket-Lebensdauer gegen denselben Server wiederholen.

Wir verwenden daher kein 0-RTT für:

• OTA-Firmware-Befehle (Replay würde erneutes Flashen verursachen).
• Änderungen der Kindersicherung.
• Punktestand-Übermittlungen mit finanzieller Auswirkung (kostenpflichtige Story-Pakete).

Wir verwenden 0-RTT für:

• Telemetrie-Veröffentlichungen (idempotent, durch das nächste Paket überholt).
• NTP-ähnliche Zeitsynchronisationsanfragen (idempotent).
• Heartbeats (idempotent).

9. TLS-Beendigung auf der Cloud-Seite

Die Werksempfehlung ist, TLS am Cloud-Broker (HiveMQ, EMQX, AWS IoT Core) oder an einer CDN-Edge (CloudFront, Cloudflare) zu terminieren. Für Schulbereitstellungen mit On-Premise-Brokern muss das IT-Team die Zertifikatsrotation auf dem Broker verwalten. Wir stellen ein Terraform-Modul für AWS IoT Core und ein Helm-Chart für EMQX auf Kubernetes bereit, das die Rotation mit Let's Encrypt oder einer internen CA automatisiert.

Für HIPAA-ähnliche Programme (wir haben eines im Mittleren Westen der USA für eine pädiatrische Lese-Initiative eines Krankenhauses) muss der Broker FIPS-Mode-OpenSSL ausführen. Q8 und T2 mit ATECC608B halten die FIPS-140-2-Grenze; der Broker hält die FIPS-140-3-Grenze. End-to-End-FIPS-140 bedeutet einen BOM-Aufschlag von 0,85 $ pro Einheit bei 5.000 MOQ.

11. Mutual TLS für die Schul-MDM-Integration

Über die Server-Authentifizierung hinaus verlangen mehrere MDM-Plattformen (Jamf School, Mosyle, Microsoft Intune for Education), dass sich der Stift mit einem Client-Zertifikat authentifiziert. Wir unterstützen dies auf Q8 und T2 mit dem Secure-Element ATECC608B; der private Schlüssel des Zertifikats verlässt den Chip nie.

Der MDM-Enrolment-Ablauf:

1. Schul-IT überträgt ein MDM-Profil auf das Tablet des Lehrers.
2. Lehrer koppelt Q8/T2 über BLE mit dem Tablet.
3. Das MDM-Profil enthält eine SCEP-Endpunkt-URL (Simple Certificate Enrolment Protocol).
4. Stift verbindet sich per HTTPS mit dem SCEP-Endpunkt und legt eine CSR vor.
5. SCEP-CA signiert die CSR mit der MDM-Sub-CA der Schule.
6. Signiertes Zertifikat wird in den ATECC608B geschrieben.
7. MDM-Enrolment wird abgeschlossen.

12. Penetrationstests und OWASP IoT Top 10

Unsere Firmware wird jährlich gegen die OWASP IoT Top 10 (Revision 2024) getestet. Die letzte Prüfung umfasste F8 3.1.2, K7 1.9.5, KF1 1.9.5, L5 4.2.0, Q6 3.3.1, Q8 3.3.1, T2 3.3.1 und Y6 2.6.4. Die Prüfung ergab:

• I1 Schwache Passwörter — bestanden. Werksseitig gibt es kein vom Benutzer festlegbares Passwort; das MDM weist beim Enrolment einen starken PSK zu.
• I2 Unsichere Netzwerkdienste — bestanden. Alle Dienste erfordern TLS 1.2 oder 1.3; Klartext-Ports (80, 21, 23) sind deaktiviert.
• I3 Unsichere Ökosystem-Schnittstellen — bestanden. Die MDM-API erfordert Mutual TLS mit ECDSA-P256.
• I4 Fehlender sicherer Update-Mechanismus — bestanden. ECDSA-P256 Image-Signing, Anti-Rollback-Zähler, siehe TC-046.
• I5 Verwendung unsicherer Komponenten — bestanden. Keine Drittanbieter-Bibliotheken mit bekannten CVEs in unserer Firmware.
• I6 Unzureichender Datenschutz — bestanden. Telemetrie ist Opt-in; die Standardauslieferung erfolgt mit deaktivierter Telemetrie.
• I7 Unsichere Datenübertragung — bestanden. TLS 1.3 + ECDSA-P256 + 0-RTT-Disziplin.
• I8 Fehlendes Gerätemanagement — bestanden. Volle MDM-Unterstützung bei Q8, T2.
• I9 Unsichere Standardeinstellungen — bestanden. Werkseinstellungen sind die restriktivsten.
• I10 Fehlende physische Härtung — teilweise. KF1, L5, Q8, T2, Y6 verfügen über Tamper-Detect-Pins; B1, B2, P2 nicht.

Importeure können den vollständigen Auditbericht unter NDA anfordern. Der Bericht umfasst 84 Seiten; die Bearbeitungszeit beträgt 5 Werktage.

13. CRL-Verteilung und OCSP-Stapling in der Praxis

Eine Schulflotte von 10.000 Stiften erzeugt eine nicht triviale PKI-Last. Würde jeder Stift bei jedem TLS-Handshake ein Serverzertifikat durch direkte Anfrage beim OCSP-Responder der CA verifizieren, würde die CA-Infrastruktur kollabieren. Wir lösen dies durch OCSP-Stapling auf der Broker-Seite: Der Broker ruft die OCSP-Antwort alle 4 Stunden von der CA ab und heftet sie in den TLS-Handshake ein.

Eingestapelte OCSP-Antworten sind 4 Stunden gültig (entsprechend der Aktualisierungskadenz). Der Stift prüft die eingestapelte Antwort anhand des öffentlichen CA-Schlüssels, validiert die Signatur und fährt fort. Fehlt die eingestapelte Antwort oder ist sie abgelaufen, fällt der Stift auf direktes OCSP zurück und kann 200–800 ms blockiert sein.

Für die CRL-Verteilung betreiben wir einen täglichen Anycast-Responder an 4 PoPs (Singapur, Frankfurt, Virginia, São Paulo). Die CRL ist 48 KB groß; die Stifte rufen sie über HTTP-Range-Request bei jedem erfolgreichen TLS-Handshake ab (24 Stunden zwischengespeichert). Die kumulierte Bandbreite pro Stift und Tag beträgt 2 KB. Die CRL-Fehlerrate auf Q8/T2-Firmware 3.3.1 liegt bei 0,04 % über 47.000+ ausgelieferte Stifte.

Für alle neuen Deployments empfehlen wir TLS 1.3 + ECDSA-P256 mit ATECC608B für jeden Stift über 25 USD Einzelhandels-ASP. Die Latenzersparnis beim Handshake, die Reduzierung der Zertifikatsgröße und die sichere Schlüsselspeicherung sind die richtige technische Basis für 2026–2028.

Weiterführende Literatur

• IoT MQTT vs. HTTP vs. CoAP
• Datenverschlüsselung AES-128 vs. AES-256
• OTA-Firmware-Update-Mechanismus
• Wi-Fi-Roaming und Wiederverbindung
• DSGVO und Datenschutz in der EU
• COPPA und Kindersicherung