InfoCity
InfoCity - виртуальный город компьютерной документации
Реклама на сайте







Размещение сквозной ссылки

 

О скрытых каналах и не только

Алексей Галатенко

СОДЕРЖАНИЕ

Оправдания

К истокам

Коротко о традиционном подходе к проблеме скрытых каналов

Скрытые каналы и повседневная практика

Скрытые каналы и Java-аплеты

О скрытых каналах в искусстве и жизни

Заключение

Благодарности

Литература

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

Р. Стаут. "Если бы смерть спала"

Оправдания

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

Р. Стаут. "Слишком много клиентов"

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

К истокам

Чем выше ум, тем тень длиннее ляжет,

Отброшенная им на дальний мир.

Р. Браунинг. "Парацельс"

В статьях и обзорах, посвященных скрытым каналам, обычно пишут, что этот термин введен в работе Лэмпсона [1]. Важно отметить, однако, что Батлер Лэмпсон упоминает о скрытых каналах как бы между делом, не они являются предметом исследования. Его трехстраничная заметка называется "О проблеме ограничения" ("A Note on the Confinement Problem") и посвящена она, выражаясь современным языком, контролируемому выполнению (недоверенных) программ с целью помешать им организовать утечку конфиденциальной информации.

Идея дополнительного ограничения действий, которые разрешается выполнять программе, (помимо применения имеющихся в операционной системе механизмов контроля доступа), является исключительно важной и глубокой, опередившей свое время. По сути Лэмпсон пунктиром обозначил будущие модели безопасности для Java-аплетов — от "песочницы" до контроля по стеку вызовов, причем сделал это на 25 лет раньше разработчиков Java (заметка была сдана в редакцию в июле 1972 года, а по ссылкам видно, что он занимался проблемами динамической защиты еще в 1960-е годы).

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

Подчеркнем, что речь идет о создании "песочницы" для произвольной программы. Если ограничения окажутся нарушенными, выполнение сервиса должно аварийно завершаться.

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

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

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

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

Листинг 1

 setbit (file, bit); 
   Boolean bit; 
begin 
   if bit = true then 
      loop1: open (file, loop1) 
   else 
      close (file) 
end;

Boolean procedure testbit (file); 
begin 
   testbit : = true; 
   open (file, loop2); 
   testbit := false; 
   close (file) 
loop2: end;

(К своему стыду, автор не знает, как окружение АЛГОЛ-программ реагирует на попытку закрыть неоткрытый файл).

Сейчас далеко не все помнят тонкости АЛГОЛа-60, поэтому нужно пояснить по крайней мере два момента. Во-первых, метки в АЛГОЛе являются допустимым типом данных, значения которого можно передавать в качестве параметров. Во-вторых, если (занятый) файл открыть не удалось, управление нелокально передается на метку, заданную в качестве второго аргумента процедуры open. Кстати, это более практичный способ обработки исключительных ситуаций, чем проверка кодов возврата, которую зачастую забывают сделать, что является одним из источников уязвимостей программных систем.

Теперь, располагая элементарными операциями, можно организовать передачу бита между процессами. Для этого Лэмпсон использует три файла: data, sendclock и receiveclock.

В программе-сервисе может присутствовать такой фрагмент (написанный нами с некоторыми вольностями):

Листинг 2

: 
   setbit (data, bitbeingsent); 
   while testbit (receiveclock) = false do 
      ; 
   setbit (sendclock, false); 
   while testbit (receiveclock) = true do 
      ;

Процесс-получатель может осуществлять прием бита так:

Листинг 3

: 
   while testbit (sendclock) = false do 
      ; 
   receivedbit : = testbit (data); 
   setbit (receiveclock, true); 
   while testbit (sendclock) = true do 
      ; 
   setbit (receiveclock, false);

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

Если нелокальная память отсутствует, то для успешной реализации ограничения достаточно, чтобы ограничиваемая программа не вызывала других программ. Это правило полной изоляции по сути совпадает с моделью "песочницы" в версии 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 в сотой степени?") игрок дал сразу после того, как в зале отчетливо прозвучал одиночный кашель (правильным был первый вариант ответа).

Стали разбираться, изучать видеозапись (передача записывалась два дня). Выяснилось, что при ответе на первый вопрос второго дня (а всего восьмой, на восемь тысяч фунтов стерлингов) ("Кто был вторым мужем Жаклин Кеннеди?") майор по очереди вслух произносил представленные варианты ответов, и после озвучивания правильного варианта также послышался кашель.

Дальнейшее расследование показало, что в зале присутствовала жена майора, Диана, якобы передававшая по рации вопросы другу семьи, который находил в Интернет ответы и сообщал их Диане, передававшей их мужу с помощью описанного выше скрытого канала с переменной схемой кодирования. (На самом деле, мы излагаем здесь реконструированную и наиболее логичную, на наш взгляд, версию происходившего; разные источники — www.izvestia.ru, www.tv-digest.ru, www.interpolice.ru — расходятся в деталях.) В марте 2003 года начался суд, призванный решить судьбу миллиона. Естественно, адвокаты Ингрэма утверждают, что никакого обмана со стороны их клиента не было, а кашель в аудитории, насчитывающей двести человек, слышится постоянно (что, заметим, затрудняет мониторинг подобных скрытых каналов, хотя и зашумляет их).

После скандальной передачи организаторы игры усилили меры безопасности (см. http://www.interpolice.ru/archiv/2001/24/show.shtml?16). Все зрители подвергаются личному досмотру, участники — психологическому тестированию на предмет выявления криминальных склонностей. За залом ведется постоянное наблюдение, в том числе с помощью камер ночного видения. Эфир прослушивается радиосканером, чтобы выявить и заглушить возможную передачу ответа на миниатюрный приемник, который может быть спрятан у игрока в ухе. Вот так приходится бороться со скрытыми каналами, которые могут использовать злоумышленники с высокой мотивацией. Но не будет у организаторов гарантий информационной безопасности, пока у игрока и зрителей остается хоть один разделяемый ресурс, даже если этот ресурс — воздух.

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

Тема использования скрытых каналов в процессе игры, конечно, не нова. По крайней мере, внимание художников она привлекла более четырехсот лет назад. Наверняка многие помнят классическое полотно Караваджо (Микеланджело Меризи) "Игроки в карты" (второе название — "Игра в карты с шулерами"), датируемое приблизительно 1594 годом. На нем изображена типичная ситуация: недоверенный субъект осуществляет несанкционированное раскрытие информации, после чего передает ее по скрытому каналу. Отметим также, что еще один изображенный на картине недоверенный субъект уже обзавелся средствами (лишней картой за поясом) для нарушения целостности.

Рисунок 1. Караваджо (Микеланджело Меризи) "Игроки в карты" (второе название — "Игра в карты с шулерами")

Последователь Караваджо, Валантен (Жан де Булонь), на полотне "Игра в карты" изобразил более тонкий метод нарушения конфиденциальности, но механизм передачи данных остался тем же.

Рисунок 2. Валантен (Жан де Булонь) "Игра в карты"

(По адресу http://www.citycat.ru/rest/cards/painting/ можно найти и другие полотна аналогичной направленности, например, картину Йоса ван Красбека "Игроки в карты", где изображен трюк с зеркальцем.)

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

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

Итак, слово Борхесу.

На двадцать второй странице "Истории мировой войны" Лиддел Гарта сообщается, что предполагавшееся на участке Сер-Монтобан 24 июля 1916 года наступление тринадцати британских дивизий (при поддержке тысячи четырехсот орудий) пришлось отложить до утра двадцать девятого. Нижеследующее заявление, продиктованное, прочитанное и подписанное доктором Ю. Цуном, бывшим преподавателем английского языка в Hoch Schule города Циндао, проливает на случившееся неожиданный свет.

... Значит, Рунеберг арестован или убит. Солнце не зайдет, как та же участь постигнет и меня. ... я знаю Тайну — точное название места в долине Анкра, где расположен новый парк британской артиллерии. ... О, если бы ... я смог выкрикнуть это известие так, чтобы его расслышали в Германии... Мой человеческий голос был слишком слаб. Как сделать, чтобы он дошел до слуха шефа? До слуха этого слабогрудого, ненавистного человечка, который только знает обо мне и Рунеберге, что мы в Стаффордшире, и напрасно ждет от нас известий в своем унылом английском кабинете, день за днем изучая газеты... ... Что-то — наверное, простое желание убедиться в ничтожности своих ресурсов — подтолкнуло меня осмотреть карманы. Там нашлось только то, что я и думал найти. Американские часы, ... крона, два шиллинга и несколько пенсов, ... револьвер с одной пулей.

Я зачем-то взял его и, придавая себе решимости, взвесил в руке. Тут у меня мелькнула смутная мысль, что выстрел услышат издалека. Через десять минут план был готов. По телефонному справочнику я разыскал имя единственного человека, способного передать мое известие: он жил в предместье Фэнтона, с полчаса езды по железной дороге.

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

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

... из дома за оградой показался фонарь ... Нес его рослый мужчина. ... Он приоткрыл ворота и медленно произнес на моем родном языке:

— Я вижу, благочестивый Си Пэн почел своим долгом скрасить мое уединение. Наверное, вы хотите посмотреть сад?

Он назвал меня именем одного из наших посланников, и я в замешательстве повторил за ним:

— Сад?

— - Ну да, сам расходящихся тропок.

Что-то всколыхнулось у меня в памяти, и с необъяснимой уверенностью я сказал:

— Это сад моего прадеда Цюй Пэна.

— Вашего прадеда? Так вы потомок этого прославленного человека? Прошу.

Альбер поднялся во весь рост. Он выдвинул ящик высокой конторки и на миг стал ко мне спиной. Мой револьвер был давно наготове. Я выстрелил, целясь как можно тщательней: Альбер упал тут же, без единого слова. Клянусь, смерть его была мгновенной, как вспышка.

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

Заключение

"На этот раз я буду умнее", — подумал он, доставая камни из сумки и пряча их в карман. Это ведь портовый город, а в порту, как верно заметил тот, кто его обокрал, всегда полно жуликов.

П. Коэльо. "Алхимик"

Изучение проблематики скрытых каналов показывает, как важно правильно поставить задачу и рассматривать ее не изолированно, а в реальном окружении.

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

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

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

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

Благодарности

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

Р. Стаут. "Если бы смерть спала"

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

Литература

[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


Реклама на InfoCity

Яндекс цитирования



Финансы: форекс для тебя








1999-2009 © InfoCity.kiev.ua