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

По–крупному есть два основных пути утечки информации:

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

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

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

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

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

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

Побочные каналы

Очень часто противник может по крохам собрать важные сведения, измеряя нечто такое, о чем проектировщики даже не подозревали. Или, по крайней мере, не думали, что «разглашение» может иметь какие–либо последствия для безопасности!

Есть два вида так называемых побочных каналов: связанные с хронометражем и с хранением. По хронометрируемому каналу противник получает информацию о внутреннем устройстве системы, измеряя время выполнения операций. Например, в грехе 11 мы описали простой хронометрируемый канал в процедуре входа в систему TENEX, когда противник мог что–то узнать о пароле, засекая время реакции на ввод неверных паролей. Если первая буква введенного пароля правильна, то система отвечает быстрее, чем в случае неправильной буквы.

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

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

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

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