GlobalSign и Рутокен
Эпизод I.
Выпустили сертификат подписи кода от GlobalSign. У них есть официальная инструкция по выпуску и использованию: https://support.globalsign.com/code-sig … rutoken-30
Несколько удивил сам процесс и результат. В процессе задействовано приложение Fortify (https://github.com/PeculiarVentures/fortify/) и браузерная часть. Представитель GS прислал Рутокен ЭЦП 3.0 3220 для использования.
Инструкцию следует интерпретировать так, что если планируется использовать signtool, то во время процедуры нужно использовать драйверы 4.17.0.0 или новее. Кроссплатформенная утилита jsign (Windows/Linux), которую можно использовать вместо signtool, и у которой нет проблемы ввода PIN должна работать и при создании ключа с более ранними драйверами.
Первая попытка выпустить сертификат окончилось ошибкой. Генерация ключа RSA 4096 на Рутокен 3220 небыстрая операция и процесс окончился таймаутом...
Комментарий про скорость работы можно посмотреть по ссылке https://forum.rutoken.ru/post/24887/#p24887:
cy, да, Рутокен ЭЦП 3.0 3220, к сожалению, имеет отнюдь не лучшую скорость подписи RSA4096. По нашим внутренним измерениям одна операция подписи без накладных расходов на токенах этой модели занимает 6 секунд.
Быстрая подпись RSA4096 реализована в токенах Рутокен ЭЦП 3.0 3120 и Рутокен ЭЦП 3.0 3150: в них само выполнение команды подписи RSA4096 занимает около 250 мс. С учетом накладных расходов у меня с токеном Рутокен ЭЦП 3.0 3120 подпись 256 файлов четырьмя батчами по 64 файла занимает около 75 секунд (время может немного плавать), 8 батчей по 32 файла -- около 70 секунд.
Из самого GlobalSign ответили, что они не поддерживают EC-криптографию для CodeSign:
...At this point, all code signing certificates are issued using RSA algorithm...
Вторая попытка выпуска сертификата прошла успешно (быстрее вводился PIN-код).
Для проверки результата была запущена утилита pkcs11-tool, что бы вывести список объектов на токене. Результат удивил:
Public Key Object; RSA 4096 bits
label: RSA
ID: 618ba098e429bda788874a13f382a22d
Usage: encrypt, verify
Access: local
Private Key Object; RSA
label: RSA
ID: 618ba098e429bda788874a13f382a22d
Usage: decrypt, sign
Access: sensitive, always sensitive, never extractable, local
Public Key Object; RSA 4096 bits
label: RSA
ID: 618ba098e429bda788874a13f382a22d
Usage: encrypt, verify
Access: none
Public Key Object; RSA 4096 bits
label: RSA
ID: 0120b2555e805969b5f96f0a8a09bc9c
Usage: encrypt, verify
Access: local
Private Key Object; RSA
label: RSA
ID: 0120b2555e805969b5f96f0a8a09bc9c
Usage: decrypt, sign
Access: sensitive, always sensitive, never extractable, local
Public Key Object; RSA 4096 bits
label: RSA
ID: 0120b2555e805969b5f96f0a8a09bc9c
Usage: encrypt, verify
Access: none
Public Key Object; RSA 4096 bits
label: RSA
ID: 0120b2555e805969b5f96f0a8a09bc9c
Usage: encrypt, verify
Access: none
Public Key Object; RSA 4096 bits
label: RSA
ID: 0120b2555e805969b5f96f0a8a09bc9c
Usage: encrypt, verify
Access: none
Data object 3257969126
label: 'X509 Request'
application: 'webcrypto-p11'
app_id: -1
flags: modifiable
Data object 3257969130
label: 'X509 Request'
application: 'webcrypto-p11'
app_id: -1
flags: modifiable
Certificate Object; type = X.509 cert
label: RSA
subject: DN: ...
serial: 6E0C...
ID: 0120b2555e805969b5f96f0a8a09bc9cОстались следы от первой неудачной попытки, ну ладно. Но зачем-то записалось куча публичных ключей. И остались следы в виде Data object. Причем, уникальностью меток даже не заморачивались (а это критично для Java, например) и два сертификата на одном токене таким образом, полагаю, не сделать.
Интересно, что это, косорукость разработчиков?
