Телефон: 8-800-350-22-65
WhatsApp: 8-800-350-22-65
Telegram: sibac
Прием заявок круглосуточно
График работы офиса: с 9.00 до 18.00 Нск (5.00 - 14.00 Мск)

Статья опубликована в рамках: Научного журнала «Студенческий» № 18(272)

Рубрика журнала: Информационные технологии

Скачать книгу(-и): скачать журнал часть 1, скачать журнал часть 2, скачать журнал часть 3, скачать журнал часть 4, скачать журнал часть 5, скачать журнал часть 6, скачать журнал часть 7, скачать журнал часть 8, скачать журнал часть 9, скачать журнал часть 10

Библиографическое описание:
Сальков Н.С. АНАЛИЗ ПРОТОКОЛОВ УПРАВЛЕНИЯ X.509 СЕРТИФИКАТАМИ // Студенческий: электрон. научн. журн. 2024. № 18(272). URL: https://sibac.info/journal/student/272/329686 (дата обращения: 24.11.2024).

АНАЛИЗ ПРОТОКОЛОВ УПРАВЛЕНИЯ X.509 СЕРТИФИКАТАМИ

Сальков Никита Сергеевич

студент, кафедра Автоматики, Новосибирский государственный технический университет,

РФ, г. Новосибирск

Гунько Андрей Васильевич

научный руководитель,

канд. техн. наук, доц., Новосибирский государственный технический университет,

РФ, г. Новосибирск

ANALYSYS OF X.509 CERTIFICATE MANAGEMENT PROTOCOLS

 

Nikita Salkov

student, Department of Automation, Novosibirsk state technical University,

Russia, Novosibirsk

Andrey Gunko

scientific supervisor, candidate of Technical Sciences, associate professor Novosibirsk state technical University,

Russia, Novosibirsk

 

АННОТАЦИЯ

Статья представляет собой обзор и сравнительный анализ трех протоколов управления сертификатами: SCEP, ACME и EST. Автор освещает основные принципы и функциональность каждого протокола, а также проводит сравнение их преимуществ.

ABSTRACT

The article presents a study and comparative analysis of three certificate management protocols: SCEP, ACME, and EST. The author illuminates the fundamental principles and functionality of each protocol, as well as conduct a comparison of their advantages.

 

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

Keywords: certificate, certification authority, X509, enrollment, renewal.

 

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

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

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

  • Запрос сертификата удостоверяющего центра
  • Издание сертификата
  • Обновление сертификата
  • Запрос списка отозванных сертификатов
  • Отзыв сертификата
  • Запрос состояния отзыва сертификата
  • Запрос копии сертификата.

Примерами таких протоколов являются SCEP (Simple Certificate Enrollment Protocol), EST (Enrollment over Secure Transport), ACME (Automatic Certificate Management Environment). Разберем детали этих протоколов.

Обзор протокола SCEP

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

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

В SCEP передача данных происходит по протоколу HTTP (HyperText Transfer Protocol). Так как HTTP передает информацию в открытом виде, в протоколе предусмотрено её защита с помощью CMS (Cryptographic Message Syntax). Безопасная передача реализуется с помощью двух контейнеров PKCS #7 (Public Key Cryptography Standards), где внешний контейнер имеет тип signedData, а внутренний envelopedData. Внешний контейнер подписывается закрытым ключом отправителя, чтобы получатель мог удостовериться в аутентичности и в целостности сообщения. А внутренний контейнер, который содержится во внешнем, хранит передаваемую информацию, зашифрованную открытым ключом получателя, как пример запрос на подпись.

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

Обзор протокола EST

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

Общение между клиентом и сервером происходит по протоколу HTTPS (HyperText Transfer Protocol Secure), что соответствует современной тенденции информационной безопасности. Из-за использования HTTPS, клиент аутентифицирует сервер по TLS (Transport Layer Security). В случае, если политика удостоверяющего центра подразумевает аутентификацию клиентской стороны, то приоритетом будет использование TLS. Но эта аутентификация доступна в случае, когда у клиента либо уже есть сертификат, который был издан сервером, либо сертификат, полученный от удостоверяющего центра, которому доверяет сервер. В качестве альтернативной аутентификации, сервер может воспользоваться аутентификацией по HTTP с использованием логина и пароля.

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

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

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

Обзор протокола ACME

Протокол ACME представляет возможность издавать, обновлять и отзывать сертификаты. В ACME используются обмен сообщений в формате JSON (JavaScript Object Notation) через протокол HTTPS.

Работа клиента начинается с создания аккаунта у сервера. В ответ, клиент получает список URL (Uniform Resource Locator), адресов для взаимодействия с удостоверяющим центром через свой аккаунт. После создания аккаунта, все операции протокола становятся доступными.

Аутентификация сервера происходит по протоколу TLS. Клиент проходит аутентификацию во время получения сертификата. Аутентификация клиента может производиться либо с помощью проверки HTTP-01 или с помощью проверки DNS-01 (Domain Name System).

При аутентификации по HTTP-01, сервер отправляет клиенту токен, который клиент должен записать в файл и разместить этот файл по определенному URL. Файл содержит токен и отпечаток ключа аккаунта. После готовности файла, сервер скачает его и проверить корректность содержимого. Если файл корректный, то проверка считается пройденной и клиент может отправлять запрос на подпись и после готовности сертификата, скачать его.

Проверка DNS-01 подтверждает права владения на домен, используя TXT-запись для доменного имени. Сервер также отправляет клиенту токен, который вместе с ключом аккаунта будет содержаться в TXT-записи с определенным именем. После создания записи в DNS-зоне домена, сервер запрашивает ее и проверяет корректность содержимого. После чего владение доменом, считается подтверждённым.

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

Сравнение протоколов SCEP, EST и ACME

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

Таблица 1.

Сравнение протоколов

 

SCEP

EST

ACME

Протокол TLS

-

+

+

Запрос копии сертификата удостоверяющего центра

+

+

-

Издание сертификата

+

+

+

Обновление сертификата

+

+

+

Запрос CRL (Certificate Revocation List)

+

-

-

Отзыв сертификата

-

-

+

Запрос копии изданного сертификата

+

-

-

Генерация ключа на стороне сервера

-

+

-

Запрос желаемых, для удостоверяющего центра, атрибутов запроса на подпись

-

+

-

Авторизация сервера

+

+

+

Авторизация клиента

+

+

+

 

 

Протокол SCEP и EST архитектурно похожи друг на друга, это объясняется тем, что SCEP был создан раньше, а EST появился как замена SCEP, которая взяла лучшее из протокола и в которой были доработаны его недостатки. Протокол ACME отличается от других рассмотренных протоколов. В нём более сложная процедура аутентификации клиента и поддерживает необходимый минимум операций, а также имеет возможность отзыва сертификата, чего нет у его конкурентов.

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

 

Список литературы:

  1. RFC 8894. Simple Certificate Enrolment Protocol. September 2020.
  2. RFC 7030. Enrollment over Secure Transport. October 2013.
  3. RFC 8555. Automatic Certificate Management Environment. March 2019.
Удалить статью(вывести сообщение вместо статьи): 

Оставить комментарий

Форма обратной связи о взаимодействии с сайтом
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.