Загруженный файл tsl не прошел проверку эп
webvoron пишет: Отключены Spider Guard, Spider Mail, Spider Gate, Превентивная защита, самозащита, на всякий случай сайт ЭБ добавлен был в исключения антивируса. Проверили что отключен параметр "Проверять зашифрованный трафик".
папку континента надо добавлять в исключения
вы бы уже в Код безопасности написали по поводу веба, может они что подскажут
хотя врятли ответят по делу, они только слать лесом умеют
Решил не создавать новую тему, а спросить в этой (тем более по смыслу подходит, вроде-бы).
Серт сервера ТЛС для ГОСТ-2001 lk.budget.gov.ru.cer истекает 18.09.2019 . Если не ошибаюсь, после этой даты будет невозможно входить и подписывать сертификатами пользователей по ГОСТ-2001, правильно? Ни у кого в регионах не было каких-либо ЦУ, рожденных в УФК (из ЦАФК тишина, насколько я в курсе), о планах действий в связи с приближающимся днем "Ч"("П")?
Alex_04 пишет: Решил не создавать новую тему, а спросить в этой (тем более по смыслу подходит, вроде-бы).
Серт сервера ТЛС для ГОСТ-2001 lk.budget.gov.ru.cer истекает 18.09.2019 . Если не ошибаюсь, после этой даты будет невозможно входить и подписывать сертификатами пользователей по ГОСТ-2001, правильно? Ни у кого в регионах не было каких-либо ЦУ, рожденных в УФК (из ЦАФК тишина, насколько я в курсе), о планах действий в связи с приближающимся днем "Ч"("П")?
Gvinpin пишет: Только предположения: будет новый сертификат сервера сроком действия до конца года.
"Сумлеваюсь я. " (с) - наврядли будет УЦ ФК заморачиваться с ним на оставшиеся 3 месяца. Поживем - увидим. (а когда доживем - запрыгаем?)
Для тех, у кого Dr.Web: нужно добавить в исключаемые приложения путь C:\Program Files\Security Code\Continent TLS Client\TlsClient.exe
Gvinpin пишет: Только предположения: будет новый сертификат сервера сроком действия до конца года.
"Сумлеваюсь я. " (с) - наврядли будет УЦ ФК заморачиваться с ним на оставшиеся 3 месяца. Поживем - увидим. (а когда доживем - запрыгаем?)
А можно сейчас сделать новые сертификаты сотрудникам по новому ГОСТу, старые аннулировать, работать в ЭБ по новым и не прыгать.
Mischanja пишет: А можно сейчас сделать новые сертификаты сотрудникам по новому ГОСТу.
Так про то и намёк - команды сверху нет и никто не заморачивается, что это грозит очередным авралом в последний момент, когда время будет упущено.
Mischanja пишет: А можно сейчас сделать новые сертификаты сотрудникам по новому ГОСТу, старые аннулировать, работать в ЭБ по новым и не прыгать.
Alex_04 пишет: Так про то и намёк - команды сверху нет и никто не заморачивается, что это грозит очередным авралом в последний момент, когда время будет упущено.
А у вас много осталось именно пользователей ЭБ, работающих еще по старому ГОСТУ?
У нас - аж целых 8, из них у 4-х сертификаты заканчиваются раньше, чем сертификат сервера Континент TLS.
Сервис Проверки Подписи «КриптоПро SVS» позволяет настроить дополнительную проверку соответствия полей сертификата установленной форме, а также проверку того, что сертификат выдан аккредитованным УЦ.
Проверка происходит на основании требований, представленных в Приказе ФСБ РФ от 27 декабря 2011 г. N 795 «Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи» и в соответствии с Федеральным законом "Об электронной подписи" от 06.04.2011 N 63-ФЗ.
Примечание
Выполняемая КриптоПро SVS проверка соответствия сертификата форме СКПЭП не подразумевает выполнения ВСЕХ требований Приказа N 795 и предназначена для выявления наиболее распространенных ошибок в полях сертификата.
Проверка полей сертификата производится на основе следующего списка требований:
- Версия (version). Версия сертификата должна быть не ниже 3.
- Серийный номер (serial number). Проверяется наличие номера и отсутствие в нем недопустимых символов.
- Алгоритм подписи (signature). В поле algorithm, входящем в состав поля signature, должен содержаться идентификатор используемого алгоритма подписи:
- ГОСТ Р 34.10–2012 для ключей длины 256 бит: "1.2.643.7.1.1.3.2", szOID_CP_GOST_R3411_12_256_R3410
- ГОСТ Р 34.10–2012 для ключей длины 512 бит: "1.2.643.7.1.1.3.3", szOID_CP_GOST_R3411_12_512_R3410
- (для архивного хранения и проверки подписи) ГОСТ Р 34.10-2001: "1.2.643.2.2.3", szOID_CP_GOST_R3411_R3410EL
- Для физических лиц — ФИО, СНИЛС, ИНН (CN, SN, G, SNILS, INN).
- Для ИП — ФИО, ОГРНИП, ИНН, СНИЛС (CN, SN, G, OGRNIP, INN, SNILS).
- Для юридических лиц —
- Наименование, местоположение, ОГРН, ИНН ЮЛ (CN, O, C, OGRN, INNLE) – для сертификатов, выпущенных после 1 сентября 2021 г.
- Наименование, местоположение, ОГРН, ИНН (CN, O, C, OGRN, INN) – для сертификатов, выпущенных до 1 сентября 2021 г.
Компоненты имени проверяются на допустимые символы, длину (если такие требования имеются). Для сертификата юридического лица дополнительно могут быть включены следующие требование:
- местоположение (S, L, Street).
- совпадение общего имени и наименования организации (CN=O).
- Открытый ключ (subjectPublicKeyInfo). Проверяется только наличие его в сертификате.
- Дополнения (расширения) сертификата (Extensions). Проверяется только наличие следующих расширений в сертификате.
- Authority Key Identifier, OID.2.5.29.35, идентификатор ключа УЦ.
- Key Usage, OID.2.5.29.15, область использования ключа.
- Certificate Policies, OID.2.5.29.32, политики сертификата. Для данного расширения проверяется содержимое в соответствии с требованиями, указанными в Приказе ФСБ РФ от 27 декабря 2011 г. N 795.
- Subject Sign Tool, OID.1.2.643.100.111, сведения о средстве ЭП владельца сертификата.
- Issuer Sign Tool, OID.1.2.643.100.112, сведения о средствах ЭП УЦ и средствах УЦ.
- ExtendedKeyUsage, OID.2.5.29.37, расширенное использование ключа. Состав дополнения (расширения) зависит от информационной системы, в которой используется сертификат.
- CDP, OID.2.5.29.31, точки распространения списков аннулированных сертификатов (CRL).
- IdentificationKind, OID.1.2.643.100.114, идентификация заявителя.
Проверка сертификата выполняется при помощи специального плагина. Для активации проверки сертификатов необходимо зарегистрировать плагин с помощью Windows PowerShell. После установки SVS плагин находится в директории \DSS\Plugins\CertificatesVerifiers\ и называется SVS.CertificateVerifier.Qualified.dll .
Для настройки проверки того, что сертификаты выпущены аккредитованным УЦ, необходимо задать отпечатки корневых сертификатов Министерства цифрового развития, связи и массовых коммуникаций РФ. Работа с отпечатками производится при помощи командлетов Add-VsQualifiedCAThumbprints, Get-VsQualifiedCAThumbprints и Remove-VsQualifiedCAThumbprints. Если отпечатки не заданы, данная проверка сертификатов проводиться не будет.
Корневые сертификаты должны быть установлены в выделенное хранилище Сервиса Проверки Подписи. Хранилище создается автоматически при установке Сервиса Проверки Подписи и имеет название вида -TSL .
Пример:
Дополнительные параметры плагина:
- LocationCheck – требовать обязательного наличия компонентов имени S, L, Street для сертификата ЮЛ. Возможные значения: true, false. Значение по умолчанию false;
- OrganizationNameStrictCheck – требовать совпадения значений компонентов имени CN и O в сертификате ЮЛ. Возможные значения: true, false. Значение по умолчанию false;
- INNforLECheckMode – режим проверки ИНН в сертификате юридического лица (ЮЛ), выпущенном после 1 сентября 2021 г. Возможные значения: Any, Soft, Strict. Значение по умолчанию Soft.
- Any – требуется присутствие INN и/или INNLE;
- Soft – требуется присутствие INNLE; присутствие INN докускается;
- Strict – требуется присутствие только INNLE.
Для проверки статуса аккредитации УЦ необходимо указать путь к файлу со списком аккредитованных УЦ Tsl.xml в параметре TSLPath.
Загрузка файла Tsl.xml возможна следующими способами:
Файл TSL будет загружен в папку tmp в каталоге утилиты Dss.TslTool.exe.
- при помощи команды wget в консоли Powershell
SVS автоматически отслеживает изменения файла TSL, путь к которому указан в параметре TSLPath. Безопасно скопировать актуальный файл TSL можно с помощью Powershell-скрипта, приведенного ниже. Данный скрипт можно добавить в Планировщик задач Windows и выполнять раз в сутки (или чаще).
Пример скрипта для безопасного копирования TSL:
Настройка выполнения по умолчанию проверки полей сертификата
Проверка соответствия полей сертификата установленной форме при помощи описанного в данном разделе плагина может применяться по умолчанию как в веб-интерфейсе SVS, так и при обращении к SVS с использованием REST API. Для этого в настройках плагина необходимо указать флаг CheckByDefaultRequired .
Пример:
В зависимости от интерфейса SVS данная настройка будет применена следующим образом:
- в веб-интерфейсе SVS - напротив пункта "Проверка требований к квалифицированному сертификату" в разделе "Дополнительные проверки" по умолчанию будет активирован чекбокс. Пользователь может самостоятельно отключить проверку, деактивировав данный чекбокс перед отправкой сертификата на проверку.
- при использовании REST API SVS - параметр зависит от переданного в запросе списка CertVerifiersPluginsIds:
- если список передан - проверка не учитывается, будут применены плагины, указанные в списке;
- если список передан со значением NULL - проверка не учитывается, никакие дополнительные проверки к сертификату применяться не будут;
- если список НЕ передан (отсутствует в запросе) - проверка учитывается, сертификат будет проверен в соответствии с настройками плагина, описанного в данном разделе.
Квалифицированная электронная подпись (КЭП) создается с помощью подтвержденных ФСБ криптографических средств и имеет сертификат от аккредитованного удостоверяющего центра, выступающего гарантом подлинности подписи. Электронный документ, подписанный КЭП, во всех случаях приравнивается законодательством к бумажному документу с собственноручной подписью.
Подтверждение подлинности ЭП сертификата, изданного удостоверяющим центром, входящим в список аккредитованных удостоверяющих центров Министерства цифрового развития, связи и массовых коммуникаций, и квалифицированных подписей через Сервис Проверки Подписи возможно после выполнения следующих условий:
- Корневой сертификат Головного удостоверяющего центра должен быть установлен в хранилище сертификатов SVS.
- Сертификаты подчинённых Удостоверяющих Центров: «УЦ 1 ИС ГУЦ», «УЦ 2 ИС ГУЦ» должен быть установлен в хранилище «Промежуточные Центры Сертификации» локального компьютера
- Сертификат аккредитованного УЦ в режиме подчинения должен быть установлен в хранилище «Промежуточные Центры Сертификации» локального компьютера
- Сервис Проверки Подписи должен иметь возможность проверки статуса сертификата по списку аннулированных сертификатов (CRL) или OCSP-ответу. Для этого необходимо либо установить локально и регулярно обновлять CRL, либо обеспечить доступ с сервера SVS в интернет для возможности загрузки CRL или проверки актуального статуса сертификата по протоколу OCSP.
Для удобства установки всех необходимых сертификатов аккредитованных УЦ и CRL в состав установки КриптоПро SVS включена утилита Dss.TslTool.exe . Утилита предназначена для выполнения следующих действий:
- Загрузка и установка корневого сертификата Головного удостоверяющего центра
- Загрузка TSL (списка аккредитованных УЦ, Trust-service Status List)
- Установка сертификатов подчинённых УЦ, перечисленных в TSL (сертификаты аккредитованных УЦ и сертификаты подчинённых УЦ)
- Загрузки и установки списков аннулированных сертификатов (CRL) аккредитованных УЦ
- Удалению CRL аккредитованных УЦ с истёкшим сроком действия
Утилита распространяется в самораспаковывающемся архиве DssTslTool.exe , который устанавливается в каталог C:\Program Files\Crypto Pro\DSS\VerificationService. Для начала работы с утилитой распакуйте архив:
После распаковки архива внимательно ознакомьтесь со справкой к утилите. Для этого в командной строке перейдите в каталог, куда была распакована утилита, и выполните команду:
Пример базового использования утилиты Dss.TslTool:
- Первоначальная установка всех необходимых сертификатов и CRL:
Примечание
Имя хранилища сертификатов для установки сертификата головного удостоверяющего Центра зависит от имени Веб-приложения SVS. Имя хранилища сертификатов и CRL для установки сертификатов подчинённых удостоверяющих Центров зависит от имени Веб-приложения SVS.
Примечание
При обновлении с версий SVS 2.0.2300 и предыущих рекомендуется очистить хранилище Промежуточные Центры Идентификации Локального компьютера от ранее установленных сертификатов и CRL. Большое количество сертификатов и CRL в данном хранище замедляет как работу SVS, так и системы в целом. Сертификаты подчинённых УЦ и CRL рекомендуется устанавливать в хранилище SVS -CA .
- Обновление сертификатов аккредитованных УЦ и CRL
Примечание
Выполнение данной команды можно добавить в планировщик Windows для регулярного обновления CRL.
В случае если сервер SVS не имеет выхода в интернет, то сертификаты аккредитованных УЦ и CRL могут быть установлены из файла. Для этого на машине, имеющей выход в Интернет, запустите утилиту со следующими параметрами:
После выполнения данной команды в каталог \tmp будут сохранены TSL и CRL. Каталог для сохранения объектов, загруженных из сети, при необходимости может быть изменён.
Примечание
Далее необходимо перенести каталог с загруженными файлами на сервер SVS. Для установки сертификатов аккредитованных УЦ и CRL из файла запустите утилиту со следующими параметрами:
Нужно в параметры запуска chrome.exe добавить ключ
--allow-running-insecure-content
и добавить lk.budget.gov.ru в список разрешённых доменов где можно использовать смешанный контент Например в свойствах ярлыка "ЭБ CG.lnk" добавить в конец через пробел ключChromium GOST и DrWEB не открываются сайты
Помогает запуск с ключом - -no-sandbox. (для х64 версии)
Но лучше использовать х32 версию браузера
У кого Jinn не видит контейнер читаем подробности
(*) С 01.08.2020 lk2012 больше не доступен
Про Jinn Sign Extension Provider
слишком сложно написано
Просьба написать попроще, например что в пути установки не должно быть кириллицы, например имя пользователя написано по-русски (аля Юзер, Пользователь, Админ и прочее) и используется путь установки предложенный установщиком (в папку профиля пользователя)Параметры командной строки для тихой установки Jinn Sign Extension Provider сразу для всех пользователей Windows (путь можете указать свой, лишь бы он был доступен для всех пользователей):
ПРИМЕЧАНИЕ: Командную строку нужно запускать по правой кнопки мыши с выбором "Запуск от имени администратора"
Jinn не видит контейнер
Размер имеет значение (с)
Инструкция по созданию носителя от пользователя 7449
ДОПОЛНЕНИЕ
ОТВЕТ ТЕХПОДДЕРЖКИ УФК
Цитата:
3. Если нужный сертификат не отображается, проверить подключение съемного носителя и нажать кнопку «Обновить список».
5. Далее выбираем, где сохранить криптоконтейнер, можно на этом же съемном носителе (файлы не заменяются) или на любом другом, и указываем пароль оригинального контейнера, нажимаем «Сохранить».
Очень плохая новость для установивших Континент АП 3.7.7.651 с криптопровайдером КБ CSP
Вернул обратно на своём тестовом стенде КАП 3.7.651 с крипто-провайдером от КБ (куда ж теперь без него?)
На этапе подписи заявки в ЭБ при "поиске носителя" получаем: "Прекращена работа программы визуализации и подписи Jinn-Client"
До этого всё подписывало в ЭБ (Win 10.15063x64)update: Ложка мёда в бочку дёгтя: проверяли на win7x32 sp1 такой проблемы нет.
Плохая новость для установивших Континент АП 3.7.7.651 с криптопровайдером КБ CSP
Для правильной установки Континент TLS-клиент». Версия 2 придётся удалять КАП. Вычищать следы пребывание КБ CSP утилитой от кода безопасности тынц с параметрами -to из командной строки от администратора. Так же должен стоять криптопро. Тогда ТЛС клиент не будет пытаться установить или обновить свой криптопровайдер. Потом континент ап можно ставить обратно с его криптопровайдером, все работает. Не забываем удалить
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 1\CryptDllImportPublicKeyInfoEx\1.2.643.7.1.1.1.1
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Cryptography\OID\EncodingType 1\CryptDllImportPublicKeyInfoEx\1.2.643.7.1.1.1.1
из реестра.СКЗИ «Континент TLS-клиент». Версия 2 "Доступ к конфигурационному файлу запрещен"
Британские учёные установили, ошибка СКЗИ «Континент TLS-клиент». Версия 2 "Доступ к конфигурационному файлу запрещен" таки связана с недостатком прав. Все установщики запускать через .ехе а не через .msi и от имени администратора. Если это не помогло. смотрим права на ветку реестра [HKEY_LOCAL_MACHINE\SOFTWARE\SecurityCode]
По логам на проблемной машине видно что идёт обращение к ветке [HKEY_LOCAL_MACHINE\SOFTWARE\SecurityCode], и не может получить доступ туда. Проверил права на ветку - кривые, нет права на запись. Можно выдать права, я полечил просто удалив ветку целиком (но у меня и были имитация установки на чистую, без других компонентов КБ). В общем случае, надо пробовать давать права на ветку Еще добавлю - сегодня под обычным пользователем пытался запустить Континент-TLS дал разрешения в реестре, но при запуске так же ошибку выдавал. Дал разрешение на чтение и запись до каталогов:
c:\Program Files\Security Code\
c:\Users\Public\ContinentTLSClient\
Заработало и под обычным пользователем.Обнаружил машину на которой даже после манипуляций с реестром, после установки TLS клиента всё равно вылетала ошибка по доступу. Вылечилось после следующих манипуляций:
1. Через панель управления удалить ВСЕ продукты КриптоПро и Кода Безопасности, перезагрузка
2. Удаление через cspclean (КП)и cspcleaner -to (КБ), перезагрузка,
3. Удаление следов в ProgramFiles, удаление веток [HKEY_LOCAL_MACHINE\SOFTWARE\SecurityCode] и [HKEY_LOCAL_MACHINE\SOFTWARE\Security Code], перезагрузка
4. Установка КриптоПро 4.0 R4 (4.0.9963), перезагрузка
5. Установка TLS клиента 2.0.1440.
После этого заработало. Замечу, что устанавливать клиент лучше через командную строку с параметрами /install /log log.txt. Если в результате установки появился только один log файл - то установка точно прошла с косяком и работать не будет. Если два файла - то скорее всего всё ок. Если три файла - то к TLS клиенту доставился еще и КБ CSPЕсли кто задумает "хочу установить все заново"
(взято с форума росказны)
Варианты установки программных продуктов
Состав программных продуктов:
* КриптоПро CSP или Валидата CSP;
* Jinn-Client;
* TLS-клиент.Выполните действия в следующем порядке:
1. Установите сторонний криптопровайдер (КриптоПро CSP или Валидата CSP).
2. Установите Jinn-Client. В состав данного продукта входит криптопровайдер "Код Безопасности CSP" версии 3.7, в котором необходимо отменить регистрацию. Загрузите и распакуйте архив по ссылке https://www.securitycode.ru/upload/docu . gScCSP.zip. Перейдите в папку, соответствующую данной платформе (x86 или x64) и запустите файл unreg_sc_37.reg.
3. Установите TLS-клиент. В состав данного продукта входит криптопровайдер "Код Безопасности CSP" версии 4.0, который не будет установлен. В такой ситуации используется сторонний криптопровайдер.Состав программных продуктов:
* КриптоПро CSP или Валидата CSP;
* TLS-клиент.Выполните действия в следующем порядке:
1. Установите сторонний криптопровайдер (КриптоПро CSP или Валидата CSP).
2. Установите TLS-клиент. В состав данного продукта входит криптопровайдер "Код Безопасности CSP" версии 4.0, который не будет установлен. В такой ситуации используется сторонний криптопровайдер.Состав программных продуктов:
* Jinn-Client;
* TLS-клиент.Выполните действия в следующем порядке:
1. Установите Jinn-Client. В состав данного продукта входит криптопровайдер "Код Безопасности CSP" версии 3.7. © КОМПАНИЯ "КОД БЕЗОПАСНОСТИ"
2. Удалите криптопровайдер "Код Безопасности CSP" версии 3.7.
3. Установите TLS-клиент. Он содержит криптопровайдер "Код Безопасности CSP" версии 4.0, который установится автоматически.Отсутствуют сторонние криптопровайдеры (КриптоПро CSP или Валидата CSP) и Jinn-Client.
В данном случае установите TLS-клиент. Он содержит криптопровайдер "Код Безопасности CSP" версия 4.0, который установится автоматически.
Исправление ошибок установки
При нарушении порядка установки выполните действия в следующем порядке:
1. Удалите все программные продукты, входящие в вариант установки.
2. После каждого удаления программного продукта выполните перезагрузку, если она требуется.
3. Установите программные продукты заново в соответствии с описанными вариантами установки.Для подписания в Электронном бюджете в Mozilla Firefox с помощью Jinn-client 1.0.3050.0, рекомендуется использовать версию от 52.9.0esr и выше , необходимо установленное в браузере расширение Jinn Sign Extension, а также установленный в Windows Jinn Sign Extension Provider версии 1.0.0.5. Во избежание появления в firefox ошибки при подписании:
Не удалось обработать
script
Document.GetElementByID(. ).loadCertificates is not a function (TypeError)
необходимо в firefox выполнить следующее:
- В адресной строке firefox ввести about:config
- Установить параметры accessibility.delay_plugins = true; accessibility.delay_plugin_time = 90000
- В браузере включитьплагин Jinn-client (если версия firefox поддерживает плагин - например, как версия 52.9.0esr) и одновременно включить расширение Jinn-client.
Если такая ошибка появилась, то помимо указанных выше настроек необходимо при закрытом firefox удалить, а затем заново установить Jinn sign extension provider версии 1.0.0.5. (Перезагружать компьютер при этом необязательно, куки и кэш желательно удалить).
Так как для браузеров Mozilla Firefox и Google Chrome, в отличие от Internet Explorer 11, при подписании в Электронном бюджете используются ещё расширение Jinn-client и Jinn Sign Extension Provider, то при возникновении ошибок при подписании лучше всего после этого проверять подписание в настроенном для работы в Электронном бюджете Internet Explorer 11.
Извините, но у вас недостаточно прав для комментирования
Комментарии
У меня странная проблема. вход в lk работает, но после добавления ресурса eb.cert.roskazn a.ru при входе выдает ошибку "серверный сертификат не прошел проверку сравнением" и далее "не удалось установить соединение с хостом.."
антивирусов не стоит, брандмауэр отключен(Кто нибудь сталкивался с таким ? как решить ?
Добрый день.
Помогите решить проблему. ЭБ. Рабочее место настроенно. Пользователь пытается подписать документ, но идет бесконечное обращение к контейнеру. Нажимаем отмена, появляется окошко выбора сертификата. Вместо одного сертификата видно два одинаковых. Один при выборе сразу выдает ошибку, второй запрашивает пароль, но после ввода пароля документ остается неподписанным.
Переустановка всех программ и конвертация не помогла.
Tls 2.0 Jinn 1.0.3050 КриптоПро 4.0.9944Это я хорошо знаю. Дело в том что континент TLS в сети где нет прокси сам скачивает их при нажатии кнопки Загрузить. А в сети где через прокси сеть работает пишет что не найдены. Как решить?
В информационном мире и Digital-Банке само собой разумеется – Digital Security и Digital Signature.
Криптография позволяет нам защитить информацию от подмены и однозначно установить ее правообладателя посредством усиленной электронной подписи.
Криптография дает возможность закрыть для посторонних глаз информацию конфиденциального характера с помощью шифрования.
Как применять криптографию в соответствии с законодательством и ладу с регуляторами?
Речь пойдет о правовых аспектах и об организационно-технических мероприятиях в рамках официального перехода на национальные стандарты в области криптографической защиты информации ГОСТ Р 34.11-2012 «Функция хэширования» и ГОСТ Р 34.10-2012 «Процессы формирования и проверки электронной цифровой подписи».
Переход осуществляется в средствах электронной подписи, применяемых для информации, не содержащей сведений, составляющих государственную тайну, в случаях, подлежащих регулированию со стороны ФСБ России в соответствии с действующей нормативной правовой базой.
Правовые аспекты
Сначала, короткая справка, кто и на основании каких правовых документов является регуляторами в данной области.
Федеральным законом от 4 мая 2011 г. № 99-ФЗ «О ЛИЦЕНЗИРОВАНИИ ОТДЕЛЬНЫХ ВИДОВ ДЕЯТЕЛЬНОСТИ» установлен перечень видов деятельности, подлежащих обязательному лицензированию.
Постановлением Правительства РФ № 957 от 21 ноября 2011 г. «ОБ ОРГАНИЗАЦИИ ЛИЦЕНЗИРОВАНИЯ ОТДЕЛЬНЫХ ВИДОВ ДЕЯТЕЛЬНОСТИ» утвержден «ПЕРЕЧЕНЬ ФЕДЕРАЛЬНЫХ ОРГАНОВ ИСПОЛНИТЕЛЬНОЙ ВЛАСТИ, ОСУЩЕСТВЛЯЮЩИХ ЛИЦЕНЗИРОВАНИЕ КОНКРЕТНЫХ ВИДОВ ДЕЯТЕЛЬНОСТИ»
К лицензируемым видам деятельности, которые курирует ФСБ РФ, относятся:
Разработка, производство, распространение шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, выполнение работ, оказание услуг в области шифрования информации, техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств (за исключением случая, если техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, осуществляется для обеспечения собственных нужд юридического лица или индивидуального предпринимателя)
31 января 2014 выходит документ ФСБ России № 149/7/1/3-58 «О порядке перехода к использованию новых стандартов ЭЦП и функции хэширования».
Здесь я позволю себе процитировать выписку из данного документа, которая опубликована на портале ТЕХНИЧЕСКОГО КОММИТЕТА ПО СТАНДАРТИЗАЦИИ «КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ИНФОРМАЦИИ» (ТК 26)
“Для средств ЭП, техническое задание на разработку которых утверждено после 31 декабря 2012 года, должна быть предусмотрена реализация функций средства в соответствии с ГОСТ Р 34.10-2012 хотя бы по одному из определяемых стандартом вариантов требований к параметрам (использование варианта, соответствующего длине секретного ключа порядка 256 бит, является предпочтительным, поскольку обеспечивает достаточный уровень криптографической стойкости и лучшие эксплуатационные характеристики, в том числе при совместной реализации со схемой ГОСТ Р 34.10-2001). После 31 декабря 2013 года не осуществлять подтверждение соответствия средств ЭП Требованиям к средствам электронной подписи, утверждённым приказом ФСБ России от 27.12.2011 г. № 796, если в этих средствах не предусмотрена реализация функций средства в соответствии с ГОСТ Р 34.10-2012 хотя бы по одному из определяемых стандартом вариантов требований к параметрам. Исключение может быть сделано для средств ЭП, удовлетворяющих одновременно следующим условиям:
— техническое задание на разработку средства утверждено до 31 декабря 2012 года;
— в соответствии с техническим заданием разработка средства завершена после 31 декабря 2011 года;
— подтверждение соответствия средства указанным Требованиям ранее не осуществлялось.
Использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2018 года не допускается. ”На кого нацелен этот документ?
- он нацелен в первую очередь на лицензированных разработчиков СКЗИ, которые сертифицируют свои криптографические провайдеры в ФСБ.
- на уполномоченный федеральный орган в области использования электронной подписи и одновременно Головной Удостоверяющий Центр (ГУЦ), которым в соответствии с Федеральным законом № 63 «Об электронной подписи» и Постановлением Правительства РФ №976 от 28.11.2011 является Министерство связи и массовых коммуникаций
- на удостоверяющие центры, которые в соответствии со статьей 16 ФЗ № 63 «Об электронной подписи» получают аккредитацию в ГУЦ «Минкомсвязь»
- на организации, например, Альфа-Банк, которые осуществляют коммерческую деятельность с применением средств криптографической защиты информации.
приведен Перечень выполняемых работ и оказываемых услуг, составляющих лицензируемую деятельность, в отношении шифровальных (криптографических) средств.
Например, пункт из перечня: «2. Разработка защищенных с использованием шифровальных (криптографических) средств информационных систем»
Иными словами организация, которая используя криптографию, взаимодействует с внешним миром и получает от этого прибыль, должна получить лицензию и соблюдать требования регулятора.
В пункте 6 Положения №313 приведены лицензионные требования к организациям лицензиатам.
На этом с правовыми аспектами, которые порой трудно читать, закончим. И перейдем к организационным мероприятиям.
Взаимодействие с регулятором
ГУЦ «Минкомсвязь» имеет свой портал — это своего рода единая точка входа в (Public Key Infrastructure PKI) Инфраструктуру с открытым ключом в масштабах Российской Федерации. Там опубликован большой список нормативных документов, требования и порядок аккредитации удостоверяющих центров, реестр действующих аккредитованных УЦ и информация о доступности их сервисов.
Там же можно скачать XML-представление реестра аккредитованных УЦ
TSL — Trusted List of supervised/accredited Certification Service Providers. Этот список подписан электронной подписью Минкомсвязи, через него выстраивается доверие и пути сертификации.
В целом на площадке Госуслуги развернуто единое пространство Электронного правительства РФ. Большинство сервисов, которого стало возможным благодаря развертыванию национальной PKI и применению криптографии и квалифицированной электронной подписи.
Так, например, в сервисах шины Системы межведомственного электронного взаимодействия СМЭВ используется квалифицированная электронная подпись, сертификаты открытого ключа которой заверены аккредитованными удостоверяющими центрами национальной PKI.
Мое письмо было принято в работу группой ГУЦ-Восход:
Здравствуйте!
В соответствии с выпиской из документа ФСБ России № 149/7/1/3-58 от 31.01.2014 «О порядке перехода к использованию новых стандартов ЭЦП и функции хэширования»,
Где говорится, что использование ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2018 года не допускается и необходимо выполнить переход на новые стандарты ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012Сообщите, пожалуйста, какого плана работы предусмотрены для осуществления перевода инфраструктуры Головного удостоверяющего центра Минкомсвязи России на работу с ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012
Будут ли меняться:
Что будет со старыми типами подписи СМЭВ?
Будет единовременный переход на СМЭВ 3 с новым алгоритмом подписи?И получил следующие ответы:
В связи с тем, что с первого января 2019 года формирование подписи с использованием старых гостов не допускается, все сертификаты, используемые для формирования подписи, будут заменены.
Переход Головного удостоверяющего центра на новые госты планируется в первом полугодии 2018 года, соответственно сертификат ГУЦ Минкомсвязи России будет заменен в это же время.
Сертификаты УЦ 1 ИС ГУЦ и УЦ 2 ИС ГУЦ и сертификат подписи TSL предположительно будут заменены в это же время.Структуру TSL списка менять не планируется.
Согласно вышеописанной выписке, после 1 января 2019 года не допускается формирование подписи на старых ГОСТ, т.е., исходя из нее, дожить они могут, но подписывать ими нельзя. Обязательный отзыв сертификатов на старых ГОСТ пока также не планируется. Перевод своих клиентов на новые ГОСТ аккредитованный УЦ осуществляет самостоятельно, по мере своих возможностей, какого-либо общего порядка по нему не предусмотрено.
По СМЭВ, к сожалению, подсказать не смогу, Головной удостоверяющий центр СМЭВом не занимается. По вопросам, связанным с ним, Вам необходимо создать отдельную заявку в поддержку СМЭВ.
Вопросы касательно СМЭВ я сформулировал в отдельном письме на тот же адрес и оно было маршрутизировано на группу PТК-CМЭВ, а затем команде ПАО «Ростелеком».
Получен такой ответ:
Какое-то время будут поддерживаться оба типа стандартов. Конкретная дата проведения работ в СМЭВ не определена. Участники информационного взаимодействия будут заблаговременно оповещены соответствующей новостью на Технологическом портале, а также всей необходимой информацией.
Вообще СМЭВ и подпись XMLDsig/XAdES это отдельная большая тема.
Постановка задачи
- обеспечить бесперебойную работу собственного программного обеспечения в переходный период.
- выполнить генерацию новых ключей и сертификатов
- проверить программное обеспечение на возможность корректного перехода. Для этого подписать документ новой электронной подписью и проверить ее.
Тем более, почти все необходимое под рукой есть. Сертифицированные СКЗИ, поддерживающие новые алгоритмы КриптоПро CSP 4.0, Java API КриптоПро JCSP и КриптоПро JCP 2.0 есть.
Выполнить генерацию новых ключей можно.
Бесперебойная работа ПО
В Базе знаний портала технической поддержки размещена подробная информация об этих предупреждениях, и как их отключить в версиях СКЗИ под различные операционные системы:
Конечно же, такие уведомления могут быть крайне нежелательны в информационных системах. Где они могут вклиниться в поток, перехватить управление и привести к сбою основной логики программы.
За примером далеко ходить не надо. Возьмем операционную систему Linux, информационную систему на Java и провайдер КриптоПро JCP 2.0, посредствам которого выполняется электронная подпись документов. Если не отключить своевременно уведомления о переходе на новые стандарты, то в информационной системе при попытке подписать документ возникнет ошибка:
Эта ошибка говорит, что провайдер попытался выбросить графическое предупреждение на сервере, где нет графического терминала.В итоге предупреждение приводит к сбою в программе, подпись на документ не ставится.
Разумеется, для информационной системы, где идет поток обращений к провайдеру, запускать сервер X Window System, например, программу Xming на своей станции и подключаться с помощью PuTTY по SSH с включенной опцией X11 forwarding для того, что бы клиент КриптоПро JCP мог отображать все предупреждения на нашу станцию, мы не будем.
Поэтому отключаем уведомления в контрольной панели КриптоПро JCP, следуя инструкции.
Если информационная система на Java использует криптографический провайдер КриптоПро CSP через JavaCSP, то выполняем пункт инструкции:
Для отключения данных предупреждений в КриптоПро CSP до 1 января 2019 года на Unix-системах нужно добавить два ключа в конфигурационный файл /etc/opt/cprocsp/config64.ini (или /etc/opt/cprocsp/config.ini в случае 32-битной системы) в существующую секцию Parameters:
Соответствующие напоминания КриптоПро CSP появляются при генерации ключей и нового запроса на сертификат в UI центра регистрации. Если указать в поле Криптопровайдер — Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider.
Для новой ключевой пары будет появляться окно с предупреждением вида:Его можно отключить на месяц. Или навсегда для криптографического провайдера, действуя по уже знакомой инструкции.
Предупреждения СКЗИ вовремя отключены, они больше не смогут привести к сбою в наших информационных системах.
Получение новых сертификатов
На момент написания статьи УЦ поддерживающий новые стандарты отсутствовал.
Был получен ответ:
Сейчас появилась живая ссылка на тестовый УЦ КриптоПро, поддерживающий ГОСТ 2012.
Помощь с получением сертификатов оказало подразделение информационной безопасности. Был развернут собственный экземпляр тестового центра сертификации, поддерживающий ГОСТ 34.10-2012
Выполнена генерация двух комплектов ключей с размерностями 256 и 512 бит и получены два сертификата, соответствующие новым стандартам ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012.
Подпись документа и проверка
Напомню, в составе КриптоПро JCP можно найти много примеров в файле samples-sources.jar. В частности, там есть примеры подписи и проверки ЭП документов. Все остальное является по большому счету частными кастомизациями.
Провайдеры КриптоПро JCP и JCSP поддерживают следующие нужные нам алгоритмы хэш функции и подписи:
JCSP - CryptoPro Java CSP Provider
JCP - CryptoPro Java ProviderMessageDigest - GOST3411_2012_256
MessageDigest - GOST3411_2012_512Signature - GOST3411_2012_256withGOST3410DH_2012_256
Signature - GOST3411_2012_512withGOST3410DH_2012_512
Как красиво распечатать список установленных и готовых к работе в JVM криптографических провайдеров, поддерживаемых ими функций и реализуемых алгоритмов:
Для того чтобы существующие методы подписи по ГОСТ Р 34.10-2001 начали подписывать документ по ГОСТ Р 34.10-2012, потребовалось внести ряд небольших изменений.Добавить названия новых алгоритмов:
Инициализировать объект подписи с нужным алгоритмом:
Добавить в создаваемый CMS контейнер нужный идентификатор хэш-функции:
CMS может содержать не одну подпись, поэтому в цикле для каждой отдельно указываются идентификаторы алгоритмов хэша и подписи:
В этом же цикле выполняем хэширование:
И здесь же создаем четвертый подписываемый атрибут, содержащий хэш сертификата открытого ключа проверки этой подписи
Это все места, где при подписании нужно указать новый алгоритм.Для проверки подписи в другом классе добавляем названия алгоритмов и новые OID-ы.
Правда, идентификаторы новых алгоритмов пока не добавлены в российский сегмент OID-ов. Переход ведь только грядет. А вот по алгоритмам 2001 года информация есть:
Далее в методе проверки подписи проверяем, что алгоритм хэш-функции, указанный в CMS-контейнере нам знаком:
Выполняем проверку алгоритмов digest-а и signature для каждой подписи внутри контейнера:
Создаем экземпляр объекта хэш по указанному алгоритму в атрибуте подписи. Он нам нужен, чтобы заново посчитать хэш данных и сравнить с переданным в контейнере.
Инициализируем объект класса Signature c соответствующим алгоритмом:
На этом все нюансы программного перехода на стандарты ГОСТ 34.10-2012 и ГОСТ 34.11-2012 исчерпаны.Наше программное обеспечение готово подписывать документы и проверять подписи по новому стандарту с размерностью ключа 256 и 512 бит.
Вот так выглядит структура CMS с новыми идентификаторами алгоритмов в программе ASN1View (разработчик)
Результат проверки подписи PKCS-7 ГОСТ Р 34.11-2012/34.10-2012 256 бит
— в сервисе проверки ЭП на портале Госуслуги
«Подлинность документа не подтверждена», потому что сертификат выдан в тестовом УЦ и Электронное Правительство ничего про него не знает. Сама ЭП — верна.
— с помощью программы КриптоАрм
— в собственном программном обеспечении
Результат проверки подписи PKCS-7 ГОСТ Р 34.11-2012/34.10-2012 512 бит
— в сервисе проверки ЭП на портале Госуслуги
— с помощью программы КриптоАрм
В КриптоАРМ сертификат проверки ЭП считается действительным, потому что корневой сертификат нашего тестового УЦ я добавил в хранилище корневых доверенных центров сертификации своей операционной системы.
Читайте также: