Имеет ли право пользователь отправить запрос на изготовление сертификата ключа в центр сертификации

Обновлено: 02.07.2024

7.1 Защита открытых ключей шифрования от подмены

Сценарий таких действий достаточно прост. Предположим, что есть два пользователя i и j, каждый из которых имеет по паре ключей. При этом у пользователя j есть открытый ключ Kpi для проверки ЭЦП пользователя i. Предположим, что злоумышленник может перехватить этот ключ Kpi в процессе его передачи от пользователя i пользователю j или получить доступ к этому ключу, хранящемуся у пользователя j. В любом случае злоумышленник считает из ключа его реквизиты (например, фамилию владельца, место работы и т. д.) и создаст свою пару ключей – Ksi' и Kpi', в которые запишет известные ему реквизиты пользователя i. Затем он подменит посланный пользователю j открытый ключ Kpi своим фальшивым открытым ключом Kpi', имеющим реквизиты пользователя i.

В настоящее время наиболее популярны два основных способа сертификации: двухуровневая и так называемая инфраструктура открытых ключей.

7.2. Сертификационные центры

Сертификация ключа — это подтверждение подлинности открытого ключа и хранимой совместно с ним служебной информации, в том числе и о его принадлежности. Данная процедура обычно выполняется путем вычисления ЭЦП сертифицируемого ключа и его реквизитов с помощью специального секретного ключа-сертификата, доступного только сертификационному центру (уполномоченному на данную операцию лицу или организации).

Открытый ключ сертификационного центра (парный секретному, на котором проводится сертификация других открытых ключей), используется для проверки целостности сертифицированных открытых ключей. Его обычно называют ключом-сертификатом.

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

Правило первое: каждый раз, верифицируя ЭЦП какую-либо информацию, необходимо контролировать соответствие сертификации открытого ключа, с помощью которого эта ЭЦП проверяется. Если целостность открытого ключа нарушена (т. е., сертифицирующая ЭЦП открытого ключа неверна), то следует считать ЭЦП информации недостоверной, а информацию – подложной, независимо от результатов верификации той ЭЦП, которая относится к информации. Обычно по факту обнаружения открытого ключа с фальшивой сертифицирующей ЭЦП в организациях проводится расследование причин его появления.

Правило второе: защита от подмены ключа-сертификата, с помощью которого проверяется ЭЦП остальных открытых ключей. Обычно с этой целью ключ-сертификат хранят на том же персональном носителе, что и секретный ключ пользователя.

Аналогичным образом необходимо контролировать целостность и принадлежность открытых ключей и при асимметричном шифровании.

Возможны два варианта двухуровневой сертификации: когда имеется третья доверенная сторона и когда она отсутствует.

  • подписать полученный открытый ключ нового пользователя своим секретным ключом и только после этого записать его, например на жесткий диск ПК;
  • используя открытый ключ нового пользователя, каждый раз проверять его ЭЦП с помощью собственного открытого ключа, который в данном случае играет роль ключа-сертификата.

Вся защита открытых ключей от подмены перекладывается на ключ-сертификат, которым служит собственный открытый ключ. Поэтому последний должен храниться на том же персональном ключевом носителе, где и секретный ключ пользователя. Если же злоумышленник сумеет подменить ключ-сертификат, могут пострадать и остальные открытые ключи, сертификация которых проверялась с его помощью.

В принципе при небольшом числе пользователей сети все открытые ключи остальных пользователей можно записать на персональный ключевой носитель (если на нем достаточно памяти). В этом случае их можно не сертифицировать, если криптосистема позволяет применять несертифицированные открытые ключи.

Как уже упоминалось выше, допускается передача открытых ключей и по недоверенной связи (например, по электронной почте). Но тогда одновременно с открытым ключом обязательно нужно послать сопроводительное письмо по доверенной связи (например, заказным письмом). В нем обычно содержится распечатка всего ключа (включая любую хранящуюся в файле ключа дополнительную информацию – реквизиты пользователя, срок действия и т. д.), а также список полномочий пользователя (какого рода документы данный пользователь имеет право подписывать).

После получения открытого ключа (по электронной почте) и сопроводительного письма пользователь визуально или с помощью специального ПО сравнивает соответствие образа присланного ключа с записанным в сопроводительном письме. При любом несовпадении присланный ключ считается недействительным. Если несовпадений нет, проводится сертификация присланного открытого ключа (как описано выше).

Предположим, что описанная выше схема не помогла и обнаружился документ, ЭЦП которого при проверке сертифицированным открытым ключом Kpi пользователем j оказалась верна, однако пользователь i впоследствии стал утверждать, что его ЭЦП под данным документом поддельная. Как разрешить данную конфликтную ситуацию?

