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

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

Изучив 4ую версию документа и получив информацию что нужно делать как написано в разделе "ЗАЩИТА ЭЛЕКТРОННЫХ СООБЩЕНИЙ (ПАКЕТОВ ЭС) С ПОМОЩЬЮ КА" получилось следующее:

1 - сам xml сформировали(ED-###);
2 - подписали получив byte[] sign;
3 -

var sigInBase64 = Convert.ToBase64String(sign);
                var xmlSigInBase64 = "<dsig:MACValue xmlns:dsig=\"urn:cbr-ru:dsig:v1.1\">" + sigInBase64 + "</dsig:MACValue>";
                var dataInBase64 = Convert.ToBase64String(data);
                var xmlDataInBase64 = "<sen:Object>" + sigInBase64 + "</sen:Object>";
xmlPackage = "<sen:SigEnvelope xmlns:sen=\"urn:cbr-ru:dsig:v1.1\">"
                    + "<sen:SigContainer>"
                    + xmlSigInBase64
                    + "</sen:SigContainer>"
                    + xmlDataInBase64
                    + " </sen:SigEnvelope>";
                var resultFilePath = Path.Combine(Path.GetDirectoryName(fileName), Path.GetFileNameWithoutExtension(fileName) + "Signed.xml");

Собственно вопрос в том, что верно ли сформировано тело xmlPackage. Всё ли верно "орбернул" в тэги? Или может чего-то не хватает/лишнее ?

Вот что получилось:
<sen:SigEnvelope xmlns:sen="urn:cbr-ru:dsig:v1.1">
    <sen:SigContainer>
        <dsig:MACValue xmlns:dsig="urn:cbr-ru:dsig:v1.1">MIIBYAYJKoблаблаблаRJFD6M=</dsig:MACValue>
    </sen:SigContainer>
    <sen:Object>MIIBYAблаблаблаD6M=</sen:Object>
</sen:SigEnvelope>

Пробуем в разных вариантах обёртки скормить КБР-Н'у файлы с подписью. Стандартные вещи на что он ругался были:
- Файл недопустимого типа. Ожидается сообщение в служебном конверте;
- Сообщение не зашифровано или формат сообщения искажен   (код: 0xE0700083).

Первое для наших файлов обёрнутых разными способами и для файлов примеров с сайта ЦБ. Второй вариант ошибки был для файла примера с сайта ЦБ (файл PacketEPD_SOAP.xml).

Затем сделали свой согласно этому SOAP. Получили вот такую ошибку:
Error 21.08.2017 13:14:37.99 MSK-0974 OBT_oper_test kbr-rcv
111Signed - копия (4).xml: System.Exception: Неверный тип сообщения в формате PKCS#7   (код: 0xE0700022)
   в uarm.Common.Sign.SignProxy.Decode(String strEncFileName, String strDatFileName)
   в uarm.Gate.SAX.GateRcv.process(String filename)
   в uarm.Gate.GateBase.processMain()

upd #2: После всех приключений мы дошли до стадии того, что документ подписан КА. Для этого вызывалась функция ППИ 

SignParameters sp = new SignParameters();
                sp.Pkcs7 = true;
                sp.Detached = true;
                byte[] sign = vcertCtx.SignMemory(sp, data, null);

однако система ругнулась что необходимо защищать(подписывать) файл способом другим.

116Signed - копия (2).dat
Info 22.08.2017 13:52:07.53 MSK-0974 OBT_oper_test kbr-snd
Начало обработки файла 116Signed - копия (2).dat

Info 22.08.2017 13:52:07.55 MSK-0974 OBT_oper_test kbr-snd
КА проверен. Владелец <CN=PROCESSING501,OU=4525161000,O=KO161,L=REGRNP,ST=45,C=RU>

Error 22.08.2017 13:52:07.55 MSK-0974 OBT_oper_test kbr-snd
116Signed - копия (2).dat: System.ApplicationException: Несоответствие варианта защиты: требуется Вариант 2 - ЗК на весь пакет, получили Вариант 1 - не формировать ЗК
   в uarm.Gate.GateBase.checkZKMethod(String strFileName, ZKMethod pZKMethod)
   в uarm.Gate.GateBase.CheckZK(String strFileName, ZKMethod pZKMethod)
   в uarm.Gate.GateBase.checkSign(Stream streamKA, ZKMethod pZKMethod)
   в uarm.Gate.SAX.GateSnd.process(String filename)
   в uarm.Gate.GateBase.processMain()

Из сообщения понимаем это как то, что должен быть и КА и ЗК. Значит алгоритм несколько иной. Надо вызывать подпись ЗК, а потом подпись КА на результат подписанного ЗК документа.

upd #3: Для подписи ЗК из api ППИ использовали:

SignParameters sp = new SignParameters();
                sp.Pkcs7 = true;
                sp.Detached = true;
                byte[] sign = vcertCtx.SignMemory(sp, data, null);

Получили следующую ошибку:

Info 22.08.2017 18:19:30.85 MSK-0974 OBT_oper_test kbr-snd
Начало обработки файла 117Signed.xml

Info 22.08.2017 18:19:31.10 MSK-0974 OBT_oper_test kbr-snd
КА проверен. Владелец <CN=PROCESSING501,OU=4525161000,O=KO161,L=REGRNP,ST=45,C=RU>

Error 22.08.2017 18:19:31.24 MSK-0974 OBT_oper_test kbr-snd
117Signed.xml: System.ApplicationException: Проверка ЗК: System.Exception: Подпись недостоверна   (код: 0xE0700042)
   в uarm.Common.Sign.SignProxy.verifyResult(Boolean result, VerifyResultCollection vrc)
   в uarm.Common.Sign.SignProxy.Check(String strDataFileName, String strSignFileName, CertInfo& info)
   в uarm.Gate.GateBase.checkZKWhole(String filename)
   в uarm.Gate.GateBase.checkZKWhole(String filename)
   в uarm.Gate.GateBase.CheckZK(String strFileName, ZKMethod pZKMethod)
   в uarm.Gate.GateBase.checkSign(Stream streamKA, ZKMethod pZKMethod)
   в uarm.Gate.SAX.GateSnd.process(String filename)
   в uarm.Gate.GateBase.processMain()

В чём может быть причина? Что можете сказать по этому коду ошибки ?

ау

Хорошо, спасибо.

Подскажите пожалуйста как с ними связаться (с разработчиками АРМ КБР) ?

P.S: Я бы с удовольствием наконец-то решил вопрос и поделился бы решением с другими, кто мучается на круг не меньше моего. Меня, как программиста, жутко бесит, что приходится заниматься не программированием, а выискиванием всяких подобных сведений, которые скорее всего больше в жизни нигде и никогда не пригодятся. Уже зла не хватает на это. Потому буду искренне признателен если сможете помочь наконец решить эту чёртову загадку под кодовым названием "УФЭБС".

Вы вопросы свои задаете, ну совершенно не по адресу.
Вам же уже написали (и даже ссылки привели), что больше всего разработчиков по этой тематике тусуется на форуме сайта bankir.ru в ветке автоматизаторов. В чем проблема озвучивать свои вопросы именно там? А если Вы поделитесь там своими наработками по данной тематике, Вам еще и спасибо скажут.
Разработчиком АРМ КБР и УФЭБС является Центральный Банк Российской Федерации. Естественно, документация лежит на сайте ЦБ  - cbr.ru. В документации указано подразделение ЦБ, которое занимается разработкой АРМ КБР. Но сможете ли Вы получить от них ответ, это совсем другой вопрос, и не для этого форума. Это я к тому, что Вам уже предоставили всю необходимую информацию, что бы понять, в каком направлении двигаться дальше.
И не стоит разливать здесь свой негатив. Умение находить и получать необходимую информацию, полезный навык не только для программиста. но и для специалиста любой профессии. А начинать тут, КМК, имеет смысл с  нахождения правильного места получения необходимой информации. Разговоры "мне никогда больше в жизни это не понадобится" - типичные подростковые грабли с гравировкой на черенке "Не проходите мимо". Уж извините.
Удачи!

ЗЫ:И такое впечатление, что у компании, где Вы работаете, понимание требований ПП-313 достаточно поверхностное. К сожалению.

Зато, у Вас есть реальная возможность стать самым компетентным специалистом по данному направлению!))
Первопроходцам всегда тяжелее, чем тем, кто двигается уже проторенным путем.
И поаккуратней с желанием поделиться своими наработками. Дело это конечно весьма благородное, но т.к. код Вы пишете за з/п, права на исходники формально принадлежат работодателю. Ну а знаниями делиться никто не запрещает.
Ждем Вас на bankir-е.))

Подпись недостоверна   (код: 0xE0700042), это значит что не проверилась ЭП. Скорее всего данные передаваемые при формировании ЗК и проверке отличаются друг от друга. Похоже что Ваш алгоритм подготовки данных для формирования ЗК отличается от АРМ КБР. Если я правильно понял, то с КА все успешно?

К сожалению, я здесь бессилен...

Сигнатура  ничего не знает о нормализации и канонизации, она только принимает массив байт и проверяет ЭП, ей все равно как этот массив байт был получен, соответственно, никаких специальных кодов кроме "Подпись недостоверна   (код: 0xE0700042) Вы не получите.

Всегда рады помочь