здесь - Ipoteka Bank

Техническое требование к интерфейсам электронного
взаимодействия Центров регистрации ЭЦП
коммерческих банков с единым реестром
сертификатов Центрального банка Республики
Узбекистан
Данное техническое требование разработано с целью взаимодействия Систем
информационной безопасности (СИБ) коммерческих банков с СИБ Центрального банка для:
- создания и взаимодействия единого реестра сертификатов ключей электронных
цифровых подписей платежной системы,
- реализации универсальности формата ключа электронной цифровой подписи,
- создания универсальных криптоконтейнеров в стандарте PKСS#7 (RFC5652 и ASN.1
RFC5911) и обеспечения безопасного приема-передачи, криптографической обработки,
хранения файловой информации в них.
Требование к интерфейсам электронного взаимодействия
с едином реестром сертификатов.
Информационные сервисы единого реестра являются специализированными
модулями и предназначены для обеспечения передачи информации. Информационная
система должна применять сертификаты открытых ключей ЭЦП. Сертификаты открытых
ключей ЭЦП должны выдаваться Центром регистрации ключей ЭЦП коммерческих банков.
При проверке ЭЦП должны проверяться:
- отсутствие искажения в подписанном документе и подтверждение принадлежности
ЭЦП КБ, на серверах которого, была сформирована ЭЦП;
- подлинность ЭЦП и действительность сертификата открытого ключа ЭЦП в момент
подписания документа.
Данные должны передаваться в режиме реального времени. Передаваемые данные,
должны соответствовать требованиям, изложенным в настоящем документе.
Информационные сервисы должны быть разработаны по технологии Web-service с
использованием протокола: SOAP версии 1.2, стиль: document/literalwrapped.
Принцип взаимодействия
Принцип взаимодействия информационных систем следующий:
Система-клиент (ЦРК ЭЦП коммерческого банка) вызывает веб-сервис сервера и
передает необходимую информацию;
Система-сервер (Единый реестр сертификатов ЦБ) принимает информацию и
запускает механизмы автоматической идентификации и последующей обработки
информации;
В случае возникновения ошибок, система возвращает клиенту ответ в установленном
порядке, как это указано в требовании;
Система возвращает клиенту результат выполнения действия в установленном
порядке.
Требование к передаваемой информации
Информация должна передаваться через параметр веб-сервиса в виде документа
XML. Описания структуры передаваемого XML документа должны быть оформлены в виде
XSD схем и содержаться в соответствующих “.xsd” файлах. Описания веб-сервисов должны
быть оформлены на языке WSDL в виде соответствующих “.wsdl” файлов.
В данном документе при описании структур передаваемой информации и входных
параметров веб-сервисов используются следующие простые типы данных:
№
1
Тип
String
2
DateTime
3
4
Int
long
Описание
текстовая информация в кодировке UTF-8
дата и время в формате стандарта X509v3 как у полей NotBefore/NotAfter.
целочисленная информация (4 байтовая)
целочисленная информация не ограниченная по длине
Приведенные выше типы данных являются описательными и могут не совпадать
по наименованию с типами, используемыми в .wsdlи .xsd.
Идентификатор ЦРК ЭЦП КБ содержится в сертификате, 3-е поле идентификатор
ключа субъекта.
Входные параметры веб-сервисов
Все веб-сервисы используемые для передачи информации, в контексте
взаимодействия должны иметь входные параметры указанные далее.
Передача нового сертификата в единый реестр ЦБ
Наименование
параметра
1 MsgID
№
2 MsgDate
3 CaID
Тип
данных
long
DatеTime
long
4 Certfile
String
5 Passport
6 Inn
7 Pinfl
String
String
String
8 SignDate
DatеTime
9 SignThumbprint
String
10 SignOID
String
Обяза- Комментарий
тельно
Да Формируется на стороне отправителя. Десятичное.
Должно быть уникальным на день подачи заявки.
Да Дата подачи заявки.Формат поля как у
NotBefore/NotAfter в стандарте X509v3.
Да Идентификатор ЦРК ЭЦП. Формат Hex.Выдается ЦБ
ДБЗИ для каждого ЦРК.
Да Содержимое сертификата владельца ЭЦП. Формат
base64 без служебных строк начала и конца.
Нет Серия и номер паспорта без пробелов.
Нет Индивидуальный номер налогоплательщика.
Нет Персональный идентификационный номер
физического лица.
Да Дата подписания. Формат поля как у
NotBefore/NotAfter в стандарте X509v3.
Да Отпечаток SHA1 сертификата ЦРК КБ. Формат Hex.
Да
Идентификатор алгоритма ЭЦП ЦРК КБ
String
11 Sign
Да
Значение ЭЦП ЦРК КБ,подсчитанное для полей 1-10.
Формат HЕХ, порядок байтов как в X509v3 для
соответствующего алгоритма подписи. Алгоритм
определяется полем-10. Допустимо, но не
ограничено, применение алгоритмов O’zDSt 1092
(алгоритм II), GOST 34.10-2001, ECC, RSA.
Обновление сведений о состоянии сертификата
№
Наименование
параметра
1 MsgID
2 MsgDate
3 CaID
4 CertThumbprint
5 Status
6 StatusDate
Тип
данных
long
Обязательно
Да
DatеTime
Да
long
Да
String
Да
Int
Да
DatеTime
Да
DatеTime
Да
8 SignThumbprint
String
Да
9 SignOID
String
Да
String
Да
7 SignDate
10 Sign
Комментарий
Формируется на стороне отправителя.
Десятичное. Должно быть уникальным на
день подачи заявки.
Дата подачи заявки.Формат поля как у
NotBefore/NotAfter в стандарте X509v3.
Идентификатор ЦРК ЭЦП. Формат Hex.
Выдается ЦБ ДБЗИ для каждого ЦРК.
Отпечаток SHA1 сертификата ЭЦП. Формат
Hex.
Статус сертификата:
0 - просрочен;
1 - отозван;
2 - приостановлен;
3 - активный (возобновлен).
Дата установки статуса.Формат поля как у
NotBefore/NotAfter в стандарте X509v3.
Дата подписания. Формат поля как у
NotBefore/NotAfter в стандарте X509v3.
Отпечаток SHA1 сертификата ЦРК КБ. Формат
Hex.
Идентификатор алгоритма ЭЦП ЦРК КБ.
Значение ЭЦП ЦРККБ,подсчитанное для
полей 1-9. Формат HEX, порядок байтов как в
X509v3 для соответствующего алгоритма
подписи. Алгоритм определяется полем-9.
Допустимо, но не ограничено, применение
алгоритмов O’zDSt 1092 (алгоритм II), GOST
34.10-2001, ECC, RSA.
Все веб-сервисы используемые для передачи информации, в контексте
взаимодействия ИС, должны иметь следующие выходные параметры:
№ Наименование
параметра
1 Result
2 ReceiptID
Тип
данных
Int
String
Обязательно
String
Нет
DateTime
Нет
Дата отправки(она же дата подписи
квитанции).Формат поля как у
поляNotBefore/NotAfter в стандарте X509v3.
5 SignThumbprint
String
Да
6 SignOID
String
Да
String
Да
Отпечаток SHA1 сертификата уполномоченного
лица ЦРК ЦБ. Формат Hex.
Идентификатор алгоритма ЭЦП уполномоченного
лица ЦРК ЦБ.
Значение ЭЦП уполномоченного лица ЦРК
ЦБ,подсчитанное для полей 1-6. Формат HEX,
порядок байтов как в X509v3 для соответствующего
алгоритма подписи. Алгоритм определяется полем6. Допустимо, но не ограничено, применение
алгоритмов O’zDSt 1092 (алгоритм II), GOST 34.102001, ECC, RSA.
3 Comments
4 SignDate
7 Sign
Да
Нет
Комментарий
Результат действия (код из справочника)
Присвоенный системой идентификационный номер
запроса
Комментарий
Коды результатов действий при вызове web-сервиса
Код
возврата
1
0
2
3
101
102
103
104
201
202
Ошибки
Данные успешно обработаны
Сервис временно не доступен
Ошибка при обработке запроса
Данные уже зарегистрированы в системе
Отсутствие или ошибка подписи
Отозванный сертификат
Истекший сертификат
Сертификат, выданный не признанным сертифицирующим органом
Обязательные данные отсутствуют
Неправильный формат данных
Требование к формату ключа электронной цифровой подписи
№
Наименование требования
Значение
АлгоритмII.
Значения соответствуютRFC-4357 пункт 11.2 (idGostR3411-94-CryptoProParamSet)
Алгоритм II.
1.2.860.1.7.9
Алгоритм II.
ЗначенияпараметровсоответствуютRFC-4357 пункт
8.4, пункт 11.4 (id-GostR3410-2001-CryptoPro-XchAParamSet, id-GostR3410-2001-CryptoPro-XchBParamSet)
1
Блок подстановокфункции
хеширования O’zDSt 1106:2009
2
OID функции хеширования O’zDSt
1106:2009
3
Параметры алгоритма цифровой
подписи (domainparameter)для
функции ЭЦП O’zDST 1092:2009
4
OID’ы для параметров алгоритма
цифровой подписи (domainparameter)
Sign ParamsetOID:1.2.860.1.7.36.0, 1.2.860.1.7.36.1
Digest Sbox OID: 1.2.860.1.7.30.1
5
Формат открытого ключа в ИОК (PKI)
RFC 4491 пункт 2.3.2
6
OIDоткрытого ключа в ИОК (PKI)
1.2.860.1.7.3
7
8
Формат цифровой подписи в ИОК (PKI)
OIDцифровой подписи в ИОК (PKI)
9
Форматы хранения закрытого ключа
иесли имеются, национальные OID‘ы
RFC 4491 пункт 2.2.2
1.2.860.1.7.5
Для ОС Linux:
PKCS#8, форматы совместимые с библиотекой
openssl.
Для ОС Windows:
закрытый формат CNGкриптопровайдера
Форматы хранения связки закрытого
10 ключа с сертификатом и если имеются,
национальные OID‘ы
PKCS#12
11
Форматы хранения закрытого ключа на
токенах
PKCS#8,
внутренний формат производителя iKey, eToken
12
Форматы хранения связки закрытого
ключа с сертификатом на токенах
PKCS#12, внутренний формат производителя iKey,
eToken
Требование к формату ключа электронной цифровой подписи и
к поддерживаемым криптографическим провайдерам в системах защиты
информации коммерческих банков
Для подписания (шифрования) и проверки ЭЦП электронных документов с
использованием сертификатов различных стандартов (O’zDSt 1092 алгоритм II, O’zDSt 1106
алгоритм II, GOSTR-34.10-2001, GOSTR-34.11-94, GOST28147-89, RSA и т.п.) в программном
комплексе защиты информации должна быть учтена работа с внешними
криптографическими провайдерами с интерфейсом Microsoft CryproAPI CNG (Microsoft®
Cryptography Next Generation).
№
Наименование требования
Значение
Алгоритм II.
Значения соответствуют RFC-4357 пункт 11.2 (idGostR3411-94-CryptoProParamSet)
Алгоритм II.
1.2.860.1.7.9
Алгоритм II.
Значения параметров соответствуют RFC-4357 пункт
8.4, пункт 11.4 (id-GostR3410-2001-CryptoPro-XchAParamSet, id-GostR3410-2001-CryptoPro-XchBParamSet)
1
Блок подстановок функции
хеширования O’zDSt 1106:2009
2
OID функции хеширования O’zDSt
1106:2009
3
Параметры алгоритма цифровой
подписи (domainparameter)для
функции ЭЦП O’zDST 1092:2009
4
OID’ы для параметров алгоритма
цифровой подписи (domainparameter)
Sign ParamsetOID:1.2.860.1.7.36.0, 1.2.860.1.7.36.1
Digest Sbox OID: 1.2.860.1.7.30.1
5
Формат открытого ключа в ИОК (PKI)
RFC 4491 пункт 2.3.2
6
OID открытого ключа в ИОК (PKI)
1.2.860.1.7.3
7
8
Формат цифровой подписи в ИОК (PKI)
OID цифровой подписи в ИОК (PKI)
9
Форматы хранения закрытого ключа и
если имеются, национальные OID‘ы
RFC 4491 пункт 2.2.2
1.2.860.1.7.5
Для ОС Linux:
PKCS#8, форматы совместимые с библиотекой
openssl.
Для ОС Windows:
закрытый формат CNG криптопровайдера
Форматы хранения связки закрытого
10 ключа с сертификатом и если имеются,
национальные OID‘ы
11
Форматы хранения закрытого ключа на
токенах
PKCS#12
PKCS#8,
внутренний формат производителя iKey, eToken
12
Форматы хранения связки закрытого
ключа с сертификатом на токенах
PKCS#12, внутренний формат производителя iKey,
eToken
Программы систем защиты информации должны работать c поддержкой
криптографических алгоритмов O’zDSt 1092 (алгоритм II), O’zDSt 1106 (алгоритм II), GOSTR34.10-2001,GOSTR-34.11-94, GOST28147-89.
Требование к Операционным системам
Linux: x64 RHEL 6, CentOS 6 или выше.
Windows:x64 Vista или выше (7,8,8.1,10, 2008,2008R2,2012,2012R2).
Интеграция
Программный комплексы по защиты информации должны быть совместимым с
Удостоверяющим центрам коммерческого банка и Центрального банка РУз.