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

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

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

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

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

В работе [11] рассматривается пример простого протокола из области электронной торговли, возникающие при этом сложности с обеспечением конфиденциальности и возможные пути их преодоления. Суть примера в следующем. Имеются три субъекта: покупатель, продавец и банк, обслуживающий покупателя. Для оформления заказа покупатель загружает с сервера продавца Java-аплет, осуществляющий ввод данных о заказываемом товаре и реквизитах счета покупателя. Аплет должен передать эту информацию продавцу, предварительно зашифровав банковские реквизиты имеющимся у покупателя ключом банка (продавцу знать реквизиты счета покупателя не полагается, ему нужно лишь получить от банка плату за покупку).

Очевидно, у аплета есть много способов разной степени скрытности передать продавцу конфиденциальную информацию о счете покупателя: изменить представление заказа зависящим от реквизитов образом, зашифровать реквизиты своим ключом (а не ключом банка) и т.п. Идея ограничения аплетов, предлагаемая в [11], состоит в том, чтобы вместе с интерпретируемым кодом поступали спецификация свойств конфиденциальности и допускающее автоматическую проверку доказательство того, что байт-код соответствует спецификации. В свою очередь, в спецификации задаются зависимости между изменением исходных данных (вводимых пользователем) и наблюдаемым поведением аплета. Эти зависимости должны быть в точности такими, как предписывает протокол. Например, результат шифрования реквизитов должен меняться при их изменении, равно как и при изменении банковского ключа; если последнее утверждение неверно, значит аплет использует для шифрования нелегальный ключ. Еще пример: данные о заказываемом товаре, передаваемые продавцу, не должны меняться при изменении реквизитов.

Мы не будем вдаваться в тонкости применяемого в [11] формализма. Отметим лишь, что предлагаемый подход представляется весьма перспективным; это подтверждается прототипной реализацией. Он не решает всех проблем; со скрытыми каналами по времени бороться по-прежнему трудно, хотя в принципе можно варьировать уровень детализации наблюдаемого поведения, добиваясь видимости все более тонких эффектов.