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

Уведомление

Icon
Error

3 Страницы<123
Опции
К последнему сообщению К первому непрочитанному
Offline Dmitrii F  
#21 Оставлено : 4 июня 2020 г. 15:45:06(UTC)
Dmitrii F

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

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

Сказал(а) «Спасибо»: 1 раз
Выяснил, что правильный вариант получения закрытого/открытоко ключа
в .Net>4.6 (на примере RSA ключа):
Код:

Dim privateKey As RSA = cert.GetRSAPrivateKey()
Offline Dmitrii F  
#22 Оставлено : 4 июня 2020 г. 18:10:21(UTC)
Dmitrii F

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

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

Сказал(а) «Спасибо»: 1 раз
Судя по всему, реализации создания Signature
данных openssl и Net. различаются, поэтому
и не проходит верификацию.
информация

Вероятно, что нужно реализовывать wrapper для openssl или
использовать сторонние библиотеки, в которых этот функционал уже есть.

А ещё, можно попробовать использовать функцию
Код:
VerifyData()


1,2

Скажите пожалуйста, что вы об этом думаете?

Отредактировано пользователем 4 июня 2020 г. 18:11:08(UTC)  | Причина: Не указана

Offline Dmitrii F  
#23 Оставлено : 5 июня 2020 г. 22:17:25(UTC)
Dmitrii F

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

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

Сказал(а) «Спасибо»: 1 раз
Думаю, что надо добавить расширение к openssl (наподобии rsautil) и пересобрать openssl,
чтобы Signature рассчитывалась так-же, как и в Net.

Может, кто-то знает, есть ли подобные проекты?

В принципе, вот реализация Net.:

ComputeSignature Net.

openssl:

функции openssl для рассчёта Signature

Пример создания Signature openssl API

rsautil

Отредактировано пользователем 5 июня 2020 г. 22:18:07(UTC)  | Причина: Не указана

Offline two_oceans  
#24 Оставлено : 8 июня 2020 г. 6:12:42(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Добрый день. Несколько дней не заходил и не нашлось никого объяснить как работает проверка xmldsig?

Dmitrii F скорее всего проблема в неправильном понимании понятия "отсоединенная" применительно к xmldsig формату (который проверяется классом SignedXml). "Отсоединенная" (detached) для xmldsig означает что подпись и подписанный фрагмент взаимно не подчинены. Поэтому отсоединенная подпись может быть как в отдельном файле (на весь документ), так и внутри исходного (на фрагмент).

Обратите внимание на полный формат параметра Reference URI - в начале указывается URL файла, затем решетка и идентификатор фрагмента файла, то есть технически возможно подписать любой опубликованный файл в интернете. Если пропущено URL - используется текущий документ, в котором расположен тег Signature. Если пропушена решетка и идентификатор - берется весь документ. Пустое значение соответственно означает "подписан весь текущий документ". У вас при проверке Reference URI="" внешнего файла с подписью класс signedXml посчитает хэш от внешнего файла с подписью, а не от исходного и понятное дело так как в подписи указан хэш от исходного, то хэши файлов не сходятся.

Поэтому правильно так подписать весь файл:
1) В исходном файле тег Signature включается под тегом самого высокого уровня, в этом случае URI="" и должен присутствовать трансформ enveloped signature, то есть выйдет уже не detached. Проблема тут в том, что каждый валидный документ xml может содержать только один тег самого высокого уровня (не считая текст, специальные конструкции
Код:
<! --> <? ?>
), поэтому мы не можем просто "прилепить" подпись в конец файла, приходится включать на уровень ниже, где уже будет зависимость и тип enveloped signature.
2) Во внешнем файле ВНИМАНИЕ! URI должно содержать URL (ну хотя бы имя, считая что файлы в одной папке и это "текущий каталог") подписанного файла! В сообщениях выше есть цитата, что этот вариант не поддерживается SignedXml. С чем и поздравляю.

Для передачи в другие информационные системы вариант 2 неудобен и используется вариант 1. Отмечу однако, стандарт SOAP (и все форматы сервисов на его основе) напрямую запрещает вариант 2, оставляя только вариант 1 или 3 (ниже, отсоединенная подпись фрагмента в том же файле). В этом и ответ почему поддержку варианта 2 не включили в класс - используется крайне редко, но при этом требует много кода и ресурсов.

3)При подписи фрагмента (detached) выглядит примерно так:
Код:
<SIMPLE><HELLO id="aaaa"> Hello World </HELLO><Signature ...>...<Reference URI="#aaaa">...</Reference>...</Signature></SIMPLE>

Поэтому предлагаю прервать экскурс в sha алгоритмы подписи и вернуться к гост-2012 - с ним я смогу что-либо посоветовать и выявить проблему, а вот sha в моем решении не поддерживается.

Отредактировано пользователем 8 июня 2020 г. 8:13:06(UTC)  | Причина: Не указана

thanks 2 пользователей поблагодарили two_oceans за этот пост.
Dmitrii F оставлено 08.06.2020(UTC), Санчир Момолдаев оставлено 08.06.2020(UTC)
Offline Dmitrii F  
#25 Оставлено : 8 июня 2020 г. 13:45:43(UTC)
Dmitrii F

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

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

Сказал(а) «Спасибо»: 1 раз
two_oceans, Спасибо, что ответили.

Однако, в моём случае значения Digest (хэш) совпадают в openssl и Net.
для алгоритма gost_2012.

А вот Signature проходит проверку только та, что сформирована в Net.
ссылка


Отредактировано пользователем 8 июня 2020 г. 15:09:08(UTC)  | Причина: Дополнение информации

Offline Dmitrii F  
#26 Оставлено : 10 июня 2020 г. 15:14:25(UTC)
Dmitrii F

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

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

Сказал(а) «Спасибо»: 1 раз
Попробовал вариант с enveloped - с идентификатором (#)/без него.
Проверку не проходит (если создавать в openssl)

Если создавать средствами .Net, то проверку проходит.

Отредактировано пользователем 11 июня 2020 г. 8:57:10(UTC)  | Причина: Дополнение информации

Offline two_oceans  
#27 Оставлено : 25 июня 2020 г. 5:50:47(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: Dmitrii F Перейти к цитате
Однако, в моём случае значения Digest (хэш) совпадают в openssl и Net.
для алгоритма gost_2012. А вот Signature проходит проверку только та, что сформирована в Net.
При подписании хэши совпадают, так и задумано. А вот какой хэш получается при проверке (точнее от какого фрагмента) - совсем другая история. Когда подпись сформировали вручную из заданного хэша, Вы можете ошибаться с тем, какой фрагмент реально будет проверяться по сформированной Вами подписи.

В принципе, где-то здесь на форуме была инструкция как включить отладку проверки подписей в .Net и тогда сможете это наглядно увидеть. Для чистоты примера можете еще прикрепить успешно проверяемую подпись из .NET? Пока опишу примерно что происходит при проверке вышеприведенных подписей из архива.

В продемонстрированном примере (где подпись в отдельном файле и там кроме подписи ничего нет) без указания имени исходного файла такая подпись не сработает. Без enveloped при проверке URI="" вычислится хэш от самой готовой подписи вместо каноничного исходного текста, а с enveloped вычислится хэш от пустой строки вместо каноничного исходного текста. То есть SignatureValue успешно проверится, но DigestValue не совпадет.

Указание только решетки и идентификатора на это не повлияет, так как в файле с подписью нет такого идентификатора, парсер не знает из какого файла взять фрагмент с таким идентификатором и скорее всего выберется пустая строка от которой посчитается хэш. Аналогично SignatureValue успешно проверится, но DigestValue не совпадет.

Итого, если имя файла не указано в URI, то подпись с решеткой + идентификатором и enveloped должна быть в том же файле, что и подписанные данные.

Отредактировано пользователем 25 июня 2020 г. 5:52:31(UTC)  | Причина: Не указана

Offline Dmitrii F  
#28 Оставлено : 25 июня 2020 г. 12:15:07(UTC)
Dmitrii F

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

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

Сказал(а) «Спасибо»: 1 раз
Спасибо за ответ.

Однако, подпись в Net., которая проходит проверку, создаётся, также, откреплённая.
Т.е.

Код:
<Signature><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments"/><SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256"/><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments"/></Transforms><DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"/><DigestValue>BpyqygrUdUmyy66XwYlFYcJyXDxDuK6uONl3b6yskLc=</DigestValue></Reference></SignedInfo><SignatureValue>DwzdGxaoV30hLLlyyaZ+zqkjzJqdY3mNG2LxNXL3eYV33fc1plZSLzeAMpqzEyflD68dXnVhTGr33zDuQ5lx4w==</SignatureValue><KeyInfo><X509Data><X509Certificate>..................</X509Certificate></X509Data></KeyInfo></Signature>


А что Вы думаете об этом?


Offline Dmitrii F  
#29 Оставлено : 28 июня 2020 г. 0:44:48(UTC)
Dmitrii F

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

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

Сказал(а) «Спасибо»: 1 раз
Автор: two_oceans Перейти к цитате
В принципе, где-то здесь на форуме была инструкция как включить отладку проверки подписей в .Net и тогда сможете это наглядно увидеть

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