14.4.6. Operacje: klucze, wygasanie i rozwiązywanie problemów

Trzy elementy pracy z certyfikatami towarzyszą każdemu wdrożonemu urządzeniu: ochrona klucza prywatnego, gdy znajdzie się on już na kamerze, planowanie na dzień, w którym certyfikat wygaśnie, oraz krótka lista trybów błędów, które pojawiają się w praktyce.

14.4.6.1. Ochrona klucza prywatnego

Za każdym razem, gdy kamera przedstawia certyfikat – jako serwer TLS lub jako klient w mTLS – jej klucz prywatny musi znajdować się na urządzeniu, w postaci czystego DER, w systemie plików lub w ROMFS. Przechowywany w ten sposób jest odczytywalny przez dowolny kod działający na kamerze oraz przez każdego, kto ma do niej fizyczny dostęp: dysk pamięci masowej USB, prompt REPL czy surową pamięć flash. ROMFS i flagi tylko do odczytu zapobiegają modyfikacji, a nie wydobyciu. Traktuj każdy klucz prywatny dostarczony na urządzeniu jako możliwy do odzyskania przez zdeterminowanego atakującego mającego dostęp fizyczny lub dostęp do kodu.

Nie czyni to TLS bezużytecznym – kształtuje to sposób, w jaki je wdrażasz:

  • Używaj unikalnego klucza i certyfikatu dla każdego urządzenia. Nigdy nie wgrywaj jednego wspólnego klucza na całą flotę: wydobycie go z pojedynczego egzemplarza pozwoliłoby wówczas atakującemu podszyć się pod każdą kamerę. Klucze per urządzenie ograniczają skutki włamania do tego jednego urządzenia, które możesz unieważnić lub wyłączyć po stronie serwera.

  • Utrzymuj krótki okres ważności certyfikatów. Skradziony klucz jest użyteczny tylko dopóki jego certyfikat jest ważny; krótki czas życia w połączeniu z rutynową rotacją ogranicza szkody (zobacz Certificate expiry and rotation poniżej).

  • Unikaj umieszczania sekretu na urządzeniu, kiedy tylko możesz. Jeśli musisz jedynie zweryfikować serwer (uwierzytelnianie serwera, a nie mTLS), kamera jako klient przechowuje tylko certyfikat CA – który jest publiczny – i nie zawiera żadnego klucza prywatnego wartego kradzieży.

  • Nigdy nie dostarczaj klucza w publicznym obrazie oprogramowania układowego. Klucz wbudowany w ROMFS w dystrybuowanej przez ciebie kompilacji oprogramowania układowego nie jest tajny; każdy, kto pobierze to oprogramowanie układowe, ma do niego dostęp. Provisioning per urządzenie oznacza programowanie klucza po generycznym oprogramowaniu układowym, a nie wewnątrz niego.

  • Ogranicz zasięg rażenia. Ogranicz zakres tego, co certyfikat uwierzytelnia (zasada najmniejszych uprawnień) i upewnij się, że pojedynczą wyciekniętą tożsamość urządzenia można unieważnić lub wyłączyć bez wpływu na resztę.

Jeśli twój model zagrożeń obejmuje atakujących z dostępem fizycznym, projektuj przy założeniu, że klucz urządzenia w końcu wycieknie, i spraw, by było to do przetrwania, zamiast zakładać, że można go utrzymać w tajemnicy na sprzęcie, który nie ma ku temu żadnych środków.

14.4.6.2. Wygasanie i rotacja certyfikatów

Każdy certyfikat zawiera okno ważności. Po jego upływie peer z ssl.CERT_REQUIRED odrzuca połączenie – wygaśnięcie jest zatem realną, zaplanowaną awarią, a nie ryzykiem teoretycznym. Zegar kamery również musi być poprawny, aby sprawdzenie ważności mogło zostać uczciwie ocenione.

  • Self-signed. Czas życia wybrałeś za pomocą -days. Gdy upłynie, musisz ponownie wygenerować klucz/certyfikat i wdrożyć go: ponownie skopiować pliki DER lub przebudować i wgrać ponownie obraz ROMFS, jeśli certyfikat jest w nim wbudowany. Wybierz wartość -days, o której faktycznie będziesz pamiętać, by zadziałać.

  • Publiczne CA. Mają one celowo krótki czas życia. Let’s Encrypt wydaje certyfikaty 90-dniowe i oczekuje zautomatyzowanego odnawiania mniej więcej co 60 dni; nie ma opcji „zainstaluj raz i zapomnij”.

Szerszy trend jest jednokierunkowy: maksymalny okres ważności publicznie zaufanych certyfikatów TLS wciąż się kurczy. Wynosił 825 dni, obecnie jest ograniczony do 398 dni, a CA/Browser Forum przyjęło harmonogram stopniowego obniżania go do około 47 dni do roku 2029. Wniosek dla projektu urządzenia jest taki, by zakładać, że certyfikaty mają krótki czas życia oraz że rotacja musi być zautomatyzowana lub przynajmniej rutynowa – nie dostarczaj produktu, który zależy od człowieka wymieniającego dziesięcioletni certyfikat.

W praktyce, na kamerze: preferuj rozwiązania, w których certyfikat można wymienić bez ponownego wgrywania oprogramowania układowego (zapisywalny system plików plus ścieżka zdalnej aktualizacji lub uruchomienie kamery jako klienta, który ufa CA rotowanemu centralnie). Jeśli certyfikat musi znajdować się w ROMFS, planuj aktualizacje oprogramowania układowego wokół jego czasu życia.

14.4.6.3. Rozwiązywanie problemów

  • Zegar musi być ustawiony. Kamera, która nie ustawiła zegara od czasu włączenia, nie przejdzie sprawdzenia ważności certyfikatu – najpierw wywołaj ntptime.settime().

  • Nazwa hosta musi się zgadzać. Gdy klient przekazuje server_hostname, musi ona odpowiadać polu subjectAltName certyfikatu (lub CN na starszych stosach), w przeciwnym razie weryfikacja się nie powiedzie.

  • Niewłaściwy format. Plik PEM skopiowany na kamerę nie zostanie wczytany – najpierw przekonwertuj go do DER.

  • Certyfikat wygasł. Połączenie, które wcześniej działało, a teraz kończy się niepowodzeniem z OSError, może po prostu mieć wygasły certyfikat – sprawdź daty ważności i ponownie wygeneruj/wdróż w razie potrzeby.

  • Klucze Ed25519 zawodzą. Używaj ECDSA P-256/P-384 lub RSA, a nie Ed25519.

  • Błędy to OSError. MicroPython nie implementuje ssl.SSLError; niepowodzenia TLS (zły certyfikat, wygasły, nieznane CA, błąd formatu, niepowodzenie handshake) są zgłaszane jako OSError.