. Порядок идентификации и аутентификации
23.1. Требования к идентификационной информации, включаемой в состав сертификата
23.1.1. Типы имен
Идентификационные данные владельцев сертификатов, а также идентификационные данные УЦ службы ДТС, указываемые в сертификатах, должны представлять собой отличительное имя (DN), закодированное в соответствии с Рекомендациями Х.500. Отличительное имя должно быть уникальным в рамках УЦ службы ДТС.
Состав и формат компонентов отличительного имени должны соответствовать рекомендациям Х.501
Требования к компонентам имени (к идентификационной информации владельца сертификата) приведены в таблице 1.
Таблица 1
Имя DN предлагается лицом, представляющим заявление в УЦ службы ДТС. Если данное имя соответствует общим требованиям и является уникальным, т.е. не совпадает с DN другого владельца сертификата, уже зарегистрированного в УЦ службы ДТС, то оно принимается в качестве идентификационных данных и заносится в УЦ службы ДТС при регистрации владельца сертификата.
Для обеспечения уникальности имени DN операторы УЦ службы ДТС могут добавлять различительные символы в компонент CN отличительного имени.
23.1.2. Анонимные сертификаты
УЦ службы ДТС не выпускает анонимные сертификаты. В качестве псевдонимов используются наименования служб и сервисов.
23.2. Процедуры идентификации и аутентификации пользователей УЦ службы ДТС и первоначальной регистрации
Регистрация пользователей УЦ службы ДТС осуществляется, когда физическое лицо, подающее заявление на выпуск сертификата, не имеет ни одного действительного сертификата, выданного УЦ службы ДТС.
После успешной проверки предоставленных данных заявитель вносится в список уполномоченных пользователей УЦ службы ДТС и получает парольную фразу для оперативной идентификации при запросе на отзыв. Заявление на выпуск сертификата обрабатывается и осуществляется выпуск сертификата.
Процедура идентификации определяется утвержденными руководителем УЦ службы ДТС политиками сертификатов.
23.2.1. Порядок идентификации и аутентификации при запросе сертификата сервера сервиса подтверждения подлинности ДТС
При подаче заявления на выпуск сертификата идентификация заявителя осуществляется только при личном обращении в УЦ службы ДТС. Заявитель обязан предоставить следующие документы:
заявление на выпуск сертификата на бумажном носителе;
паспорт физического лица, предоставляющего заявку на сертификат;
доверенность на право получения сертификата, выданную организацией – оператором ДТС на имя заявителя;
копию приказа или выписку из приказа по организации о назначении ответственного за эксплуатацию программно-аппаратного комплекса (далее – ПАК) ДТС, заверенную руководителем организации.
Если паспорт, удостоверяющий личность заявителя, является подлинным и фотография в документе является фотографией предъявителя, а заявитель входит в список уполномоченных лиц ДТС (представленный ранее оператором ДТС по электронной почте), то заявитель считается аутентифицированным.
Полномочия заявителя считаются подтвержденными, если подписи и печати организации на доверенности и копии приказа (выписке) являются подлинными (либо доверенность заверена нотариально в соответствии с национальным законодательством), а организация, выдавшая доверенность, входит в перечень организаций – операторов ДТС.
Проверка подлинности документов производится в соответствии с приложением № 2 к настоящему Регламенту.
23.2.2. Порядок идентификации и аутентификации при запросе сертификата сервиса проверки статуса сертификата
При подаче заявления на выпуск сертификата идентификация заявителя осуществляется только при личном обращении в УЦ службы ДТС. Заявитель обязан предоставить следующие документы:
заявление на выпуск сертификата на бумажном носителе;
паспорт физического лица, предоставляющего заявку на сертификат;
доверенность на право получения сертификата СПСС, выданную организацией – оператором УЦ службы ДТС на имя заявителя;
копию приказа или выписку из приказа по организации о назначении ответственного за эксплуатацию СПСС, заверенную руководителем организации.
Если паспорт, удостоверяющий личность заявителя, является подлинным и фотография в документе является фотографией предъявителя, то заявитель считается аутентифицированным.
Полномочия заявителя считаются подтвержденными, если подписи и печати организации на копии приказа (выписке) являются подлинными (либо доверенность заверена нотариально в соответствии с национальным законодательством), а организация, выдавшая доверенность, входит в перечень организаций – операторов ДТС.
Проверка подлинности документов производится в соответствии с приложением № 2 к настоящему Регламенту.
23.2.3. Порядок идентификации и аутентификации при запросе сертификата сервиса штампов времени
При подаче заявления на сертификат СШВ идентификация заявителя осуществляется только при личном обращении в УЦ службы ДТС. Заявитель обязан представить следующие документы:
заявление на выпуск сертификата на бумажном носителе;
паспорт физического лица, предоставляющего заявку на сертификат;
доверенность на право получения сертификата СШВ, выданную оператором ДТС на имя заявителя;
копию приказа или выписку из приказа по организации о назначении ответственного за эксплуатацию СШВ (или ПАК ДТС), заверенную руководителем организации.
Если паспорт, удостоверяющий личность заявителя, является подлинным и фотография в документе является фотографией предъявителя, то заявитель считается аутентифицированным.
Полномочия заявителя считаются подтвержденными, если подписи и печати организации на доверенности копии (выписке) приказа являются подлинными (либо доверенность заверена нотариально в соответствии с национальным законодательством), заявитель назначен ответственным за эксплуатацию СШВ (ПАК ДТС), а организация является оператором СШВ (ПАК ДТС).
Проверка подлинности документов производится в соответствии с приложением № 2 к настоящему Регламенту.
23.2.4. Идентификация и аутентификация при обновлении ключей
Идентификация и аутентификация при подаче заявления на выпуск сертификата при плановой смене ключей производится в порядке, аналогичном порядку первоначальной идентификации, описанному в данном пункте настоящего Регламента, в зависимости от политики сертификата.
23.2.5. Идентификация и аутентификация при подаче запроса после отзыва сертификата
Идентификация и аутентификация при подаче запроса после отзыва сертификата производится в порядке, аналогичном порядку первоначальной идентификации, описанном в данном пункте настоящего Регламента, в зависимости от политики сертификата.
23.2.6. Идентификация и аутентификация при отзыве сертификата
Аутентификация при подаче запроса на отзыв осуществляется по парольной фразе, выдаваемой в процессе первоначальной регистрации. Для оперативной обработки запроса на отзыв владелец сертификата при обращении в УЦ службы ДТС должен назвать свои имя, фамилию, должность и парольную фразу.
Если идентификационные данные владельца сертификата, содержащиеся в базе данных УЦ службы ДТС, и выданная парольная фраза совпадают с указанными при обращении, то владелец сертификата считается аутентифицированным и запрос на отзыв передается на обработку.
При подаче запроса на отзыв с использованием съемного носителя аутентификация пользователя осуществляется путем проверки ЭЦП запроса.
Если идентификационные данные владельца сертификата содержатся в базе данных УЦ службы ДТС и ЭЦП в сообщении верна, то пользователь считается аутентифицированным и запрос обрабатывается.
. Технические средства безопасности
32.1. Генерация и установка ключевой пары
32.1.1. Генерация ключевой пары
Ключевая пара УЦ службы ДТС генерируются на автоматизированном рабочем месте (АРМ) администратора в соответствии с эксплуатационной документацией. Генерация ключей УЦ осуществляется администратором сертификации совместно с администратором информационной безопасности УЦ службы ДТС.
Ключевые пары СПСС и СШВ УЦ службы ДТС генерируются на сервере УЦ в соответствии с эксплуатационной документацией. Генерация ключей УЦ осуществляется администратором сертификации УЦ службы ДТС.
Ключевые пары СПП и СШВ ДТС национальных сегментов и интеграционного сегмента интегрированной системы генерируются непосредственно на сервере ДТС уполномоченным сотрудником оператора ДТС в соответствии с эксплуатационной документацией на подсистему ДТС.
Для генерации ключей в УЦ и ДТС Комиссии используется доверенное вычислительное устройство средств ЭЦП (ДВУ ЭЦП). Для защиты сохраняемой ключевой информации дополнительно используются специально подготовленные USB-flash носители.
Для инициализации ключа ЭЦП в ДВУ кроме наличия информации, хранимой в ДВУ, дополнительно требуется ввод пароля доступа и данных, хранимых на USB-flash носителе.
32.1.1.1. Предоставление личного ключа ЭЦП пользователю
УЦ службы ДТС не имеет доступ к ключам ЭЦП пользователей, так как в соответствии с настоящим Регламентом каждый пользователь самостоятельно осуществляет генерацию ключевой пары.
32.1.1.2. Передача ключа проверки ЭЦП в УЦ службы ДТС
Пользователь осуществляет самостоятельную генерацию ключей и передает в УЦ службы ДТС ключ проверки ЭЦП в составе файла запроса на сертификат в электронном виде с использованием электронных носителей.
32.1.1.3. Предоставление ключа проверки ЭЦП доверяющим сторонам
Предоставление ключа проверки ЭЦП УЦ службы ДТС доверяющим сторонам осуществляется путем публикации сертификата ключа проверки ЭЦП, содержащего ключ проверки ЭЦП, в репозитории УЦ службы ДТС.
Все сертификаты, выданные УЦ службы ДТС включают расширение AuthorityInformationAccess, содержащее ссылку на файл корневого сертификата УЦ службы ДТС, опубликованного в репозитории УЦ службы ДТС.
32.1.2. Размеры ключей
В соответствии с эксплуатационной документацией на используемые средства ЭЦП размеры ключей составляют:
длины ключей электронной цифровой подписи:
ключ электронной цифровой подписи – 512 бит;
ключ проверки электронной цифровой подписи – 1024 бит.
длины ключей, используемых при шифровании:
симметричный ключ – 256 бит.
32.1.3. Параметры генерации ключа проверки ЭЦП и проверка качества ключей
Для генерации ключей пользователи УЦ службы ДТС используют ДВУ. Ключевым носителем при этом является SSD-диск из состава ДВУ. В качестве ключевых носителей также используются индивидуальные ключевые USB-носители.
Параметры генерации ключа проверки ЭЦП задаются используемым средством ЭЦП автоматически.
Алгоритм генерации ключей соответствует ГОСТ Р 34.10-2021 согласно Решению Коллегии ЕЭК от 2.06.16 №49ДСП.
При получении запроса на сертификат УЦ службы ДТС проверяет полученный в запросе ключ на совместимость с используемым средством ЭЦП, его разрядность, а также его уникальность. При совпадении полученного ключа с уже имеющимся в базе данных УЦ службы ДТС отклоняет запрос и уведомляет пользователя, подавшего запрос с повторным ключом, о необходимости генерации новой ключевой пары и запроса на сертификат.
32.1.4. Цели использования ключей
Способ применения ключа определен в поле KeyUsage стандартных расширений сертификата, соответствующего X.509 v3.
Ключ ЭЦП уполномоченного лица УЦ службы ДТС может использоваться только для формирования ЭЦП в выпускаемых сертификатах (бит 5 keyCertSign) и СОС (бит 6 cRLSign).
Ключи конечных пользователей используются для формирования ЭЦП. Использование каждого бита в поле KeyUsage соответствует правилам, изложенным в RFC 5280.
32.1.5. Защита ключа ЭЦП уполномоченного лица УЦ службы ДТС
Ключ ЭЦП уполномоченного лица (администратора сертификации) УЦ службы ДТС хранится в защищённом (зашифрованном) виде в ДВУ ЭЦП АРМ администратора УЦ службы ДТС.
Для инициализации в ДВУ ЭЦП ключа уполномоченного лица требуется последовательный ввод ключевых носителей администраторов УЦ (с вводом паролей доступа) и наличие служебных данных, хранимых на SSD-диске из состава ДВУ.
Ключ ЭЦП уполномоченного лица в период эксплуатации (от момента его создания до момента уничтожения) находится в ДВУ ЭЦП и не может быть отчужден на какие-либо внешние носители (функция депонирования ключей ДВУ ЭЦП не поддерживается).
32.1.6. Стандарты криптографического модуля
Форматы ключей и криптографические операции, выполняемые аппаратным криптографическим модулем, соответствуют стандартам ГОСТ Р 34.10-2021 и ГОСТ Р 34.11-2021.
32.1.7. Депонирование ключей ЭЦП
УЦ службы ДТС не осуществляет депонирование ключей ЭЦП.
32.1.8. Резервная копия ключа ЭЦП
УЦ службы ДТС не осуществляет резервирование ключей ЭЦП.
32.1.9. Хранение ключа ЭЦП по окончании срока действия
Ключ ЭЦП по окончании срока действия подлежит удалению с использованием штатных функций средств ЭЦП и средств УЦ службы ДТС.
32.1.10. Создание и уничтожение ключа ЭЦП УЦ службы ДТС
Ключ ЭЦП уполномоченного лица УЦ службы ДТС постоянно находится в ДВУ с момента его создания и до его удаления при выводе из эксплуатации.
32.1.11. Хранение ключа ЭЦП в криптографическом модуле
Ключ ЭЦП уполномоченного лица УЦ службы ДТС хранится в аппаратном криптографическом модуле в зашифрованном виде.
32.1.12. Способ активации ключа ЭЦП
Ключ ЭЦП уполномоченного лица УЦ службы ДТС инициализируется при последовательном предъявлении съемных ключевых носителей администраторов УЦ (с вводом паролей доступа) и наличии служебных данных, хранимых на SSD-диске из состава ДВУ.
32.1.13. Резервное копирование репозитория
Репозиторий УЦ службы ДТС подвергается периодическому резервному копированию в соответствии с порядком резервного копирования, установленным в УЦ службы ДТС.
32.1.14. Сроки действия сертификатов и ключей
Сроки действия ключей ЭЦП и сертификатов ключей проверки ЭЦП определяются эксплуатационной документацией используемого средства ЭЦП.
Сроки действия ключей и сертификатов УЦ службы ДТС:
максимальный срок действия ключей ЭЦП – до 3 лет;
максимальный срок действия ключей проверки ЭЦП – до 7 лет.
Сроки действия ключей и сертификатов пользователей:
максимальный срок действия ключа ЭЦП – до 3 лет;
максимальный срок действия ключа проверки ЭЦП – до 7 лет.
32.1.15. Данные активации
Для ключей ЭЦП УЦ службы ДТС в качестве данных активации выступают:
данные, считываемые ДВУ с USB-flash носителя;
пароли доступа к USB-flash носителю;
служебные данные, хранимые на SSD-диске ДВУ.
I. общие положения
1. Настоящий Регламент устанавливает порядок взаимодействия участников инфраструктуры открытых ключей, использующих сертификаты, выданные удостоверяющим центром службы доверенной третьей стороны (ДТС) интегрированной информационной системы Евразийского экономического союза (далее соответственно – УЦ службы ДТС, интегрированная система), описание основных процедур и организационно-технических мероприятий, используемых УЦ службы ДТС при выпуске сертификатов ключей проверки электронной цифровой подписи (электронной подписи) (далее – ЭЦП), сопровождения указанных сертификатов, форматы данных и протоколы работы.
Настоящий Регламент подготовлен в соответствии с рекомендациями RFC 3647. “Certificate Policy and Certification Practices Framework” (Рекомендации по политике выдачи сертификатов и сертификационным практикам).
1.1. Наименование документа и идентификация
Наименование документа: Регламент удостоверяющего центра службы доверенной третьей стороны интегрированной информационной системы Евразийского экономического союза.
Сокращенное наименование: Регламент УЦ службы ДТС.
1.2. Участники инфраструктуры открытых ключей интегрированной системы
В соответствии с Рекомендацией МСЭ-Т X.509 “Информационные технологии – Взаимосвязь открытых систем – Справочник: Структуры сертификатов открытых ключей и атрибутов” под инфраструктурой открытых ключей интегрированной системы (далее – ИОК) понимается инфраструктура, способная поддерживать управление открытыми ключами для поддержки услуг аутентификации, шифрования, целостности или фиксации авторства в рамках единого пространства доверия Союза.
1.2.1. Удостоверяющий центр
УЦ службы ДТС – отдел в составе Департамента информационных технологий Евразийской экономической комиссии (далее – Комиссия), осуществляющий функции по обеспечению сертификатами ключей проверки ЭЦП для взаимодействия уполномоченных ДТС интеграционного сегмента Комиссии и национальных сегментов государств – членов Союза (далее – государства-члены).
К основным функциям УЦ службы ДТС относятся:
регистрация доверенной третьей стороны Комиссии и доверенных третьих сторон государств-членов;
создание и выдача сертификатов ключей проверки ЭЦП по запросам доверенной третьей стороны Комиссии и доверенных третьих сторон государств-членов;
определение полномочий лиц, выступающих от имени доверенной третьей стороны Комиссии или доверенных третьих сторон государств-членов при обращении за получением сертификата ключа проверки ЭЦП, и хранение информации об указанных полномочиях в соответствии с утверждаемыми Комиссией документами, регламентирующими функционирование удостоверяющего центра службы доверенной третьей стороны;
подтверждение владения ключом ЭЦП, который соответствует ключу проверки ЭЦП, указанному соответствующей доверенной третьей стороной в запросе на создание и получение сертификата ключа проверки ЭЦП, и отказ в создании указанного сертификата в случае отрицательного результата при подтверждении владения данным ключом;
установление сроков действия сертификатов ключей проверки ЭЦП. Сертификат ключа проверки ЭЦП действует с момента его выдачи, если иная дата начала действия такого сертификата не указана в самом сертификате, при этом информация о сертификате ключа проверки ЭЦП должна быть внесена удостоверяющим центром службы доверенной третьей стороны в реестр выданных, прекративших действие и аннулированных сертификатов ключей проверки ЭЦП (далее – реестр сертификатов) не позднее указанной в нем даты начала действия такого сертификата;
прекращение действия и аннулирование сертификатов ключей проверки ЭЦП;
ведение реестра сертификатов с включением в него информации, содержащейся в выданных удостоверяющим центром службы доверенной третьей стороны сертификатах ключей проверки ЭЦП, а также информации о дате прекращения действия или аннулирования таких сертификатов и об основаниях прекращения действия или аннулирования;
ведение списка прекративших действие и аннулированных сертификатов ключей проверки ЭЦП (далее – список отозванных сертификатов);
уведомление владельца сертификата ключа проверки ЭЦП об аннулировании его сертификата до внесения соответствующих изменений в реестр сертификатов и список отозванных сертификатов;
проверка уникальности ключей проверки ЭЦП в реестре сертификатов и отказ в создании сертификата ключа проверки ЭЦП случае отрицательного результата проверки уникальности ключа проверки ЭЦП, указанного в запросе доверенной третьей стороны Комиссии или доверенной третьей стороны государства-члена;
актуализация информации, содержащейся в реестре сертификатов и списке отозванных сертификатов, а также ее защита от неправомерного доступа, уничтожения, модификации, блокирования и иных неправомерных действий;
хранение информации, внесенной в реестр сертификатов, в течение всего срока деятельности удостоверяющего центра службы доверенной третьей стороны;
доступ на безвозмездной основе доверенной третьей стороны Комиссии и доверенных третьих сторон государств-членов к реестру сертификатов с использованием средств интегрированной системы в любое время;
осуществление проверок ЭЦП по обращениям доверенной третьей стороны Комиссии или доверенных третьих сторон государств-членов;
создание штампов времени на квитанциях доверенной третьей стороны Комиссии и квитанциях доверенных третьих сторон государств-членов при обращении таких доверенных третьих сторон с целью подтверждения времени создания электронных документов и их подписания соответствующей ЭЦП;
осуществление иной деятельности, связанной с управлением выданными сертификатами ключей проверки ЭЦП.
1.2.2. Пользователи инфраструктуры открытых ключей
Пользователи инфраструктуры открытых ключей (ИОК) делятся на две категории: владельцы сертификатов и доверяющие стороны.
Владельцами сертификатов ключей проверки ЭЦП, выдаваемых УЦ службы ДТС, являются следующие субъекты (осуществляющие генерацию ключевых пар, формирование запроса на получение сертификата, установку на своем рабочем месте сертификата УЦ службы ДТС и другие операции в соответствии с правами и обязанностями владельцев сертификатов ключей проверки ЭЦП):
доверенная третья сторона Комиссии;
доверенные третьи стороны государств-членов (уполномоченные организации – операторы соответствующих сервисов);
УЦ службы ДТС.
Операции, связанные с формированием криптографических ключей, формированием запросов на изготовление сертификатов ключей проверки электронных цифровых подписей (электронных подписей), получением сертификатов ключей проверки электронных цифровых подписей (электронных подписей), получением запросов на прекращение действия и аннулирование сертификатов ключей проверки электронных цифровых подписей (электронных подписей) от имени указанных владельцев сертификатов ключей проверки электронных цифровых подписей (электронных подписей) выполняют уполномоченные лица, полномочия которых подтверждаются в порядке, описанном в пункте 23.2 настоящего Регламента.
Владельцы сертификатов ключей проверки ЭЦП при проведении процедур проверки ЭЦП других пользователей ИОК являются доверяющими сторонами, запрашивающими в УЦ службы ДТС информацию о статусе сертификатов и открытых ключей (полагаясь на нее при проверке ЭЦП и принятии решения о подлинности электронного документа).
Других доверяющих сторон в ИОК интеграционного сегмента интегрированной системы нет.
1.2.2.1. Доверенная третья сторона Комиссии и доверенные третьи стороны государств-членов
Совокупность сервисов ДТС, функционирующих в составе интеграционного сегмента Комиссии и национальных сегментов государств-членов, обеспечивающих единое трансграничное пространство доверия ЭЦП при электронной форме взаимодействия субъектов средствами интегрированной информационной системы Союза, представляет собой единую службу ДТС интегрированной информационной системы (далее – служба ДТС).
В рамках службы ДТС сервисы ДТС предоставляются государствами-членами в лице ДТС государств-членов и Комиссией в лице ДТС Комиссии.
Операторами сервисов ДТС государств-членов являются уполномоченные органы или определенные (аккредитованные) ими организации.
Оператором сервисов ДТС Комиссии является Комиссия.
Основными задачами службы ДТС в рамках интегрированной системы являются:
подтверждение подлинности и актуальности электронных документов и ЭЦП субъектов информационного взаимодействия – владельцев сертификатов, выпущенных удостоверяющими центрами рамках интегрированной системы, в фиксированный момент времени;
обеспечение гарантий доверия в международном (трансграничном) обмене электронными документами;
обеспечение правомерности применения ЭЦП в исходящих и (или) входящих электронных документах в соответствии с законодательством государств-членов и актами Комиссии.
Сертификат сервера сервиса ДТС (сертификат сервера СДТС) включается в состав квитанций и запросов и используется для проверки ЭЦП в данных квитанциях и запросах, а также идентификации сервера сервиса ДТС.
1.2.2.2. Сервис штампов времени
В инфраструктуре открытых ключей интегрированной системы реализованы сервисы штампов времени. Сервисы штампов времени генерируют штампы времени в соответствии с рекомендациями RFC 3161 (Time-Stamp Protocol) – протоколом штампов времени. Каждый штамп времени удостоверяется исключительно при помощи ключей ЭЦП, созданных специально для сервисов штампов времени.
1.2.2.3. Сервис проверки статуса сертификата
В инфраструктуре открытых ключей интегрированной системы, кроме метода проверки статуса сертификата по списку отозванных сертификатов, предоставляется сервис по проверке статуса сертификата в онлайн-режиме (OCSP). Все ответы сервиса проверки статуса сертификата подписываются при помощи ключей ЭЦП, созданных специально для сервиса проверки статуса сертификата.
1.2.3. Использование сертификатов
Сертификаты, выпускаемые УЦ службы ДТС, используются операторами ДТС в целях обеспечения функционирования службы ДТС.
Области использования сертификатов зависят от политик, в соответствии с которыми выданы сертификаты, утверждаемых руководителем УЦ службы ДТС.
УЦ службы ДТС выдает сертификаты в соответствии со следующими политиками сертификатов ключей проверки ЭЦП:
сертификаты ключей проверки ЭЦП сервиса сертификации УЦ службы ДТС (далее – сертификаты уполномоченных лиц УЦ, корневые сертификаты УЦ);
сертификаты ключей проверки ЭЦП сервера сервиса ДТС (СДТС);
сертификаты ключей проверки ЭЦП сервиса проверки статуса сертификата (СПСС);
сертификаты ключей проверки ЭЦП сервиса штампов времени (СШВ).
Сертификаты ключей проверки ЭЦП уполномоченных лиц УЦ службы ДТС предназначены для проверки электронных цифровых подписей сертификатах и списках отозванных сертификатов (далее – СОС).
Сертификаты ключей проверки ЭЦП сервера СДТС предназначены для проверки ЭЦП в квитанциях и идентификации сервера сервиса ДТС. Сертификаты ключей проверки ЭЦП сервера СДТС также используются для проверки подписи запросов на выпуск и отзыв сертификатов, поступающих в УЦ службы ДТС от операторов ДТС.
Сертификаты ключей проверки ЭЦП СПСС предназначены для проверки электронных цифровых подписей в ответах, выдаваемых сервисом проверки статусов сертификатов.
Сертификаты ключей проверки ЭЦП СШВ предназначены для проверки электронных цифровых подписей в штампах времени, выдаваемых сервисом штампов времени, интеграционного и национальных сегментов интегрированной системы.
Не допускается использование сертификатов, выданных УЦ службы ДТС, не предусмотренное политиками, утверждаемыми руководителем УЦ службы ДТС, в соответствии с которыми выпущен сертификат, предусмотренный согласно приложению № 1.
Ii. перечень услуг уц службы дтс
2. Для обеспечения услуг УЦ службы ДТС, предоставляемых в соответствии с перечнем основных функций, предусмотренных пунктом 1.2.1 настоящего Регламента, в УЦ службы ДТС реализованы следующие функциональные компоненты (сервисы):
сервис сертификатов;
сервис штампов времени;
сервис проверки статуса сертификата;
сервис регистрации;
сервис сертификации;
система защиты информации;
средства ЭЦП.
Сервис сертификатов обеспечивает доступ к реестру сертификатов ключей проверки ЭЦП и спискам отозванных сертификатов со стороны ДТС национальных сегментов государств-членов и ДТС Комиссии.
Сервис штампов времени предоставляет для ДТС национальных сегментов государств-членов и ДТС Комиссии интерфейс для получения штампов времени при выполнении операций формирования ЭЦП.
Сервис проверки статуса сертификата предоставляет для ДТС национальных сегментов государств-членов и ДТС Комиссии возможность проверки статуса сертификата без запроса списков аннулированных сертификатов в режиме реального времени с использованием протокола OCSP.
Сервис регистрации предоставляет возможность регистрации запросов на выдачу и изменение статуса сертификатов. Сервис обеспечивает хранение регистрационных данных ДТС национальных сегментов государств-членов и ДТС Комиссии, запросов на создание сертификатов ключей проверки ЭЦП.
Сервис сертификации обеспечивает хранение эталонной базы сертификатов ключей проверки ЭЦП и списков аннулированных сертификатов. Сервис используется для формирования ключей ЭЦП, записи ключевой информации на ключевые носители, создания и обработки запросов на изготовление и изменение статуса сертификатов ключей проверки ЭЦП, создания сертификатов ключей проверки ЭЦП и списков аннулированных сертификатов.
Система защиты информации обеспечивает защиту, в том числе криптографическую защиту конфиденциальной информации, обрабатываемой и сохраняемой на технических средствах УЦ, в том числе при резервном копировании.
Средства ЭЦП обеспечивают функции генерации пар ключей ЭЦП, хранения ключевой информации, проверки ЭЦП, генерации ЭЦП, отображения подписываемой и проверяемой информации.
Для обеспечения указанных услуг в УЦ службы ДТС в УЦ службы ДТС выделены следующие доверенные роли, которые может выполнить одно или несколько лиц:
руководитель УЦ службы ДТС – осуществляет общую координацию деятельности УЦ службы ДТС, организует работы по разработке и совершенствованию нормативных актов в области функционирования УЦ службы ДТС, использованию средств ЭЦП;
уполномоченное лицо УЦ службы ДТС (администратор сертификации) – обеспечивает хранение и использование ключа ЭЦП УЦ службы ДТС, принимает участие в разработке нормативной базы УЦ службы ДТС и использованием средств ЭЦП, разрабатывает планы по обеспечению СДТС Комиссии сертификатами в соответствии с их потребностями, организует работы по разбору конфликтных ситуаций, проводит процедуры подтверждения подлинности ЭЦП в электронных документах по обращениям владельцев сертификатов, подтверждения подлинности ЭЦП уполномоченного лица УЦ службы ДТС в созданных сертификатах ключей проверки ЭЦП;
администратор информационной безопасности УЦ службы ДТС, должностные обязанности которого включают организацию работ по использованию СКЗИ, участие в выработке инструкций для пользователей, обеспечение доведения инструкций и необходимой документации на СКЗИ (в том числе организация периодического контроля целостности установленного ПО СКЗИ), контроль за исполнением их требований.
Средствами удостоверяющего центра реализуются следующие обязательные роли:
системный администратор, в полномочия которого входит администрирование специального ПО на сервере удостоверяющего центра и автоматизированном рабочем месте администратора;
администратор безопасности, обеспечивающий защиту информации и настройку средств защиты;
администратор сертификации, в полномочия которого входит создание сертификатов ключей проверки ЭЦП и списков отозванных сертификатов ключей проверки ЭЦП;
администратор аудита, в полномочия которого входят контроль системных событий и событий средств защиты информации по журналам аудита, а также разбор конфликтных ситуаций.
Одна функциональная роль может быть закреплена за одним или несколькими сотрудниками. Возможно закрепление нескольких функциональных ролей за одним сотрудником при соблюдении условия, что общее количество персонала УЦ службы ДТС не менее 2 человек.
По решению руководства Комиссии численность работников, выполняющих обязанности по эксплуатации УЦ службы ДТС, может быть увеличена пропорционально количеству и сложности решаемых задач.
Планирование сроков действия crl
Это всё было о составе списков отзыва для каждого ЦС. Теперь следует определить сроки:
- На какой срок следует публиковать список отзыва?
- Как долго информация в нём может считаться достоверной и достаточно актуальной?
Здесь тоже можно применить подход в зависимости от условий эксплуатации. Риск отзыва промежуточного ЦС весьма низкий, следовательно, нет смысла слишком часто публиковать пустой CRL. В современной практике применяются следующие типовые значения по сроку действия CRL для ЦС, которые выписывают сертификаты только другим ЦС:
Для подчиненных ЦС схема такая же. Поскольку риск отзыва клиентских сертификатов высокий, то можно предположить и высокую частоту отзыва. Следовательно, таким ЦС следует выполнять публикацию списков отзыва гораздо чаще, а для экономии трафика комбинировать базовые и дифференциальные CRL.
Можно понять желание администраторов уменьшить это время (в идеале – мгновенно), чтобы клиенты не признавали отозванный сертификат действительным. Однако, уменьшение одного риска приводит к увеличению другого риска. Представьте, что по какой-то причине отказал сервер ЦС в момент, когда предыдущий CRL близок к истечению срока действия, а новый CRL невозможно опубликовать.
Microsoft CA по умолчанию уже закладывает некоторый резерв по времени на непредвиденные случаи и когда распространение списков отзыва по всем точкам публикации занимает некоторое время (например, вызваны латентностью репликации). Этот резерв в английской терминологии называется CRL overlap.
Это достигается использованием двух полей в списке отзыва: Next CRL Publish и Next Update. Поле Next CRL Publish указывает на время, когда ЦС опубликует обновлённый список отзыва (автоматически). Next Update указывает на время, когда срок действия текущего списка истечёт.
Поле Next Update будет всегда выставлен на несколько позднее время, чем Next CRL Publish. Другими словами, ЦС опубликует обновлённый список отзыва до истечения срока предыдущего. Алгоритм вычисления автоматических значений для этих полей нетривиален и описан в следующей статье:
How ThisUpdate, NextUpdate and NextCRLPublish are calculated (v2). Если значения по умолчанию вас не устраивают по тем или иным причинам, их можно отредактировать. Необходимо учитывать, что запас по времени имеет нижние и верхние границы.
Например, верхняя граница не может превышать срока действия самого CRL. Так, если срок действия CRL составляет 1 день, то запас может составлять максимум 1 день, и тогда ЦС будет публиковать списки отзыва ежедневно, но срок действия будет составлять 2 дня. Тем самым достигается запас времени на восстановление ЦС в случае непредвиденных обстоятельств.
На практике я достаточно часто наблюдал желание администраторов закрутить настройки сроков действия CRL до минимального предела с таким обоснованием: «пользователь уволился и не должен иметь возможность аутентифицироваться с отозванным сертификатом».
При планировании сроков действия CRL и периодичности следует руководствоваться следующими рекомендациями:
- Все ЦС, которые выдают сертификаты только другим ЦС (не конечным потребителям), должны публиковать CRL сроком действия от 3-х до 12 месяцев с запасом в один месяц.
- Все ЦС, которые выдают сертификаты конечным потребителям (пользователям и устройствам), должны публиковать базовые CRL не реже одного раза в неделю и дифференциальные списки не реже 3-х дней (желательно, ежедневно). Запас по времени не следует корректировать (используйте тот, который будет автоматически высчитан внутренней логикой ЦС).
Шаблонызапросов на сертификаты, сертификатов и список отозванных сертификатов
Шаблон запроса на сертификат
Запрос на сертификат представляет собой структуру в формате PKCS#10 и является последовательностью трех полей, из которых первое содержит основное тело запроса (certificationRequestInfo), второе – информацию о типе алгоритма, использованного для подписания запроса на сертификат (signatureAlgorithm), а третье – электронную цифровую подпись, которой подписан запрос (signatureValue).
Запросы на сертификаты ЭЦП УЦ службы ДТС содержат как минимум следующие основные поля:
Version: первая версия (v1(0)) формата запроса на сертификат;
Subject: уникальное имя (DN) конечного пользователя, получающего сертификат;
SubjectPublicKeyInfo: значение открытого ключа вместе с идентификатором алгоритма;
Attributes: коллекция аттрибутов, которые могут содержать информацию о расширениях, сохраняемых в сертификат.
Значения основных полей и расширений определяются в зависимости от политики, в соответствии с которой выдается сертификат ключа проверки ЭЦП.
Запрос на сертификат сервера СДТС
Запрос на сертификат сервера СПСС
Запрос на сертификат сервера СШВ
Шаблон сертификата ключа проверки ЭЦП
Сертификат ключа проверки ЭЦП в соответствии со стандартом X.509 v.3 является последовательностью трех полей, из которых первое содержит содержимое сертификата (tbsCertificate), второе – информацию о типе алгоритма, использованного для подписания сертификата (signatureAlgorithm), а третье – электронную цифровую подпись, которой подписан сертификат (signatureValue).
Сертификаты ключей проверки ЭЦП УЦ службы ДТС содержат как минимум следующие основные поля:
Version: третья версия (X.509 v.3) формата сертификата;
SerialNumber: серийный номер сертификата, уникальный в рамках удостоверяющего центра;
Signature Algorithm: идентификатор алгоритма, применяемого удостоверяющим центром, выдающим сертификаты для подписания сертификата;
Issuer: уникальное имя (DN) Удостоверяющего центра;
Validity: срок действия сертификата, определенный началом (notBefore) и окончанием (notAfter) действия сертификата;
Subject: уникальное имя (DN) конечного пользователя, получающего сертификат;
SubjectPublicKeyInfo: значение открытого ключа вместе с идентификатором алгоритма;
Signature: подпись генерируется и кодируется в соответствии с RFC 5280.
Значения основных полей и расширений определяются в зависимости от политики, в соответствии с которой выдается сертификат ключа проверки ЭЦП.
Сертификат сервера СДТС
Сертификат сервера СПСС
Сертификат сервера СШВ
Номер версии
Все сертификаты ключей проверки ЭЦП выдаются УЦ службы ДТС в соответствии с версией X.509 v.3.
Расширения сертификата ключа проверки ЭЦП
Функция каждого расширения определена стандартным значением связанного с ним идентификатора объекта (OBJECT IDENTIFIER). Расширение в зависимости от опции, выбранной УЦ службы ДТС, выдающее сертификат ключа проверки ЭЦП может быть критическим или некритическим.
Если расширение обозначено как критическое, тогда приложение, использующее сертификаты ключей проверки ЭЦП, должно отклонять каждый сертификат ключа проверки ЭЦП, в котором после обнаружения критического расширения оно не сможет его распознать. Каждое некритическое расширение может игнорироваться.
Использование ключа (Key Usage)
Разрешение использование ключа – может быть критическим или некритическим. Данное расширение определяет способ применения ключа (например ключ для шифрования данных, ключ для ЭЦП и т.д.). Значение данного расширения зависит от политики, в соответствии с которой выдан сертификат ключа проверки ЭЦП.
Сертификат сервера СДТС
В сертификате сервера ДТС расширение “Использование ключа” помечается как критическое и имеет следующие значения:
digitalSignature (0) – ключ для реализации цифровой подписи (идентификации субъекта или данных);
nonRepudiation (1) – ключ, связанный с реализацией неотрекаемости.
Сертификат сервиса проверки статуса сертификата ключа проверки ЭЦП
В сертификате СПСС расширение “Использование ключа” помечается как критическое и имеет следующие значения:
digitalSignature (0) – ключ для реализации цифровой подписи (идентификации субъекта или данных);
nonRepudiation (1) – ключ, связанный с реализацией неотрекаемости.
Сертификат сервиса штампов времени
В сертификате СШВ расширение “Использование ключа” помечается как критическое и имеет следующие значения:
digitalSignature (0) – ключ для реализации цифровой подписи (идентификации субъекта или данных);
nonRepudiation (1) – ключ, связанный с реализацией неотрекаемости.
Улучшенный ключ (ExtendedKeyUsage)
Уточнение (ограничение) использования ключа – расширение может быть критическим. Данное поле определяет одну или более областей в дополнение к основному применению, установленному в поле keyUsage, в пределах которых может быть использован сертификат.
Сертификат сервиса проверки статуса сертификата
В сертификате СПСС расширение помечается как некритическое и содержит объектный идентификатор OCSPSigning: 1.3.6.1.5.5.7.3.9.
Сертификат сервиса штампов времени
В сертификате СШВ расширение помечается как некритическое и содержит объектный идентификатор Timestaping: 1.3.6.1.5.5.7.3.8.
Политики сертификата (Certificate Policy)
Расширение политики применения сертификатов (CertificatePolicies) содержит идентификаторы политик и ее квалификаторы, вносимые в сертификат ключа проверки ЭЦП в соответствии с правилами, описанными в Регламенте УЦ службы ДТС. Данное расширение не является критическим расширением.
Основные ограничения (Basic Constraints)
Расширение является критическим в сертификатах ключей проверки ЭЦП удостоверяющих центров и может быть критическим или некритическим в сертификатах конечных пользователей. Расширение позволяет определить, является ли субъект сертификата удостоверяющим центром (поле CA), а также сколько максимально (принимая иерархическую систематизацию удостоверяющих центров) может быть удостоверяющих центров на пути, ведущем от рассматриваемого удостоверяющего центра до конечного пользователя (поле pathLength).
Значение поля pathLength, равное 0, означает, что сертификат принадлежит удостоверяющему центру, который может выдавать сертификаты только конечным пользователям.
В сертификатах в расширение BasicContraints вносится пустая последовательность без указания в ней поля CА и поля pathLength.
Точки доступа к спискам отозванных сертификатов (CRL Distribution Points)
Расширение не является критическим. Расширение определяет протоколы и сетевые адреса, по которым можно получить актуальный список отозванных сертификатов, выданный издателем сертификата, в котором находится данное расширение.
Доступ к информации о центрах сертификации (AuthorityInformationAccess)
Расширение не является критическим. Поле указывает, каким образом передаются данные и услуги издателем сертификата, в сертификате которого данное расширение имеется. Данное расширение, если имеет место, то обычно содержит URL адрес файла сертификата удостоверяющего центра и URL адрес услуги OCSP проверки статуса сертификата, в котором указан этот адрес.
Идентификатор алгоритма
Поле signatureAlgorithm содержит идентификатор криптографического алгоритма, описывающего алгоритм, применяемый для реализации ЭЦП, которую ставит Удостоверяющий центр на сертификате.
Для сертификатов, выдаваемых УЦ службы ДТС, значение поля:
id-tc26-gost3410-2021-512 OBJECT IDENTIFIER ::= id-tc26-signwithdigest-gost3410-2021-512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1) signwithdigest(3) gost3410-2021-512(3) }
Формы имен
УЦ службы ДТС выдает сертификаты, содержащие имя издателя и субъекта, создаваемые в соответствии с правилами, описанными в Регламенте УЦ службы ДТС.
Идентификаторы политик сертификатов
Политика сертификата содержит информацию типа PolicyInformation (идентификатор, электронный адрес) о политике сертификата, которая реализуется УЦ службы ДТС, выдающим сертификаты – расширение не является критическим. В сертификатах, выдаваемых УЦ службы ДТС возможны следующие идентификаторы политик:
iso(1) member-body(2) ru(643) _______(X) id ЕЭК (ХХХ) id-____(Х) id-_______(Х) id-___________(Х) … – политика сертификата службы статусов сертификата;
iso(1) member-body(2) ru(643) _______(X) id ЕЭК (ХХХ) id-____(Х) id-_______(Х) id-___________(Х) … – политика сертификата службы штампов времени;
iso(1) member-body(2) ru(643) _______(X) id ЕЭК (ХХХ) id-____(Х) id-_______(Х) id-___________(Х) … – политика сертификата администратора сертификации. Список отозванных сертификатов (CRL) состоит из последовательности трех полей. Первое поле (tbsCertList) содержит информацию об отозванных сертификатах, второе и третье поля (signatureAlgorithm и signatureValue) – соответственно информацию о типе алгоритма, примененного для подписания списка и ЭЦП, которая ставится на сертификате удостоверяющим центром.
Значение двух последних полей полностью совпадает, как в случае сертификата. Информационное поле tbsCertList является последовательностью обязательных и опциональных полей. Обязательные поля идентифицируют издателя списка отозванных сертификатов, а необязательные содержат отозванные сертификаты и расширения списка отозванных сертификатов.
Значения основных полей и расширений списка отозванных сертификатов приведены в таблице 2.
Таблица 2
Номер версии
СОС, выпускаемые УЦ службы ДТС, соответствуют Х.509 v2.
Расширения СОС
Среди многих расширений CRL самыми важными являются два, из которых первое (поле AuthorityKeyIdentifier) позволяет идентифицировать ключ проверки ЭЦП, соответствующий ключу ЭЦП, примененному для подписания списка отозванных сертификатов, а второе (поле cRLNumber) содержит постепенно увеличиваемый номер списка CRL, издаваемого удостоверяющим центром (благодаря этому расширению пользователь списка может определить, когда один CRL заменил другой CRL).
Шаблон OCSP
Протокол проверки статуса сертификата в оперативном режиме (OCSP) применяется удостоверяющими центрами и позволяет определить состояние сертификата. Структура запросов и ответов СПСС соответствует RFC 6960. В связи с этим единственным разрешенным номером версии является 0 (это соответствует версии v1). СПСС УЦ службы ДТС работает в режиме авторизованного ответчика.
Сертификат сервера СПСС должен содержать в себе расширение под названием extKeyUsage, определенное в RFC 5280. Данное расширение должно быть обозначено как критическое и означает, что удостоверяющий центр, выдавая сертификат серверу OCSP, подтверждает своей подписью факт передачи ему права выдачи от его имени удостоверений о статусе сертификатов клиентов данного центра.
Сертификат может содержать также информацию о способе контакта с сервером центра проверки статуса сертификата. Данная информация содержится в поле расширения AuthorityInfoAccess.
Информация о статусе сертификата вносится в поле certStatus структуры SingleResponse. Она может принимать одно из трех разрешенных значений, определенных в Регламенте УЦ службы ДТС.
Шаблон запроса OCSP
OCSP-запрос принимает ASN.1-структуру в соответствии с RFC 6960 и имеет следующие ограничения.
Поле requestExtensions структуры tbsRequest содержит список расширений. Данный список должен содержать только расширение ocspNonce (OID 1.3.6.1.5.5.7.48.1.2).
Необязательное поле singleRequestExtensions структуры tbsRequest, содержащее список расширений для единичного запроса, должно отсутствовать.
В случае, если поле optionalSignature структуры OCSPRequest задано, то на него накладываются следующие ограничения:
поле signatureAlgorithm должно принимать значение “ГОСТ Р 34.11/34.10-2021” (OID 1.2.643.7.1.1.3.3);
поле certs должно включать сертификат для проверки ЭЦП запроса OCSP. Кроме того, поле requestorName из структуры tbsRequest должно присутствовать в обязательном порядке и представлять собой структуру directoryName, содержащую элемент CommonName (объектный идентификатор – 2.5.4.3).
Шаблон ответа OCSP
OCSP-ответ принимает ASN.1-структуру в соответствии с RFC 6960 и имеет следующие ограничения.
Поле responseType содержит объектный идентификатор типа ответа, который имеет значение 1.3.6.1.5.5.7.48.1.1. Поле response содержит структуру BasicOCSPResponse.
В случае, если в соответствующем OCSP-запросе присутствовало расширение ocspNonce, то в OCSP-ответе необязательное поле responseExtensions структуры ResponseData будет содержать расширение ocspNonce с аналогичным значением.
Поле signatureAlgorithm принимает значение “ГОСТ Р 34.11/34.10-2021” (OID 1.2.643.7.1.1.3.3).
В списке сертификатов certs содержится сертификат СПСС, необходимый для проверки ЭЦП.
Необязательное поле singleExtensions структуры SingleResponse, которое может содержать расширения OCSP-ответа, отсутствует.
Шаблон штампов времени
СШВ УЦ службы ДТС подписывает ЭЦП выдаваемые им же штампы времени при помощи ключа ЭЦП, специально зарезервированного для этой цели. В соответствии с рекомендацией RFC 5280, совместимые с ними сертификаты ключей проверки ЭЦП СШВ содержат поле, уточняющее узкое допустимое применение ключа (ExtKeyUsage), обозначенное как критическое. Это означает, что сертификат может быть использован СШВ и только для формирования ЭЦП в выдаваемых им штампах времени.
Штамп времени, выданный СШВ УЦ службы ДТС содержит в себе информацию о штампе времени (структура TSTInfo), внесенную в структуру SignedData (в соответствии с RFC 2630), подписанную СШВ и закрепленную в структуре ContentInfo. Штампы времени, выдаваемые СШВ УЦ службы ДТС, соответствуют RFC 3161.
Шаблон запроса TSP
TSP-запрос представляет собой ASN.1-структуру в соответствии с RFC 2630 и имеет следующие ограничения:
необязательное поле reqPolicy структуры TimeStampReq должно отсутствовать либо содержать объектный идентификатор базовой политики (OID = 0.4.0.2023.1.1);
необязательное поле nonce должно отсутствовать либо содержать случайно сгенерированное 64-битное значение.
Шаблон ответа TSP
TSP-ответ представляет собой ASN.1-структуру в соответствии с RFC 2630 и имеет следующие ограничения:
поле digestAlgorithms структуры SignedData принимает значение “ГОСТ Р 34.11-2021 с длиной 512” (OID 1.2.643.7.1.1.2.3);
необязательное поле certificates структуры SignedData будет содержать сертификат службы TSP, если в TSP-запросе необязательное поле certReq структуры TimeStampReq содержало значение true;
необязательное поле crls структуры SignedData должно отсутствовать;
поле policy структуры TSTInfo должно содержать объектный идентификатор базовой политики (OID = 0.4.0.2023.1.1);
в случае, если в соответствующем TSP-запросе присутствовало необязательное поле nonce, то в TSP-ответе необязательное поле nonce структуры TSTInfo также будет содержать аналогичное значение;
необязательное поле tsa структуры TSTInfo отсутствует;
необязательное поле extensions структуры TSTInfo отсутствует;
поле digestAlgorithm структуры SignerInfo принимает значение “ГОСТ Р 34.11-2021 с длиной 512” (OID 1.2.643.7.1.1.2.3);
поле signedAttrs структуры SignerInfo будет содержать следующие объекты: тип подписываемого содержимого (OID 1.2.840.113549.1.9.16.1.4 (штамп времени)), значение хеш-функции штампа времени, информация о сертификате службы штампов времени;
поле signatureAlgorithm структуры SignerInfo принимает значение “ГОСТ Р 34.10-2-12 с длиной 512”.
Приложение № 2к Регламентуудостоверяющего центра службыдоверенной третьей стороныинтегрированнойинформационной системыЕвразийского экономического союза