Система безопасности Java

Нижегородский государственный технический университет Институт радиоэлектроники и информационных технологий Кафедра «Информатика и системы управления»

Методы и средства защиты компьютерной информации Реферат

«Система безопасности Java»

Нижний Новгород, 2007

1. Принцип работы Java

2. Защита Java-аплетов

3. Модель безопасности JDK1.2

4. Криптографическая архитектура Java

5. Объектная организация механизмов безопасности Список используемой литературы

1. Принцип работы Java

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

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

Кроме виртуального процессора, технология Java включает в себя (в качестве необязательного элемента) объектно-ориентированный язык программирования, построенный на основе языка C++, к которому добавили новые механизмы для обеспечения безопасности и распределенных вычислений.

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

2. Защита Java-аплетов

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

· читать, изменять, уничтожать и переименовывать локальные файлы;

· создавать локальные директории и читать их содержимое;

· проверять существование и параметры определенного файла;

· осуществлять доступ по сети к удаленному компьютеру;

· получать список сетевых сеансов связи, которые устанавливает локальный компьютер с другими компьютерами;

· получать сведения о пользователе или его домашней директории;

· выходить из интерпретатора Java;

Эти правила обеспечивают следующие компоненты Java-технологии.

· Собственно виртуальный Java-процессор, который постоянно контролирует свое состояние.

· Загрузчик аплетов и Java-программ, который контролирует загружаемые коды.

· Диспетчер безопасности (Secu-rityManager), контролирующий и блокирующий опасные действия аплетов.

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

· соответствует ли версия полученного блока версиям остальных элементов системы;

· соответствует ли программа спецификации конкретного виртуального Java-процессора;

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

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

Блокировка сервиса

В результате этого частично или полностью блокируется работа пользователя и даже может быть выведен из строя браузер. Вот далеко не полный список возможных вариантов такого «нападения» :

· загрузка процессора бессмысленными действиями;

· заполнение всей свободной памяти;

· захват важных системных классов.

" Тайные" каналы

Эти каналы позволяют получать информацию даже через систему защиты (брандмауэры). Существование «тайных» каналов в браузере делает его очень опасным. В качестве «тайного» канала можно использовать следующие действия аплетов:

· посылку почты через SMTP-порт сервера (причем почта посылается от имени пользователя, который работает с аплетом);

· запрос на поиск по несуществующему URL-адресу, в котором в качестве параметров передаются необходимые «взломщику» данные;

· попытку доступа по несуществующему адресу (последовательность директорий может содержать необходимые данные).

Информация, известная аплетам

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

· системное время;

· название и версия операционной системы;

· архитектура процессора.

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

3. Модель безопасности JDK1.2

В Java-технологии предусмотрен целый ряд защитных рубежей, которые можно разделить на три группы:

· надежность языка;

· контроль при получении и загрузке программ;

· контроль при выполнении программ.

Java обеспечивает безопасность за счет средств статического и динамического контроля. Еще одно Java — автоматическое управление памятью, исключающее появление «висячих» указателей.

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

· подделка указателей (например, получение указателя как результат выполнения арифметической операции);

· нарушение прав доступа к компонентам классов;

· вызов методов объектов с недопустимым набором параметров;

· недопустимое преобразование типов;

· переполнение или исчерпание стека.

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

Если продолжить деление на группы и уровни, то полезно выделить следующие два аспекта Java-безопасности:

· защита Java-окружения времени выполнения и ресурсов аппаратно-программной платформы от вредоносного программного обеспечения;

· разграничение доступа субъектов к ресурсам прикладного уровня.

Основная цель мер безопасности в Java — обеспечить защиту Java-окружения от вредоносных программ. Для достижения этой цели была предложена концепция «песочницы» (sandbox) — замкнутой среды, в которой выполняются потенциально ненадежные программы. Таковыми считались аплеты, поступившие по сети. Весь «родной» код (то есть программы, располагающиеся на локальном компьютере) считался абсолютно надежным и ему было доступно все, что доступно виртуальной Java-машине.

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

Чтобы как-то справиться с этой проблемой, ввели понятие электронной подписи, которую ставит распространитель аплета. Java-машина в соответствии со своей политикой безопасности делит распространителей и, соответственно, их аплеты на две категории — надежные и ненадежные. Надежные аплеты были приравнены в правах к «родному» коду.

Оформились три основных понятия:

· источник программы;

· право и множество прав;

· политика безопасности.

Источник программы определяется парой (универсальный локатор ресурсов — URL, распространители программы). URL может указывать на файл в локальной файловой системе или же на ресурс удаленной системы.

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

Политика безопасности задает соответствие между источником и правами поступивших из него программ. «Родные» программы не имеют каких-либо привилегий в плане безопасности и политика по отношению к ним может быть любой.

По сути имеется традиционный для современных операционных систем и систем управления базами данных механизм прав доступа со следующими особенностями:

· Субъектом доступа является не пользователь, а источник программы. Впрочем, формально можно считать, что во время исполнения программы ее источник становится;

· Нет понятия владельца ресурса, который (владелец) мог бы менять права; последние задаются исключительно политикой безопасности.

Модель безопасности в JDK 1.2

4. Криптографическая архитектура Java

Без криптографии невозможны надежная аутентификация, контроль целостности и сохранение конфиденциальности.

Криптографическая архитектура Java (Java Cryptography Architecture, JCA) разработана для предоставления следующих сервисов:

· постановка/проверка электронной подписи;

· вычисление хэш-функции;

· генерация пар ключей открытый/секретный;

· создание сертификатов, подтверждающих аутентичность открытых ключей;

· хранение ключей, а также сертификатов надежных партнеров;

· преобразование ключей из представления со скрытой структурой в общепонятное представление и наоборот;

· генерация параметров криптографических алгоритмов;

· генерация (псевдо)случайных чисел;

· симметричное шифрование;

· выработка общего ключевого материала.

Кроме того, криптографическая архитектура должна удовлетворять следующим технологическим требованиям:

· обеспечивать независимость от алгоритмов и их реализаций;

· обеспечивать взаимную совместимость реализаций;

· обеспечивать расширяемость набора алгоритмов и их реализаций.

Каждый сервис может обеспечиваться несколькими алгоритмами, каждый из которых, в свою очередь, может иметь несколько реализаций. Например, для вычисления хэш-функции предназначены алгоритмы MD5/SHA-1 (равно как и российский ГОСТ «Функция хэширования»), для выработки и проверки электронной подписи — алгоритмы RSA/DSA, российский ГОСТ «Процедуры выработки и проверки электронной цифровой подписи» и т. д.

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

Два последних элемента в списке сервисов (симметричное шифрование и выработка общего ключевого материала) подвержены экспортным ограничениям США, поэтому они, в отличие от остальных перечисленных сервисов, оформлены как расширение (Java Cryptography Extension, JCE), являющееся отдельным продуктом.

Иерархия криптографических сервисов, алгоритмов и реализаций

5. Объектная организация механизмов безопасности

java аплет защита криптографический Механизмы безопасности в JDK 1.2 оформлены в виде четырех основных пакетов и трех пакетов расширения. Вот некоторые из них

· java.security — содержит интерфейсы и классы, составляющие каркас механизмов безопасности. Сюда входят рассмотренные выше средства разграничения доступа, а также криптографические средства, такие как выработка электронной подписи, вычисление хэш-функции и т. п.

· java.security.interfaces — средства генерации RSAи DSA-ключей.

· javax.crypto — интерфейс и классы для симметричного шифрования.

Наиболее важные с концептуальной точки зрения интерфейсы и классы сосредоточены в пакете java.security.

Политика безопасности

Политика безопасности в устанавливает соответствие между источниками программ и их правами доступа. В Java-машине в каждый момент времени она представлена одним объектом класса, являющегося преемником абстрактного класса Policy. Методы класса Policy позволяют получить/установить текущую политику, а также выяснить права доступа, ассоциированные с заданным источником программ.

Проверка прав доступа

Для контроля прав доступа можно пользоваться двумя средствами:

· встроенным менеджером безопасности, получившим название AccessController;

· динамически изменяемым менеджером безопасности — SecurityManager.

Класс AccessController предоставляет единый метод для проверки заданного права в текущем контексте — checkPermission.

Криптографические интерфейсы и классы

Объектная организация криптографической подсистемы Java естественным образом отражает описанную выше криптографическую. Каждому сервису соответствует абстрактный класс, описывающий его (сервиса) программный интерфейс, а также класс, описывающий программный интерфейс поставщика сервиса. Важными являются классы Provider и Security. В первом собраны общие методы поставщиков криптографических услуг, во втором — методы управления поставщиками и параметрами алгоритмов.

Список используемой литературы

1. http://www.jetinfo.ru/1998/11−12/1/article1.11−12.19 981 237.html

2. http://vestnik.sci.pfu.edu.ru/archiv-cs/articles-cs/2004;3−1/pdf/kulyabov-2004.pdf

3. http://ru.wikipedia.org/wiki/Java

4. http://infocity.kiev.ua/hack/content/hack081.phtml

5. http://citforum.uar.net/security/web/java_seq.shtml

6. http://www.htc-cs.ru/press/tribune/java.html

7. http://www.ccc.ru/magazine/depot/00₁₁/print.html?web3.htm