Doelgroep: Dit artikel is geschreven voor inkopers bij schoolministeries, IT-securityverantwoordelijken van merkfabrikanten en OEM-programmamanagers die deze exacte vraag moeten beantwoorden in hun RFP: "hoe weet de leespennen dat deze praat met uw cloud en niet met een proxy?". We doorlopen SPKI-hash pinning, pin-set rotatie-intervallen, de telemetrie die ons vertelt dat een pen probeerde met het verkeerde eindpunt te praten, en het incident-response-playbook dat ons beveiligingsteam gebruikt voor de 11 SKU's in het Smart Reading Pen-assortiment (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6).
Een leespennen is slechts 22% van de wakkere uren online — hij slaapt bij 0,06 mA en wordt wakker bij scan, gebruikersknop, OTA-watchdog. Wanneer hij wakker wordt, heeft hij tussen de 9 en 16 seconden om met de cloud te praten, status te synchroniseren en weer te slapen. Dat 9-tot-16-secondenvenster is precies het venster dat een zakelijke MITM-proxy wil misbruiken. We verdedigen het kanaal met SPKI-hash pinning bij elke TLS-handshake. Dit artikel is de technische diepgang.
Advies voor kopers: Wanneer u twee leveranciers vergelijkt op "TLS 1.3-ondersteuning", is dat geen onderscheidend element — ze doen het allebei. Het onderscheidend element is of de pen de verbinding zal weigeren als het cloudcertificaat onverwachts wijzigt. Vraag naar het productie pin-set rotatie-interval en de toegangscode voor het velddebug-menu. Een leverancier die aarzelt, past geen pinning toe.
1. Waarom standaard TLS niet voldoende is op een embedded device
Een leespennen kan WebPKI niet uitvoeren zoals een browser dat doet. Er is geen automatisch updatekanaal voor de trust store, geen Google CRL-pijplijn, geen Apple pushmelding. Als we de pen met het Mozilla CA-bundel zouden verzenden, zou een CA-compromittering in een van de 140 roots in het bundel ons dwingen 47.000+ pennen terug te roepen. Dus we verzenden geen CA-bundel. We verzenden een pin-set: een kort lijstje van SPKI-hashes die het apparaat zal accepteren als bewijs van identiteit.
Wanneer de pen probeert het cloud MQTT-eindpunt te bereiken op mqtt-eu.smartreadingpen.com, retourneert de TLS-handshake een servercertificaat. De leespennen berekent de SHA-256 van het SubjectPublicKeyInfo van het certificaat (de openbare-sleutelbytes) en vergelijkt die hash met de pin-set die is opgeslagen in het beveiligde element. Als de hash overeenkomt, gaat de verbinding door; zo niet, wordt de verbinding geweigerd en wordt het evenement geregistreerd.
| Cloud-eindpunt | Certificaat | SPKI-hash (SHA-256, eerste 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 (self-signed) | 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 (self-signed) | 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 |
Het patroon met twee vastgezette hashes is expres: elk eindpunt is vastgezet tegen twee SPKI-hashes tegelijk, het huidige productiecertificaat en het volgende certificaat waarnaar we willen overgaan. Rotatie dwingt nooit een veldrecall af.
2. De pin-set indeling in het apparaat
Een typische pin-set op een L5 of Q8 ziet er zo uit in NVM:
pin-set[0] = SPKI-hash (primair) = 15 96 09 ...
pin-set[1] = SPKI-hash (backup) = 96 bc ec ...
pin-set[2] = vervaldatum (epoch 1747) = 2027-01-15
pin-set[3] = vlaggen = PIN_REQUIRED | PIN_LOG_ON_MISS
pin-set[4] = intrekkingslijst (CRL) = 1 item
pin-set[5] = maximale ketenlengte = 3
Vlaggen zijn de operationele hefbomen. PIN_REQUIRED weigert de handshake bij miss. PIN_LOG_ON_MISS schrijft de overtredende SHA-256 en het bron-IP naar NVRAM voor de volgende sync. PIN_LOG_ONLY accepteert de verbinding maar registreert de miss voor diagnose. De vlag PIN_REQUIRED is standaard aan op elke SKU; we hebben PIN_LOG_ONLY gereserveerd voor QA-builds.
3. Het rotatieinterval
Pins gaan niet eeuwig mee. Twee klokken sturen de rotatie: een harde vervaldatum (epoch) en een noodtrigger (CA-compromittering, apparatuurwijziging). Het interval is conservatief omdat we ons geen veldrecall kunnen veroorloven.
| Pin-set | Eigenaar | Harde vervaldatum | Zachte evaluatie | Noodtrigger | Mechanisme |
|---|---|---|---|---|---|
| Cloud MQTT primair | Cloud-team | 24 maanden | 18 maanden | CA-compromittering, MITM-telemetrie | Firmware OTA + SE herflashen |
| Cloud MQTT-back-up | Cloudteam | 24 maanden | 18 maanden | n.v.t. (roteert altijd mee) | Firmware OTA |
| OTA-server | OTA-team | 12 maanden | 9 maanden | OTA-ketenmanipulatie | Firmware OTA + SE |
| OEM-portal | OEM (Pattern A alleen) | 12 maanden | 9 maanden | OEM-verzoek | OEM HSM-zijde |
| Crashreporter | Cloudteam | 36 maanden | 24 maanden | TLS-certificaat vervaldatum | Firmware OTA |
Over 47 000+ geïmplementeerde pennen hebben we de cloud MQTT-pincode-set drie keer geroteerd: één keer in 2023 (cross-signed door Let's Encrypt), één keer in 2024 (alleen ISRG Root X1) en één keer in 2025 (DigiCert intermediate). De dekking van elke rotatie was 99,6% binnen 14 dagen, waarbij de resterende pennen binnen 45 dagen werden gesynchroniseerd via offline OTA via het schooldesktopcradle.
4. Veldtelemetrie: Hoe We Weten Dat Er Een Pinmismatch Is Opgetreden
De pen faalt nooit geruisloos bij een pincontrole. Elke mismatch wordt naar NVRAM geschreven met: tijdstempel (RTC), de SPKI-hash die het probeerde, de endpoint-hostnaam, het opgeloste IP, de certificaatketendikte en de lokale netwerk-SSID (indien verbonden via Wi-Fi). Bij de volgende succesvolle opstart — doorgaans binnen 9 uur — wordt de logboekvermelding geüpload naar de backend via het zakelijke telemetriekanaal.
Een samenvatting van pin-controletelemetrie over 47 000+ geïmplementeerde pennen voor het jaar eindigend op 2026-06:
| Gebeurtenis | Aantal | % van vloot | Mediaan per pen | Actie |
|---|---|---|---|---|
| Succesvolle handshake | 12,4 M | 99,85 % | 264 | normaal |
| Pinmismatch (belastende SPKI-hash) | 18 240 | 0,13 % | 0,39 | beoordeeld |
| Pinmismatch + gekoppelde mismatch | 184 | 0,0014 % | 0,004 | geëscaleerd |
| Geforceerde rotatie na incident | 2 | — | — | post-mortem ingediend |
De 184 gekoppelde mismatches in het jaar eindigend op 2026-06 zijn de interessante gevallen. Deze komen van bedrijfsproxies die het certificaat tijdens de vlucht opnieuw hebben ondertekend. Elk van deze genereerde een supportticket naar de IT-afdeling van de school binnen 48 uur. Geen enkele resulteerde in een datalek omdat de TLS-handshake wordt geweigerd voordat enige payload over de lijn gaat.
5. De 90-Dagen "Stille Rotatie" Oefening
Elke 90 dagen voeren we een "stille rotatie" oefening uit. We ondertekenen een test MQTT-broker met een nieuwe SPKI-hash, pushen de hash als back-up pincode naar 5 000 pennen en kijken of de handshake slaagt op de testbroker. Als 99% van de 5 000 pennen slaagt, keuren we de rotatie goed voor de hele vloot.
De oefening heeft de 99,0%-drempel nooit gehaald. De laagste cyclus was Q3-26 op 98,4% (veroorzaakt door 32 pennen op een bedrijfsproxy die TLS ontsleutelde — die 32 pennen werden opnieuw geconfigureerd via de OEM-overeenkomst, niet het apparaat).
6. OEM-Programma's Die Hun Eigen Pincodes Willen
Voor Pattern A OEM-programma's (alleen T2 en Y6) overhandigen we een OEM-portal-ondertekeningscertificaat dat het HSM van de importeur kan herondertekenen. Het importportaal autentiseert het apparaat via mTLS. De pincode-set wordt op de T2/Y6 secure element bewaard.
De OEM mag zijn eigen pinrotatiecadans instellen. De meesten kiezen voor 12 maanden. Een cadence van 6 maanden is acceptabel op T2/Y6 omdat de on-device re-pin een 4 600-byte OTA is en wordt uitgevoerd in 1,2 s. Onder 6 maanden hebben we CR-LATEX-NAGLE-stijl druk op het OTA-kanaal waargenomen en raden we het af.
| OEM-pincadans | Aanbevolen? | OTA-payloadgrootte | Tijd via Wi-Fi |
|---|---|---|---|
| 3 maanden | Nee | 4 600 B | 1,2 s |
| 6 maanden | Ja | 4 600 B | 1,2 s |
| 12 maanden | Ja (standaard) | 4 600 B | 1,2 s |
| 24 maanden | Ja (cloud MQTT) | 4 600 B | 1,2 s |
7. Wat er gebeurt wanneer een pin-mismatch het juiste antwoord is
Niet elke pin-mismatch is een aanval. We hebben drie terugkerende gevallen waarbij de mismatch het juiste beleid is en het IT-team van de school moet onderzoeken:
- Schoolbedrijfsproxy — De proxy ondertekent TLS opnieuw, waardoor de pin wordt verbroken. De pen weigert. De oplossing is om de SPKI-hash van de proxy toe te voegen aan de pen via het OEM-portaal — maar alleen als de proxy zich op het door de school beheerde netwerk bevindt.
- Verouderd offline woordenboek — Een pen die 24+ maanden in opslag heeft gezeten, raakt een certificaat dat is geroteerd. De oplossing is een handmatige herflashing bij het OEM-servicecentrum.
- Vervalste cloud — Iemand heeft een valse MQTT-broker gebouwd met een geldige TLS-keten. De pin weigert. De OEM wordt gewaarschuwd via het keten-mismatchrapport.
Elk van de drie heeft een gedocumenteerd afhandelingsrunboek dat bij elke OEM-overeenkomst wordt geleverd. Scholen die 12 000 pennen of meer gebruiken, krijgen een 2-uur durende runboek-doorloop.
8. De conclusie voor distributeurs en aanbestedingen
Certificate pinning is het deel van de leespen dat het moeilijkst retroactief kan worden aangebracht. Als u begint met een leverancier die niet pinnt, kunt u dit niet toevoegen zonder een hardware-revisie. Onze elf SKU's pinnen bij elke TLS-handshake en de pin-set roteert elk kwartaal op een geteste cadans. Elke inkopend manager die dit leest, herkent de formulering in onze RFP-bijlage: "elk endpoint SPKI gepind, met twee-hash-overlap en 24 maanden harde vervaldatum."
CTA
Gerelateerd lezen
- Leespen TLS 1.2 vs 1.3 en certificaat
- Leespen cryptografie en TrustZone
- Leespen sleutelbeheer en HSM
- Leespen anti-rollback en versie-attestatie
- Leespen firmwareversleuteling en secure boot
- Leespen OTA-firmware-updatemechanisme
- Offerte aanvragen