| ||||
| ||||
| Добрый день! Есть пара вопросов: 1. Существует ли описание формата блоба (blob) секретного ключа КриптоПро (PRIVATEKEYBLOB)? Если да - где можно посмотреть? 2. Можно ли экспортировать/импортировать секретные ключи КриптоПро в PFX-файлы (PKCS#12)? Заранее спасибо. | ||||
| Ответы: | ||||
| ||||
| 1. (информация из файла csp*.chm. Файл есть в дистрибутиве CSP и на сайте: для CSP 2.0 http://www.cryptopro.ru/CryptoPro/products/csp/20/csp-2-0.chm для CSP 3.0 http://www.cryptopro.ru/CryptoPro/products/csp/30/CSP-3-0.chm ) Описание структуры CRYPT_PRIVATEKEYBLOB Псевдоструктура CRYPT_PRIVATEKEYBLOB. Описывает ключевой блоб типа PRIVATEKEYBLOB для ключей "КриптоПро CSP". Все поля этой псевдоструктуры выравнены по границе байта и находятся в сетевом порядке байт (ASN1 DER). struct CRYPT_PRIVATEKEYBLOB { CRYPT_PUBKEY_INFO_HEADER tPublicKeyParam; BYTE bExportedKeys [1]; }; Описание данных, членов структуры tPublicKeyParam Общий заголовок ключевого блоба типа PRIVATEKEYBLOB "КриптоПро CSP". 2. Нет, экспорт ключей в pfx невозможен. Аргумент - ключи недостаточно надёжно хранить в файле, защищенном только паролем. | ||||
| ||||
| Спасибо за ответы. По первому вопросу меня интересует именно bExportedKeys, который нигде не описан и имеет следующий вид: 0 30 96: SEQUENCE { 2 30 88: SEQUENCE { 4 04 8: OCTET STRING : 28 F0 E4 D4 22 D5 DD 60 14 30 40: SEQUENCE { 16 04 32: OCTET STRING : 11 E6 7C 2A 8A C9 A6 EA 05 1B 9A 82 80 A0 12 A2 : 48 DC 30 6E 23 CF 14 44 8D 88 1C 35 CC CC DA 82 50 04 4: OCTET STRING : 75 AA A9 AF : } 56 A0 34: [0] { 58 03 2: BIT STRING 7 unused bits : '1'B (bit 0) 62 A0 28: [0] { 64 06 6: OBJECT IDENTIFIER '1 2 643 2 2 19' 72 30 18: SEQUENCE { 74 06 7: OBJECT IDENTIFIER '1 2 643 2 2 35 1' 83 06 7: OBJECT IDENTIFIER '1 2 643 2 2 30 1' : } : } : } : } 92 04 4: OCTET STRING : 52 20 E6 48 : } | ||||
| ||||
| Посмотрите ещё файл http://www.cryptopro.ru/pub/csp-3-0/3293/sdk/include/WinCryptEx.h Там есть комментарий к описанию структуры CRYPT_PRIVATEKEYBLOB_ А вообще, может быть, если Вы сформулируете постановку задачи более подробно, мы сможем более детально Вам ответить... | ||||
| ||||
| Задача следующая: парный секретный ключ, сформированный КриптоПро CSP необходимо поместить в ключевой контейнер Signal-COM CSP и наоборот. | ||||
| ||||
| > Задача следующая: парный секретный ключ, сформированный > КриптоПро CSP необходимо поместить в ключевой контейнер > Signal-COM CSP и наоборот. Хм. И что это будет означать? Есть одно сертифицированное "СКЗИ КриптоПро CSP 3.0", есть другое сертифицированное "СКЗИ Крипто-КОМ 3.1". Где в документации "СКЗИ Крипто-КОМ 3.1" сказано, что оно может использовать закрытые ключи от "СКЗИ КриптоПро CSP 3.0"? Да и, по сути, наверняка применяемые меры защиты ключей, ограничения на них и прочая, прочая... в этих СКЗИ разные, поэтому даже гарантировать функционирование на 100% проблематично. | ||||
| ||||
| Речь идет не о СКЗИ, а ключе ЭЦП, который у Вас и у Сигнал-КОМ соответствуют ГОСТ-у. Именно поэтому рассматривался вариант с экспортом/импортом секретного ключа с последующей (автоматической) привязкой к СКЗИ соответствуюшего криптопровайдера. | ||||
| ||||
| Во-первых, такой подход несколько противоречит действующему законодательству РФ. Во-вторых, с технической точки зрения для реализации этого подхода требуется между двумя сертифицированными СКЗИ (или сертифицированными средствами ЭЦП) согласовать и разрешить целый ряд проблем безопасности. Например, при операции подписи существенно используется случайное число k, которое должны быть гарантировано непредсказуемо, секретно и уничтожаться сразу после операции подписи. В случае, если при любой операции подписи оно становится известным нарушителю, то он сможет тривиально восстановить закрытый ключ ЭЦП. Лично мне неизвестно, где и как "СКЗИ Крипто-КОМ 3.1" хранит данные для получения этого числа (состояние своего криптографического ДСЧ) и как их защищает. | ||||
| ||||
| Уважаемый Сергей. У вас спрашивают ответ на простой вопрос. 1. Информации по структуре вашего контейнера в свободном доступе нет, что составляет большую трудность преобразовать ваш контейнер в некую другую форму, например для использования в CSP другого производителя. 2. PKCS#12 транспортные контейнеры ни вы ни Сигнал-ком не поддерживаете. Соответственно и обеспечить взаимообмен на сегодня простыми способами невозможно. Из того что вы ответили: 1. Действующее законодательство и использование транспортного контейнера ни как не связано. Более того ФЗ Об ЭЦП предполагает режим, где ключи готовит сам УЦ и как следствие их потом надо доставить на рабочее место через какой то транспорт. 2. Требования к ключевому материалу определены в ГОСТ. Требования к ДСЧ и у вас и у Сигнал-КОМ проверены при сертификации в ФСБ обоих изделий. | ||||
| ||||
| Сергей доброго дня, > Информации по структуре вашего контейнера в свободном доступе нет Да такой информации в документации нет, но мы её сообщаем нашим партнёрам, а так же оповещаем их, что использование ключевых носителей в тех или иных программных комплексах – является документированным использованием СКЗИ и требует тщательного исследования (а в ряде случаев, подпадающих под действие ПКЗ-2005, сертификации ПКЗИ). > PKCS#12 транспортные контейнеры ни вы ни Сигнал-ком не поддерживаете. Хм. PKCS#12 это только слово такое, без реального наполнения. Ну, предположим, что сделаем мы его, но и у нас и у них, будут несовместимые расширения. > 1. Действующее законодательство и использование транспортного контейнера > ни как не связано. Более того ФЗ Об ЭЦП предполагает режим, где ключи > готовит сам УЦ и как следствие их потом надо доставить на рабочее > место через какой то транспорт А так же, например, требует указать какие СКЗИ (средства ЭЦП) будут с этим ключом использоваться, т.е. явно указано, ключ должен быть предназначен для этих СКЗИ (средства ЭЦП). > Требования к ДСЧ и у вас и у Сигнал-КОМ проверены > при сертификации в ФСБ обоих изделий. Для КС2 при условии использования ключевых носителей. В общем, у нас, архитектура такова, что не возможно откатить или предсказать случайные числа без ключевого носителя, на котором будет производиться операция ЭЦП. | ||||
| ||||
| Извините, Следует читать: "...использование ключевых носителей в тех или иных программных комплексах – не является документированным использованием СКЗИ и требует тщательного исследования (а в ряде случаев, подпадающих под действие ПКЗ-2005, сертификации ПКЗИ)..." | ||||
| ||||
| >Да такой информации в документации нет, но мы её >сообщаем нашим партнёрам, а так же оповещаем их, что >использование ключевых носителей в тех или иных >программных комплексах – является НЕ документированным >использованием СКЗИ и требует тщательного исследования >(а в ряде случаев, подпадающих под действие ПКЗ-2005, >сертификации ПКЗИ). 1. Я не вижу оснований для «не документированности», поскольку планируется использовать сертифицированные по единым требованиям, одного стандарта (ГОСТ) и одного класса КС1 (КС2) СКЗИ. 2. Что исследовать? Случайное число (закрытый ключ) созданный сертифицированными средствами перемещается в другое сертифицированное средство тогоже класса. Это почти тоже самое если запросить у соответствующей структуры ФСБ блок «гарантированно» случайных чисел. 3. Под ПКЗ в обязательном порядке подпадает ВСЕ сертифицированное. >Хм. PKCS#12 это только слово такое, без реального >наполнения. Ну, предположим, что сделаем мы его, но и у >нас и у них, будут несовместимые расширения. Свести П12 много проще (было бы желание или коммерческий интерес) чем согласовать контейнеры разных производителей. Поскольку П12 опирается на стандартные примитивы из драфтов по ГОСТ, например, мы эту процедуру с Лисси выполнили еще в начале того года, провели испытания и выпустили соответствующий пресс-релиз. >А так же, например, требует указать какие СКЗИ >(средства ЭЦП) будут с этим ключом использоваться, т.е. >явно указано, ключ должен быть предназначен для этих >СКЗИ (средства ЭЦП). Очень просто, например, указать перечень средств. Основанием может выступать проведение взаимного тестирования продуктов разных произодителей, например, как это мы сделали вместе с Сигнал-КОМ и Лисси. Сигнал-КОМ и техсредства УФО. Ваша компания тоже проводила такие работы с МО ПНИЭИ и у вас существует официальное заключение (это информация с вашего же форума). >Для КС2 при условии использования ключевых носителей. В >общем, у нас, архитектура такова, что не возможно >откатить или предсказать случайные числа без ключевого >носителя, на котором будет производиться операция ЭЦП Мне представляется, что сертифицированный способ получения закрытого ключа ни коем образом не связан с сертифицированной выработкой ЭЦП на этом ключе другими техническими средствами. | ||||
| ||||
| > Мне представляется, что сертифицированный способ получения закрытого ключа ни коем образом > не связан с сертифицированной выработкой ЭЦП на этом ключе другими техническими средствами. Сергей, ты немного кривишь душой, т.к. требования к состоянию ДСЧ и к закрытым ключам совпадают, в том числе и по генерации (т.к. они, очень грубо говоря, взаимозаменяемы и могут быть вычислены один из другого). Так же если один хранится на отделяемом ключевом носителе, то и другой должен храниться там же, и т.д. и т.п. | ||||
Тихонов Николай