Секреты и ложь. Безопасность данных в цифровом мире

1.3.5. Сфальсифицировать поля «ответить» или «от кого» подлинного сообщения (ИЛИ)

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

1.3.6. Прочитать послание после того, как оно будет расшифровано получателем

1.3.6.1. Скопировать сообщение с жесткого диска или из виртуальной памяти компьютера (ИЛИ)

1.3.6.2. Копировать сообщение с резервной копии, хранящейся на магнитной ленте (ИЛИ)

1.3.6.3. Контроль сетевого трафика (ИЛИ)

1.3.6.4. Использовать средства приема электромагнитного излучения для считывания сообщения, выведенного на экран (ИЛИ)

1.3.6.5. Получение сообщения с устройств вывода

1.3.6.5.1. Получить текст с бумажной распечатки

1.3.6.5.2. Получить текст с фоточувствительного барабана принтера

1.3.6.5.3. Подслушать передачу информации с компьютера на принтер

1.3.6.5.4. Получить информацию из памяти принтера.

1.4. Добыть секретный ключ получателя

1.4.1. Разложение на модули RSA или вычисление дискретного логарифма для схемы Эль-Гамаля (ИЛИ)

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

1.4.2. Получить секретный ключ получателя из его связки ключей (ИЛИ)

1.4.2.1. Добыть зашифрованную связку ключей получателя (И)

1.4.2.1.1. Скопировать его с жесткого диска пользователя (ИЛИ)

1.4.2.1.2. Скопировать его резервную копию (ИЛИ)

1.4.2.1.3. Контроль сетевого трафика (ИЛИ)

1.4.2.1.4. Внедрить вирус или закладку для раскрытия копии зашифрованного секретного ключа

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

1.4.2.2. Расшифровать секретный ключ

1.4.2.2.1. Взломать зашифрованное с помощью алгоритма IDEA сообщение (ИЛИ)

1.4.2.2.1.1. Взломать IDEA с помощью атаки «в лоб» (ИЛИ)

IDEA использует 128-битовые ключи. Поэтому успешная атака «в лоб» нереальна.

1.4.2.2.1.2. Криптоанализ IDEA

Эффективные методы криптоанализа IDEA не известны

1.4.2.2.2. Узнать пароль

1.4.2.2.2.1. Контроль клавиатуры в момент введения пользователем пароля (ИЛИ)

1.4.2.2.2.2. Убедить пользователя открыть пароль (ИЛИ)

1.4.2.2.2.3. Использовать программу, запоминающую нажатия на клавиши, когда пользователь вводит пароль (ИЛИ)

1.4.2.2.2.4. Угадать пароль

1.4.3. Контроль памяти получателя (ИЛИ)

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

1.4.4. Внедрить вирус для раскрытия секретного ключа

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

1.4.5. Создать для получателя незащищенную пару ключей (открытый – закрытый)

При рассмотрении схемы сразу становится очевидным, что взлом RSA и IDEA алгоритмов шифровки – не самое выгодное нападение на PGP. Существует множество способов считывания посланий, зашифрованных PGP. Вы можете подсмотреть изображение на экране, когда получатель расшифровывает и читает послание (используя троянского коня вроде Back Orifice, приемник TEMPEST или скрытую камеру), завладеть секретным ключом, после того как пользователь введет пароль (с помощью Back Orifice или специального компьютерного вируса), получить пароль (с помощью программы, запоминающей ввод с клавиатуры, приемника TEMPEST или Back Orifice) или попытаться овладеть паролем «в лоб» (это будет в меньшей степени энтропией, чем генерировать 128-битовые ключи IDEA). Выбор алгоритма и длина ключа – наименее существенные вещи из тех, которые могут сокрушить всю систему безопасности PGP.

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

Дерево атак для чтения сообщения электронной почты

Задача: прочитать определенное сообщение электронной почты, посланное с одного компьютера, использующего Windows 98, на другой.

1. Убедить отправителя показать письмо (ИЛИ)

1.1. Подкуп

1.2. Шантаж

1.3. Принуждение с помощью угроз

1.4. Обман

2. Прочитать сообщение, когда оно вводится в компьютер (ИЛИ)

2.1. Улавливать электромагнитное излучение экрана компьютера (Мера противодействия: использовать TEMPEST)

2.2. Визуально контролировать экран компьютера

2.3. Контролировать видеопамять

2.4. Контролировать шнур для подключения дисплея

3. Прочитать сообщение, хранящееся на диске отправителя (контрмера: использовать SFS для шифрования данных на жестких дисках) (И)

3.1. Получить доступ к жесткому диску (контрмера: установить замки на все двери и окна)

3.2. Считать файл, защищенный SFS

4. Прочитать сообщение, когда оно пересылается от отправителя к получателю (контрмера: использовать PGP) (И)

4.1. Перехватить сообщение во время пересылки (контрмера: использовать программу шифрования транспортного уровня)

4.2. Прочитать сообщение, зашифрованное PGP

5. Убедить получателя показать сообщение (ИЛИ)

5.1. Подкуп

5.2. Шантаж

5.3. Принуждение с помощью угроз

5.4. Обман

6. Подсмотреть сообщение во время его прочтения (ИЛИ)

6.1. Принимать электромагнитное излучение экрана монитора (контрмера: использовать TEMPEST)

6.2. Следить за изображением на экране

7. Прочитать сообщение, хранящееся на диске получателя (ИЛИ)

7.1. Получить сообщение с жесткого диска после его расшифровки (контрмера: использовать SFS для шифровки данных на диске) (И)

7.1.1. Получить доступ к жесткому диску (контрмера: установить замки на двери и окна)

7.1.2. Считать файл, зашифрованный SFS

7.2. Получить резервную копию расшифрованного сообщения

8. Получить бумажную распечатку сообщения (контрмера: хранить бумажные копии в сейфе) (И)

8.1. Получить доступ к сейфу

8.2. Открыть сейф

9. Украсть компьютер отправителя и попытаться извлечь из него сообщение

10. Украсть компьютер получателя и попытаться извлечь из него сообщение

Создание и использование деревьев атак

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

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

Создав однажды дерево атак и проанализировав значения всех его узлов (эти значения будут меняться со временем, поскольку вы будете уточнять сведения о возможных нападениях), вы сможете использовать эту схему для принятия решений по вопросам безопасности. Значения корневого узла позволяют оценить степень уязвимости цели. Вы сможете определить, уязвима ли система для отдельных видов атак, например распределенной атаки, приводящей к отказу в обслуживании. Вы можете использовать дерево атак для того, чтобы очертить круг допущений, исходя из которых решаются вопросы безопасности системы: например, средства безопасности PGP созданы в предположении, что никто не сможет подкупить программиста[56]. Вы можете оценить последствия изменений в системе или значение вновь обнаруженного слабого места; вычислить новые значения узлов на основе полученной информации и определить, как это влияет на узел, содержащий цель. И наконец, вы можете сравнивать и классифицировать виды нападений по затратам, вероятности успеха и т. д.

Такого рода исследования приводят к удивительному выводу о том, что кажущиеся уязвимыми места на самом деле таковыми не являются. Те, кто используют PGP, обычно беспокоятся о длине ключа: что следует предпочесть – 1024-битовый RSA или 2048-битовый? Схема нападения показывает, что длина ключа RSA не имеет значения. Существует множество других видов нападений, намного более простых, чем взлом открытого ключа: внедрение программы, запоминающей ввод с клавиатуры, изменение программы на жестком диске жертвы. Увеличение длины ключа с 1024 до 2048 бит нисколько не усложняет дерево атак; гораздо более опасны нападения, направленные на преодоление мер компьютерной безопасности. Деревья атак позволяют оценить перспективы системы в целом.

Дерево атак обладает еще одним ценным свойством: содержащиеся в нем сведения остаются актуальны в дальнейшем. Однажды построив дерево атак PGP, вы сумеете использовать его в любой другой ситуации, когда речь идет о PGP. Эта схема может быть включена в другую, более обширную. Например, на рис. 21.2 представлена схема, целью которой является прочтение определенного письма, посланного с одного компьютера, использующего Windows 98, на другой. Если вы посмотрите на терминальные узлы дерева, то заметите, что целые деревья атак на PGP и на сейф вставлены в этот план нападения.

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

Глава 22

Испытание и верификация программных продуктов

Мы уже неоднократно затрагивали тему испытания средств безопасности. В главе 7 обсуждался выбор криптографических примитивов. Там же была выдвинута идея, что наилучшим способом проверки надежности криптографии является открытый криптоанализ, проводимый в течение многих лет. В главе 8 мы рассматривали различные стандарты безопасности компьютера – Оранжевую Книгу и Общие Критерии, а также проверку их соответствия этим стандартам. В главе 13 обсуждались надежность программного обеспечения и то, как ошибки оборачиваются уязвимостью. Испытания позволяют проверить работоспособность системы безопасности: одно дело смоделировать угрозы, разработать политику безопасности и применить меры противодействия, но будут ли эти меры работать на самом деле? Несомненно, вы уже приобрели солидный брандмауэр или антивирусную программу, или VPN (виртуальную частную сеть), или систему защиты от мошенничества для платного телевидения, или систему биометрического контроля, или основанную на использовании смарт-карт систему расчетов, или программу шифрования электронной почты и т. п., но достаточно ли прочна их защита? Большинство программных продуктов ненадежны, и причина кроется в недостаточности тестирования.

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

На протяжении всей книги я подчеркивал, насколько трудно обеспечить действительную безопасность. Одно дело – спроектировать систему обороны, другое – должным образом реализовать ее, третье – исключить влияние ятрогенных эффектов,[57] но совсем другое – провести испытания и убедиться в том, что все сделано правильно.

Раньше я был президентом Counterpane Systems, консультационной компании по вопросам шифрования и безопасности. Большую часть времени я тратил на оценку продуктов компьютерной безопасности. Как правило, меня приглашали, когда продукт был почти готов, чтобы проверить, действительно ли он безопасен. Более разумные заказчики обращались ко мне на раннем этапе разработок, чтобы удостовериться в безопасности разработки. Иногда я оценивал готовый продукт, основанный на решениях, которые были проанализированы мною ранее. Эта глава – квинтэссенция того опыта.

Неудачи испытаний

Перечитайте главу 13, посвященную надежности программного обеспечения, найдите словосочетание «компьютер Сатаны» и вспомните, как продукты безопасности должны работать при появлении противника. Теперь подумайте, как и зачем проводят функциональное испытание.

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

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

Функциональное тестирование хорошо для обнаружения случайных погрешностей, которые приводят к тому, что компьютерная программа ведет себя непредсказуемо, в основном перестает работать. Недостатки системы защиты не проявляются столь эффектно; обычно они невидимы, пока не станут известны злоумышленникам. Испытание средств безопасности – это не беспорядочное использование программного обеспечения и наблюдение за его работой. Это сознательное выявление проблем, создающих угрозу безопасности. Функциональное испытание никогда не выявило бы, что нападающий может создать веб-страницу, которая будет запускать некоторую программу на компьютере пользователя, просматривающего эту страницу с помощью Microsoft Internet Explorer 3.0 или 3.0.1. Как раз этого и не удастся обнаружить при бета-тестировании.

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

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

К сожалению, слишком многие программные продукты, даже продукты безопасности, имеют те же проблемы.

Даже достаточно полный анализ безопасности не сильно поможет. Я обнаруживал от 5 до 15 ошибок на тысячу строк кода, и это – в конечном продукте, после всех испытаний. Мы все знаем, какое огромное количество ошибок можно найти в операционной системе Microsoft, даже после сотен человеко-часов испытаний. Точно так же дни, недели и даже месяцы исследования безопасности не приведут ни к чему.

Другая сторона проблемы состоит в том, что полноценное исследование безопасности может быть проведено только опытными специалистами. Вспомним, что о продукте безопасности в лучшем случае можно будет сказать: «Я не могу взломать его, и другие умельцы также не смогут сделать этого». Только опытные специалисты в области безопасности в состоянии действительно обнаружить недостатки системы, поэтому качество любого испытания зависит от профессионализма исследователей.

Иногда недостатки защиты обнаруживаются случайно. Хороший пример – изъян в защите пароля Microsoft Bob: она позволяет повторно вводить пароль и после трех неправильных попыток. Хотя это – исключение. Вероятность случайного попадания на какую-либо ошибку в системе безопасности очень низка, иногда она стремится к нулю. Более эффективен целенаправленный поиск.

К сожалению, еще не создана такая полезная вещь, как всеобъемлющий справочник по вопросам безопасности. Те из нас, кто работают в этой области, зачастую создавали свои собственные справочники, содержащие перечни возможных нападений и уязвимых мест, которые встречаются в коммерческих продуктах, описаны в научной литературе или придуманы нами самими. Подобные перечни огромны – пару лет назад я составил такой список из 759 нападений, но и он не был исчерпывающим.

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

Обратите внимание, я не говорю «очень трудно» или «невероятно трудно». Я сказал «невозможно».

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

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

Что делать разработчику системы? В идеале – он должен перестать полагаться на своих собственных проектировщиков и бета-тестирование. Ему следует нанять независимых экспертов в области безопасности, которые проведут испытания. На них придется истратить значительные средства; скорее всего, это потребует стольких же усилий, сколько и сама разработка и реализация.

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

Производители же намерены поступать, как всегда, то есть продавать ненадежные продукты, и лишь затем устранять изъяны в защите, которые будут обнаружены и преданы гласности. Они будут делать из ряда вон выходящие заявления и надеяться, что никто не призовет их к ответу. Они будут проводить конкурсы по взлому их систем и устраивать другие рекламные трюки. Они станут выпускать новые версии программ так быстро, что к тому времени, когда кто-нибудь потрудится закончить анализ безопасности, они смогут сказать: «Да, но это было в гораздо более ранней версии». Однако продукты все равно останутся ненадежны.

Выявление недостатков защиты продуктов при использовании

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

Так или иначе, кто-нибудь да находит уязвимые места в системе безопасности. И что дальше?

Существует несколько вариантов его дальнейших действий. Он может сохранять все в тайне и никому не сообщать об этом или поделиться только со своими друзьями. Он может уведомить производителя. Или оповестить своих собственных клиентов, постаравшись не раскрывать ошибку, чтобы только его продукты могли защищать пользователя (мне встречались компании, поступавшие таким образом). Или предать гласности свою находку. (Конечно, он всегда может использовать в преступных целях свои знания об уязвимых местах, но давайте предполагать, что он – честный человек.) Практика предания гласности, известная как полное раскрытие (full disclosure), стала популярна в последние годы. И остается предметом горячих споров.

Но сначала немного истории.

В 1988 году, после того как использование червя Морриса продемонстрировало, насколько легко провести нападение через Интернет, Агентство перспективных исследовательских программ (Defense Advanced Research Projects Agency, DARPA) начало финансирование группы, которая, как предполагалось, будет координировать ответные меры безопасности, повышать уровень осведомленности в вопросах безопасности и вообще делать много полезных вещей. Она называется Группой компьютерной «скорой помощи» (Computer Emergency Response Team, CERT), ее центральное подразделение находится в Университете Карнеги-Меллона в Питсбурге.

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

Это хорошо выглядит в теории, но плохо работает на практике. Были три главные претензии к этой системе. Во-первых, CERT медленно проверяла наличие уязвимых мест, поскольку получала множество сообщений и не успевала справляться с работой. Во-вторых, производители не торопились исправлять ошибки, о которых им сообщала CERT, поскольку она не публиковала никакие сведения, прежде чем ошибки были исправлены, и не было необходимости в спешке. И в-третьих, CERT не сразу публиковала сообщения даже после того, как все исправления были сделаны.

Практика полного раскрытия возникла из-за общего разочарования в описанной процедуре. Конференции в Интернете, такие как Bugtraq и NT Bugtraq (организованные в 1993 и в 1997 годах соответственно), превратились в форум для людей, считавших, что производителей извещать бесполезно, а единственный способ повысить безопасность – предавать гласности случаи, когда ее средства оказываются ненадежны. Это была реакция протеста на «башню из слоновой кости», воздвигнутую учеными, хранившими в тайне свои познания. Как писал один хакер: «Теперь обсуждение проблем безопасности не будет ограничено закрытыми списками рассылки так называемых специалистов по вопросам безопасности, и подробности можно будет найти не только в пространных, перегруженных деталями академических статьях. Напротив, информация станет общедоступной, и каждый сможет использовать ее по своему усмотрению».

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