Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Ответы для экзамена - Информационная безопасность - файл 1.doc


Ответы для экзамена - Информационная безопасность
скачать (974 kb.)

Доступные файлы (1):

1.doc974kb.16.11.2011 00:46скачать

1.doc

1   ...   4   5   6   7   8   9   10   11   12

30. Хэш-функции

^

Требования к хэш-функциям


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

Хэш-код создается функцией Н:

h = H (M)

Где М является сообщением произвольной длины и h является хэш-кодом фиксированной длины.

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

Хэш-функция Н, которая используется для аутентификации сообщений, должна обладать следующими свойствами:

  1. Хэш-функция Н должна применяться к блоку данных любой длины.

  2. Хэш-функция Н создает выход фиксированной длины.

  3. Н (М) относительно легко (за полиномиальное время) вычисляется для любого значения М.

  4. Для любого данного значения хэш-кода h вычислительно невозможно найти M такое, что Н (M) = h.

  5. Для любого данного х вычислительно невозможно найти y x, что H (y) = H (x).

  6. Вычислительно невозможно найти произвольную пару (х, y) такую, что H (y) = H (x).

Хеширование паролей
Для того, чтобы не заставлять человека запоминать ключ – длинную последовательность цифр, были разработаны методы преобразования строки символов любой длины (так называемого пароля) в блок байт заранее заданного размера (ключ). На алгоритмы, используемые в этих методах, накладываются требования, сравнимые с требованиями на сами криптоалгоритмы.

От методов, повышающих криптостойкость системы в целом, перейдем к блоку хеширования паролей – методу, позволяющему пользователям запоминать не 128 байт, то есть 256 шестнадцатиричных цифр ключа, а некоторое осмысленное выражение, слово или последовательность символов, называющуюся паролем. Действительно, при разработке любого криптоалгоритма следует учитывать, что в половине случаев конечным пользователем системы является человек, а не автоматическая система. Это ставит вопрос о том, удобно, и вообще реально ли человеку запомнить 128-битный ключ (32 шестнадцатиричные цифры). На самом деле предел запоминаемости лежит на границе 8-12 подобных символов, а, следовательно, если мы будем заставлять пользователя оперировать именно ключом, тем самым мы практически вынудим его к записи ключа на каком-либо листке бумаги или электронном носителе, например, в текстовом файле. Это, естественно, резко снижает защищенность системы.

Для решения этой проблемы были разработаны методы, преобразующие произносимую, осмысленную строку произвольной длины – пароль, в указанный ключ заранее заданной длины. В подавляющем большинстве случаев для этой операции используются так называемые хеш-функции (от англ. hashing – мелкая нарезка и перемешивание). Хеш-функцией называется такое математическое или алгоритмическое преобразование заданного блока данных, которое обладает следующими свойствами:

  1. хеш-функция имеет бесконечную область определения,

  2. хеш-функция имеет конечную область значений,

  3. она необратима,

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

Эти свойства позволяют подавать на вход хеш-функции пароли, то есть текстовые строки произвольной длины на любом национальном языке и, ограничив область значений функции диапазоном 0..2N-1, где N – длина ключа в битах, получать на выходе достаточно равномерно распределенные по области значения блоки информации – ключи.

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

31. Цифровая подпись

Требования к цифровой подписи


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

Например, предположим, что Джон посылает Мери аутентифицированное сообщение, и аутентификация осуществляется на основе общего секрета. Рассмотрим возможные недоразумения, которые могут при этом возникнуть:

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

  • Джон может отрицать, что он посылал сообщение Мери. Так как Мери может подделать сообщение, у нее нет способа доказать, что Джон действительно посылал его.

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

  1. Должна быть возможность проверить автора, дату и время создания подписи.

  2. Должна быть возможность аутентифицировать содержимое во время создания подписи.

  3. Подпись должна быть проверяема третьей стороной для разрешения споров.

Таким образом, функция цифровой подписи включает функцию аутентификации.

На основании этих свойств можно сформулировать следующие требования к цифровой подписи:

  1. Подпись должна быть битовым образцом, который зависит от подписываемого сообщения.

  2. Подпись должна использовать некоторую уникальную информацию отправителя для предотвращения подделки или отказа.

  3. Создавать цифровую подпись должно быть относительно легко.

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

  5. ^ Цифровая подпись должна быть достаточно компактной и не занимать много памяти.

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

Существует несколько подходов к использованию функции цифровой подписи. Все они могут быть разделены на две категории: прямые и арбитражные.
^

Прямая и арбитражная цифровые подписи


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

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

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

Другая угроза состоит в том, что закрытый ключ может быть действительно украден у Х в момент времени Т. Нарушитель может затем послать сообщение, подписанное подписью Х и помеченное временной меткой, которая меньше или равна Т.

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

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

