Сертификат электронной подписи: создание, получение, требования

Содержание

Приложение А(обязательное)

А.1 Содержание и защита журнала аудита УЦ и ЦР

https://www.youtube.com/watch?v=ytdevru

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

а) дата и время записи;

б) регистрационный или порядковый номер записи;

в) тип записи;

г) источник (терминал, порт, местонахождение, клиент и т.д.);

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

а) тип идентификационного(ых) документа(ов), представленного юридическим или физическим лицом, обратившимся в УЦ;

б) запись уникальных идентификационных данных, номеров или их комбинации (например, номер документа, удостоверяющего юридическое или физическое лицо, обратившееся в УЦ), если это необходимо;

в) место хранения копий заявок на сертификат (на его создание, продление и т.п.) и идентификационных документов;

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

д) метод, используемый для проверки идентификационных документов, если таковые имеются;

е) наименование УЦ (ЦР), непосредственно принявшего запрос на сертификат ключа проверки электронной подписи от конечного владельца сертификата;

https://www.youtube.com/watch?v=ytadvertiseru

ж) о принятии владельцем сертификата ключа проверки электронной подписи пользовательского договора;

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

а) создание ключей;

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

в) резервное копирование;

г) хранение;

д) восстановление;

е) изъятие ключевой информации из обслуживания;

ж) условное депонирование;

з) архивирование;

и) уничтожение;

к) формирование сертификатов;

л) получение запросов на сертификат(ы) ключа проверки электронной подписи, включая первичные запросы, запросы на продление и запросы на замену;

м) запросы на прекращение и приостановку действия сертификата;

н) прекращение, приостановка и восстановление действия сертификата;

о) получение, формирование и отправление САС;

https://www.youtube.com/watch?v=ytcreatorsru

п) распределение ключа проверки электронной подписи УЦ;

р) предоставление ключей проверки электронной подписи для сертификатов ключей проверки электронной подписи;

с) действия, принятые при компрометации ключа электронной подписи.

а) чтение или запись конфиденциальных файлов или документов;

б) действия с критически важными по отношению к безопасности данными;

в) изменения в профиле безопасности;

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

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

е) отказ системы, сбои аппаратных средств и другие нештатные ситуации;

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

з) изменение принадлежности юридического или физического лица;

и) доступ к журналу аудита;

https://www.youtube.com/watch?v=ytaboutru

к) действия, связанные с обходом процессов или процедур шифрования/аутентификации;

л) доступ к системе УЦ или какому-либо из ее компонентов.

а) все сообщения/данные (в электронном виде), входящие (исходящие) в (из) УЦ (включая САС);

б) все сформированные сертификаты ключей проверки электронной подписи;

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

г) идентификационные данные лиц, получающих части ключей.

А.2 Резервное копирование журнала аудита Данные журнала аудита УЦ и ЦР должны подвергаться резервному копированию через соответствующие промежутки времени, а созданные копии следует хранить вне места эксплуатации.

а) необычное потребление системных ресурсов;

б) внезапное, неожиданное увеличение объема трафика и т.п.;

в) доступ в необычное время из необычных мест.

Неквалифицированная электронная подпись, или НЭП

https://www.youtube.com/watch?v=ytcopyrightru

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

Человек получает в удостоверяющем центре два ключа электронной подписи: закрытый и открытый. Закрытый ключ хранится на специальном ключевом носителе с пин-кодом или в компьютере пользователя — он известен только владельцу и его нужно держать в тайне. С помощью закрытого ключа владелец генерирует электронные подписи, которыми подписывает документы.

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

То, что открытый ключ принадлежит владельцу закрытого ключа, прописывается в сертификате электронной подписи. Сертификат также выдается удостоверяющим центром. Но при использовании НЭП сертификат можно не создавать. Требования к структуре неквалифицированного сертификата не установлены в федеральном законе № 63-ФЗ “Об электронной подписи”.

Где используется?

НЭП можно использовать для внутреннего и внешнего ЭДО, если стороны предварительно договорились об этом.

Юридическая сила

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

Принцип работы

Наглядное объяснение принципа работы сертификатов открытого ключа на примере установки ПО от стороннего разработчика пользователем в Интернете

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

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

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

Сертификат открытого ключа выдаётся центром сертификации и состоит из таких полей как:

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

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

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

В SSL используется целая цепочка доверия: сертификат подписывается закрытым ключом владельца сертификата, находящегося выше в цепи.[1]

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

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

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

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

Квалифицированная электронная подпись, или КЭП

Юридическая сила

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

• Обязательно имеет квалифицированный сертификат в бумажном или электронном виде, структура которого определена приказом ФСБ России № 795 от 27.12.2011.
• Программное обеспечение для работы с КЭП сертифицировано ФСБ России.
• Выдавать КЭП может только удостоверяющий центр, который аккредитован Минкомсвязи России.

Получить квалифицированную электронную подпись

Где используется?

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

Юридическая сила

КЭП — это подпись, которая придает документам юридическую силу без дополнительных условий.  Если организации ведут ЭДО, подписывая документы КЭП,  их юридическая сила признается автоматически согласно федеральному закону № 63-ФЗ “Об электронной подписи”.

Формальное описание

https://www.youtube.com/watch?v=ytpolicyandsafetyru

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

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

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

Затем с помощью широко известного проверяется подпись стороны . Если подпись корректна — значит действительно прошел регистрацию у .

Пусть имеются две стороны информационного обмена — A{displaystyle A}, B{displaystyle B}, желающие обмениваться сообщениями конфиденциально, и третья сторона T{displaystyle T} (играющая роль удостоверяющего центра), которой доверяют A{displaystyle A} и B{displaystyle B}.

1. Стороне A{displaystyle A} принадлежит пара ключей (KAo{displaystyle KA_{o}}, KAs{displaystyle KA_{s}}), где KAo{displaystyle KA_{o}} — открытый ключ, а KAs{displaystyle KA_{s}} — закрытый (секретный) ключ стороны A{displaystyle A}.
2. Стороне T{displaystyle T} принадлежит пара ключей (KTo{displaystyle KT_{o}}, KTs{displaystyle KT_{s}}).

A{displaystyle A} регистрируется у T{displaystyle T} (посылает запрос на подпись), указывая данные о себе и свой KAo{displaystyle KA_{o}}. Сторона T{displaystyle T} посредством определенных механизмов “удостоверяет личность” стороны A{displaystyle A} и выдает стороне A{displaystyle A} сертификат C{displaystyle C}, устанавливающий соответствие между субъектом A{displaystyle A} и ключом KAo{displaystyle KA_{o}}. Сертификат C{displaystyle C} содержит:

1. ключ KAo{displaystyle KA_{o}},
2. идентификационные данные субъекта A{displaystyle A},
3. идентификационные данные удостоверяющей стороны T{displaystyle T},
4. подпись стороны T{displaystyle T}, которую обозначим ST{displaystyle ST}. Подпись ST{displaystyle ST} — это хеш (набор символов, хеш-сумма/хеш-код), полученный в результате применения хеш-функции к данным сертификата C{displaystyle C}, зашифрованный стороной T{displaystyle T} с использованием своего закрытого ключа KTs{displaystyle KT_{s}}.
5. и другую информацию.

A{displaystyle A} посылает стороне B{displaystyle B} свой сертификат C{displaystyle C}. B{displaystyle B} проверяет цифровую подпись ST{displaystyle ST}. Для этого B{displaystyle B}

1. самостоятельно вычисляет хеш от данных сертификата C{displaystyle C},
2. расшифровывает ЭЦП сертификата ST{displaystyle ST} с помощью всем известного KTo{displaystyle KT_{o}}, получив другой хеш,
3. проверяет равенство этих двух хешей.

Если полученные хеши равны – ЭЦП корректна, а это подтверждает, что KAo{displaystyle KA_{o}} действительно принадлежит A{displaystyle A}.

Теперь B{displaystyle B}, зная открытый ключ A{displaystyle A} и зная, что он принадлежит именно A{displaystyle A}, может шифровать этим открытым ключом все последующие сообщения для A{displaystyle A}. И только A{displaystyle A} сможет их расшифровать, так как KAs{displaystyle KA_{s}} известен только A{displaystyle A}.

Введение

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

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

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

Структура сертификата

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

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

4.1 Обзор

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

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

Аутентификация ключей проверки электронной подписи является необходимым условием, и поэтому такие ключи находятся в сертификатах ключей проверки электронной подписи. Сертификат ключа проверки электронной подписи содержит ключ проверки электронной подписи и идентификационные данные, а также электронную подпись УЦ. Настоящий стандарт основан на ГОСТ Р ИСО/МЭК 9594-8 в части аутентификации в открытых системах.

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

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

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

1 Область применения

Настоящий стандарт определяет систему управления сертификатами ключей проверки электронной подписи для использования в сфере финансовой деятельности юридическими и физическими лицами, включающую:- содержание (данные) запроса на сертификат ключа проверки электронной подписи;- типы систем удостоверяющих центров;

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

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

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

Российские стандарты

В России действуют свои криптографические стандарты. Использование их совместно с сертификатами описано в RFC4491: Using GOST with PKIX.

В России действуют свои криптографические стандарты. Использование их совместно с сертификатами описано в RFC4491: Using GOST with PKIX.

Ссылки

Эта страница в последний раз была отредактирована 9 октября 2019 в 07:03.

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:ГОСТ Р ИСО/МЭК 8824-1-2001 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотацииГОСТ Р ИСО/МЭК 8824-2-2001 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 2.

Спецификация информационного объектаГОСТ Р ИСО/МЭК 8824-3-2002 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 3. Спецификация ограниченияГОСТ Р ИСО/МЭК 8824-4-2003 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 4. Параметризация спецификации АСН.

1ГОСТ Р ИСО/МЭК 8825-1-2003 Информационная технология. Правила кодирования АСН.1. Часть 1. Спецификация базовых (BER), канонических (CER) и отличительных (DER) правил кодированияГОСТ Р ИСО/МЭК 8825-2-2003 Информационная технология. Правила кодирования АСН.1. Часть 2. Спецификация правил уплотненного кодирования (PER)ГОСТ Р ИСО/МЭК 9594-8-98 Информационная технология.

Взаимосвязь открытых систем. Справочник. Часть 8. Основы аутентификацииПримечание – При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования – на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю “Национальные стандарты”, который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя “Национальные стандарты” за текущий год.

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

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

3 Термины и определения

https://www.youtube.com/watch?v=upload

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

3.1 владелецсертификата ключа проверки электронной подписи;владелец сертификата (public key certificate subject): Юридическое или физическое лицо, которому выдан сертификат ключа проверки электронной подписи.

3.2 восстановление действия сертификата (ключа проверки электронной подписи) (public key certificate release): Восстановление удостоверяющим центром действия сертификата ключа проверки электронной подписи, действие которого было приостановлено этим удостоверяющим центром.

3.3 данные запроса на сертификат (ключа проверки электронной подписи) (request data on public key certificate): Подписанная информация в запросе на сертификат ключа проверки электронной подписи, включающая ключ проверки электронной подписи физического или юридического лица, идентификационные данные этого лица и другую информацию, включаемую в сертификат.

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

3.5 доверенный ключ проверки электронной подписи (trusted certification authority public key): Ключ проверки электронной подписи, полученный доверенным образом и используемый для проверки первого сертификата ключа проверки электронной подписи в цепочке сертификатов ключей проверки электронной подписи при проверке цепочки сертификатов.

3.6 журнал аудита (audit journal): Хронологическая запись системной активности, достаточная, чтобы позволить реконструкцию, анализ и изучение последовательности условий и действий, окружающих или приводящих к каждому событию в ходе транзакции от ее начала и до вывода окончательных результатов.

3.7 замена сертификата (ключа проверки электронной подписи) (public key certificate re-key): Процесс, при котором владелец сертификата ключа проверки электронной подписи получает новый сертификат ключа проверки электронной подписи на новый ключ проверки электронной подписи после создания новой пары ключей.

3.8 ключ проверки электронной подписи (public key): Уникальная последовательность символов, однозначно связанная с ключом электронной подписи и предназначенная для проверки подлинности электронной подписи.Примечание – В настоящем стандарте в целях сохранения терминологической преемственности по отношению к действующим национальным правовым и нормативным документам, регулирующих отношения по использованию электронной подписи (например [1, 2]), и опубликованным научно-техническим изданиям установлено, что термины “ключ проверки электронной подписи” и “открытый ключ” являются синонимами.

3.9 ключ электронной подписи (private key): Уникальная последовательность символов, предназначенная для создания электронной подписи.

3.10 ключевая информация (keying material): Данные, необходимые для выполнения криптографических операций, например изготовления ключей.

3.11 конечный владелец сертификата ключа проверки электронной подписи:конечный владелец сертификата (end entity): Владелец сертификата ключа проверки электронной подписи, за исключением удостоверяющего центра, использующий свой ключ электронной подписи для целей, отличных от подписания сертификатов ключей проверки электронной подписи.

3.12 криптографический ключ (cryptographic key): Параметр, который определяет работу криптографической функции.Примечание – Криптографическая функция позволяет осуществить:- преобразование обычного текста в шифрованный текст и наоборот;- создание ключевой информации;- создание или проверку электронной подписи.

3.13 кросс-сертификация (cross-certification): Процесс, при котором два удостоверяющих центра взаимно подтверждают ключи проверки электронных подписей друг друга.

3.14 модуль ASN.1 (ASN.1 module): Совокупность идентифицируемых видов и значений абстрактной синтаксической нотации (ASN.1).

3.15 отличительное имя (distinguished name): Уникальный идентификатор владельца сертификата ключа проверки электронной подписи.Примечание – Методы определения глобальной уникальности имени выходят за рамки настоящего стандарта.

3.16 пара ключей (key pair): Совокупность ключа проверки электронной подписи и соответствующего ему ключа электронной подписи.

3.17 политика применения сертификатов (ключей проверки электронных подписей) (public key certificate policy): Поименованный набор правил, определяющий порядок применения сертификата ключа проверки электронной подписи, для определенной совокупности и (или) отдельного класса бизнес-приложений с едиными требованиями безопасности.Примечания

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

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

3.18 пользователь сертификата (relying party): Юридическое или физическое лицо, использующее сертификат ключа проверки электронной подписи для проверки электронной подписи.

3.19 приостановка действия сертификата (ключа проверки электронной подписи) (public key certificate suspension): Временное прекращение удостоверяющим центром действия сертификата ключа проверки электронной подписи.

3.20 продление сертификата (ключа проверки электронной подписи) (public key certificate renewal): Процесс, при котором юридическому или физическому лицу выдается новый сертификат существующего ключа проверки электронной подписи с новым сроком действия.

3.21 разделенное знание (split knowledge): Метод хранения криптографического ключа, при котором два (или более) физических или юридических лица по отдельности, имеют части ключа, которые, по отдельности, не дают никаких сведений о результирующем криптографическом ключе.

3.22 регламент выдачи сертификатов ключей проверки электронных подписей; РВС (public key certification practice statement): Совокупность правил, регулирующих порядок выдачи и управления сертификатами ключей проверки электронных подписей удостоверяющим центром на протяжении их жизненного цикла.

3.23 реестр сертификатов (ключей проверки электронных подписей) (public key certificate register): Совокупность данных, включающая список выданных удостоверяющим центром сертификатов ключей проверки электронных подписей и информацию, содержащуюся в этих сертификатах, а также информацию о датах прекращения действия или аннулирования сертификатов ключей проверки электронных подписей и об основаниях таких прекращений или аннулирований.

3.24 сертификат ключа проверки электронной подписи (public key certificate): Электронный документ или документ на бумажном носителе, выданные удостоверяющим центром либо доверенным лицом удостоверяющего центра и подтверждающие принадлежность ключа проверки электронной подписи владельцу данного сертификата ключа проверки электронной подписи.

3.25 сертификат ключа проверки электронной подписи удостоверяющего центра; сертификатУЦ (certification authority public key certificate): Сертификат ключа проверки электронной подписи, владельцем которого является удостоверяющий центр, чей ключ электронной подписи используется для подписания сертификатов ключей проверки электронной подписи.

3.26 система удостоверяющих центров;система УЦ (certification authority system): Совокупность удостоверяющих центров, которые управляют сертификатами ключей проверки электронных подписей (включая соответствующие им ключи проверки электронных подписей и ключи электронных подписей) на протяжении жизненного цикла сертификата ключа проверки электронной подписи.

3.27 список недействительных сертификатов ключей проверки электронных подписей; САС (public key certificate revocation/non-action list): Список сертификатов ключей проверки электронных подписей, объявленных недействительными.Примечание – Недействительными сертификатами являются сертификаты срок действия которых истек, приостановленные сертификаты и сертификаты, аннулированные по решению суда.

3.28 уведомление по дополнительному каналу (out-of-band notification): Уведомление с использованием средств связи, независимых от основных средств связи.

3.29 удостоверяющий центр; УЦ (certification authority): Юридическое лицо или индивидуальный предприниматель, осуществляющие функции по созданию и выдаче сертификатов ключей проверки электронных подписей, а также иные функции, предусмотренные национальным законодательством.

3.30 управление ключами (key management): Обращение с ключевой информацией и ключами на протяжении их жизненного цикла в соответствии с политикой безопасности.

3.31 часть ключа (key fragment): Фрагмент ключа, переданный на хранение юридическому или физическому лицу для реализации метода разделения знаний.

Приложение Д (справочное). Распределение сертификатов ключей проверки электронной подписи и САС

В Федеральном законе от 06.04.2011 № 63-ФЗ говорится о том, что для подтверждения принадлежности ключа проверки ЭП автору документа сертификат может не использоваться. Сейчас он требуется только для квалифицированной ЭП.

1) уникальный номер квалифицированного сертификата, даты начала и окончания его действия;

2) для физлица: ФИО и СНИЛС владельца сертификата;

для юрлица: наименование, место нахождения, ИНН и ОГРН владельца сертификата;

3) ключ проверки ЭП;

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

6) наименование и место нахождения аккредитованного УЦ, который выдал квалифицированный сертификат, номер квалифицированного сертификата УЦ;

7) ограничения использования квалифицированного сертификата.

Нужна электронная подпись? Подберите сертификат под вашу задачу 

Требования к форме квалифицированного сертификата установлены Приказом ФСБ РФ от 27.12.2011 № 795. Для ограничения использования сертификата есть, например, дополнение keyUsage, содержащее серию флагов, с помощью которых устанавливается, где ключ проверки электронной подписи не может применяться. Флаг keyCertSign в дополнении keyUsage означает, что область использования ключа включает проверку подписей под квалифицированными сертификатами.

4.1 Обзор

Приложение В(справочное)

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

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

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

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

В.2 Принятие данных запроса на сертификат ключа проверки электронной подписи от физического лица

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

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

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

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

В.3 Принятие данных запроса на сертификат ключа проверки электронной подписи от юридического лица

В.3.1 Для одноуровневого финансового учрежденияПример – Клиринговые расчетные палаты (например, CHIPS, CHAPS) и системы автоматизированных расчетов центральных банков._______________CHIPS (The Clearing House Interbank Payments System) – частная электронная система денежных переводов в США. CHAPS (The Clearing House Automated Payment System) – система клиринговых расчётов в Великобритании.

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

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

Приложение Г(справочное)

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

Для переоформления сертификатов ключей проверки электронной подписи может использовать методы с применением двух пар ключей проверки электронной подписи, т.е. пары первичных ключей (ключ проверки электронной подписи , ключ электронной подписи ) и пары вторичных ключей (,), например:- уведомление с помощью пары вторичных ключей (САС, подписанный с помощью вторичного ключа);

– переоформление сертификатов с помощью пары вторичных ключей ;- переоформление сертификатов ключей проверки электронной подписи с помощью пары новых первичных ключей ;- уведомление с помощью множества подписанных сертификатов ключей проверки электронной подписи.Указанные методы рассматриваются в Г.2-Г.

Ключ проверки электронной подписи проверяется на действительность вторичным ключом проверки электронной подписи ;- : Первичный сертификат ключа проверки электронной подписи подписывается с использованием первичного ключа электронной подписи ;- : Вторичный сертификат ключа проверки электронной подписи подписывается с использованием вторичного ключа электронной подписи .

Г.2 Уведомление с помощью пары вторичных ключей Когда новый конечный владелец сертификатов () представляет свой ключ проверки электронной подписи () , формирует первичный сертификат ключа проверки электронной подписи , подписанный с помощью первичного ключа электронной подписи , и вторичный сертификат ключа проверки электронной подписи , подписанный с помощью вторичного ключа электронной подписи .

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

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

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

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

Аккредитованный удостоверяющий центр

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

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

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

Подробно об обязанностях и функционале аккредитованного УЦ написано в ст. 15 Федерального закона от 06.04.2011 № 63-ФЗ.

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

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

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

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

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

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

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

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

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

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

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

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

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

5 Системы УЦ

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

5.2.1 Ответственность и характеристики УЦ

а) обеспечение безопасности ключа электронной подписи, связанного с ключом проверки электронной подписи, содержащимся в сертификате ключа проверки электронной подписи УЦ;

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

в) обеспечение отсутствия дублирования отличительного имени запрашивающей стороны с именем любого другого физического или юридического лица, сертификат ключа проверки электронной подписи которого был создан этим УЦ;

г) создание сертификатов ключа проверки электронной подписи с применением алгоритма электронной подписи к информации, указанной в сертификате ключа проверки электронной подписи;

д) поддержание механизма прекращения действия сертификатов и проверки, приемлемого для владельцев и пользователей сертификатов;

е) создание и распределение САС (см. приложение Д);

ж) создание пар ключей в соответствии с подробным сценарием процедуры создания ключей удостоверяющим центром и требованиями РВС;

з) разработку РВС и обеспечение его доступности для всех юридических и физических лиц;

и) обеспечение уверенности в том, что он владеет и управляет своими ключами электронной подписи;

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

а) имел достаточно ресурсов для поддержания своей деятельности в соответствии со своими обязанностями;

б) был способен в достаточной мере принять свой риск ответственности перед конечными владельцами сертификатов и пользователями сертификатов, как это диктуется политикой применения сертификатов;

в) применял кадровую политику, которая обеспечивает доверие к деятельности УЦ;

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

д) обеспечивал доступность своих сертификатов ключей проверки электронной подписи, ключа проверки электронной подписи и САС для пользователей сертификатов;

е) определял и документально оформлял внутренние политики функционирования для области действия УЦ и обеспечивал их доступность заинтересованным лицам;

ж) обеспечивал уверенность в соответствии всем надлежащим нормативным требованиям.Система УЦ должна обеспечить уверенность в том, что обязанности УЦ и ЦР (при его наличии) были определены.

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

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

в) извещать о создании сертификата ключа проверки электронной подписи сторону, указанную в сертификате ключа проверки электронной подписи (при необходимости);

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

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

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

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

з) информировать конечного владельца сертификата о том, что его работа определяется как скомпрометированная, если его ключ электронной подписи используется каким-либо другим юридическим или физическим лицом;

и) использовать соответствующие средства, чтобы убедиться в том, что конечный владелец сертификата понимает обязанности, сформулированные в 5.2.3, и в состоянии их выполнять;

к) в случае компрометации ключа электронной подписи УЦ незамедлительно информировать об этом владельцев и пользователей сертификатов в области действия УЦ;

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

а) обеспечивать уверенность в том, что ключ электронной подписи конечного владельца сертификата:- хранится в контролируемой зоне, установленной для средства, реализующего криптографические функции;- используется только уполномоченным лицом с применением надлежащих мер и средств контроля и управления доступом (например, пароля), согласно соответствующему РВС;

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

в) предпринимать действия по обеспечению конфиденциальности ключа электронной подписи для предотвращения несанкционированного использования и компрометации ключа в течение его жизненного цикла;

г) предпринимать действия по незамедлительному уведомлению УЦ, когда конечный владелец сертификата знает или подозревает о потере, раскрытии или иного рода компрометации своего ключа электронной подписи;

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

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

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

з) обеспечить уровень безопасности, требуемый РВС и определенный соответствующим договорным соглашением;

и) предоставлять точные и полные данные для запроса на сертификат;

к) сообщать в УЦ/ЦР о любых неточностях или изменениях в содержании сертификата ключа проверки электронной подписи (например, изменение фамилии и т.д.).

5.3.1 Создание

а) порядок создания, использования, хранения и уничтожения ключа электронной подписи УЦ определяется в соответствии с требованиями эксплуатационной документации на средства УЦ, реализующие криптографические функции, и нормативными требованиями соответствующих уполномоченных органов (например, требованиями [2]);

б) процесс создания ключа проверки электронной подписи/ключа электронной подписи должен обеспечивать уверенность в том, что ключевая информация соответствует требованиям к ключу проверки электронной подписи;

в) только УЦ должен иметь доступ к своему ключу электронной подписи;

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

https://www.youtube.com/watch?v=https:accounts.google.comServiceLogin

д) после истечения срока действия ключа все копии ключа электронной подписи УЦ (и частей ключа, если они существуют) должны оставаться надежно защищенными или должны быть уничтожены безопасным образом.