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

пользователь А уехал в отпуск и установил в своем почтовом ящике автоот­ ветчик, который отвечает на каждое входящее письмо сообщением: “Я уехал

вотпуск”. Вы отправляете сообщение пользователю А и получаете точную копию этого ответа. Когда пользователь Б отсылает сообщение пользовате­ лю А, он получает точно такой же ответ, однако на сей раз зашифрованный. В этом случае у вас окажется и открытый и шифрованный текст. Если вам удастся определить ключ, вы сможете расшифровывать все сообщения, ко­ торыми обмениваются пользователи А и Б.

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

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

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

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

вданном случае идет только на пользу.

3.6.3Избранный открытый текст

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

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

Чтобы лучше понять эту проблему, введем понятие различающей ата­ ки. Различающая атака (distinguishing attack) — это любой нетривиальный метод, позволяющий обнаружить различие между идеальным и реальным шифром. Данное понятие охватывает все рассмотренные нами типы атак, а также атаки, которые появятся в будущем. Разумеется, нам также понадо­ бится определить, что следует считать идеальным шифром.

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

3.6.6Атаки, в основе которых лежит парадокс задачи о днях рождения

Такие атаки получили свое название в честь парадокса задачи о днях рождения, суть которого такова: если в комнате находятся 23 человека, ве­ роятность того, что два из них родились в один и тот же день, превышает 50%. Это на удивление высокая вероятность, учитывая то, что в году может быть 365 разных дней рождения.

Итак, что же такое атака, в основе которой лежит парадокс задачи о днях рождения (birthday attack)? Это тип атаки, основанный на том факте, что одинаковые значения, называемые также коллизиями (collisions), появляют­ ся намного быстрее, чем можно было ожидать. Представьте себе систему финансовых транзакций, в которой для обеспечения безопасности каждой транзакции применяется новый 64-битовый ключ аутентификации. (Для про­ стоты будем предполагать, что шифрование не используется.) Существует 264 возможных значения ключа (это больше, чем 18 •1018, т.е. 18 миллиардов

54 Глава 3. Введение в криптографию

миллиардов), поэтому взломать такую систему на первый взгляд довольно сложно, не правда ли? Отнюдь нет! Отследив около 232 транзакций, зло­ умышленник может предположить, что две из них используют один и тот же ключ. Предположим, что первое сообщение, передаваемое в ходе каж­ дой транзакции, всегда одно и то же: “Готовы ли вы принять транзакцию?” Если две транзакции используют один и тот же ключ аутентификации, то­ гда значения MAC первых сообщений этих транзакций будут совпадать, что легко отследит злоумышленник. Зная, что обе транзакции используют один и тот же ключ аутентификации, он сможет вставлять сообщения из более старой транзакции в более новую транзакцию во время выполнения послед­ ней. Поскольку ложные сообщения успешно пройдут аутентификацию, они будут приняты, что является очевидным взломом системы финансовых тран­ закций.

В общем случае, если элемент может принимать N различных значений, ожидать первой коллизии можно после случайного выбора приблизительно y/N элементов. Не вдаваясь в подробности, можно сказать, что значение y/N достаточно близко к истинному. Для парадокса задачи о днях рождения N = 365 и y/N « 19. На самом деле количество людей, при котором ве­ роятность совпадения дней рождения превышает 50%, равно 23, однако для наших целей вполне достаточно и приближения y/N. Для большей наглядно­ сти рассмотрим следующее. Если случайным образом выбрать к элементов из N , они могут образовать к{к— 1)/2 различных пар. Вероятность того, что элементы одной пары совпадут, равна 1/N. Следовательно, вероятность того, что хотя бы два элемента из к совпадут, равна к(к - 1)/2АГ. Если к « y/N, эта вероятность приближается к 50%2.

В большинстве случаев мы будем говорить об n-битовых значениях. По­ скольку п-битовый элемент может иметь 2Пвозможных значения, необходимо извлечь у/2* = 2П/2 элементов множества, чтобы надеяться на возникнове­ ние коллизии. Назовем это оценкой 2"/2 или оценкой парадокса задачи о днях рождения (birthday bound).

3.6.7Двусторонняя атака

Другой разновидностью атак, в основе которых лежит парадокс задачи о днях рождения, являются так называемые двусторонние атаки или атаки “встреча на середине” (meet-in-the-middle attacks). (В совокупности оба типа атак называются атаками на основе коллизий (collision attacks).) Этот тип атак более распространен и более результативен. Вместо того чтобы пассивно

2В действительности это лишь приближенные значения, однако для наших целей их вполне достаточно.

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

Давайте вернемся к предыдущему примеру о системе финансовых тран­ закций, в которой для каждой транзакции используется новый 64-битовый ключ. Используя двустороннюю атаку, злоумышленник может еще более про­ двинуться во взломе системы. Для этого он случайным образом выбирает 232 различных 64-битовых ключа. По каждому из них он подсчитывает зна­ чение MAC для сообщения: “Готовы ли вы принять транзакцию?” Получен­ ное значение MAC вместе с соответствующим ключом помещается в таблицу. Затем злоумышленник прослушивает каждую транзакцию и проверяет, не окажется ли значение MAC первого сообщения этой транзакции в его табли­ це. Если такая транзакция находится, значит, с высокой долей вероятности ее ключом аутентификации является тот самый ключ, который был сгене­ рирован злоумышленником и помещен в таблицу вместе с соответствующим значением MAC. Теперь, когда злоумышленник обладает ключом аутентифи­ кации транзакции, он может вставлять в нее собственные сообщения с лю­ бым нужным ему текстом. (Напомним, что предыдущий тип атаки позволял злоумышленнику вставлять только сообщения, взятые из более старой тран­ закции.)

Сколько транзакций придется прослушать злоумышленнику? Он подсчи­ тал значения MAC для 232 из всех возможных ключей. По этой причине каж­ дый раз, когда система выбирает ключ, он с вероятностью 1 к 232 окажется в таблице злоумышленника, а следовательно, после 232транзакций злоумыш­ ленник может ожидать появление транзакции, использующей ключ из его таблицы. Таким образом, злоумышленнику придется проделать 232 предва­ рительных подсчета и прослушать 232 транзакции. Это намного меньше, чем перебирать все 264 возможных ключа.

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

Двусторонняя атака является более гибкой, чем атака, в основе которой лежит парадокс задачи о днях рождения. Давайте рассмотрим суть двусто­ ронней атаки в более абстрактной форме. Предположим, что элементы обоих множеств могут принимать N возможных значений. Пусть в первом множе­ стве содержится Р элементов, а во втором — Q элементов. Из них можно обра­ зовать PQ различных пар, в которых один элемент будет принадлежать пер­ вому множеству, а другой — второму множеству. Для каждой пары вероят­ ность того, что значения ее элементов совпадут, равна 1/N. Мы можем ожи­

56 Глава 3. Введение в криптографию

дать возникновения коллизии, когда значение PQ/N приближается к еди­ нице. В этом случае наиболее эффективным выбором будет Р « Q « y/N. Как видите, мы вновь получили оценку парадокса задачи о днях рождения. Отметим, что двусторонняя атака обладает определенной гибкостью в отно­ шении выбора Р и Q. Иногда элементы одного множества легче получить, чем элементы второго, поэтому размер множеств может быть и неодинаков. Единственным требованием является соблюдение условия PQ « N. Мы мо­ жем выбрать Р « TV1/3, a Q « N2/3. В приведенном выше примере злоумыш­ ленник может составить таблицу из 240 значений MAC и ожидать первого совпадения уже после 224 прослушанных транзакций.

Проводя теоретический анализ того, насколько легко взломать систему, мы часто принимаем размер обоих множеств равным у/N, поскольку это минимизирует количество шагов, которые должен предпринять злоумыш­ ленник. На практике необходимо анализировать, насколько элементы одного множества труднее получить, чем элементы другого. Проводя двустороннюю атаку в реальной жизни, величины Р и Q следует выбирать таким образом, чтобы удовлетворить условие PQ & N при наименьших возможных затратах.

3.6.8 Другие типы атак

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

3.7Уровень безопасности

Теоретически, приложив достаточно усилий, злоумышленник может взло­ мать любую криптографическую систему. Вопрос заключается в том, сколько работы ему необходимо проделать. Чтобы получить количественную оценку нагрузки на злоумышленника, атаку можно сравнить с поиском, выполняе­ мым путем полного перебора вариантов. Если для осуществления атаки необ­ ходимо проделать 2235 шагов, это эквивалентно полному перебору вариантов для 235-битового значения.

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

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

Любой современной системе вполне достаточно 128-битового уровня без­ опасности. Это означает, что осуществление любой атаки на систему потребу­ ет, как минимум, 2128 шагов. Среднестатистическая криптографическая си­ стема, созданная в наши дни, скорее всего, проработает около 30 лет и долж­ на обеспечивать конфиденциальность данных на протяжении приблизитель­ но еще 20 лет с момента окончания использования системы. Таким образом, нам нужно гарантировать безопасность системы на протяжении следующих 50 лет. Это было бы нелегкой задачей, если бы на помощь не пришел закон Мура, адаптированный к криптографии. Согласно ему для современных си­ стем достаточно 128-битового уровня безопасности [62]. Вообще говоря, нам могло бы хватить 110 или даже 100 бит, однако криптографических алгорит­ мов, рассчитанных на такие ключи, не существует, поэтому мы воспользуемся 128-битовыми ключами.

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

3.8Производительность

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

Прежде всего, безопасность не бывает бесплатной. Если вы хотите обес­ печить безопасность своих систем, готовьтесь хорошо заплатить. Те, кто не

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

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

Для большинства компьютеров системные требования криптографиче­ ских алгоритмов не составляют проблемы. Современные процессоры настоль­ ко быстры, что могут справиться практически с любым потоком данных. На­ пример, шифрование канала передачи данных, обладающего пропускной спо­ собностью 100 Мбит/с, с помощью алгоритма AES отнимает всего лишь 20% процессорного времени старенького процессора Pentium III 1 ГГц. (В реаль­ ной жизни эта величина еще меньше, поскольку добиться скорости передачи данных 100 Мбит/с невозможно из-за особенностей протокола обмена данны­ ми.) Подождав еще пару месяцев, вы сможете купить по той же цене гораздо более мощный процессор, а значит, затраты на повышение производитель­ ности будут равны нулю. Одна компания когда-то жаловалась на высокую стоимость шифрования канала передачи данных с пропускной способностью 1 Гбит/с. Машина, которая обрабатывала эти данные, стоила более полумил­ лиона долларов. Думается, эта компания могла бы позволить себе установить дополнительный процессор или обновить материнскую плату для ускорения обработки криптографии.

Иногда применение криптографии действительно приводит к появлению “узких мест” в производительности системы. Хорошим примером являются Web-серверы, использующие большое число SSL-соединений. Процедура ини­ циализации SSL-соединения предполагает применение шифрования с откры­ тым ключом и требует большого объема вычислительной мощности на сто­ роне сервера. Разумеется, мы могли бы разработать замену протоколу SSL,

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

Недавно мы придумали хороший аргумент для тех, кто не желает по­ ступаться производительностью в пользу безопасности: “У нас уже есть ку­ ча быстрых и небезопасных систем. Зачем нам еще одна?” Это очень верное высказывание. Обеспечение безопасности “наполовину” обходится почти в та­ кую же сумму, как и обеспечение безопасности “целиком”, а вот практической пользы от такой безопасности нет. Мы свято верим, что безопасность нужно либо обеспечивать хорошо, либо не обеспечивать вообще.

3.9Сложность

Не существует сложных систем, которые были бы безопасными.

Правило проектирования 1. Сложность — главный враг безопасности.

Это очень простое правило, тем не менее нам понадобилось немало лет для его полного осознания. Современные IT-разработчики практически не справляются с построением сложных систем. Они что-то придумывают, чтото реализуют и приводят это в рабочее состояние... вот, собственно говоря, и все. Продукты, которые ббльшую часть времени находятся в работоспособ­ ном состоянии, считаются хорошими, и практически никогда не проводятся тесты на попытку их преднамеренного разрушения.

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

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

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

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

Между тем именно это и происходит в наши дни с системами безопасно­ сти. Их невозможно протестировать, так как никто не знает, на что их нужно тестировать. При этом, если в системе безопасности обнаружится хотя бы од­ на ошибка, она сведет на нет назначение всей системы. Таким образом, един­ ственный способ получить безопасную систему — это с самого начала делать ее надежной и безопасной. Это, в свою очередь, требует, чтобы система была простой.

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

Правило проектирования 2. Корректность работы должна быть локаль­ ным свойством.

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

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