Фиксация и ротация сертификатов читающей ручки: защита от атак «человек посередине» для 11 B2B SKU

Аудитория: Эта статья написана для специалистов по закупкам при министерствах образования, руководителей ИТ-безопасности брендов и менеджеров OEM-программ, которые должны ответить на этот вопрос в своём RFP: «как читающая ручка определяет, что общается именно с нашим облаком, а не с прокси-сервером?». Мы разберём SPKI hash pinning, периодичность ротации pin-набора, телеметрию, которая сообщает нам о попытках ручки подключиться к чужому эндпоинту, и план реагирования на инциденты, который использует наша команда безопасности для 11 SKU линейки Smart Reading Pen (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6).

Читающая ручка находится онлайн лишь 22 % времени бодрствования — она спит при 0,06 мА и просыпается при сканировании, нажатии пользовательской кнопки и по сигналу OTA-watchdog. Когда она просыпается, у неё есть от 9 до 16 секунд, чтобы связаться с облаком, синхронизировать состояние и снова уснуть. Именно этот интервал 9–16 секунд пытается эксплуатировать корпоративный MITM-прокси. Мы защищаем канал с помощью SPKI hash pinning на каждом TLS-рукопожатии. Эта статья — инженерный глубокий разбор.

Совет закупщику: Когда вы сравниваете двух поставщиков по «поддержке TLS 1.3», это не дифференциатор — её поддерживают оба. Дифференциатор — будет ли ручка отклонять соединение при неожиданной смене облачного сертификата. Запросите периодичность ротации производственного pin-набора и код доступа к сервисному меню отладки. Поставщик, который колеблется, не использует pinning.

1. Почему стандартного TLS недостаточно для встраиваемого устройства

Читающая ручка не может использовать WebPKI так, как это делает браузер. У неё нет автоматического канала обновления хранилища доверия, нет конвейера Google CRL, нет push-уведомлений Apple. Если бы мы поставляли ручку с набором корневых сертификатов Mozilla, компрометация любого из 140 корневых CA в наборе вынудила бы нас отозвать более 47 000 ручек. Поэтому мы не поставляем набор корневых CA. Мы поставляем pin-набор: короткий список SPKI-хэшей, которые устройство принимает как подтверждение подлинности.

Когда ручка пытается подключиться к облачному MQTT-эндпоинту mqtt-eu.smartreadingpen.com, TLS-рукопожатие возвращает серверный сертификат. Читающая ручка вычисляет SHA-256 от SubjectPublicKeyInfo сертификата (байты открытого ключа) и сравнивает этот хэш с pin-набором, хранящимся в защищённом элементе. Если хэш совпадает, соединение устанавливается; если нет — соединение отклоняется, и событие фиксируется в логе.

Схема с двумя закреплёнными хэшами выбрана намеренно: каждый эндпоинт одновременно закреплён на два SPKI-хэша — текущий рабочий сертификат и сертификат, на который мы планируем перейти. Ротация никогда не требует отзыва устройств в полевых условиях.

2. Структура pin-набора внутри устройства

Типичный pin-набор для L5 или Q8 выглядит в NVM так:

pin-set[0]= SPKI hash (primary)    = 15 96 09 ...
pin-set[1]= SPKI hash (backup)     = 96 bc ec ...
pin-set[2]= expiry (epoch 1747)    = 2027-01-15
pin-set[3]= flags                  = PIN_REQUIRED | PIN_LOG_ON_MISS
pin-set[4]= revocation list (CRL)  = 1 entry
pin-set[5]= chain length max       = 3

Флаги — это операционные рычаги. PIN_REQUIRED отклоняет рукопожатие при промахе. PIN_LOG_ON_MISS записывает ошибочный SHA-256 и IP-источник в NVRAM для следующей синхронизации. PIN_LOG_ONLY принимает соединение, но логирует промах для диагностики. Флаг PIN_REQUIRED включён по умолчанию на каждом SKU; PIN_LOG_ONLY мы зарезервировали для QA-сборок.

3. Периодичность ротации

Закреплённые хэши не вечны. Ротацию задают два таймера: жёсткий срок действия (epoch) и аварийный триггер (компрометация CA, замена оборудования). Периодичность выбрана консервативной, потому что мы не можем допустить отзыв устройств в полевых условиях.

Среди более чем 47 000 развёрнутых ручек мы трижды выполняли ротацию набора пинов облачного MQTT: в 2023 году (перекрёстное подписание Let's Encrypt), в 2024 году (только ISRG Root X1) и в 2025 году (промежуточный сертификат DigiCert). Охват каждой ротации составил 99,6 % за 14 дней, оставшиеся ручки были синхронизированы в течение 45 дней через офлайн-OTA с использованием школьной настольной док-станции.

4. Телеметрия в полевых условиях: как мы узнаём о несовпадении пинов

Ручка никогда не завершает проверку пина без уведомления. Каждое несовпадение записывается в NVRAM с указанием: временной метки (RTC), хеша SPKI, который был использован, имени хоста конечной точки, разрешённого IP, глубины цепочки сертификатов и локального SSID сети (при подключении через Wi-Fi). При следующей успешной загрузке — обычно в течение 9 часов — запись журнала загружается в бэкенд через корпоративный канал телеметрии.

Сводка телеметрии проверки пинов для более чем 47 000 развёрнутых ручек за год, заканчивающийся 2026-06:

184 цепных несовпадения за год, заканчивающийся 2026-06, представляют наибольший интерес. Они возникают из-за корпоративных прокси-серверов, которые переподписывали сертификат на лету. Каждое из них породило тикет в ИТ-отдел школы в течение 48 часов. Ни одно не привело к утечке данных, поскольку TLS-рукопожатие отклоняется до передачи каких-либо полезных данных.

5. 90-дневные учения «тихой ротации»

Каждые 90 дней мы проводим учения «тихой ротации». Мы подписываем тестовый MQTT-брокер новым хешем SPKI, отправляем хеш в качестве резервного пина в 5 000 ручек и отслеживаем успешность рукопожатия на тестовом брокере. Если 99 % из 5 000 ручек успешно проходят проверку, мы одобряем ротацию для всего парка.

Учения ни разу не опустились ниже порога 99,0 %. Самый низкий цикл был в Q3-26 и составил 98,4 % (вызван 32 ручками на корпоративном прокси, расшифровывающем TLS — эти 32 ручки были перенастроены через OEM-соглашение, а не на самом устройстве).

6. OEM-программы, которые хотят собственные пины

Для OEM-программ Pattern A (только T2 и Y6) мы передаём сертификат подписи OEM-портала, который HSM импортёра может переподписать. Импортный портал аутентифицирует устройство через mTLS. Набор пинов размещается на защищённом элементе T2/Y6.

OEM может установить собственную периодичность ротации пинов. Большинство выбирает 12 месяцев. 6-месячный цикл допустим на T2/Y6, так как повторная установка пинов на устройстве представляет собой OTA-обновление размером 4 600 байт и выполняется за 1,2 с. При периодичности менее 6 месяцев мы наблюдаем нагрузку на канал OTA по типу CR-LATEX-NAGLE и не рекомендуем это.

7. Что происходит, когда несовпадение пина — это правильный ответ

Не каждое несовпадение пина является атакой. Существуют три повторяющихся случая, когда несовпадение отражает корректную политику и ИТ-отделу школы следует провести проверку:

1. Корпоративный прокси школы — прокси переподписывает TLS, нарушая пин. Читалка отказывает. Решение — добавить SPKI-хэш прокси в читалку через OEM-портал, но только если прокси находится в сети, контролируемой школой.
2. Устаревший офлайн-словарь — читалка, находившаяся на хранении 24+ месяцев, сталкивается с ротацией сертификата. Решение — ручная перепрошивка в сервисном центре OEM.
3. Поддельное облако — кто-то развернул фальшивый MQTT-брокер с валидной TLS-цепочкой. Пин отказывает. OEM получает уведомление через отчёт о несовпадении цепочки.

Для каждого из трёх случаев предусмотрен документированный runbook, который поставляется с каждым OEM-соглашением. Школы, эксплуатирующие 12 000 и более читалок, получают двухчасовой разбор runbook.

8. Итог для дистрибьюторов и тендеров

Certificate pinning — это самая сложная для модернизации часть читалки. Если вы начинаете с поставщика, который не использует пин, добавить его без аппаратной ревизии невозможно. Все наши одиннадцать SKU применяют пин на каждом TLS-хэндшейке, а набор пинов ротируется ежеквартально по проверенному графику. Любой специалист по закупкам узнает формулировку из нашего Приложения к RFP: «SPKI каждого эндпоинта закреплён, с перекрытием двух хэшей и жёстким 24-месячным сроком действия».

Запросить предложение — быстрый ответ с фабрики

CTA

Связанные материалы

• TLS 1.2 и 1.3 в читалках и сертификаты
• Криптография и TrustZone в читалках
• Управление ключами и HSM в читалках
• Защита от отката и аттестация версий в читалках
• Шифрование прошивки и безопасная загрузка в читалках
• Механизм OTA-обновления прошивки читалки
• Запросить предложение

Финальный CTA