Токены PKCS#11: генерация ключевой пары и неизвлекаемость приватного ключа (Продолжение)

[@L11R]

А ключи Yubikey не поддерживают же PKCS#11?
У меня есть Yubikey 4, но похоже для госуслуг и других российских сервисов он бесполезен :(

[@saipr]

Ключ Yubikey — это генератор одноразовых паролей. Он не поддерживает PKCS#11, а тем более российскую криптографию.

[@L11R]

То что он не поддерживает российскую криптографию это очевидно. Я предполагал, что в центрах сертификации могут выдать RSA-подпись. Но Yubikey 4 это не просто генератор одноразовых паролей. Тут и OpenPGP (как смарткарта) и хранилище по американскому стандарту PIV (PKCS#11 вроде как раз)

Информация с сайта Yubico

The YubiKey 4 and YubiKey NEO support the Personal Identity Verification (PIV) interface specified in NIST SP 800-73 document «Cryptographic Algorithms and Key Sizes for PIV». This enables you to perform RSA or ECC sign/decrypt operations using a private key stored on the smartcard, through common interfaces like PKCS#11.

Поэтому я и подумал, что можно получить RSA-сертификат вместо ГОСТ. Ну или даже ECC.

[@saipr]

Ну наши центры сертификации (УЦ) не выдают сертификаты на RSA-ключах, на ECC-тоже. Где-нибудь на VeriSign, COMODO можно получить, если есть интерфейс PKCS#11, с помощью Firefox. Что касается OpenPgp можно посмотреть GnuPg-2, Kleopatra, KMail и российская криптография

[@herrjemand]

Yubico уже давно не выпускает чисто OTP токены. Все Yubikey сегодня это мультифакторные аутентификационные устройства с поддержкоц PKCS#11 в том числе https://developers.yubico.com/PIV/Guides/SSH_with_PIV_and_PKCS11.html

[@saipr]

Это здорово, что все в одном флаконе. Но, к сожалению без ГОСТ-ов. А если упоминать SSH, то следует упоминуть поддержку ГОСТ-ов в openssh/putty.

[@herrjemand]

Характеристики https://www.yubico.com/products/yubikey-hardware/

[@saipr]

Спасибо. Их там целый зоопарк, начиная от одноразовых паролей OATH до поддержки ECC p256. Кстати поддержка ECC p256 в принципе позволяет положить на yubikey-hardware поддержку ГОСТ Р 34.10-2012 с длиной ключа 256 бит. Мы уже так делали с китайцами, только здесь никому не надо.

[@saipr]

У меня есть Yubikey 4, но похоже для госуслуг и других российских сервисов он бесполезен :(

Да, именно так сегодня!

[@worldmind]

Где-то когда-то слышал про токены с которых в принципе считать закрытый ключ нельзя т.е. у них нет программного доступа в закрытому ключу (есть только апи для подписи), а при попытке аппаратно вскрыть токен ключ неминуемо разрушается.
Может подскажете бывает/не бывает, а если бывает, то как называется и как выдают такие ключи, ведь получается что изготовитель может иметь копию? в идеале надо печатать такой токен на личном 3d принтере, но видимо технологии ещё не дозрели.

[@L11R]

Если не ошибаюсь, большинство смарткарт и токенов именно так и работает.
Лично у меня Yubikey 4. Тут говорят, что приватный ключ не покидает устройство. Во всяком случае c OpenPGP точно. Насчет PKCS#11 не уверен, но скорее всего тоже не покидает.

И не понял про копию. Вы же сами генерируете пару уже у себя дома. Как производитель может сделать эту копию ещё до создания пары ключей (public/private)?

[@saipr]

Да, именно так и работает. Наружу передается не ключ, а его Handle (указатель на ключ).
И именно этот handle используется в операциях с закрытым ключом, например, формиршвание подписи. Копию, конечно, до создания ключевой пары даже теоретически нелься. Хотя, как известно, есть вероятность, что обезьяна напишет «Войну и мир».

[@robux]

Если к закрытому ключу есть доступ, то смысл в железке вобще отпадает.
Железка должна внутри себя генерять ключевую пару, хранить закрытый ключ, а юзеру предоставлять API для показа открытого ключа, короткого шифрования (обычно симетричного ключа) и ЭЦП (т.е. тоже короткого шифрования, но хэша данных).

[@saipr]

Именно внутри себя настоящий токен/смарткарта и генерят ключевую пару. Юзер может, естественно, получить открытый ключ (хотя бы для того, чтобы положить его в сертификат). Что касается ЭЦП. Короткое шифрование, т.е. шифрование хэша — это свойство RSA. ЭЦП по ГОСТ тоже берется от хэша (ГОСТ Р 34.11-94/2012), но это не совсем шифрование. ЭЦП по ГОСТ естественно делается на закрытом ключе. Значение ключа юзер не получает, а получает указатель на него (HANDLE),. Именно этот указатель и передается в API. И подпись формируется, естественно, внутри токена/смарткарты. Наружу попадает только значение подписи (512 или 1024 бита).
Поэтому, если доступ к ключу — это получение HANDLE, то именно железка и обеспечивает неизвлекаемость. Но если железка дает (как это может быть написано в статье), то смысл в железке все же есть, но не глобальный.

[@lumag]

Еще в список:

• id-tc26-gost-3410-2012-256- paramSetA
• id-tc26-gost-3410-2012-512-paramSetC

[@saipr]

Да, документе они есть, но для

эквивалентного представления в форме скрученных кривых Эдвардса

Это немного отдельная песня и я бы сейчас на этом не зацикливался!

[@V2008]

Включены, смотрите здесь.

[@mihmig]

Можно спросить — какие конкретно модели USB-токенов обладают функцией неизвлекаемости ключа?

[@saipr]

У каждого токена может быть своя политика выставления флагов:

CKA_SENSITIVE=CK_TRUE, а атрибута CKA_EXTRACTABLE=CK_FALSE

Из тех, что на слуху, это RuToken ECP (РуТокен ЭЦП) — ключ не извлекаемый!!! Хотя на него можно импортировать закрытый ключ, например, из PKCS#12.
Установив флаги CKA_SENSITIVE=CK_TRUE && CKA_EXTRACTABLE=CK_FALSE
можно сделать неизвлекаемым ключ даже программно-аппаратных токенах на USB-флэшках.

[@mihmig]

Что-то я не пойму — как можно сделать неизвлекаемый ключ на базе обычной флешки? Что помешает мне её скопировать в месте с меткой тома на флешку из той же партии (на том же контроллере)?

[@saipr]

Первое, все объекты токена хранятся на флэшке зашифрованные на PIN-е.
Создаваемый токен жестко привязан к флэшке (в частности, к ее серийному номеру) и «партия» не прокатит. Неизвлекаемость нафлэшке подразумевает (впрочем, так же и классическом токене) невозможность экспортировать значение закрытьго ключа (CKA_SENSITIVE=CK_TRUE && CKA_EXTRACTABLE=CK_FALSE).
Да, здесь криптографические операции, например, подпись, выполняются не в отдельном устройстве (аппаратном токене), а на компьютере (библиотеке), к которому подключена флэшка. И это, естественно, отличает аппаратный токен от программно-аппаратного токена.

[@mihmig]

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

[@saipr]

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

[@mihmig]

Эмм, а где эти «флаги» выставлять?
Могули я, имея рутокен, поместить на него существующие ключи указав, что они неизвлекаемые? В стандартном интерфейсе рутокеновских утилит…

[@saipr]

Можете. У вас ключи хранятся вместе с сертификатом в PKCS#12?
Если это так, то для импорта можно воспользоваться Redfox или FoxXCA.
В РуТокен ЭЦП флаги устанавливаются по умолчанию и ключ становится неизвлекаемым.

Эмм, а где эти «флаги» выставлять?

В программе, которую вы можете написать сами в соответствии с PKCS#11 v.2.30, например:
priv_atts <<
pk11_attr_bool(CKA_TOKEN, true) <<
pk11_attr_bool(CKA_PRIVATE, true) <<
pk11_attr_data(CKA_LABEL, getIntName().toUtf8()) <<
new_id <<
pk11_attr_bool(CKA_SENSITIVE, true) <<
pk11_attr_bool(CKA_DECRYPT, true) <<
pk11_attr_bool(CKA_SIGN, true) <<
pk11_attr_bool(CKA_UNWRAP, true)<<
pk11_attr_bool(CKA_EXTRACTABLE, false);

[@saipr]

GUI для утилиты P11Conf: