by Bruce Schneier
Cryptography Consultant Counterpane Internet Security, Inc.
e-mail: schneier@counterpane.com
Copyright Counterpane Internet Security, Inc., 2001
Перевод статьи – Василий Кондрашов
Журнальные статьи любят описывать криптографические продукты в терминах алгоритмов и длины ключей. Алгоритмы благозвучны: их описание может быть немногословным и их легко сравнивать друг с другом. "128-битные ключи означают высокую степень защиты". "Тройной DES означает высокую степень защиты". "40-битные ключи означают низкий уровень защиты". "2048-битный RSA лучше 1024-битного RSA".
Но в действительности всё не так просто. Более длинные ключи не всегда означают лучшую защиту. Сравним криптографический алгоритм с замком на Вашей входной двери. Большинство дверных замков имеют четыре металлических штифта, каждый из которых может находиться в одном из десяти положений. Ключ устанавливает штифты в особой комбинации. Если ключ установит их все правильно, замок откроется. Таким образом, может быть только 10000 различных ключей и взломщик, готовый испробовать все 10000, обязательно попадёт к Вам в дом. Но улучшенный замок с десятью штифтами, дающий 10 миллиардов возможных ключей, возможно, не сделает Ваше жилище безопаснее. Взломщики не испытывают каждый возможный ключ (атака "в лоб"); большинство даже не настолько хитры, чтобы взломать замок (криптографическая атака на алгоритм). Они разбивают окна, выбивают двери, переодеваются полицейскими или отнимают ключи под дулом пистолета. Одна шайка похитителей предметов искусства обходила домашние системы безопасности, пропиливая стены дома цепной пилой. Лучшие замки не спасут от таких атак.
Сильная криптография значит очень много, когда всё сделано верно, но панацеей она не является. Сосредоточение на криптографических алгоритмах, сопряжённое с игнорированием остальных аспектов безопасности похоже на защиту дома не постройкой забора вокруг него, а установкой огромного столба в надежде, что противник налетит прямо на него. Сообразительный нападающий просто обойдёт алгоритмы.
Counterpane (имеется ввиду Counterpane Internet Security, Inc.) потратила много лет на разработку, анализ и взлом криптографических систем. Пока мы занимаемся исследованием опубликованных алгоритмов и протоколов, большая часть нашей работы состоит в проверке реальных продуктов. Мы разрабатывали и анализировали системы, которые защищают секреты, обеспечивают конфиденциальность и правомочность, способствуют коммерции. Мы работали с программным обеспечением, автономным аппаратным обеспечением и всем, что стоит между ними. Мы взламывали некоторые алгоритмы, но почти всегда находились способы атаки, позволяющие полностью обойти сами алгоритмы. Мы не пытаемся пробовать каждый возможный ключ или даже искать недостатки в алгоритмах. Мы используем ошибки в проектировании, реализации и установке. Иногда мы изобретаем новый способ взлома системы, но, по большей части, мы используем те же старые ошибки, которые разработчики повторяют снова и снова.
Криптографическая система может быть сильна лишь настолько, насколько таковыми являются алгоритмы шифрования, алгоритмы цифровой подписи, односторонние хэш-функции и коды идентификации сообщений, на которые она опирается. Взломайте что-нибудь одно и вы взломаете систему. И как можно построить слабую структуру из крепких материалов, так и возможно построить слабую криптографическую систему из надежных алгоритмов и протоколов.
Мы часто находим системы, которые "аннулируют гарантию" своей криптографии неправильным использованием последней: не проверяя размеры значений, повторно используя случайные параметры, которые повторно использовать никогда нельзя, и т.д. Алгоритмы шифрования не всегда обеспечивают целостность данных. Протоколы обмена ключами не гарантируют получение обеими сторонами одного и того же ключа. В недавнем исследовательском проекте мы нашли, что некоторые (не все) системы, использующие связанные ключи могут быть взломаны, даже если каждый отдельный ключ безопасен. Безопасность – нечто намного большее, чем простое использование алгоритма и ожидание получить работоспособную систему. Даже хорошие инженеры, известные компании и большие усилия не гарантируют устойчивой реализации; наша работа над алгоритмом шифрования в цифровой сотовой связи в США подтвердила это.
Генераторы случайных чисел – ещё одно место, в котором часто ломаются криптографические системы. Хорошие генераторы случайных чисел сложны в разработке, так как их надёжность часто зависит от особенностей аппаратного и программного обеспечения. Многие из проверенных нами продуктов используют плохие. Криптография может быть сильной, но если генератор случайных чисел выдаёт слабые ключи, то систему взломать гораздо проще. Другие продукты используют надёжные генераторы случайных чисел, но не используют достаточно случайности для обеспечения надёжной криптографии.
Недавно Counterpane опубликовала новый класс атак на генераторы случайных чисел (http://www.counterpane.com/pseudorandom_number.html), основанный на нашей работе над коммерческими моделями. Одна из самых неожиданных находок была в том, что определённые генераторы случайных чисел могут быть надёжными при использовании с одной целью, но ненадёжными для другой; обобщение анализа надёжности опасно.
В результатах другого исследования мы рассматривали взаимодействие между двумя, поодиночке надёжными криптографическими протоколами. Мы показывали, как по заданному надёжному протоколу построить другой надёжный протокол, который взломает первый при использовании с теми же ключами на том же устройстве.
Многие системы рушились из-за ошибок в реализации. Некоторые системы не убеждаются в уничтожении открытого текста после шифрования. Другие системы используют временные файлы, чтобы защититься от потерь данных, связанных с крахом системы, или виртуальную память, чтобы расширить объём доступной памяти; эти возможности могут случайно оставить открытый текст валяющимся на жёстком диске. В особых случаях операционная система может оставить ключи на жёстком диске. В одном из рассмотренных продуктов использовалось специальное окно для ввода пароля. Пароль оставался в памяти окна даже после его закрытия. И не важно, насколько хороша была криптография продукта, – он был взломан через интерфейс пользователя.
Другие системы терпели поражение от менее явных проблем. Иногда одни и те же данные шифровались двумя разными ключами, одним сильным и одним слабым. Другие системы использовали главные ключи и, затем, одноразовые сеансовые ключи. Мы взломали их с помощью частичной информации о разных ключах. Мы также встречали системы с неадекватными механизмами защиты главных ключей, ошибочно полагающихся на надёжность сеансовых ключей. Жизненно важно перекрыть все возможные пути изучения ключа, а не только самые очевидные.
Системы электронной коммерции часто идут на компромисс в вопросах реализации с целью обеспечения простоты использования. Здесь мы находили скрытые слабые места, появившиеся из-за того, что разработчики не продумывали тщательно влияние этих компромиссов на безопасность. Наверное, проводить согласование счетов раз в день проще, но какой вред может нанести злоумышленник за несколько часов? Возможно ли переполнение механизмов контроля, с целью скрыть личность злоумышленника? Некоторые системы хранят скомпрометированные ключи в рабочих списках (hotlists) – атака на такие списки может быть очень плодотворной. Другие системы могут быть взломаны посредством replay-атак: повторным использованием старых сообщений или их частей с целью обмана различных механизмов.
Системы, которые допускают восстановление ключей в экстренной ситуации, предоставляют ещё одно направление для атаки. Хорошие криптографические системы разрабатываются с таким расчётом, чтобы время жизни ключа было как можно короче. Восстановление ключей зачастую сводит на нет усилия по повышению надёжности, заставляя ключ существовать дольше, чем требуется. Более того, базы данных восстановления ключей являются источниками уязвимостей сами по себе и должны разрабатываться и реализовываться с учётом требований безопасности. В одном из рассмотренных продуктов дефект базы данных восстановления ключей давал преступникам возможность для мошенничества с возможностью свалить всё на законных пользователей.
Многие системы взламываются из-за того, что полагаются на пароли, созданные пользователями. Предоставленные сами себе, люди не склонны к выбору надёжных паролей. Если заставить их использовать надёжные пароли, то они будут их забывать. Когда пароль становится ключом, то, обычно, проще и быстрее угадать пароль, нежели подобрать ключ – мы встречали доскональные системы, терпевшие на этом пути неудачу. Некоторые интерфейсы пользователя только усугубляют проблему, ограничивая длину пароля восемью символами, преобразовывая всё к нижнему регистру и т.д. Даже идентификационная фраза (многословный вариант пароля) может оказаться ненадёжной: поиск среди фраз из 40 символов обычно гораздо проще поиска среди произвольных ключей длиной 64 бита. Нам также встречались системы восстановления ключей, которые дискредитировали надёжные сеансовые ключи использованием слабых паролей для восстановления ключа.
Некоторые системы, в особенности, коммерческие, в вопросах безопасности полагаются на защищённое от несанкционированного доступа аппаратное обеспечение – карточки с микропроцессором (smart card), электронные бумажники, защитные заглушки и т.д. Эти системы могут предполагать, что общедоступные терминальные устройства никогда не попадут не в те руки или "не те руки" не будут обладать достаточными знаниями или оборудованием для атаки на аппаратное обеспечение. Хотя аппаратное обеспечение безопасности и является важным компонентом многих надёжных систем, мы не доверяем системам, надёжность которых базируется исключительно на предположениях о защищённости от несанкционированного доступа. Нам редко встречались работоспособные системы защиты от несанкционированного доступа, а инструменты преодоления такой защиты совершенствуются постоянно. Когда мы разрабатываем системы, использующие элементы защиты от несанкционированного доступа, мы обязательно встраиваем дополнительные механизмы обеспечения безопасности на случай, если система защиты от несанкционированного доступа не сработает.
Хронометрические атаки (timing attack) наделали много шума в прессе в 1995 году: закрытые ключи RSA могут быть восстановлены измерением относительных интервалов времени, затраченных на произведение криптографических операций. Эти атаки были успешно применены к карточкам с микропроцессорами и другим средствам надёжной идентификации, а также к серверам электронной коммерции в Сети. Counterpane, в числе других, обобщила эти методы, включая атаки на системы путём измерения уровня потребления энергии, излучения и других побочных каналов и применила их против многих алгоритмов, как с открытым ключом, так и симметричных, в "надёжных" системах идентификации. Однако мы нашли средства идентификации, вытянуть из которых секретный ключ, наблюдая за побочными каналами, нам не удалось. Связанное с этим направление исследований рассматривало анализ ошибок: преднамеренно спровоцированные ошибки криптографического процессора с целью определения секретных ключей. Эффект от таких атак может быть огромным.
Многие из более интересных наших атак были направлены на модели доверия, лежащие в основе системы: кому или чему доверяет системы, каким образом и до какой степени. Простые системы, такие как программы шифрования содержимого жёстких дисков или продукты для обеспечения секретности телефонных переговоров, обладают простыми моделями доверия. Сложные системы, такие как системы электронной коммерции и многопользовательские системы безопасности электронной почты, имеют сложные (и тонкие) модели доверия. Программа для работы с электронной почтой может использовать невзламываемое шифрование, но пока ключи не подтверждены достоверным источником (или пока такое подтверждение не может быть проверено), система остаётся уязвимой. Некоторые коммерческие системы могут быть взломаны путём сговора продавца и покупателя, или двух разных покупателей. Другие системы делают неявные предположения о инфраструктуре обеспечения безопасности, не заботясь о проверке подлинности этих предположений. Если модель доверия не документирована, инженер может неосознанно изменить её на стадии разработки продукта и, тем самым, скомпрометировать систему обеспечения безопасности.
Многие программные системы делают неверные предположения относительно компьютеров, на которых они запущены, – они предполагают, что компьютер надёжен. Такие программы часто могут быть взломаны "троянскими конями" - программами, которые подсматривают пароли, читают открытые сообщения или обходят систему безопасности иным путём. Системы, работающие через вычислительную сеть, должны предусматривать дефекты систем безопасности, вызываемые сетевыми протоколами. Компьютеры, подключённые к Internet также уязвимы. Криптография может оказаться неуместной, если её можно обойти, воспользовавшись ненадёжностью сети. И не существует программного обеспечения, устойчивого к декомпиляции.
Часто система разрабатывается с расчётом на одну модель доверия, а реализуется с другой. Решения, принятые в процессе разработки могут быть полностью проигнорированы к моменту продажи конечному потребителю. Система, надёжная в случае использования надёжными операторами на компьютерах, находящихся под полным контролем компании, использующей систему, может оказаться ненадёжной, если операторы – временные работники с предельно низким жалованьем, а компьютеры не заслуживают доверия. Хорошие модели доверия работают даже тогда, когда одно из предположений о доверии перестаёт быть верным.
Даже если система надёжна при надлежащем обращении, пользователи могут случайно нарушить систему безопасности, особенно, если система спроектирована не очень хорошо. Классический пример – пользователь, дающий свой пароль другим сотрудникам, чтобы они могли решать какие-то вопросы, когда его самого нет на месте. Пользователи могут не докладывать о пропаже карточки доступа, если она потерялась. Они могут невнимательно проверять имя на электронном сертификате. Они могут повторно использовать свои надёжные пароли на других, ненадёжных системах. Они могут не изменить настройки безопасности программного обеспечения, установленные по умолчанию на низкий уровень безопасности. Хорошо спроектированная система не сможет решить всех этих социальных проблем, но поможет избежать многих из них.
Сильные системы проектируются с таким расчётом, чтобы не дать небольшим проблемам с системой безопасности стать большими. Восстановление ключа к одному файлу не должно давать злоумышленнику возможности читать все файла на жёстком диске. Хакер, разобравший смарт-карту не должен иметь возможности найти пути к взлому других смарт-карт в системе. В многопользовательской системе знание секретов одного не должно компрометировать других.
Многие системы по умолчанию находятся в небезопасном режиме. Если функция системы безопасности не работает, большинство людей просто отключают её и занимаются своими делами. Если система проверки кредитных карточек в реальном времени отключена, придётся воспользоваться менее надёжной "бумажной" системой. Аналогично, порой бывает возможно устроить атаку отката версии (version rollback attack) после того, как она была модернизирована для усовершенствования системы безопасности: требование обратной совместимости позволяет злоумышленнику вынудить использовать старый, менее надёжный протокол.
Другие системы не имеют возможности "на ходу" восстановиться после аварии. Если система безопасности взломана, то пути её исправить нет. Для систем электронной торговли, порой насчитывающих миллионы пользователей, это может оказаться чрезвычайно разрушительным. Такие системы должны быть готовы ответить на атаку и модернизировать систему безопасности, не выключая всю систему. Фраза "и компания сворачивается" - не то, что Вы хотели бы поместить в бизнес-план. Хороший проект системы учитывает действия на случай обнаружения атаки и вырабатывает пути локализации повреждения и восстановления после атаки.
Порой продукты имеют изъяны в криптографической системе. Некоторые полагаются на собственные алгоритмы шифрования. Они неизменно оказываются очень слабыми. Counterpane имеет определённые достижения в области взлома известных алгоритмов шифрования, но среди "самодельных" таких достижений гораздо больше. Секретность алгоритма не является большим препятствием для анализа – в любом случае, потребуется лишь несколько дней для инженерного анализа криптографического алгоритма из исполняемого кода. Одна из проанализированных нами систем, стандарт электронной почты S/MIME 2, использовала относительно устойчивую конструкцию, но реализованную со слабым криптографическим алгоритмом. Система шифрования DVD выбрала слабый алгоритм и сделала его ещё слабее.
Мы встречали много других криптографических ошибок: реализации, повторяющие "уникальные" случайные величины, алгоритмы цифровой подписи, недостаточно тщательно проверяющие параметры, хэш-функции, изменённые так, что теряются самые важные их свойства. Мы встречали протоколы, которые использовались не так, как это было предусмотрено разработчиками и протоколы, "оптимизированные", по-видимому, тривиальными способами, что полностью лишило их надёжности.
Большинство криптографических систем зависят от предупреждения как от единственного способа защиты: криптография спасает людей от мошенничества, лжи, злоупотреблений и т.д. Защита никогда не должна быть ограниченной. Сильная система также пытается обнаруживать факты злоупотреблений и ограничивать эффект любых атак. Один из наших фундаментальных принципов проектирования состоит в предположении, что рано или поздно любая система будет успешно атакована, возможно, совершенно неожиданным способом и с совершенно неожиданными результатами. Важно иметь возможность обнаружить такую атаку и затем ограничить её, чтобы быть уверенным, что нанесённый ущерб будет минимальным.
Важнее то, что после обнаружения атаки, система нуждается в восстановлении: генерации новой пары ключей, обновлении протокола с запретом использования старого, удаления из системы дискредитированного узла и т.д. К сожалению, многие системы не собирают достаточно данных для предоставления контрольного следа, или не в состоянии защитить эти данные от изменения. Counterpane провела значительную работу по защите журналов контрольной проверки в системах электронной коммерции, по большей части, в ответ на проекты систем, которые могут быть полностью разрушены в результате успешной атаки. Такие системы должны не только обнаруживать атаки, но и давать убедительные улики для суда и присяжных.
Разработчики систем безопасности занимают то, что прусский генерал Карл фон Клаушвиц (Carl von Clausewitz) назвал "позицией в осаде". Хорошая система безопасности должна защищать от любых возможных атак, пусть даже неизвестных на данный момент. Злоумышленники, с другой стороны, должны найти лишь одну ошибку для того, чтобы система была взломана. И они могут мошенничать, сговариваться, дожидаться, пока развитие технологии предоставит им новые инструменты. Они могут атаковать систему способом, о котором разработчик и не подозревал.
Построение надёжной криптографической системы - из разряда того, что сделать плохо легко, а хорошо – очень трудно. К сожалению, большинство людей не видят разницы. В других областях теории вычислительных систем функциональность служит для того, чтобы отличать хорошее от плохого: хороший алгоритм сжатия работает лучше плохого, плохой архиватор выглядит хуже при сравнительном анализе его возможностей. В криптографии – иначе. Только тот факт, что шифрующая программа работает, не означает, что она надёжна. Так случается с большинством продуктов: кто-то читает "Прикладную криптографию", выбирает алгоритм и протокол, удостоверяется в работоспособности и считает, что дело сделано. Но всё не так просто – функциональность не равноценна качеству и непродолжительное тестирование всегда выявляет дефекты системы безопасности. Слишком много продуктов идут на поводу у моды – они используют надёжную криптографию, сами надёжными не являясь.
Оригинал статьи (In English) http://www.counterpane.com/pitfalls.html.