Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

3 Страницы123>
Опции
К последнему сообщению К первому непрочитанному
Offline Dartwed1989  
#1 Оставлено : 17 мая 2019 г. 11:38:52(UTC)
Dartwed1989

Статус: Участник

Группы: Участники
Зарегистрирован: 17.05.2019(UTC)
Сообщений: 13
Российская Федерация
Откуда: Санкт-Петербург

Поблагодарили: 1 раз в 1 постах
Добрый День!

Подписываю файл XML с помощью XMLDSig, сервер портала системы электронных паспортов(СЭП) возвращает сообщение - "Подпись некорректна".
Пробовал на версиях платформы 1С 8.3.10.2496 и 8.3.12.1531.

Подписываю файл следующим образом:
1. Есть сертификат УЦ с алгоритмом подписи GOST R 34.11-2012/34.10-2012 256 bit, Алгоритм Хэш GOST R 34.11-2012 256 bit.
Открытый ключ: ГОСТ Р 34.10-2012 256 бит. Идентификатор 1.2.643.7.1.1.1.1
Подпись удостоверяющего центра: ГОСТ Р 34.11-2012/34.10-2012 256 бит. Идентификатор 1.2.643.7.1.1.3.2
В параметрах XMLDsig в 1С прописал следующее:
ИмяАлгоритмаПодписи = "GR 34.10-2012 256";
OIDАлгоритмаПодписи = "1.2.643.7.1.1.3.2" - если прописать 1.2.643.7.1.1.1.1, то 1С ругается, что OID алгоритма подписи не соответствует OID компоненты.
ИмяАлгоритмаХеширования = "GR 34.11-2012 256"
OIDАлгоритмаХеширования = "1.2.643.7.1.1.2.2"

XPathПодписываемыйТег = "(//. | //@* | //namespace::*)[ancestor-or-self::soapenv:Envelope]"; По требованиям СЭП подписывать необходимо весь конверт целиком.
XPathSignedInfo = "(//. | //@* | //namespace::*)[ancestor-or-self::*[local-name()='SignedInfo']]";

2. После сбора всех данных в 1С формирую строку XML, которую буду подписывать(см. Строка для подписи)
Параллельно формирую строку XML, в которую буду вставлять подпись (см. Строка с тэгами подписи). Строки абсолютно идентичны, только во второй есть тэги подписи.
3. Каноникализация строки для подписи(см. Строка для подписи каноникализация)
4. Во вторую строку выгружаю данные сертификата в тэг X509Certificate, вставляю рассчитанный хэш в тэг DigestValue и саму подпись в тег SignatureValue. Данные отправляются в СЭП(см. Итоговый конверт отправки, Ответ СЭП)
Возвращается ответ - Подпись некорректна. В чем именно проблема разобраться не выходит. Тех поддержка СЭП ответить на вопрос не может.
Если получится помочь, буду крайне признателен.
Offline Максим Коллегин  
#2 Оставлено : 20 мая 2019 г. 12:10:12(UTC)
Максим Коллегин

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC)
Сообщений: 6,374
Мужчина
Откуда: КРИПТО-ПРО

Сказал «Спасибо»: 32 раз
Поблагодарили: 704 раз в 613 постах
Выложите по возможности примеры "хорошего" и "плохого" подписанного xml. Попробуйте поиграть с PreserveWhitespace.
Знания в базе знаний, поддержка в техподдержке
Offline Dartwed1989  
#3 Оставлено : 20 мая 2019 г. 17:09:40(UTC)
Dartwed1989

Статус: Участник

Группы: Участники
Зарегистрирован: 17.05.2019(UTC)
Сообщений: 13
Российская Федерация
Откуда: Санкт-Петербург

Поблагодарили: 1 раз в 1 постах
К сожалению "хорошего" xml нет.
Ресурс https://www.justsign.me/verifyqca/Verify/ так же показывает, что подпись недействительна.
Offline two_oceans  
#4 Оставлено : 21 мая 2019 г. 8:14:58(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Похоже вложения не прикрепились. Попробую предположить вслепую, что Вы делаете подпись через низкоуровневые функции или плагин и сами собираете тег Signature - нужно проверить положение вставленного тега подписи Signature и вставленный текст, возможно вставляете не то и не туда. По идее при подписании всего документа (предполагаю что кроме SOAP:Envelope и вложенных в него тегов больше ничего нет в документе), он должен располагаться в конце документа перед
Код:
</SOAP:Envelope>
, в референс указывается URI="" и в список трансформов под референсом добавляется урл трансформа enveloped signature. Трансформ enveloped signature показывает что подпись (подписи), располженную непосредственно под подписываемым тегом надо удалить при проверке перед расчетом хэша, без него в расчет хэша попадет и сама подпись следовательно хэш не сойдется, так как Вы считали хэш еще без подписи. Также не забудьте проверить, что текст SignedInfo не изменяется в процессе ручной сборки подписи после вычисления SignatureValue (лучше вообще вставить именно каноникализированный текст SignedInfo, от которого вычислено SignatureValue в готовую подпись). Также лучше избегать переводов строк с символом 13 в SignedInfo, разными системами стандарты применяются в разном порядке и есть различия в обработке символов с кодом 13. В идеальном случае символы 13 должны быть удалены перед каноникализацией в процессе "нормализации" документа, то есть каноникализация их вообще не должна обрабатывать при наложении подписи. Если несмотря на все это, все равно ошибка проверки, то возможно каноникализация проведена неверно.

