14.4.6. Operațiuni: chei, expirare și depanare

Trei aspecte ale lucrului cu certificate apar la orice dispozitiv aflat în producție: protejarea cheii private odată ce aceasta se află pe cameră, planificarea pentru ziua în care certificatul expiră și scurta listă de moduri de eroare care apar în practică.

14.4.6.1. Protejarea cheii private

Ori de câte ori camera prezintă un certificat – ca server TLS sau ca client în mTLS – cheia sa privată trebuie să se afle pe dispozitiv, în format DER simplu, pe sistemul de fișiere sau în ROMFS. Stocată astfel, ea poate fi citită de orice cod care rulează pe cameră și de oricine are acces fizic la aceasta: unitatea de stocare în masă USB, un prompt REPL sau memoria flash brută. ROMFS și marcajele de tip read-only împiedică modificarea, nu extragerea. Considerați orice cheie privată livrată pe un dispozitiv ca fiind recuperabilă de către un atacator hotărât care are acces fizic sau prin cod.

Acest lucru nu face TLS inutil – el modelează modul în care îl implementați:

  • Folosiți o cheie și un certificat unice pentru fiecare dispozitiv. Nu programați niciodată o singură cheie partajată în întreaga flotă: extragerea ei dintr-o singură unitate ar permite atunci unui atacator să se dea drept oricare cameră. Cheile individuale pentru fiecare dispozitiv limitează o compromitere la acel singur dispozitiv, pe care îl puteți revoca sau dezactiva pe partea de server.

  • Păstrați certificatele cu durată scurtă de viață. O cheie furată este utilă doar atâta timp cât certificatul ei este valid; duratele de viață scurte plus rotația de rutină limitează pagubele (consultați mai jos Expirarea și rotația certificatelor).

  • Evitați, pe cât posibil, plasarea unui secret pe dispozitiv. Dacă trebuie doar să verificați serverul (autentificarea serverului, nu mTLS), camera, în calitate de client, stochează doar certificatul CA – care este public – și nu deține nicio cheie privată care să merite furată.

  • Nu livrați niciodată o cheie într-o imagine de firmware publică. O cheie încorporată în ROMFS într-o versiune de firmware pe care o distribuiți nu este secretă; oricine descarcă firmware-ul o deține. Provizionarea individuală pentru fiecare dispozitiv înseamnă programarea cheii după firmware-ul generic, nu în interiorul acestuia.

  • Limitați raza de impact. Restrângeți domeniul a ceea ce autentifică certificatul (principiul privilegiului minim) și asigurați-vă că o singură identitate de dispozitiv compromisă poate fi revocată sau dezactivată fără a afecta restul.

Dacă modelul dumneavoastră de amenințare include atacatori cu acces fizic, proiectați pornind de la premisa că cheia dispozitivului va ajunge până la urmă să fie compromisă și faceți acest lucru suportabil, în loc să presupuneți că poate fi păstrată secretă pe un hardware care nu dispune de niciun mijloc în acest sens.

14.4.6.2. Expirarea și rotația certificatelor

Fiecare certificat are o fereastră de valabilitate. Odată ce aceasta trece, un partener ssl.CERT_REQUIRED respinge conexiunea – astfel încât expirarea este o întrerupere reală și programată, nu un risc teoretic. De asemenea, ceasul camerei trebuie să fie corect pentru ca verificarea valabilității să fie evaluată corect.

  • Auto-semnat. Ați ales durata de viață cu -days. Când aceasta expiră, trebuie să regenerați cheia/certificatul și să le reimplementați: recopiați fișierele DER sau reconstruiți și reprogramați imaginea ROMFS dacă certificatul este încorporat. Alegeți o valoare -days la care chiar vă veți aminti să acționați.

  • CA public. Acestea sunt în mod deliberat cu durată scurtă de viață. Let’s Encrypt emite certificate valabile 90 de zile și se așteaptă la reînnoirea automată aproximativ la fiecare 60 de zile; nu există opțiunea „instalează o singură dată și uită”.

Tendința generală este unidirecțională: valabilitatea maximă a certificatelor TLS de încredere publică se reduce continuu. A fost de 825 de zile, în prezent este plafonată la 398 de zile, iar CA/Browser Forum a adoptat un calendar care o reduce treptat spre aproximativ 47 de zile până în 2029. Concluzia pentru proiectarea unui dispozitiv este să presupuneți că certificatele au durată scurtă de viață și că rotația trebuie să fie automatizată sau cel puțin de rutină – nu livrați un produs care depinde de un om care înlocuiește un certificat valabil zece ani.

În practică, pe cameră: preferați soluțiile în care certificatul poate fi înlocuit fără reprogramare (un sistem de fișiere care permite scrierea plus o cale de actualizare la distanță sau rularea camerei ca client care are încredere într-un CA pe care îl rotiți la nivel central). Dacă un certificat trebuie să se afle în ROMFS, programați actualizările de firmware în funcție de durata sa de viață.

14.4.6.3. Depanare

  • Ceasul trebuie să fie setat. O cameră care nu și-a setat ceasul de la pornire eșuează verificarea valabilității certificatului – apelați mai întâi ntptime.settime().

  • Numele de gazdă trebuie să corespundă. Când clientul transmite server_hostname, acesta trebuie să corespundă cu subjectAltName al certificatului (sau cu CN pe stivele mai vechi), altfel verificarea eșuează.

  • Format greșit. Un fișier PEM copiat pe cameră nu se va încărca – convertiți-l mai întâi în DER.

  • Certificat expirat. O conexiune care funcționa anterior și acum eșuează cu OSError poate avea pur și simplu un certificat expirat – verificați datele de valabilitate și regenerați/reimplementați după caz.

  • Cheile Ed25519 eșuează. Folosiți ECDSA P-256/P-384 sau RSA, nu Ed25519.

  • Erorile sunt OSError. MicroPython nu implementează ssl.SSLError; eșecurile TLS (certificat invalid, expirat, CA necunoscut, eroare de format, eșec de handshake) sunt generate ca OSError.