Система защиты Bluetooth (версии 2.1 и более поздние) может работать в четырех режимах, начиная от полного бездействия и заканчивая тотальным шифрованием данных и контролем целостности. Как и в случае с 802.11, если система защиты отключена (по умолчанию для старых устройств это именно так), о какой-либо безопасности говорить не приходится. Большинство пользователей не включают защиту до тех пор, пока не грянет гром. Можно привести сельскохозяйственный пример такого подхода: ворота конюшни закрывают только после исчезновения лошади.
Bluetooth обеспечивает безопасность на нескольких уровнях. На физическом уровне для этого применяются скачкообразные изменения частот, но поскольку любое устройство, появляющееся в микросети, должно узнать последовательность скачков частоты, эта последовательность, очевидно, не является секретной. Настоящая защита информации начинает проявляться тогда, когда вновь прибывшее подчиненное устройство пытается запросить канал для связи с управляющим устройством. До появления Bluetooth 2.1 предполагалось, что оба устройства совместно использовали предварительно установленный закрытый ключ. В некоторых случаях он прошивается в обоих устройствах (например, в гарнитуре и мобильном телефоне, продающихся вместе). В других случаях в одном из устройств (например, в гарнитуре) ключ прошит, а в сопряженное устройство (например, мобильный телефон) пользователь должен ввести ключ вручную в виде десятичного числа. Общие ключи такого типа называются отмычками (passkeys). К сожалению, отмычки очень часто жестко кодируются как «1234» или другие предсказуемые значения, и в любом случае это будет четырехзначное число, имеющее только 104 вариантов. При Bluetooth 2.1 устройства выбирают код из шестизначного диапазона, что делает отмычку менее предсказуемой, но все же недостаточно надежной.
Перед установкой канала подчиненное и управляющее устройства должны выяснить, владеют ли они отмычками. В случае положительного ответа им необходимо договориться о том, каким будет канал: шифрованным, с контролем целостности или и таким, и таким. Затем выбирается ключ сеанса длиной 128 бит, некоторые биты которого могут быть сделаны общедоступными. Такое послабление сделано в целях соответствия системы ограничениям, введенным правительствами разных стран и запрещающим экспорт или использование ключей, длина которых больше той, что способно взломать правительство.
Шифрование выполняется с применением потокового шифра E0, контроль целостности — с применением SAFER+. И тот и другой представляют собой традиционные блочные шифры с симметричными ключами. SAFER+ пытались использовать в AES, однако очень быстро отказались от этой мысли, так как он работал гораздо медленнее других. Работа над Bluetooth завершилась еще до того, как был выбран шифр AES; в противном случае, вероятно, использовался бы алгоритм Rijndael.
Процесс шифрования с использованием потокового (группового) шифра показан на рис. 8.12. На нем видно, что открытый текст суммируется по модулю 2 с ключевым потоком. В результате получается шифрованный текст. К сожалению, алгоритм E0, как и RC4, чрезвычайно слаб (Jacobsson и Wetzel, 2001). Несмотря на то что на момент написания книги он еще не взломан, его сходство с шифром A5/1, чей провал угрожает безопасности всего GSM-трафика, наводит на грустные мысли (Biryukov и др., 2000). Многим (в том числе и авторам) кажется удивительным тот факт, что в игре «кошки-мышки» между криптографами и криптоаналитиками так часто побеждают последние.
Еще одна проблема безопасности, связанная с Bluetooth, состоит в том, что система идентифицирует только устройства, а не пользователей. Это приводит к тому, что вор, укравший устройство Bluetooth, получит доступ к финансовым и другим счетам жертвы. Тем не менее система безопасности в Bluetooth реализована и на верхних уровнях, поэтому даже в случае взлома защиты на канальном уровне некоторые шансы еще остаются, особенно если приложение для выполнения транзакции требует ввода PIN-кода вручную с помощью какой-нибудь разновидности клавиатуры.
8.7. Протоколы аутентификации
Аутентификация (или идентификация) — это метод, с помощью которого процесс удостоверяется в том, что его собеседник является именно тем, за кого он себя выдает. Проверка подлинности удаленного процесса при активных злонамеренных попытках проникновения представляет собой удивительно сложную задачу и требует сложных протоколов, основанных на криптографии. В данном разделе мы познакомимся с несколькими протоколами аутентификации, применяемыми в незащищенных компьютерных сетях.
Следует отметить, что понятия аутентификации и авторизации иногда путают. Аутентификация связана с вопросом подлинности вашего собеседника. Авторизация имеет дело с разрешениями. Например, клиентский процесс обращается к файловому серверу и говорит: «Я процесс Скотта, и я хочу удалить файл cookbook.old». Файлсервер должен решить следующие два вопроса.
1. Действительно ли это процесс Скотта (аутентификация)?
2. Имеет ли Скотт право удалять файл cookbook.old (авторизация)?
Только после того, как на оба вопроса будут получены недвусмысленные утвердительные ответы, может быть выполнено запрашиваемое действие. Ключевым является первый вопрос. После того как сервер узнает, с кем он разговаривает, для проверки прав доступа потребуется лишь просмотреть содержимое локальных таблиц или баз данных. По этой причине в данном разделе мы уделим особое внимание вопросу аутентификации.
Общая схема, используемая практически всеми протоколами аутентификации, состоит из следующих действий. Алиса желает установить защищенное соединение с Бобом или считающимся надежным Центром распространения ключей (KDC — Key Distribution Center). Затем в разных направлениях посылаются еще несколько сообщений. По мере их передачи хулиганка по имени Труди может перехватить, изменить и снова воспроизвести эти сообщения, чтобы обмануть Алису и Боба или просто сорвать сделку.
Тем не менее, когда протокол завершит свою работу, Алиса должна быть уверена, что разговаривает с Бобом, а Боб — что разговаривает с Алисой. Кроме того, в большинстве протоколов собеседники также установят секретный ключ сеанса (session key), которым будут пользоваться для последующего обмена информацией. На практике весь обмен данными шифруется с помощью одного из алгоритмов с секретным ключом (AES или тройной DES), так как их производительность намного выше производительности алгоритмов с открытым ключом. Тем не менее алгоритмы с открытым ключом широко применяются в протоколах аутентификации и для определения ключа сеанса.
Цель использования нового, случайно выбираемого ключа сеанса для каждого нового соединения состоит в минимизации трафика, посылаемого с использованием закрытых и открытых ключей пользователя, уменьшении количества шифрованного текста, который может достаться злоумышленнику, а также минимизации вреда, причиняемого в случае, если процесс даст сбой и дамп ядра попадет в чужие руки. Поэтому после установления соединения в процессе должен храниться только один временный ключ сеанса. Все постоянные ключи должны быть тщательно стерты.
8.7.1. Аутентификация, основанная на общем секретном ключе
В нашем первом протоколе аутентификации мы предположим, что у Алисы и Боба есть общий секретный ключ KAB. Об этом секретном ключе можно договориться при личной встрече или по телефону, но в любом случае не по (незащищенной) сети.
В основе этого протокола лежит принцип, применяемый во многих протоколах аутентификации: одна сторона посылает другой случайное число, которое другая сторона преобразует особым образом и возвращает результат. Такие протоколы называются протоколами типа оклик-отзыв (challenge-response). В этом и последующих протоколах аутентификации будут использоваться следующие условные обозначения:
