Почему не срабатывают криптосхемы: смена парадигмы
Росс Андерсон, University Computer Laboratory, Cambridge
перевод BGS

Аннотация

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

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

Введение

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

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

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

Почему модель угроз неадекватна

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

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

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

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

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

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

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

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

Подтверждение анализа

В последнее время стало ясно (несмотря на туман официальной секретности), что в военном секторе возникают те же проблемы, что были описаны выше. Наиболее серьезное подтверждение произошло на рабочей встрече в Кембридже в апреле 1993 года, когда один из ведущих специалистов Агентства Национальной безопасности (АНБ), выслушав доводы автора по обсуждаемым вопросам, заявил, что:
  • наибольшее количество отказов систем безопасности происходит на уровне реализации;
  • сотрудники АНБ не являются более квалифицированным, чем гражданские специалисты по проблемам безопасности, просто они лучше информированы о конкретных угрозах. В частности существуют работники, чья специализация состоит в сборе информации и изучении угроз;
  • в АНБ проведена классификация профилей угроз для внутреннего использования.


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

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

Необходимость серьезного акцента на контроль качества систем сейчас общепринята в военном секторе. Например, в Военно-воздушных Силах США в информационных системах внедряется японская концепция "тотального управления качеством". Однако наряду с этим, до сих пор сохраняется непреодоленная тенденция придерживаться старого подхода. Многие миллионы вложены в продукты, сертифицированные в соответствии с требованиями TCSEC и ITSEC и инвестирование продолжается. Потребуется много времени пока более прагматический подход, основанный на реалистической оценке угроз и учете организационных и человеческих факторов, станет обычной политикой и повсеместной практикой.

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

Новая парадигма безопасности?

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

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

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

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

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

Новая метафора

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

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


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


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


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

Эти пункты тесно связаны с нашими результатами (и с известным опытом АНБ). Однако, даже беглое сравнение с программой ITSEC показывает, что предстоит пройти долгий путь. Похоже, что никто до сих пор не овладел даже первой стадией процесса инженерии безопасности для коммерческих криптографических систем.

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

Два пути

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

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

Из двух моделей первая является более ограниченной, а вторая обладает меньшей концептуальной целостностью. Эти две модели не являются взаимоисключающими. Формальная верификация в авиации- неплохая вещь до тех пор, пока люди не начинают слишком доверять ей. Основное отличие состоит в системной философии.

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

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

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

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

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

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

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

Выводы

Наша работа также показывает, что покомпонентная сертификация реализованная как в программе ITSEC, так и в программе TCSEC, вряд ли приводит к достижению провозглашенных целей. Этот факт был косвенно признан и в военной сфере ( по крайней мере в США ) и мы бы рекомендовали в последующих версиях данных стандартов уделять больше внимания окружению, в котором используется продукт и, в особенности, системным и человеческим факторам.

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

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