Re: Работа с функциями библиотеки rtPKCS11ECP
А можно код того, как вы "готовите" данные для sign?
Вы не авторизованы. Пожалуйста, войдите или зарегистрируйтесь.
Форум Рутокен → Техническая поддержка разработчиков → Работа с функциями библиотеки rtPKCS11ECP
Страницы Назад 1 2 3 4 … 10 Далее
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
А можно код того, как вы "готовите" данные для sign?
А можно код того, как вы "готовите" данные для sign?
// Crypto - экземпляр класса для работы с библиотекой
// Device - идентификатор подключенного Рутокена
// id - идентификатор сертификата
// docpath - путь к файлу с исходными данными
// signpath - путь к файлу открепленной подписи
string data = "";
using (FileStream fs = new FileStream(docpath, FileMode.Open, FileAccess.Read))
{
byte[] buffer = new byte[fs.Length];
fs.Read(buffer, 0, buffer.Length);
//data = BitConverter.ToString(buffer).Replace("-", ""); // Попробуем не в HEX, а в Base64
data = Convert.ToBase64String(buffer);
}
OptionsMap options = new OptionsMap();
options.Add("addUserCertificate", true);
options.Add("addSignTime", true);
options.Add("detached", true);
options.Add("calculateHash", true);
options.Add("isBase64", true);
options.Add("useHardwareHash", false);
string sign = Crypto.sign(
Device,
id,
data,
options,
new StringVector());
// Записываем ЭЦП в файл
using (StreamWriter fs = new StreamWriter(signpath))
{
fs.Write(sign);
}
Я вас немного обманул.
Вот так надо.
options.Add("base64", true);
Сработало! Спасибо!
Но... Теперь обратная ситуация: проверка валидности подписи функцией Verify библиотеки не проходит. Перебирал несколько вариантов. Код одного из них, который мне кажется логичным с учетом выясненных с Вашей помощью параметров для Sign:
// Crypto - экземпляр класса для работы с библиотекой
// Device - идентификатор подключенного Рутокена
// docpath - путь к файлу с исходными данными
// signpath - путь к файлу открепленной подписи
// сертификат в содержимом подписи
string sign = "";
string data = "";
using (StreamReader sg = new StreamReader(signpath))
using (Stream dt = File.Open(docpath, FileMode.Open))
{
sign = sg.ReadToEnd();
byte[] buffer = new byte[dt.Length];
dt.Read(buffer, 0, buffer.Length);
data = Convert.ToBase64String(buffer);
}
OptionsMap options = new OptionsMap();
options.Add("base64", true);
options.Add("verifyCertificate", false);
options.Add("useHardwareHash", false);
bool right = Crypto.verify(
Device,
sign,
data,
new StringVector(),
new StringVector(),
new StringVector(),
options);
options.Dispose();
Вы все делаете правильно. Судя по всему в функции verify ошибка при декодировании данных из base64. Разбираемся.
Ключевая пара на рутокене сгенерирована в VIPNet CSP, по запросу УЦ прислал сертификат. Если привязывать сертификат к ключевой паре средствами того же самого VIPNet, то функция вида enumerateCertificates(Device, 0) его видит как объект. Если же сертификат привязать к паре с помощью кнопки "Импортировать" в Панели управления Рутокена, то не видит. Пробовал при различных значениях второго параметра, указывающего на категорию сертификата, не помогло... Также не видит и самоподписанный импортированный сертификат, изготовленный по рецепту https://forum.rutoken.ru/topic/1639/
1. Да, текущая версия Панели управления не импортирует в совместимом виде.
2. При использовании openssl самоподписанный сертификат не импортируется на токен, а сохраняется в файл. Из файла его можно импортировать. Например, через сервис http://ra.rutoken.ru
Здравствуйте!
Снова вопросы по Библиотека для встраивания электронной подписи в приложения С++ и rtPKCS11ECP.dll. Снова формирую подпись формата CMS функцией Sign, используя тот же код, что указывался выше, только теперь в качестве данных (параметр № 3 функции Sign) не сами исходные данные, а предвычисленный хэш ГОСТ 34.11-94. Так как в отдельной библиотеке для встраивания ЭЦП функции вычисления хэша еще не реализованы, использую библиотеку rtPKCS11ECP.dll и ее функции C_DigestInit и C_Digest, механизм { CKM_GOSTR3411, NULL, 0 }. Неприятности такие:
Для некоторого набора данных функция хэширования возвращает
8F-D0-6C-E0-89-F7-10-ED-0D-F2-A0-9B-3B-57-E2-2C-E8-B3-97-65-1D-B7-E5-FC-A4-D4-5D-A3-B3-AC-89-2D,
а утилита проверки хэшей, взятая здесь https://www.infotecs.ru/downloads/produ … duct=10808, это:
F8-0D-C6-0E-98-7F-01-DE-D0-2F-0A-B9-B3-75-2E-C2-8E-3B-79-56-D1-7B-5E-CF-4A-4D-D5-3A-3B-CA-98-D2,
т.е. символы в HEX-паре расположены в обратном порядке... Кто прав здесь, не решусь судить...
Проверка подписи, полученной вышеописанным образом, средствами VIPNet не проходит. Пробовал кодировку хэша и Base64 и HEX, переставлял биты, учитывая пункт 1, не помогает. В наборе опций для функции Sign менялось только значение параметра calculateHash с true на false.
Функция Sign всегда считает хеш. Поэтому опция calculateHash справедлива только для функции rawSign. Получается у вас в итоге подпись хеша от хеша. Подозреваю, что поэтому и проверка не проходит.
Тогда вопросов нет, подпись хэша от хэша, так и есть... А функция rawSign не включает в подпись сертификат, что мне необходимо. У меня просто ситуация "хитрого" вычисления хэша, а именно: в качестве данных - три файла, от каждого вычисляется ГОСТовский хэш, из полученных трех ГОСТовских хэшей формируется итоговый ГОСТовский хэш, и уже последний - на подпись. Если Вы не планируете доработку функции Sign для работы с готовым хэшем, что ж, будем менять нашу тактику. )))
А есть какие-нибудь мысли по поводу C_DigestInit и C_Digest
...Для некоторого набора данных функция хэширования возвращает
8F-D0-6C-E0-89-F7-10-ED-0D-F2-A0-9B-3B-57-E2-2C-E8-B3-97-65-1D-B7-E5-FC-A4-D4-5D-A3-B3-AC-89-2D,
а утилита проверки хэшей, взятая здесь https://www.infotecs.ru/downloads/produ … duct=10808, это:
F8-0D-C6-0E-98-7F-01-DE-D0-2F-0A-B9-B3-75-2E-C2-8E-3B-79-56-D1-7B-5E-CF-4A-4D-D5-3A-3B-CA-98-D2,
т.е. символы в HEX-паре расположены в обратном порядке... Кто прав здесь, не решусь судить...
Сгенерировал пару ключей RSA для подписи с помощью функции C_GenerateKeyPair с механизмом CKM_RSA_PKCS_KEY_PAIR_GEN (0x00000000). Функция отработала успешно, ключи как объекты поиском видны, операции подписи и проверки выполняются, но... эта пара не видна в панели управления Рутокен! Вроде и мелочь, по задумке при работе с нашей программой пользователю нет смысла иметь дело с панелью, но настораживает. При генерации шаблоны атрибутов ключей строил по подобию проекта CreateRSA из скачанного SDK с переводом на C#. Кстати, если скомпилировать и запустить сам проект SDK, то сгенерированная пара в панели видна. Может, Вам как разработчикам библиотеки виднее при каких условиях идет отображение в Панели строчки с информацией о ключевой паре?
Здравствуйте. У меня аналогичная проблема, не могли бы вы и мне скинуть на почту переходник под C#?
Здравствуйте. У меня аналогичная проблема, не могли бы вы и мне скинуть на почту переходник под C#?
Отправил на почту
Если Вы не планируете доработку функции Sign для работы с готовым хэшем, что ж, будем менять нашу тактику. )))
Нам будет проблематично доработать функцию sign таким образом. Это связано с особенностями формата CMS.
Sergeant пишет:Если Вы не планируете доработку функции Sign для работы с готовым хэшем, что ж, будем менять нашу тактику. )))
Нам будет проблематично доработать функцию sign таким образом. Это связано с особенностями формата CMS.
И не надо! Мы уже определились как быть. Текущая работа функции Sign вполне устраивает. Спасибо.
Виктор Ткаченко, спасибо большое, буду разбираться что и как.
Страницы Назад 1 2 3 4 … 10 Далее
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Форум Рутокен → Техническая поддержка разработчиков → Работа с функциями библиотеки rtPKCS11ECP