помимо DER закодированного сертификата там есть еще поля, если вы их уберете - как раз и получите сертификат

Ок, спасибо, буду пробовать!

snussi пишет:

3F00/0000/0000/0002/1003/4001 - 1308 байт

вот это сертификат
то, что расположено в этом файле соответствует структуре функции CryptSetKeyParam (… KP_CERTIFICATE …)

Гм, тогда немного странно. В описании функции сказано:

KP_CERTIFICATE - pbData is the address of a buffer that contains the X.509 certificate that has been encoded by using Distinguished Encoding Rules (DER). The public key in the certificate must match the corresponding signature or exchange key.

т.е., проще говоря, файл содержит сертификат x509 в DER-формате.
При этом, OpenSSL его не воспринимает:

> openssl x509 -text -noout -inform DER -in ./3F00_0000_0000_0002_1003_4001
unable to load certificate
2009290776:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1199:
2009290776:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:374:Type=X509

На форумах пишут, что "This error is due to an invalid certificate format installed".

Я также попробовал

> openssl asn1parse -in ./3F00_0000_0000_0002_1003_4001 -inform DER
    0:d=0  hl=2 l= 116 prim: appl [ 3 ]        
  118:d=0  hl=2 l=  32 cons: appl [ 22 ]       
Error in encoding
2010339352:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147:

что не сильно совпадает с DER-структурой. Возможно ли, что OpenSSL и CryptoAPI используют разные DER-форматы?

3F00/0000/0000/0002/1003/4001 - 1308 байт

вот это сертификат
то, что расположено в этом файле соответствует структуре функции CryptSetKeyParam (… KP_CERTIFICATE …)

Ок, понятно, спасибо!

Попробую объяснить.
С картой я "общаюсь" при помощи opensc-explorer.
В папке 3F00/0000/0000/0001/8001/8001 присутствуют файлы (X - порядковый номер сертификата):
020X - 134 байта
220X - 282 байта
030X - 1432 байта
FFFE - с ним уже все выяснили.
По моим ощущениям, в одном из первых трех должен содержаться сертификат или публичный ключ.
В файлах 030X содержатся куски наших OU.
Я попробовал прогнать все три через OpenSSL:

openssl x509 -text -noout -inform DER -in ./3F00_0000_0000_0001_8001_8001_0200 
unable to load certificate
2001803288:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1199:
2001803288:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:374:Type=X509

openssl x509 -text -noout -inform DER -in ./3F00_0000_0000_0001_8001_8001_2200 
unable to load certificate
2004080664:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1199:
2004080664:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:374:Type=X509

openssl x509 -text -noout -inform DER -in ./3F00_0000_0000_0001_8001_8001_0300 
unable to load certificate
1998739480:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:157:

Есть еще два "подозрительных файла":
3F00/0000/0000/0002/1001/C001 - 282 байта
3F00/0000/0000/0002/1003/4001 - 1308 байт
Тоже не парсятся.
Ну и есть два файла, не читающихся без пин-кода, но туда я пока не лезу.

А можно ли хотя бы утверждать, что файл FFFE - это аналог 5031 в PKCS-15?

Если мы все правильно понимаем, то это разное
5031 в pkcs15 - это Object Directory File, то есть - это мапфайл, в котором перечислены пути к мапфайлам конкретных типов объектов. Такой ODF один на весь pkcs15

А в родной ФС Рутокен S много файлов FFFE
Каждый из них - это почти мапфайл для конкретного типа объектов (лежит в соответствующей этому типу объектов папке и перечисляет id этих объектов - относительные пути)

Если проводить аналогии, то FFFE - это приблизительно то же самое, что и файлы, указатели на которые лежат в 5031 в pkcs15 с некоторыми оговорками:
1) насчет пути - в FFFE путь относительный, в тех файлах, на которые указывает 5031 - абсолютные;
2) в файлах, на которые указывает 5031, могут лежать не только пути до всех объектов какого-то типа, но и некоторые атрибуты этих объектов (например, CKA_LABEL для CKO_DATA),
а в FFFE лежат вроде только id EF-файлов соответствующего типа, а уже в этих EF-файлах - атрибуты

так, увы, не понятно.
покажите что именно вы качаете с карты (Лучше командами)

А описание этой файловой структуры где-то существует, или является закрытой информацией?

это тоже закрытая информация

snussi пишет:

PKCS-15 - это, грубо говоря, файловая система. И, как я понимаю, на рутокене (здесь и далее речь про S), отформатированном под Windows, находится какая-то другая. Не подскажете - какая?

Тоже PKCS#15, но немного отличающаяся от той, которая принята в OpenSC

А описание этой файловой структуры где-то существует, или является закрытой информацией?

PKCS-15 - это, грубо говоря, файловая система. И, как я понимаю, на рутокене (здесь и далее речь про S), отформатированном под Windows, находится какая-то другая. Не подскажете - какая?

Тоже PKCS#15, но немного отличающаяся от той, которая принята в OpenSC

Да.

К сожалению, нет. Код библиотек мы не раскрываем.

Вы можете не выдирать ключ, а экспортировать его в P12 формат из токена (Рутокен S под Windows это поддерживает, если при генерации не стояла галка - неэкспортируемый). Либо сразу можно выписывать в P12.
Потом P12 контейнер, вы с помощью openssl можете разделить на ключи и сертификат и импортировать их через pkcs11-tool или pkcs15-tool

Прошу прощения за глупые вопросы, но не могли бы вы помочь мне кое-в чем разобраться (сразу оговорюсь, что я начинающий "криптограф"):
1. PKCS-15 - это, грубо говоря, файловая система. И, как я понимаю, на рутокене (здесь и далее речь про S), отформатированном под Windows, находится какая-то другая. Не подскажете - какая?
2. Я отформатировал токен под PKCS-15 (как указано в wiki OpenSC, здесь и далее речь про 0.11), он оказался виден под Windows, я записал туда сертификаты (через Rutoken Control panel, Windows), и теперь pkcs11-tool видит токен без ошибок, но не видит на нем объекты (в Windows токен работает). Это означает, что на токене существует теперь две параллельных файловых системы? Или Windows, грубо говоря, размещает "файлы" в других "директориях"?
3. Можно ли как-то посмотреть на код библиотеки rtPKCS11.dll - возможно, мне удастся пересобрать ее под Windows.
4. Через opensc-explorer я вижу файлы в файловой системе на токене, отформатированном под Windows, могу перемещаться по папкам, проходит verify команда с указанием ПИН и прочее. Существует ли описание файловой структуры на токене? Возможно, я буду просто "выдирать" из него ключ, хоть это и небезопасно...

Спасибо за помощь!

Да, потребуется взять очень старый OpenSC, версии 0.11.13 и попробовать увидеть ключи записанные через Windows. И там просто точно не будет.

Ок, понятно, спасибо, попробую прогрызть. OpenSC 0.11.13 уже скомпилирован, карту видит и даже что-то с нее читает... Если что-то получится - отпишусь здесь, вдруг кому-то пригодится...
Если вдруг у Вас есть идеи - в какую сторону копать от OpenSC - буду, разумеется, признателен.

К сожалению, у нас уже много закупленных РутокенS...

Но если у вас на Байкалах пока ограниченный набор рабочих мест - может лучше сразу рассмотреть вопрос постепенного апгрейда токенов? Модель Рутокен ЭЦП PKI вам полностью подойдет под ваши задачи, а по цене она не сильно отличается от Рутокен S.