лекции ОИБ / Lekcija_6

Лекция 6

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

Доверенная вычислительная база

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

Поэтому, как поступить? Основная идея заключается в том, чтобы минимизировать количество кода, который должен быть правильным для того, чтобы система была защищена (принцип экономии механизмов, подход защищенной сети (ясные спецификации и итерационное проектирование)). Когда разрабатывается защищенная система, то мы разделяем ее на не доверенную и доверенную части. Последняя определяется, как совокупность программных и технических средств, создаваемая и поддерживаемая для обеспечения защиты средств вычислительной техники или автоматизированных систем от несанкционированного доступа к информации (комплекс средств защиты, КСЗ). Корректность или некорректность не доверенного кода не влияет на правильность системы. КСЗ – это часть, которая должна правильно работать для того, чтобы система оставалась защищенной. КСЗ часто называется доверенной вычислительной базой (trusted computing base, TCB).

Пример: в протоколе XNS, сам протокол, сервис аутентификации – части КСЗ; а клиентские рабочие станции не являются таковыми. Еще один пример, в интерпретаторе Java, интерпретатор, байт-кодовый загрузчик и байт-кодовый корректор (verifier) являются частью КСЗ; кроме этого, реализация языковых пакетов java.io, java.util, java.awt, проектирование языка и проектирование байт-кода. Апплеты Java – не являются частью КСЗ.

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

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

аутентификационных систем. Аутентификационная мышления, а не обязательно доказательство.

можно также определить атаки, против которых КСЗ защищен, поэтому риск приемлем. Указав, что КСЗ делает, и чего он не делает, мы знаем, против каких видов атак мы защищены.

2.Проектирование минимального КСЗ. Используются формальные инструменты (такие, как автоматы ввода/вывода, логика аутентификации) для выражения проекта.

3.Реализация КСЗ. Используются качественные методы реализации: например, многие ошибки безопасности существуют только потому, что в языке Си не контролировались границы массивов!

4.Тестирование КСЗ. Посмотрите, как удовлетворяет требованиям конечный результат.

Трудная часть такой методологии состоит в принятии решений:

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

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

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

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

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

Аутентификационная логика Бэрроуза-Абади-Нидхэма (BAN)

Аутентификационная логика БАН представляет собой теорию, которая может помочь в обсуждении определенного класса защищенных систем – а именно, тех, которые построены из принципалов и объектов, там, где объекты защищены простыми защитниками со списками контроля доступа (ACL). Защитнику необходим надежный способ определения того, кем на самом деле является принципал, запрашивающий доступ к объекту. Логика поможет установить цепь умозаключений, которые лежат в основе процесса аутентификации, выполняемого защитником. Мы дадим неформальное и упрощенное описание логики и ее использования. Для серьезного изучения прочтите «Аутентификация в распределенных системах: теория и практика» Лэмпсона и др., ACM Trans on Computer Systems, Vol. 10, No 4, Nov.1992, pp.

265-310.

Рассмотрим следующий пример: Алиса печатает на своем PC: «Отправьте задание номер 2». Ее ПК «А» посылает сообщение по сети из сетевой карты 14 в сетевую карту 5 на файл-сервере F, и т.о. соединяется с файл-сервером. Файл-сервер хранит объект «задание номер 2» и имеет список ACL с маркером доступа для Алисы.

Файл-сервер должен только знать, что < Алиса сказала “отправьте задание номер 2”>. В аутентификационной логике эта фраза является высказыванием. Говоря неформально, предложение <A сказал B> означает, что можно какимто образом определить, что A действительно сказал B. Если бы мы находились в пределах видимости, команда <A сказал B> была бы аксиомой (мы бы видели, что именно A сказала это!); но если мы только слышали об этом, то для доказательства необходимо использовать дополнительные допущения.

К сожалению, файловая система знает только, что сетевая карта F.5 (т.е., сетевая карта 5 на машине F) передала, что Алиса хочет, чтобы ей послали задание номер 2. Это означает, что файловая система знает, что <сетевая карта F.5 сказала: (Алиса сказала “отправьте задание номер 2”)>. Поэтому < Алиса сказала “отправьте задание номер 2”> в данный момент всего лишь гипотеза. Вопрос заключается в том, можем ли мы доверять тому, что сетевая карта F.5 сообщает правдивую информацию о том, что Алиса говорила или не говорила? Если мы доверяем F.5 говорить вместо Алисы, то пишем: <сетевая карта F.5 говорит от имени Алисы>. Это новое высказывание в аутентификационной логике. Тогда в примере, если мы верим тому, что <сетевая карта F.5 говорит от имени Алисы>, то можно заключить, что < Алиса сказала “отправьте задание номер 2”>.

Для того чтобы делать заключения согласно этой логике, необходимо соблюдать три правила:

Правило 1. Имперсонализация. Если <A сказал (B говорит от имени A)>, то <B говорит от имени A>. Это правило дает возможность Алисе поручить сетевой карте говорить от ее имени.

Правило 2. Делегация. Если <A говорит от имени B > и <A сказала (B сказал X) >, то <B сказал X>. Это правило говорит о том, что, если Алиса поручила сетевой карте говорить от ее имени, и карта передала информацию о том, что Алиса что-то сказала, то можно поверить тому, что Алиса действительно это сказала.

Правило 3. Цепочка поручений. Если <A говорит от имени B> и <B говорит от имени C>, то <A говорит от имени C>. Это правило говорит, что передача полномочий является транзитивной: если Боб поручил говорить от своего имени Алисе, а Карл поручил Бобу говорить от своего имени, то Карл, тем самым, также поручил Алисе говорить от его имени.

Подход жесткой логики (hardwired approach)

Как может файл-сервер установить, что <сетевая карта F.5 говорит от имени Алисы>? Первый подход состоит в жесткой связи всей нашей инсталляции. Если мы прикрепим Алису к ее РС, ее ПК к сетевой карте A.14 и сетевую карту A.14 через сетевой кабель к сетевой карте F.5, то получим:

1.<сетевая карта F.5 говорит от имени сетевого кабеля>: предполагается, что нарушитель не перемонтировал карту.

2.<сетевой кабель говорит от имени сетевой карты A.14>: предполагается, что отсутствует вмешательство в канал.

3.<карта A.14 говорит от имени ПК Aлисы>: предположим, что ПК правильно подсоединен.

4.<ПК A говорит от имени Алисы>: предположим, что операционная система ПК Алисы является защищенной.

Короче говоря, мы предполагаем, что и оборудование, и ПК Алисы являются частями доверенной вычислительной базы. Если мы допускаем это, то мы можем повторно применить правило 3, пока не получим <сетевая карта F.5 говорит от имени Алисы>. Затем мы можем применить правило 2 и получить: <Алиса сказала «Отправьте задание номер 2»>. Аутентификация происхождения сообщения закончена, и теперь файловая система может искать маркер доступа Алисы в списке контроля доступа.

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

Подход сети Интернет

Теперь предположим, что мы подключили сетевую карту 14 к сетевой карте 5 файл-сервера через Интернет. Тогда имеем:

1.<сетевая карта F.5 говорит от имени Интернета>: предположим, что нарушитель не перемонтировал карту.

2.<Интернет говорит от имени сетевой карты A.14>: согласно подходу «жесткой логики» нам приходится предположить, что Интернет является частью ДВБ?!

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

Что же нам делать? Предположим, что сообщение, посланное Алисой, имеет MAC или имитовставку, ключ которой Т. Т.е. Алиса посылает сообщение {Кому: файл-серверу; От кого: Алиса; “отправьте задание номер

2”}T.

Тогда мы имеем, что <T сказал (Алиса сказала “отправь задание номер 2”)>. Если мы знаем, что Алиса – единственная особа, кому известен ключ T, то можем поверить тому, что <ключ T говорит от имени Алисы>.

Тогда имеем по правилу 2, <Алиса сказала “отправьте задание номер 2”>. Но является ли Алиса действительно единственным человеком в мире, кто знает ключ T? Мы используем секретный ключ системы, следовательно, файловый сервис тоже должен знать этот ключ, и, тем или иным образом, ключ должен быть надежно передан Алисе и файл-серверу. Таким образом, мы должны добавить в наш список предположений:

надежность файл-сервера;

защищенный обмен совместным ключом;

ни Алиса, ни файловый сервис не раскрыли ключ третьей стороне. Например, если файл-сервер и Алиса – единственные, кто знает ключ T

(они обменялись им по защищенному каналу в начальный момент времени), то действительно можно считать, что <T выступает вместо Алисы>.

Если файл-сервер получил T посредством сообщения {Алиса, файлсервер, T}kFS от сервиса аутентификации, такого как протокол XNS, то имеем: <kFS сказал (XNS сказал (T выступает вместо Алисы))>. Если мы доверяем kFS, то можем заключить, что <XNS сказал (T выступает вместо Алисы)>. Т.о. если мы доверяем корпорации Xerox, то видим, что действительно <T выступает вместо Алисы>, и все в порядке. Снова этот путь рассуждений не доказательство, но он заставляет четко формулировать наши предположения (например, о надежности ключа kFS и протокола XNS).

Логика, представленная здесь, не занимается вопросами «свежести». На самом деле, из примераможно вывести только то, что «Алиса сказала: отправьте задание номер 2», но не то, что Алиса произнесла это в данный момент. Следовательно, кто-то еще мог бы воспроизвести это сообщение. Расширения базовой логики позволяют иметь дело со «свежестью», вводя дополнительные правила, которые относятся к различию в правилах с точки зрения «говорит (в данный момент)» и «сказала». Если мы хотим проанализировать это более глубоко, то нам надо более подробно специфицировать сетевые протоколы; однако остановимся на этом. Общая картина должна быть ясна.

Сертификация открытых ключей

А теперь изучим совершенно другую проблему сертификации: а именно, как можно сертифицировать общий или открытый ключ. Предположим, что у нас две пары ключей: одна для Алисы, (kA,pub, kA,priv), и одна для Боба, (kB,priv, kB,pub). Если Боб передал Алисе свой открытый ключ kB,pub, то после этого она может послать зашифрованное сообщение kB, pub [M] в полной уверенности, что только Боб сумеет прочитать M. Весь вопрос в том, откуда Алиса может узнать, что kB, pub действительно открытый ключ Боба? Если Алиса и Боб встретились бы лицом к лицу, и Боб вручил бы Алисе лист бумаги с его открытым ключом, то Алиса могла бы иметь разумное свидетельство тому, что ключ принадлежит Бобу. Однако, если Алиса получает только электронное сообщение, в котором говорится: “Привет, я Боб, а это мой открытый ключ”, то у Алисы нет полной уверенности, что сообщение не подделано. Боб могла бы аутентифицировать сообщение с помощью шифрования на своем секретном ключе, но Алиса пока еще не знает его открытого ключа, поэтому такой механизм не работает.

Предположим, что у Боба и Алисы есть общий друг Сергей, чей открытый ключ они знают. Алиса может спросить у Сергея: “Какой у Боба открытый ключ?” Тогда сергей может послать Алисе сообщение: kS, priv{A, kB, pub}. Фактически, это сообщение говорит Алисе: “Я, Сергей, удостоверяю, что ключ kB, pub является подлинным открытым ключом Боба”. Или <Сергей сказал (kB, pub выступает вместо Боба)>. Мы назовем это сообщение сертификатом1, и мы создали цепь сертификации. Существуют два подхода в организации сертификатов: обсудим по очереди каждый из них.

Иерархический подход

В иерархическом подходе центры распределения ключей или службы сертификации (CA) ведут учет открытых ключей и управляются своими руководителями (central authorities). Для того, чтобы сделать этот подход масштабируемым, центры распределения ключей иерархически упорядочены.

Например, Алиса запрашивает локальную службу сертификации (ЦРК СФУ) по поводу ключа Боба. Если ЦРК СФУ не знает открытый ключ Боба kB,pub, то он запрашивает краевой ЦРК. Если не знает краевой ЦРК, то он запрашивает ЦРК России и т.д. Затем СФУ возвращает Алисе открытый ключ Боба kB,pub с цепочкой подтверждений от руководств, которые принимали участие в создании цепочки сертификатов. Проблема такого подхода состоит в том, что вы должны доверять сторонам.

Сетевой подход

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

В подходе доверенной сети избегают использования цепочки полномочных сторон. Вместо этого, Алиса может выбрать сама, кому она доверяет. В этом подходе Боб получает сертификаты от своих друзей Сергея, Николая и Эллы и вывешивает их на своей веб-странице: kS,priv [B, kB,pub], kN,priv [B, kB,pub], kE,priv [B, kB,pub]. Если Алиса знает кого-нибудь из них: Сергея, Николая или Эллу, то она может подтвердить какой-либо из сертификатов, расшифровав открытым ключом сертификат, который они подписали, используя свои секретные ключи.

С другой стороны, если Алиса не знает ни Сергея, ни Николая, ни Эллу, то он, возможно, знает кого-нибудь еще (скажем, Игоря), кто знает одного из них. Если она доверяет Игорю, то может получить от него сертификат, удостоверяющий один из открытых ключей kS, pub, kN, pub или kE, pub, который она может затем использовать, чтобы сертифицировать открытый ключ Боба. Если она хочет, то может проверить цепь доверия, которая выступает вместо открытого ключа Боба, и посмотреть, устраивает ли ее эта цепь.

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

Центральная идея в сетевом подходе состоит в том, что Алиса может решить сама, кому доверяет, вместо опоры на центральное руководство. Протокол PGP (Pretty Good Privacy) использует этот подход.

Сертификация недоверенного кода

С приходом Java и Active-X сертификация недоверенного кода стала горячей темой. Проблема состоит в следующем. Пользователь, запустив свой браузер, щелкает по URL, браузер интерпретирует URL и устанавливает связь с указанным сервером. Если запрашиваемая страница является активной страницей (страницей с программой), а не пассивной страницей (т.е., страницей с HTML), сервер посылает код на браузер, который его выполняет. Активная страница может содержать картинку с анимацией (прыгающие шары) или что-то еще. Проблема в том, что активная страница может также содержать команду, которая удалит все ваши файлы.

Существуют два подхода, используемых при сертификации недоверенного кода:

1.Сэндбоксинг, (англ., sandbox, ящик с песком). Недоверенный код выполняется в защищенном “ящике с песком”. “Ящик с песком” тщательно устанавливается так, что выполняемый в нем код не может причинить ущерба чему-нибудь за его пределами. Например, “ящик с песком” установлен таким образом, что недоверенный код может читать только временные файлы.

2.Подпись кода. Недоверенный код прибывает вместе с сертификатом, который говорит о том, кто его написал. Если вы доверяете автору, то выполняете код; если не доверяете, то не выполняете. Если вы доверяете автору, но код делает что-то плохое, то вы обвиняете автора. Например,

web-страница может содержать kMS, priv [Microsoft, программа]. Если мы можем расшифровать это сообщение открытым ключом Microsoft, тогда < kMS, priv сказал (Microsoft выступает вместо код)>. Если мы доверяем Microsoft писать хорошие программы, то можем принять решение выполнять этот код; в противном случае не выполнять. Этот подход напоминает модель распространения программного обеспечения (ПО) (CD-диски с ПО упакованы в пластик, и пользователь знает, откуда они поступают).

Подход на основе “ящиков с песком” часто приводит к большой ДВБ. Надо доверять “сэндбоксеру” (на Java, байт-кодовому интерпретатору, библиотекам и т.п.) и правилам безопасности “сэндбоксера”; список допущений, которые нужно принять, велик. Подход с подписью кода является подходом типа “все или ничего”; если вас обманули в том, что некоторый ключ “выступает вместо” кого-то, кому вы доверяете, то вы проиграли. К тому же, после нанесения ущерба нелегко установить, кого следует обвинять.

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