14.4.6. Operasi: kunci, kedaluwarsa, dan pemecahan masalah

Tiga aspek pekerjaan sertifikat mencakup setiap perangkat yang telah diterapkan: melindungi kunci privat setelah berada di kamera, merencanakan hari sertifikat kedaluwarsa, dan daftar pendek mode kesalahan yang muncul dalam praktik.

14.4.6.1. Melindungi kunci privat

Setiap kali kamera menyajikan sertifikat -- sebagai server TLS, atau sebagai klien dalam mTLS -- kunci privatnya harus berada di perangkat, dalam format DER biasa, di sistem file atau di ROMFS. Disimpan dengan cara itu, kunci dapat dibaca oleh kode apa pun yang berjalan di kamera dan oleh siapa pun yang memiliki akses fisik ke dalamnya: drive USB mass-storage, prompt REPL, atau flash mentah. ROMFS dan tanda baca-saja mencegah modifikasi, bukan ekstraksi. Perlakukan setiap kunci privat yang dikirimkan pada perangkat sebagai dapat dipulihkan oleh penyerang yang bertekad dengan akses fisik atau kode.

Ini tidak membuat TLS menjadi tidak berguna -- hal ini membentuk cara Anda menerapkannya:

  • Gunakan kunci dan sertifikat unik per perangkat. Jangan pernah mem-flash satu kunci yang digunakan bersama ke seluruh armada: mengekstraknya dari satu unit akan memungkinkan penyerang menyamar sebagai setiap kamera. Kunci per perangkat membatasi kompromi hanya pada satu perangkat tersebut, yang dapat Anda cabut atau nonaktifkan dari sisi server.

  • Buat sertifikat berumur pendek. Kunci yang dicuri hanya berguna selama sertifikatnya masih valid; masa hidup singkat ditambah rotasi rutin membatasi kerusakan (lihat Certificate expiry and rotation di bawah).

  • Hindari menyimpan rahasia di perangkat sama sekali jika memungkinkan. Jika Anda hanya perlu memverifikasi server (autentikasi server, bukan mTLS), kamera sebagai klien hanya menyimpan sertifikat CA -- yang bersifat publik -- dan tidak menyimpan kunci privat yang berharga untuk dicuri.

  • Jangan pernah menyertakan kunci dalam citra firmware publik. Kunci yang dipanggang ke ROMFS dalam build firmware yang Anda distribusikan tidak bersifat rahasia; siapa pun yang mengunduh firmware memilikinya. Provisi per perangkat berarti memprogram kunci setelah firmware generik, bukan di dalamnya.

  • Batasi radius ledakan. Batasi cakupan yang diautentikasi oleh sertifikat (hak istimewa minimum), dan pastikan identitas perangkat yang bocor dapat dicabut atau dinonaktifkan tanpa mempengaruhi yang lain.

Jika model ancaman Anda mencakup penyerang dengan akses fisik, desainlah dengan asumsi bahwa kunci perangkat pada akhirnya akan bocor dan buatlah hal itu bisa ditanggulangi, daripada mengasumsikan bahwa kunci tersebut dapat dirahasiakan pada perangkat keras yang tidak memiliki fasilitas untuk melakukannya.

14.4.6.2. Kedaluwarsa dan rotasi sertifikat

Setiap sertifikat memiliki jendela validitas. Setelah berlalu, peer ssl.CERT_REQUIRED menolak koneksi -- sehingga kedaluwarsa adalah gangguan nyata yang terjadwal, bukan risiko teoritis. Jam kamera juga harus benar agar pemeriksaan validitas dievaluasi dengan jujur.

  • Ditandatangani sendiri. Anda memilih masa hidup dengan -days. Ketika habis masa berlakunya, Anda harus membuat ulang kunci/sertifikat dan menerapkannya kembali: salin ulang file DER, atau bangun ulang dan flash ulang citra ROMFS jika sertifikat sudah dipanggang di dalamnya. Pilih nilai -days yang benar-benar akan Anda ingat untuk ditindaklanjuti.

  • CA Publik. Sertifikat ini sengaja berumur pendek. Let's Encrypt menerbitkan sertifikat 90 hari dan mengharapkan pembaruan otomatis kira-kira setiap 60 hari; tidak ada opsi "pasang sekali dan lupakan".

Tren yang lebih luas bersifat satu arah: validitas maksimum sertifikat TLS yang dipercaya publik terus menyusut. Dulu 825 hari, saat ini dibatasi di 398 hari, dan CA/Browser Forum telah mengadopsi jadwal yang menurunkannya menuju sekitar 47 hari pada tahun 2029. Pelajaran untuk desain perangkat adalah mengasumsikan sertifikat berumur pendek dan bahwa rotasi harus otomatis atau setidaknya rutin -- jangan kirimkan produk yang bergantung pada manusia yang menukar sertifikat sepuluh tahun.

Secara praktis, pada kamera: pilih desain di mana sertifikat dapat diganti tanpa reflashing (sistem file yang dapat ditulis ditambah jalur pembaruan jarak jauh, atau menjalankan kamera sebagai klien yang mempercayai CA yang Anda rotasi secara terpusat). Jika sertifikat harus berada di ROMFS, jadwalkan pembaruan firmware sesuai masa hidupnya.

14.4.6.3. Pemecahan masalah

  • Jam harus diatur. Kamera yang belum mengatur jamnya sejak dinyalakan gagal dalam pemeriksaan validitas sertifikat -- panggil ntptime.settime() terlebih dahulu.

  • Nama host harus cocok. Ketika klien melewatkan server_hostname itu harus cocok dengan subjectAltName sertifikat (atau CN pada tumpukan yang lebih lama), atau verifikasi gagal.

  • Format salah. File PEM yang disalin ke kamera tidak akan dimuat -- konversi ke DER terlebih dahulu.

  • Sertifikat kedaluwarsa. Koneksi yang sebelumnya berhasil dan sekarang gagal dengan OSError mungkin hanya memiliki sertifikat yang kedaluwarsa -- periksa tanggal validitas dan buat ulang/terapkan ulang sesuai kebutuhan.

  • Kunci Ed25519 gagal. Gunakan ECDSA P-256/P-384 atau RSA, bukan Ed25519.

  • Kesalahan adalah OSError. MicroPython tidak mengimplementasikan ssl.SSLError; kegagalan TLS (sertifikat buruk, kedaluwarsa, CA tidak dikenal, kesalahan format, kegagalan handshake) dimunculkan sebagai OSError.