14.4.6. Käyttö: avaimet, vanheneminen ja vianmääritys

Jokaista käyttöön otettua laitetta koskee kolme varmenteisiin liittyvää työtehtävää: yksityisen avaimen suojaaminen sen päädyttyä kameralle, varautuminen siihen päivään jolloin varmenne vanhenee, sekä lyhyt lista virhetilanteista joita käytännössä esiintyy.

14.4.6.1. Yksityisen avaimen suojaaminen

Aina kun kamera esittää varmenteen – TLS-palvelimena tai mTLS:n asiakkaana – sen yksityisen avaimen on sijaittava laitteella, selkokielisessä DER-muodossa, tiedostojärjestelmässä tai ROMFS:ssä. Näin tallennettuna sen voi lukea mikä tahansa kameralla suoritettava koodi ja kuka tahansa jolla on fyysinen pääsy laitteeseen: USB-massamuistiasema, REPL-kehote tai raaka flash-muisti. ROMFS ja vain luku -liput estävät muokkaamisen, eivät poimimista. Oleta että minkä tahansa laitteella toimitetun yksityisen avaimen voi palauttaa määrätietoinen hyökkääjä, jolla on fyysinen tai koodipohjainen pääsy.

Tämä ei tee TLS:stä turhaa – se vaikuttaa siihen, miten otat sen käyttöön:

  • Käytä jokaisella laitteella yksilöllistä avainta ja vardetta. Älä koskaan flashaa yhtä jaettua avainta koko laitekantaan: sen poimiminen yhdestä yksiköstä antaisi hyökkääjälle mahdollisuuden esiintyä jokaisena kamerana. Laitekohtaiset avaimet rajaavat tietomurron tuohon yhteen laitteeseen, jonka voit kumota tai poistaa käytöstä palvelinpuolella.

  • Pidä varmenteet lyhytikäisinä. Varastettu avain on hyödyllinen vain niin kauan kuin sen varmenne on voimassa; lyhyet voimassaoloajat ja säännöllinen kierrätys rajaavat vahingon (ks. Varmenteen vanheneminen ja kierrätys alla).

  • Vältä salaisuuden tallentamista laitteelle aina kun voit. Jos sinun tarvitsee vain todentaa palvelin (palvelimen todennus, ei mTLS), kamera asiakkaana tallentaa vain CA-varmenteen – joka on julkinen – eikä sisällä mitään varastamisen arvoista yksityistä avainta.

  • Älä koskaan toimita avainta julkisessa laiteohjelmiston levykuvassa. ROMFS:ään paistettu avain jakelemassasi laiteohjelmistokäännöksessä ei ole salainen; kuka tahansa joka lataa laiteohjelmiston saa sen. Laitekohtainen valmistelu tarkoittaa avaimen ohjelmointia yleisen laiteohjelmiston jälkeen, ei sen sisään.

  • Rajoita vaikutusaluetta. Rajaa se mihin varmenne todentaa (pienin mahdollinen oikeus), ja varmista että yksittäisen vuotaneen laiteidentiteetin voi kumota tai poistaa käytöstä vaikuttamatta muihin.

Jos uhkamallisi sisältää hyökkääjiä joilla on fyysinen pääsy, suunnittele olettaen että laitteen avain tulee lopulta vuotamaan ja tee siitä selviytyvä, sen sijaan että olettaisit sen pysyvän salassa laitteistossa jossa ei ole mitään keinoa siihen.

14.4.6.2. Varmenteen vanheneminen ja kierrätys

Jokaisella varmenteella on voimassaoloaika. Kun se umpeutuu, ssl.CERT_REQUIRED -vertaisosapuoli hylkää yhteyden – joten vanheneminen on todellinen, aikataulutettu käyttökatko, ei teoreettinen riski. Myös kameran kellon on oltava oikeassa, jotta voimassaolotarkistus voidaan arvioida luotettavasti.

  • Itse allekirjoitettu. Valitsit voimassaoloajan parametrilla -days. Kun se umpeutuu, sinun on luotava avain/varmenne uudelleen ja otettava se uudelleen käyttöön: kopioi DER-tiedostot uudelleen, tai rakenna uudelleen ja flashaa ROMFS-levykuva uudelleen, jos varmenne on paistettu sisään. Valitse -days-arvo, jonka mukaan muistat todella toimia.

  • Julkinen CA. Nämä ovat tarkoituksella lyhytikäisiä. Let’s Encrypt myöntää 90 päivän varmenteita ja odottaa automaattista uusimista suunnilleen joka 60. päivä; ”asenna kerran ja unohda” -vaihtoehtoa ei ole.

Laajempi suuntaus on yksisuuntainen: julkisesti luotettujen TLS-varmenteiden enimmäisvoimassaolo lyhenee jatkuvasti. Se oli 825 päivää, on tällä hetkellä rajattu 398 päivään, ja CA/Browser Forum on hyväksynyt aikataulun joka laskee sen noin 47 päivään vuoteen 2029 mennessä. Laitesuunnittelun kannalta johtopäätös on olettaa että varmenteet ovat lyhytikäisiä ja että kierrätyksen on oltava automatisoitua tai vähintään rutiininomaista – älä toimita tuotetta joka riippuu siitä että ihminen vaihtaa kymmenen vuoden varmenteen.

Käytännössä kameralla: suosi suunnitelmia joissa varmenteen voi korvata flashaamatta uudelleen (kirjoitettava tiedostojärjestelmä sekä etäpäivityspolku, tai kameran ajaminen asiakkaana joka luottaa keskitetysti kierrättämääsi CA:han). Jos varmenteen on sijaittava ROMFS:ssä, aikatauluta laiteohjelmistopäivitykset sen voimassaoloajan mukaan.

14.4.6.3. Vianmääritys

  • Kello on asetettava. Kamera joka ei ole asettanut kelloaan käynnistyksen jälkeen epäonnistuu varmenteen voimassaolotarkistuksessa – kutsu ensin ntptime.settime().

  • Isäntänimen on täsmättävä. Kun asiakas välittää server_hostname-arvon, sen on täsmättävä varmenteen subjectAltName-kentän kanssa (tai CN-kentän vanhemmissa pinoissa), tai todennus epäonnistuu.

  • Väärä muoto. Kameralle kopioitu PEM-tiedosto ei lataudu – muunna ensin DER-muotoon.

  • Varmenne vanhentunut. Yhteys joka aiemmin toimi ja nyt epäonnistuu virheellä OSError saattaa yksinkertaisesti johtua vanhentuneesta varmenteesta – tarkista voimassaolopäivät ja luo uudelleen / ota uudelleen käyttöön tarpeen mukaan.

  • Ed25519-avaimet epäonnistuvat. Käytä ECDSA P-256/P-384:ää tai RSA:ta, älä Ed25519:ää.

  • Virheet ovat OSError. MicroPython ei toteuta ssl.SSLError-luokkaa; TLS-virheet (viallinen varmenne, vanhentunut, tuntematon CA, muotovirhe, kättelyvirhe) nostetaan OSError-virheinä.