Проверка делегированного пути

Проверка делегированного пути ( DPV ) — это криптографический метод, используемый для разгрузки задачи проверки пути сертификации цифровых сертификатов от клиента к доверенному серверу . ^{[ 1 ]} Этот процесс является неотъемлемой частью различных протоколов безопасности, основанных на инфраструктуре открытых ключей (PKI). DPV стремится повысить эффективность проверки пути сертификации за счет использования выделенного для этой задачи сервера , который предоставляет результаты проверки клиенту. Этот подход особенно полезен в средах с ограниченными ресурсами, где у клиентов может не хватить вычислительной мощности для самостоятельного выполнения обширной проверки сертификата. ^{[ 1 ]}

Проверка пути сертификата

Проверка пути сертификата — важнейший процесс в PKI, обеспечивающий подлинность и надежность цифрового сертификата . Этот процесс стандартизирован в RFC 5280 и включает проверку цепочки сертификатов , начиная с проверяемого сертификата (сертификата конечного объекта) и заканчивая доверенным корневым центром сертификации (CA). ^{[ 2 ]} Процесс проверки включает в себя несколько ключевых этапов: ^{[ 2 ]}

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

Если все эти проверки успешно пройдены, путь сертификата считается действительным и сертификату конечного объекта можно доверять. ^{[ 2 ]}

Политика проверки

DPV позволяет серверу выполнять весь процесс проверки пути на основе набора предопределенных правил, известных как политика проверки. ^{[ 1 ]} Эта политика может включать в себя несколько якорей доверия . Якорь доверия характеризуется открытым ключом, именем центра сертификации (CA) и периодом действия; он также может иметь дополнительные ограничения. ^{[ 3 ]} можно Самозаверяющий сертификат использовать для обозначения открытого ключа, имени издателя и периода действия якоря доверия . Могут быть определены дополнительные ограничения для якорей доверия, например ограничения политики сертификации или ограничения именования. Эти ограничения также могут быть частью самозаверяющих сертификатов. ^{[ 1 ]} Для успешной проверки пути между сертификатом конечного объекта и якорем доверия должен быть установлен действительный путь сертификации, гарантирующий, что ни один из сертификатов в пути не истек или не отозван, а также должны быть соблюдены все ограничения на пути. ^{[ 1 ]} Политика валидации состоит из трех основных компонентов: ^{[ 1 ]}

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

Требования протокола

RFC 3379 определяет несколько ключевых требований для обеспечения эффективной и безопасной проверки делегированного пути.

Во-первых, если клиент запрашивает определенную политику проверки, которую сервер DPV не поддерживает, сервер должен вернуть ошибку. Это гарантирует, что клиент знает, что запрошенная политика не может быть применена. Если клиент не указывает политику проверки, сервер должен указать, какая политика проверки использовалась в ответе. Такая прозрачность позволяет клиентам понять, на каком основании была выполнена проверка. ^{[ 1 ]}

Политики проверки могут быть сложными и могут включать такие параметры, как корневые самозаверяющие сертификаты. Протокол DPV должен позволять клиентам включать эти параметры, зависящие от политики, в свои запросы. Однако ожидается, что большинство клиентов либо будут ссылаться на политику проверки, подходящую для их приложения, либо примут политику проверки по умолчанию сервера DPV. ^{[ 1 ]}

Клиенты также могут запросить, чтобы сервер DPV определял срок действия сертификата в определенное время, отличное от текущего. В таких случаях сервер должен получить информацию о статусе отзыва, соответствующую указанному времени проверки. Если необходимая информация о статусе отзыва недоступна, сервер должен вернуть статус, указывающий, что сертификат недействителен, возможно, предоставляя дополнительные сведения о причине недействительности. ^{[ 1 ]}

Для продолжения проверки сертификат должен быть либо непосредственно предоставлен в запросе, либо на него должна быть недвусмысленная ссылка в таких деталях, как отличительное имя ЦС , серийный номер сертификата и хэш сертификата . Это гарантирует, что правильный сертификат проверен. ^{[ 1 ]}

