книги / Практическая криптография

8.3 Структура решения

141

Пусть £(■) — это функция, которая возвращает длину строки данных (в байтах). Значение MAC а вычисляется по формуле

:= MAC (г |£{х{) |щ |яц),

гдеги £(х{) — 32-битовые беззнаковые целые числа, представленные в форма­ те, в котором наименее значимый байт записывается первым. Функция £(xi) гарантирует, что строка г |£(х*) |Х{ |т » уникальным образом разбивается на нужные части. При отсутствии £(х{) разбивка соответствующей строки на г, Xi и га*, а следовательно, и аутентификация были бы неоднозначны­ ми. Разумеется, данные Х{ должны быть закодированы таким образом, что­ бы их можно было разбить на разные поля без какой-либо дополнительной контекстной информации, однако гарантировать это на уровне безопасного канала общения мы не можем. За это должно отвечать приложение, исполь­ зующее наш канал общения.

8.3.3 Шифрование

Для шифрования сообщений мы будем применять блочный шифр AES врежиме CTR. В роли уникального значения оказии, необходимого для шиф­ рования в режиме CTR, будет выступать номер сообщения.

Размер каждого сообщения имеет ограничение в 16 •232 байт, что ограни­ чивает размер счетчика блоков до 32 бит. Разумеется, мы могли бы исполь­ зовать и 64-битовый счетчик, однако 32-битовые значения легче обрабаты­ вать на многих платформах. Кроме того, большинству приложений вообще не нужны такие громадные сообщения.

Ключевой поток состоит из байтов kotk i,... Для сообщения с оказией i ключевой поток определяется как

*о,• • •,*аэ.-1 := Е (К ,О II t II 0) II Е{К, 1 1|* || 0) ||... || Е(К,232 - 11| i || 0),

где каждый блок открытого текста представляет собой конкатенацию 32-би­ тового номера блока, 32-битового номера сообщения и 64 бит нулей. Получен­ ный ключевой поток будет очень длинной строкой. Мы будем использовать только первые £{тгц) + 32 байт ключевого потока. (Надеемся, не стоит упо­ минать, что оставшуюся часть ключевого потока подсчитывать не нужно...) Мы выполним конкатенацию значений пц и а* и сложим эти байты с помо­ щью операции XOR с последовательностью байтов •••i &((т<)+31*

8.3.4 Формат пакета

Мы не можем просто отослать зашифрованное значение тщ |а*, так как пользователю Б нужно знать номер сообщения. Поэтому перед зашифрован­ ным сообщением |а* будет добавлен номер сообщения г, представленный

142	Глава 8. Безопасный канал общения

в виде 32-битового целого числа, в котором наименее значимый байт записы­ вается первым.

8.4Детали реализации

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

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

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

Для описания наших алгоритмов будем использовать псевдокод, понят­ ный всем, кто хоть немного знаком с соглашениями, принятыми в языках программирования. Блоки операторов будут выделяться с помощью отсту­ пов и парных ключевых слов наподобие i f / f i или do/od.

8.4.1Инициализация

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

ф ун к ц и я IN ITIA LIZE SE C U R E C H AN NEL

вход: К Ключ канала общения, 256 бит.

RРоль. Указывает, кем является участник — пользователем А или Б.

выход: S Состояние безопасного канала общения.

Вначале построим четыре дочерних ключа. Это будут четыре строки ASCII без фиксированной длины и нуль-терминаторов.

K E Y SE N D E N O - SHAd -	256(К |“Шифрование от А к Б” )
K E Y R E C E N C * - SHAd -	256(К |“Шифрование от Б к А”)
K E Y SE N D A U TH « - SHAd -		256{К |“Аутентификация от А к Б” )
K E Y R B C A U TH <- SHAd -		256(К |“Аутентификация от Б к А” )

g4 Детали реализации

143

Поменяем местами ключи шифрования и дешифрования, если участ­ ник — пользователь Б.

if Л = “Пользователь Б” then

S W A P (K E Y S E N D E N C , K E Y R ECE NC)

S W A P (K E Y S E N D A U T H , K E YR ECA UTH)

fi

Установим значения счетчиков отправленных и полученных сообще­ ний равными 0. Счетчик отправленных сообщений — это номер последнего отправленного сообщения. Счетчик полученных сообще­ ний — это номер последнего полученного сообщения.

(M S G C N T SE N D , M S G C N T R E C ) +- (0,0)

Зафиксируем состояние.

S <- (K E Y S E N D E N C ,

K E Y R E C E N C ,

K E Y SE N D A U T H ,

K E Y R E C A U T H ,

M S G C N T S E N D ,

M S G C N T R E C ) retu rn S

У нас есть еще одна функция, которая уничтожает значение состояния 5. Мы не будем рассматривать ее реализацию более подробно. Все, что требу­ ется от данной функции, — это очистить и высвободить память, в которой хранится переменная S. Обратите внимание на слово “очистить” — это очень важный момент. Во многих системах функция высвобождения памяти не обя­ зательно очищает ее, поэтому по окончании использования состояния S его необходимо удалить явно.

8.4.2 Отправка сообщения

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

ф ункция SE N D M E S SA G E

вход: S Состояние безопасного сеанса.

т Сообщение, которое должно быть отправлено.

144	Глава 8. Безопасный канал общения

хДополнительные данные, которые должны подвергнуться аутентификации.

выход: t Данные, которые должны быть переданы получателю.

Вначале проверим номер сообщения и обновим его. assert M S G CN T SE N D < 232 - 1

M S G C N T SEND <- M S G C N T SEND + 1

i « -M SG C N T SEND

Подсчитаем значение MAC. Kaoicdoe значение £(x) и i представлено в виде 4-байтового числа, у которого наименее значимый байт за­ писывается первым.

a *-HMAC-SHA-256(KE Y SE N D A U T H , i |£{х) |х |т) t *—т || а

Сгенерируем ключевой поток. Каждый блок открытого текста, по­ дающийся на вход блочного шифра, состоит из 4-байтового счет­ чика блоков, четырех байтов значения i и восьми байтов нулей. Целые числа представлены в формате, в котором наименее значи­ мый байт записывается первым. Е — это функция шифрования AES с 256-битовым ключом.

К « -K E Y SENDENC

* <— Ек(0 |i |0) |Ек(11|i |0) ||...

Сформируем окончательный вариант сообщения. И вновь значение i будет представлено 4-байтовым числом, в котором наименее зна­ чимый байт записывается первым,

t *- i |(t е F IR S T - £{t) - B Y T E S (fc)) return t

Данный алгоритм выглядит довольно просто (см. раздел 8.3). Вначале мы проверяем, не исчерпаны ли значения счетчика сообщений. Переоценить важность такой проверки невозможно. Если счетчик сообщений когда-нибудь вернется к нулю, это полностью разрушит безопасность системы. К сожале­ нию, подобные ошибки встречаются слишком часто. Аутентификация и шиф­ рование выполняются так, как было описано ранее в главе. И наконец, к за­ шифрованному и аутентифицированному сообщению добавляется значение г, чтобы получатель знал номер сообщения.

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

8,4 Детали реализации

145

8.4.3 Получение сообщения

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

SENDME SSA G E , и те ж е самые дополнительные данные х, которые должны

быть аутентифицированы.

ф ункция R E C E IV E M E SSA G E

вход:	«5 Состояние безопасного сеанса.
t	Текст, переданный отправителем.

хДополнительные данные, которые должны подвергнуться аутентификации.

выход: т Сообщение, которое было отправлено.

Полученное сообщение должно, как минимум, содержать 4-байтовый номер сообщения и 32-байтовое значение MAC. Следующая провер­ ка гарантирует, что все последующие операции разбивки сообщения на поля могут быть выполнены корректно.

assert i{t) > 36

Разобьем t на две части: г и зашифрованное сообщение плюс аутенти­ фикатор. Такая разбивка будет однозначной, поскольку длина г все­ гда равна 4 байт.

i\\t *— t

Сгенерируем ключевой поток точно так же, как это делал отправи­ тель.

К « -K E Y R E C E N C

*«-Bjr(0|t|0)|B*(l II > 10) 1...

Расшифруем t и разобьем полученный результат на сообщение и значе­ ние MAC. Такая разбивка будет однозначной, поскольку длина а все­ гда равна 32 байт,

т |а <— 10 F I R S T - 2{t) - B Y T E S (£)

Пересчитаем значение аутентификатора. Каждое значение 2(х)и i представлено в виде 4-байтового числа, у которого наименее зна­ чимый байт записывается первым,

а' H M AC-SH A-256(K E Y R ECA UTH, г |£(х) |х |т) if а ф a' th e n

d e s tro y	k, т
re tu rn	A U TH E N T IC A T IO N FAILURE
else if i < M S G C N T R EC then
d e s tro y	k, m

re tu rn M E S S A G E O R D E R ER RO R

146	Глава 8. Безопасный канал общения

M S G C N T R EC <- i

return m

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

Нельзя не отметить еще один важный момент, касающийся получателя сообщений. Функция R E C E IV E M ESSAGE не должна раскрывать никакой ин­ формации о ключе или открытом тексте сообщения до тех пор, пока сообще­ ние не прошло аутентификацию. Бели аутентификация окончится неудачей, функция должна уведомить получателя об ошибке, но не возвращать ника­ кой информации о ключевом потоке или открытом тексте. Вместо этого она должна очистить области памяти, в которых те хранились. Почему это так важно? Наличие открытого текста сообщения позволяет вычислить ключевой поток, поскольку мы исходим из предположения, что злоумышленник знает шифрованный текст. Опасность состоит в том, что злоумышленник отошлет ложное сообщение (с некорректным значением MAC). Сообщение будет от­ брошено, но злоумышленник все равно узнает ключевой поток по данным, выданным функцией получателя. Как видите, в дело вновь вступает пара­ ноидальная модель, согласно которой любая информация, преждевременно раскрытая или упущенная функцией R E C E IV E M E S S A G E , автоматически по­ падает в руки злоумышленника. Уничтожая данные, хранящиеся в перемен­ ных к п т , еще до того как функция R E C E IV E M E S S A G E возвратит ошибку, мы предотвращаем какую-либо утечку этих данных.

8.4.4Порядок сообщений

Как и отправитель, получатель обновляет состояние S , изменяя значение переменной M S G C N T R E C . Получатель гарантирует, что номера принятых им сообщений строго возрастают. Это исключает возможность повторного при­ нятия одного и того же сообщения, однако, если в процессе передачи по сети поток сообщений будет переупорядочен, получателю придется отбросить це­ лый ряд совершенно корректных (во всем остальном) сообщений.

8.5 Альтернативы

147

Это упущение довольно легко исправить (хотя и за счет некоторых рас­ ходов). Если разрешить получателю принимать сообщения вне зависимости от их порядка, тогда приложение, использующее безопасный канал общения, должно обладать возможностью обработки сообщений, номера которых “вы­ биваются” из общей последовательности. Многие приложения не способны справиться с подобной ситуацией. Некоторые системы могут обрабатывать неупорядоченные сообщения, однако обладают небольшими изъянами (зача­ стую в области безопасности). В большинстве ситуаций мы предпочитаем исправлять ошибки транспортного уровня и гарантировать, что случайное перемешивание сообщений невозможно, а значит, безопасному каналу обще­ ния не придется сталкиваться с подобной проблемой.

Порой возникает ситуация, когда получатель допускает прием сообщений, прибывших не по порядку; и тому есть очень важная причина. Речь идет об IPSec — протоколе безопасности IP (IP Security) [50], который выполняет шифрование и аутентификацию IP-пакетов. Поскольку IP-пакеты могут быть переупорядочены в процессе передачи по сети и все приложения, использую­ щие протокол IP, знают об этом свойстве, IPSec не просто запоминает номер последнего полученного сообщения, а отслеживает целый диапазон номеров сообщений. Если с — это номер последнего полученного сообщения, IPSec ор­ ганизует битовую карту для номеров сообщений с-31, с-30, с -2 9 ,..., с - 1, с. Каждый бит этой карты указывает на то, было ли получено сообщение с соот­ ветствующим номером. Сообщения с номерами, меньшими чем с -3 1 , всегда отклоняются. Сообщения с номерами в диапазоне от с-31 до с-1 принимают­ ся только тогда, когда значение соответствующего бита равно 0 (разумеется, после этого оно изменяется на 1). Если же номер нового сообщения больше с, значение с обновляется, а битовая карта соответствующим образом сдвигает­ ся. Подобная схема допускает ограниченный прием переупорядоченных сооб­ щений и при этом не требует хранить слишком много сведений о состоянии.

8.5Альтернативы

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

Когда мы писали эту книгу, Нильс работал с клиентом, который столк­ нулся с аналогичной проблемой. Вначале в качестве режима работы блочно­ го шифра предполагалось использовать ОСВ [82, 83]. Преимущество данного режима состоит в том, что и аутентификация и шифрование выполняются с помощью блочного шифра, а потому не требуют реализации дополнитель-

148	Глава 8. Безопасный канал общения

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

Для решения этой проблемы Дуг Уайтинг (Doug Whiting), Расс Хаусли (Russ Housley) и Нильс скомбинировали режим CTR с аутентификацией СВС-МАС. Полученный режим работы блочного шифра получил название ССМ (по первым буквам аббревиатур CTR, СВС и MAC) [93]. По сравне­ нию с ОСВ режим ССМ требует выполнения вдвое большего числа операций для шифрования и аутентификации сообщения, однако, насколько мы знаем, проблем с его патентованием нет вообще. Разработчикам ССМ не известно ни одного патента, защищающего этот режим, а сами они патентовать его не собираются. Якоб Йонссон (Jakob Jonsson) получил доказательство без­ опасности для ССМ [14], a NIST рассматривает вопрос стандартизации ССМ в качестве режима работы блочного шифра.

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

Одно из существенных различий между режимами ССМ и ОСВ состоит в их поведении при осуществлении атак на основе коллизий. В ССМ приме­ няется режим шифрования CTR, при использовании которого после шифро­ вания более 264 блоков данных (при условии, что размер блока составляет 128 бит) начинается утечка информации. Поэтому спецификации ССМ огра­ ничивают количество блоков, которые могут быть зашифрованы с помощью одного и того же ключа, до 260. При этом объем утечки информации опуска­ ется до несущественного (порядка доли бита). На часть режима ССМ, ответ­ ственную за выполнение аутентификации, известных атак на основе коллизий пока что не существует. Таким образом, хотя ССМ не позволяет полностью достигнуть 128-битового уровня безопасности, он практически приближает­ ся к этому уровню и работает так же хорошо, как другие режимы работы блочных шифров.

В отличие от ССМ, для режима ОСВ существует атака на основе колли­ зий, направленная на функцию аутентификации. При возникновении колли­ зии свойства аутентификации будут полностью утеряны [34]. Это означает, что ОСВ не может обеспечить 128-битовый уровень безопасности. Если огра­ ничить количество блоков, которые могут быть зашифрованы с помощью

8.6 Заключение

149

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

Думаем, вы нисколько не удивитесь, узнав, что мы предпочитаем ССМ. Данный режим представляется нам вполне разумной альтернативой безопас­ ному каналу общения, определенному в этой главе. Но, конечно же, мы не можем быть полностью объективными, поскольку сами принимали участие в разработке этого режима.

Еще один момент: ССМ, ОСВ и аналогичные режимы не гарантируют полной безопасности канала общения. Они обеспечивают функциональность шифрования и аутентификации и требуют наличия ключа и уникальной ока­ зии для каждого пакета. При необходимости наши алгоритмы безопасного канала общения легко адаптировать таким образом, чтобы они использова­ ли подобные режимы, а не отдельные функции шифрования и вычисления MAC. Вместо четырех дочерних ключей, которые генерировались функци­ ей INITIALIZESE C U R E C H A N N E L , вам понадобится два ключа — по одному на каждое направление трафика. Значение оказии может быть получено путем дополнения номера сообщения до нужного размера.

8.6 Заключение

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

Глава 9

Проблемы реализации. Часть I

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

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

До сих пор тематика наших обсуждений была ограничена вопросами крип­ тографии. В этой главе, однако, мы решили сконцентрировать внимание на окружении, в котором функционируют криптографические алгоритмы. Каж­ дая часть системы влияет на безопасность. Чтобы получить действительно надежную систему, все ее компоненты с самого начала должны разрабаты­ ваться не просто с оглядкой на безопасность; безопасность должна стать од­ ной из главных целей. “Система”, о которой мы говорим, может быть очень большой. Она включает в себя все компоненты окружения, неправильное по­ ведение которых может негативно отразиться на свойствах безопасности.

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