Создание защищенных пользовательских приложений на базе СнК SmartFusion2 компании Microsemi.
Часть 8. Технология SPPS. Протоколы и аппаратное обеспечение

PDF версия
Продолжается рассмотрение решения компании Microsemi, называемого «доверенное программирование микросхем в недоверенном окружении» (Secure Production Programming Solution, SPPS). Оно основано на использовании аппаратных модулей криптографической защиты (Hardware Security Module, HSM1) и позволяет в полевых условиях обновлять критичное ПО (firmware) для микроконтроллеров и конфигурацию ПЛИС. Кроме того, технология SPPS разрешает ограничить количество микросхем, запрограммированных одной и той же модификацией внутреннего ПО (firmware), предварительно заданным значением. Таким образом, с помощью технологии SPPS может быть решена задача защиты устройств от клонирования в заводских условиях. В предыдущей публикации были рассмотрены общие положения технологии SPPS. В данной статье описаны протоколы и аппаратное обеспечение, используемое в технологии SPPS.

Протоколы SPPS

Далее будут описаны протоколы, используемые в технологии SPPS. Они включают в свой состав протоколы, поддерживаемые микросхемой, — протоколы авторизации (Authorization Protocols) и OTPK, а также протоколы, созданные выше уровня микросхемы, — например, протокол уникального ключа микросхемы (Per-device key protocol).

 

Протокол кода авторизации

Это основной протокол, используемый в SPPS. Поддержка протокола кода авторизации (Authorization Code protocol) встроена в сами микросхемы SmartFusion2/IGLOO2. Протокол позволяет в недоверенном окружении в рамках технологии SPPS доверенным образом программировать в чистую микросхему начальные настройки политики безопасности, которые в противном случае могут оказаться подверженными простейшим атакам мониторинга (simple monitoring) или атакам типа «человек посередине» (man-in-the-middle, MITM).

Протокол применяется первичным образом (Master bitstream) в режиме HSM flow [13], а также образом обновления (UEK1/2/3 Update bitstream) при программировании микросхем, которые имеют запрограммированные ключи микросхемы (per-device key) UEK1/2/3.

Протокол кода авторизации (Authorization Code protocol) позволяет доверенным образом передать в микросхему сгенерированный с помощью датчика случайных чисел (ДСЧ) ключ шифрования (encryption key, IP key, KIP). Микросхема может использовать переданный ключ KIP для расшифрования входного образа для программирования (programming bitstream). Ключ KIP остается в микросхеме только до завершения цикла программирования, после чего стирается — он не хранится в энергонезависимой памяти (non-volatile memory, eNVM) микросхемы.

Зашифрованный на ключе KIP пользовательский образ (user bitstream) можно запрограммировать в такую микросхему лишь в том случае, если она «авторизована» с помощью рассматриваемого протокола.

Ключ KIP можно передать в микросхему только тогда, когда он был зашифрован на одном из ключей, известных микросхеме. В случае чистой микросхемы, в зависимости от ее типа, имеется два таких ключа, поддерживаемых технологией SPPS:

  • Уникальный для микросхемы (per-device) заводской ключ (Factory Key, FK), который размещается в микросхеме компанией Microsemi в процессе производства.
  • Уникальная для микросхемы (per-device) ключевая пара «открытый ключ (public key)/закрытый ключ (private key) Factory SRAM-PUF ECC», доступная в больших микросхемах (M2S060, M2GL060, M2S090, M2GL90, M2S150 и M2GL150), которая размещается в микросхеме компанией Microsemi в процессе производства. Подробности об этой ключевой паре можно найти в документе [7].

Если пользовательские настройки безопасности уже запрограммированы в микросхему, то режим заводского ключа (Factory Key mode, FKM) отключается. Для таких микросхем пользователь может программировать только компоненты массива ПЛИС (FPGA fabric) и/или энергонезависимой памяти (eNVM) с помощью образа обновления (Update bitstream), применив один из пользовательских ключей, загруженных при программировании первичного образа (Master bitstream). Если ключ шифрования (encryption key), употребленный при таком обновлении, уникален для микросхемы (per-device key), то образ обновления (Update bitstream) зашифровывается на специальном ключе шифрования (KIP), и затем этот ключ (KIP) передается в микросхему посредством протокола кода авторизации (Authorization Code protocol).

Далее пойдет речь об использовании протокола кода авторизации (Authorization Code protocol) при загрузке первичного ключа (initial key) и в процедурах обновления.

 

Протокол кода авторизации при загрузке первичного ключа

Начальный ключ (initial key) для SPPS загружается посредством первичного образа (Master bitstream), основываясь на протоколе кода авторизации (Authorization Code protocol). Этот протокол использует диверсифицированный заводской ключ (Diversified Factory Key, DFK) или заводской открытый ключ SRAM-PUF (Factory SRAM-PUF ECC Public Key). Ниже дано описание обоих ключей.

Диверсифицированный заводской ключ и база данных DFK

Каждая микросхема SmartFusion2/IGLOO2 имеет запрограммированный уникальный заводской ключ (Factory Key). Клиентам компании Microsemi, которые применяют основанную на АМЗ (HSM) технологию SPPS в процессе регистрации пользовательских АМЗ (U‑HSM) через портал Microsemi Portal, предоставляется база данных (DB) диверсифицированных заводских ключей (Diversified Factory Keys, DFK). При регистрации каждый пользовательский АМЗ (U‑HSM) получает уникальный идентификатор (UUID). Он представляет собой символьную строку, состоящую их 32 шестнадцатеричных (hex) символов (40 символов для заводского АМЗ, M‑HSM). Идентификатор клиента (Customer UUID) используется для диверсификации значения заводского ключа (Factory Key) микросхемы при генерации для конкретного клиента базы данных диверсифицированных заводских ключей (Diversified Factory Key Database, DFK DB). Диверсификация (diversification) представляет собой необратимую криптографическую операцию, в качестве входных данных для которой используются уникальный для микросхемы заводской ключ (per-device Factory Key) и уникальный идентификатор клиента (Customer UUID). Полученный в результате выполнения операции ключ называется «диверсифицированный заводской ключ» (Diversified Factory Key, DFK). Значение DFK необратимо, уникально для каждой микросхемы (per-device) и для клиента (per-customer) и хранится в базе данных DFK в зашифрованном виде. Шифрование производится с помощью открытых ключей (Public Key) пользовательского АМЗ (U‑HSM) и заводского АМЗ (M‑HSM). Это позволяет иметь непосредственный доступ к открытому тексту значений ключей DFK только внутри АМЗ (HSM).

Чистой микросхеме не известен уникальный идентификатор клиента (Customer UUID), поскольку он передается микросхеме по протоколу кода авторизации (authorization code protocol). Значение UUID является аутентифицированным, но не зашифрованным. Затем микросхема использует значение заводского ключа (Factory Key) и полученное значение UUID для создания значения (DFK).

Подробно процесс генерации базы данных диверсифицированных заводских ключей (DFK DB) инженером по обслуживанию (OE), использующим его для тестирования и подготовки заводского АМЗ (M‑HSM) к производству, описан в разделе Setup документа [6]. Кратко сущность процесса генерации DFK DB показана на рис. 1.

Создание базы данных диверсифицированных заводских ключей (DFK DB)

Рис. 1. Создание базы данных диверсифицированных заводских ключей (DFK DB)

Режимы заводского эллиптического ключа SRAMPUF

Микросхемы семейств SmartFusion2 и IGLOO2, такие как M2S060, M2GL060, M2S090, M2GL90, M2S150 и M2GL150, имеют аппаратный IP-блок криптографических операций на эллиптических кривых (Elliptic Curve Cryptography, ECC) совместно с блоком SRAM-PUF, что позволяет этим микросхемам иметь уникальные для каждой из них заводские ключи (unique-per-device factory), защищенные ключевой парой «открытый/закрытый ключ» ECC PUF. Это позволяет клиентам для начальной загрузки ключа использовать заводской ECC PUF открытый ключ (public key) вместо диверсифицированного заводского ключа (Diversified Factory Key, DFK), таким образом избавляя от необходимости обращаться к базе данных ключей (DB DFK) от Microsemi.

Для применения указанного режима клиент использует протокол Диффи — Хеллмана на эллиптических кривых (Elliptic Curve Diffie-Hellman, ECDH), чтобы доверенным способом получить общий (сеансовый) закрытый ключ (shared secret key), предназначенный для зашифрования кода авторизации. Операция ECDH происходит внутри защищенной границы АМЗ (HSM) и ПЛИС (FPGA), и общий закрытый ключ (shared secret key) не известен за пределами доверенной зоны. Перед тем как АМЗ (HSM) воспользуется заводским открытым эллиптическим ключом микросхемы (Factory ECC Public Key), он проверяет открытый ключ (public key), проверяя подпись сертификата микросхемы с помощью ключей Microsemi. Это позволяет гарантировать, что открытый ключ (public key) является верным и принадлежит микросхеме, выпущенной компанией Microsemi.

Существует два доступных режима использования ключей (key mode):

  • KFP, в котором микросхема использует сертифицированную ключевую пару (certified key pair), а АМЗ (HSM) применяет случайным образом сгенерированную эфемерную ключевую пару (ephemeral key pair). Это соответствует протоколу ECDH распределения общих секретных ключей (shared secret key).
  • KFPE, в котором микросхема использует сертифицированную ключевую пару вместе с вторичной случайным образом сгенерированной эфемерной ключевой парой (ephemeral key pair), а АМЗ (HSM) использует две случайным образом сгенерированные эфемерные ключевые пары (ephemeral key pairs). В таком случае протокол ECDH выполняется дважды, что приводит к появлению двух общих закрытых ключей (shared secret key), которые применяются в следующем раунде процедуры согласования ключей (key derivation) для генерации единственного общего закрытого ключа (shared secret key). Этот режим является более предпочтительным, чем режим KFP, поскольку в нем используются случайно сгенерированные ключевые пары (key pair), а значит, и более безопасным. Однако для данного режима необходимо больше времени, поскольку выполняются две операции ECDH и происходит генерация ключевых пар.

Более подробную информацию можно получить из документа [7].

Начальная загрузка ключей проекта

Инициализация образа bitstream

Выбирая первичный образ (Master bitstream) в режиме HSM flow, пользователь настраивает ПО генерации образа (bitstream) на протокол кода авторизации (Authorization Code protocol) либо в режиме DFK, либо в режиме Factory PUF ECC key mode. Сгенерированный образ (bitstream) будет иметь специальный запрограммированный алгоритм для запроса компонента кода авторизации (Authorization Code) от заводского АМЗ (M‑HSM). Образ Authorization Code bitstream генерируется динамически заводским АМЗ (M‑HSM) на этапе производственного программирования микросхем. Компонент кода авторизации Authorization Code криптографически связан с программируемым образом (bitstream). Таким образом, его невозможно использовать с любыми другими образами (bitstream), если он будет перехвачен во время программирования. Дополнительная, специфичная для протокола информация создается для использования заводским АМЗ (M‑HSM) при генерации компонента кода авторизации (Authorization Code).

Экспорт задачи HSM Job

Экспортированная задача программирования (programming job) содержит следующую специфичную для протокола информацию:

  • Инструкцию по использованию протокола ключа авторизации (Authorization Key Protocol) совместно с информацией о режиме применения ключа (key mode: DFK, KFP или KFPE).
  • Заголовок для генерации компонента кода авторизации (Authorization Code) и его привязки к связанному образу (bitstream).
  • Значение KIP, зашифрованное на ключе квитанции Ticket Key (раздел «Добавление данных HSM Data к задаче (Job) посредством задач HSM Tasks» предыдущей статьи [13]).

Выполнение задачи

В начале процесса программирования микросхемы программирующий алгоритм считывает серийный номер микросхемы (Device Serial Number, DSN) и отправляет запрос программному обеспечению FlashPro Express на получение кода авторизации (Authorization Code). На основании контекста текущей операции программирования (device programming action) программное обеспечение FlashPro Express получает информацию о квитанции (ticket), зашифрованное значение ключа (KIP) и другие управляющие данные, а затем передает сведения в заводской АМЗ (M‑HSM) в качестве части запроса кода авторизации (Authorization Code).

Если для протокола кода авторизации (Authorization code) выбран режим использования ключа (key mode) DFK, то заводской АМЗ (M‑HSM) ищет зашифрованное значение DFK в собственной базе данных DFK DB и направляет запрос к ядру доверенного исполнения кода (secure execution engine, SEE machine) внутри своего АМЗ (HSM). Программное обеспечение (firmware), выполняющееся внутри доверенной среды исполнения (SEE machine) в АМЗ (HSM), расшифровывает KIP, прикрепленную к образу (bitstream) информацию, заголовок кода авторизации (Authorization Code Header) и собирает компоненты кода авторизации (Authorization Code). На последнем шаге расшифровывается DFK и используется для зашифрования полученных компонентов образа кода авторизации (Authorization Code bitstream).

Программирующее ПО передает компонент кода авторизации (Authorization Code) в микросхему, а затем в компоненты образа для программирования (main programming bitstream). В случае программирования чистой микросхемы главным образом (master bitstream) микросхема для вычисления DFK использует свой предварительно запрограммированный заводской ключ (factory key, FK) и идентификатор UUID из заголовка кода авторизации (Authorization Code). Микросхема применяет DFK для аутентификации и распаковки (расшифрования) ключа KIP из зашифрованной порции данных кода авторизации (Authorization Code). В завершение процесса ключ KIP используется для аутентификации и расшифрования компонентов главного образа (main master bitstream), таких как компоненты политики безопасности (security) и дополнительные компоненты для программирования массива ПЛИС (FPGA fabric) и энергонезависимой памяти (eNVM).

Если для кода авторизации (Authorization Code) выбран режим использования ключа (key mode) KFP или KFPE, то заводской АМЗ (M‑HSM) генерирует эфемерную эллиптическую ключевую пару (ephemeral ECC key pair) и обменивается ее открытым ключом (public key) с микросхемой. Затем применяется протокол ECDH для доверенной передачи общего закрытого ключа (shared secret key) внутрь доверенной среды исполнения (secure execution engine, SEE machine, рис. 2).

Работа в доверенной среде исполнения (SEE) и без нее

Рис. 2. Работа в доверенной среде исполнения (SEE) и без нее

Программное обеспечение (firmware), работающее в доверенной среде исполнения (SEE machine) внутри АМЗ (HSM), расшифровывает KIP, прикрепленную к образу (bitstream) информацию и заголовок кода авторизации (Authorization Code Header) и собирает компоненты кода авторизации (Authorization Code component). На последнем шаге для зашифрования итогового компонента образа с кодом авторизации (Authorization Code bitstream component) используется общий закрытый ключ (shared secret key). Программирующее ПО помещает компонент кода авторизации (Authorization Code component) в микросхему и следом размещает его в компонентах главного образа (main programming bitstream). В случае программирования чистой микросхемы главным образом (master bitstream) микросхема использует общий закрытый ключ (shared secret key), который создается в результате выполнения протокола ECDH, для аутентификации и распаковки (расшифрования) KIP из зашифрованной порции данных кода аутентификации (Authorization Code). В завершение процесса ключ KIP используется для аутентификации и расшифрования компонентов главного образа (main master bitstream), таких как компоненты политики безопасности (security) и дополнительные компоненты для программирования массива ПЛИС (FPGA fabric) и энергонезависимой памяти (eNVM).

При обновлении микросхемы, применяющей уникальный пользовательский ключ (per-device user key), она восстанавливает выбранный пользовательский ключ (user key) из защищенного сегмента своей энергонезависимой памяти (NVM security segment) и назначает его для аутентификации кода авторизации (Authorization Code) и распаковки KIP из зашифрованной порции данных. Ключ KIP предусмотрен для аутентификации и расшифрования компонентов образа обновления (main update bitstream), содержащего компоненты массива ПЛИС (FPGA fabric) и энергонезависимой памяти (eNVM).

Начальная загрузка уникальных для микросхемы ключей

Хотя описанная здесь последовательность операций и аналогична процедуре загрузки первичного ключа (Initial Key Loading) для ключей проекта (Project keys), однако она имеет несколько дополнительных шагов.

В рассматриваемом сценарии сгенерированный утилитой Job Manager главный образ (Master bitstream) не содержит полного комплекта защиты. Это происходит из-за того, что значения уникальных для микросхемы ключей (per-device key) могут быть получены только во время программирования, после того как будет прочитан серийный номер микросхемы (DSN). Поэтому компонент защиты передается в заводской АМЗ (M‑HSM) в виде предварительно заполненного шаблона через структуры данных, защищенные квитанцией Job Ticket. В дополнение к стандартным для протокола кода авторизации (Authorization Code protocol) данным модуль АМЗ (HSM), подключенный к заводскому АМЗ (M‑HSM), получает шаблон компонента защиты (security component template) вместе с базовыми ключами (полученными из файла KeySet) и в процессе программирования создает фактический уникальный для устройства ключ или ключи (per-device key). Такой ключ (или ключи) вставляется в шаблон компонента защиты. Затем программное обеспечение модуля АМЗ (HSM) объединяет криптографическим способом все компоненты образа (bitstream). После чего проделывает те же самые шаги, что и описанные в разделе «Начальная загрузка ключей проекта», посвященном использованию ключей проекта (project keys).

Последовательность создания образа обновления при использовании уникальных для микросхемы ключей

Эта последовательность также аналогична главной последовательности Main flow технологии SPPS, при которой происходит загрузка первичного ключа (initial key) с использованием ключей проекта (project keys). Различие заключается в том, что код авторизации (Authorization Code) зашифровывается на одном и том же уникальном для микросхемы ключе UEK1, UEK2 или UEK3, полученном на заводском АМЗ (M‑HSM) при начальном программировании.

В данном случае информация из квитанции Ticket, передаваемая в заводской АМЗ (M‑HSM), содержит полученное базовое значение уникального для микросхемы ключа (per-device key). Это значение изначально берется из файла KeySet на стороне пользовательского АМЗ (U‑HSM). Программное обеспечение (firmware) модуля АМЗ (HSM), присоединенного к заводскому АМЗ (M‑HSM), будет использовать присланный серийный номер микросхемы (DSN) и базовый ключ (base key) в уникальном для каждой микросхемы протоколе (Per-device protocol), чтобы получить фактическое значение уникального для микросхемы ключа (per-device key). Затем на этом значении зашифровывается компонент кода авторизации (Authorization Code), который отсылается в микросхему тем же путем, что и первичный ключ (Initial Key) для обновляемых компонентов ПЛИС (FPGA) или энергонезависимой памяти (eNVM).

Следует отметить, что в рассмотренной последовательности не требуется БД заводских ключей (DFK DB) на стороне заводского АМЗ (M‑HSM).

 

Защита от несанкционированного производства

Протокол кода авторизации (Authorization Code protocol) разрешает пользователю ограничить выполнение любой процедуры программирования на заданное максимальное количество микросхем.

Это возможно по следующим причинам:

  • Чистые микросхемы не имеют ключа KIP, и ключ KIP необходимо прогружать в каждую программируемую микросхему.
  • Ключ KIP не хранится в микросхеме даже после использования в цикле программирования микросхемы.

Ключ KIP передается в зашифрованном виде, с использованием уникального для микросхемы (per-device key) ключа шифрования (DFK, KFP, KFPE или уникальный для микросхемы токен UEK1/2/3). Таким образом, один и тот же код авторизации (Authorization Code) не может быть предназначен для нескольких микросхем.

Аппаратное обеспечение модуля АМЗ (HSM) оснащено счетчиками защиты от перепроизводства (overbuild protection counter) как частью информации, принимаемой из квитанции Ticket, и будет останавливать генерацию новых кодов авторизации (Authorization Codes) после того, как сгенерировано максимально допустимое количество кодов авторизации (Authorization Code).

 

Уникальный для микросхемы протокол

Уникальный для микросхемы протокол (Per-device protocol) предназначен для вычисления уникальных для микросхемы (per-device) значений ключей UPK1/UPK2/UEK1/UEK2/UEK3/DPK. Уникальные для микросхемы ключи (Per-device keys) создаются поверх стандартных для микросхем SmartFusion2/IGLOO2 типов ключей. Они программируются в микросхему в качестве стандартных ключей UPK1/UPK2/UEK1/UEK2/UEK3/DPK. Если какой-либо из ключей шифрования становится уникальным для микросхемы (per-device key), то ключ доступа (passcode), который защищает такой ключ от перезаписи, тоже становится уникальным для микросхемы (per-device passcode).

С помощью уникального для микросхемы протокола (per-device protocol) из базового ключа (base key) и серийного номера микросхемы (DSN) формируются специфические для микросхемы ключи. Это позволяет создавать пользовательские модели программирования, где операции программирования могут быть авторизованы для микросхемы на основе ее серийного номера (DSN).

Получение уникальных для микросхемы значений ключей (per-device key) происходит с помощью односторонних криптографических операций, принимающих в качестве входных параметров базовый ключ (base key) и серийный номер микросхемы (DSN), выполняющихся программным обеспечением (firmware), реализованным внутри модуля АМЗ (HSM). Пользовательский АМЗ (U‑HSM) создает файл KeySet, который содержит значения базового ключа (base key) для ключей UPK1/UPK2/UEK1/UEK2/UEK3/DPK. Эти значения передаются в заводской АМЗ (M‑HSM) через квитанции Ticket под защитой ключа квитанции (Ticket key).

