PKCS # 11. Возможность выполнения шифрования / дешифрования в аппаратном обеспечении - PullRequest
Новая
       43

PKCS # 11. Возможность выполнения шифрования / дешифрования в аппаратном обеспечении

0 голосов
/ 14 ноября 2018

Приветствия. Это копия моего вопроса о обмене стеками шифрования.

Я имею дело с HSM через PKCS # 11 C / Python интерфейс. Мне интересно, возможно ли сделать некоторые C_Encrypt / C_Decrypt аппаратно. Говоря "в аппаратном обеспечении" , я имею в виду шифрование / дешифрование без предоставления результата пространству вызывающего. Это в основном полная расшифровка, так как я хочу вызвать C_Decrypt и оставить результат внутри HSM в качестве произвольных данных, чтобы позже выполнить некоторые другие преобразования этих данных, сказав, что повторно зашифровал его на каком-то другом ключе. Заранее спасибо.

Ответы [ 2 ]

0 голосов
/ 15 ноября 2018

PKCS # 11 не предоставляет такие методы, но некоторые модели HSM позволяют расширять их встроенное программное обеспечение с помощью собственных алгоритмов / механизмов или даже запускать собственное приложение внутри устройства, так что, несомненно, есть способ достичь того, чего вы хотите.Только не с PKCS # 11 API.

Кстати, я обсуждал именно этот сценарий в список рассылки с комментариями pkcs11 из Технический комитет OASIS PKCS # 11 в 2013 году. К сожалению, я не получил никакой обратной связи ¯\_(ツ)_/¯, но позже, когда я захотел присоединиться к техническому комитету для работы над этим предложением, я получил прайс-лист с членскими взносами :D.

Моя почта от 2013 года:

Я хотел бы открыть дискуссию о безопасном перекодировании данных и способах его обработки с помощью API PKCS # 11.Допустим, есть некоторые данные, зашифрованные с помощью симметричного ключа A, и по какой-то причине (т. Е. Время жизни ключа истекло, алгоритм шифрования больше не считается безопасным и т. Д.), Необходимо повторно зашифровать данные ключом B.Какие опции предоставляет PKCS # 11 API?

ОПЦИЯ # 1: Расшифровывать данные с помощью функций A и C_DecryptInit/C_Decrypt/C_DecryptUpdate/C_DecryptFinal, а затем шифровать данные с помощью ключей B и C_EncryptInit/C_Encrypt/C_DecryptUpdate/C_DecryptFinalфункции.

Преимущества:

  • использует текущий хорошо известный API PKCS # 11

Недостатки:

  • возможные проблемы безопасности- открытый текст неоправданно подвергается памяти хоста
  • накладные расходы на связь - необходимо дважды обменяться открытым текстом между приложением cryptoki и модулем cryptoki

OPTION # 2: Let'sскажем, будут введены новые функции PKCS # 11 для повторного шифрования данных.Он должен принимать зашифрованный текст, созданный с помощью ключа A, в качестве входных данных и предоставлять зашифрованный текст, созданный с помощью ключа B, в качестве выходных данных.Другими словами, он должен расшифровать, а затем зашифровать данные за один вызов.Это может быть достигнуто, например, путем введения функции C_DecryptEncryptUpdate с поведением, аналогичным C_DecryptVerifyUpdate (скорее всего, у него будут аналогичные проблемы с конвейерной обработкой).

Преимущества:

  • Устраняет недостатки ОПЦИИ № 1:

    • дешифрованный открытый текст не нуждается в доступе к памяти хоста, поскольку возможна реализация, когда открытый текст никогда не покидает защищенное устройство.
    • производительность должна быть увеличена, посколькуМежду приложением cryptoki и модулем / устройством cryptoki необходимо обмениваться на 50% меньше данных

Недостатки:

  • Необходим новый (-ые) метод (-ы)представленный в PKCS # 11 API

Лично я определенно хотел бы видеть API для безопасного перешифрования даты.Каковы ваши мнения?Кто-нибудь еще пропускает API для безопасного повторного шифрования данных?

0 голосов
/ 14 ноября 2018

Нет, PKCS#11 не поддерживает то, что вам нужно.

Ближайшая операция по вашему требованию - C_UnwrapKey, которая используется для создания ключевого объекта внутри HSM с использованием расшифровки отправленных данных с использованием другого ключа. Но я не думаю, что это удовлетворит ваши потребности.

...