Современная криптография - Венбо Мао
ISBN 5-8459-0847-7
Скачать (прямая ссылка):
1. Боб —> Алисе: Nb-
2. Алиса —* Бобу: sigi4(M, Nb)-
3. Боб проверяет цифровую подпись, используя свое одноразовое (11-4-3) случайное число, и либо принимает его, если подпись является подлинной, либо отказывается в противном случае.
Обратите внимание на то, что в этой стратегии свободный выбор Алисой сообщения М является важным обстоятельством. В этом случае Алиса не может непреднамеренно подписать сообщение, подготовленное Бобом. Например, Боб может приготовить свое "случайное число" следующим образом:
Nb = h (Перевести 1 ООО фунтов на счет Боба № 123 со счета Алисы № 456),
где h — функция хэширования.
В некоторых приложениях лицо, подписывающее сообщение и играющее роль j Алисы в стратегии (11.4.3), не имеет свободы при выборе сообщения М. В та- j ких ситуациях используются специализированные ключи. Например, открытый I ключ, предназначенный для верификации подписи Алисы в стратегии (11.4.3), I можно уточнить. Специализация криптографических ключей является предметом I изучения теории управления ключами (key management).
11.4.1.2 Стандартная стратегия "оклик-отзыв"
Международная организация по стандартизации (International Organization for I Standardization — ISO) и Международная электротехническая комиссия (Interna- | tional Electrotechnical Commission — IEC) приняли описанные выше три стратегии I в качестве стандартных конструкций стратегии односторонней аутентификации I сущности (unilateral entity authentication). Стандартный вариант стратегии (11.4.1) | называется "Двухпроходным односторонним протоколом аутентификации ISO" I ("ISO Two-pass Unilateral Authentication Protocol") [147]. Он выглядит следующим I образом.
Глава 11. Протоколы аутентификации — принципы
393
1. B-+A:RB ||Textl;
2. А -» В : TokenAB.
Здесь TokenAB = Text3 || ?Kab(Rb || В || Text2).
Получив сообщение TokenAB, Боб должен расшифровать его. Если в результате расшифровки восстанавливается правильное значение случайного числа Rb, аутентификация считается успешной, а если нет — безуспешной. Здесь и далее при описании стандартов КОЛЕС используются обозначения, принятые в спецификациях стандартных протоколов, где Textl, Text2 и т.д. — необязательные поля, символ || означает операцию конкатенации, a RB — одноразовое случайное число, сгенерированное Бобом.
Напомним, что алгоритм шифрования должен обеспечивать защиту целостности данных. Это является необходимым условием для того, чтобы можно было >проверить правильность результатов расшифровки (см. замечание 11.2 в разделе 11.4.1.1).
Заметим также, что стратегия (11.4.1) предназначена для проверки "свежести" сообщений, а ее стандартный аналог — для аутентификации сущностей. Следовательно, включение сообщения В, т.е. имени Боба вместо сообщения М в стратегии (11.4.1) является очень важным моментом: это подчеркивает, что механизм ISO/IEC предназначен для проверки существования Боба и представляет собой протокол аутентификации, в котором Боб является субъектом. Абади (АЬа-di) и Нидхем создали список принципов, которыми должен руководствоваться разработчик криптографических протоколов [1]. Одним из таких принципов является явное выделение сущности, представляющей собой субъект аутентификации. В разделе 11.7.7 мы убедимся, что нарушение этого принципа создает опасную ситуацию.
Стандартный вариант стратегии (11.4.2) называется "двухпроходным односторонним протоколом аутентификации с использованием криптографической тестовой функции (CCF)" ("ISO Two-pass Unilateral Authentication Protocol Using a Cryptographic Check Function (CCF)") [149]. Он выглядит следующим образом.
1. B-*A:RB || Textl;
2. A—> В : TokenAR
Здесь4 TokenAB = Text2 || /йгав(Дв || В || Text2), где / — криптографическая функция хэширования, имеющая ключ.
Получив сообщение TokenAB, Боб должен реконструировать ключевую функцию CCF, используя общий ключ, свое случайное число, свое имя и поле Text2. Если в результате расшифровки восстановленный блок функ-
4В работе [149] поле Text2 в открытом тексте ошибочно обозначено как Text3. Если в открытом тексте нет поля Text2, пользователь в не может верифицировать функцию CCF путем ее реконструкции.
394
Часть IV. Аутентификация
ции CCF совпадает с полученным, аутентификация считается успешной!
а если нет — безуспешной. Стандартный вариант стратегии (11.4.3) называется "двухпроходным одно-j сторонним протоколом аутентификации с открытым ключом ISO" ("ISO public-J Key Two-pass Unilateral Authentication Protocol") [148]. Он выглядит следующий образом.
1. В —> A: Rb || Textl;
2. А—> В : CertA || ТокепЛВ.
Здесь ТокепЛБ = RA || RB \\ В || Text3 || sigA(RA || Rb || В || Text2), гд! Cert/i — сертификат открытого ключа Алисы (это понятие вводится в слеш дующей главе).
Получив сообщение ТокепАВ, Боб должен верифицировать его цифро вую подпись. Если подпись проходит проверку, аутентификация считаете-успешной, а если нет — безуспешной. Как указывалось при описании стратегии (11.4.3), в данном протоколе ISO/IE пользователь А может свободно выбирать случайное число RA для того, чтобЛ предотвратить непреднамеренное подписание сообщения, подготовленное поль| зователем В.
