Содержание
Приложение А(обязательное)
А.1 Содержание и защита журнала аудита УЦ и ЦР
А.1.1 Общая информацияЗаписи журнала аудита должны быть идентифицированы в отношении источника, даты и номера записи. В журнал аудита следует вносить только подтверждаемую и необходимую для журнала аудита информацию.Большинство записей заносится в журнал аудита автоматически, однако некоторые важные, связанные с безопасностью, события могут вноситься вручную.Также должны быть учтены положения 5.4.1 (последний абзац).
а) дата и время записи;
б) регистрационный или порядковый номер записи;
в) тип записи;
г) источник (терминал, порт, местонахождение, клиент и т.д.);
д) идентификационные данные юридического или физического лица, делающего запись в журнале.Записи, сделанные в журнале вручную, должны, при необходимости, включать следующее:- идентификационные данные юридического или физического лица, санкционирующего операцию, и юридических или физических лиц, обрабатывающих любую ключевую информацию (например, части ключей или ключи, хранящиеся в портативных устройствах или на носителях информации);- сведения об устройствах или носителях, на которых хранятся ключи.
а) тип идентификационного(ых) документа(ов), представленного юридическим или физическим лицом, обратившимся в УЦ;
б) запись уникальных идентификационных данных, номеров или их комбинации (например, номер документа, удостоверяющего юридическое или физическое лицо, обратившееся в УЦ), если это необходимо;
в) место хранения копий заявок на сертификат (на его создание, продление и т.п.) и идентификационных документов;
г) идентификационные данные лица, принявшего заявку на сертификат;
д) метод, используемый для проверки идентификационных документов, если таковые имеются;
е) наименование УЦ (ЦР), непосредственно принявшего запрос на сертификат ключа проверки электронной подписи от конечного владельца сертификата;
ж) о принятии владельцем сертификата ключа проверки электронной подписи пользовательского договора;
з) о согласии юридического или физического лица, обратившегося в УЦ, на ведение УЦ записей, содержащих персональные данные, и передачу этой информации указанным третьим сторонам; а также публикацию сертификатов ключей проверки электронной подписи (когда это требуется в соответствии с законодательством).
а) создание ключей;
б) установка криптографических ключей вручную и ее результаты (с идентификационными данными оператора);
в) резервное копирование;
г) хранение;
д) восстановление;
е) изъятие ключевой информации из обслуживания;
ж) условное депонирование;
з) архивирование;
и) уничтожение;
к) формирование сертификатов;
л) получение запросов на сертификат(ы) ключа проверки электронной подписи, включая первичные запросы, запросы на продление и запросы на замену;
м) запросы на прекращение и приостановку действия сертификата;
н) прекращение, приостановка и восстановление действия сертификата;
о) получение, формирование и отправление САС;
п) распределение ключа проверки электронной подписи УЦ;
р) предоставление ключей проверки электронной подписи для сертификатов ключей проверки электронной подписи;
с) действия, принятые при компрометации ключа электронной подписи.
а) чтение или запись конфиденциальных файлов или документов;
б) действия с критически важными по отношению к безопасности данными;
в) изменения в профиле безопасности;
г) использование механизмов идентификации и аутентификации, как успешное, так и неудачное (включая многократные неудачные попытки аутентификации);
д) важные по отношению к безопасности нефинансовые транзакции (например, изменения учетной записи или имени/адреса и т.п.);
е) отказ системы, сбои аппаратных средств и другие нештатные ситуации;
ж) действия, предпринимаемые лицами, исполняющими доверенные роли: операторов компьютеров, системных администраторов и должностных лиц, обеспечивающих информационную безопасность систем;
з) изменение принадлежности юридического или физического лица;
и) доступ к журналу аудита;
к) действия, связанные с обходом процессов или процедур шифрования/аутентификации;
л) доступ к системе УЦ или какому-либо из ее компонентов.
а) все сообщения/данные (в электронном виде), входящие (исходящие) в (из) УЦ (включая САС);
б) все сформированные сертификаты ключей проверки электронной подписи;
в) идентификационные данные используемых криптографических ключей и их хэш (где это применимо);_______________ Контрольные числа, полученные из криптографических ключей с использованием функции хэширования, должны быть внесены в журнал аудита в качестве средства идентификации ключей и проверки их корректности.
г) идентификационные данные лиц, получающих части ключей.
А.2 Резервное копирование журнала аудита Данные журнала аудита УЦ и ЦР должны подвергаться резервному копированию через соответствующие промежутки времени, а созданные копии следует хранить вне места эксплуатации.
а) необычное потребление системных ресурсов;
б) внезапное, неожиданное увеличение объема трафика и т.п.;
в) доступ в необычное время из необычных мест.
Принцип работы
Наглядное объяснение принципа работы сертификатов открытого ключа на примере установки ПО от стороннего разработчика пользователем в Интернете
Сертификаты, как правило, используются для обмена зашифрованными данными в больших сетях. Криптосистема с открытым ключом решает проблему обмена секретными ключами между участниками безопасного обмена, однако не решает проблему доверия к открытым ключам. Предположим, что Алиса, желая получать зашифрованные сообщения, генерирует пару ключей, один из которых (открытый) она публикует каким-либо образом.
Любой, кто желает отправить ей конфиденциальное сообщение, имеет возможность зашифровать его этим ключом, и быть уверенным, что только она (так как только она обладает соответствующим секретным ключом) сможет это сообщение прочесть. Однако описанная схема ничем не может помешать злоумышленнику Давиду создать пару ключей, и опубликовать свой открытый ключ, выдав его за ключ Алисы.
Идея сертификата — это наличие третьей стороны, которой доверяют две другие стороны информационного обмена. Предполагается, что таких третьих сторон немного, и их открытые ключи всем известны каким-либо способом, например, хранятся в операционной системе или публикуются в журналах. Таким образом, подлог открытого ключа третьей стороны легко выявляется.
Сертификат открытого ключа выдаётся центром сертификации и состоит из таких полей как:
- сам открытый ключ владельца сертификата,
- срок действия,
- имя эмитента (центра сертификации),
- имя владельца сертификата
- и, самой важной части, цифровой подписи.
Цифровая подпись гарантирует невозможность подделки сертификата. Она является результатом криптографической хеш-функции от данных сертификата, зашифрованным закрытым ключом центра сертификации. Открытый ключ центра сертификации является общеизвестным, поэтому любой может расшифровать им цифровую подпись сертификата, затем вычислить хеш самостоятельно и сравнить, совпадают ли хеши.
Если Алиса сформирует сертификат со своим публичным ключом, и этот сертификат будет подписан третьей стороной (например, Трентом), любой, доверяющий Тренту, сможет удостовериться в подлинности открытого ключа Алисы. В централизованной инфраструктуре в роли Трента выступает удостоверяющий центр. В сетях доверия Трент может быть любым пользователем, и следует ли доверять этому пользователю, удостоверившему ключ Алисы, решает сам отправитель сообщения.
В SSL используется целая цепочка доверия: сертификат подписывается закрытым ключом владельца сертификата, находящегося выше в цепи.[1]
Сертификаты, как правило, используются для обмена зашифрованными данными в больших сетях. Криптосистема с открытым ключом решает проблему обмена секретными ключами между участниками безопасного обмена, однако не решает проблему доверия к открытым ключам. Предположим, что Алиса, желая получать зашифрованные сообщения, генерирует пару ключей, один из которых (открытый) она публикует каким-либо образом.
Любой, кто желает отправить ей конфиденциальное сообщение, имеет возможность зашифровать его этим ключом, и быть уверенным, что только она (так как только она обладает соответствующим секретным ключом) сможет это сообщение прочесть. Однако описанная схема ничем не может помешать злоумышленнику Давиду создать пару ключей, и опубликовать свой открытый ключ, выдав его за ключ Алисы.
Идея сертификата — это наличие третьей стороны, которой доверяют две другие стороны информационного обмена. Предполагается, что таких третьих сторон немного, и их открытые ключи всем известны каким-либо способом, например, хранятся в операционной системе или публикуются в журналах. Таким образом, подлог открытого ключа третьей стороны легко выявляется.
Если Алиса сформирует сертификат со своим публичным ключом, и этот сертификат будет подписан третьей стороной (например, Трентом), любой, доверяющий Тренту, сможет удостовериться в подлинности открытого ключа Алисы. В централизованной инфраструктуре в роли Трента выступает удостоверяющий центр. В сетях доверия Трент может быть любым пользователем, и следует ли доверять этому пользователю, удостоверившему ключ Алисы, решает сам отправитель сообщения.
Формальное описание
Пусть имеются две стороны информационного обмена — A{displaystyle A}, B{displaystyle B}, желающие обмениваться сообщениями конфиденциально, и третья сторона T{displaystyle T} (играющая роль удостоверяющего центра), которой доверяют A{displaystyle A} и B{displaystyle B}.
- Стороне A{displaystyle A} принадлежит пара ключей (KAo{displaystyle KA_{o}}, KAs{displaystyle KA_{s}}), где KAo{displaystyle KA_{o}} — открытый ключ, а KAs{displaystyle KA_{s}} — закрытый (секретный) ключ стороны A{displaystyle A}.
- Стороне 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} содержит:
- ключ KAo{displaystyle KA_{o}},
- идентификационные данные субъекта A{displaystyle A},
- идентификационные данные удостоверяющей стороны T{displaystyle T},
- подпись стороны T{displaystyle T}, которую обозначим ST{displaystyle ST}. Подпись ST{displaystyle ST} — это хеш (набор символов, хеш-сумма/хеш-код), полученный в результате применения хеш-функции к данным сертификата C{displaystyle C}, зашифрованный стороной T{displaystyle T} с использованием своего закрытого ключа KTs{displaystyle KT_{s}}.
- и другую информацию.
A{displaystyle A} посылает стороне B{displaystyle B} свой сертификат C{displaystyle C}. B{displaystyle B} проверяет цифровую подпись ST{displaystyle ST}. Для этого B{displaystyle B}
- самостоятельно вычисляет хеш от данных сертификата C{displaystyle C},
- расшифровывает ЭЦП сертификата ST{displaystyle ST} с помощью всем известного KTo{displaystyle KT_{o}}, получив другой хеш,
- проверяет равенство этих двух хешей.
Если полученные хеши равны – ЭЦП корректна, а это подтверждает, что 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.
Российские стандарты
В России действуют свои криптографические стандарты. Использование их совместно с сертификатами описано в 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 января текущего года, и по выпускам ежемесячного информационного указателя “Национальные стандарты” за текущий год.
Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия).
Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