Клиент DPV должен быть способен предоставлять серверу проверки полезные сертификаты и информацию об отзыве, относящуюся к каждому проверяемому сертификату. Сюда входят ответы OCSP, списки отзыва сертификатов и дельта-списки отзыва сертификатов, которые имеют решающее значение для проверки текущего состояния сертификатов. ^{[ 1 ]}

Сервер DPV должен иметь доступ к сертификату, который требует проверки. Если сертификат не указан в запросе, сервер должен получить его и проверить, соответствует ли он ссылке, предоставленной клиентом. В ответ сервер должен включить либо сертификат, либо четкую ссылку на него, особенно в случаях компрометации ключа CA. ^{[ 1 ]}

В ответе сервера DPV должен быть указан один из следующих статусов: ^{[ 1 ]}

Сертификат действителен в соответствии с политикой проверки;
Сертификат недействителен в соответствии с политикой проверки;
Срок действия сертификата неизвестен в соответствии с политикой проверки;
Срок действия не удалось определить из-за ошибки.

Если сертификат недействителен, сервер также должен указать причину такого решения. Общие причины включают невозможность создания пути сертификации, построенный путь не проходит алгоритм проверки или сертификат недействителен в запрошенное время, например, до начала срока его действия или во время приостановки. ^{[ 1 ]}

Кроме того, протокол DPV должен позволять клиентам запрашивать у сервера дополнительную информацию в своем ответе. Эта дополнительная информация помогает доверяющим сторонам, которые не доверяют серверу DPV, быть уверенными в том, что проверка сертификата выполнена правильно. Ответ DPV должен быть привязан к запросу DPV, чего можно добиться, включив в ответ односторонний хэш запроса. Эта привязка гарантирует, что все параметры запроса были учтены при построении ответа. ^{[ 1 ]}

Чтобы гарантировать, что клиент доверяет серверу DPV, ответ должен быть аутентифицирован . Чтобы клиент мог доказать третьим лицам, что проверка сертификата была проведена правильно, ответ DPV должен быть подписан цифровой подписью , за исключением случаев, когда сообщается об ошибке. Сертификат сервера DPV должен аутентифицировать сервер, добавляя еще один уровень доверия и безопасности к процессу проверки. ^{[ 1 ]}

Ретрансляция, перенаправление и многоадресная рассылка

В определенных сетевых средах, особенно с межсетевыми экранами , сервер DPV может столкнуться с трудностями при получении всей необходимой информации для обработки запроса на проверку. Чтобы решить эту проблему, сервер DPV можно настроить для использования услуг других серверов DPV. В таких сценариях клиент не знает, что основной сервер DPV использует дополнительные серверы для выполнения запроса. По сути, основной сервер DPV действует как клиент для другого сервера DPV, облегчая более комплексный процесс проверки. ретрансляции, перенаправления или В отличие от конечных клиентов, серверы DPV обычно обладают более существенными вычислительными ресурсами и ресурсами памяти, что позволяет им использовать механизмы многоадресной рассылки . ^{[ 1 ]}

Протоколы, предназначенные для поддержки этих операций, могут включать дополнительные поля и расширения для облегчения ретрансляции, перенаправления или многоадресной рассылки между серверами DPV. Однако не ожидается, что клиенты DPV будут поддерживать эти функции. Если протокол включает такие функции, он также должен предоставлять механизмы, обеспечивающие совместимость с клиентами и серверами DPV, которые не поддерживают эти расширенные функции, обеспечивая соблюдение основных требований протокола. ^{[ 1 ]}

Последствия для безопасности

Протокол DPV должен включать в себя механизмы предотвращения атак повторного воспроизведения , гарантируя, что злоумышленники не смогут повторно использовать запросы проверки для получения несанкционированного доступа. ^{[ 1 ]} Важно отметить, что предотвращение повторного воспроизведения не должно зависеть от синхронизации часов между клиентом и сервером, что может стать уязвимостью, если часы не выровнены точно. ^{[ 4 ]}

Если сертификат успешно проверен в соответствии с указанной политикой, сервер DPV должен включить эту информацию в ответ по запросу клиента. Однако, если сертификат окажется недействительным или сервер не сможет определить его действительность, сервер может пропустить эту информацию, чтобы избежать ненужного раскрытия потенциально конфиденциальных данных. ^{[ 1 ]}

Информация о статусе отзыва, используемая сервером DPV, относится ко времени проверки, указанному в запросе клиента. сертификата Это время проверки может отличаться от фактического времени, когда закрытый ключ использовался для подписи документа или транзакции. ^{[ 1 ]} Таким образом, клиент DPV должен настроить время проверки, чтобы учесть несколько задержек: ^{[ 1 ]}

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

Учитывая эти факторы, протокол DPV пытается гарантировать, что информация о статусе отзыва точно отражает текущую действительность сертификата, повышая общую безопасность и надежность процесса проверки. ^{[ 1 ]}

См. также

Ссылки

^ Jump up to: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж ^к ^л ^м ^н ^тот ^п ^д ^р ^с ^т ^в ^v ^В RFC 3379 (сентябрь 2002 г.), глава 4, Требования к протоколу проверки делегированного пути и обнаружения делегированного пути.
^ Jump up to: ^а ^б ^с RFC 5280 (май 2008 г.), глава 6, Профиль сертификата инфраструктуры открытых ключей Internet X.509 и списка отзыва сертификатов (CRL).
^ Ма, Зейн; Остген, Джеймс; Мейсон, Джошуа; Дурумерик, Закир; Бэйли, Майкл (2 ноября 2021 г.). «Прослеживая свои корни: изучение экосистемы якоря доверия TLS» . Материалы 21-й Интернет-конференции ACM по измерениям . ММК '21. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. стр. 179–194. дои : 10.1145/3487552.3487813 . ISBN 978-1-4503-9129-0 .
^ Сиверсон, П. (1994). «Таксономия повторных атак [криптографических протоколов]» . Материалы семинара по основам компьютерной безопасности VII . IEEE-компьютер. Соц. Нажимать. стр. 187–191. дои : 10.1109/CSFW.1994.315935 . ISBN 978-0-8186-6230-0 .

Дальнейшее чтение

Вакка, Джон Р., изд. (2014). «Глава 3. Инфраструктура открытых ключей». Кибербезопасность и защита ИТ-инфраструктуры (1-е изд.). Уолтем, Массачусетс: Syngress — это отпечаток Elsevier. ISBN 978-0-12-416681-3 . OCLC 861507009 .

Внешние ссылки

«Обнаружение и проверка распределенного делегированного пути» . Гугл Патенты . Проверено 9 июля 2024 г.
Браун, Уильям. «Проверка пути сертификации» . docs.hidglobal.com . Проверено 11 июля 2024 г.

[RFC3379-1] Jump up to: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж ^к ^л ^м ^н ^тот ^п ^д ^р ^с ^т ^в ^v ^В RFC 3379 (сентябрь 2002 г.), глава 4, Требования к протоколу проверки делегированного пути и обнаружения делегированного пути.

[RFC5280-2] Jump up to: ^а ^б ^с RFC 5280 (май 2008 г.), глава 6, Профиль сертификата инфраструктуры открытых ключей Internet X.509 и списка отзыва сертификатов (CRL).

[3] Ма, Зейн; Остген, Джеймс; Мейсон, Джошуа; Дурумерик, Закир; Бэйли, Майкл (2 ноября 2021 г.). «Прослеживая свои корни: изучение экосистемы якоря доверия TLS» . Материалы 21-й Интернет-конференции ACM по измерениям . ММК '21. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. стр. 179–194. дои : 10.1145/3487552.3487813 . ISBN 978-1-4503-9129-0 .

[4] Сиверсон, П. (1994). «Таксономия повторных атак [криптографических протоколов]» . Материалы семинара по основам компьютерной безопасности VII . IEEE-компьютер. Соц. Нажимать. стр. 187–191. дои : 10.1109/CSFW.1994.315935 . ISBN 978-0-8186-6230-0 .

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]