НОУ ИНТУИТ | Лекция | Механизмы аутентификации

НОУ ИНТУИТ | Лекция | Механизмы аутентификации Сертификаты
На чтение 20 мин. Просмотров 29 Опубликовано
Содержание
  1. Аутентификация при помощи сертификатов
  2. Инфраструктура открытых ключей: утилита генерации запросов на квалифицированный сертификат
  3. Ключевое соглашение
  4. Примечания

Аутентификация при помощи сертификатов

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

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

Помимо него применяются протоколы Transport LayerSecurity (TLS) [142], InternetKey Exchange (IKE)

[147], S/MIME[169], PGP и OpenPGP[149]. Каждый из них немного по-своему использует сертификаты, но основные принципы – одни и те же.

Рис. 2.5 иллюстрирует типичный обмен сообщениями при аутентификации на базе сертификатов, использующий цифровые подписи [70]. Обмен соответствует стандарту аутентификации субъектов на основе криптографии с открытыми ключами[117].

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

Если серверВ поддерживает метод аутентификации, запрашиваемый пользователем А, то начинается обмен сообщениями. Сообщение Token ID уведомляет о том, что будет выполняться взаимная аутентификация, а также содержит номер версии протокола и идентификатор протокола.

Хотя этот идентификатор не обязателен, он намного упрощает процедуру и поэтому обычно используется. ПользовательА ожидает сообщение Token ВА1 от сервера В. Идентификатор протокола в Token ID позволяет пользователю А удостовериться, что серверВ отправляет ожидаемое сообщение. Token ВА1 состоит только из случайного числа ran B, это – своего рода запрос, корректным ответом должна быть цифровая подпись числа ran B.
ПользовательА подписывает ответ и отправляет свой сертификат ключа подписи, для того чтобы серверВ при помощи открытого ключа мог выполнить валидацию подписи.

ПользовательА подписывает последовательность из трех элементов: свой запросran A, запрос сервера ran B и имя сервера name B. Ran A – это запросА к серверу В, гарантирующий, что пользовательА подписывает не произвольное сообщение сервера В или другого субъекта, выдающего себя за серверВ.

Получив ответ Token АВ от пользователя А, серверВ проверяет, совпадает ли значениеran B с соответствующим значением в сообщении Token ВА1, а по значению name В устанавливает, действительно ли пользовательА желает пройти аутентификацию сервера В.

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

Ответ сервера Token ВА2 состоит из заверенной цифровой подписью последовательности трех элементов: ran A, ran B и name A, где ran A – запрос, сгенерированный А, ran B – исходный запрос сервера В, а name A – имя пользователяА.

Получив ответ сервера, пользовательА убеждается, что ran A имеет то же самое значение, что и в сообщении Token АВ, а проверяя значениеname A – что серверВ намерен аутентифицировать именно его (пользователя А ).

Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае пользовательА проверяет подлинность сертификата сервера В и его цифровой подписи.

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

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

Инфраструктура открытых ключей: утилита генерации запросов на квалифицированный сертификат

image

Одним из центральных объектом инфраструктуры открытых ключей (Public Key Infrastructure — PKI/ИОК) наряду с ключевой парой является сертификат, который сегодня фактически является аналогом гражданского паспорта.

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

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

По аналогичной схеме происходит и получение сертификата ключа проверки электронной подписи (СКПЭП). Сначала гражданин, желающий получить сертификат, должен приобрести «навык» в проставлении собственноручной подписи. Этот «навык» реализуется через получение заявителем ключевой пары, которая содержит открытый ключ или ключ проверки электронной подписи (КПЭП) и закрытый ключ или ключ электронной подписи, который, собственно, и позволяет генерировать электронную подпись и подписывать электронный документ. Идентификация электронной подписи под документом осуществляется по следующему алгоритму. Из сертификата определяется каким ключом (ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2021 с длиной ключа 64 или 128 байт) был подписан документ. По типу ключа определяется алгоритм хэширования, который использовался при подписании документа. Это может быть ГОСТ Р 34.11-94 или ГОСТ Р 34.11-2021 с длиной хэш 256 или 512 бит. По выбранному алгоритму считается хэш от исходного документа. А по значению посчитанного хэш от исходного документа, публичного ключа (КПЭП) и его параметрам (все это берется из сертификата СКПЭП) и проверяется достоверность электронной подписи под документом.

Про сертификаты:  Обязательный сертификат пожарной безопасности в Чебоксарах | ОС "Сертификация"

Для создания ключевой пары используются различные средства криптографической защиты информации (СКЗИ), поддерживающие криптографические алгоритмы ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2021. При этом следует помнить, что использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2021 года не допускается! СКЗИ, которые реализуют различные криптографические алгоритмы и протоколы могут быть как программными, так и аппаратными. Доступ к СКЗИ осуществляется через криптографические интерфейсы. Абсолютное большинство сертифицированных СКЗИ с российской криптографией поддерживает либо универсальный криптографический интерфейс PKCS#11, который поддерживается на всех платформах, либо интерфейс CSP и CryptoAPI от Микрософт на платформах MS Windows (далее MS CSP). Именно эти два криптографических интерфейса и поддерживаются, например, порталом Госуслуг. Именно эти два типа СКЗИ и будут рассматриваться далее:

Следует иметь ввиду, что если есть желание или необходимость работы с электронной подписью не только на платформе Windows, но и на других платформах (Linux, macOS и т.п.), то следует выбирать токены PKCS#11 с поддержкой российской криптографии.

Помимо основной функции, связанной с генерацией запроса, в утилите предусмотрены функции для работы с токенами и сертификатами:

Комбинированное поле (combobox) «Выберите токен:» на основном окне содержит список доступных СКЗИ для генерации ключевой пары. Если утилита генерации запроса запущена на платформе Windows и на ней установлены криптопровайдеры CSP с поддержкой российской криптографии, то в перечне доступных СКЗИ («Выберите токен:») будет определен и виртуальный токен «MS_CSP». Так что, если есть желание использовать криптопровайдер MS CSP, то он должен быть установлен в системе до запуска утилиты.

Для добавления поддержки нового токена PKCS#11 достаточно выбрать пункт меню «Управление Токенами->Добавить Токен». Добавление поддержки для нового токена состоит в выборе библиотеки PKCS#11 для подключаемого типа токенов/смарткарт и задании удобного имени (никнайма). При добавлении поддержки нового типа токенов (а также при запуске утилиты, если ранее была добавлена поддержка токенов) при подключенном (вставленном) токене будет затребован PIN-код для доступа к нему:

Но это произойдет только в том случае, если токен не только подключен, но и находится в рабочем состоянии, т.е. проинициализирован. Проверить токен и, при необходимости, проинициализировать его, сменить PIN-код для доступа к нему и т.д. удобно утилитой

p11conf

:

Выбрав пункт «Управление Токенами->Механизмы Токена», можно посмотреть криптографические механизмы того или иного токена, например, есть ли поддержка алгоритма ГОСТ Р 34.10-2021. Для виртуального токена MS_CSP перечисляются все провайдеры CSP с поддержкой ГОСТ-алгоритмов и поддерживаемые ими механизмы:

Если выбранный токен не поддерживает выбранный тип ключевой пары, то будет выдано соответствующее сообщение:

Прежде чем перейти непосредственно к заполнению полей запроса необходимо определиться для каких целей нужен сертификат, т.е. указать «Роль сертификата». Сегодня таких ролей накопилось не один десяток:

И каждая роль связана с множеством различных OID-ов, включаемых в сертификат. Так, например, для доступа на портал Госуслуг необходимы следущие oid-ы:

{Госуслуги} {clientAuth, emailProtection, 1.3.6.1.4.1.311.20.2.2, 1.2.643.100.2.1, 
1.2.643.2.2.34.6, 1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4, 1.2.643.5.1.24.2.1.3, 
1.2.643.6.14, 1.2.643.3.215.4, 1.2.643.3.215.5, 1.2.643.3.215.6, 1.2.643.3.215.7, 
1.2.643.3.215.8, 1.2.643.3.215.9, 1.2.643.3.215.11, 1.2.643.3.215.12, 1.2.643.3.215.13, 1.3.6.1.4.1.40870.1.1.1, 1.2.643.2.64.1.1.1, 1.2.643.3.5.10.2.12, 1.2.643.6.3.2, 
1.2.643.5.1.24.2.46, 1.2.643.6.45.1.1.1, 1.2.643.5.1.24.2.30, 1.2.643.5.1.28.2, 
1.2.643.5.1.28.3, 1.2.643.3.202.1.8}

OID-ы для других ролей (например, «Площадка Газпромбанк», «Потребитель спирта» и т.д.) можно найти в исходном коде утилиты (переменная oid_roles_bad, оператор:

set oid_roses_bad {. . .}

).

Наличие такого количества oid-ов трудно понять. Речь идет о квалифицированных сертификатах, в которых присутствуют oid-ы ИНН, ОГРН, СНИЛС и т.п., которые однозначно идентифицируют и физическое лицо и юридическое лицо и, кажется, этого было бы достаточно для доступа на портал Госуслуг, да и на другие тоже. Но, Dura lex, sed lex — Закон суров, но это закон.

В поле «Наименование СКЗИ» необходимо указать название СКЗИ (токен/смарткарта, CSP), которое прописано в сертификате соответствия (не путать с сертификатом X509) ФСБ России или другом аналогичном документе, копию которого должна предоставляться в момент приобретения СКЗИ. В последующем значение этого поля войдет в сертификат.

Итак, определившись с СКЗИ и ключевой парой, можно приступать к заполнению электронного заявления/запроса на сертификат ключа проверки электронной подписи (СКПЭП):

Первым заполняется поле «Common Name», в которое заносится полное имя будущего владельца сертификата. Для физического лица это ФИО как в паспорте. Для юридического лица это наименование компании из ЕГРЮЛ. Эта информация для юридического лица автоматически будет продублирована в поле «Наименование организации» («O»):

При заполнении формы проверяется правильность заполнения полей ИНН, ОГРН, СНИЛС (при вводе не цифры поле становится красным, правильно заполненные поля становятся зеленоватыми), адреса электронной почты:

После заполнения всех полей запроса и нажатия кнопки «Finish» в итоге будет получен запрос на сертификат:

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

Напомним, что ключевая пара содержит два ключа: закрытый и открытый. Открытый ключ, который еще называют ключом проверки электронной подписи, отправляется в запрос на сертификат. Для просмотра сгенерированного запроса, который содержит и открытый ключ, используется меню «Сертификаты->Просмотр запроса»:

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

Про сертификаты:  Электронная подпись (ЭЦП) и торговые площадки (ЭТП) | Статьи УЦ СКБ Контур — Удостоверяющий центр СКБ Контур

однозначное соответствие

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

Теперь со всеми необходимыми документами, со сгенерированным запросом на флэшке можно идти в ближайший удостоверяющий центр и получать сертификат. Итак запрос поступает для выпуска сертификата в один из УЦ, созданных с учетом Федерального закона от 6 апреля 2021г. №63-ФЗ «Об электронной подписи»:

Запрос в УЦ пройдет стадии импорта, рассмотрения, утверждения и выпуска сертификата по данному запросу:

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

