14.4.6. Operacije: ključevi, istek i rješavanje problema

Rad s certifikatima u svakom isporučenom uređaju obuhvaća tri dijela: zaštitu privatnog ključa nakon što se nađe na kameri, planiranje za dan kada certifikat istekne te kratak popis pogrešaka koje se pojavljuju u praksi.

14.4.6.1. Zaštita privatnog ključa

Kad god kamera predstavi certifikat – kao TLS poslužitelj ili kao klijent u mTLS-u – njezin privatni ključ mora se nalaziti na uređaju, u običnom DER obliku, na datotečnom sustavu ili u ROMFS-u. Pohranjen na taj način čitljiv je svakom kodu koji se izvodi na kameri i svakome tko joj ima fizički pristup: USB pogonu za masovnu pohranu, REPL upitu ili sirovoj flash memoriji. ROMFS i oznake samo-za-čitanje sprečavaju izmjenu, a ne izvlačenje. Smatrajte da je svaki privatni ključ isporučen na uređaju oporavljiv od odlučnog napadača s fizičkim pristupom ili pristupom kodu.

To ne čini TLS besmislenim – to oblikuje način na koji ga primjenjujete:

  • Koristite jedinstveni ključ i certifikat po uređaju. Nikada nemojte u cijelu flotu programirati jedan zajednički ključ: izvlačenje iz jedne jedinice tada bi napadaču omogućilo da se lažno predstavlja kao svaka kamera. Ključevi po uređaju zadržavaju kompromitaciju na tom jednom uređaju, koji možete opozvati ili onemogućiti na strani poslužitelja.

  • Neka certifikati budu kratkog vijeka. Ukradeni ključ koristan je samo dok mu je certifikat valjan; kratak vijek trajanja uz redovitu rotaciju ograničava štetu (vidi Certificate expiry and rotation u nastavku).

  • Izbjegavajte stavljanje tajne na uređaj kad god možete. Ako trebate samo provjeriti poslužitelj (provjera autentičnosti poslužitelja, ne mTLS), kamera kao klijent pohranjuje samo CA certifikat – koji je javan – i ne sadrži privatni ključ vrijedan krađe.

  • Nikada nemojte isporučivati ključ u javnoj slici ugrađenog programa (firmware). Ključ ugrađen u ROMFS unutar verzije ugrađenog programa koju distribuirate nije tajan; svatko tko preuzme firmware ima ga. Pripremanje po uređaju znači programiranje ključa nakon generičkog ugrađenog programa, a ne unutar njega.

  • Ograničite opseg štete. Ograničite na najmanju mjeru ono što certifikat autenticira (najmanje privilegije) i pobrinite se da se jedan procurjeli identitet uređaja može opozvati ili onemogućiti bez utjecaja na ostatak.

Ako vaš model prijetnji uključuje napadače s fizičkim pristupom, projektirajte uz pretpostavku da će ključ uređaja na kraju procuriti i učinite to preživljivim, umjesto da pretpostavljate da se može držati u tajnosti na hardveru koji za to nema mogućnosti.

14.4.6.2. Istek i rotacija certifikata

Svaki certifikat nosi razdoblje valjanosti. Kad ono prođe, ravnopravni sudionik s postavkom ssl.CERT_REQUIRED odbija vezu – pa je istek stvarni, zakazani prekid rada, a ne teoretski rizik. Sat kamere također mora biti točan da bi se provjera valjanosti pošteno ocijenila.

  • Samopotpisani. Vijek trajanja odabrali ste s -days. Kad istekne, morate ponovno generirati ključ/certifikat i ponovno ga primijeniti: ponovno kopirati DER datoteke ili ponovno izgraditi i ponovno isprogramirati ROMFS sliku ako je certifikat ugrađen u nju. Odaberite vrijednost za -days na koju ćete se zaista sjetiti reagirati.

  • Javni CA. Oni su namjerno kratkog vijeka. Let’s Encrypt izdaje certifikate na 90 dana i očekuje automatiziranu obnovu otprilike svakih 60 dana; ne postoji opcija „instaliraj jednom i zaboravi”.

Širi je trend jednosmjeran: maksimalna valjanost javno povjerenih TLS certifikata neprestano se smanjuje. Bila je 825 dana, trenutno je ograničena na 398 dana, a CA/Browser Forum usvojio je raspored koji je do 2029. spušta na otprilike 47 dana. Zaključak za dizajn uređaja jest pretpostaviti da su certifikati kratkog vijeka i da rotacija mora biti automatizirana ili barem rutinska – nemojte isporučivati proizvod koji ovisi o tome da čovjek zamijeni desetogodišnji certifikat.

Praktično, na kameri: dajte prednost dizajnima u kojima se certifikat može zamijeniti bez ponovnog programiranja (datotečni sustav s mogućnošću pisanja uz mogućnost daljinskog ažuriranja ili izvođenje kamere kao klijenta koji vjeruje CA-u koji centralno rotirate). Ako certifikat mora živjeti u ROMFS-u, planirajte ažuriranja ugrađenog programa oko njegovog vijeka trajanja.

14.4.6.3. Rješavanje problema

  • Sat mora biti postavljen. Kamera koja nije postavila svoj sat od uključivanja ne prolazi provjeru valjanosti certifikata – najprije pozovite ntptime.settime().

  • Ime hosta mora se podudarati. Kad klijent prosljeđuje server_hostname, ono se mora podudarati s subjectAltName certifikata (ili CN na starijim implementacijama), inače provjera ne uspijeva.

  • Pogrešan format. PEM datoteka kopirana na kameru neće se učitati – najprije je pretvorite u DER.

  • Certifikat je istekao. Veza koja je prije radila, a sada ne uspijeva s OSError, možda jednostavno ima istekli certifikat – provjerite datume valjanosti te ponovno generirajte/primijenite prema potrebi.

  • Ed25519 ključevi ne uspijevaju. Koristite ECDSA P-256/P-384 ili RSA, ne Ed25519.

  • Pogreške su OSError. MicroPython ne implementira ssl.SSLError; TLS greške (loš certifikat, istekao, nepoznat CA, greška formata, neuspjeh rukovanja) podižu se kao OSError.