Работа с API. C# quick start (Страница 1 из 2)

Здравствуйте!
Спасибо за ответ. Текущий статус сейчас это установлены дистрибутивы
1 - "Программа конфигурации СКЗИ СКАД Сигнатура" х64
2 - Справочник сертификатов х64

Тут первое это я так понимаю Ваш SDK, а второе то, к чему мне необходимо ещё получить ключи и сертификаты. Верно?
Это первое.

Второе в том, что когда я получу ключи эти, то мне надо запросить для .net приложения так называемый ППИ: Прикладной Программный Интерфейс СКАД Сигнатура. В его поставку будет включена dll'ка vcpi2.dll.  Она будет содержать функции, которые дёргают spki1.dll и используют уже её. Но мне, как программисту С# как раз и надо будет работать непосредственно с функциями vcpi2.dll.  Всё верно?

Тогда получается что 2 программы это SDK ?

1 - "Программа конфигурации СКЗИ СКАД Сигнатура" х64
и
2 - "ППИ: Прикладной Программный Интерфейс СКАД Сигнатура" х64

И если это так, то чем они отличаются? Как вариант могу предположить что они отличаются тем что 1-ый для не .net, а второй для .net C#. Прошу прояснить этот момент..

А будет ли мне нужно настраивать это "криптографическое ядро"?
Я думал, что просто установлю ППИ, открою документацию где написано вызвать функции А, Б и Ц. Добавлю в студии ссылку на dll с указанными функциями. Вызову их, передавая туда сформированный файл xml, и получу другой файл. А другой уже отправлю в ЦБ вместо текущей xml'ки.

Так там просто описание как составить xml'ку для той или иной платёжки. Меня заверили что согласно описанным правилам они у нас уже составляются. Вот только дальше нужно их как-то подписать. Для этого и ищется способ.. На текущий момент я так понимаю что мне нужно взять и установить ППИ для этого. В нём будет vcpi2.dll, а в ней функции что смогут это сделать. Или что-то не так ?

К примеру на входе в функцию будет файл, а на выходе zip архив, который формируется на основании ключа банка, в котором работаю. Zip содержит файл что был на входе и некий .sig файл. И такое считается что подписано. А дальше я просто это отправляю в ЦБ.

Здравствуйте!
Я прочитал этот документ. Из него ясно что внутри xml вставляется секция <dsig:тратратра бла бла бла>, но не ясно какие функции API дёргать чтобы получить этот результат. Попросту говоря в документе, по больше части, "налита вода".

Посему вопрос в том, что где взять описание непосредственно того какие функции дёргать чтобы получить результат? И верно ли я понял, что этим результатом будет xml с секцией <dsig:тратратра бла бла бла> ?

То есть по сути нужно простое руководство вида 1 2 и 3, где вместо цифр будет что-то типа:
"1 - Скачать/получить дистрибутив ППИ, установить его, добавить в Visual Studio dll'ку такую-то
2 - Для того чтобы подписать xml'ку(заверить или ещё как-то в терминологии могу ошибаться) вызовите функцию такую-то.
3 - Для того чтобы убрать подпись/расшифровать назад, при необходимости, функцию такую-то"
И всё.

Здравствуйте!

На текущий момент я получил настроенный справочник сертификатов и ключ от рутокен. В итоге есть и ключ и сертификат. Также "Программа конфигурации СКЗИ СКАД Сигнатура - программа настройки криптографического ядра" я так понял что настроена.

Жду когда будет получен ППИ. Параллельно изучаю алгоритм что просят сделать для подписи документа.
Вроде как шаги следующие:
1 - вырезать dsig:SigValue если оно есть в xml.

