Сервисы безопасности. Валидация

Лекция 12. Сервисы безопасности. Валидация Сабанов Алексей Геннадьевич, к.т.н., доцент кафедры т ИУ-10 Сервис валидации • проверка действительности данных, связанных с подписанным сообщением или документом, а также сертификатов ключей подписи (RFC 2459). • Может проводиться по стандартизованному протоколу Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols (DVCS) с квитанцией за подписью сервера (RFC 3029). • Для проверки статуса сертификата также используется On-line Certificate Status Protocol - OCSP (RFC 2560). • Отдельно может проводиться проверка действительности сертификата открытого ключа – Validation of Public Key Certificates (VPKC) Назначение сервиса действительности (валидации) сертификата Сервис валидации предназначен для централизованной проверки действительности электронных удостоверений и сертификатов (полномочий и ЭП) субъекта ИС, а также для комплексной проверки ЭП и меток времени. В комплексную проверку действительности ЭП в качестве процедур входят проверки действительности сертификатов субъекта, создавшего подпись (полномочий и ЭП) и метки времени (при ее наличии). Назначение сервиса валидации – проверка действительности (или валидация): • электронных удостоверений доступа, требуемых для идентификации и аутентификации и авторизации субъекта доступа в ИС; • атрибутных сертификатов полномочий, требуемых для подтверждения полномочий доступа к ЭД или для его подписания; • сертификатов ключа проверки ЭП; • проверки штампов времени различного назначения; • комплексной проверки электронной подписи. Валидация цифрового сертификата Европейским институтом по стандартизации ETSI были выпущены рекомендации по реализации сервисов создания и валидации видов электронных подписей, форматы которых приняты в пределах Европейского союза: ETSI TS 119 102-1 V1.0.1 «Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation», 2015 [1]. ETSI TR 119 100 V1.1.1 «Electronic Signatures and Infrastructures (ESI); Guidance on the use of standards for signature creation and validation», 2016 [2]. ETSI TS 119 101 V1.1.1 «Electronic Signatures and Infrastructures (ESI); Policy and security requirements for applications for signature creation and signature validation», 2016 [3]. В соответствии с этими документами, сервис валидации представляет из себя сервис, который на основании предъявленного подписанного ЭД либо его хэш-кода и ЭП производит проверку действительности подписи и выпускает отчет по результатам проверки. Так как валидация сертификата ЭП входит в валидацию ЭП в качестве процедуры, правомерно использовать рекомендации ETSI в части, касающейся требований к содержанию проверок действительности сертификатов ЭП. Проверка действительности ЭП осуществляется в соответствии с политикой валидации. Политика валидации - совокупность правил, применимых к единичной ЭП или к набору взаимосвязанных ЭП, которые определяют технические и процедурные требования к валидации ЭП (набора взаимосвязанных ЭП), в соответствии с которыми ЭП (набор взаимосвязанных ЭП) может быть определена как действительная в целях удовлетворения потребностей бизнеса. Включает в себя (согласно рекомендация ETSI): Требования к криптографическим алгоритмам – включают требования к длине открытого ключа, содержащегося в сертификате; требования к используемым криптографическим алгоритмам и проч. Требования к параметрам цифрового сертификата – включают требования к корневым сертификатам; требования к цепочке сертификации; к формату и содержанию сертификата ЭП; требования к актуальности информации об отзыве сертификата ЭП и пр. Требования к валидации ЭП – включают требования к атрибутам субъекта, создавшего подпись; требования к меткам времени; требования к месту создания подписи; требования к формату ЭД и другим элементам, включаемым в ЭП. Перечень проверок Проверка формата сертификата ЭП: проверяется по формальным признакам (формат и структура файла -нотация); проверяется наличие обязательных полей и дополнений; проверяется содержание обязательных полей и дополнений. Имеется политика валидации для проверки сертификата ЭП, определяющая требования к проверке сертификата КС, сертификатов ЦС и криптографическим алгоритмам. Срок действия сертификата не истек. Сертификат не отозван, и информация об отзыве удовлетворяет требованиям к актуальности. Проверена цепочка сертификации. Срок действия сертификатов ЦС не истек. Ни один из сертификатов ЦС не отозван. Сертификаты ЦС соответствуют требованиям (ограничения по длине и проч.). Криптографическая проверка сертификата КС Криптографическая проверка целостности полей сертификата КС. Проверка требований к используемым криптографическим алгоритмам. Проверка требований к длине ключа проверки ЭП. Способы проверки статуса сертификата Критически важным является управление информацией о статусе отзыва сертификатов. Подтверждение статуса обеспечивают единственный способ проверки валидности сертификата при условии успешной верификации содержимого полей сертификата, его срока действия и криптографической целостности. В настоящее время службы подтверждения статуса отзыва цифрового сертификата подразделяются на службы, работающие в режиме on-line и offline. К off-line службам относятся списки отозванных сертификатов CRL и его сокращенные версии (Delta CRL). К on-line службам относят протоколы подтверждения статуса отзыва сертификата в режиме реального времени, в частности, протокол OCSP. Способы проверки статуса сертификата Список отозванных сертификатов (Certificate revocation list - CRL) стандартизован; содержит перечень серийных номеров действительных сертификатов, которые были отозваны по каким-либо причинам в пределах покрываемой данным CRL области (домене). CRL поддерживается Издателем PKI-сертификатов, регулярность обновлений определяется политикой Издателя (Удостоверяющего центра) и требованиями законодательства. Для получения информации о статусе отзыва сертификата клиент обращается к ресурсу, предоставляющему CRL, скачивает его и проверяет наличие серийного номера искомого сертификата. Delta CRL – список отозванных сертификатов меньшего размера, который содержит информацию о действительных сертификатах, статус отзыва которых был изменен с момента выпуска последнего актуального CRL. Delta CRL содержит ссылку на полный CRL. Для проверки статуса отзыва сертификата клиент обращается к ресурсу, который предоставляет Delta CRL, скачивает его и проверяет наличие серийного номера искомого сертификата. Распространение CRL может осуществляться по различным протоколам – LDAP (поверх транспортного протокола TCP), HTTP либо HTTPS, FTP другими. Один из недостатков использования CRL состоит в том, что процедура скачивания CRL и Delta CRL и поиска в нем искомого серийного номера крайне ресурсоемка, сильно зависит от емкости каналов связи и доступности ресурса, предоставляющего CRL либо Delta CRL OCSP-клиент 1. Генерация запроса 2. Подписание запроса (опционально) 3. Обмен сообщениями OCSP Сообщение >>> OCSP-запрос >>> <<< OCSP-ответ (ошибка) <<< 4. Проверка валидности OCSP-ответа <<< OCSP-ответ (статус) <<< OCSP-сервер 3. Проверка валидности запроса: 3.1. Запрос не валиден Генерация сообщения об ошибке (не подписывается сервером) 3.2. Запрос валиден Генерация ответа Подписание ответа Протокол подтверждения статуса сертификата в режиме реального времени (Online Certificate Status Protocol - OCSP) стандартизован. Он позволяет приложениям определять текущий статус (отзыва) сертификата в режиме on-line более быстрым способом, чем обращение к CRL. В протоколе участвует OCSP-сервер и OCSP-клиент, который обмениваются сообщениями (OCSP-запрос, OCSP-ответ) с информацией, требуемой для проверки статуса. Схема обмена сообщениями между OCSP-клиентом и OCSP-сервером представлена в таблице. При обращении к одной и той же базе отозванных сертификатов, поддерживаемой УЦ, приложение, использующее службу OCSP, получает информацию об актуальном статусе отзыва сертификата в режиме реального времени без необходимости синхронизации, загрузки и хранения информации из базы данных. Статус сертификата в OCSP-ответе Действителен (good) – положительный статус сертификата. Означает, что сертификат с заданным серийным номером не отозван в пределах интервала валидности ответа. В расширении может присутствовать информация, утверждающая другие статусы сертификата – был выпущен, действителен и др. Отозван (revoked) – сертификат с указанным серийным номером либо отозван, либо приостановлен. Может возвраться в случае, если CA не выпускал сертификата с таким серийным номером. Ответ OCSP-сервера должен включать расширение с определением причины отзыва сертификата (Extended Revoked Definition) Не известен (unknown) – издатель сертификата не распознан OCSP-сервером (не обслуживается данным OCSP-сервером) Значения времени в OCSP-ответе могут быть следующими: thisUpdate – ближайшая к моменту проверки статуса сертификата дата и время, когда OCSP-серверу поступила информация о корректности определенного статуса сертификата (good/revoked/unknown) nextUpdate – ближайшая дата и время, до или во время которой будет доступна обновленная информация о статусе сертификата producedAt – дата и время подписания OCSP-ответа OCSP-сервером revocationTime – дата и время отзыва или приостановления действия сертификата. Интервал валидности ответа (response validity interval) составляет промежуток времени {thisUpdate, nextUpdate}. Должен признаваться ненадежным статус сертификата, если в полученном OCSP-ответе время nextUpdate более раннее, чем текущее время в системе. Некоторые проверки в OCSP Валидация запроса OCSP-сервером включает следующие проверки: Запрос сформирован корректно; OCSP-сервер предоставляет запрашиваемый сервис; Запрос содержит необходимую информацию для OCSP-сервера. Если запрос OCSP-клиента не валиден, то ему возвращается сообщение об ошибке. Проверка валидности OCSP-ответа при получении OCSP-клиентом включает проверки: сертификат в ответе соответствует запрашиваемому сертификату; ЭП в ответе валидна; субъект (OCSP-сервер) идентифицирован и соответствует тому субъекту, которому был отправлен запрос; субъект, подписавший OCSP-ответ, авторизован для предоставления OCSP-ответа по запрашиваемому сертификату; дата и время thisUpdate соответствует предъявляемым требованиям к дате поступления такой информации; дата и время nextUpdate является более поздними, чем текущие дата и время. Типы ошибок в OCSP • malformedRequest – некорректно сформированный OCSP-запрос (синтаксис запроса); • internalError – ошибка на стороне OCSP-сервера (нештатное состояние); • tryLater – ошибка на стороне OCSP-сервера, без возможности возвратить сообщение об ошибке; • sigRequired – требуется подпись OCSP-запроса клиентским приложением; • unauthorized – OCSP-клиент не авторизован для выполнения запроса к данному OCSP-серверу, либо OCSP-сервер не в состоянии ответить. Протокол. В качестве транспортного протокола для передачи OCSP-сообщений между клиентом и сервером в настоящее время используются протоколы HTTP, может считаться надежным только при использовании шифрования (как, например, функционируют программно-аппаратные комплексы компании «КриптоПро», предоставляющие службу OCSP); HTTPS (HTTP поверх TLS) – используется в сети Интернет для подтверждения статуса сертификатов веб-сайтов. Алгоритм проверки Основные функции проверки валидации 1.Функция проверки формата сертификата 𝒇𝒇А𝟏𝟏 𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄 • • • • • А1 На вход функции 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 поступают сертификат конечного субъекта и политика валидации. А1 Функция проверки формата сертификата 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 осуществляет проверку содержимого сертификата на соответствие требованиям к проверке сертификата, обозначенным в разделе 1.2.2. В случае, если структура и содержимое сертификата соответствует требованиям, А1 = 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃. устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑠𝑠 В случае, если сертификат не соответствует требованиям, устанавливается статус А1 А1 = 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 и статус-индикатор 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 = 𝐵𝐵𝐵𝐵𝐵𝐵_𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹. 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑠𝑠 А1 Выходные статусы функции 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 представлены в таблице. Выходные статусы функции проверки формата 𝒇𝒇А𝟏𝟏 𝒄𝒄𝒉𝒉𝒆𝒆𝒆𝒆𝒆𝒆 Промежуточный статус 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 15 Статус-индикатор 𝐵𝐵𝐵𝐵𝐵𝐵_𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 Описание Сертификат соответствует требованиям к формату, содержит обязательные поля. Сертификат не соответствует требованиям к формату. А2 2.Функция загрузки политики валидации 𝑓𝑓𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐 А2 Функция загрузки политики валидации 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 осуществляет поиск, загрузку и распознавание политики валидации. Поиск политики валидации осуществляется по серийному номеру политики валидации в хранилище сервиса (база данных политик валидации, далее – БД политик валидации). Если политика не найдена в БД политик валидации, то функция производит загрузку политики из внешнего источника по адресу, указанному в сертификате. После загрузки осуществляется проверка формата политики валидации. В случае, если политика соответствует формату, производится ее обработка. Политика валидации может быть: документом на формальном языке и содержаться в самом сертификате; в сертификате может быть указан только идентификатор на применяемую политику валидации и адрес источника загрузки; политика валидации может содержаться в конфигурационном файле или настройках самого сервиса валидации. Если политика загружена успешно и ее формат соответствует требованиям, то на выходе функции А2 А2 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑠𝑠 = 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃. В случае, если политика валидации не найдена или имеет некорректный формат, устанавливается А2 = 𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼 и статус-индикатор в зависимости от типа ошибки: статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑠𝑠 А2 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 = 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃_𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃_𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸, если политика валидации имеет некорректный формат; А2 = 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆_𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃_𝑁𝑁𝑁𝑁𝑁𝑁_𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴, если политика валидации не 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 доступна. • • • • • • • • 3. Проверка действительности сертификата А4 конечного субъекта 𝑓𝑓𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐 А3 На вход функции 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 поступают сертификат КС и политика валидации. А3 Функция проверки действительности сертификата конечного субъекта 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 осуществляет проверку срока действия и проверку статуса отзыва сертификата конечного субъекта (далее – сертификата КС). Для проверки статуса отзыва осуществляется вызов функции проверки статуса А3 Б1 Б1 сертификата 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 . На выходе 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 возвращает статус сертификата. Функция 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 проверяет актуальность информации о статусе сертификата. Если срок действия сертификата КС не истек, сертификат не отозван, и информация об отзыве А3 сертификата актуальна, то устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑠𝑠 = 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃. А3 Если период действия сертификата истек, то устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏 = 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 и статусА3 индикатор 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸. А3 Если информация о статусе сертификата не актуальна, то устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏 = А3 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 и статус-индикатор 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 = 𝑇𝑇𝑇𝑇𝑇𝑇_𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿. А3 Если сертификат был отозван, то устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏 = 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 и статус-индикатор А3 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅. В этом случае обязательно возвращается дополнительная информация о причине и времени отзыва сертификата (информация извлекается из списка отозванных сертификатов CRL / Delta CRL, либо из OCSP-квитанции). А3 Если сертификат был приостановлен, то устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏 = 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 и статусА3 индикатор 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆. А3 Если информация о статусе отзыва сертификата не получена, то устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏 = А3 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 и статус-индикатор 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 = 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆_𝑁𝑁𝑁𝑁𝑁𝑁_𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴. 17 4.Построение цепочки сертификации А4 • На вход функции 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 поступают сертификат КС и политика валидации. А4 • Функция построения цепочки сертификации 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 осуществляет загрузку родительских сертификатов сертификата КС и построение цепочки сертификации. • Если цепочка сертификации построена успешно, то устанавливается статус А4 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑠𝑠 = 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃. • Если сертификаты цепочки не найдены, собраны не полностью или А4 загружены с ошибкой, то устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑠𝑠 = А4 𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼 и статус-индикатор 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 = 𝑁𝑁𝑁𝑁_𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹. А4 • Выходные статусы функции 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 представлены в таблице. Выходные статусы функции построения цепочки сертификации 𝒇𝒇А𝟓𝟓 𝒄𝒄𝒉𝒉𝒆𝒆𝒆𝒆𝒆𝒆 Промежуточный статус 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼 Статус-индикатор 𝑁𝑁𝑁𝑁_𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 Описание Цепочка сертификации построена успешно. Сертификаты цепочки не найдены, собраны не полностью или загружены с ошибкой. 18 5.Проверка цепочки сертификации А5 На вход функции 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 поступают сертификаты цепочки сертификации и политика валидации. А5 осуществляет проверку срока Функция проверки действительности сертификатов цепочки 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 действия и проверку статуса отзыва сертификата цепочки (далее – сертификата ЦС). Для А5 проверки статуса отзыва осуществляется вызов функции проверки статуса сертификата 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 . На А5 А5 возвращает статус сертификата. Функция 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 проверяет актуальность выходе 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 информации о статусе сертификата. Если срок действия всех сертификатов ЦС не истек, сертификаты ЦС не отозваны, и информация А5 = 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃. об отзыве сертификатов актуальна, то устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑠𝑠 Если период действия хотя бы одного сертификата ЦС истек, то устанавливается статус А5 А5 = 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 и статус-индикатор 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸. 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏 А4 Если информация о статусе сертификата ЦС не актуальна, то устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏 = А5 = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝑇𝑇𝑇𝑇𝑇𝑇_𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿. 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 и статус-индикатор 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 А5 = 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 и статусЕсли сертификат ЦС был отозван, то устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏 А5 = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅. В этом случае обязательно индикатор 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 возвращается дополнительная информация о причине и времени отзыва сертификата (информация извлекается из списка отозванных сертификатов CRL / Delta CRL, либо из OCSPквитанции). А5 = 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 и статусЕсли сертификат ЦС был приостановлен, то устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏 А5 индикатор 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆. Если информация о статусе отзыва сертификата ЦС не получена, то устанавливается статус А5 А5 = 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 и статус-индикатор 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 = 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆_𝑁𝑁𝑁𝑁𝑁𝑁_𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴. 19 6.Соответствие ограничениям А6 На вход функции 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 поступают сертификаты цепочки сертификации и политика валидации. А6 Функция проверки цепочки сертификации 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 осуществляет проверку ЦС на соответствие требованиям, содержащимся в политике валидации. А6 Если ЦС соответствует требованиям, устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏 = 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃. А6 = 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 Если ЦС не соответствует требованиям, устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏 А6 и статус-индикатор 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹. А6 Выходные статусы функции 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 представлены в таблице. Выходные статусы функции проверки действительности сертификатов цепочки 𝒇𝒇А𝟔𝟔 𝒄𝒄𝒉𝒉𝒆𝒆𝒆𝒆𝒆𝒆 Промежуточный статус 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 Статус-индикатор 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶_𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 Описание ЦС соответствует требованиям. ЦС не соответствует требованиям. 20 7. Криптографическая проверка А7 На вход функции 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 поступают сертификат КС и его родительский сертификат. А7 Функция 𝑓𝑓𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 осуществляет криптографическую проверку целостности сертификата КС, проверку требований к используемым криптографическим алгоритмам и к длине ключа проверки ЭП. Проверка целостности полей сертификата осуществляется путем сравнения значения ЭП, которая была сформирована выдавшим сертификат УЦ и содержится в сертификате, со значением ЭП, вычисленным от полей сертификата. Если хэш-коды совпадают, то сертификат признается прошедшим криптографическую проверку (целостным). Если целостность сертификата КС подтверждена, используются утвержденные криптографические алгоритмы, ключ проверки ЭП соответствует требованиям, то А7 = 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃. устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏 Если хеш-коды не совпадают (целостность сертификата КС была нарушена), то А7 устанавливается статус 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏 = 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹и статус-индикатор А7 = 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻_𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹. 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑠𝑠𝑠𝑠𝑏𝑏_𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖𝑖 21 Спасибо за внимание! 22