| ||||||||||||||||
| ||||||||||||||||
| ||||||||||||||||
О скрытых каналах и не только
Автор не является экспертом в области скрытых каналов и прекрасно осознает это. Данную статью он рассматривает как еще одну попытку убедить себя и, если повезет, читателя в продуктивности подхода к проблемам информационной безопасности с позиций технологии программирования, в необходимости рассматривать программно-технический уровень безопасности в общем контексте информационных технологий.
В статьях и обзорах, посвященных скрытым каналам, обычно пишут, что этот термин введен в работе Лэмпсона [1]. Важно отметить, однако, что Батлер Лэмпсон упоминает о скрытых каналах как бы между делом, не они являются предметом исследования. Его трехстраничная заметка называется "О проблеме ограничения" ("A Note on the Confinement Problem") и посвящена она, выражаясь современным языком, контролируемому выполнению (недоверенных) программ с целью помешать им организовать утечку конфиденциальной информации. Идея дополнительного ограничения действий, которые разрешается выполнять программе, (помимо применения имеющихся в операционной системе механизмов контроля доступа), является исключительно важной и глубокой, опередившей свое время. По сути Лэмпсон пунктиром обозначил будущие модели безопасности для Java-аплетов — от "песочницы" до контроля по стеку вызовов, причем сделал это на 25 лет раньше разработчиков Java (заметка была сдана в редакцию в июле 1972 года, а по ссылкам видно, что он занимался проблемами динамической защиты еще в 1960-е годы). Лэмпсон рассматривает следующую задачу. Пусть клиент вызывает некоторый сервис, передавая ему в качестве параметров конфиденциальную информацию, утечка которой нежелательна. Спрашивается, как следует ограничить поведение произвольного сервиса? (В 1972 году сервис представлял собой процедуру, вызываемую из клиентской программы; о распределенных архитектурах речь не шла, но многопроцессные конфигурации были обычным явлением.) Подчеркнем, что речь идет о создании "песочницы" для произвольной программы. Если ограничения окажутся нарушенными, выполнение сервиса должно аварийно завершаться. Чтобы понять характер налагаемых ограничений, Лэмпсон сначала исследует возможные каналы утечки информации, выделяя следующие:
Всегда интересно не просто теоретически знать, что каналы утечки существуют, но и понять на практике, как они могут быть устроены. Лэмпсон описывает "эксплойт" для использования конфликтов по ресурсам (мы приведем его в несколько модифицированном виде). Пусть, например, один и тот же файл нельзя параллельно открыть из двух процессов (при попытке сделать это фиксируется ошибка). Данный факт можно использовать для побитной передачи информации. Две следующие процедуры, написанные на АЛГОЛоподобном языке обеспечивают, соответственно, установку нужного бита и его проверку. Листинг 1
(К своему стыду, автор не знает, как окружение АЛГОЛ-программ реагирует на попытку закрыть неоткрытый файл). Сейчас далеко не все помнят тонкости АЛГОЛа-60, поэтому нужно пояснить по крайней мере два момента. Во-первых, метки в АЛГОЛе являются допустимым типом данных, значения которого можно передавать в качестве параметров. Во-вторых, если (занятый) файл открыть не удалось, управление нелокально передается на метку, заданную в качестве второго аргумента процедуры open. Кстати, это более практичный способ обработки исключительных ситуаций, чем проверка кодов возврата, которую зачастую забывают сделать, что является одним из источников уязвимостей программных систем. Теперь, располагая элементарными операциями, можно организовать передачу бита между процессами. Для этого Лэмпсон использует три файла: data, sendclock и receiveclock. В программе-сервисе может присутствовать такой фрагмент (написанный нами с некоторыми вольностями): Листинг 2
Процесс-получатель может осуществлять прием бита так: Листинг 3
Переходя к правилам ограничения (контролируемого выполнения), Лэмпсон прежде всего указывает, что ограничиваемая программа не должна иметь возможности сохранять информацию между вызовами. Для процедур это условие легко проверяется: оно означает отсутствие обращений к нелокальным переменным. Если нелокальная память отсутствует, то для успешной реализации ограничения достаточно, чтобы ограничиваемая программа не вызывала других программ. Это правило полной изоляции по сути совпадает с моделью "песочницы" в версии JDK 1.0. Разумеется, Лэмпсон тут же отвергает его как нереалистичное, поскольку, как показывают два последних из перечисленных выше примеров утечек, в числе прочих должны быть запрещены явные и неявные вызовы супервизора (ядра ОС). Попытка применить правило полной изоляции "насквозь" и потребовать, чтобы ограничивались все вызываемые программы, не проходит, поскольку супервизор нельзя ограничивать. Чтобы исправить ситуацию, предлагается, как и следовало ожидать, поделить всех на чистых и нечистых, то есть на тех, кому доверяют, и тех, кого ограничивают. В результате получается следующее правило: если ограничиваемая программа вызывает недоверенную, то последнюю также необходимо ограничивать. Дело осталось за малым — написать доверенный супервизор. Как показывают два последних из перечисленных выше примеров утечек, дело это непростое, поскольку используемые для этого каналы могут быть самыми неожиданными. Тем не менее Лэмпсон придерживается оптимистической точки зрения: каналов утечки, конечно, на удивление много, но все-таки конечное число. Необходимо их перенумеровать, а потом и заблокировать. В качестве отправной точки предлагается следующая классификация каналов:
Вот в каком контексте вводится понятие скрытого канала (covert channel) и как оно определяется Лэмпсоном. Обратим внимание читателя на то, что все каналы по памяти отнесены к другому классу утечек. Важно и то, что помимо скрытых, Лэмпсон рассматривает и так называемые "подсознательные" или потайные каналы (легальные каналы, по которым передаются данные, допускающие нестандартную интерпретацию и, следовательно, которые могут служить каналом утечки конфиденциальной информации), хотя используемый в настоящее время термин subliminal channel, по-видимому, введен Б. Шнейером [2] примерно двадцать лет спустя. По мнению Лэмпсона предотвратить утечки через память довольно просто. Например, чтобы избавиться от блокировок при совместном доступе к ресурсам, можно при попытке записи копировать файл и бесконфликтно предоставлять копию для чтения ограничиваемой программой. (Заметим, что идея эта весьма глубока, только лучше при попытке записи открывать новую версию файла и писать в нее, применяя в дальнейшем механизмы конфигурационного управления.) Для блокирования легальных и скрытых каналов предлагается следующий принцип маскирования: ограничиваемая программа должна позволять вызывающему полностью определять вывод в легальные и скрытые каналы. Таким образом каналы маскируются вызывающим (клиентом). Это — центральная идея работы Лэмпсона. Программа ограничивается в соответствии с ожидаемой семантикой и специфическими потребностями вызывающего. Например программа для просмотра документов не должна изменять или создавать файлы. Напротив компилятору без создания файлов (временных и постоянных) не обойтись. Вообще говоря при разных вызовах одного сервиса ограничения могут быть разными. Тем более они могут быть разными для разных сервисов. Если сервис не в состоянии удовлетворить требования клиента, вызов отвергается. Для скрытых каналов Лэмпсон формулирует еще одно правило — проведения в жизнь: супервизор обязан обеспечить соответствие вывода ограничиваемой программы в скрытые каналы спецификациям вызывающего. Считается, что концептуально это несложно: можно искусственно замедлять выполнение программы, генерировать фиктивные обращения к дискам и т.п., короче говоря, зашумлять скрытые каналы. Цена проведения в жизнь может быть большой. Более практичной альтернативой (если клиент готов допустить некоторую утечку) является ограничение пропускной способности скрытых каналов. Конечно, можно отметить, что некоторые положения работы Лэмпсона, касающиеся концептуальной простоты или принципиальной реализуемости выявления и блокирования каналов утечки (в частности, скрытых каналов), остались необоснованными. Более того, как показали последующие исследования, они неверны. Тем не менее эта работа продолжает оставаться актуальной и в наше время, а ее идейный потенциал далеко не исчерпан. Тематика ограничения (контролируемого выполнения) программ ждет дальнейшего развития. Коротко о традиционном подходе к проблеме скрытых каналов
Лэмпсон понимал, что без учета семантики программ невозможно управлять доступом и, в частности, не допускать утечек информации. К огромному сожалению, эта идея не была воспринята. Последующие усилия в основном оказались направленными на разработку и реализацию универсальных и формальных, но недостаточно содержательных моделей безопасности (в особенности моделей доступа), а также на выявление и оценку пропускной способности скрытых каналов для таких моделей. Более содержательная и важная для практики задача ограничения программ по сути оказалась забытой. Традиционным стало следующее определение скрытого канала (см. [3]). Пусть дана модель недискреционной политики безопасности М и ее реализация I(M) в операционной системе. Потенциальная связь между субъектами I(Si) и I(Sj) в I(M) называется скрытым каналом тогда и только тогда, когда эта связь между Si и Sj в модели M не разрешена. Несмотря на формальный стиль и пугающее слово "недискреционной", смысл этого определения довольно прост. С одной стороны, по сравнению с работой Лэмпсона, понятие скрытого канала стало трактоваться шире. Фактически к нему отнесены все виды передачи информации, нарушающие политику безопасности. С другой стороны, наложено ограничение на дисциплину разграничения доступа, реализуемую в ОС. Она не должна сводиться к произвольному (дискреционному, согласно официальной терминологии) управлению доступом. Это значит, что круг рассматриваемых систем сужен до весьма немногочисленных, хотя и критически важных, режимных конфигураций, использующих многоуровневую политику безопасности и принудительное (мандатное) управление доступом. Напомним, что в "Оранжевой книге" требования, касающиеся скрытых каналов, фигурируют, начиная с класса B2, а мандатный доступ появляется в классе B1. В тех странах, где нормативные документы в области информационной безопасности построены на основе "Оранжевой книги", режимные организации должны бороться со скрытыми каналами и по содержательным, и по формальным причинам, для них и реализация принудительного управления доступом, и блокирование скрытых каналов — действия необходимые. В то же время, они весьма сложны. Например, в упомянутой выше работе [3] обосновывается необходимость анализа исходного текста (наряду с анализом спецификаций) ядра ОС для выявления скрытых каналов по памяти и утверждается, что на ручной анализ ядра Secure Xenix требуется два человеко-года. Разумеется, анализ можно автоматизировать, что и было сделано, после чего было выявлено 25 переменных, потенциально пригодных для организации скрытых каналов. Любопытно отметить, что существование пяти каналов стало возможным из-за конфликтов между программным интерфейсом ядра Secure Xenix и правилами мандатного доступа; очевидно, без потери совместимости ликвидировать эти каналы невозможно. В подавляющем большинстве случаев многоуровневая политика безопасности направлена на сохранение конфиденциальности. С этой целью запрещаются информационные потоки "вниз", с верхних уровней секретности (доверия) на нижние. В таких условиях передатчиком в скрытом канале должна служить "троянская" программа с высоким уровнем доверия. Скрытые каналы по памяти были детально рассмотрены в предыдущем разделе. В принципе, скрытые каналы по времени устроены аналогично примеру с конфликтами при открытии файлов; различия касаются в основном способов кодирования передаваемой информации. Чтобы организовать скрытый канал по времени, нужен разделяемый ресурс (например, процессор) с возможностью воздействия со стороны одного процесса и выявления этого воздействия со стороны другого, а также двое часов — эталонные и сигнальные. Часы могут быть виртуальными и реализовываться в виде последовательности наблюдаемых событий. Передача информации осуществляется за счет модуляции последовательности сигнальных событий, прием — путем измерения модуляции относительно эталонных часов. В работе [4] рассматривается построение скрытого канала по времени, использующего модуляцию занятости процессора. Идея состоит в следующем. На верхнем уровне доверия действует одна программа-передатчик. За один такт эталонных часов передатчик выполняет два вида циклов. Сначала (фаза 1) он почти не тратит процессорное время, сразу отдавая управление планировщику; затем (фаза 2), наоборот, занимает процессор максимально плотно. Приемник пытается определить относительную длительность этих двух фаз. Для этого приемник реализуется в виде двух процессов. Один подсчитывает, сколько раз он получил доступ к процессору, в цикле увеличивая (разделяемый) счетчик и тут же отдавая управление планировщику; другой в конце такта часов считывает и сохраняет значение счетчика, обнуляет его и откладывается до конца следующего такта. Со скрытыми каналами можно бороться двумя способами: пытаться блокировать их полностью или уменьшать пропускную способность. Для полного блокирования скрытого канала нужно устранить разделение ресурсов, видимое для процессов с низким уровнем доверия; последние должны выполняться так, будто кроме них в системе никого и ничего нет. Подобного невлияния можно добиться либо избегая конфликтов (например, за счет устранения разделения ресурсов), либо незаметным образом разрешая их в пользу "низших". Это, в свою очередь, порождает проблему, аналогичную инвертированию приоритетов: процесс с высоким уровнем доверия рискует получить слишком мало ресурсов, а совершаемые им транзакции могут слишком часто откладываться. Для борьбы с дискриминацией "секретных" процессов приходится идти на новые хитрости (см., например, [5]). Разумеется, в сколько-нибудь сложной системе избежать видимого разделения ресурсов невозможно. Идея реализации доменов безопасности с непроницаемыми границами и аппаратно односторонними междоменными каналами (см. [6]) относится скорее к области курьезов, поскольку игнорирует реально используемые коммуникационные протоколы. Следовательно, с существованием некоторых скрытых каналов приходится мириться, пытаясь, однако, уменьшить (или, по крайней мере, оценить) их пропускную способность. Если считать, что такт T эталонных часов постоянен, и за один такт можно различить N модуляций, то пропускная способность скрытого канала по времени оценивается величиной log2(N)/T. Для уменьшения пропускной способности можно "сбивать" часы (эталонные и/или сигнальные), "зашумлять" канал еще каким-либо способом (например, обслуживая фиктивные запросы), уменьшать разрешающую способность часов (увеличивая такт). (Заметим, что предпочтительнее воздействовать на эталонные, а не сигнальные часы, так как первое дает линейный эффект, а второе — лишь логарифмический). Любопытно отметить, что в локальной сети корпорации Боинг, сертифицированной по классу A1, разрешающая способность часов, доступных недоверенным процессам, составляет одну секунду (см. [4]). Как говорится, страшнее скрытого канала зверя нет, и для борьбы с ним приходится применять весьма сильнодействующие средства, существенно снижающие эффективность и осложняющие работу приложений. Впрочем, как показывает рассмотренный выше пример, можно добраться до более тонких внутренних часов планировщика; он демонстрирует также, насколько сложны анализ пропускной способности скрытых каналов и борьба с ними. Первопричина существования скрытых каналов и невозможность их устранения при традиционном подходе к построению информационных систем видится нам в следующем. Поскольку такие формальные модели безопасности, как известная модель Белла-Лападула, разграничивают доступ "в принципе", но не содержат понятия времени и не регламентируют конкуренцию за ресурсы, то есть ситуации, когда "в принципе ресурс использовать можно, только в данный момент нельзя — он занят", при любом распределении прав доступа разного рода сигнальные события и, в частности, коллизии вследствие конкуренции могут быть использованы для организации скрытых каналов. С потайными каналами (см. выше раздел 1) дело обстоит еще хуже. Представляется очевидным, что если не формализовать структуру данных, передаваемых программами по легальным каналам (Лэмпсон указывал на необходимость подобной формализации), последние всегда можно использовать для скрытой передачи информации. Строгое доказательство невозможности устранения и даже обнаружения потайных каналов при весьма общих предположениях относительно схем контроля имеется в работах А.А. Грушо [7], [8]. Перечисленными причинами объясняется необходимость развития отдельной науки под названием "анализ скрытых каналов", а также принципиальная невозможность полностью блокировать утечку конфиденциальной информации универсальными средствами, не учитывающими семантику программ. Скрытые каналы и повседневная практика
В повседневной практике скрытые каналы трактуются шире, чем в теории. Расширение происходит по четырем направлениям:
В повседневной практике скрытые каналы чаще всего возникают из-за возможности доступа к данным несколькими способами. Например, если в корневом каталоге файловой системы располагается tftp-сервер, он позволит получить всем пользователям доступ на чтение ко всем файлам, независимо от установленных прав доступа. Второй пример: если есть программа со взведенным битом переустановки действующего идентификатора пользователя, владельцем root и ... уязвимостью, то обычный пользователь может проэксплуатировать уязвимость, захватить привилегии суперпользователя и нарушить конфиденциальность и целостность чего угодно. Третий пример: пароль в незашифрованном виде, хранящийся в оперативной памяти и сбрасываемый в файл с образом памяти при аварийном завершении. Очевидно, число подобных примеров можно умножать до бесконечности. Нестандартные способы передачи информации по легальным каналам получили название "подсознательных" или потайных каналов (subliminal channels), хотя по аналогии с наложенными сетями их лучше было назвать наложенными скрытыми каналами. Потайные каналы используют тогда, когда имеется легальный коммуникационный канал, но политика безопасности запрещает передавать по нему определенную информацию; иными словами, информацию передавать можно, но она не должна выглядеть подозрительно (в соответствии с некими, обычно не очень четкими критериями). Помимо разведчиков, в потайных каналах нуждаются хозяева "троянских" программ, таких, например, как Back Orifice или Netbus; если канал взаимодействия с ними будет явным, "троянца" быстро вычислят и уничтожат. Подобные каналы, используемые для управления, должны быть двунаправленными. Потайной канал возможен тогда, когда в передаваемых легальных данных есть незначащие или почти незначащие биты, например, некоторые биты в заголовках IP-пакетов или младшие биты интенсивности цветов в графическом файле, присоединенном к письму. (Электронная почта — идеальный легальный канал, на который удобно накладывать скрытые.) В работе [9] рассматривается другой пример: нестандартный алгоритм электронной подписи, оставляющий место для тайных сообщений, не препятствующих проверке аутентичности ЭЦП. Для нарушения целостности чаще всего используют уязвимости, связанные с переполнением буферов. Если тем самым изменяется содержимое стека вызовов, то перед нами еще один пример скрытого канала, основанного на возможности доступа к данным нестандартным способом. Применяются также атаки пользовательских процессов на целостность транзакций, выполняемых процессами привилегированными (соответствующий англоязычный термин — race condition). Возможность подобной атаки появляется, если временные данные для транзакции располагаются в общедоступных каталогах, таких как /tmp. Разумеется, при расширительном толковании понятия скрытого канала проблемы, описанные в предыдущем разделе, не только остаются, но и обостряются; кроме того, к ним добавляются новые. С этими проблемами можно бороться двумя способами: формальным и содержательным. Формальный способ усиления безопасности состоит в попытке добавить к употребительным операционным системам, таким как Linux, возможности, реализующие требования классов B2 и старше из "Оранжевой книги", то есть реализовать в ядре ОС мандатный доступ ко всем ресурсам и провести анализ скрытых каналов. Вне зависимости от выполнимости последнего пункта, подобный путь представляется тупиковым. Одно дело анализировать скрытые каналы в операционной системе мэйнфрейма, изначально спроектированной с учетом требований безопасности и прошедшей многолетнюю апробацию (см., например, [10]) и совсем другое — в ОС, содержащей ошибки, связанные с переполнением буферов. Для подлинной безопасности нужно не только добавление принудительного управления доступом, но и существенное перепроектирование ОС. Содержательный способ борьбы со скрытыми каналами состоит в выстраивании эшелонированной обороны; утечки информации признаются неизбежными, но их пытаются локализовать и отследить. Для иллюстрации рассмотрим следующий гипотетический пример. Банк, информационная система которого имеет соединение с Интернет, защищенное межсетевым экраном, приобрел за рубежом автоматизированную банковскую систему (АБС). Изучение регистрационной информации экрана показало, что время от времени за рубеж отправляются IP-пакеты, содержащие какие-то непонятные данные. Стали разбираться, куда же пакеты направляются, и оказалось, что идут они в форму-разработчик АБС. Возникло подозрение, что в АБС встроены "троянская" программа и скрытый канал, чтобы получать информацию о деятельности банка. Связались с фирмой и в конце концов выяснили, что один из программистов не убрал из поставленного в банк варианта отладочную выдачу, которая была организована сетевым образом (как передача IP-пакетов специфического вида, с явно заданным IP-адресом рабочего места этого программиста). Если бы не межсетевой экран, канал оставался бы скрытым, а конфиденциальная информация о платежах свободно гуляла по сетям. Конечно, мысль о необходимости эшелонированной обороны не нова; надо только не забыть реализовать ее на практике... Еще один практически важный в данном контексте архитектурный принцип — разнесение доменов выполнения для приложений с разным уровнем доверия на разные узлы сети. Если такие приложения будут функционировать в распределенной среде клиент/сервер, ограничить их взаимное влияние (и, следовательно, заблокировать скрытые каналы) будет существенно проще, чем в случае единых многопользовательских систем. Скрытые каналы и Java-аплеты
Одной из актуальных и практически важных проблем информационной безопасности является пресечение вредоносных действий со стороны мобильных агентов и, в частности, Java-аплетов. Подобные агенты — обязательная составляющая систем электронной коммерции, электронного голосования и других приложений, ориентированных на массовое, повседневное использование. Универсальной модели безопасности, реализованной на платформе Java 2 и ориентированной на защиту локальных ресурсов от несанкционированного доступа со стороны аплета, недостаточно для того, чтобы предотвратить утечку конфиденциальной информации по скрытым каналам, поскольку такую информацию может передать аплету сам пользователь (в надежде на корректность поведения аплета). Хотелось бы, чтобы кроме надежды, у пользователя были и другие основания для доверия. Для этого необходимо ограничить поведение аплета в соответствии с его спецификациями, что означает возврат к истокам, к постановке задачи, предложенной Лэмпсоном тридцать лет назад. В работе [11] рассматривается пример простого протокола из области электронной торговли, возникающие при этом сложности с обеспечением конфиденциальности и возможные пути их преодоления. Суть примера в следующем. Имеются три субъекта: покупатель, продавец и банк, обслуживающий покупателя. Для оформления заказа покупатель загружает с сервера продавца Java-аплет, осуществляющий ввод данных о заказываемом товаре и реквизитах счета покупателя. Аплет должен передать эту информацию продавцу, предварительно зашифровав банковские реквизиты имеющимся у покупателя ключом банка (продавцу знать реквизиты счета покупателя не полагается, ему нужно лишь получить от банка плату за покупку). Очевидно, у аплета есть много способов разной степени скрытности передать продавцу конфиденциальную информацию о счете покупателя: изменить представление заказа зависящим от реквизитов образом, зашифровать реквизиты своим ключом (а не ключом банка) и т.п. Идея ограничения аплетов, предлагаемая в [11], состоит в том, чтобы вместе с интерпретируемым кодом поступали спецификация свойств конфиденциальности и допускающее автоматическую проверку доказательство того, что байт-код соответствует спецификации. В свою очередь, в спецификации задаются зависимости между изменением исходных данных (вводимых пользователем) и наблюдаемым поведением аплета. Эти зависимости должны быть в точности такими, как предписывает протокол. Например, результат шифрования реквизитов должен меняться при их изменении, равно как и при изменении банковского ключа; если последнее утверждение неверно, значит аплет использует для шифрования нелегальный ключ. Еще пример: данные о заказываемом товаре, передаваемые продавцу, не должны меняться при изменении реквизитов. Мы не будем вдаваться в тонкости применяемого в [11] формализма. Отметим лишь, что предлагаемый подход представляется весьма перспективным; это подтверждается прототипной реализацией. Он не решает всех проблем; со скрытыми каналами по времени бороться по-прежнему трудно, хотя в принципе можно варьировать уровень детализации наблюдаемого поведения, добиваясь видимости все более тонких эффектов. О скрытых каналах в искусстве и жизни
Идея скрытых и потайных каналов стара как мир. Аллегории, эзопов язык — это способы организовать потайные каналы при словесной передаче данных. Для визуальной передачи применяют пресловутые горшки с геранью, выставляемые на подоконник в определенных случаях, и другие условные знаки. Такая привычная вещь, как школьная подсказка, также является формой использования скрытых каналов. Впрочем, подсказки практикуются не только в школе. В сентябре 2001 года, при записи английской телепередачи "Who wants to be a millionaire?" майор Чарльз Ингрэм правильно ответил на все вопросы, но не получил положенный миллион фунтов стерлингов, поскольку организаторы шоу заподозрили обман и не только не выпустили записанную передачу в эфир, но и обратились в полицию. Режиссеру показалось, что ответ на последний, пятнадцатый вопрос ("Как называется число 10 в сотой степени?") игрок дал сразу после того, как в зале отчетливо прозвучал одиночный кашель (правильным был первый вариант ответа). Стали разбираться, изучать видеозапись (передача записывалась два дня). Выяснилось, что при ответе на первый вопрос второго дня (а всего восьмой, на восемь тысяч фунтов стерлингов) ("Кто был вторым мужем Жаклин Кеннеди?") майор по очереди вслух произносил представленные варианты ответов, и после озвучивания правильного варианта также послышался кашель. Дальнейшее расследование показало, что в зале присутствовала жена майора, Диана, якобы передававшая по рации вопросы другу семьи, который находил в Интернет ответы и сообщал их Диане, передававшей их мужу с помощью описанного выше скрытого канала с переменной схемой кодирования. (На самом деле, мы излагаем здесь реконструированную и наиболее логичную, на наш взгляд, версию происходившего; разные источники — После скандальной передачи организаторы игры усилили меры безопасности (см. Не беремся предсказывать, чем закончится эта история. Отметим лишь, что если у кого-то есть друг, умеющий быстро находить в Интернет нужную информацию, и жена, способная эту информацию воспринять и правильно, да еще с вариациями, прокашлять, то ему, безусловно, повезло. А организаторам подобных игр лучше бы озаботиться качеством вопросов, а не сканированием ушей игроков... Тема использования скрытых каналов в процессе игры, конечно, не нова. По крайней мере, внимание художников она привлекла более четырехсот лет назад. Наверняка многие помнят классическое полотно Караваджо (Микеланджело Меризи) "Игроки в карты" (второе название — "Игра в карты с шулерами"), датируемое приблизительно 1594 годом. На нем изображена типичная ситуация: недоверенный субъект осуществляет несанкционированное раскрытие информации, после чего передает ее по скрытому каналу. Отметим также, что еще один изображенный на картине недоверенный субъект уже обзавелся средствами (лишней картой за поясом) для нарушения целостности. Рисунок 1. Караваджо (Микеланджело Меризи) "Игроки в карты" (второе название — "Игра в карты с шулерами") Последователь Караваджо, Валантен (Жан де Булонь), на полотне "Игра в карты" изобразил более тонкий метод нарушения конфиденциальности, но механизм передачи данных остался тем же. Рисунок 2. Валантен (Жан де Булонь) "Игра в карты" (По адресу Не счесть примеров скрытых и потайных каналов в литературе. Один из лучших и самых драматичных принадлежит перу Борхеса и описан в его замечательной новелле "Сад расходящихся тропок". Мы приведем несколько фрагментов из нее, чтобы читатель смог оценить ресурсы и методы, потребовавшиеся для организацию подобного канала, результаты использования переданной информации и соотношение между тем и другим. Отметим, что в данном случае скрытый канал стал возможен из-за наличия свободного доступа к части регистрационной информации. Поучительно проанализировать и обстоятельства, способствовавшие успеху предприятия, в первую очередь — слабость некоторых методов биометрической идентификации/аутентификации (по разрезу глаз и цвету кожи) Итак, слово Борхесу.
Заключение
Изучение проблематики скрытых каналов показывает, как важно правильно поставить задачу и рассматривать ее не изолированно, а в реальном окружении. На наш взгляд, правильная постановка, связанная с контролируемым выполнением (ограничением) программ, с самого начала предложенная Лэмпсоном, в дальнейшем незаслуженно отошла на второй план. Попытки бороться со скрытыми (и потайными) каналами с помощью формальных методов, не учитывающих семантику программ, как показывают результаты А.А. Грушо, обречены на неудачу. В реальном окружении проблема утечки конфиденциальной информации стоит особенно остро для распределенных систем с мобильными агентами. В настоящее время существуют перспективные подходы к ее решению. На практике требуется блокировать скрытые каналы всех видов: как те, что угрожают конфиденциальности, так и представляющие угрозу целостности программ и данных. В частности, необходимо выявлять и пресекать общение "троянских" программ со своими хозяевами (равно как и попытки внедрения таких программ). Следование принципам архитектурной безопасности (эшелонированность обороны, разнесение доменов выполнения) помогает бороться как со скрытыми каналами, так и с последствиями их функционирования. При современной технологии создания информационных систем выявить и блокировать все скрытые каналы невозможно. Нужно заставить злоумышленников выстраивать как можно более длинные цепочки из таких каналов; обнаружить и разорвать подобную цепочку существенно проще, чем отдельный канал. Благодарности
Автор признателен И.А. Трифаленкову, которому принадлежит общий замысел данной статьи, определивший ее практическую направленность. Литература[1] B.W. Lampson -- A Note of the Confinement Problem. -- Communications of ACM, v. 16, n. 10, Oct. 1973 [2] B. Schneier -- Applied Cryptography: Protocols, Algorithms, and Source Code in C., 2nd edition -- John Wiley & Sons, New York, 1996 [3] C.-R. Tsai , V.D. Gligor , C.S. Chandersekaran -- A Formal Method for the Identification of Covert Storage Channels in Source Code -- IEEE Transactions on Software Engineering, v.16:6, 1990 [4] J.V.A. James , D.B. Darby , D.D. Schnachenberg -- Building Higher Resolution Synthetic Clocks for Signalling in Covert Timing Channels. — Proceedings of the Eight IEEE Computer Security FOundations Workshop (CSFW'95). -- IEEE, 1995 [5] S.H. Son , R. Mukkamala , R. David -- Integrating Security and Real-Time Requirements Using Covert Channel Capacity. -- IEEE Transactions on Knowledge and Data Engineering, v. 12, n. 6, Nov.-Dec. 2000 [6] J.A. Davidson -- Asymmetric Isolation. — Proceedings of the 12th Annual Computer Security Applications Conference (ACSAC). -- IEEE, 1996 [7] А.А. Грушо -- Скрытые каналы и безопасность информации в компьютерных системах -- Дискретная математика, т.10, вып. 1, 1998 [8] А.А. Грушо -- О существовании скрытых каналов -- Дискретная математика, т.11, вып. 1, 1999 [9] J.-K. Jan , Y.-M. Tseng -- New Digital Signature with Subliminal Channels on the Discrete Logarithm Problem. — Proceedings of the 1999 International Workshops on Parallel Processing. -- IEEE, 1999 [10] С. Симонов , П. Колдышев -- Обеспечение информационной безопасности в вычислительных комплексах на базе мэйнфреймов. -- Jet Info, No. 4, 2002 [11] M. Dam , P. Giambiagi -- Confidentiality for Mobile Code: The Case of a Simple Payment Protocol. — Proceedings of the 13th IEEE Computer Security Foundations Workshop (CSFW'00). -- IEEE, 2000 |
|
| ||||||||||||||||
|