Secure element, PUF, TPM и secure boot: аппаратный корень доверия
Аппаратный корень доверия — минимальный компонент или функция, которым система доверяет до запуска прикладного кода. Он хранит либо воспроизводит секреты, выполняет криптографические операции и помогает проверить следующую ступень загрузки. Но отдельный secure element не делает устройство защищённым: важны цепочка загрузки, производство, обновление, отладочный доступ, серверная инфраструктура и план восстановления. Secure element, PUF и TPM решают пересекающиеся, но разные задачи. Выбор начинается с модели угроз и операций с ключами, а не со списка поддерживаемых алгоритмов.
Постройте модель угроз
Опишите активы: приватный ключ устройства, firmware, алгоритм, данные пользователя, сетевые учётные данные, счётчик ресурса. Затем перечислите противника и доступ: удалённый сетевой, пользователь с корпусом, сервисный инженер, контрактное производство или лаборатория с физическим анализом.
Для каждой угрозы определите требуемый результат. Защита от клонирования устройства отличается от защиты конфиденциальности прошивки. Secure boot мешает выполнить неподписанный код, но не шифрует данные автоматически. TLS защищает канал, но не предотвращает копирование приватного ключа из открытой Flash.
Что такое secure element
Secure element — отдельная микросхема с защищённым хранилищем и криптографическим ядром. Приватный ключ может генерироваться внутри и не покидать устройство: хост передаёт digest и получает подпись. Типовые функции — ECDSA/ECDH, AES, HMAC, random number generator, monotonic counters и защищённые slots.
Интерфейс I²C не обязан быть секретным. Безопасность строится на невозможности извлечь ключ и на аутентифицированных командах. Однако злоумышленник может повторять допустимые операции через хост, поэтому права слотов, лимиты и протокол приложения должны быть настроены осмысленно.
Что даёт PUF
Physical Unclonable Function использует уникальные физические вариации кристалла для получения устройства-зависимого ответа. На практике система хранит helper data и при включении восстанавливает ключ с коррекцией ошибок. Секрет не обязательно существует в Flash в готовом виде.
PUF уменьшает риск копирования постоянного ключа, но требует понимания enrollment, температурного/вольтажного диапазона, стабильности и резервного сценария. Нельзя переносить маркетинговое слово PUF между разными реализациями: проверяйте, какие операции сертифицированы и где проходит граница доверенной среды.
Когда нужен TPM
TPM ориентирован на стандартизованные измерения загрузки, PCR-регистры, attestation, sealed storage и управление ключами в более сложных системах. Он часто уместен в Linux/Windows-устройствах, шлюзах и компьютерах, где программный стек уже понимает TPM 2.0.
Для маленького MCU TPM может оказаться избыточным по коду и интеграции. Secure element с несколькими ключевыми операциями проще, если нужны TLS client authentication и anti-counterfeit. Решение зависит от протоколов сервера и требований аудита.
Secure boot — это цепочка, а не флаг
Неизменяемый ROM-код проверяет первую изменяемую ступень, та — следующую, пока не будет проверено приложение и при необходимости данные конфигурации. Каждая ступень должна проверять подпись до исполнения и ограничивать версию для защиты от rollback. Корневой публичный ключ или его hash хранятся в OTP/eFuse/защищённой области.
Важно определить, что происходит при ошибке: безопасная остановка, recovery из подписанного образа или переход в сервисный режим. Бесконечная перезагрузка усложняет диагностику, а непроверенный recovery разрушает всю цепочку.
Ключи на производстве
Самый сильный secure element бесполезен, если один общий приватный ключ записывается в файл на рабочем столе оператора. Предпочтительна уникальная идентичность каждого изделия: ключ генерируется внутри компонента или поступает из HSM через контролируемый процесс. Сертификат связывает публичный ключ с серийным номером и партией.
Нужны журнал операций, разделение ролей, ограничение числа записей и проверка результата. Контрактному производителю не следует передавать корневой signing key. Для тестовой линии используют отдельную иерархию или ограниченные provisioning credentials.
Конфигурация слотов необратима
Многие security IC имеют зоны конфигурации, которые блокируются навсегда. Сначала создайте карту слотов: назначение, алгоритм, право чтения/записи, требуемая авторизация, жизненный цикл и процедура ротации. Проверьте её на тестовых образцах и сохраните machine-readable конфигурацию в системе контроля версий.
Перед lock выполните readback и независимую проверку. Ошибка бита может превратить партию в брак. Производственный скрипт должен различать новый, уже настроенный и повреждённый компонент, а не безусловно повторять команды.
Отладка и сервисный доступ
JTAG/SWD позволяет обойти многие программные меры. В серии debug отключают, защищают challenge-response или переводят в режим, при котором разблокировка стирает секреты. Но необратимое отключение усложняет анализ отказов. Решение принимают по модели угроз и сервисной стратегии.
Сервисный firmware тоже должен быть подписан и ограничен по функциям. Нельзя оставлять «временный» пароль UART или универсальный bootloader command. Все диагностические интерфейсы входят в attack surface.
Обновление, anti-rollback и отзыв
Подпись доказывает происхождение образа, но устройство должно знать допустимую минимальную версию. Monotonic counter или защищённая версия предотвращают установку старой уязвимой прошивки. Политика должна допускать аварийное восстановление, не открывая downgrade.
Продумайте компрометацию ключа подписи: резервный корень, список отозванных ключей, переключение на новую иерархию. Если единственный hash навсегда записан в OTP без пути замены, инцидент может потребовать отзыв всего парка.
Опишите жизненный цикл идентичности
Устройство проходит состояния blank, provisioned, production, service, decommissioned. Для каждого укажите разрешённые команды, открытые интерфейсы и доверенные ключи. Серийный номер на корпусе не должен быть единственным идентификатором: сервер связывает его с публичным ключом, hardware revision и записью производства. При возврате устройства решается, можно ли повторно выдать сертификат и как доказать, что ключ не был скомпрометирован.
Тестовая инфраструктура отделяется от production CA. Development keys никогда не принимаются серийным firmware, а production keys недоступны сборочной системе общего назначения. В план реагирования входят отзыв конкретного сертификата, массовая ротация промежуточного CA, доставка аварийного подписанного образа и вывод устройства из эксплуатации с уничтожением секретов. Проверьте эти операции на небольшом парке до выпуска: архитектура, у которой есть только happy path первичной регистрации, не готова к реальному инциденту.
Практический пример
Промышленный шлюз подключается к облаку по mutual TLS и обновляется удалённо. Уникальный ECDSA-ключ генерируется в secure element; сертификат выдаётся после проверки серийного номера на линии. ROM MCU проверяет bootloader, bootloader — A/B-образ приложения. Версия образа сравнивается с защищённым счётчиком.
Сервер умеет отозвать сертификат конкретного устройства. Debug в серии закрыт, но подписанный сервисный образ может собрать диагностику без доступа к ключам. Проверка включает прерывание питания во время обновления, повреждение подписи, старый образ и замену security IC.
Примеры из каталога ChipBaza
ATECC608B-SSVDA-T — пример secure element Microchip для хранения ключей и криптографических операций. SLS32AIA010MKUSON10XTMA2 — пример OPTIGA Trust M в компактном корпусе. Суффиксы важны: они кодируют исполнение, конфигурацию, корпус и упаковку. Нельзя заменять один вариант другим только по базовому имени.
Перед закупкой проверяют provisioning state, возможность заказной персонализации, официальный lifecycle и поддержку middleware. Пустой и заранее персонализированный компонент требуют разных процессов.
Что запросить у производителя и поставщика
Помимо datasheet нужны security target/сертификаты, errata, lifecycle, provisioning guide, описание factory state и условия поставки pre-personalized изделий. Уточните, контролируется ли конфигурация полным MPN и lot, можно ли получить certificate chain/manifest и как подтверждается подлинность компонента. Для middleware зафиксируйте поддерживаемые MCU/RTOS, лицензию, CVE-процесс и доступ к исходникам критичного transport layer. Входной контроль партии должен отличать пустое, заблокированное и неверно персонализированное состояние безопасной командой, не расходующей необратимые счётчики.
Типовые ошибки
- покупать secure element без модели угроз и provisioning-процесса;
- хранить общий приватный ключ во внешней Flash;
- считать secure boot эквивалентом шифрования прошивки;
- блокировать конфигурацию без readback и тестовой партии;
- оставлять открытый debug или универсальный сервисный пароль;
- проверять подпись, но разрешать rollback;
- не планировать отзыв сертификата и ротацию signing key;
- логировать секреты, nonce или чувствительные диагностические данные.
Чек-лист архитектуры доверия
- зафиксированы активы, противники и физический доступ;
- назначены trust anchor и границы каждой ступени загрузки;
- описаны генерация, выдача, хранение, ротация и отзыв ключей;
- создана и проверена карта слотов security IC;
- secure boot проверяет весь путь до приложения;
- предусмотрены anti-rollback, recovery и аварийный ключ;
- debug и сервисный режим соответствуют модели угроз;
- production provisioning журналируется и не раскрывает корневые ключи.
Источники для технической проверки
Параметры и ограничения сверяйте с актуальной документацией производителя для полного артикула и нужного исполнения.
Следующий шаг
Проверьте артикулы и количество до отправки заявки
Загрузите спецификацию в BOM-сервис или пришлите полный код производителя менеджеру. Если точное совпадение не доказано, позиция останется на ручной проверке.