Кстати, возможен еще вариант с "переворотом" значений хэша и/или подписи - в зависимости от криптопровайдера результат может быть "задом наперед" от требуемого XMLDSig формата и нужно поменять первый байт с последним, второй с предапоследин и т.д до середины перед переводом значения в Base64. Если плагин Вам результат выдал уже в Base4 то надо декодировать, перевернуть и снова закодировать. При длине 256 хэш должен заканчиваться один знаком =, а значение подписи двумя знаками ==. В случае гост-2001 и низкоуровневыми функциями нужно было перевернуть хэш, а значение подписи записать как есть без переворота. По гост-2012 было сообщение что порядок тот же, но у меня что-то тоже не сходится подпись, а верных примеров с гост-2012 для "калибровки" маловато, жду пока смэв начнет подписывать новым гост.

Если нужно, могу прогнать Ваши примеры через свою программку и уточнить на каком этапе проверки возникает ошибка.
Offline Dartwed1989  
#5 Оставлено : 21 мая 2019 г. 8:38:20(UTC)
Dartwed1989

Статус: Участник

Группы: Участники
Зарегистрирован: 17.05.2019(UTC)
Сообщений: 13
Российская Федерация
Откуда: Санкт-Петербург

Поблагодарили: 1 раз в 1 постах
Stroka s tehgami podpisi.xml (27kb) загружен 21 раз(а). Stroka dlja podpisi.xml (26kb) загружен 22 раз(а). Stroka dlja podpisi kanonikalizacija.xml (39kb) загружен 22 раз(а). Itogovyjj konvert otpravki.xml (30kb) загружен 21 раз(а). OtvetSEhP.xml (5kb) загружен 11 раз(а).

Файлы перезалил
Offline two_oceans  
#6 Оставлено : 22 мая 2019 г. 7:37:52(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Посмотрел файлы. Какая-то смесь разных требований если честно, пройти может только первый этап проверки подписи (проверка правильности SignatureValue), хэши в таком виде документа не могут сойтись. Попробую их проверить чуть позже, слегка изменив документ, а пока перечислю странности документа.

1.
Исправлено: после перепрочтения текста стандарта в сообщении ниже уже не уверен в своем понимании трансформа enveloped signature, поэтому убрано в спойлер

Еще отмечу, что несмотря на удаление тега Signature и вложенных в него тегов трансформом enveloped signature, в подписываемом тексте должны сохранятся все остальные теги. В данном случае я вижу что в строке для подписи отсутствует тег SenderInformationSystemSignature, по стандартам он должен присутствовать (пусть и пустой), так как он тоже не удалится трансформом enveloped signature.

2. Важно то, что CanonicalizationMethod Algorithm применяется только к SignedInfo перед выработкой SignatureValue и ничего не говорит о каноникалилации тега на который ссылается референс перед вычислением DigestValue. Поэтому если Вы текст документа за исключением текущей подписи каноникализируете, то в трансформах должен присутствовать и метод каноникализации. Иначе при проверка каноникализация скорее всего не будет выполнена и получится другой хэш.

В принципе проверяющая сторона может выбрать некий алгоритм каноникализации по умолчанию, который используется когда никакого не указано. Например, чтобы проверить все примеры разных ГИС моя программа подбирает трансформ каноникализации хэша когда никакого не указано в трансформах референса, но выдает предупреждение что фактически использован такой-то алгоритм каноникализации при том что никакого не указано. Однако это уже натяжка стандарта под конкретные ГИС, лучше укаать явно какой алгоритм каноникализации Вы использовали перед вычислением хэша чтобы проверка точно прошла успешно.

Сразу скажу по порядку трансформов когда их несколько в одном референсе: в случае присутствия трансформа enveloped signature сначала указавается enveloped signature потом метод каноникализации. Если присутствует смэвовский трансформ он указывается после канононикализации. При другом порядке трансформы дают неожиданный результат.

