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

НМАС

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

При разработке алгоритма НМАС преследовались следующие цели:

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

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

Введем следующие обозначения:

Н - встроенная хэш-функция.

b - длина блока используемой хэш-функции.

n - длина хэш-кода.

K - секретный ключ. К этому ключу слева добавляют нули, чтобы получить b-битовый ключ K⁺.

Вводится два вспомогательных значения:

Ipad - значение '00110110', повторенное b/8 раз.

Opad - значение '01011010', повторенное b/8 раз.

Далее НМАС вычисляется следующим образом:

НМАС = Н ((K⁺ Opad) || H ((K⁺ Ipad) || M))

10. Лекция: Цифровая подпись: Рассматриваются основные требования к цифровым подписям, прямая и арбитражная цифровая подпись, стандарты цифровой подписи ГОСТ 3410 и DSS.

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2014-12-23