14.4.6. Provoz: klíče, expirace a řešení potíží

Práce s certifikáty na každém nasazeném zařízení zahrnuje tři oblasti: ochranu soukromého klíče, jakmile je na kameře, plánování okamžiku, kdy certifikát vyprší, a krátký seznam chybových stavů, které se v praxi objevují.

14.4.6.1. Ochrana soukromého klíče

Kdykoli kamera předkládá certifikát – jako TLS server nebo jako klient v mTLS – musí její soukromý klíč ležet na zařízení, v čistém DER, v souborovém systému nebo v ROMFS. Takto uložený je čitelný jakýmkoli kódem běžícím na kameře a kýmkoli s fyzickým přístupem k ní: prostřednictvím USB mass-storage disku, REPL promptu nebo přímo z flash paměti. ROMFS a příznaky pouze pro čtení brání úpravě, nikoli extrakci. Považujte jakýkoli soukromý klíč dodaný na zařízení za získatelný odhodlaným útočníkem s fyzickým přístupem nebo přístupem ke kódu.

To nečiní TLS zbytečným – formuje to způsob jeho nasazení:

  • Používejte jedinečný klíč a certifikát pro každé zařízení. Nikdy nezapisujte jeden sdílený klíč napříč celou flotilou: jeho extrakce z jediné jednotky by pak útočníkovi umožnila vydávat se za každou kameru. Klíče specifické pro zařízení omezí kompromitaci pouze na dané zařízení, které můžete odvolat nebo zakázat na straně serveru.

  • Udržujte certifikáty s krátkou životností. Odcizený klíč je užitečný pouze po dobu platnosti jeho certifikátu; krátká životnost spolu s rutinní rotací omezuje rozsah škod (viz Expirace a rotace certifikátů níže).

  • Pokud je to možné, vyhněte se umístění tajného klíče na zařízení vůbec. Pokud potřebujete pouze ověřit server (autentizace serveru, nikoli mTLS), kamera jako klient ukládá pouze certifikát CA – který je veřejný – a neobsahuje žádný soukromý klíč, který by stálo za to odcizit.

  • Nikdy nedodávejte klíč ve veřejném firmwarovém obrazu. Klíč zapečený do ROMFS ve firmwarovém buildu, který distribuujete, není tajný; má jej každý, kdo si firmware stáhne. Provisioning pro jednotlivá zařízení znamená naprogramovat klíč po nahrání generického firmwaru, nikoli uvnitř něj.

  • Omezte dosah dopadu. Omezte rozsah toho, co certifikát autentizuje (princip nejmenších oprávnění), a zajistěte, aby bylo možné jedinou uniklou identitu zařízení odvolat nebo zakázat bez vlivu na ostatní.

Pokud váš model hrozeb zahrnuje útočníky s fyzickým přístupem, navrhujte s předpokladem, že klíč zařízení nakonec unikne, a učiňte to přežitelným, namísto předpokladu, že jej lze udržet v tajnosti na hardwaru, který k tomu nemá prostředky.

14.4.6.2. Expirace a rotace certifikátů

Každý certifikát nese platnostní okno. Jakmile uplyne, protějšek typu ssl.CERT_REQUIRED spojení odmítne – expirace je tedy skutečný, naplánovaný výpadek, nikoli teoretické riziko. Hodiny kamery musí být rovněž správné, aby bylo možné kontrolu platnosti vyhodnotit poctivě.

  • Vlastnoručně podepsaný. Životnost jste zvolili pomocí -days. Když uplyne, musíte znovu vygenerovat klíč/certifikát a opět jej nasadit: znovu zkopírovat DER soubory nebo znovu sestavit a přeflashovat ROMFS obraz, pokud je certifikát zapečený. Zvolte hodnotu -days, na kterou si skutečně vzpomenete a podle níž budete jednat.

  • Veřejná CA. Tyto jsou záměrně krátkodobé. Let’s Encrypt vydává 90denní certifikáty a očekává automatickou obnovu zhruba každých 60 dní; možnost „nainstalovat jednou a zapomenout“ neexistuje.

Širší trend je jednosměrný: maximální platnost veřejně důvěryhodných TLS certifikátů se neustále zkracuje. Byla 825 dní, aktuálně je omezena na 398 dní a CA/Browser Forum přijalo plán, který ji do roku 2029 sníží zhruba na 47 dní. Závěr pro návrh zařízení je předpokládat, že certifikáty jsou krátkodobé a že rotace musí být automatizovaná nebo alespoň rutinní – nedodávejte produkt, který závisí na tom, že člověk vymění desetiletý certifikát.

Prakticky na kameře: preferujte návrhy, kde lze certifikát vyměnit bez přeflashování (zapisovatelný souborový systém spolu s cestou pro vzdálenou aktualizaci, nebo provoz kamery jako klienta, který důvěřuje CA rotovanému centrálně). Pokud certifikát musí ležet v ROMFS, naplánujte aktualizace firmwaru podle jeho životnosti.

14.4.6.3. Řešení potíží

  • Hodiny musí být nastaveny. Kamera, která od zapnutí nenastavila své hodiny, neprojde kontrolou platnosti certifikátu – nejprve zavolejte ntptime.settime().

  • Název hostitele se musí shodovat. Když klient předává server_hostname, musí se shodovat s subjectAltName certifikátu (nebo s CN na starších stacích), jinak ověření selže.

  • Špatný formát. PEM soubor zkopírovaný na kameru se nenačte – nejprve jej převeďte na DER.

  • Vypršela platnost certifikátu. Spojení, které dříve fungovalo a nyní selhává s OSError, může mít jednoduše prošlý certifikát – zkontrolujte data platnosti a podle potřeby znovu vygenerujte/nasaďte.

  • Klíče Ed25519 selhávají. Použijte ECDSA P-256/P-384 nebo RSA, nikoli Ed25519.

  • Chyby jsou OSError. MicroPython neimplementuje ssl.SSLError; selhání TLS (chybný certifikát, prošlý, neznámá CA, chyba formátu, selhání handshaku) jsou vyvolána jako OSError.