Считывающее перо TLS 1.2 vs 1.3 и управление сертификатами: задержка рукопожатия, расход батареи и стоимость подготовки

Аудитория:Данная статья ориентирована на OEM-инженеров встраиваемого ПО, архитекторов безопасности MDM и сотрудников отдела соответствия нормативным требованиям, которые должны обосновать выбор версии TLS, набора шифров и цепочки сертификатов для партии детских считывающих перьев. В статье проводится сравнительный анализ TLS 1.2 (RFC 5246), TLS 1.3 (RFC 8446) и DTLS 1.3 для всех 11 активных SKU (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6) с измерением задержки рукопожатия, энергопотребления и влияния на BOM-затраты на хранение сертификатов.

В ходе пилотного проекта ЕС в 2025 году 5000 считывающих перьев были размещены за межсетевым экраном Palo Alto PA-5220 школы. Команда MDM обязала использовать исключительно TLS 1.3 и сертификаты сервера ECDSA-256. Встроенное ПО первого поколения версии 3.1.2 на F8 поддерживало TLS 1.3 на стороне сервера, но не имело клиентских сертификатов ECDSA — только RSA-2048. В результате: каждое перо не проходило рукопожатие с первой попытки и повторно пыталось использовать частично сломанный откат на TLS 1.2. Рукопожатие занимало 4,6 с и потребляло 18 мАч на перо в день. После отгрузки встроенного ПО версии 3.3.1 с поддержкой клиентских сертификатов ECDSA-P256 на Q8 и T2 время рукопожатия снизилось до 0,95 с, а энергопотребление — до 3,1 мАч в день.

Данная статья — это инженерная документация, которую нам хотелось бы иметь с первого дня развёртывания. Она основана на производственных измерениях для 11 SKU и внутренних заводских приёмочных испытаниях.

1. Почему TLS важен для считывающего пера

Считывающее перо — это «подключённое устройство для детей». Согласно GDPR ст. 32, COPPA §312 и PIPL ст. 51, перо обрабатывает персональные данные несовершеннолетних. Обязательное шифрование при передаче данных не подлежит обсуждению. Мы всегда завершаем TLS на облачном брокере (MQTT 8883, HTTPS 443) и на сервере загрузки OTA. Встроенное ПО отказывается выпускать сборку с TLS 1.2.

В производстве используются две версии протокола:

• TLS 1.2 — поддерживается на всех SKU с Wi-Fi чипом (все 11). Обязательный базовый уровень. Наборы шифров: ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256.
• TLS 1.3 — поддерживается на K7, KF1, L5, Q8, T2, Y6. Наборы шифров: TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256. Данные 0-RTT при возобновлении.
• DTLS 1.3 — поддерживается только на Q8, T2. Используется для CoAP-over-DTLS.

2. Матрица поддержки TLS для 11 SKU

Несколько неочевидных фактов в этой таблице. Во-первых, DTLS (Datagram TLS) требуется только для CoAP; основная часть ручек использует TCP+TLS. Во-вторых, Защищённый элемент (Microchip ATECC608B или NXP SE050) является опциональным на Q8 и T2 — его добавление стоит $0,62 за единицу и хранит закрытые ключи в защищённом от взлома оборудовании. Мы требуем защищённый элемент для любой ручки, отправляемой в Германию, Францию или Калифорнию (CCPA), где риски несанкционированного доступа не являются незначительными. В-третьих, аппаратный ГПСЧ имеет значение: TRNG (генератор истинных случайных чисел) позволяет избежать статистической слабости ПО-генераторов случайных чисел, которые затронули BK7251 rev A в 2022 году.

Совет покупателю: Если ваша команда по соответствию требует FIPS 140-2 или Common Criteria EAL4+, вы должны заказать Q8 или T2 с защищённым элементом ATECC608B. Остальные 9 SKU не могут соответствовать этим сертификациям, поскольку закрытый ключ хранится в открытом флеш-накопителе.

3. Измерение квитирования TLS 1.2 и 1.3

Подтверждение TLS 1.2 ECDHE-RSA-AES128-GCM-SHA256два обмена данными плюс проверка сертификата. TLS 1.3 с ECDHE-ECDSA-P256 составляет один обмен данными плюс зашифрованная проверка сертификата. По чистому Wi-Fi соединению показатели в реальном времени:

Цифры выравниваются при разбивке по SKU:

Квитирование 1-RTT в TLS 1.3 экономит 58% задержки по сравнению с RSA-квитированием TLS 1.2. На питаемом от батареи устройстве экономия энергии ещё важнее: радио остаётся активным примерно в 1,5 раза дольше при TLS 1.2.

4. RSA против ECDSA — Вопрос себестоимости

Сертификаты хранятся в образе прошивки или в специальном защищённом элементе. Размеры:

Сертификаты ECDSA-P256 на 54% меньше по размеру, чем RSA-2048, и проверяются на 57% быстрее по времени ЦП. Для парка из 10 000 устройств экономия флеш-памяти на устройство суммируется: 10 000 × 562 Б = 5,6 МБ совокупной экономии пропускной способности OTA при каждой смене сертификата.

Реальность BOM такова, что цепочки ECDSA несколько дороже в управлении с облачной стороны. AWS IoT, Azure IoT Hub и большинство корпоративных PKI взимают примерно одинаковую плату за любой тип ключа, поэтому мы рекомендуем ECDSA-P256 для всех новых развёртываний.

5. Подготовка сертификатов на ICT

Считывающая ручка должна иметь уникальный клиентский сертификат для аутентификации в облаке. Наша процедура ICT (In-Circuit Test) выполняет:

1. Ручка подключается к VLAN подготовки.
2. Ручка обращается к SCEP-конечной точке заводского CA по HTTPS с CSR (PKCS#10).
3. CA подписывает CSR со сроком действия 10 лет.
4. Подписанный сертификат записывается в сектор NVM ручки.
5. Ручка перезагружается и пытается установить TLS-соединение с MQTT-брокером.

Пропускная способность подписания CA на Raspberry Pi 4 составляет 3,4 сертификата/сек. При скорости линии ICT 60 секунд/единица, подготовка сертификатов является узким местом только при очень больших партиях. Мы используем кластер подписания из 4 узлов для достижения 12 сертификатов/сек для тендеров свыше 20 000 единиц.

Для заводской себестоимости жизненный цикл сертификата составляет $0,10 за единицу (RSA-2048) или $0,06 за единицу (ECDSA-P256). Дельта в 38% — одна из причин, по которой мы рекомендуем ECDSA.

6. Стратегии ротации сертификатов

Три стратегии ротации развёрнуты в парках устройств заказчиков:

• Ежегодная ротация — большинство школьных MDM. Обновление по воздуху (OTA). Совместимо со всеми 11 SKU.
• Ротация каждые 90 дней — высокобезопасные районы, дочерние компании финансового сектора. Требуется Q8, T2 с ATECC608B; закрытый ключ невозможно извлечь.
• Ротация по запросу — реагирование на компрометацию. Принудительная ротация через OTA за 18 минут, включая загрузку + установку + перезагрузку.

OCSP stapling и проверка CRL включены по умолчанию в прошивке Q8, T2 версии 3.3.1+. Ручка проверяет цепочку сертификатов сервера и проверяет прикреплённый OCSP-ответ. Для парка из 100 000 ручек OCSP-сервер должен обрабатывать 100 000 ежедневных запросов — мы используем Anycast-based OCSP-сервер с 4 PoPs для поддержания p99 ниже 80 мс.

7. Наборы шифров по умолчанию

Заводской список наборов шифров по умолчанию задокументирован в нашем [Compliance Manual]. Полный порядок для L5/Q8/T2/Y6:

TLS 1.3:
  TLS_AES_128_GCM_SHA256         (приоритет 1)
  TLS_AES_256_GCM_SHA384         (приоритет 2)
  TLS_CHACHA20_POLY1305_SHA256   (приоритет 3, резервный)

TLS 1.2:
  ECDHE-ECDSA-AES128-GCM-SHA256  (приоритет 1)
  ECDHE-RSA-AES128-GCM-SHA256    (приоритет 2)
  ECDHE-ECDSA-AES256-GCM-SHA384  (приоритет 3)
  ECDHE-RSA-AES256-GCM-SHA384    (приоритет 4)

Мы никогда не включаем AES-CBC, RC4, MD5, SHA-1, 3DES или экспортные наборы шифров. Школьный округ, который запускает TLS-сканер (testssl.sh, Qualys SSL Labs) против конечной точки брокера ручки, видит только зелёные наборы шифров.

8. Данные 0-RTT: тонкая ловушка

TLS 1.3 вводит данные 0-RTT — клиент может отправлять байты приложения в самом первом пакете, до сообщения Finished от сервера. На считывающей ручке это экономит 240 мс при возобновлении, но данные 0-RTT уязвимы к атакам повтора. Злоумышленник, перехвативший первый пакет, может воспроизвести его на том же сервере в течение срока действия тикета сессии.

Поэтому мы не используем 0-RTT для:

• OTA-команд прошивки (повтор может вызвать перепрошивку).
• Изменений родительского контроля.
• Отправки результатов с финансовыми последствиями (платные сюжетные пакеты).

Мы используем 0-RTT для:

• Публикации телеметрии (идемпотентная, заменяется следующим пакетом).
• Запросов синхронизации времени по NTP-подобному протоколу (идемпотентные).
• Heartbeats (идемпотентные).

9. TLS-терминация на стороне облака

Заводская рекомендация — терминировать TLS на облачном брокере (HiveMQ, EMQX, AWS IoT Core) или на CDN edge (CloudFront, Cloudflare). Для школьных развёртываний с локальными брокерами команда ИТ должна управлять ротацией сертификатов на брокере. Мы предоставляем Terraform-модуль для AWS IoT Core и Helm-чарт для EMQX на Kubernetes, которые автоматизируют ротацию с Let's Encrypt или внутренним CA.

Для программ в стиле HIPAA (у нас есть один проект в Среднем Западе США для педиатрической инициативы больничного чтения) брокер должен работать в FIPS-режиме OpenSSL. Q8 и T2 с ATECC608B содержат границу FIPS 140-2; брокер содержит границу FIPS 140-3. Сквозной FIPS 140 — это дельта $0,85 за единицу BOM при MOQ 5 000.

11. Взаимный TLS для интеграции школьного MDM

Помимо аутентификации сервера, несколько платформ MDM (Jamf School, Mosyle, Microsoft Intune for Education) требуют, чтобы ручка аутентифицировалась с использованием клиентского сертификата. Мы поддерживаем это на Q8 и T2 с защищённым элементом ATECC608B; закрытый ключ сертификата никогда не покидает микросхему.

Поток регистрации MDM:

1. Школьный ИТ-отдел отправляет MDM-профиль на планшет учителя.
2. Учитель связывает Q8/T2 с планшетом по BLE.
3. Профиль MDM содержит URL-адрес конечной точки SCEP (протокол упрощённой регистрации сертификатов).
4. Ручка подключается к SCEP-конечной точке по HTTPS, представляя CSR.
5. SCEP CA подписывает CSR школьным MDM-поди CA.
6. Подписанный сертификат записывается в ATECC608B.
7. Регистрация MDM завершена.

12. Тестирование на проникновение и OWASP IoT Top 10

Наша прошивка ежегодно тестируется на соответствие OWASP IoT Top 10 (редакция 2024). Самый недавний аудит охватывал F8 3.1.2, K7 1.9.5, KF1 1.9.5, L5 4.2.0, Q6 3.3.1, Q8 3.3.1, T2 3.3.1 и Y6 2.6.4. Аудит выявил:

• I1 Слабые пароли — пройдено. Заводские настройки по умолчанию не имеют пользовательского пароля; MDM назначает надёжный PSK при регистрации.
• I2 Небезопасные сетевые службы — пройдено. Все службы требуют TLS 1.2 или 1.3; порты открытого текста (80, 21, 23) отключены.
• I3 Небезопасные интерфейсы экосистемы — пройдено. MDM API требует взаимный TLS с ECDSA-P256.
• I4 Отсутствие безопасного механизма обновления — пройдено. Подпись изображений ECDSA-P256, счётчик защиты от отката, см. TC-046.
• I5 Использование небезопасных компонентов — пройдено. В нашем дереве прошивки отсутствуют сторонние библиотеки с известными CVE.
• I6 Недостаточная защита конфиденциальности — пройдено. Телеметрия является опциональной; по умолчанию поставляется с отключённой телеметрией.
• I7 Небезопасная передача данных — пройдено. TLS 1.3 + ECDSA-P256 + дисциплина 0-RTT.
• I8 Отсутствие управления устройствами — пройдено. Полная поддержка MDM на Q8, T2.
• I9 Небезопасные настройки по умолчанию — пройдено. Заводские настройки являются наиболее ограничительными.
• I10 Отсутствие физической защиты — частично. KF1, L5, Q8, T2, Y6 имеют контакты обнаружения вскрытия; B1, B2, P2 не имеют.

Импортёры могут запросить полный аудиторский отчёт по NDA. Отчёт составляет 84 страницы; срок подготовки — 5 рабочих дней.

13. Распределение CRL и прикрепление OCSP на практике

Автопарк школы из 10 000 ручек создаёт нетривиальную нагрузку на PKI. Если бы каждая ручка проверяла сертификат сервера, обращаясь к OCSP-респонденту CA при каждом TLS-подтверждении, инфраструктура CA вышла бы из строя. Мы решаем эту проблему с помощью прикрепления OCSP на стороне брокера: брокер получает OCSP-ответ от CA каждые 4 часа и включает его в TLS-подтверждение.

Прикреплённые OCSP-ответы действительны в течение 4 часов (в соответствии с циклом обновления). Ручка проверяет прикреплённый ответ по открытому ключу CA, проверяет подпись и продолжает работу. Если прикреплённый ответ отсутствует или истёк, ручка возвращается к прямому OCSP и может задержаться на 200–800 мс.

Для распределения CRL мы используем ежедневный Anycast-респондент в 4 точках присутствия (Сингапур, Франкфурт, Вирджиния, Сан-Паулу). CRL составляет 48 КБ; ручки получают его через HTTP-запрос диапазона при каждом успешном TLS-подтверждении (кэшируется на 24 часа). Совокупная пропускная способность на ручку в день составляет 2 КБ. Частота отказов CRL на прошивке Q8/T2 3.3.1 составляет 0,04% при более чем 47 000 отгруженных ручек.

Для всех новых развёртываний наша рекомендация — TLS 1.3 + ECDSA-P256 в сочетании с ATECC608B для любой ручки с розничной ASP выше $25. Сокращение задержки при подтверждении, уменьшение размера сертификата и защищённое хранение ключей — правильная инженерная база для 2026–2028 годов.

Дополнительное чтение

• IoT MQTT vs HTTP vs CoAP
• Шифрование данных AES-128 vs AES-256
• Механизм обновления прошивки OTA
• Wi-Fi роуминг и переподключение
• GDPR и защита данных ЕС
• COPPA и родительский контроль