Уникальный для микросхемы протокол (per-device protocol) используется в технологии SPPS в следующих случаях:

  • Загрузка первичного ключа (Initial key) посредством главного образа (Master bitstream) — для программирования уникальных для микросхемы ключей (per-device key).
  • Образ обновления (Update bitstream), если микросхема имеет запрограммированные уникальные (per-device) ключи шифрования, — для генерации требуемых кодов авторизации (Authorization Code).
  • В протоколе OTPK — чтобы разблокировать микросхему, если используются уникальные для микросхемы коды доступа (per-device pass key).

 

Протокол однократного ключа доступа

Этот протокол поддерживается микросхемами SmartFusion2/IGLOO2 и используется для разблокирования защиты от перезаписи (overwrite-protection) или при непроверяемых настройках политики безопасности (если таковые используются):

В операциях «Стирание (Erase)/Проверка программирования (Verify)» в последовательности операций Master bitstream flow.

В операциях «Программирование (Program)/Стирание (Erase)/Проверка программирования (Verify)» для образа обновления (Update bitstream), если массив ПЛИС (FPGA fabric) и/или энергонезависимая память (eNVM) имеют защитную блокировку.

Описанный протокол разрабатывался для временной разблокировки защиты при выполнении операции программирования. Назначение АМЗ (HSM) — спрятать открытые значения ключей доступа (pass keys).

Технология SPPS автоматически использует протокол OTPK без какого-либо вмешательства со стороны пользователя.

 

Сертификат соответствия микросхемы

В процессе программирования микросхема может генерировать подписанные криптографическим способом журналы операций для каждого только что запрограммированного компонента образа (bitstream). Журналы операций для каждого компонента с созданными для них с помощью АМЗ (HSM) проверочными значениями (кодами аутентификации сообщения — message authentication code, MAC) именуются сертификатом соответствия (Certificate of Conformance, CoC). Сертификаты соответствия (CoC) могут быть использованы в качестве доказательства, что микросхема запрограммирована конкретным проектом.

Коды аутентификации в сертификате соответствия (CoC) могут быть проверены утилитой Job Manager с помощью пользовательского АМЗ (U‑HSM).

Микросхема будет генерировать и возвращать сертификат соответствия (CoC), если пользователь запрашивает его при инициализации программирования образа (bitstream).

 

Протокол сертификатора завершения задачи

При завершении задачи (Job) квитанции для выполненной задачи (Job Ticket) удаляются из модуля АМЗ (HSM). Для каждой удаленной квитанции (ticket) модуль АМЗ (HSM) возвращает доказательство ее удаления. Эта информация проверяется утилитой Job Manager с помощью пользовательского АМЗ (U‑HSM). Информация защищена криптографическим способом и не может быть модифицирована без обнаружения такой модификации.

Сертификатор завершения задачи (Job end certifier) гарантирует, что задача программирования не может быть продолжена и является составной частью механизма защиты от несанкционированного производства (overbuild protection mechanism).

 

Протокол проверки аутентичности микросхемы

Микросхемы SmartFusion2/IGLOO2 имеют встроенные сертификаты, позволяющие программному обеспечению Microsemi проверять их подлинность при программировании. Эта проверка выполняется утилитой FlashPro Express при каждой операции программирования как часть цепочки операций проверки (сертификации). Подробности можно найти в Руководстве [3].

Для любой микросхемы, не прошедшей проверку подлинности (Authenticity Check), выдается предупреждение.

 

Серверы АМЗ

Теперь обратимся к назначению пользовательских и заводских серверов АМЗ (User and Manufacturer HSM server): к сценариям развертывания и схеме управления ключами (key management scheme).

Серверы АМЗ (HSM server) обеспечивают защищенное доверенное окружение, которое позволяет в рамках SPPS:

  • Генерировать и защищать пользовательские ключи шифрования (user encryption key) и ключи доступа (user pass key), базовые ключи (base key), одноразовые случайные числа (nonce) и т. п.:
    •  прикладные ключи (Application key) и связанные с ними метаданные хранятся как зашифрованные ключевые токены на устройствах хранения информации серверов АМЗ (HSM-server), например жестких дисках.
  • Выполнять криптографические алгоритмы и протоколы с использованием защищенных ключей:
    • генерировать данные протокола — например, компоненты образа кода авторизации (Authorization Code bitstream), раздел «Протокол кода авторизации» и т. п.;
    • проверять валидаторы, сгенерированные другими АМЗ (HSM) или микросхемами — например, сертификатами соответствия CoC, сертификаторами завершения задачи (Job End certifier) и т. п.;
    • передавать информацию между серверами АМЗ (HSM server) по защищенному каналу, созданному с помощью защищенного ключа (Secured key), и протокола, реализованного программным обеспечением (firmware) и выполняющегося в доверенном окружении (SEE) внутри аппаратной платформы модуля АМЗ (HSM).

 

Модуль аппаратной защиты, предназначенный для SPPS

В технологии SPPS используются аппаратные модули защиты (Hardware Security Module, HSM) nShield Edge (рис. 3) и nShield Solo (рис. 4) производства компании Thales. Оба модуля сертифицированы в соответствии с FIPS140-2 по уровню защиты Level 3. Модуль nShield Edge подключается к компьютеру через USB-разъем.

Аппаратный модуль защиты (HSM) nShield Edge

Рис. 3. Аппаратный модуль защиты (HSM) nShield Edge

Модуль nShield Solo HSM выполнен в виде платы в форм-факторе PCIe и может устанавливаться в обычные персональные компьютеры и серверы со свободным слотом PCIe.

Аппаратный модуль защиты (HSM) nShield Solo

Рис. 4. Аппаратный модуль защиты (HSM) nShield Solo

Модуль nShield Edge HSM имеет интегрированный считыватель смарт-карт. В комплект поставки nShield Solo HSM входит внешний считыватель смарт-карт.

С точки зрения производительности nShield Solo превосходит nShield Edge и является оптимальным для применения в качестве пользовательского АМЗ (U‑HSM) для высокопроизводительного программирования кода аутентификации (Authentication Code) и генерации одноразового кода доступа (passcode). Модуль nShield Edge оптимален для использования в качестве заводского АМЗ (M‑HSM) для выполнения операций генерации легковесного образа (bitstream). С точки зрения программного обеспечения и процедуры развертывания оба модуля взаимозаменяемы, и выбор конкретного варианта обычно основан на специфике условий эксплуатации и размере микросхем SmartFustion2/IGLOO2, которые необходимо обслуживать.

Модули АМЗ (HSM) имеют стандартные, реализованные компанией Thales и сертифицированные FIPS криптографические алгоритмы и выполняют пользовательские алгоритмы внутри защищенного ими периметра. Данные модули имеют ограниченный объем внутренней энергонезависимой памяти (non-volatile memory, NVM) для хранения мастер-ключа (master key) модуля и информации из квитанций Job Ticket, такой как обязательные данные квитанции Ticket, данные по защите от несанкционированного производства (overbuild protection) и т. п. Вся остальная информация, для которой требуется защита с помощью АМЗ (HSM), хранится на жестком диске управляющего ПК (host PC) или в любом другом хранилище данных, подключенном к управляющему ПК по локальной сети.