3. Формат начиная с RequestMessage очень напоминает схемы СМЭВ3 (хотя и отличия есть, например MessageID не по требования смэв3 из метки времени и мак адреса, а сгенерирован случайно), по которым в SenderInformationSystemSignature помещается подпись от элемента SenderProvidedRequestData, а не от SOAP:Envelope.

Возможно нужно наложить две подписи - одну по требованиям смэв (в SenderInformationSystemSignature поместить подпись от элемента SenderProvidedRequestData с определенными смэв трансформами: исключающая каноникализация и смэвовский, при этом SenderProvidedRequestData должен иметь Id начинающийся с буквы и этот Id указывается в референс ури после решетки), вторую в конце документа, перед </SOAP:Envelope> с URI="" и трансформами: enveloped signature и каконикализацией. Обратите внимание, что при наложении подписей на теги вложенные один в другой важно соблюдать порядок наложения подписей - сначала подписать вложенный тег потом обрамляющий тег (но без исключения подписи вложенного тега).

Другой вариант - что вторая подпись накладывается на какой-то другой из тегов (SOAP:Body или EPLTSAddData или RequestMessage). Это все же нужно уточнить в требованиях предъявляемых конкретной ИС. Либо все-таки какой-то правильный пример из руководства пользователя хотелось бы посмотреть чтобы не гадать.

Отредактировано пользователем 22 мая 2019 г. 12:19:14(UTC)  | Причина: Не указана

thanks 1 пользователь поблагодарил two_oceans за этот пост.
Андрей * оставлено 22.05.2019(UTC)
Offline Dartwed1989  
#7 Оставлено : 22 мая 2019 г. 9:57:41(UTC)
Dartwed1989

Статус: Участник

Группы: Участники
Зарегистрирован: 17.05.2019(UTC)
Сообщений: 13
Российская Федерация
Откуда: Санкт-Петербург

Поблагодарили: 1 раз в 1 постах
example.xml (239kb) загружен 39 раз(а).


СЭП прислал корректный файл с подписью
Offline two_oceans  
#8 Оставлено : 22 мая 2019 г. 12:14:57(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Хм, или я неправильно понимаю трансформ enveloped signature или что-то тут не так.


Ну хорошо, пусть текущая подпись (содержащая алгоритм enveloped signature) убирается где бы ни была, тогда навскидку вижу отличия: 1) нет XML Declaration
Код:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
Ваши файлы вроде бы уже в UTF-8, но без данной строки в начале (строка должна появиться в итоговом варианте, в остальных может отсутствовать, так как все равно удаляется при каноникализации); 2) все же надо вставить пустой тег SenderInformationSystemSignature в строку для подписи; 3) замечание про указание каноникализации из прошлого моего ответа все равно может быть в силе (хоть трансформ каноникализации не указан в примере, может быть не лишним его указать).

Сейчас изменю трансформ в своей программе и попробую проверить на предмет порядка байтов.

Отредактировано пользователем 22 мая 2019 г. 12:20:52(UTC)  | Причина: Не указана

Offline two_oceans  
#9 Оставлено : 23 мая 2019 г. 13:27:47(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Спасибо за пример, помог мне заодно разобраться с гост-2012.

Так как пример прошел проверку на КриптоПро DSS, то использовал его для калибровки гост-2012. Попробовал провести пример через проверку и завалился сразу на проверке SignatureValue. Как оказалось, у меня инициализировался по умолчанию хэш гост-94 при типе провайдера 80 и подавался на проверку с дескриптором открытого ключа из сертификата гост-2012 и низкоуровневая функция проверки о несовместимых алгоритмах даже не пикнула, просто проверила по гост-2001 надо полагать и выдала результат: неверная подпись.

С поправкой алгоритма хэша на гост-2012-256 проверка SignatureValue в примере прошла, а в Вашем итоговом конверте все равно пока не проходит, попробую разнын варианты с сохранением удалением символов с кодом 9,10 и разным порядком байт. Для устойчивости прохождения проверки во всех средствах проверки было бы замечательно чтобы в SignedInfo вообще не было символов с кодами ниже 32 (другими словами, табуляций и переводов строк, так как остальные символы с кодами наже 32 и так уже запрещены форматом XML).
Offline Dartwed1989  
#10 Оставлено : 24 мая 2019 г. 14:48:35(UTC)
Dartwed1989

Статус: Участник

Группы: Участники
Зарегистрирован: 17.05.2019(UTC)
Сообщений: 13
Российская Федерация
Откуда: Санкт-Петербург

Поблагодарили: 1 раз в 1 постах
По "правильному" файлу можно ли определить данные в каких тегах подписываются?
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
3 Страницы123>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.