И вот теперь, когда получен сертификат, осталось положить его на СКЗИ (PKCS#11, MS CSP) (Сертификаты->Импорт x509):

Убедиться, что сертификат находится на токене, можно просмотрев содержимое токена/смарткарты (Сертификаты->Просмотр x509 на токене):

Ну и чтобы это была «броня» (Дайте мне такую БУМАЖКУ! Окончательная Бумажка, Броня. (Собачье Сердце к/ф)), подключим токен к браузеру

Firefox

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

Утилита CreateCSRCAFL63 разработана на

Tcl/Tk

. Для доступа к криптографическим функциям MS CSP и токенов PKCS#11 разработан пакет cwapi, реализующий требования к библиотекам C со стороны Tcl. Реализовать эти требования

не сложно

, но порой отнимает много времени в силу своей рутинности. И тут на помощь приходит общедоступная утилита

SWIG.

, которая позволяет создавать интерфейсные модули между библиотеками C/C и другими языками. Это не только Tcl, но и Java и другие. Проект очень хорошо документирован и имеет прекрасные примеры. Воспользоваться им не представляет труда. В нашем случае для получения интерфейсного модуля был написан простой исходный файл cwapi.i для утилиты swig:

%module cwapi
%inline %{
#include "cwapi.h"
%}
%include "cwapi_SWIG.h"

В файле cwapi.h находятся описания функций из основного проекта cwapi:

#ifdef __cplusplus
extern "C" {
#endif
    int CW_Initialize (char *configdir);
    int CW_Finalize ();
    int addp11mod (char *nickname, char *library);
    int remp11mod (char *nickname);
    char *  lmod ();
    char *  ltok ();
    char *  lcert (char *token, int priv_cert);
    char* createreq (char *token, char *subject, char *keyusage, int keyparams, int pem, char *skzi, char* role);
    char* viewx509 (char *nickname, int CertOrReq);
    char* x509pem (char *nickname);
    char*  x509fromfile(char *token, char *infile, char *trusts);
    int delcert (char *nickname, int priv_cert);
    int p12tofile (char *token, char *nickname, char *outfile);
    char*  p12fromfile(char *token, char *infile);
    char* lmech(char* token);
    char* tinfo(char* token);
#ifdef __cplusplus
}
#endif

Выполнив команду:

$export SWIG_LIB=/usr/local/swig-3.0.12/Lib 
$/usr/local/swig-3.0.12/swig -tcl8   -o cwapi_wrap.c cwapi_.i
$

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

Для получения дистрибутива очень удобно использовать утилиту

freewrap

, при этом библиотека cwapi также включается непосредственно в дистрибутив. Исходный код утилиты и дистрибутивы доступны для платформ Windows и Linux.

Хотелось бы упомянуть еще об одной утилите, а именно о tcl2c. Эта утилита «заварачивает» tcl/tk-код в C-код.

Для получения исполняемого кода достаточно выполнить команду:

$cc -o create_csr_С create_csr.c -ltcl -ltk
$

В состав дистрибутивов для платформы Linux включен и дистрибутив на языке С со статическим подключением пакета cwapi.

Ключевое соглашение

В протоколе Диффи-Хеллмана две стороны создают симметричный ключ сеанса без KDC. Перед установлением симметричного ключа эти две стороны должны выбрать два числа p и g.

Первое число, p, является большим простым числом порядка 300 десятичных цифр (1024 бита). Второе число, g, служит генератором порядка p – 1 в группе <

Шаги перечислены ниже.

  1. Алиса выбирает большое случайное число x, такое, что 0 < x < p – 1, и вычисляет R1 = gx mod p.
  2. Боб выбирает другое большое случайное число y, такое, что 0 < y < p – 1, и вычисляет R2 = gy mod p.
  3. Алиса передает Бобу R1. Обратите внимание, что Алиса не передает значение x ; она передает только R1.
  4. Боб передает Алисе R2. Снова обратите внимание, что Боб не передает значение y, он передает только R2.
  5. Алиса вычисляет K = (R2)x mod p.
  6. Боб также вычисляет K = (R1)y mod p.

    K = (gx mod p)y mod p = (gymod p)x mod p = gxy mod p

Боб вычисляет K = (R1)y mod p = (gx mod p)y mod p = gxy mod p

Алиса вычисляет K = (R2)x mod p = (gy mod p)x mod p = gxy mod p

и получает то же самое значение без Боба, знающего значение x. А Боб получил это значение без Алисы, знающей значение y.

Симметричный (общедоступный) ключ в методе Диффи-Хеллмана – K = gxy mod p

Пример 5.1

Приведем тривиальный пример, чтобы ясно понять процедуру. Наш пример использует маленькие числа, но заметим, что в реальной ситуации применяются очень большие числа. Предположим, что g = 7 и p = 23. Тогда процедура содержит следующие шаги.

  1. Алиса выбирает x = 3 и вычисляет R1 = 73 mod 23 = 21.
  2. Боб выбирает y = 6 и вычисляет R2 = 76 mod 23 = 4.
  3. Алиса передает число 21 Бобу.
  4. Боб передает число 4 Алисе.
  5. Алиса вычисляет симметричный ключ K = 43 mod 23 = 18.
  6. Боб вычисляет симметричный ключ K = 216 mod 23 = 18.

Значение K одно и то же и для Алисы, и для Боба: gx y mod p = 718 = 18 .

Пример 5.2

Давайте возьмем более реальный пример. Мы используем программу, чтобы создать случайное целое число 512 битов (идеально – 1024 бит). Целое число p – число с 159 цифрами. Мы также выбираем g, x и y, как показано ниже:

Про сертификаты:  Перенос контейнеров закрытых ключей и сертификатов CryptoPro | Digital Cub.

Следующая таблица показывает R1, R2 и K.

Анализ протокола Диффи-Хеллмана

Концепция Диффи-Хеллмана, показанная на
рис. 5.10, является простой, но изящной. Мы можем представить ключ засекречивания между Алисой и Бобом – он состоит из трех частей: g, x и y.

Первая часть общедоступна. Каждый знает 1/3 ключа
– g, общедоступное значение. Другие две части нужно узнать у Алисы и Боба. Каждый из них знает одну часть. Алиса добавляет x как вторую часть для Боба;

Боб добавляет y как вторую часть для Алисы. Когда Алиса получает 2/3 полного ключа от Боба, она добавляет последнюю часть, ее y,
чтобы завершить ключ. Когда Боб получает ключ от Алисы – законченный на 2/3, он добавляет последнюю часть, свое y, чтобы завершить ключ.

Обратите внимание, что хотя ключ Алисы состоит из g, y и x и ключ Боба состоит из g, x и y, эти два ключа – одни и те же, потому что gxy = gyx.

Обратите внимание также, что хотя два ключа те же самые, Алиса не может найти значение y, используемого Бобом, потому что вычисление сделано по модулю p. Алиса получает gy mod p от Боба, но не gy.

Безопасность протокола

Замена ключа Диффи-Хеллмана восприимчива к двум атакам: атаке дискретного логарифма и атаке посредника (man-in middle)

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

Из R1 = gx mod p и y из R2 = gy mod p она может затем вычислить симметричный ключ: K = gxy mod p.

  1. Простое число p должно быть очень большим (более чем 300 десятичных цифр).
  2. Простое число p должно быть выбрано так, чтобы p – 1 имел по крайней мере один простой делитель (больше чем 60 десятичных цифр).
  3. Генератор должен быть выбран из группы <Zp*, x >.
  4. Боб и Алиса должны уничтожить x и y после того, как они вычислили значение симметричного ключа. Значения x и y должны использоваться только единожды.

Атака “посредника”. Этот протокол имеет другую слабость. Еве не надо находить значения x и y, чтобы напасть на протокол. Она может использовать глупость Алисы и Боба, создающих два ключа:

  1. Алиса выбирает x , вычисляет R 1 = gx mod p и передает R1 Бобу.
  2. Ева, злоумышленник, перехватывает R1. Она выбирает z, вычисляет R 2 = gz mod p и передает R 2 Алисе и Бобу.
  3. Боб выбирает y, вычисляет R3 = gy mod p, передает R3 Алисе. Ева перехватывает R3, и Алиса никогда не получит это число.
  4. Алиса и Ева вычисляют K1 = gxz mod p, который становится открытым ключом между Алисой и Евой. Алиса, однако, думает, что это -открытый ключ между ней и Бобом.
  5. Ева и Боб вычисляют K2 = gzymod p, который становится открытым ключом между Евой и Бобом. Однако Боб думает, что это – открытый ключ между ним Алисой.

Другими словами, создаются два ключа вместо одного: один между Алисой и Евой и один между Евой и Бобом. Когда Алиса посылает данные Бобу, она зашифровывает их ключом K1 (совместный ключ Алисы и Евы). Эти данные могут быть расшифрованы и прочитаны Евой.

Ева может передать сообщение Бобу, зашифрованное K2 (совместный ключ между Евой и Бобом); или она может даже изменить сообщение или передать новое сообщение. Боб введен в заблуждение, поскольку уверен, что сообщение пришло от Алисы. Подобный сценарий может случиться и в другом направлении – с Алисой.

Эта ситуация называется
” атака посредника “, поскольку Ева находится между партнерами и перехватывает R1, передаваемый Алисой Бобу, и R3, передаваемый Бобом Алисой.

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

Примечания

  1. ↑«Recommendation ITU-T X.509», на веб-сайте ITU, 2021  (Проверено 10 февраля 2021).
  2. ↑“ L’annuaire — Cadre d’authentification ” на веб-сайте ITU, 2008  (Проверено 11 февраля 2021).
  3. ↑Public-Key Infrastructure (X.509) (pkix) (неопр.). IETF Datatracker. Дата обращения: 11 марта 2021.
  4. ↑ 12Turcotte Y.Syntax testing of the entrust public key infrastructure for security vulnerabilities in the X.509 certificate (англ.) // Royal Military College of Canada (Canada) : диссертация. — 2005.
  5. ↑Tremblett P.X.509 certificates (англ.) // Miller Freeman Inc. — 1999. — Vol. 24, no. 7. — P. 42—48. — ISSN1044-789X.
  6. ↑X.509 security update (англ.) // CMP Media LLC. — 1995. — Vol. 24, no. 10. — P. 14. — ISSN0363-6399.
  7. ↑Lewis J.X.509 is a start, but it’s no panacea (англ.) // Ziff Davis Media Inc. : статья в журнале. — 1997. — Vol. 14, no. 37. — P. 109. — ISSN0740-1604.
  8. ↑Хорев Павел Борисович.Образовательная сеть доверия на основе сертификатов стандарта X.509 (рус.) // Издательский дом МЭИ (Москва) : конференция. — 2021. — 12—13 апреля.
  9. ↑Chadwick D.W., Otenko A.The PERMIS X.509 role based privilege management infrastructure (англ.) // Elsevier Science Publishing Company, Inc. — 2003. — Vol. 19, no. 2. — P. 277—289. — ISSN0167-739X.
  10. ↑Raghunathan S.A security model for mobile agent environments using X.509 proxy certificates (англ.) // University of North Texas : диссертация. — 2003.
  11. ↑Arjen Lenstra, Xiaoyun Wang, Benne de Weger. Colliding X.509 Certificates based on MD5-collisions, Eindhoven University of Technologies News (1 марта 2005 года).
  12. ↑J.R. Prins (CEO Fox-IT). DigiNotar Certificate Authority breach “Operation Black Tulip” (англ.) (PDF), FOX-IT BV (5 сентября 2021).
  13. ↑Hans Hoogstraaten (Team leader), Ronald Prins (CEO), Daniël Niggebrugge, Danny Heppener, Frank Groenewegen, Janna Wettinck, Kevin Strooy, Pascal Arends, Paul Pols. Robbert Kouprie, Steffen Moorrees, Xander van Pelt, Yun Zheng Hu. Report of the investigation into the DigiNotar Certificate Authority breach (англ.) (PDF), FOX-IT BV (13 августа 2021).
  14. ↑Jim Fenton. Top of Mind: Reexamining Public Key Infrastructure (англ.), Cisco Blogs (14 ноября 2021 года). Архивировано 23 декабря 2021 года.
  15. ↑Michael Gielesberger.Alternatives to X.509 (англ.) // Technical University of Munich : Internet Seminar. — 2021. — 1 февраль.
Check Point Check Point Endpoint Security Check Point Security Gateway JaCarta JaCarta Management System JaCarta PKI JMS pki Token Logon vpn Аладдин Р.Д. Аутентификация вакансия инженер пресейл-инженер смарт-карта
Оцените статью
Мой сертификат
Добавить комментарий

© 2025 Мой сертификат