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.