Дополнительную информацию о модулях nShield Edge и nShield Solo можно получить из документов nShield Edge Solo User Guide от компании Thales и отчетов по сертификации в FIPS [9, 10, 11].

 

Архитектура сервера АМЗ

Модуль АМЗ (HSM) должен быть подключен к управляющему ПК (host PC), на котором выполняется стандартное программное обеспечение для модулей nShield от компании Thales. Это программное обеспечение предоставляет доступ к модулям АМЗ (HSM). Серверы пользовательского АМЗ (U‑HSM) и заводского АМЗ (M‑HSM) имеют аналогичную архитектуру, но отличаются тем, что в качестве клиентского ПО используется FlashPro Express для заводского АМЗ (M‑HSM) или Job Manager для пользовательского АМЗ (U‑HSM), как показано на рис. 5.

Компоненты M‐HSM и U‐HSM

Рис. 5. Компоненты:
а) M‐HSM;
б) U‐HSM

Клиентское приложение (на приведенной блок-схеме Job Manager) делает запросы к серверу. Программное обеспечение сервера АМЗ (HSM server), выполняющееся на управляющем ПК (host PC), обслуживает клиентские запросы. В зависимости от запроса оно считывает всю необходимую информацию из базы данных, хранящейся на управляющем ПК (host PC), и передает ее посредством программного обеспечения nShield программному обеспечению (firmware), работающему внутри модуля АМЗ (HSM). Модуль АМЗ (HSM) расшифровывает присланные ключи и обрабатывает запрос. В конце обработки он зашифровывает выходные данные и отправляет ответ обратно серверу АМЗ (HSM server). Часть информации хранится в локальной базе данных (например, сертификаты соответствия, CoC). Вся запрошенная клиентом информация возвращается к запрашивавшему.

Программное обеспечение защищенной области исполнения (SEE firmware) хранится на диске управляющего компьютера (host PC) в зашифрованном виде.

 

Функциональность сервера АМЗ

В технологии SPPS применяется сервер пользовательского АМЗ (User HSM, U-HSM) и сервер заводского АМЗ (Manufacturer HSM, M‑HSM).

Пользовательский АМЗ

Пользовательский АМЗ (User HSM) позволяет инженеру по эксплуатации (OE) генерировать ключи и затем работать с ними при создании образа для программирования микросхемы (programming bitstreams).

Пользовательский АМЗ (U‑HSM) обеспечивает следующую функциональность:

  • Генерация пользовательских ключей (user key):
    • ключей (Base Keys) для получения уникальных для микросхемы (per-device) пользовательских ключей шифрования (User encryption key);
    • пользовательских кодов доступа (User passcode);
    • базовых ключей шифрования (encryption key) и кодов доступа (passcode).
  • Зашифрование образа для программирования микросхемы (programming bitstream).
  • Генерация данных для защищенных протоколов (security protocol). Подробности можно найти в Руководстве [4].
  • Создание квитанций для задач программирования (Job Ticket).
  • Создание самих задач программирования (Programming Job).
  • Подтверждение (Validation) результатов программирования, раздел «Сертификат соответствия микросхемы (CoC)».
  • Подтверждение (Validation) завершения задачи программирования (programming job), раздел «Протокол сертификатора завершения задачи».
  • Подготовка данных по производству микросхемы для заводского АМЗ (M‑HSM), таких как база данных заводских ключей (DFK DB) и изготовление ключей (подробности в документе [6]).
  • Проверка выполнения задачи Job Execution (функция M‑HSM для U‑HSM):
    • полная функциональность заводского АМЗ (M‑HSM).
  • Поддержка всех базовых криптографических алгоритмов и генерация случайных чисел криптографического качества.

Заводской АМЗ

Заводской АМЗ (M‑HSM) имеет программное обеспечение и прошивку (firmware), функциональность которых ограничена выполнением задач программирования, и спроектирован для использования производителем при выполнении следующих задач:

  • Создание квитанций задач (Job Ticket) с привязкой к физическому модулю АМЗ (HSM) — обслуживание запросов Job Request.
  • Генерация данных для протоколов (подробности в Руководстве [4]).
  • Проверка подлинности микросхем.
  • Защита от несанкционированного производства (Overbuild protection).
  • Доверенная загрузка начального ключа (initial key).
  • Предоставление данных о состоянии задачи (job status).
  • Предоставление доказательств завершения работы (proof of job completion).
  • Формирование сертификатов соответствия (CoC).
  • Поддержка всех базовых криптографических алгоритмов и генерация случайных чисел криптографического качества.

 

Сценарии развертывания

Серверы пользовательского АМЗ (U‑HSM Server) и заводского АМЗ (M‑HSM Server) представляют собой службы ОС Windows. Клиентские приложения АМЗ (HSM client), Job Manager и FlashPro Express могут быть установлены и функционировать как на системах с ОС Linux, так и на системах с ОС Windows.

На платформах с ОС Windows клиентские приложения можно установить в одной и той же или нескольких физических операционных системах. В платформах в ОС Linux клиентские приложения всегда устанавливаются на различных физических ОС.

Существует два основных сценария развертывания АМЗ (HSM): в качестве сервера (Server) и в качестве рабочей станции (Workstation).

Дополнительную информацию можно получить из документов [5, 6].

Серверный сценарий

В серверном сценарии развертывания ПО сервера АМЗ (HSM) выполняется на специализированном ПК. Все клиентские приложения имеют доступ к АМЗ (HSM) по локальной сети.

Одно или более приложений Job Manager могут иметь одновременный доступ к одному и тому же серверу клиентского АМЗ (U‑HSM server), и одно или более приложений FlashPro Express могут одновременно использовать один и тот же заводской АМЗ (M‑HSM).

Для доступа к АМЗ (HSM) необходимо, чтобы был открыт ряд портов протокола TCP/IP.

Дополнительную информацию можно получить из документов [5, 6].

Сценарий рабочей станции

В сценарии развертывания рабочей станции (workstation) предполагается, что клиентские приложения и сервер АМЗ (HSM server) совместно используют одну и ту же физическую ОС Windows. Рабочие станции в операционном (Operation) или производственном (Production) окружении могут быть полностью изолированы от сетей передачи данных.

Замечания относительно использования виртуальных машин

Возможна работа серверной части АМЗ (HSM server) или клиентских приложений внутри виртуальных машин, таких как VMWare player. Это обеспечивает гибкость при создании дополнительных гибридных сценариев развертывания. Например, в виртуальной машине с ОС Linux может выполняться Job Manager, а в виртуальной машине с ОС Windows — установлен сервер пользовательского АМЗ (U‑HSM server). Данный сценарий позволяет применять одну и ту же физическую машину для клиента и для сервера. Подобная гибридная рабочая станция (Workstation) может быть изолирована от внешних сетей передачи данных.

Установка и подготовка к эксплуатации сервера АМЗ

Установка и подготовка к эксплуатации серверов пользовательского АМЗ (U‑HSM server) и заводского АМЗ (M‑HSM server) производится вручную или с помощью утилиты установщика, предоставляемой компанией Microsemi.

Дополнительную информацию о получении компонентов серверов АМЗ (HSM server), а также инструкции по установке и подготовке к эксплуатации можно найти в документах [5, 6].

Использование веб-портала Microsemi

Веб-портал Microsemi Web Portal (https://ops.microsemi.com/dfk) разработан для обеспечения клиентов, использующих технологию SPPS, удобным способом взаимодействия с заводским АМЗ (Manufacturing HSM, M‑HSM) компании Microsemi при развертывании собственных пользовательских АМЗ (U‑HSM) и заводских АМЗ (M‑HSM). Кроме того, он позволяет IHP6-клиентам Microsemi инициировать их работы по программированию, выполняемые в рамках IHP, и управлять этими работами.

 

Доверенное окружение АМЗ

Далее приведен краткий обзор доверенного окружения (security environment), применяемого пользовательским АМЗ (U‑HSM) и заводским АМЗ (M‑HSM). Представлена ключевая схема управления и взаимодействия между клиентскими U‑HSM и M‑HSM и Microsemi Manufacturing HSM.

Основными компонентами доверенного окружения АМЗ (HSM security environment) являются:

  • Данные, хранящиеся в защищенной области (Security World).
  • Модуль АМЗ (HSM), подключенный к защищенной области (Security World).
  • Набор смарт-карт администратора (Administrator Card Set, ACS), используемый администратором защищенной области (Security World).

Рассмотрим более подробно каждый из компонентов.

Защищенная область

Защищенная область (Security World) — это ключевая часть сервера АМЗ (HSM server), представляющая собой защищенный блок данных (security data domain), физически расположенный на жестком диске управляющего ПК (host PC) и используемый подключенным к нему модулем АМЗ (HSM). Защищенная область (Security World) содержит конфигурационные данные и ключи защиты (security key), применяемые сервером АМЗ (HSM server).

Защищенная область (Security World) создается и поддерживается с помощью специализированного ПО компании Thales. Полное описание утилит для управления защищенной областью (Security World) содержится в Руководстве [8]. В этом документе имеется обзор ключей защиты (security key), используемых в технологии SPPS.

Для реализации технологии SPPS необходимо выполнить ввод в эксплуатацию и пользовательского АМЗ (U‑HSM), как описано в документе [6], и заводского АМЗ (M‑HSM), как указано в документе [5].

В описание процесса входят инструкции по созданию новой защищенной области (Security World) и ключей, используемых АМЗ (HSM). Кроме того, рассказано, как выполнить обмен ключами (key exchange) и как управлять БД заводских ключей DFK DB.

Каталог защищенной области

Все данные, относящиеся к защищенной области (Security World), хранятся в специальном каталоге (Security World directory) на диске управляющего ПК (host PC). Реальное имя каталога определяется при инсталляции. По умолчанию используется путь: C:\ProgramData\nCipher\Key Management Data\local

Данные защищенной области

Каталог защищенной области (Security World directory) содержит все данные, относящиеся к защищенной области (Security World), и для него могут выполняться операции резервного копирования, восстановления из резервных копий, копирования или перемещения в другой АМЗ (HSM). Он включает идентификационную информацию для АМЗ (HSM identity information), и для него должна периодически проводиться операция резервного копирования.

В набор данных защищенной области (Security World data) входит следующее:

  • Идентификационные данные защищенной области (Security World identity) и настройки конфигурации (configuration settings).
  • Данные о модулях АМЗ (HSM), подключенных к защищенной области (Security World).
  • Данные о наборе карт администратора (ACS), связанном с защищенной областью (Security World).
  • Ключи, предназначенные для использования внутри АМЗ (HSM key set).
  • Закрытый компонент (private key) ключевой пары «закрытый ключ/открытый ключ» (private/public key infrastructure) для создания защищенного канала обмена данными.
  • Открытые ключи (public keys) других АМЗ (HSM), с которыми предполагается защищенный обмен данными.
  • Заводские ключи Microsemi (Microsemi Manufacturing Key), используемые при генерации образа прошивки (bitstream) пользовательским АМЗ (U‑HSM) и в протоколах заводского АМЗ (M‑HSM).

Пример содержимого каталога защищенной области пользовательского АМЗ (U‑HSM Security World directory) показан на рис. 6.

Пример структуры каталога Security World для U‐HSM

Рис. 6. Пример структуры каталога Security World для U‐HSM

Следует отметить, что заводской АМЗ (M‑HSM) имеет очень похожую структуру данных защищенной области (Security World). Основным отличием между ними является длина идентификатора UUID, применяемого каждым из типов АМЗ (HSM): 32 для U‑HSM UUID и 40 для M‑HSM UUID, а также префиксы имен ключей: cu для U‑HSM и cm для M‑HSM соответственно.

Создание защищенной области

Инструкции по созданию новой защищенной области (Security World) можно найти в документе [6] для пользовательского АМЗ (U‑HSM) и в документе [5] для заводского АМЗ (M‑HSM). В этот процесс входит также инициализация набора карт администратора (Administrator Card Set, ACS), предусмотренная для операций администрирования защищенной области (Security World), таких как подключение новых модулей АМЗ (HSM), и т. п.

Информация о защищенной области (Security World) расположена в файле с именем world, как показано на рис. 6.

Сведения о каждой карте набора ACS хранятся в файле с префиксом card_, например card_7fb2caf3494e585d4664febf7d624ab1b99e7d50_1.

Подключение модуля АМЗ к защищенной области

В процессе создания защищенной области (Security World) используется модуль АМЗ (HSM), подключенный к управляющему компьютеру (host PC). Модуль АМЗ (HSM) подсоединяется к защищенной области (Security World), в результате ПО nCipher компании Thales в каталоге защищенной области (Security World directory) создает файл, в котором содержится информация о подключенном модуле. Имя файла строится по шаблону “module_<module serial number>”, как показано в примере на рис. 6.

Подключенный модуль АМЗ (HSM) можно заменить другим модулем в любое время после создания защищенной области (Security World).

 

Схема управления ключами

Рассмотрим схему управления ключами (key management scheme, рис. 7), используемую обоими типами серверов АМЗ (HSM server) в их взаимодействии между собой, а также с заводским сервером АМЗ Microsemi (Microsemi Manufacturing HSM Server).

Схема управления ключами

Рис. 7. Схема управления ключами

Все ключи защиты (security keys), применяемые защищенной областью (Security World), хранятся в каталоге защищенной области (Security World directory) в виде файлов токенов (key token files), как видно на рис. 6. Все секретные данные в файлах токенов (key token files) зашифрованы, снабжены водяными знаками и подписаны. Эти файлы являются частью сертифицированной по FIPS140-2 Level 2 и Level 3 системы управления ключами nShield key management system. Дополнительную информацию можно найти в документе [8].

Списки управления доступом к ключам защищенной области (Security World Key Access Control Lists, SW Key ACL) предназначены для управления тем, в каких операциях можно использовать ключ, может ли ключ после генерации постоянно храниться в виде токена, может ли ключ восстанавливаться администратором безопасности (Security Officer) защищенной области (Security World), и другие атрибуты ключа.

Одной из функций списков SW Key ACL является использование в технологии SPPS в схеме прикладных ключей доверенной среды исполнения (SEE application key scheme). Эта схема позволяет выполнять все операции шифрования, доступные для данного типа ключа, только в рамках должным образом подписанного приложения (прошивки АМЗ) доверенной среды исполнения (SEE).

Ключ целостности SEE

На аппаратной платформе АМЗ (HSM hardware) выполняется два типа внутреннего программного обеспечения (firmware):

Стандартное программное обеспечение nShield firmware, поставляемое в составе АМЗ (HSM) компанией Thales, обеспечивает базовую функциональность АМЗ (HSM).

  • Пользовательское программное обеспечение (firmware), которое реализует протоколы защиты (security protocol) компании Microsemi и использует различные ключи, созданные для технологии SPPS. Для этого ПО (firmware) имеется термин «доверенная среда исполнения» (Secure Execution Engine, SEE machine).
  • Стандартное программное обеспечение (firmware) управляет работой доверенной среды исполнения SEE machine. Это управление включает загрузку, расшифрование и доверенную интеграцию между прошивкой (firmware), реализованной ключами защиты (security key), используемыми в технологии SPPS, и данными, хранящимися внутри энергонезависимой памяти (non-volatile memory, NVRAM) модуля АМЗ (HSM module):
    1. Образ SEE machine подписан закрытой частью (private component) ключа целостности SEE (SEE Integrity Key) компании Microsemi.
    2. Открытая часть (public component) ключа целостности SEE (SEE Integrity Key) устанавливается в каталог защищенной области (Security World directory) при установке АМЗ (HSM) в файл key_seeinteg_userdata_signer, как показано на рис. 6.
    3. Все ключи, созданные и используемые в рамках технологии SPPS, подписаны открытой частью (public component) ключа целостности SEE (SEE Integrity Key). Эта подпись содержит хэш закрытой части (private component) ключа, позволяя стандартному программному обеспечению (firmware) nShield применить политику ACL, проверив соответствие подписей образа SEE machine и используемых ею ключей.

Закрытые/открытые ключи АМЗ

Для каждого сервера АМЗ (HSM server) пользователь создает две пары «закрытый ключ/открытый ключ» (private key/public key). Одна пара закрытый/открытый ключ используется для зашифрования и расшифрования. Эти ключи на рис. 6 изображены с префиксами “key_simple_g4cu_seepk” и “key_simple_g4cu_seesk”. Открытый ключ (public key) передается другим серверам АМЗ (HSM server) для зашифрования данных, отправляемых обратно в данный АМЗ (HSM). Затем АМЗ (HSM) использует закрытый ключ (private key component) для расшифрования полученных данных. Закрытый ключ (private component) представляет собой постоянный ключ, созданный в каталоге защищенной области (Security World directory) и хранящийся в зашифрованном виде.

Вторая пара закрытый/открытый ключ используется для формирования и проверки подписи. Эти ключи изображены с префиксом “key_simple_g4cu_seessk” и “key_simple_g4cu_seespk” (рис. 6). Модуль АМЗ (HSM) использует закрытый ключ (private key component) для формирования подписи к данным, которые пересылает другим серверам АМЗ (HSM server). Открытый ключ (public key) отправляется другим серверам АМЗ (HSM server) для проверки подписи данных, отправленных этим АМЗ (HSM), что позволяет гарантировать аутентичность (т. е. удостоверение личности подписавшего) и целостность (то есть проверку наличия несанкционированного доступа и разрушение) импортированных данных. Закрытый ключ (private component) представляет собой постоянный ключ, созданный в каталоге защищенной области (Security World directory) и хранящийся в зашифрованном виде.

Открытый ключ (public key) сервера АМЗ (HSM server) распространяется в виде сертификата, который содержит криптографическое доказательство того, что он был создан модулем АМЗ nShield HSM. Эта привязка осуществляется посредством специального файла HSM Warrant и может быть проверена другими АМЗ (HSM) при импорте открытого ключа (public key component). Такой механизм делает почти невозможным для нарушителя получение доступа к любому из серверов АМЗ (HSM server), используемых для реализации технологии SPPS, отправив ему ложно сгенерированный открытый ключ (public key).

Файл nShield HSM Warrant

Конструкция nShield HSM warrant представляет собой файл, созданный непосредственно компанией Thales. Он уникален и входит в комплект поставки каждого модуля АМЗ nShield Solo или Edge HSM, который обеспечивается компанией Microsemi как часть процесса приобретения модуля.

Данные внутри файла HSM warrant позволяют убедиться, что модуль nShield с конкретным серийным номером (ESN) и значением KLF сертифицирован компанией Thales.

Ключ внутренней защиты

Ключ ISK является постоянным ключом защищенной области (Security World), сгенерированным пользователем. Ключ ISK хранится в каталоге защищенной области (Security World directory) в файле с именем по умолчанию key_simple_g4see_isk, как показано в примере на рис. 6. Актуальное имя файла может быть сконфигурировано пользователем на основание инструкций, представленных в документах [5, 6].

Значение ключа ISK генерируется случайным образом модулем АМЗ (HSM module) и является уникальным внутри защищенной области (Security World). Ключ может использоваться только приложениями доверенной среды исполнения (SEE).

Импорт открытого ключа из других АМЗ

Перед тем как АМЗ (HSM) сможет организовать канал обмена данными с другими АМЗ (HSM), необходимо вручную доверенным образом произвести обмен открытыми ключами (public key). В рамках обмена ключами каждый сервер АМЗ (HSM server), используемый в технологии SPPS, должен импортировать по два открытых ключа (public key) из каждого другого АМЗ (HSM). Этот механизм отражен в примере, рассмотренном в разделе «Закрытый/открытый ключи АМЗ (HSM)». Подробности об импорте открытых ключей можно найти в документах [5, 6].

В процесс импорта открытого ключа (public key) входит строгая проверка сертификата генерации ключа для импортируемого ключа. Эта проверка призвана подтвердить, что ключ был сгенерирован настоящим АМЗ (HSM) в составе официального приложения в рамках SPPS.

После успешного завершения проверки ключ ISK применяется для формирования подписи импортированного открытого ключа (public key), которая служит доказательством завершения проверки импорта ключа. Эта подпись необходима для того, чтобы ключ мог работать с приложениями в доверенной среде исполнения (SEE).

Пример импортированного открытого ключа (public key) показан на рис. 6 — здесь защищенная область (Security World) имеет следующие импортированные открытые ключи (public key):

  • key_simple_g4cm-seepk‑0000000000000000000000000000000000000002:
    • открытый ключ шифрования (encryption public key) заводского АМЗ (M‑HSM) с UUID “0000000000000000000000000000000000000002”;
    • обратите внимание, что заводской АМЗ (M‑HSM) имеет UUID длиной 40 шестнадцатеричных символов.
  • key_simple_g4cu-seepk‑00000000000000000000000000000001:
    • открытый ключ шифрования (encryption public) данного пользовательского АМЗ (U‑HSM);
    • обратите внимание, что пользовательский АМЗ (U‑HSM) имеет UUID длиной только 32 шестнадцатеричных символа;
    • это необходимо для активации функции заводского АМЗ (M‑HSM) для сервера пользовательского АМЗ (U‑HSM server).
  • key_simple_g4cm-seespk‑0000000000000000000000000000000000000002:
    • открытый ключ проверки подписи (verify public key) заводского АМЗ (M‑HSM) с UUID “0000000000000000000000000000000000000002”;
    • обратите внимание, что заводской АМЗ (M‑HSM) имеет UUID длиной 40 шестнадцатеричных символов.
  • key_simple_g4cu-seespk‑00000000000000000000000000000001:
    • открытый ключ проверки подписи (verify public key) данного пользовательского АМЗ (U‑HSM);
    • обратите внимание, что пользовательский АМЗ (U‑HSM) имеет UUID длиной только 32 шестнадцатеричных символа;
    • это необходимо для активации функции заводского АМЗ (M‑HSM) для сервера пользовательского АМЗ (U‑HSM server).

Заводские ключи Microsemi

Это специальные ключи компании Microsemi, импортируемые для каждого типа микросхем как часть получения базы данных DFK DB. Дополнительную информацию можно найти в документе [6] для пользовательского АМЗ (U‑HSM) и в документе [5] для заводского АМЗ (M‑HSM).

Каждый импортированный ключ создается в файле, имя которого начинается с префикса ключа “key_simple_f4mf-”. Эти ключи предназначены как для пользовательских АМЗ (U‑HSM), так и для заводских АМЗ (M‑HSM). Они отправляются в каждый АМЗ (HSM) из заводского АМЗ Microsemi (Microsemi Manufacturing HSM). Значения ключей зашифровываются на открытом ключе (public key) принимающего АМЗ (HSM).

Мастер-ключ пользовательского АМЗ

Мастер-ключ пользовательского АМЗ (U‑HSM Master Key) создается пользователем. Это симметричный ключ, который позволяет пользовательскому АМЗ (U‑HSM) защищать файлы с набором ключей (KeySet file) и мастер-ключи квитанции задач Job Ticket.

Мастер-ключ пользовательского АМЗ (U‑HSM Master Key) зашифровывает мастер-ключ квитанции задачи (Job Ticket Master Key), который в свою очередь защищает все приватные данные квитанции задач Job Ticket. Чтобы отправить данные квитанции (Ticket data) заводскому АМЗ (M‑HSM), пользовательскому АМЗ (U‑HSM) необходимо только перепаковать мастер-ключ квитанции задач Job Ticket Master Key на открытом ключе (public key) заводского АМЗ (M‑HSM).

Работа с DFK DB

База данных диверсифицированных заводских ключей DFK DB используется заводским АМЗ (M‑HSM) в процессе загрузки начального ключа (initial key). Кроме того, она может найти применение и при тестировании работы пользовательского АМЗ (U‑HSM).

База данных DFK DB генерируется самой компанией Microsemi для конкретного UUID пользовательского АМЗ (U‑HSM). Все значения DFK в сгенерированной БД зашифрованы на специфичном для микросхемы типе ключей квитанции (ticket) для DFK DB. Ключи квитанции DFK DB защищены на открытом ключе (public key) пользовательского АМЗ (U‑HSM), импортированном в заводской АМЗ (Manufacturing HSM) компании Microsemi на предыдущих шагах. Эта схема открывает пользовательскому АМЗ (U‑HSM) доступ к значениям DFK в полученной базе данных.

Для того чтобы работать с базой данных DFK DB на стороне заводского АМЗ (M‑HSM), пользователь экспортирует ключи DFK DB ticket keys и отправляет затем на сервер Microsemi Manufacturing server для перепаковки на открытом ключе (public key) заводского АМЗ (M‑HSM). Перепакованные ключи квитанции импортируются пользователем обратно в базу данных DFK DB. Если база данных DFK DB имеет ключи квитанции, зашифрованные на открытом ключе (public key) заводского АМЗ (M‑HSM), их невозможно использовать заводским АМЗ (M‑HSM).

Работа с задачами

Все приватные данные и ключевой материал, используемые утилитой Job Manager в процессе генерации образа для программирования микросхемы (bitstream) и подготовки задачи (job), защищены на мастер-ключе квитанции Ticket Master Key. Это симметричный ключ шифрования (encryption key), зашифрованный на мастер-ключе заводского АМЗ (U‑HSM Master Key).

Когда АМЗ (HSM) экспортирует задачу (job), все квитанции задач Job Tickets перепаковываются на открытом ключе (public key) целевого заводского АМЗ (M‑HSM). Это предоставляет заводскому АМЗ (M‑HSM) доступ ко всем данным задачи программирования (job data), защищенным на мастер-ключах квитанции задачи Job Ticket.

Другие типы обмена данными между пользовательским АМЗ (U‑HSM) и заводским АМЗ (M‑HSM), такие как протокол запроса/ответа задачи (Job Request/Reply protocol) или отправка сертификаторов завершения задачи из заводского АМЗ (M‑HSM) для квалифицированной проверки в пользовательском АМЗ (U‑HSM), также применяют открытый ключ (public key) модуля АМЗ (HSM) на другом конце канала обмена данными для защиты приватной информации.

 

Заключение

Технология SPPS позволяет с помощью аппаратных модулей защиты (HSM) в полевых условиях доверенным образом обновлять критичное ПО (firmware) для микроконтроллеров и конфигурацию ПЛИС. Кроме того, технология SPPS разрешает ограничить количество микросхем, запрограммированных одной и той же модификацией прошивки (firmware), предварительно заданным значением. Таким образом, с помощью технологии SPPS можно решить задачу защиты устройств от несанкционированного производства (клонирования) в заводских условиях.

В статье описаны протоколы и аппаратное обеспечение, предназначенные для реализации технологии SPPS. Подробно изложены вопросы развертывания заводского АМЗ (M‑HSM) и пользовательского АМЗ (U‑HSM), а также ключевая система и вопросы администрирования.

В следующей статье будет описана утилита Job Manager, позволяющая создавать защищенные образы для доверенного программирования микросхем в недоверенном окружении

Литература
  1. Secure Production Programming Solution (SPPS) For Libero SoC v11.8 SP1 User Guide.
  2. Programming Job Manager User Guide v11.8
  3. FlashPro Express for Libero SoC v11.8 User’s Guide. 
  4. Libero SoC for Enhanced Constraint Flow v11.8 SP1 release User’s Guide. 
  5. Manufacturer HSM Installation and Setup User Guide v11.8. 
  6. User HSM Installation and Setup User Guide v11.8
  7. UG0443: SmartFusion2 and IGLOO2 FPGA Security Best Practices User Guide. 
  8. nShield Edge Solo User Guide (высылается Thales по клиентскому запросу).
  9. nShield Security Policy. MiniHSM, MiniHSM for nShield Edge and MiniHSM for Timestamp Master Clock in FIPS 140-2 level 3 mode. 
  10. nShield Security Policy. MiniHSM, MiniHSM for nShield Edge and MiniHSM for Timestamp Master Clock in FIPS 140-2 level 2 mode
  11. Non-proprietary Security Policy FIPS 140-2 level 3 nShield SOLO XC F3 & nShield SOLO XC F3 for nShield Connect XC. 
  12. Самоделов  А. Создание защищенных пользовательских приложений на базе SmartFusion2 SoC FPGA компании Microsemi. Части 1–6 // Компоненты и технологии. 2017. № 8–12. 2018. № 1.
  13. Самоделов  А. Создание защищенных пользовательских приложений на базе SmartFusion2 SoC FPGA компании Microsemi. Часть 7. Доверенное программирование микросхем в недоверенном окружении. Общие положения // Компоненты и технологии. 2018. № 2.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *