Простая и сильная аутентификация
Каркасы сертификатов открытых ключей и атрибутов - основа целого ряда сервисов безопасности, в число которых входят аутентификация, контроль целостности, управление доступом. Они могут использоваться как самой Директорией, так и произвольными приложениями. В этом разделе мы рассмотрим простую и сильную аутентификации, включенные в рекомендации 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 (Ap), попутно проверяя статус сертификата A;
- проверяет подпись и, тем самым, целостность присланной информации;
- проверяет, что в качестве получателя указан B;
- удостоверяется, что временной штамп "свежий", а число rA ранее не использовалось.
Двусторонний и трехсторонний обмены являются довольно очевидным развитием одностороннего.
На этом мы завершаем рассмотрение рекомендаций семейства X.500.
<