2 - нормализовать как-то (urn:cbr-ru:dsig:v1.1#normalization   - приведено упоминание вот этого. Что это и где взять?)

3 - канонизировать результат шага 2 (https://msdn.microsoft.com/ru-ru/library/system.security.cryptography.xml.xmldsigexcc14ntransform(v=vs.110).aspx)

4 - Загрузить полученный xml в память и передать как массив байт из памяти некой функции, что получу вместе с ППИ

5 - результат пункта 4 вернёт мне некий ЗК. Предположительно это строка. Надо его закодировать (https://stackoverflow.com/questions/11743160/how-do-i-encode-and-decode-a-base64-string). Если не строка, а байты то тоже кодировать, просто чутка иначе (https://msdn.microsoft.com/ru-ru/library/dhx0d524(v=vs.110).aspx).

6 - результат 5 обернуть так: "<dsig:SigValue>результат_пункта_5</dsig:SigValue>" и положить в начало xml'ки из пункта 3.

Всё верно?

Приветствую!
Я бы еще добавил для расширения кругозора:
http://bankir.ru/dom/forum/департамент- … -csp/page4
http://bankir.ru/dom/forum/департамент- … ости/page5

А, вообще, при работе с криптографией,  неплохо бы держать в голове следующие вещи:
1. Все что касается криптографии в нашей стране регулирует ФСБ.
2. Любая деятельность, связанная с разработкой криптографии, её встраиванием или еще какими услугами с ней связанными, является лицензируемой деятельностью. Т.е. организация на данные виды деятельности должна получать лицензию ФСБ. Отсутствием такой лицензии, чревата в т.ч. уголовной статьей для руководства компании. И прецеденты такие известны.
3. Если в ПО куда Вы встраиваете СКЗИ обрабатывается конфиденциальная информация, защищаемая в соответствии с действующим законодательством, необходимо провести т.н. "тематические исследования" или, по простому, контроль встраивания. О необходимости этого мероприятия говорится , например, на сайте ФСБ
http://www.fsb.ru/fsb/science/single.ht … chart.html
При чем, на самом деле, это требование касается обработки не только персональных данных (ПДн), но и  платежей, банковской тайны и т.д. Т.е. всей той информации, которая упомянута в п.1.2., 552-П ЦБ РФ. Это то самое Положение ЦБ, результатом которого явилось то, что Вам поручили эту задачу (хотя, возможно, что я ошибаюсь ).
Для контроля встраивания, обращаться положено к разработчику СКЗИ (рекомендуется заранее уточнить о сроках и ценах). Хотя, можно это переложить и на банки, т.е. тех, кто будет Ваше ПО использовать (если, конечно, сами  Вы трудитесь в компании-разработчике).

Далее. В мире вообще и в Европе в  частности, существует целый ряд стандартов формализующих способы формирования электронной подписи (ЭП). Перечислять буду не все и не всё.
1. Для формирования ЭП файла любого формата, были разработаны следующие стандарты (каждый последующий. это развитие предыдущего). PKCS#7, CMS и европейский стандарт - CAdES.
Упрощенно, суть в следующем. берется любой файл, вычисляется ЭП (т.е. вычисляется хеш и шифруется закрытым ключом),  и, к самой ЭП, добавляется сертификат, открытый ключ, какие-то параметры, временные метки и т.д. и все это остается в двоичном виде. Далее, получившаяся последовательность байт присоединяется к исходному файлу или записывается в отдельный файл. Таким образом и получается attached/detached ЭП.
2. Для подписания (формирования ЭП) XML файлов были разработаны стандарты XML-DSig и в Европе XAdES. Там был реализован несколько иной подход:
2.1. Исходный XML файл определенным образом трансформируется, таким образом, что бы из него удалить все незначимые для подписываемых данных поля, теги, строки и символы (лишние пробелы, <CR><LF> переводят только в <LF> и т.д.). Это необходимо для того, что если в файле поменяли что-то "не значимое", ЭП при этом не менялась.
Как правило, эту трансформацию и называют канонизацией, приведением XML файла к некой канонической форме.
2.2. Далее все получаемые или используемые при подписании файла значения и величины преобразуют в текст (Base64), отдельно обрамляют соответствующими тегами и записывают в тот же XML.
Т.е. в теле исходного XML файла появляются отдельные, обрамленные соответствующими отдельными тегами, поля с ЭП, хешем, сертификатом, временными метками и т.д.

В и-нете навалом описания, исходников, программ для всевозможных стандартных канонизаций и подписаний.

Как это все реализовано у нас.
1. Наверное, у всех разработчиков СКЗИ, существуют утилиты командной строки, формирующие ЭП для любого файла в PKCS#7 или CMS, а может и в CAdES.
2. Каждое наше ведомство, включая ЦБ, при реализации обмена в виде XML файлов, придумывает свой очередной уникальный способ трансформации XML файлов, далее формирует подпись, как правило в PKCS#7 или CMS и запихивает его в XML в виде одного поля.

Т.е. у нас в стране, одновременно живет достаточно разношерстное множество способов формирования ЭП  для XML.
Все они не совместимы друг с другом, а наши программисты, похоже, никогда не останутся без работы.

Так, например, ЦБ, при трансформации XML для обмена платежами через АРМ КБР, использует вроде бы стандартную (одну из) канонизаций и, зачем-то, добавил еще некую нормализацию XML, исходя из каких-то своих представлений. При реализации им же обмена отчетностью в виде XML, используется неколько иной способ трансформации.
Зачем? хз, но тем не менее, это так. Ну и т.д. и т.п. На том же сайте bankir.ru в ветке автоматизаторов,  эти многочисленные форматы XML обмена регулярно обсуждаются.

Очень рекомендую, почитать в и-нете про все вышеперечисленные стандарты, посмотрите имеющееся (открытое) ПО в исходниках. Т.е. наберите некий базис и, потом, Вам будет легче общаться с программерами на сайте того же bankir.ru.
Начинать можно с http://www.w3.org/TR/xmldsig-core/, и вообще, яндекс/google Вам в руки.

И да, компания Валидата, к сожалению, не занимается реализацией ЭП для XML в формате УФЭБС. Т.е. вопросы Вы задаете определенно не на том форуме

В общем, как-то так. Надеюсь, сильно ни где не соврал....
Да прибудет с нами знание (т.е. сила) (с)

ППИ этого делать не умеет

ППИ выдаст подпись в PKCS7 формате, далее ее придется конвертировать в BASE64. Вся работа с форматом УФЭБС ложится на Ваши плечи.

PKCS7  - PKCS (Public-Key Cryptography Standards). PKCS#7 (седьмой из набора стандартов PKCS). Это не строка, а бинарный массив. Детальное  описание PKCS7 сотрите тут https://tools.ietf.org/html/rfc2315 (к сожалению на английском). А так, по алгоритму все верно.
P.S. при вызове функции ППИ Вам необходимо подать флаг, что ЭП будет в отсоединенном формате (без тела подписанного сообщения).

Код который Вы привели, это  зашифрование и расшифрование.
Для подписи страница 57-58 из документации

byte[] data = File.ReadAllBytes(fileName); 
SignParameters sp = new SignParameters(); 
sp.Pkcs7 = true; 
sp.Detached = false; 
byte[] sign = ctx.SignMemory(sp, data, null);

в вашем случае надо ставить

sp.Detached = true; 

Проблемы с не нахождением DLL могут быть связаны с разрядностью проекта и с разрядностью установленной Сигнатуры. Какая у Вас разрядность ОС? Разрядность Сигнатуры? Разрядность собираемого проекта?