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 Certificate expiry and rotation 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.