Прежде всего ЭЦП спорного документа еще раз проверяется открытым ключом Kpi. Если ЭЦП неверна, то считается, что виноват пользователь j, поскольку он либо неправильно интерпретировал результат первой проверки ЭЦП, либо допустил двойную подмену хранящегося у него Kpi (т. е. сначала на фальшивый ключ Kpi', а потом обратно). Если ЭЦП все-таки верна, проверяется соответствие хранящегося у пользователя j ключа Kpi его распечатке в сопроводительном письме. Если ключи не совпадают, то опять-таки виноват пользователь j, поскольку допустил подмену хранящегося у него открытого ключа Kpi. В противном случае считается, что виноват пользователь i, поскольку он либо допустил несанкционированное использование его секретного ключа Ksi злоумышленником, либо просто отказывается от легально подписанного им документа.

Как видно, при использовании сертифицированных открытых ключей достаточно легко найти виновника конфликтной ситуации. Обычно различные средства ЭЦП сопровождаются документацией, разъясняющей пользователям порядок безопасного хранения ключей, их сертификации, разбора конфликтных ситуаций и т. д.

Предположим, что существует некая третья доверенная сторонацентр сертификации ключей (часто его называют также СЦ – сертификационный центр, или УЦ – удостоверяющий центр; последний термин, в частности, используется в отечественном законе об ЭЦП). Назначение СЦ – сертификация открытых ключей всех пользователей системы и распространение сертифицированных открытых ключей.

Рассмотрим процесс сертификации и распространения ключей через СЦ, воспользовавшись тем же примером, в котором в криптосистему добавляется новый пользователь. Последний прежде всего создает персональную дискету с собственными секретным и открытым ключами и сопроводительное письмо (аналогичное тому, что и при сертификации без СЦ). Сопроводительное письмо вместе с открытым ключом по электронной почте пересылается в СЦ. Кроме того, сопроводительное письмо направляется в СЦ обычной почтой или с курьером. В СЦ проверяется идентичность открытого ключа, пришедшего по электронной почте, тому, что находится в сопроводительном письме.

В завершение процедуры СЦ передает новому пользователю по электронной почте сертифицированные открытые ключи всех пользователей, сертифицированные файлы с полномочиями пользователей и ключ-сертификат. Кроме того, обычной почтой или с курьером ему посылается сопроводительное письмо, содержащее распечатку ключа-сертификата. Пользователь сверяет соответствие ключа-сертификата сопроводительному письму, затем проверяет с помощью ключа-сертификата ЭЦП открытых ключей всех пользователей и файлов их полномочий. Начинать использовать ЭЦП в системе разрешается только при положительном результате всех проверок.

В описанном выше случае предполагается, что пары ключей генерируются пользователями самостоятельно. Однако их можно создавать и централизованно – в центре генерации ключей (ЦГК). Такой центр чаще всего применяется, если работа с ЭЦП происходит в криптосистеме, действующей в рамках одной организации.

В функции ЦГК обычно входят генерация ключей, рассылка секретных ключей пользователям (только в зашифрованном виде или передачей из рук в руки), а также передача открытых ключей в СЦ. Часто СЦ и ЦГК бывают совмещены (представляют собой одно рабочее место).

Однако следует помнить, что генерация и сертификация ключей — это такие операции, неправильное выполнение которых может пагубно отразиться на безопасности всей системы. Поэтому рабочее место, где размещен СЦ и/или ЦГК, должно соответствовать ряду требований. Во-первых, во избежание вмешательства злоумышленника в процесс генерации ключей или перехвата ключей следует физически отделить данный компьютер от любых сетей. Во-вторых, необходимо установить на нем защиту от несанкционированного доступа и обеспечить контроль целостности запускаемых программ (чтобы злоумышленник не сумел внедрить на нем программные закладки).

Описанные выше схемы отнюдь не единственно возможные. Существует немало других вариантов подобной сертификации; необходимо лишь убедиться в уровне безопасности того способа, который предполагается использовать, и в его соответствии конкретной криптосистеме.

Компоненты структуры PKI имеют следующее назначение.

Центр сертификации (Certification Authority, CA) — организационная единица, назначением которой является сертификация открытых ключей пользователей (т. е. получение из открытого ключа сертификата в формате, определенном в X.509) и их опубликование в каталоге сертификатов.

Центр регистрации (Registration Authority, RA) — другая организационная единица, обеспечивающая регистрацию пользователей системы.

Пользователь в терминах структуры PKI — это владелец какого-либо сертификата (такой пользователь подлежит регистрации) или любой пользователь, запрашивающий сертификат, хранящийся в каталоге сертификатов.

Как известно, открытые ключи вычисляются по определенным алгоритмам из соответствующих им секретных ключей и используются в основном для следующих целей:

  • проверки ЭЦП данных или другого открытого ключа;
  • шифрования данных, направляемых владельцу секретного ключа, парного открытому: расшифровать данные можно только с использованием данного секретного ключа;
  • вычисления ключа парной связи с целью последующего шифрования или расшифровывания данных с помощью алгоритма симметричного шифрования.

Во всех этих случаях совершенно необходимы подтверждение целостности и установление принадлежности открытого ключа конкретному пользователю. Некая третья доверенная сторона (Trusted Third Party, TTP), в данном случае CA, должна подтвердить, что владелец открытого ключа — это именно тот пользователь, информация о котором содержится в сертификате, а также что открытый ключ соответствует секретному ключу данного пользователя.

Таким образом, цифровой сертификат содержит три главные составляющие: открытый ключ пользователя, информацию о пользователе — владельце сертификата, сертифицирующую ЭЦП двух предыдущих составляющих (вычисленную на секретном ключе CA).

PKI подразумевает, что все сертификаты конкретной PKI (а свою PKI может иметь любая организация или компания) организованы в иерархическую структуру.

Иерархическая схема PKI предусматривает существование четырех типов сертификатов.

Сертификат пользователя — описан выше

Сертификат CA — должен быть доступен для проверки ЭЦП сертификата пользователя и, в свою очередь, должен быть подписан секретным ключом CA верхнего уровня. При этом данную ЭЦП (подписанную секретным ключом CA верхнего уровня) также следует проверять, а потому необходимо, чтобы был доступен сертификат CA верхнего уровня и т. д.

Самоподписанный сертификат — корневой для всей PKI. Это по определению доверенный сертификат: если результат проверки цепочки сертификатов CA показывает, что один из них подписан корневым секретным ключом, процесс проверки ЭЦП сертификатов на этом завершается.

Кросс-сертификат можно назвать средством расширения, поскольку он позволяет распространить действие конкретной PKI на другую путем взаимоподписания корневых сертификатов двух PKI.

Процедура проверки ЭЦП электронного документа происходит в системе PKI следующим образом. Сначала проверяется ЭЦП конкретного документа, а затем ЭЦП сертификата, с помощью которого проверялась предыдущая ЭЦП. Последняя проверка повторяется в цикле до тех пор, пока цепочка сертификатов не приведет к корневому.

ЭЦП документа признается верной лишь в том случае, если верна не только она, но и все проверяемые в данном процессе ЭЦП сертификатов. При обнаружении неверной ЭЦП любого из сертификатов неверными считаются все ЭЦП, проверенные на предыдущих шагах.

Заметим, что корневых сертификатов может быть несколько: каждая организация (или организационная единица) вправе устанавливать свои корневые сертификаты (один или несколько). Стандартом предусмотрено и наличие корневого сертификата для всего сообщества пользователей Интернета.

7.3. Формат электронных сертификатов, расширения сертификатов, отзыв сертификатов

В настоящее время для сертификации открытых ключей применяется формат электронных сертификатов X.509 (стандарт X.509 версии 3). В предыдущей, второй, версии отсутствовали расширения, а в версии 1 – еще и ряд дополнительных полей. В X.509 версии 3 определено, что в цифровом сертификате обязательно присутствие следующих полей:

  • номер версии формата, которому соответствует сертификат;
  • серийный номер сертификата – уникальный номер, присваиваемый каждому сертификату, выпускаемому конкретным CA;
  • идентификатор CA, который выпустил данный сертификат (т. е. сгенерировал пару ключей и подписал открытый ключ). Данное поле в паре с предыдущим образуют уникальный идентификатор сертификата;
  • срок действия сертификата, указывающий диапазон дат начала и окончания действия данного сертификата;
  • персональные данные пользователя, которому принадлежит сертификат, и собственно открытый ключ пользователя;
  • расширения формата, код алгоритма, примененного при вычислении сертифицирующей ЭЦП, и сертифицирующая ЭЦП.

Все поля сертификата записываются по принципу TLV (tag-length-value - код-длина-идентификатор), который в настоящее время широко применяется для различных форматных записей, особенно в области коммуникаций.

Отметим также, что в третьей версии X.509 указано, что не следует более издавать сертификаты версии 2, а версия 1 сохраняется только для обеспечения совместимости с существующими приложениями, которые используют сертификаты X.509 данной версии.

Расширения сертификатов версии 3 существенно увеличивают возможности обработки сертификатов, позволяя уточнить правила и области применения конкретного сертификата и задать необходимые параметры. Приведем лишь основные расширения, предусмотренные стандартом.

Идентификатор ключа CA дает возможность указать конкретный секретный ключ центра сертификации, на котором вычислялась ЭЦП данного сертификата, из существующего набора ключей CA (каждый CA может иметь несколько ключей).

Назначение ключа характеризует область его применения. Фактически в данное поле записана битовая маска, которая определяет одну или несколько возможных целей использования данного сертификата и парного ему секретного ключа. В число возможных вариантов входят вычисление и проверка ЭЦП, шифрование данных, шифрование других ключей, сертификация ключей и т. д.

См. подробнее в хрестоматии

В дополнение к указанным основным расширениям формата стандарт X.509 устанавливает ряд других. Более того, любая PKI-система (например, инфраструктура открытых ключей конкретной организации) может вводить свои расширения, в зависимости от конкретных условий применения цифровых сертификатов.

Любой сертификат может быть отозван раньше времени окончания срока его действия (что означает запрет на его использование в дальнейшем), как минимум, по одной из двух причин: скомпрометирован соответствующий сертификату секретный ключ или изменились персональные данные владельца сертификата. Стандарт X.509 предусматривает, что CA регулярно публикуют списки отозванных сертификатов (Certificate Revocation List, CRL), если не используются иные методы приостановки действия сертификатов. CRL может быть и пустым, если в отзыве нет необходимости. Во избежание ложных отзывов сертификатов каждый CRL снабжается сертифицирующей ЭЦП CA, который его выпустил. Любое PKI-ориентированное приложение в процессе проверки ЭЦП цепочки сертификатов (например, согласно описанному выше алгоритму проверки ЭЦП электронного документа) обязано также проверять отсутствие всех сертификатов проверяемой цепочки в текущих CRL. В случае обнаружения отозванного сертификата все ЭЦП, проверенные на предыдущих шагах, считаются неверными.

1С:Подпись – обеспечивает заполнение заявки на регистрацию квалифицированного сертификата ключа проверки электронной подписи в Удостоверяющем центре "1С", получение и установку сертификата на компьютере пользователя.

Сертификат ключа проверки электронной подписи (СКП) – электронный документ подтверждающий соответствие между открытым ключом и информацией, идентифицирующей владельца ключа. Содержит информацию о владельце ключа, сведения об открытом ключе, его назначении и области применения

Заявление – бумажный документ, подписываемый законным представителем организации, включающий реквизиты, подлежащие указанию в СКП и в реестре изданных сертификатов (в соответствии с требованиями законодательства РФ), соглашение о присоединении к Регламенту Удостоверяющего центра.

Мастер подготовки заявки – компонента программного продукта 1С:Подпись, предназначенная для подготовки заявки в пошаговом режиме.

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

Настройка криптопровайдера

Для поддержки работы с квалифицированными сертификатами в среде MS Windows необходимо получить и установить на ПК актуальную версию сертифицированного криптопровайдера. В настоящее время поддерживается работа со следующими программами:

Установка и настройка криптопровайдеров осуществляется в соответствии с технической документацией на эти продукты.

В настройках информационной базы необходимо указать установленный криптопровайдер, для этого перейдите в Настройки электронной подписи и шифрования

Запуск Мастера

Подготовка заявления на выпуск нового квалифицированного сертификата

Выбор типа заявителя

Выберите нужный тип заявителя с помощью выпадающего меню.

Заполнение заявки

Для Юридических лиц:

Заполните реквизиты организации вручную или выберите из справочника организаций.

Заполните данные владельца сертификата или выберите сотрудника из справочника.

Укажите ФИО, должность и основание полномочий подписанта заявления на изготовление сертификата

Для Индивидуальных предпринимателей:

Заполните реквизиты индивидуального предпринимателя или выберите из справочника.

Заполните данные владельца сертификата - индивидуального предпринимателя.

Для Физических лиц:

Заполните данные владельца сертификата – физического лица или выберите из справочника.

Для автоматического прикрепления Вашей заявки к Личному кабинету обслуживающей организации укажите ее ИНН/КПП или выберите организацию из справочника контрагентов. Это позволит сократить срок рассмотрения Вашей заявки.

Создание ключа электронной подписи

Внимательно проверьте указанные сведения и выберите криптопровайдер, настроенный в разделе 2 данного Руководства.

Сформируйте ключ электронной подписи и запрос с помощью интерфейса криптопровайдера. Для хранения ключа электронной подписи рекомендуется использовать защищенный ключевой носитель (информационный выпуск № 24982 от 21.09.2018 Расширение ассортимента защищенных носителей "Рутокен" для ключей электронной подписи от российского разработчика Компании "Актив").

При необходимости, обращайтесь к технической документации на используемое вами средство электронной подписи.

Подготовка комплекта заявительных документов

Распечатайте и подпишите заявление на изготовление сертификата.

Подготовьте и передайте комплект документов уполномоченному представителю Вашей обслуживающей организации.

Для Юридических лиц:

  • Заявление на выпуск сертификата (подготовленное на предыдущем шаге).
  • Копия* свидетельства о постановке на учет в налоговом органе (ИНН).
  • Копия* свидетельства о государственной регистрации юридического лица (ОГРН) или лист записи ЕГРЮЛ (Форма № Р50007).
  • Копия* документа, удостоверяющего личность представителя организации, указанного для выпуска сертификата.
  • Копия* страхового свидетельства обязательного пенсионного страхования (СНИЛС) представителя организации, указанного для выпуска сертификата.
  • Копия* документа, подтверждающего полномочия представителя организации, указанного для выпуска сертификата (решение собственника, протокол собрания учредителей, выписка ЕГРЮЛ или доверенность)

Для Индивидуальных предпринимателей:

  • Заявление на выпуск сертификата (подготовленное на предыдущем шаге).
  • Копия* свидетельства о постановке на учет в налоговом органе (ИНН).
  • Копия свидетельства о государственной регистрации индивидуального предпринимателя (ОГРН) или лист записи ЕГРИП (Форма Р60009).
  • Копия документа, удостоверяющего личность индивидуального предпринимателя.
  • Копия* страхового свидетельства обязательного пенсионного страхования (СНИЛС) индивидуального предпринимателя.

Для Физических лиц:

  • Заявление на выпуск сертификата (подготовленное на предыдущем шаге).
  • Копия* свидетельства о постановке на учет в налоговом органе (ИНН).
  • Копия документа, удостоверяющего личность физического лица.
  • Копия* страхового свидетельства обязательного пенсионного страхования (СНИЛС) физического лица.

Отправка заявки в 1С:Подпись

Проверка состояния заявления и установка сертификата в контейнер

По окончании обработки заявки сертификат будет получен и установлен в контейнер автоматически.

Для использования электронной подписи в системе B2B-Center требуется предварительное выполнение следующих условий:

Загрузка сертификата электронной подписи

2. В блоке Профиль организации откройте ссылку Мои ЭП.

01 - Раздел Мои ЭП.jpg

Отобразится страница Мои электронные подписи.

02 - Открытая вкладка Мои Электронные Подписи.jpg

03 - Форма регистрации сертификата.jpg

4. Установите отметку в поле Сертификат уже установлен на компьютере. Отобразится меню Выберите сертификат.

5. Выберите сертификат для загрузки.

04 - Выбран сертификат установленный на компьютере.jpg

Примечание: если сертификат открытого ключа сохранен на компьютере в виде отдельного файла, то вместо выбора из списка установленных сертификатов его можно загрузить с помощью кнопки
Обзор
, которая доступна если вы не поставили отметку в поле Сертификат уже установлен на компьютере. Для загрузки пригодны файлы сертификатов в формате .cer.

6. Загрузите сканы правоустанавливающих документов с помощью кнопки


05 - Файл с правоустанавливающими документами.jpg

  • для юридических лиц правоустанавливающие документы должны включать свидетельство о постановке на налоговый учет (ИНН) и документ о назначении владельца сертификата подписи на должность;
  • для физических лиц требуется сканированное изображение страниц паспорта с фото и пропиской;
  • для индивидуальных предпринимателей требуется сканированное свидетельство о постановке на учет физического лица.

. Отобразится страница Электронная цифровая подпись с уведомлением Заявка на обработку файла сертификата отправлена!


06 - Заявка на обработку файла сертификата отправлена.jpg

07 - Отправленная заявка на регистрацию сертификата.jpg

9. В Системе работает автоматическая проверка сертификатов. Если сертификат соответствует требованиям для автоматического подтверждения, то после загрузки и нажатия кнопки

После отправки сертификат электронной подписи попадает в обработку к Оператору. Оператор проверяет пригодность сертификата для работы в Системе и поданные вместе с ним документы.

1. Если сертификат допущен Оператором, на электронный адрес, указанный вами в Личном кабинете, поступит уведомление со следующим текстом:

2. Если сертификат или прилагаемые к нему документы не соответствуют требованиям площадки B2B-Center, Оператор отклоняет заявку на регистрацию. В этом случае вы не сможете пользоваться сертификатом в Системе и получите уведомление об отклонении заявки на электронный адрес, указанный в Личном кабинете.

Сертификат может быть отклонен в следующих случаях:

Просмотр сертификатов электронной подписи, загруженных в Личном кабинете

Все загруженные в Систему сертификаты электронной подписи, принадлежащие пользователям, отображаются в разделе Мои электронные подписи.

1. Для просмотра списка сертификатов авторизуйтесь в Системе и перейдите в раздел Мои электронные подписи следующим путем: Личный кабинет → блок Профиль организации → ссылка Мои ЭП . На отобразившейся странице расположена таблица со списком электронных подписей, загруженных в Личный кабинет.

08 - Список полученных электронных подписей.jpg

2. Наведите курсор на номер заявки на регистрацию сертификата в столбце Заявка. Появится всплывающая подсказка Смотреть сертификат. Нажмите на ссылку в номере заявки. В новом окне браузера отобразится страница с данными сертификата:


09 - Окно просмотра сертификата.jpg

Все файлы доступны для скачивания по ссылкам.

Проверка электронной подписи

Чтобы проверить работоспособность ЭЦП:

1. Вставьте носитель электронной подписи в USB-порт компьютера.

3. Откройте вкладку Проверка ЭП . Отобразится форма подписания проверочного документа.

4. Заполните поле Подписываемый документ и нажмите кнопку

Подписать документ

Система примет сертификат и подпишет электронный документ. На странице появится таблица с текстом подписываемого документа, результатами его подписания и данными об использованной электронной подписи. В табличной строке Проверка работы ЭЦП будет указан статус Успешно.

11 - Результат подписания электронного документа.jpg

в нижней части таблицы. Откроется окно с результатами проверки поставленной электронной подписи.

7.1 Защита открытых ключей шифрования от подмены

Сценарий таких действий достаточно прост. Предположим, что есть два пользователя i и j, каждый из которых имеет по паре ключей. При этом у пользователя j есть открытый ключ Kpi для проверки ЭЦП пользователя i. Предположим, что злоумышленник может перехватить этот ключ Kpi в процессе его передачи от пользователя i пользователю j или получить доступ к этому ключу, хранящемуся у пользователя j. В любом случае злоумышленник считает из ключа его реквизиты (например, фамилию владельца, место работы и т. д.) и создаст свою пару ключей – Ksi' и Kpi', в которые запишет известные ему реквизиты пользователя i. Затем он подменит посланный пользователю j открытый ключ Kpi своим фальшивым открытым ключом Kpi', имеющим реквизиты пользователя i.

В настоящее время наиболее популярны два основных способа сертификации: двухуровневая и так называемая инфраструктура открытых ключей.

7.2. Сертификационные центры

Сертификация ключа — это подтверждение подлинности открытого ключа и хранимой совместно с ним служебной информации, в том числе и о его принадлежности. Данная процедура обычно выполняется путем вычисления ЭЦП сертифицируемого ключа и его реквизитов с помощью специального секретного ключа-сертификата, доступного только сертификационному центру (уполномоченному на данную операцию лицу или организации).

Открытый ключ сертификационного центра (парный секретному, на котором проводится сертификация других открытых ключей), используется для проверки целостности сертифицированных открытых ключей. Его обычно называют ключом-сертификатом.

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

Правило первое: каждый раз, верифицируя ЭЦП какую-либо информацию, необходимо контролировать соответствие сертификации открытого ключа, с помощью которого эта ЭЦП проверяется. Если целостность открытого ключа нарушена (т. е., сертифицирующая ЭЦП открытого ключа неверна), то следует считать ЭЦП информации недостоверной, а информацию – подложной, независимо от результатов верификации той ЭЦП, которая относится к информации. Обычно по факту обнаружения открытого ключа с фальшивой сертифицирующей ЭЦП в организациях проводится расследование причин его появления.

Правило второе: защита от подмены ключа-сертификата, с помощью которого проверяется ЭЦП остальных открытых ключей. Обычно с этой целью ключ-сертификат хранят на том же персональном носителе, что и секретный ключ пользователя.

Аналогичным образом необходимо контролировать целостность и принадлежность открытых ключей и при асимметричном шифровании.

Возможны два варианта двухуровневой сертификации: когда имеется третья доверенная сторона и когда она отсутствует.

  • подписать полученный открытый ключ нового пользователя своим секретным ключом и только после этого записать его, например на жесткий диск ПК;
  • используя открытый ключ нового пользователя, каждый раз проверять его ЭЦП с помощью собственного открытого ключа, который в данном случае играет роль ключа-сертификата.

Вся защита открытых ключей от подмены перекладывается на ключ-сертификат, которым служит собственный открытый ключ. Поэтому последний должен храниться на том же персональном ключевом носителе, где и секретный ключ пользователя. Если же злоумышленник сумеет подменить ключ-сертификат, могут пострадать и остальные открытые ключи, сертификация которых проверялась с его помощью.

В принципе при небольшом числе пользователей сети все открытые ключи остальных пользователей можно записать на персональный ключевой носитель (если на нем достаточно памяти). В этом случае их можно не сертифицировать, если криптосистема позволяет применять несертифицированные открытые ключи.

Как уже упоминалось выше, допускается передача открытых ключей и по недоверенной связи (например, по электронной почте). Но тогда одновременно с открытым ключом обязательно нужно послать сопроводительное письмо по доверенной связи (например, заказным письмом). В нем обычно содержится распечатка всего ключа (включая любую хранящуюся в файле ключа дополнительную информацию – реквизиты пользователя, срок действия и т. д.), а также список полномочий пользователя (какого рода документы данный пользователь имеет право подписывать).

После получения открытого ключа (по электронной почте) и сопроводительного письма пользователь визуально или с помощью специального ПО сравнивает соответствие образа присланного ключа с записанным в сопроводительном письме. При любом несовпадении присланный ключ считается недействительным. Если несовпадений нет, проводится сертификация присланного открытого ключа (как описано выше).

Предположим, что описанная выше схема не помогла и обнаружился документ, ЭЦП которого при проверке сертифицированным открытым ключом Kpi пользователем j оказалась верна, однако пользователь i впоследствии стал утверждать, что его ЭЦП под данным документом поддельная. Как разрешить данную конфликтную ситуацию?

Прежде всего ЭЦП спорного документа еще раз проверяется открытым ключом Kpi. Если ЭЦП неверна, то считается, что виноват пользователь j, поскольку он либо неправильно интерпретировал результат первой проверки ЭЦП, либо допустил двойную подмену хранящегося у него Kpi (т. е. сначала на фальшивый ключ Kpi', а потом обратно). Если ЭЦП все-таки верна, проверяется соответствие хранящегося у пользователя j ключа Kpi его распечатке в сопроводительном письме. Если ключи не совпадают, то опять-таки виноват пользователь j, поскольку допустил подмену хранящегося у него открытого ключа Kpi. В противном случае считается, что виноват пользователь i, поскольку он либо допустил несанкционированное использование его секретного ключа Ksi злоумышленником, либо просто отказывается от легально подписанного им документа.

Как видно, при использовании сертифицированных открытых ключей достаточно легко найти виновника конфликтной ситуации. Обычно различные средства ЭЦП сопровождаются документацией, разъясняющей пользователям порядок безопасного хранения ключей, их сертификации, разбора конфликтных ситуаций и т. д.

Предположим, что существует некая третья доверенная сторонацентр сертификации ключей (часто его называют также СЦ – сертификационный центр, или УЦ – удостоверяющий центр; последний термин, в частности, используется в отечественном законе об ЭЦП). Назначение СЦ – сертификация открытых ключей всех пользователей системы и распространение сертифицированных открытых ключей.

Рассмотрим процесс сертификации и распространения ключей через СЦ, воспользовавшись тем же примером, в котором в криптосистему добавляется новый пользователь. Последний прежде всего создает персональную дискету с собственными секретным и открытым ключами и сопроводительное письмо (аналогичное тому, что и при сертификации без СЦ). Сопроводительное письмо вместе с открытым ключом по электронной почте пересылается в СЦ. Кроме того, сопроводительное письмо направляется в СЦ обычной почтой или с курьером. В СЦ проверяется идентичность открытого ключа, пришедшего по электронной почте, тому, что находится в сопроводительном письме.

В завершение процедуры СЦ передает новому пользователю по электронной почте сертифицированные открытые ключи всех пользователей, сертифицированные файлы с полномочиями пользователей и ключ-сертификат. Кроме того, обычной почтой или с курьером ему посылается сопроводительное письмо, содержащее распечатку ключа-сертификата. Пользователь сверяет соответствие ключа-сертификата сопроводительному письму, затем проверяет с помощью ключа-сертификата ЭЦП открытых ключей всех пользователей и файлов их полномочий. Начинать использовать ЭЦП в системе разрешается только при положительном результате всех проверок.

В описанном выше случае предполагается, что пары ключей генерируются пользователями самостоятельно. Однако их можно создавать и централизованно – в центре генерации ключей (ЦГК). Такой центр чаще всего применяется, если работа с ЭЦП происходит в криптосистеме, действующей в рамках одной организации.

В функции ЦГК обычно входят генерация ключей, рассылка секретных ключей пользователям (только в зашифрованном виде или передачей из рук в руки), а также передача открытых ключей в СЦ. Часто СЦ и ЦГК бывают совмещены (представляют собой одно рабочее место).

Однако следует помнить, что генерация и сертификация ключей — это такие операции, неправильное выполнение которых может пагубно отразиться на безопасности всей системы. Поэтому рабочее место, где размещен СЦ и/или ЦГК, должно соответствовать ряду требований. Во-первых, во избежание вмешательства злоумышленника в процесс генерации ключей или перехвата ключей следует физически отделить данный компьютер от любых сетей. Во-вторых, необходимо установить на нем защиту от несанкционированного доступа и обеспечить контроль целостности запускаемых программ (чтобы злоумышленник не сумел внедрить на нем программные закладки).

Описанные выше схемы отнюдь не единственно возможные. Существует немало других вариантов подобной сертификации; необходимо лишь убедиться в уровне безопасности того способа, который предполагается использовать, и в его соответствии конкретной криптосистеме.

Компоненты структуры PKI имеют следующее назначение.

Центр сертификации (Certification Authority, CA) — организационная единица, назначением которой является сертификация открытых ключей пользователей (т. е. получение из открытого ключа сертификата в формате, определенном в X.509) и их опубликование в каталоге сертификатов.

Центр регистрации (Registration Authority, RA) — другая организационная единица, обеспечивающая регистрацию пользователей системы.

Пользователь в терминах структуры PKI — это владелец какого-либо сертификата (такой пользователь подлежит регистрации) или любой пользователь, запрашивающий сертификат, хранящийся в каталоге сертификатов.

Как известно, открытые ключи вычисляются по определенным алгоритмам из соответствующих им секретных ключей и используются в основном для следующих целей:

  • проверки ЭЦП данных или другого открытого ключа;
  • шифрования данных, направляемых владельцу секретного ключа, парного открытому: расшифровать данные можно только с использованием данного секретного ключа;
  • вычисления ключа парной связи с целью последующего шифрования или расшифровывания данных с помощью алгоритма симметричного шифрования.

Во всех этих случаях совершенно необходимы подтверждение целостности и установление принадлежности открытого ключа конкретному пользователю. Некая третья доверенная сторона (Trusted Third Party, TTP), в данном случае CA, должна подтвердить, что владелец открытого ключа — это именно тот пользователь, информация о котором содержится в сертификате, а также что открытый ключ соответствует секретному ключу данного пользователя.

Таким образом, цифровой сертификат содержит три главные составляющие: открытый ключ пользователя, информацию о пользователе — владельце сертификата, сертифицирующую ЭЦП двух предыдущих составляющих (вычисленную на секретном ключе CA).

PKI подразумевает, что все сертификаты конкретной PKI (а свою PKI может иметь любая организация или компания) организованы в иерархическую структуру.

Иерархическая схема PKI предусматривает существование четырех типов сертификатов.

Сертификат пользователя — описан выше

Сертификат CA — должен быть доступен для проверки ЭЦП сертификата пользователя и, в свою очередь, должен быть подписан секретным ключом CA верхнего уровня. При этом данную ЭЦП (подписанную секретным ключом CA верхнего уровня) также следует проверять, а потому необходимо, чтобы был доступен сертификат CA верхнего уровня и т. д.

Самоподписанный сертификат — корневой для всей PKI. Это по определению доверенный сертификат: если результат проверки цепочки сертификатов CA показывает, что один из них подписан корневым секретным ключом, процесс проверки ЭЦП сертификатов на этом завершается.

Кросс-сертификат можно назвать средством расширения, поскольку он позволяет распространить действие конкретной PKI на другую путем взаимоподписания корневых сертификатов двух PKI.

Процедура проверки ЭЦП электронного документа происходит в системе PKI следующим образом. Сначала проверяется ЭЦП конкретного документа, а затем ЭЦП сертификата, с помощью которого проверялась предыдущая ЭЦП. Последняя проверка повторяется в цикле до тех пор, пока цепочка сертификатов не приведет к корневому.

ЭЦП документа признается верной лишь в том случае, если верна не только она, но и все проверяемые в данном процессе ЭЦП сертификатов. При обнаружении неверной ЭЦП любого из сертификатов неверными считаются все ЭЦП, проверенные на предыдущих шагах.

Заметим, что корневых сертификатов может быть несколько: каждая организация (или организационная единица) вправе устанавливать свои корневые сертификаты (один или несколько). Стандартом предусмотрено и наличие корневого сертификата для всего сообщества пользователей Интернета.

7.3. Формат электронных сертификатов, расширения сертификатов, отзыв сертификатов

В настоящее время для сертификации открытых ключей применяется формат электронных сертификатов X.509 (стандарт X.509 версии 3). В предыдущей, второй, версии отсутствовали расширения, а в версии 1 – еще и ряд дополнительных полей. В X.509 версии 3 определено, что в цифровом сертификате обязательно присутствие следующих полей:

  • номер версии формата, которому соответствует сертификат;
  • серийный номер сертификата – уникальный номер, присваиваемый каждому сертификату, выпускаемому конкретным CA;
  • идентификатор CA, который выпустил данный сертификат (т. е. сгенерировал пару ключей и подписал открытый ключ). Данное поле в паре с предыдущим образуют уникальный идентификатор сертификата;
  • срок действия сертификата, указывающий диапазон дат начала и окончания действия данного сертификата;
  • персональные данные пользователя, которому принадлежит сертификат, и собственно открытый ключ пользователя;
  • расширения формата, код алгоритма, примененного при вычислении сертифицирующей ЭЦП, и сертифицирующая ЭЦП.

Все поля сертификата записываются по принципу TLV (tag-length-value - код-длина-идентификатор), который в настоящее время широко применяется для различных форматных записей, особенно в области коммуникаций.

Отметим также, что в третьей версии X.509 указано, что не следует более издавать сертификаты версии 2, а версия 1 сохраняется только для обеспечения совместимости с существующими приложениями, которые используют сертификаты X.509 данной версии.

Расширения сертификатов версии 3 существенно увеличивают возможности обработки сертификатов, позволяя уточнить правила и области применения конкретного сертификата и задать необходимые параметры. Приведем лишь основные расширения, предусмотренные стандартом.

Идентификатор ключа CA дает возможность указать конкретный секретный ключ центра сертификации, на котором вычислялась ЭЦП данного сертификата, из существующего набора ключей CA (каждый CA может иметь несколько ключей).

Назначение ключа характеризует область его применения. Фактически в данное поле записана битовая маска, которая определяет одну или несколько возможных целей использования данного сертификата и парного ему секретного ключа. В число возможных вариантов входят вычисление и проверка ЭЦП, шифрование данных, шифрование других ключей, сертификация ключей и т. д.

См. подробнее в хрестоматии

В дополнение к указанным основным расширениям формата стандарт X.509 устанавливает ряд других. Более того, любая PKI-система (например, инфраструктура открытых ключей конкретной организации) может вводить свои расширения, в зависимости от конкретных условий применения цифровых сертификатов.

Любой сертификат может быть отозван раньше времени окончания срока его действия (что означает запрет на его использование в дальнейшем), как минимум, по одной из двух причин: скомпрометирован соответствующий сертификату секретный ключ или изменились персональные данные владельца сертификата. Стандарт X.509 предусматривает, что CA регулярно публикуют списки отозванных сертификатов (Certificate Revocation List, CRL), если не используются иные методы приостановки действия сертификатов. CRL может быть и пустым, если в отзыве нет необходимости. Во избежание ложных отзывов сертификатов каждый CRL снабжается сертифицирующей ЭЦП CA, который его выпустил. Любое PKI-ориентированное приложение в процессе проверки ЭЦП цепочки сертификатов (например, согласно описанному выше алгоритму проверки ЭЦП электронного документа) обязано также проверять отсутствие всех сертификатов проверяемой цепочки в текущих CRL. В случае обнаружения отозванного сертификата все ЭЦП, проверенные на предыдущих шагах, считаются неверными.

При приобретении и использовании электронной подписи у пользователей возникает множество вопросов. Сколько электронных подписей может быть у одного человека? С какого возраста можно получить электронную подпись? Можно ли подписать документ электронной подписью, выданной в другом государстве? И так далее. Мы собрали ответы на самые популярные вопросы пользователей об ЭЦП на этой страничке и предлагаем вам с ними ознакомиться.

Исключением является случай, когда в соответствии с федеральными законами или принимаемыми в соответствии с ним НПА документ должен быть составлен исключительно на бумажном носителе.

Электронные документы, подписанные другими видами электронных подписей (усиленная неквалифицированная и простая), признаются равнозначными документам на бумажном носителе, подписанным собственноручно, в случаях и в порядке, предусмотренных нормативными актами или соглашениями участников электронного взаимодействия.

Можно ли внести изменения в текст документа, который уже подписан электронной подписью так, чтобы никто не узнал?

Нет, это исключено. Каждое несанкционированное изменение будет автоматически выявлено при первой же проверке ЭП.

Согласно ч. 2 ст. 18 Закона № 63-ФЗ при обращении в аккредитованный удостоверяющий центр для получения квалифицированного сертификата ключа проверки электронной подписи заявитель — физическое лицо представляет следующие документы, подтверждающие достоверность информации, включаемой в сертификат: основной документ, удостоверяющий личность (то есть паспорт гражданина РФ — выдается лицам, достигшим 14-ти лет), и страховое свидетельство государственного пенсионного страхования заявителя (выдается всем гражданам РФ).

Учитывая изложенное, граждане РФ вправе получить квалифицированный сертификат ключа проверки электронной подписи при достижении ими возраста 14-ти лет.

Будет ли документ иметь юридическую силу, если он подписан электронной подписью, выданной в иностранном государстве?

Электронные подписи, созданные в соответствии с нормами права иностранного государства и международными стандартами, в Российской Федерации признаются электронными подписями того вида, признакам которого они соответствуют на основании настоящего Федерального закона. (ст. 7 ФЗ № 63). Соответственно, иностранная ЭП не будет признана квалифицированной электронной подписью, т.к. она никогда не будет соответствовать требованиям ч. 4 ст. 5 указанного закона.

Данная электронная подпись будет приравнена к неквалифицированной электронной подписи и согласно ч. 2 ст. 6 ФЗ № 63 информация в электронной форме, подписанная простой электронной подписью или неквалифицированной электронной подписью, признается электронным документом, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, в случаях, установленных федеральными законами, принимаемыми в соответствии с ними нормативными правовыми актами или соглашением между участниками электронного взаимодействия.

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

Если вы планируете продолжить пользоваться электронной подписью после окончания срока ее действия, необходимо пройти процедуру перевыпуска. Схема действий и стоимость ЭП полностью аналогичны первичному получению.

Если у Вас отсутствует сертификат ключа проверки электронной подписи в виде отдельного файла с расширением .cer, но одновременно с подписанным документом имеется файл с расширением .sig (отсоединенная электронная подпись), то Вы можете установить удостоверяющий центр, выдавший сертификат ключа проверки электронной подписи с помощью средства электронной подписи.

Сертификат должен содержать достоверную на момент создания сертификата информацию о владельце. Изменить, в целях актуализации, информацию в сертификате невозможно. Т.е. актуализировать информацию в сертификате можно только через отзыв/аннулирование действующего и изготовление нового сертификата.

Отозвать/аннулировать сертификат можно только по причинам, перечисленным в 63-ФЗ или по желанию владельца сертификата. Среди причин отзыва/аннулирования сертификата, перечисленных в 63-ФЗ, нет такой причины, как актуализация информации. Поэтому в случае смены юр.адреса действующий сертификат меняется только если захочет владелец сертификата. Использование сертификата со старым юр.адресом, если нет соответствующего заявления о внеплановой смене сертификата, не влечет никаких правовых последствий для удостоверяющего центра.

Нужно ли уполномоченному представителю юридического лица менять электронную подпись при изменении организационной формы предприятия с ОАО на ПАО?

В случае приобретения ЭП и защищенного USB-токена в офисе Компании, в нашем удостоверяющем центре, и записи ее на защищенный USB-токен, пин-код на носителе остается стандартный. Ниже представлена информация о PIN-кодах по умолчанию.

Рутокен: 12345678
ESMART: 12345678

Можно ли скопировать и перенести сертификат с защищенного USB-токена на обычную флеш-карту (USB-носитель) и пользоваться ей? Безопасно ли это?

Теоретически скопировать и поместить содержимое защищенного USB-токена на флеш-карту реально при наличии ряда факторов. Однако мы не рекомендуем производить подобных действий.

Хранение сертификата ключа на незашифрованном USB-носителе может скомпрометировать ЭП, что, впоследствии, приведет к необходимости ее перевыпуска.

Токены обеспечивают криптографическую защиту хранимой информации. Другими словами, они гораздо надежнее защищают ключ от попадания в чужие руки и от несанкционированного использования, нежели обычный USB-носитель.

Носитель электронной подписи был утерян, а его пропажа была обнаружена спустя три месяца. Что делать?

Статьей 10 Федерального закона от 06.04.2011 №63-ФЗ «Об электронной подписи (далее - Федеральный закон №63-ФЗ) установлена обязанность участников электронного взаимодействия обеспечивать конфиденциальность ключей электронных подписей, в частности не допускать использование принадлежащих им ключей электронных подписей без их согласия, а также запрет на использование ключа электронной подписи при наличии оснований полагать, что конфиденциальность данного ключа нарушена.

Учитывая, что потеря ключевого носителя влечет возможность несанкционированного доступа к записанному на нем ключу электронной подписи, потеря ключевого носителя, даже при его последующем обнаружении, признается нарушением конфиденциальности. В связи с этим, Вам необходимо прекратить использование такой электронной подписи и в соответствии с пунктом 2 статьи 10 Федерального закона от 06.04.2011 №63-ФЗ уведомить удостоверяющий центр, выдавший сертификат ключа проверки электронной подписи, и иных участников электронного взаимодействия о нарушении конфиденциальности ключа электронной подписи.

Конкретный порядок действий по уведомлению Вам необходимо уточнить в удостоверяющем центре, выдавшем сертификат ключа проверки электронной подписи, соответствующий скомпрометированному ключу электронной подписи. Однако если Вы уверены, что за это время электронная подпись не была скомпроментирована (то есть ею никто не мог воспользоваться), можете продолжить ее использование до окончания срока действия.

Читайте также: