Рекомендации по разработке распределенных информационных систем с учетом реально сложившейся архитектуры обеспечения безопасности в Интернет

Автор: Кравченко Д.В.,
Институт проблем информатики РАН,
dmitry@ipi.ac.ru

Введение

Данный методический материал содержит информацию о шифровании, о сертификатах, а также информацию об архитектуре обеспечения безопасности, необходимую для построения ИС, которая предназначается для работы в Интернет, и которая реализована в соответствии с архитектурой CORBA 2.0, и которая использует апплеты, работающие в браузерах, поддерживающих Java. Данная бумага затрагивает следующие вопросы: Следует заметить, что в данной бумаге не проводится детального и подробного рассмотрения различных архитектур обеспечения безопасности информации, а также алгоритмов шифрования. Здесь просто описывается ситуация, сложившаяся в настоящее время, касающаяся апплетов, браузеров, а также указываются конкретные шаги, показывающие как работать с различными ограничениями, которые налагаются из-за соображений безопасности на апплеты, и которые существенно сужают сферу их применения в качестве полноценных компонентов распределенных ИС.

Безопасность в Интернет

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

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

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

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

Криптография, основанная на открытом ключе

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

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

Открытые и закрытые ключи

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

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

Использование ключей для шифрования информации

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

Замечание: зашифрованное ключом нельзя расшифровать при помощи этого же ключа (эта особенность важна именно для открытого ключа).

RSA-ключи

RSA - наиболее широко используемый криптографический алгоритм. Разработанный RSA Laboratories, этот алгоритм предоставляет методы для шифрованния данных с использованием открытого и закрытого ключей. RSA специфицирован в стандарте с названием PKCS-1, информация о котором доступна в http://www.rsa.com.

Длина ключей и безопасность

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

Использование пар ключей для аутентификации

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

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

Цифровая подпись

Метод цифровой подписи обеспечивает проверку того, что: именно определенный человек послал данной сообщение данной сообщение не было подменено или изменено

Нижеописанная процедура объясняет как генерируется и используется цифровая подпись:

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

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

Если сообщение было модифицировано при передаче, то MDA сгенерирует для него дайджест, отличающийся от расшифрованного, пришедшего вместе с сообщением.

Алгоритмы создания дайджеста из сообщения

Как известно, хэш-функция - это арифметическая функция, которая вычисляет хэш-значение фиксированной длины, используя в качестве входа данные переменной длины. При генерации цифровой подписи, к сообщению применяется хэш-функция, которая возвращает хэш-значение, назавающееся дайджестом. Хэш-функции, использующиеся для генерации дайджестов, которые бестрее и легче шифровать, чем сообщения, называются message-digest algorithms(MDA). Наиболее часто используются следующие два MDA:

Сертификаты

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

Что такое сертификат?

Сертификат - это цифровой документ, который удостоверяет что данный ключ принадлежит данному человеку, данной организации или данному серверу. Сертификаты выпускаются т.н. certificate authorities(далее СA). CA ответственны за принадлежность ключа личности или организации.

В качестве CA служат фирмы, специализирующиеся на компьютерной безопасности, например VeriSign, или, используя специальные продукты, например Netscape Certificate Server, любая организация может функционировать в качестве CA.

Что содержится в сертификате

Формат сертификата определен в стандарте X.509, в соответствии с которым сертификат содержит информацию о лице и о CA, выпустившем данный сертификат.

Сертификат состоит из двух частей: данные о лице и о CA, и подпись (сигнатура) CA. Более подробно, данные несут следующую информацию:

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

Действительность сертификата

Сертификат действителен, если выполнены следующие условия: срок действия сертификата еще не истек; владелец еще имеет право использовать данный ключ, CA ответственны за отзыв сертификат при определенных обстоятельствах.

Использование сертификата

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

Доверенные источники (CA) и сертификаты

Сертификаты сами подлежат проверке. Пользователи Netscape Navigator имеют возможность указать каким CA они доверяют для генерации сертификатов. Например, когда Netscape Navigator получает сертификат, выпущенный CA, которому пользователь не доверяет, то данный сертификат не принимается.

На приведенном ниже рисунке изображено окно Security Info браузера Netscape Communicator 4.0, в котором показан список принимаемых CA-сертификатов.

Цепи сертификатов

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

Пример иерархии CA.

Цепь сертификатов состоит из сертификата, заверяющего его сертификата CA, далее сертификата CA, заверяющего предпоследний сертификат CA, и так далее. Цепь сертификатов завершается сертификатом корневого CA.

В цепи сертификатов должны соблюдаться следующие условия:

Замечание: необязательно, чтобы пользователь доверял промежуточным сертификатам CA, лишь бы цепь вела к сертификату, которому пользовтель доверяет.

"Подписанные" объекты (signed objects)

Communicator и другие продукты Netscape поддерживают множество технологий и средств под названием Object Signing, которые используют описанную выше модель обеспечения безопасности, которая дает пользователю достоверную информацию о коде, который он загружает из Интернет на свой компьютер.

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

Как пользователь может контролировать действия апплета

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

Контроль над доступом для пользователя

Когда исполняющийся "подписанный" апплет запрашивает разрешение на доступ к какому-либо ресурсу локальной системы, браузер проверяет был ли уже разрешен данный вид доступа для данного "подписчика" (автора апплета). Если был разрешен, то браузер позволяет апплету выполнить соответствующие действия, не спрашивая у пользователя. Если же "подписчику" не была дана подобная привилегия, браузер создает диалоговое окно Java Security, наподобие изображенному ниже, посредством которого пользователь может принять решение по наделению "подписчика" определенной привилегией.

Окно, с помощью которого пользователь может контролировать апплет

Для того, чтобы подписать апплет, нужно выполнить определенную последовательность действий.

Получение сертификата

Перед тем как подписывать апплет, нужно получить сертификат специально предназначенный для этой цели. Получить сертификт можно из двух источников: В браузер также должен быть инсталлирован CA-сертификат того CA, который сгенерировал данный сертификат для Object Signing. В Communicator 4.0 уже предварительно инсталлированы несколько CA-сертификатов от наиболее известных фирм-CA. Дополнительно можно инсталлировать CA-сертификат при соединении с Certificate Server'ом, выбрав соответствующий пункт в списке комманд, предоставляемых сертификационным сервером.

Средство для создания цифровой подписи

Netscape предоставляет средство для подписи апплетов под названием Zigbert. Zigbert - это программное средство, доступное в Windows 95/NT, в Solaris и в IRIX, предназначенное для использования разработчиками, распространяющими программное обеспечение по Интернет. С помощью Zigbert можно поместить множество файлов апплета в JAR-файл в сжатом виде, а также снабдить этот файл цифровой подписью.

Перед тем как "подписать" апплет, разработчик должен инсталлировать свой сертификат, а также сертификат того CA, который выдал ему сертификат. Пользователю, который намеревается загрузить апплет, необходим только CA-сертификат. Список CA-сертификатов можно найти в окне Security Info (Certificate|Signers).

Ниже описана процедура по созданию "подписанного" апплет.

  1. Создайте пустой каталог.

  2. Поместите все файла апплета в созданный каталог.

  3. Запустите zigbert с соответствующими аргументами: 
    zigbert -k имя-сертификата каталог1 -d каталог2
 каталог1 - каталог, где находятся файла апплета
 каталог2 - каталог, где находятся
	локальная база данных браузера,
	в UNIX это обычно ~/.netscape,
	в Windows 95/NT - Netscape installation directory\Users\user name
    Во время исполнения zigbert запросит пароль к закрытому ключу пользователя, который задается при инсталляции сертификата.

  4. Зайдите в каталог и создайте JAR-файл, например при помощи утилиты zip. 
    
zip -r9 ../testjar.jar *
  adding: META-INF/ (stored 0%)
  adding: META-INF/manifest.mf (stored 0%)
  adding: META-INF/zigbert.sf (stored 0%)
  adding: META-INF/zigbert.rsa (stored 0%)
  ...

  5. Проверьте целостность созданного архива: 
    
zigbert -v testjar.jar

Как расширить возможности апплета

До появления технологии Object Signing возможности апплета по доступу к ресурсам локальной системы были сильно ограничены, что сильно сужало область применения Java-апплетов. Для того, чтобы предоставить апплетам необходимые возможности, избегая в то же время риска, Netscape расширил модель безопасности Java посредством множества Java-классов под названием Java Capabilities API.

Цели, principals и привилегии

В модели Java Capabilities словом principal обозначается субъект, которому предоставляется доступ, цель (target) обозначает какое-либо действие, разрешение на которое нужно получить, а под привилегиями, ассоциированнными с principal, понимается множество разрешений или запретов по доступу к определенной цели. В Java Capabilities API principal, представленный в виде объекта класса Principal, обычно обозначает сертификат. Цель представлена объектом класса Target.

Как исполняется "подписаный" апплет

Допустим, что пользователь открывает в браузере страницу, содержащую "подписаный" апплет, тогда браузер загружает JAR-архив, содержащий классы апплета и другие, вспомогательные файлы. Далее браузер проверяет цифровую подпись, хранящуюся в архиве в виде файла, для того чтобы узнать чей сертификат использовался для подписи, а также удостоверяется в том, что содержимое архива не изменилось при передаче. Если эти операции завершились успешно, то апплет запускается на исполнение, во время которого апплет может запрашивать привилегии на выполнение того или иного действия при помощи статических методов класса PrivilegeManager, входящего в Java Capabilities. Браузер ассоциирует каждого principal со списком разрешенных или запрещенных привилегий. Допустим, апплет запрашивает разрешение на удаление файлов на пользовательской машине: 
PrivilegeManager.enablePrivilege("UniversalFileDelete");
Если апплет уже запрашивал подобную привилегию, то браузер не спрашивает повторно у пользователя, иначе браузер создает диалоговое окно, описанное выше, и пользователю предоставляется право принять решение: запретить или разрешить. В зависимости от решения пользователя метод enablePrivilege или просто завершается или возбуждает исключительную ситуацию класса ForbiddenTargetException (подтип SecurityException). Если код апплета, содержащий подлежащие контролю действия, не предваряется запросом на получение разрешения, то соответствующие методы просто возбуждают SecurityException.

Полезные ссылки

Криптография

Ресурсы Object-Signing в DevEdge

Другие ресурсы Netscape

Страница JavaSoft, относящаяся к Object Signing: