14.4.6. Üzemeltetés: kulcsok, lejárat és hibaelhárítás

A tanúsítványokkal kapcsolatos munka három területre terjed ki minden telepített eszköznél: a privát kulcs védelme, miután az a kamerára került, a tanúsítvány lejárásának napjára való felkészülés, valamint a gyakorlatban előforduló hibajelenségek rövid listája.

14.4.6.1. A privát kulcs védelme

Valahányszor a kamera bemutat egy tanúsítványt – TLS-kiszolgálóként vagy mTLS-ben kliensként –, a privát kulcsának az eszközön kell lennie, sima DER formátumban, a fájlrendszeren vagy a ROMFS-ben. Így tárolva azt a kamerán futó bármely kód, valamint bárki, akinek fizikai hozzáférése van hozzá, ki tudja olvasni: az USB-háttértár-meghajtó, egy REPL-parancssor vagy a nyers flash memória révén. A ROMFS és a csak olvasható jelzők a módosítást akadályozzák meg, nem a kinyerést. Tekints minden, eszközön szállított privát kulcsot úgy, mint amelyet egy elszánt, fizikai vagy kód-hozzáféréssel rendelkező támadó vissza tud fejteni.

Ettől a TLS még nem válik értelmetlenné – ez csak meghatározza, hogyan telepítsd:

  • Használj eszközönként egyedi kulcsot és tanúsítványt. Soha ne flashelj egyetlen közös kulcsot az egész flottára: ha azt egyetlen egységből kinyerik, a támadó minden kamera személyazonosságát meg tudja hamisítani. Az eszközönkénti kulcsok egyetlen eszközre korlátozzák a kompromittálódást, amelyet a kiszolgáló oldalán visszavonhatsz vagy letilthatsz.

  • Tartsd a tanúsítványokat rövid élettartamúra. Egy ellopott kulcs csak addig hasznos, amíg a tanúsítványa érvényes; a rövid élettartam a rendszeres rotációval együtt korlátozza a kárt (lásd alább a Tanúsítvány lejárata és rotációja című részt).

  • Lehetőség szerint egyáltalán ne tegyél titkot az eszközre. Ha csak a kiszolgálót kell ellenőrizned (kiszolgáló-hitelesítés, nem mTLS), akkor a kliensként működő kamera csak a CA-tanúsítványt tárolja – amely nyilvános –, és nincs nála ellopásra érdemes privát kulcs.

  • Soha ne szállíts kulcsot nyilvános firmware-képben. Egy olyan kulcs, amelyet egy általad terjesztett firmware-buildben a ROMFS-be sütöttek, nem titkos; bárki, aki letölti a firmware-t, hozzájut. Az eszközönkénti kiépítés azt jelenti, hogy a kulcsot az általános firmware után programozod be, nem azon belül.

  • Korlátozd a kár kiterjedését. Szabd meg, mit hitelesít a tanúsítvány (legkisebb jogosultság elve), és gondoskodj arról, hogy egyetlen kiszivárgott eszköz-személyazonosságot vissza lehessen vonni vagy le lehessen tiltani a többi érintése nélkül.

Ha a fenyegetési modelled fizikai hozzáféréssel rendelkező támadókat is tartalmaz, abból a feltételezésből tervezz, hogy az eszköz kulcsa előbb-utóbb ki fog szivárogni, és tedd ezt túlélhetővé, ahelyett, hogy azt feltételeznéd, titokban tartható egy olyan hardveren, amely erre nem nyújt lehetőséget.

14.4.6.2. Tanúsítvány lejárata és rotációja

Minden tanúsítvány hordoz egy érvényességi ablakot. Ha ez letelik, egy ssl.CERT_REQUIRED partner elutasítja a kapcsolatot – így a lejárat valós, ütemezett kiesés, nem elméleti kockázat. A kamera órájának is helyesnek kell lennie, hogy az érvényesség-ellenőrzés tisztességesen kiértékelhető legyen.

  • Önaláírt. Az élettartamot a -days kapcsolóval választottad meg. Amikor letelik, újra kell generálnod a kulcsot/tanúsítványt, és újra kell telepítened: másold át újra a DER-fájlokat, vagy építsd újra és flasheld újra a ROMFS-képet, ha a tanúsítvány bele van sütve. Olyan -days értéket válassz, amelyre tényleg emlékezni fogsz, hogy intézkedj.

  • Nyilvános CA. Ezeket szándékosan rövid élettartamúra tervezték. A Let’s Encrypt 90 napos tanúsítványokat állít ki, és nagyjából 60 naponta automatizált megújítást vár el; nincs „telepítsd egyszer és felejtsd el” lehetőség.

A tágabb tendencia egyirányú: a nyilvánosan megbízható TLS-tanúsítványok maximális érvényessége folyamatosan csökken. Korábban 825 nap volt, jelenleg 398 napban van korlátozva, és a CA/Browser Forum olyan ütemtervet fogadott el, amely 2029-re nagyjából 47 napra csökkenti. A tanulság egy eszköz tervezéséhez az, hogy feltételezd, a tanúsítványok rövid élettartamúak, és hogy a rotációnak automatizáltnak vagy legalább rendszeresnek kell lennie – ne szállíts olyan terméket, amely egy ember általi tízéves tanúsítvány-cserétől függ.

A gyakorlatban, a kamerán: részesítsd előnyben azokat a terveket, ahol a tanúsítvány újraflashelés nélkül cserélhető (egy írható fájlrendszer plusz egy távoli frissítési útvonal, vagy a kamera kliensként való futtatása, amely egy központilag rotált CA-ban bízik). Ha egy tanúsítványnak a ROMFS-ben kell laknia, ütemezd a firmware-frissítéseket az élettartamához igazítva.

14.4.6.3. Hibaelhárítás

  • Az órát be kell állítani. Egy kamera, amely a bekapcsolás óta nem állította be az óráját, megbukik a tanúsítvány érvényesség-ellenőrzésén – előbb hívd meg a ntptime.settime() függvényt.

  • A gazdagépnévnek egyeznie kell. Amikor a kliens átadja a server_hostname értéket, annak egyeznie kell a tanúsítvány subjectAltName mezőjével (vagy régebbi stackeken a CN mezővel), különben az ellenőrzés sikertelen lesz.

  • Hibás formátum. A kamerára másolt PEM-fájl nem fog betöltődni – előbb alakítsd át DER formátumra.

  • A tanúsítvány lejárt. Egy korábban működő kapcsolat, amely most OSError hibával bukik el, lehet, hogy egyszerűen csak lejárt tanúsítvánnyal rendelkezik – ellenőrizd az érvényességi dátumokat, és szükség szerint generáld újra/telepítsd újra.

  • Az Ed25519 kulcsok meghiúsulnak. Használj ECDSA P-256/P-384 vagy RSA kulcsot, ne Ed25519-et.

  • A hibák OSError típusúak. A MicroPython nem implementálja az ssl.SSLError osztályt; a TLS-hibák (hibás tanúsítvány, lejárt, ismeretlen CA, formátumhiba, kézfogási hiba) OSError formájában jelennek meg.