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

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

В настоящее время, автором разработаны две системы защиты информации, основанные на предлагаемом подходе, для браузера Netscape Navigator (3.x) и Netscape Communicator 4.х. В ходе предварительного тестирования установлено, что разработанные системы могут нормально функционировать и под управлением MExplorer, но не во всех случаях.

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

Система 1 предлагает защиту (шифрование) собственно html-страниц, как единого объекта. Вы создаете страницу, а затем ее зашифровываете и копируете на сервер. При обращении к зашифрованной странице, она автоматически расшифровывается и выводится в специальное окно. Поддержки системы защиты со стороны программного обеспечения сервера не требуется. Вся работа по зашифрованию и расшифрованию осуществляется на рабочей станции клиента. Данная система является универсальной, т.е. не зависит от структуры и назначения страницы.

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

Данный подход может быть применен и при построении систем электронных платежей через Интернет. В этом случае, при обращении к некоторой странице Web-сервера происходит запуск модуля Plug-in, который выводит пользователю форму платежного поручения. После того как клиент заполнит ее, модуль зашифровывает данные платежа и отправляет их на сервер. При этом он может затребовать электронную подпись у пользователя. Более того, ключи шифрования и подписи могут считываться с любого носителя: гибких дисков, электронных таблеток, смарт-карт и т.д.

2.3 Анализ технологий на соответствие базовым требованиям к системам электронных платежей

Выше мы описали три технологии, которые могут быть использованы при построении платежных систем через Интернет: это технология, основанная на Java-апплетах, компонентах Active-X и встраиваемых модулях Plug-in. Назовем их технологии J, AX и P соответственно.

Рассмотрим требование об неувеличении возможностей атак злоумышленника на компьютер. Для этого проанализируем один из возможных типов атак - подмену злоумышленником соответствующих клиентских модулей защиты. В случае технологии J - это апплеты, В случае AX - погружаемые компоненты, в случае P - это включаемые модули Plug-in. Очевидно, что у злоумышленника существует возможность подменить модули защиты непосредственно на компьютере клиента. Механизмы реализации данной атаки лежат за пределами данного анализа, тем не менее, необходимо отметить, что реализация данной атаки не зависит от рассматриваемой технологии защиты. И уровень защищенности каждой технологии совпадает, т.е. все они одинаково неустойчивы к данной атаке.

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

В случае технологии P опасности подмены нет, так как модуль не загружается из сети - он постоянно хранится на компьютере клиента.

Последствия подмены различны: в случае J-технологии злоумышленник может только похитить вводимую клиентом информацию (что является серьезной угрозой), а в случае, Active-X и Plug-in злоумышленник может получить любую информацию, к которой имеет доступ, работающий на компьютере клиент.

В настоящее время автору неизвестны конкретные способы реализации атак по подмене Java-апплетов. Видимо данные атаки плохо развиваются, так как результирующие возможности по похищению информации практически отсутствуют. А вот атаки на компоненты Active-X широко распространены и хорошо известны.

Рассмотрим требование о защите информации, циркулирующей в системе электронных платежей через Интернет. Очевидно, что в этом случае технология J уступает и P и AX в одном очень существенном вопросе. Все механизмы защиты информации основаны на шифровании или электронной подписи, а все соответствующие алгоритмы основаны на криптографических преобразованиях, которые требуют введения ключевых элементов. В настоящее время длина ключевых элементов составляет порядка 32-128 байт, поэтому требовать введения их пользователем с клавиатуры практически невозможно. Возникает вопрос как их вводить? Так как технологии P и AX имеют доступ к ресурсам компьютера, то решение данной проблемы очевидно и хорошо известно - ключи считываются из локальных файлов, с флоппи-дисков, таблеток или smart-карт. А вот в случае технологии J такой ввод невозможен, значит приходится либо требовать от клиента ввода длинной последовательности неосмысленной информации, либо, уменьшая длину ключевых элементов, снижать стойкость криптографических преобразований и следовательно снижать надежность механизмов защиты. Причем данное снижение является очень существенным.

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

В случае технологии P данные информация представляется с виде html-страниц, которые зашифровываются и размещаются на сервере. Все действия выполняются в соответствии с описанным выше (шифрование html-страниц) алгоритмом.

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