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

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline zlovrednaya_dgo  
#1 Оставлено : 22 марта 2022 г. 16:48:39(UTC)
zlovrednaya_dgo

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

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

Пытаюсь реализовать на клиентской части шифрование для ФСС.
Вследствие изысканий по подписанию оказалось, что для плагина не все так сложно как на форуме пишут=)
Лично у меня сформировать математически корректную подпись руками (с RawSignature и хэшами) не удалось.. Спасло подписание XML по шаблону oSignedXML.Sign(oSigner). Поэтому предположила что на js реализация шифрования тоже может быть проще, чем кажется.

Обзор темы:
Предполагается использовать:
Вариант 1. CPEnvelopedData https://docs.cryptopro.r...om_class/cpenvelopeddata
ИЛИ
Вариант 2. использовать SymmetricAlgorithm https://docs.cryptopro.r...class/symmetricalgorithm

Вариант 1 oEnvelopedData.Encrypt выдает ответ в котором включены данные в ASN.1( шифрованные данные и сессионный ключ в hex. тут человек говорит, что этот метод не делает как нужно для фсс - т.е. не генерит сессионный ключ, т.е. вероятно этот вариант не подходит и прикладывает исходники на с которые он прикрутил к своему коду.
В документации метода же указана что сессионный ключ генерится:
Цитата:
The Encrypt method generates a session key, uses that key to encrypt the contents, envelops the encrypted content for each recipient by encrypting the session key with each recipient's public key, and then returns the BLOB that contains the encrypted contents and the encrypted session keys as an encoded string.



Вариант 2 работает со следующими параметрами:
IV - вектор инициализаци
DiverseData - данные диверсификации ключа. Что такое диверсификация ключа и необходимы ли они для ФСС алгоритма - непонятно.
ExportKey - ключи (вероятно, согласования), которые почему-то всегда одинаковые, что здесь, что в дефолтной в утилите шифрования от крипто про (UPD - они все-таки разные!!!).
Вот параметры Export Key
Цитата:
1.Компонент является результатом выполнения CryptGetKeyParam(KP_CIPHEROID).
2.Эфемерный открытый ключ, который использовался для выработки ключа обмена. Компонент является результатом выполнения CryptExportKey(PUBLICKEYBLOBEX).
3.Симметричный ключ, зашифрованный на ключе обмена. Компонент является результатом выполнения CryptExportKey(SIMPLEBLOB).

и сами зашифрованные данные.

По идее из этих данных нужно получить ключ структуры вот такой (https://lapo.it/asn1js/#MIGpMCgEINeJQo4go2GVXm61yd8N4sexMqgMQyW9wOmGDiDse1vyBARiF_Ff[…]qu-lrBVBSG2D3FZQqwexkmg3GkXevCEettqzfdiTOLCIxatBAjxlNtjmaUsYw)
и к данным возможно прибавлять IV перед отправкой.


Главный вопрос: можно ли получить из структуры варианта 2 (из IV,DiverseData и ExportKey) сессионный ключ в формате, который можно будет передать в ФСС? Есть ли идеи как это сделать и как тут можно применить или не нужно DiverseData?

Отредактировано пользователем 23 марта 2022 г. 14:43:44(UTC)  | Причина: Не указана

Offline zlovrednaya_dgo  
#2 Оставлено : 22 марта 2022 г. 23:14:56(UTC)
zlovrednaya_dgo

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

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

пока попробую вариант 1
Код:
var oEnvelopedData = yield cadesplugin.CreateObjectAsync("CAdESCOM.CPEnvelopedData");
            yield oEnvelopedData.propset_Content(toChipher);
            var oRecipients = yield oEnvelopedData.Recipients;
            yield oRecipients.Add(oCertSignature);
            var encMessage = yield oEnvelopedData.Encrypt(cadesplugin.CADESCOM_ENCODE_BASE64);



В пермененной encMessage:
- похоже на сессионный ключ


- полагаю, что зашифрованные данные располагаются здесь. Непонятно они с идентификаторами должны быть переданы или нет

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

Offline zlovrednaya_dgo  
#3 Оставлено : 23 марта 2022 г. 13:44:34(UTC)
zlovrednaya_dgo

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

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

Пробую из зашифрованного CPEnvelopedData вытащить данные и ключ (шаг 1), преобразовать (шаг 2) и добавить в XML (шаг 3). Потом отправляю в ФСС (шаг 4)

шиг 1
1.1 вытаскиваю сессионный ключ (SesKey)
1.2 вытаскиваю IV (IV)
1.3 зашифрованные данные (CipherData)
вот эти данные все

шаг 2
2.1 соединяю данные CipherDataSum = 'IV' + 'CipherData' (как строки суммирую)
2.2 преобразовываю HEX to BASE64 п.2.1 и отдельно SesKey

шаг 3
3.1 Собираю XML
- сессионный ключ(SesKey) идет в EncryptedKey - KeyInfo - CipherData - CipherValue
- CipherDataSum идет в EncryptedKey - CipherData - CipherValue
- На место сертификата добавляю серт ФСС
получаю файл encryptedfile.xml (24kb) загружен 6 раз(а).

шаг 4
отправляю в ФСС на тестовый контур https://eln-test.fss.ru/...OperationsLnService?WSDL

В ответ получаю ошибку:
Цитата:
oap:Serverru.fss.integration.ws.fault.v01.InternalException: Не удалось расшифровать сообщение. Возможно сообщение зашифровано на ключе отличном от ключа уполномоченного лица ФСС. Проверьте правильность и актуальность ключа уполномоченного лица ФСС.



Что может быть не так в последовательности 1-3?
Offline two_oceans  
#4 Оставлено : 28 марта 2022 г. 10:49:14(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 394 раз в 366 постах
Добрый день.
Коллега, ссылаться на сообщения 2-летней давности не много смысла: ФСС уже с тех пор поменяли немного спецификацию. Теперь там используется еще и эфемерная ключевая пара. Есть в одной из тем подправленный для Дельфи.

Смысл в том, что при отправке теперь "наш" контейнер вообще не нужен. Примерно так:
1) Генерируется дополнительная "эфемерная" ключевая пара, закрытый ключ из нее (вместо "ключа из постоянного контейнера") и открытый ключ сертификата адресата идут на получение ключа согласования; открытый ключ будет прикреплен к зашифрованному сессионному ключу;
2) (как и при обычном методе) генерируется сессионный ключ (ТК26); сессионный ключ шифруется ключом согласования; повторяется для каждого следующего сертификата получателя - если отправителю нужно потом читать сообщение, то и в адрес отправителя тоже;
3) данные шифруются сессионным ключом;
4) в сообщение идет сертификат получателя (то есть не заменяем - сертификат ФСС), зашифрованный сессионный ключ (+ открытый ключ эфемерной пары в том же блоке BASЕ64), зашифрованные данные;
5) сообщение отправляется, а эфемерная пара уничтожается.

ФСС по сертификату находит свой закрытый ключ, комбинирует с открытым ключом эфемерной пары из сообщения = ключ согласования. Ключом согласования расшифровывается сессионный ключ. Сессионным ключом расшифровываются данные.

Поэтому скорее всего дело в "не таком" содержимом ключа (операции 1 не совсем те или ключ не ТК26 или вырезали мало/много).
Offline zlovrednaya_dgo  
#5 Оставлено : 28 марта 2022 г. 14:29:27(UTC)
zlovrednaya_dgo

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

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

В сообщении №3 этой темы вероятно была проблема с используемым сертификатом...
Также для ФСС 2.0 нужен сертификат ФСС в шифрованном сообщении + сертификат отправителя внутри подписанного сообщения в Header->X509Certificate.


Теперь у меня новая ошибка:

Вот так делаю шифр:
данные предварительно кодирую в base64

Код:
            var oEnvelopedData = yield cadesplugin.CreateObjectAsync("CAdESCOM.CPEnvelopedData");
            yield oEnvelopedData.propset_ContentEncoding(cadesplugin.CADESCOM_BASE64_TO_BINARY);
            yield oEnvelopedData.propset_Content(toChipher64);
            var oRecipients = yield oEnvelopedData.Recipients;
            yield oRecipients.Add(oCertSignature);
            var encMessage = (yield oEnvelopedData.Encrypt()).replace(new RegExp('(\r|\n)','g'),'');


Отсюда вытаскиваю данные (как и в сообщ.3).
Формирую XML и отправляю в ФСС.
cpenveloped encrypted.xml (16kb) загружен 6 раз(а).

Результат - ошибка:
Цитата:
ru.fss.integration.ws.fault.v01.InternalException: Error in execution of data encrypting/decrypting operation. class org.apache.xml.security.encryption.XMLEncryptionException


Вот тут вот предположили, что ключ верный а данные - нет. Не знаю на сколько это верное предположение.
Offline two_oceans  
#6 Оставлено : 29 марта 2022 г. 8:27:02(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 394 раз в 366 постах
Цитата:
В сообщении №3 этой темы вероятно была проблема с используемым сертификатом...
Ну по крайней мере, собрано было с сертификатом ФСС. Хотя да, не тот сертификат адресата как раз бы дало такую ошибку, как и несколько других причин.

Сюда смотрели? Думаю, данным проектом как раз можно проверить расщифрование сообщения, если конечно зашифровать в адрес какого-то своего сертификата, а не для ФСС.
В подпапке архива есть еще и примеры защифрованного сообщения. По сборке XML на первый взгляд все верно.
Если смотреть только по длине - ключ длиной 232 символа в base64, с 2 заполнителями, то есть 172 байта в двоичном виде. В том проекте ключ как раз собирается в структуру длиной 172 байта (файл Crypto.pas), то есть как минимум по длине с ключом все нормально. Дальше надо смотреть на идентификаторы алгоритмов в блобе ключа и взаимное расположение частей, если они также совпадают, то ключ скорее всего верен и насчет него можно не волноваться. С другой стороны, если алгоритмы не те, то дело может быть именно в них.

Ошибка в расшифровке и "неверные данные" - есть свобода для перебора.
Суть в чем - если большая часть сообщения все же расшифруется верно тем проектом, то ключ точно верен, но надо смотреть на паддинг и IV. IV дает артефакты в начале (хорошо видно на XML когда вначале мусор 8 символов и/или съедены первые 8 символов), паддинг - артефакты в конце. Артефакты могут повторятся через 1024 байта. Съеденные 8 символов - признак, что IV вообще отсутствует.
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.