Как расшифровать экспортированные ключи, обернутые safeNet?

Я экспортировал ключ 3DES из SafeNet HSM в файл с помощью инструмента под названием KMU. Этот инструмент оборачивает ключ перед извлечением с помощью другого ключа 3DES. У меня есть доступ к текстовому значению второго ключа.

Вопрос в том, как я могу расшифровать обернутый файл, чтобы получить текстовое значение обернутого ключа?

Обновление:

К вашему сведению: окончательный экспортированный файл выглядит так:

L1: 000001f4 000001a800000001000001a0
L2: 00000020 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
L3: 00000140 0000001b0000010300000001010100000162000000010101800001290000000101010000016500000001010000000164000000010100000000010000000101010000000200000001010100000170000000010101000000030000000f014949494949494949494949494949490000010c000000010101000001040000000101010000010a000000010101000001060000000101010000010500000001010100000108000000010101000001070000000101018000012b000000010100000001610000000401000000100000000000000004010000000400000100000000040100000014800001030000000000000001020000000000000001100000000000000001110000000000800001280000000101000000016300000001010080000102000000100132303131313232383136323032313030000000000000000000000000
L4: 00000010 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
L5: 00000020 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxx
L6: 00000020 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
L7: 00000020 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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


pkcs#11 hsm safenet
person Ebrahim Ghasemi    schedule 23.08.2020    source источник
comment
Если вы можете экспортировать ключ с помощью инструмента, вы можете расшифровать (развернуть) экспортированный ключ с помощью инструмента (при условии, что он его поддерживает). Проверьте, есть ли у инструмента возможность использовать unwrap ключ. Если это не так, вам нужно написать код для выполнения операции разворачивания.   -  person always_a_rookie    schedule 24.08.2020
comment
Ручное развертывание, как описано в моем ответе, не требуется, если все, что вам нужно сделать, это импортировать ключи в HSM. Вы можете импортировать свой второй ключ с помощью клавиши Enter из функциональных возможностей компонентов (если у вас есть значение в виде обычного текста, используйте 2 компонента и введите нули для второго компонента), а затем используйте этот ключ для импорта ключей.   -  person vlp    schedule 25.08.2020

Ответы (1)


arrow_upward
2
arrow_downward

См. Главу Руководство по функциям резервного копирования ключей в документе Справочник пользователя утилиты управления ключами (KMU) для полного описания схемы.

К сожалению, этот документ не был обновлен до последней версии схемы, которая использует AES tK и HMAC для M_mK.

Насколько я помню, можно указать KMU использовать старую схему DES3 с параметром командной строки -3.

У меня есть работающая реализация, но, к сожалению, я не могу предоставить код.

Сводка основных этапов восстановления:

  • Проверить общую структуру файла (magic 0x000001f4 | полезная нагрузка в кодировке varLen | 4-байтовый MAC | ключ MAC в оболочке varLen | транспортный ключ в оболочке varLen)

  • разворачивать транспортный ключ AES (используя ключ переноса и алгоритм, зависящий от типа ключа, например CKM_RSA_PKCS)

  • развернуть общий секретный MAC-ключ (используя транспортный ключ AES и CKM_AES_ECB. Длина 32)

  • проверить MAC закодированной полезной нагрузки (используя ключ MAC с CKM_SHA512_HMAC_GENERAL)

  • развернуть все резервные копии ключей из полезной нагрузки (используя транспортный ключ AES с CKM_WRAPKEY_AES_CBC и нулевым IV)

Вы можете использовать библиотеку регистратора PKCS # 11 (см. Руководство по программированию PTK-C) и записывать активность утилиты KMU во время восстановления ключа, чтобы проверить мелкие детали алгоритм.

Удачи с вашим проектом!

РЕДАКТИРОВАТЬ ›Общая структура файла (с учетом данных вашего примера):

000001f4 // Magic
000001a8 // Length of encoded payload
    00000001 // Number of keys
    000001a0 // Wrapped key #1 length
        xxxx...xxxx // Wrapped key #1 data for CKM_WRAPKEY_AES_CBC
xxxxxxxx // Payload MAC
00000020 // Wrapped MAC key cryptogram length
    xxxx...xxxx // Wrapped MAC key cryptogram
00000020 // Wrapped transport key cryptogram length
    xxxx...xxxx // // Wrapped transport key cryptogram

См. CKM_A_WRAP_Noreferrer. a href = "https://thalesdocs.com/gphsm/ptk/5.9/docs/Content/PTK-C_Program/PTK-C_Mechs/CKM_WRAPKEY_DES3_CBC.htm" rel = "nofollow noreferrer"> используется для формата CKM_DESRAPK для CKM_DESRAPK кодировать отдельные экспортируемые ключевые данные (# 1 .. # n) внутри закодированной полезной нагрузки.

person vlp    schedule 24.08.2020
comment
Большое спасибо дорогой vlp. Я обновил вопрос, добавив цензуру экспортированного файла. Кажется, что в моем файле гораздо больше разделов, чем структура, о которой вы упомянули в своем ответе. Я что-то упустил? Более того, как исходный ключ, так и ключ упаковки в моем случае являются ключами 3DES. Использует ли инструмент KMU еще один ключ типа AES в процессе резервного копирования? Почему он должен записывать Транспортный ключ в файл? - person Ebrahim Ghasemi; 24.08.2020
comment
@Abraham Прочтите раздел Краткое описание функции резервного копирования ключей (и обратите внимание, что несколько лет назад он переключился с DES3 на AES + HMAC - на случай, если ваша документация устарела или Thales еще не обновил ее). Использование случайного транспортного ключа - обычная практика. Ваши экспортированные ключи обертываются с использованием этого случайного транспортного ключа AES, который прикреплен к файлу под вашим настоящим экспортным ключом (который в вашем случае является 3DES). - person vlp; 25.08.2020
comment
@Abraham Документ KMU является общедоступным, поэтому я добавил ссылку на него < / а>. Они не исправили разницу между DES3 и AES + HMAC. Я обновлю ответ соответственно ... - person vlp; 25.08.2020
comment
Еще раз спасибо дорогой vlp. Мой упакованный экспортный файл имеет возраст +7 лет. (Точнее файл от 2013 года!). Вы знаете, в каком году Thales заменяет 3DES на AES + HMAC? - person Ebrahim Ghasemi; 25.08.2020
comment
И, пожалуйста, еще раз взгляните на представление файла, которое я добавил к вопросу. Похоже, есть небольшое несоответствие между структурой моего файла и структурой, которую вы упомянули в своем ответе. Последняя часть L5, а также все L6 и L7 в моей файловой структуре находятся вне структуры, которую вы предоставили. (Однако все остальные разделы и поля размеров верны). Вы хоть представляете, что это за байты? - person Ebrahim Ghasemi; 25.08.2020
comment
Уважаемый @Abraham, держу пари, что L1-L5 содержат magic + payload + mac (mac - последняя часть L5). Я полагаю, вы неправильно интерпретируете L1-L5 как отдельные блоки, но на самом деле это блоки внутри блока полезной нагрузки, который начинается в L1 и имеет длину 0x1a0 (424 байта). Обратите внимание на отступ в моем ответе - закодированная полезная нагрузка (424 байта) содержит количество ключей (4 байта), длину первых ключевых данных (4 байта) и первых ключевых данных (416 байтов). См. Связанное описание CKM_WRAPKEY_DES3_CBC. Если ваша магия совпадает с моей, следует использовать AES + HMAC. - person vlp; 25.08.2020
comment
Позвольте нам продолжить это обсуждение в чате. - person Ebrahim Ghasemi; 25.08.2020