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

На Делфи 7 разрабатываю взаимодействие с ФСС. Какие прошёл этапы

1. Через WsdlImp.exe удалось сформировать pas-файл для Сервиса Страхователя с подписанием данных FSSWSInsurer.pas. Немного допилив, проект стал нормально компилиться.
2. Пообщавшись с техподдержкой, удалось получить образцы xml-запросов, посылаемых на сервер ФСС, и ответы от них.
3. Установил VipNet, создал тестовый сертификат для подписывания запросов, установил необходимые корневые сертификаты для создания нужной цепочки.
4. Дальше стал шаманить. Для начала убедился в том, что отправка в ФСС готового запроса из п.2 проходит без каких-либо ошибок, и удаётся получить ответ.
5. А дальше уже идёт сама работа на Делфи. Тестовый сертификат установлен в хранилище "Личное". Параметры.

Алгоритм подписи: ГОСТ Р 34.10/34.11-2001
Хэш-алгоритм подписи: ГОСТ Р 34.11-94
Открытый ключ: ГОСТ Р 34.10-2012/512
Алгоритм отпечатка: sha1

5.1. Открываю локальное хранилище CertOpenStore, через CertEnumCertificatesInStore получаю список всех сертификатов, из которого потом выбираю данный сертификат.
5.2. Функциями CryptAcquireContext, CryptCreateHash, CryptHashData, CryptGetHashParam формирую хэш-сумму тэга Body.
5.3 Функциями CryptAcquireCertificatePrivateKey, CryptCreateHash, CryptSignHash(вычисление размера), CryptSignHash (подписывание хэша) подписываю хэш-сумму тэга SignedInfo, меняю порядок байт на противоположный, кодирую по Base64.
5.4. Далее через Base64 кодирую буфер сертификата pbCertEncoded.

5.5. Всё это вставляется в соответствующие места xml-запроса: <DigestValue></DigestValue>, <SignatureValue></SignatureValue>, <BinarySecurityToken></BinarySecurityToken>, после чего он посылается в ФСС.

И сейчас получаю вот такой ответ:

ORA-20001: Отсутствует подпись головной организации
stacktrace:
Ошибка при проверке ЭЦП. java.security.InvalidKeyException: Invalid key typealgorithm = 1.2.643.7.1.1.1.1, params unparsed, unparsed keybits =
0000: 04 40 5A 22 51 08 50 A1 8C 02 DB 2F F1 40 04 00 .@Z"Q.P..../.@..
0010: 95 6E E6 82 85 FC 88 E4 62 44 D7 FD 66 03 98 0E .n......bD..f...
0020: 24 D1 54 CF 4E FF FF 08 80 C7 A6 EF 82 31 F5 9C $.T.N........1..
0030: C4 21 C4 67 66 27 D8 2E C5 33 90 5E 72 B6 28 1D .!.gf'...3.^r.(.
0040: CF EA ..

stacktrace:

И теперь пытаюсь понять, с чем связана такая ошибка. Может кто-нибудь подсказать?

С уважением, Александр.

sql2012Shuraken,

Могу подсказать...
Почему ГОСТ-2012 используется?
Они уже на нём?

Тех.поддержка сказала, что да, они работают с ним.

Я формировал и сертификат с открытым ключом по ГОСТ Р 34.10-2001 (512Bits), но там возникла проблема на этапе формирования хэш-суммы тэга Body, не создаётся хэш.



CALG_GR3410EL взят из wincryptex, равен 11811.

Подставляю вместо CALG_GR3410EL CALG_GR3411 (хоть это и неправильно), тогда всё формируется, но при отправке запроса сервис ФСС возвращает ошибку: ЭЦП неверна. INVALID_SIGNATURE ЭП недействительна.

sql2012Shuraken,

'Infotecs Cryptographic Service Provider', PROV_RSA_FULL
CALG_GR3410EL взят из wincryptex, равен 11811.

1) Не прописывать имена CSP
2) Использовать правильные типы CSP
3) CALG_GR3410EL - точно он нужен?

1. Имя я прописал здесь, чтобы было понятно, о чём идёт речь. Наверняка это важно. В коде у меня стоит nil и вместо PROV_RSA_FULL стоит 1.
3. По крайней мере именно эта константа была прописана в идентификаторах алгоритма криптопровайдера . Говорю же, что подставлял и другие константы для работы что с этим сертификатом, что с другими, и с ними всё работало, но там были другие ошибки, о которых я написал ранее.

sql2012Shuraken,

CALG_GR3410EL - это идентификатор алгоритма ЭП по ГОСТ Р 34.10-2001.

А хочешь хеш получить (CryptCreateHash)... Вот и не пускает - 2148073480=0x80090008 = "Invalid Algorithm Specified"

Суть уловил. Сюда надо подставить CALG_GR3411, то же самое сделать и для подписывания SignedInfo, и т.д. Это я делал. Почему же тогда вылезает ошибка при получении ответа от ФСС "ЭЦП неверна. INVALID_SIGNATURE ЭП недействительна."?

sql2012Не судьба запросить у ОС по имени CSP его тип? Он разве 1 ... ?
Подбирать можно долго, как и путать алгоритмы хеширования и подписи...

1. А как это сделать?
2. Да, согласен, мой косяк. Увидел знакомые цифирки в идентификаторе 34.10-2001, обрадовался и подставил, не обратив внимания, за что он отвечает.

sql2012У самого получилось проверить то, что отправляешь?
Сторонний софт подтверждает корректность (для начала - хеша)?

До этого ещё не дошёл. Как это можно проверить?

sql2012,
благодарю за советы. Проверка показала, что данные неправильно подписываются. Потихоньку разбираюсь.

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

Допустим ЭЦП формируется сертификатом с таким алгоритмом подписи: ГОСТ Р 34.11-2012/34.10-2012 256 бит и таким хэш-алгоритмом подписи: ГОСТ Р 34.11-2012 256 бит. В этом случае, в блоке SignedInfo будет такая запись:
<SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256"/>
...
<DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"/>

Если же ЭЦП формируется сертификатом вот с такими параметрами:
Алгоритм подписи: ГОСТ Р 34.11/34.10-2001
Хэш-алгоритм подписи: ГОСТ Р 34.11-94

То в блоке SignedInfo будет уже такая структура:

<SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001-gostr3411"/>
...
<DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411"/>

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