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

Уведомление

Icon
Error

2 Страницы<12
Опции
К последнему сообщению К первому непрочитанному
Offline Михаил К.  
#21 Оставлено : 15 октября 2019 г. 11:42:47(UTC)
Михаил К.

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

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

Сказал «Спасибо»: 1 раз
Еще вдогонку вот что у меня получается после шифрования ключа:
https://lapo.it/asn1js/#

Как я понял, вот это вектор инициализации:
OBJECT IDENTIFIER 1.2.643.2.2.21 gostCipher (GOST 28147-89 (symmetric key block cipher))
SEQUENCE (2 elem)
OCTET STRING (8 byte) ECCCB62C6F797C0D


А вот это данные:
OBJECT IDENTIFIER 1.2.643.2.2.31.1 cryptoProCipherA (CryptoPro params A (default, variant 'Verba-O') for GOST 28147-89)
[0] (32 byte) 930C0B9EEB04CE3896A6026C85E466F40297EAD51E65E622F41B23B001626CAA


Хотя смущает надпись (default, variant 'Verba-O')....
Offline two_oceans  
#22 Оставлено : 15 октября 2019 г. 13:44:51(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 68 раз
Поблагодарили: 238 раз в 224 постах
Автор: Михаил К. Перейти к цитате
Т.е. алгоритм такой: формирую случайный ключ, шифрую на нем данные запроса, потом применяю паддинг к ключу, шифрую его на открытой части сертификата ФСС. Получаю данные в формате ASN.1(PKCS7). Разбираю их и необходимые куски вставляю в итоговый XML?
Если все так, то вот еще вопросы: есть ли требования к формированию ключа? Шифровать на нем данные надо до применения к нему паддинга? или после? И надо ли применять паддинг к данным, которые шифрую на ключе?
Паддинг прежде всего добавляется к данным, а не к ключу. Сам сессионный ключ и так по длине кратен 8 байтам, то есть паддинг не нужен, шифрование самого ключа проходит без паддинга симметричным алгоритмом и длина "зашифрованного сессионного ключа" не меняется, а "обвязка ключа" наложенная после шифрования сессионного ключа (блоб ключа) не выравнивается. Схема обмена ключей гост "немного сложнее".
Цитата:
Хотя смущает надпись (default, variant 'Verba-O')....
Да, меня тоже она смущает, ведь у ключа параметры TK26Z, надо наверно стандарты полистать или попробовать скормить утилитам работающим через крипто апи. Данные не коротковаты?

Offline Михаил К.  
#23 Оставлено : 15 октября 2019 г. 16:00:15(UTC)
Михаил К.

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

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

Сказал «Спасибо»: 1 раз
Автор: two_oceans Перейти к цитате
Автор: Михаил К. Перейти к цитате
Т.е. алгоритм такой: формирую случайный ключ, шифрую на нем данные запроса, потом применяю паддинг к ключу, шифрую его на открытой части сертификата ФСС. Получаю данные в формате ASN.1(PKCS7). Разбираю их и необходимые куски вставляю в итоговый XML?
Если все так, то вот еще вопросы: есть ли требования к формированию ключа? Шифровать на нем данные надо до применения к нему паддинга? или после? И надо ли применять паддинг к данным, которые шифрую на ключе?
Паддинг прежде всего добавляется к данным, а не к ключу. Сам сессионный ключ и так по длине кратен 8 байтам, то есть паддинг не нужен, шифрование самого ключа проходит без паддинга симметричным алгоритмом и длина "зашифрованного сессионного ключа" не меняется, а "обвязка ключа" наложенная после шифрования сессионного ключа (блоб ключа) не выравнивается. Схема обмена ключей гост "немного сложнее".
Цитата:
Хотя смущает надпись (default, variant 'Verba-O')....
Да, меня тоже она смущает, ведь у ключа параметры TK26Z, надо наверно стандарты полистать или попробовать скормить утилитам работающим через крипто апи. Данные не коротковаты?



Ага, стало понятнее про ключ.
А вот с шифрованием не совсем! Дело в том, что я реализую шифрование в SAP, а там это встроенный функциональный модуль (который просто передает данные в КриптоПро через специальную прослойку), на вход которому я подаю свой случайный ключ, и идентификатор ключа(сертификата) из личного хранилища (в данном случае ФСС). И на выходе получаю бинарные данные в формате PKCS7. Никаких векторов инициализации я не создаю и не передаю. По всей видимости КриптоПро это делает за меня.
Вот я и пытаюсь понять, могу я использовать стандарт SAP и просто потом парсить выходные данные и раскладывать их в запрос. Или же надо что-то свое стороннее делать и вызывать из SAP этот функционал.

Offline Eugeny  
#24 Оставлено : 11 марта 2020 г. 10:56:44(UTC)
Eugeny

Статус: Новичок

Группы: Участники
Зарегистрирован: 10.10.2016(UTC)
Сообщений: 2

Сказал(а) «Спасибо»: 1 раз
Добрый день!

Я пытаюсь отправить запрос в ФСС для получения данных по электронному больничному листу.
Использую SSF (версия SSF 1.0.118832, CSP 5.0.11455).
Дайджест составляю с помощью SSF_DIGEST, подпись SSF_SIGN, в формате RAW_GOST, хэш-алгоритм GOST2012-256.

Заметил, что формат RAW_GOST_INVERTED выдает то же значение, что и RAW_GOST (проверил на SSF_DIGEST). Почему так?
Какой все-таки формат нужен? Хотя пробовал вручную поменять порядок байт подписи на обратный, не помогло.

Получаю из ФСС ответ:
ORA-20001: Некорректная подпись головной организации: ЭЦП неверна. INVALID_SIGNATURE ЭП недействительна. Обратитесь к разработчику программного обеспечения, на котором осуществлялось подписание данных.

Подскажите, в какую сторону копать? Что еще можно и как проверить? (дайджест проверил на примере из ФСС-спецификации - совпадает для алгоритма GOST3411, порядок тэгов совпадает, сам xml-аргумент каноникализирован).
Offline two_oceans  
#25 Оставлено : 11 марта 2020 г. 11:38:57(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 68 раз
Поблагодарили: 238 раз в 224 постах
Добрый день! Сложно сказать без самого файла. Тег Signature как формируете, если получаете RAW_GOST?

Гадание на кофейной гуще: в файле может быть несколько подписей к разным фрагментам файла и возможно перепутали какой фрагмент к какой подписи должен относиться.

ФСС проверяет подписи несколько странно и в обход некоторых деталей стандартов: рекомендуемые атрибуты невалидны по стандартам, но их приходится использовать. Кстати, посмотрите что у Вас получилось в итоге, не исказился ли исходный текст (раз уж он "заранее каноникализирован").

Еще теоретически ФСС в своей реализации проверки вполне может взять фрагмент не смотря на reference URI (взять тот который должен быть подписан по мнению ФСС) и в этом случае выдаст что неверная ЭП, даже если у Вас подпись верна, но верна для другого фрагмента. Перепроверьте еще раз что нигде не спутали, какой именно фрагмент подписывается подписью с определенным actor .

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

Offline Eugeny  
#26 Оставлено : 11 марта 2020 г. 12:36:08(UTC)
Eugeny

Статус: Новичок

Группы: Участники
Зарегистрирован: 10.10.2016(UTC)
Сообщений: 2

Сказал(а) «Спасибо»: 1 раз
Пример очень элементарный (1 набор данных, 1 подпись, 1 актор). Данные вообще взяты из примера спецификации самой ФСС.
Весь запрос и SignedInfo во вложении.
for_sign.xml (1kb) загружен 9 раз(а). XML_PI_to_FSS.XML (4kb) загружен 13 раз(а).

SignatureValue формирую вызовом SSF_SIGN. На входе формат RAW_GOST, хэш-алгоритм GOST2012-256, мой сертификат, в качестве данных для подписи - тэг SignedInfo.

Отредактировано пользователем 11 марта 2020 г. 12:40:39(UTC)  | Причина: Не указана

Offline two_oceans  
#27 Оставлено : 11 марта 2020 г. 16:42:26(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 68 раз
Поблагодарили: 238 раз в 224 постах
Проверка: значение хэша в референсе совпадает с действительным, значение хэша от SignedInfo не проверяется по SignatureValue и сертификату.

Проверяем глазами SignedInfo и выходит что for_sign.xml не каноничен, не хватает определения пространства имен у корневого тега фрагмента. Должно быть:
Код:
<SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
Фрагмент должен быть самодостаточным и содержать все объявления использованных пространств имен. Собственно для SignedInfo как правило одно пространство, если нет заковыристых трансформов с параметрами. Это достаточно частая ошибка, так как если был тег с префиксом, парсер бы указал что в "куске" документа ("кусок", а не "фрагмент", потому что получен строковыми операциями) префикс неопределен, но тут тег без префикса и парсер считает что это пространство имен по умолчанию, а не пространство имен "http://www.w3.org/2000/09/xmldsig#", соответственно при каноникализации куска ошибки не выдалось, но в собранном документе каноническая форма будет уже с пространством имен. Кстати, почему в подписанном документе объявление пространства имен в SignedInfo есть? Добавили после подписания (при сборке) и тем самым нарушили подпись?

Рекомендую сделать SignedInfo (и дочерние теги) с тем же префиксом ds что и Signature. Работает конечно и с разными, но могут быть такие недетектируемые коллизии.

Отредактировано пользователем 11 марта 2020 г. 16:48:38(UTC)  | Причина: Не указана

thanks 1 пользователь поблагодарил two_oceans за этот пост.
Eugeny оставлено 12.03.2020(UTC)
Offline Михаил К.  
#28 Оставлено : 12 марта 2020 г. 11:56:18(UTC)
Михаил К.

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

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

Сказал «Спасибо»: 1 раз
Добрый день.
А не поможете "правильно" привести тег <ROW> к каноническому виду, а то все некорректная подпись...
row_.xml (2kb) загружен 4 раз(а).
Offline Михаил К.  
#29 Оставлено : 12 марта 2020 г. 14:59:06(UTC)
Михаил К.

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

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

Сказал «Спасибо»: 1 раз
Автор: Михаил К. Перейти к цитате
Добрый день.
А не поможете "правильно" привести тег <ROW> к каноническому виду, а то все некорректная подпись...
row_.xml (2kb) загружен 4 раз(а).


Отвечу сам себе (разобрался за полдня). Вот такой должен быть тег <ROW>: template_canonical_row_new.xml (2kb) загружен 7 раз(а).
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
2 Страницы<12
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.