Рассмотрим некоторые возможные технологии арбитражной цифровой подписи.

^ 32. Симметричное шифрование, арбитр видит сообщение:

Х A: M || EKxa [ IDX || H (M)]

Предполагается, что отправитель Х и арбитр А разделяют секретный ключ KХА и что А и Y разделяют секретный ключ KАY. Х создает сообщение М и вычисляет его хэш-значение Н (М). Затем Х передает сообщение и подпись А. Подпись состоит из идентификатора Х и хэш-значения, все зашифровано с использованием ключа KХА. А дешифрует подпись и проверяет хэш-значение.

A Y: ЕКay [ IDX || M ||

EKxa [IDX || H (M)], T ]

Затем А передает сообщение к Y, шифруя его KAY. Сообщение включает IDX, первоначальное сообщение от Х, подпись и отметку времени. Y может дешифровать его для получения сообщения и подписи. Отметка времени информирует Y о том, что данное сообщение не устарело и не является повтором. Y может сохранить М и подпись к нему. В случае спора Y, который утверждает, что получил сообщение М от Х, посылает следующее сообщение к А:

ЕКay [ IDX || M || EKxa [IDX || H (M)] ]

Арбитр использует KAY для получения IDХ, М и подписи, а затем, используя KХА, может дешифровать подпись и проверить хэш-код. По этой схеме Y не может прямо проверить подпись Х; подпись используется исключительно для разрешения споров. Y считает сообщение от Х аутентифицированным, потому что оно прошло через А. В данном сценарии обе стороны должны иметь высокую степень доверия к А:

  1. Х должен доверять А в том, что тот не будет раскрывать KХА и создавать фальшивые подписи в форме ЕKка [IDX || H (M)].

  2. Y должен доверять А в том, что он будет посылать ЕKay [ IDX || M || EKxa [IDX || H (M)] ] только в том случае, если хэш-значение является корректным и подпись была создана Х.

  3. Обе стороны должны доверять А в решении спорных вопросов.

^ 33. Симметричное шифрование, арбитр не видит сообщение:

Если арбитр не является такой доверенной стороной, то Х должен добиться того, чтобы никто не мог подделать его подпись, а Y должен добиться того, чтобы Х не мог отвергнуть свою подпись.

Предыдущий сценарий также предполагает, что А имеет возможность читать сообщения от Х к Y и что возможно любое подсматривание. Рассмотрим сценарий, который, как и прежде, использует арбитраж, но при этом еще обеспечивает конфиденциальность. В таком случае также предполагается, что Х и Y разделяют секретный ключ KXY.

X A: IDX || EKхy [M] ||

EKxa [IDX || H (EKXY [M]) ]

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

A Y: EKay [ IDX || EKXY[M] ||

EKxa [ IDX || H ( EKXY [M])], T]

А передает Y все, что он получил от Х плюс отметку времени, все шифруя с использованием ключа KAY.

Хотя арбитр и не может прочитать сообщение, он в состоянии предотвратить подделку любого из участников, Х или Y. Остается проблема, как и в первом сценарии, что арбитр может сговориться с отправителем, отрицающим подписанное сообщение, или с получателем, для подделки подписи отправителя.

^ 34. Шифрование открытым ключом, арбитр не видит сообщение:

Все обсуждаемые проблемы могут быть решены с помощью схемы открытого ключа.

X A: IDX || EKRх [ IDX || EKUy [EKRx [M] ] ]

В этом случае Х осуществляет двойное шифрование сообщения М, сначала своим закрытым ключом KRX, а затем открытым ключом Y   KUY. Получается подписанная секретная версия сообщения. Теперь это подписанное сообщение вместе с идентификатором Х шифруется KRX и вместе с IDX посылается А. Внутреннее, дважды зашифрованное, сообщение недоступно арбитру (и всем, исключая Y). Однако А может дешифровать внешнюю шифрацию, чтобы убедиться, что сообщение пришло от Х (так как только Х имеет KRX). Проверка дает гарантию, что пара закрытый/открытый ключ законна, и тем самым верифицирует сообщение.

A Y: EKRa [ IDX || EKUy [EKRx [M] ] || T ]

Затем А передает сообщение Y, шифруя его KRA. Сообщение включает IDX, дважды зашифрованное сообщение и отметку времени.

Эта схема имеет ряд преимуществ по сравнению с предыдущими двумя схемами. Во-первых, никакая информация не разделяется участниками до начала соединения, предотвращая договор об обмане. Во-вторых, некорректные данные не могут быть посланы, даже если KRX скомпрометирован, при условии, что не скомпрометирован KRА. В заключение, содержимое сообщения от Х к Y неизвестно ни А, ни кому бы то ни было еще.
1   ...   4   5   6   7   8   9   10   11   12



Скачать файл (974 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации