)
Lesekritt TLS 1.2 vs 1.3 og sertifikatadministrasjon: håndtrykk-latens, batteriforbruk og provisjoneringskostnad
Målgruppe: Denne artikkelen retter seg mot OEM-firmwareingeniører, MDM-sikkerhetsarkitekter og compliance-ansvarlige som må begrunne valget av TLS-versjon, chifferpakke og sertifikatkjede for en flåte av barnas lesekritter. Den benchmarker TLS 1.2 (RFC 5246), TLS 1.3 (RFC 8446) og DTLS 1.3 på tvers av alle 11 aktive SKU-er (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6), med målt håndtrykk-latens, batterikostnad og BOM-konsekvensen av sertifikatlagring.
En EU-pilot i 2025 satte 5 000 lesekritter bak en skoles Palo Alto PA-5220-brannmur. MDM-teamet krevde kun TLS 1.3 og ECDSA-256 serversertifikater. Vår førstegenerasjons firmware 3.1.2 på F8 støttet TLS 1.3 serverside, men hadde ikke ECDSA-klientsertifikater, kun RSA-2048. Resultatet: hver kritt mislyktes i håndtrykket på første forsøk og prøvde igjen med en halvveis ødelagt TLS 1.2-fallback. Håndtrykket tok 4,6 s og brukte 18 mAh per kritt per dag. Etter at vi sendte firmware 3.3.1 med ECDSA-P256-klientstøtte på Q8 og T2, falt håndtrykket til 0,95 s og batterikostnaden til 3,1 mAh per dag.
Denne artikkelen er den tekniske referansen vi skulle ønske vi hadde på dag 1 i den utrullingen. Den er forankret i produksjonsmålinger på 11 SKU-er og vår interne fabrikkakseptansetest.
1. Hvorfor TLS er viktig på en lesekritt
En lesekritt er et «tilkoblet barneprodukt». Under GDPR art. 32, COPPA §312 og PIPL art. 51 behandler kritten personopplysninger om mindreårige. Forpliktelsen om kryptering under overføring er ikke-forhandlbar. Vi avslutter alltid TLS i skybrokeren (MQTT 8883, HTTPS 443) og på OTA-nedlastingsserveren. Firmwaren nekter å sende ut en build med tls=false.
To protokollversjoner er i produksjon:
- TLS 1.2 – støttes på alle SKU-er med Wi-Fi-brikke (alle 11). Obligatorisk grunnlinje. Chifferpakker: ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256.
- TLS 1.3 – støttes på K7, KF1, L5, Q8, T2, Y6. Chifferpakker: TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256. 0-RTT-data ved gjenopptak.
- DTLS 1.3 – støttes kun på Q8, T2. Brukes for CoAP-over-DTLS.
2. TLS-støttematrise for 11 SKU-er
| Modell | TLS 1.2-klient | TLS 1.3-klient | DTLS 1.2-klient | DTLS 1.3-klient | Maskinvare-RNG | Sikkerhetselement | Standard sertifikattype |
|---|---|---|---|---|---|---|---|
| B1 | Ja | Nei | Nei | Nei | Nei | Nei | RSA-2048 |
| B2 | Ja | Nei | Nei | Nei | Nei | Nei | RSA-2048 |
| F8 | Ja | Ja (firmware 3.1.2+) | Nei | Nei | Ja (BK7251 TRNG) | Nei | RSA-2048 |
| K7 | Ja | Ja | Nei | Nei | Ja | Nei | RSA-2048 |
| KF1 | Ja | Ja | Nei | Nei | Ja | Nei | RSA-2048 |
| L5 | Ja | Ja | Nei | Nei | Ja | Nei | RSA-2048 |
| P2 | Ja | Nei | Nei | Nei | Nei | Nei | RSA-2048 |
| Q6 | Ja | Ja | Nei | Nei | Ja | Nei | RSA-2048 |
| Q8 | Ja | Ja | Ja | Ja | Ja | Valgfri ATECC608B | RSA-2048 eller ECDSA-P256 |
| T2 | Ja | Ja | Ja | Ja | Ja | Valgfri ATECC608B | RSA-2048 eller ECDSA-P256 |
| Y6 | Ja | Ja | Nei | Nei | Ja | Nei | RSA-2048 |
Noen få ikke-opplagte fakta i den tabellen. For det første, DTLS (Datagram TLS) er kun nødvendig for CoAP; de fleste penner bruker TCP+TLS. For det andre er en Sikkerhetsbrikke (Microchip ATECC608B eller NXP SE050) valgfri på Q8 og T2 – å legge den til koster $0.62 per enhet og lagrer private nøkler i manipuleringssikker maskinvare. Vi krever sikkerhetsbrikken for alle penner som leveres til Tyskland, Frankrike eller California (CCPA) der manipuleringsrisikoen er ikke ubetydelig. For det tredje er maskinvare-TNGNoen ord om dette: en TRNG (true random number generator) unngår den statistiske svakheten i programvarebaserte RNG-frø som rammet BK7251 rev A i 2022.
Tips til innkjøpere: Hvis compliance-teamet krever FIPS 140-2 eller Common Criteria EAL4+, må du bestille Q8 eller T2 med ATECC608B-sikkerhetselementet. De andre 9 SKU-ene kan ikke oppfylle disse sertifiseringene fordi den private nøkkelen lagres i ren flash.
3. TLS 1.2 vs 1.3-håndtrykket, målt
Et TLS 1.2 ECDHE-RSA-AES128-GCM-SHA256-håndtrykk er to tur-retur-runder pluss sertifikatverifisering. TLS 1.3 med ECDHE-ECDSA-P256 er én tur-retur-runde pluss en kryptert sertifikatverifisering. På en ren Wi-Fi-link er klokketidene i praksis:
Tallene jevner seg ut når du fordeler per SKU:
| Håndtrykksvei | Klokketid (ms) | Bytes på linjen |
|---|---|---|
| TLS 1.2 + RSA-2048 | 1 820 | 6 840 |
| TLS 1.2 + ECDHE-RSA | 1 140 | 5 120 |
| TLS 1.3 + ECDSA-P256 | 950 | 3 860 |
| TLS 1.3 + 0-RTT resume | 240 | 1 180 |
Et 1-RTT-håndtrykk på TLS 1.3 sparer 58 % av latensen til et TLS 1.2 RSA-håndtrykk. På en batteridrevet penn er energibesparelsen enda viktigere: radioen er aktiv omtrent 1,5× lenger ved TLS 1.2.
4. RSA vs ECDSA — BOM-historien
Sertifikater lagres i firmwarebildet eller i et dedikert sikkerhetselement. Størrelser:
| Sertifikattype | DER-størrelse | RAM ved verifisering | ECDHE-tid (ms) | Verifiseringstid (ms) |
|---|---|---|---|---|
| RSA-2048 | 1 042 B | 1,6 KB | 36 | 14 |
| RSA-3072 | 1 506 B | 2,4 KB | 58 | 22 |
| ECDSA-P256 | 480 B | 0,6 KB | 12 | 8 |
| Ed25519 | 460 B | 0,7 KB | 14 | 9 |
ECDSA-P256-sertifikater er 54 % mindre enn RSA-2048 og verifiseres med 57 % kortere CPU-tid. For en flåte på 10 000 penner summerer flash-besparelsen per penn seg: 10 000 × 562 B = 5,6 MB spart OTA-båndbredde per sertifikatrotasjon.
BOM-virkeligheten er at ECDSA-kjeder er litt dyrere å administrere på skysiden. AWS IoT, Azure IoT Hub og de fleste bedrifts-PKI-er tar omtrent det samme for begge nøkkeltyper, så vi anbefaler ECDSA-P256 for alle nye utrullinger.
5. Sertifikatklargjøring ved ICT
En lesepenn må ha et unikt klientsertifikat for å autentisere seg mot skyen. Vår In-Circuit Test (ICT)-prosedyre kjører:
- Pennen kobler seg til klargjørings-VLAN.
- Pennen kaller fabrikkens CA SCEP-endepunkt over HTTPS med en CSR (PKCS#10).
- CA signerer CSR-en med 10 års gyldighet.
- Signert sertifikat skrives til pennens NVM-sektor.
- Pennen starter på nytt og prøver TLS-håndtrykk med MQTT-megleren.
CA-signeringgjennomstrømningen på en Raspberry Pi 4 er 3,4 sertifikater/sekund. Ved ICT-linjehastighet på 60 sekunder/enhet er sertifikatklargjøring kun flaskehalsen ved svært store partier. Vi bruker en 4-node signeringsklynge for å nå 12 sertifikater/sekund for anbud over 20 000 enheter.
For fabrikkgulvkostnad er sertifikatlivssyklusen $0,10 per enhet (RSA-2048) eller $0,06 per enhet (ECDSA-P256). Differansen på 38 % er en av grunnene til at vi anbefaler ECDSA.
6. Strategier for sertifikatrotasjon
Tre rotasjonssykluser er tatt i bruk i kundenes flåter:
- Årlig rotasjon — de fleste skole-MDM-er. Fornyelse via OTA. Kompatibel med alle 11 SKU-er.
- 90-dagers rotasjon — høysikkerhetsdistrikter, datterselskaper i finanssektoren. Krever Q8, T2 med ATECC608B; privat nøkkel kan ikke ekstraheres.
- Rotasjon ved behov — respons ved kompromittering. Vi tvinger rotasjon via OTA på 18 minutter, inkludert nedlasting + installasjon + omstart.
OCSP-stifting og CRL-sjekk er aktivert som standard på Q8, T2-fastvare 3.3.1+. Pennen verifiserer serverens sertifikatkjede og sjekker den stiftede OCSP-responsen. For en flåte på 100 000 penner må OCSP-responderen betjene 100 000 daglige forespørsler — vi driver en Anycast-basert OCSP-responder med 4 PoP-er for å holde p99 under 80 ms.
7. Standarder for chifferpakker
Fabrikkens standardliste over chifferpakker er dokumentert i vår [Compliance Manual]. Den fullstendige rekkefølgen, på L5/Q8/T2/Y6:
TLS 1.3:
TLS_AES_128_GCM_SHA256 (prioritet 1)
TLS_AES_256_GCM_SHA384 (prioritet 2)
TLS_CHACHA20_POLY1305_SHA256 (prioritet 3, reservløsning)
TLS 1.2:
ECDHE-ECDSA-AES128-GCM-SHA256 (prioritet 1)
ECDHE-RSA-AES128-GCM-SHA256 (prioritet 2)
ECDHE-ECDSA-AES256-GCM-SHA384 (prioritet 3)
ECDHE-RSA-AES256-GCM-SHA384 (prioritet 4)
Vi aktiverer aldri AES-CBC, RC4, MD5, SHA-1, 3DES eller chifferpakker med eksportgrad. Et skoledistrikt som kjører en TLS-skanner (testssl.sh, Qualys SSL Labs) mot pennens meglerendepunkt ser kun de grønne chifferpakkene.
8. 0-RTT-data: En subtil fallgruve
TLS 1.3 introduserer 0-RTT-data — klienten kan sende applikasjonsbytes i den aller første flyvningen, før serverens Finished-melding. På en lesepenn sparer dette 240 ms ved gjenopptak, men 0-RTT-data er sårbare for replay-angrep. En angriper som fanger den første flyvningen kan spille den av igjen mot samme server innenfor sesjonsbillettens levetid.
Derfor bruker vi ikke 0-RTT for:
- OTA-fastvarekommandoer (replay ville forårsake re-flash).
- Endringer av foreldrekontrollinnstillinger.
- Poenginnsending med finansiell virkning (betalte historiepakker).
Vi bruker 0-RTT for:
- Telemetri-publiseringer (idempotente, erstattes av neste pakke).
- Tidssynkroniserings-NTP-lignende forespørsler (idempotente).
- Hjerteslag (idempotente).
9. TLS-terminering i skyen
Fabrikkens anbefaling er å avslutte TLS ved sky-megleren (HiveMQ, EMQX, AWS IoT Core) eller ved en CDN-edge (CloudFront, Cloudflare). For skoleløsninger med lokale meglere må IT-teamet håndtere sertifikatrotasjon på megleren. Vi tilbyr en Terraform-modul for AWS IoT Core og et Helm-chart for EMQX på Kubernetes som automatiserer rotasjonen med Let's Encrypt eller en intern CA.
For HIPAA-lignende programmer (vi har ett i det amerikanske Midtvesten for et sykehus' pediatriske leseinitiativ), må mekleren kjøre FIPS-modus OpenSSL. Q8 og T2 med ATECC608B opprettholder FIPS 140-2-grensen; mekleren opprettholder FIPS 140-3-grensen. Ende-til-ende FIPS 140 er en BOM-delta på $0,85 per enhet ved 5 000 MOQ.
11. Gjensidig TLS for skolens MDM-integrasjon
Utover serverautentisering krever flere MDM-plattformer (Jamf School, Mosyle, Microsoft Intune for Education) at pennen autentiserer seg med et klientsertifikat. Vi støtter dette på Q8 og T2 med ATECC608B-sikkerhetselementet; sertifikatets private nøkkel forlater aldri brikken.
MDM-registreringsflyten:
- Skolens IT sender en MDM-profil til lærerens nettbrett.
- Læreren kobler Q8/T2 til nettbrettet over BLE.
- MDM-profilen inneholder en SCEP (Simple Certificate Enrolment Protocol)-endepunkt-URL.
- Pennen kobler til SCEP-endepunktet over HTTPS og presenterer en CSR.
- SCEP CA signerer CSR-en med skolens MDM-under-CA.
- Signert sertifikat skrives til ATECC608B.
- MDM-registrering fullføres.
12. Penetrasjonstesting og OWASP IoT Top 10
Fastvaren vår testes årlig mot OWASP IoT Top 10 (2024-revisjon). Den siste revisjonen dekket 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 og Y6 2.6.4. Revisjonen fant:
- I1 Svake passord — bestått. Fabrikkstandard har ingen passord som kan settes av brukeren; MDM tildeler sterk PSK ved registrering.
- I2 Usikre nettverkstjenester — bestått. Alle tjenester krever TLS 1.2 eller 1.3; klartekstporter (80, 21, 23) er deaktivert.
- I3 Usikre økosystemgrensesnitt — bestått. MDM-API krever gjensidig TLS med ECDSA-P256.
- I4 Manglende mekanisme for sikker oppdatering — bestått. ECDSA-P256 bildesignering, anti-rollback-teller, se TC-046.
- I5 Bruk av usikre komponenter — bestått. Ingen tredjepartsbiblioteker med kjente CVE-er i vår firmware-portefølje.
- I6 Utilstrekkelig personvern — bestått. Telemetri er valgfri; standardleveranse har telemetri deaktivert.
- I7 Usikker dataoverføring — bestått. TLS 1.3 + ECDSA-P256 + 0-RTT-disiplin.
- I8 Mangelfull enhetsadministrasjon — bestått. Full MDM-støtte på Q8, T2.
- I9 Usikre standardinnstillinger — bestått. Fabrikkinnstillingene er de strengeste.
- I10 Mangelfull fysisk herdning — delvis. KF1, L5, Q8, T2, Y6 har tamper-detect-pinner; B1, B2, P2 har det ikke.
Importører kan be om fullstendig revisjonsrapport under NDA. Rapporten er på 84 sider; leveringstiden er 5 virkedager.
13. CRL-distribusjon og OCSP-stapling i praksis
En skoleflåte på 10 000 penner genererer en ikke-triviell PKI-belastning. Hvis hver penn skulle verifisere et serversertifikat ved å kontakte CAens OCSP-responder ved hver TLS-håndtrykk, ville CA-infrastrukturen kollapse. Vi løser dette med OCSP-stapling på megler-siden: megleren henter OCSP-responsen fra CA hver 4. time og stifter den inn i TLS-håndtrykket.
Stiftede OCSP-responser er gyldige i 4 timer (matcher oppdateringskadensen). Pennen verifiserer den stiftede responsen mot CAens offentlige nøkkel, sjekker signaturen og går videre. Hvis den stiftede responsen mangler eller er utløpt, faller pennen tilbake til direkte OCSP og kan stoppe i 200–800 ms.
For CRL-distribusjon kjører vi en daglig Anycast-responder ved 4 PoP-er (Singapore, Frankfurt, Virginia, São Paulo). CRL-en er på 48 KB; pennene henter den via HTTP range-forespørsel ved hvert vellykkede TLS-håndtrykk (bufret i 24 timer). Den kumulative båndbredden per penn per dag er 2 KB. CRL-feilrate på Q8/T2-firmware 3.3.1 er 0,04 % over 47 000+ leverte penner.
| Samsvarsregime | Anbefalt SKU | TLS-versjon | Nøkkeltype | Sikkerhetselement |
|---|---|---|---|---|
| GDPR + COPPA | Q8 eller T2 | TLS 1.3 | ECDSA-P256 | Valgfritt |
| CCPA + California-skoler | Q8 eller T2 | TLS 1.3 | ECDSA-P256 | Anbefalt |
| HIPAA pediatrisk program | Q8 eller T2 | TLS 1.3 | ECDSA-P256 | Påkrevd (ATECC608B) |
| PIPL Kina-program | Q8 eller T2 | TLS 1.3 | SM2-innpakket | Påkrevd (tilpasset CA) |
| LGPD Brasil | L5, Q6, Q8, T2, Y6 | TLS 1.2 eller 1.3 | ECDSA-P256 | Valgfritt |
| Sub-$10 engros | P2 | Kun TLS 1.2 | RSA-2048 | Nei |
For alle nye utrullinger er vår anbefaling TLS 1.3 + ECDSA-P256 med ATECC608B for enhver penn over $25 i detaljhandel-ASP. Håndtrykk-latensbesparelsen, reduksjonen av sertifikatstørrelsen og den sikre nøkkellagringen er det rette tekniske grunnlaget for 2026–2028.
Relatert lesing
- IoT MQTT vs HTTP vs CoAP
- Datakryptering AES-128 vs AES-256
- OTA fastvareoppdateringsmekanisme
- Wi-Fi-roaming og tilkobling på nytt
- GDPR og databeskyttelse i EU
- COPPA og foreldrekontroll