14.4.6. Операції: ключі, термін дії та усунення несправностей

Три аспекти роботи з сертифікатами охоплюють кожен розгорнутий пристрій: захист приватного ключа після його потрапляння на камеру, планування дня закінчення терміну дії сертифіката та короткий перелік режимів помилок, що виникають на практиці.

14.4.6.1. Захист приватного ключа

Щоразу, коли камера представляє сертифікат – як TLS-сервер або як клієнт у mTLS – її приватний ключ повинен зберігатися на пристрої у форматі DER, у файловій системі або в ROMFS. Збережений у такий спосіб, він доступний для читання будь-яким кодом, що виконується на камері, а також будь-ким, хто має до неї фізичний доступ: через USB-накопичувач, REPL-запит або безпосередньо з флеш-пам’яті. ROMFS та прапорці лише для читання запобігають модифікації, але не витоку. Вважайте будь-який приватний ключ, записаний на пристрій, відновлюваним для зловмисника, який має фізичний або програмний доступ до нього.

Це не робить TLS беззмістовним – це визначає спосіб його розгортання:

  • Використовуйте унікальний ключ і сертифікат для кожного пристрою. Ніколи не записуйте один спільний ключ на весь парк: витік ключа з одного пристрою дозволить зловмиснику видавати себе за будь-яку камеру. Ключі на рівні пристрою обмежують компрометацію одним пристроєм, який можна відкликати або вимкнути на стороні сервера.

  • Використовуйте короткострокові сертифікати. Вкрадений ключ корисний лише доти, доки діє його сертифікат; короткі строки дії у поєднанні з регулярною ротацією мінімізують збитки (див. Certificate expiry and rotation нижче).

  • По можливості уникайте розміщення секретів на пристрої. Якщо вам потрібна лише перевірка сервера (автентифікація сервера, а не mTLS), камера як клієнт зберігає лише сертифікат CA – який є публічним – і не містить приватного ключа, вартого викрадення.

  • Ніколи не включайте ключ у публічний образ мікропрограми. Ключ, вбудований у ROMFS у дистрибутивній збірці мікропрограми, не є секретним – будь-хто, хто завантажує мікропрограму, матиме його. Провізіонування на рівні пристрою означає програмування ключа після загальної мікропрограми, а не всередині неї.

  • Обмежуйте радіус ураження. Зводьте до мінімуму сферу дії сертифіката (принцип найменших привілеїв) і переконайтеся, що витік ідентифікатора одного пристрою можна відкликати або вимкнути, не впливаючи на інші.

Якщо ваша модель загроз передбачає зловмисників з фізичним доступом, проектуйте систему виходячи з припущення, що ключ пристрою врешті-решт буде розкрито, і зробіть це прийнятним, а не розраховуйте на те, що його можна зберегти в таємниці на апаратному забезпеченні, яке для цього не пристосоване.

14.4.6.2. Термін дії та ротація сертифікатів

Кожен сертифікат має вікно дійсності. Після його закінчення вузол з ssl.CERT_REQUIRED відхиляє з’єднання – тому закінчення терміну дії є реальним запланованим збоєм, а не теоретичним ризиком. Годинник камери також повинен бути правильно встановлений для чесної оцінки перевірки дійсності.

  • Самопідписаний. Ви вибрали термін дії за допомогою -days. Після його закінчення необхідно перегенерувати ключ/сертифікат і повторно розгорнути його: перекопіювати файли DER або перезібрати та перепрошити образ ROMFS, якщо сертифікат вбудований. Вибирайте значення -days, про яке ви справді пам’ятатимете.

  • Публічний CA. Вони навмисно короткострокові. Let’s Encrypt видає 90-денні сертифікати та очікує автоматичного поновлення приблизно кожні 60 днів; варіанту «встановити та забути» не існує.

Загальна тенденція однонаправлена: максимальний термін дії публічно-довірених TLS-сертифікатів постійно скорочується. Він становив 825 днів, зараз обмежений 398 днями, а CA/Browser Forum прийняв графік, який доведе його до приблизно 47 днів до 2029 року. Висновок для проектування пристрою: передбачайте, що сертифікати короткострокові, а ротація повинна бути автоматизована або принаймні регулярна – не створюйте продукт, що залежить від ручної заміни десятирічного сертифіката.

На практиці, стосовно камери: надавайте перевагу конструкціям, де сертифікат можна замінити без перепрошивки (файлова система з можливістю запису плюс шлях для віддаленого оновлення, або робота камери як клієнта, що довіряє CA, яким ви керуєте централізовано). Якщо сертифікат повинен зберігатися в ROMFS, плануйте оновлення мікропрограми відповідно до його терміну дії.

14.4.6.3. Усунення несправностей

  • Годинник повинен бути встановлений. Камера, яка не встановила годинник після увімкнення живлення, не пройде перевірку дійсності сертифіката – спочатку викличте ntptime.settime().

  • Ім’я хоста повинно збігатися. Коли клієнт передає server_hostname, воно повинно збігатися з subjectAltName сертифіката (або CN на застарілих стеках), інакше верифікація не пройде.

  • Неправильний формат. PEM-файл, скопійований на камеру, не завантажиться – спочатку конвертуйте його в DER.

  • Сертифікат прострочено. З’єднання, яке раніше працювало, а тепер завершується з OSError, можливо, просто має прострочений сертифікат – перевірте дати дійсності та за потреби перегенеруйте/перерозгорніть.

  • Ключі Ed25519 не працюють. Використовуйте ECDSA P-256/P-384 або RSA, але не Ed25519.

  • Помилки представлені як OSError. MicroPython не реалізує ssl.SSLError; збої TLS (поганий сертифікат, прострочений, невідомий CA, помилка формату, збій рукостискання) виникають як OSError.