Рекомендации семейства X.500

Простая и сильная аутентификация

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

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

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

Рассмотрим более подробно реализацию разновидности 2 простой аутентификации. Пользователь A сначала генерирует токен безопасности   PT1:

PT1 = h1 (t1A, r1A, A, passwdA)

Токен PT1 используется для создания аутентификационного токена AT1:

AT1 = t1A, r1A, A, PT1

(т. е. токен AT1 состоит из четырех компонентов). Пользователь A пересылает пользователю B токен AT1. Цель B - своими средствами создать аналог токена безопасности PT1 (реконструировать PT1 ) и сравнить его с оригиналом. Он запрашивает у службы директорий или извлекает самостоятельно локальную копию пароля passwdA (обозначим ее passwdA-B ) и реконструирует PT1:

PT1-B = h1 (t1A, r1A, A, passwdA-B)

Если PT1 и PT1-B совпадут, подлинность пользователя A считается установленной.

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

Рекомендации X.509 описывают три возможные процедуры сильной аутентификации:

• односторонний обмен. От пользователя A пользователю B передается один токен. При этом подтверждается подлинность A и B, а также то, что токен сгенерирован A, предназначен B, не был изменен и является "оригинальным" (т. е. не посылается повторно);
• двусторонний обмен. Дополнительно от B к A направляется ответ, допускающий проверку того, что он был сгенерирован B, предназначен A, не был изменен и является "оригинальным";
• трехсторонний обмен. От A к B передается еще один токен. Обеспечивает те же свойства, что и двусторонний, без использования временных штампов.

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

Рассмотрим более подробно процедуру одностороннего обмена.

В качестве первого шага пользователь A генерирует "уникальное" число rA, предназначенное для защиты от воспроизведения и подделки аутентификационного токена.

После этого A направляет B сообщение следующей структуры:

B -> A, A {tA, rA, B}

где tA - временной штамп, в общем случае представляющий собой пару (время генерации токена и срок его годности). (Напомним, что конструкция вида A {I} обозначает информацию I, подписанную открытым ключом A.)

Получив это сообщение, B предпринимает следующие действия:

• по обратному сертификационному пути B -> A выясняет открытый ключ A (A_p), попутно проверяя статус сертификата A ;
• проверяет подпись и, тем самым, целостность присланной информации;
• проверяет, что в качестве получателя указан B ;
• удостоверяется, что временной штамп "свежий", а число rA ранее не использовалось.

Двусторонний и трехсторонний обмены являются довольно очевидным развитием одностороннего.

На этом мы завершаем рассмотрение рекомендаций семейства X.500.