В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 8. Безопасный канал общения x Дополнительные данные, которые должны подвергнуться аутентификации. выход: t Данные, которые должны быть переданы получателю. Вначале проверим номер сообщения и обновим его. assert MsgCntSend < 2 32 − 1 MsgCntSend ← MsgCntSend + 1 i ← MsgCntSend Подсчитаем значение MAC. Каждое значение ` ( x ) и i представлено в виде 4-байтового числа, у которого наименее значимый байт за- писывается первым. a ← HMAC-SHA-256( KeySendAuth, i k ` ( x ) k x k m ) t ← m k a Сгенерируем ключевой поток. Каждый блок открытого текста, по- дающийся на вход блочного шифра, состоит из 4-байтового счет- чика блоков, четырех байтов значения i и восьми байтов нулей. Целые числа представлены в формате, в котором наименее значи- мый байт записывается первым. E — это функция шифрования AES с 256-битовым ключом. K ← KeySendEnc k ← E K (0 k i k 0) k E K (1 k i k 0) k . . . Сформируем окончательный вариант сообщения. И вновь значение i будет представлено 4-байтовым числом, в котором наименее зна- чимый байт записывается первым. t ← i k ( t ⊕ First − ` ( t ) − bytes ( k )) return t Данный алгоритм выглядит довольно просто (см. раздел 8.3). Вначале мы проверяем, не исчерпаны ли значения счетчика сообщений. Переоценить важность такой проверки невозможно. Если счетчик сообщений когда-нибудь вернется к нулю, это полностью разрушит безопасность системы. К сожале- нию, подобные ошибки встречаются слишком часто. Аутентификация и шиф- рование выполняются так, как было описано ранее в главе. И наконец, к за- шифрованному и аутентифицированному сообщению добавляется значение i , чтобы получатель знал номер сообщения. Обратите внимание: мы обновляем состояние сеанса, потому что количе- ство отправленных сообщений изменяется. Это крайне важно, поскольку но- мер сообщения должен быть уникальным. Впрочем, практически каждая со- ставляющая наших алгоритмов критически важна для безопасности системы. 8.4. Детали реализации 145 8.4.3 Получение сообщения Алгоритм получения сообщений принимает на вход зашифрованное сооб- щение с аутентификатором, полученное в результате применения функции SendMessage , и те же самые дополнительные данные x , которые должны быть аутентифицированы. функция ReceiveMessage вход: S Состояние безопасного сеанса. t Текст, переданный отправителем. x Дополнительные данные, которые должны подвергнуться аутентификации. выход: m Сообщение, которое было отправлено. Полученное сообщение должно, как минимум, содержать 4-байтовый номер сообщения и 32-байтовое значение MAC. Следующая провер- ка гарантирует, что все последующие операции разбивки сообщения на поля могут быть выполнены корректно. assert ` ( t ) ≥ 36 Разобьем t на две части: i и зашифрованное сообщение плюс аутенти- фикатор. Такая разбивка будет однозначной, поскольку длина i все- гда равна 4 байт. i k t ← t Сгенерируем ключевой поток точно так же, как это делал отправи- тель. K ← KeyRecEnc k ← E K (0 k i k 0) k E K (1 k i k 0) k . . . Расшифруем t и разобьем полученный результат на сообщение и значе- ние MAC. Такая разбивка будет однозначной, поскольку длина a все- гда равна 32 байт. m k a ← t ⊕ First − ` ( t ) − bytes ( k ) Пересчитаем значение аутентификатора. Каждое значение ` ( x ) и i представлено в виде 4-байтового числа, у которого наименее зна- чимый байт записывается первым. a 0 ← HMAC-SHA-256 ( KeyRecAuth , i k ` ( x ) k x k m ) if a 6 = a 0 then destroy k , m return AuthenticationFailure else if i ≤ MsgCntRec then destroy k , m return MessageOrderError fi |