Как вы реализуете лицензионный ключ платформы с TPM в Linux?

Question

Меня попросили реализовать, что составляет лицензионный ключ с использованием TPM для устройства x86_64 с микросхемой TPM. По сути, необходимо обеспечить, чтобы программное обеспечение, выпущенное для устройства, могло работать только на самом устройстве, чтобы при переносе программного обеспечения на виртуальную машину или другое оборудование оно отказывалось работать.

Я не ожидаю, что решение будет устойчивым к обратному проектированию, скорее это типичное решение типа «ключ», где оно будет мешать обычным пользователям и сохранять честность корпоративных клиентов.

Я успешно собрал и включил модули TPM, а также TrouSerS и код openssl-tpm-engine - я могу успешно стать владельцем TPM, но кроме этого доступная документация не дает вполне рассмотрим этот вариант использования - или, если это так, я до сих пор не смог найти простое решение на английском языке.

Я бы предпочел, если возможно, полагаться на секретную природу закрытых ключей, хранящихся в доверенном платформенном модуле, а не на использование хэшей компонентов платформы (жесткий диск может умереть, процессор может быть заменен и т. Д.) ошибка на стороне клиента, так что система не станет непригодной для использования после обычного обновления оборудования.

Кроме того, в идеале я подозреваю, что это решение может быть спроектировано таким образом, чтобы при изготовлении публичные ключи каждого устройства собирались и добавлялись в цепочку ключей для подписи, чтобы программное обеспечение могло быть подписано на один ключ, который могло хранить каждое устройство. в TPM, а не требовать, чтобы программное обеспечение было подписано несколько раз? Здесь я могу ошибаться, но должен существовать какой-то метод массового удовлетворения метода аутентификации на платформе, иначе его будет очень сложно масштабировать.

Answer 1

Если устройство настроено вами, вы можете воспользоваться следующей схемой:

A.Перед отправкой:

1. Стать владельцем - также создает корневой ключ хранилища (SRK)
2. Создать немигрируемый ключ подписи
3. Хранить завернутый ключ в надежном хранилище ключейна платформе
4. Сохраните открытый ключ созданного ключа где-нибудь в вашей БД / файловой системе / что-нибудь еще

B.Подготовка приложения:

1. Вы должны отправить открытый ключ вместе с двоичным файлом приложения
2. Я бы не стал компилировать открытый ключ в двоичный файл, вместо этого я бы предпочел использоватьчто-то вроде системы CA, где компилируется только открытый ключ корневого CA.Открытая часть ключа подписи доверенного платформенного модуля может быть отправлена ​​в виде файла сертификата.Это предотвращает компиляцию двоичного файла для каждого устройства в отдельности.

C.При запуске приложения:

1. Создать NONCE
2. Позвольте TPM подписать NONCE
3. Прочитать сертификат и проверить его
4. Извлечь общедоступныйключ из проверенного сертификата
5. Проверка подписи, возвращенной модулем TPM, с использованием полученного открытого ключа (и, конечно, проверка, равны ли подписанные данные NONCE)
6. Если подпись действительна => вы счастливы

Примечание 1: С теоретической точки зрения это решение небезопасно, так как двоичный файл может быть исправлен.Вы знаете, что это должно работать.

Примечание 2: Если устройство не настроено вами самостоятельно, вы не можете доверять открытому ключу, который клиент может дать вам.

---

Редактировать 1: объяснить некоторые моменты более точно

@A.2: Поскольку я использую jtt & jTSS вместоTrouSerS Я не знаю, есть ли инструмент командной строки, включенный в пакет TrouSerS для создания ключей.Но я точно знаю, что он предоставляет соответствующий API для этого.Во всяком случае, jtt, например, имеет команду create_key, которая делает это.Когда вы используете этот инструмент, у вас будет проблема с тем, что хранилище ключей jTSS и TrouSerS несовместимо с AFAIK.

@A.3: Нет, внутри TPM не хранятся ключи, кроме ключа хранилища(SRk) и Ключ подтверждения (EK).Но доверенный платформенный модуль гарантирует, что ни одна закрытая часть ключей, принадлежащих доверенному платформенному модулю, никогда не будет находиться за пределами доверенного платформенного модуля в незашифрованном формате.Таким образом, у вас есть хранилище ключей, которое каким-то образом управляется доверенным программным стеком (TSS -> jTSS, TrouSerS), который содержит материал ключей зашифрованный .TSS также отвечает за загрузку правильных ключей в TPM перед их использованием, например, для операции подписания.

@ C *: криптографическая часть на стороне приложения является вполне стандартной.Я не знаю, как ваши знания в этой области.Для части TPM снова TSS предоставляют высокоуровневые API.Я не знаю, существуют ли существующие инструменты командной строки для подписи с TPM.