|
ПРИМЕНЕНИЕ КЛАССОВ JAVA В LOTUS SCRIPT
текст: Рафаэл Осипов
Вступление
Целью данной статьи служит описание возможностей совместного использования классов Java в LotusScript. В качестве платформы разработки рассматривается IBM Lotus Notes Client версии 7.0.
Приложения для платформы Lotus Notes можно создавать как с применением Lotus Script, так и с применением Java. Возможности Java, представленные в Lotus Notes Client 7.0, довольно широки (используется виртуальная машина Java версии 1.4.2), но имеют свои границы, как и Lotus Script.
У Java и Lotus Script есть свои сильные и слабые стороны при создании приложений для Lotus Notes. Задачей разработчика является максимально эффективное использование сильных сторон этих технологий и минимизация воздействия отрицательных факторов.
Технология LotusScript To Java (LS2J) даёт возможность использования классов Java из кода LotusScript.
На первый взгляд эта возможность кажется излишней. Ведь есть возможность взаимодействия разнородных блоков кода с помощью профайлов (profiles) и переменных окружения notes.ini.
Это не всегда удобно и оправдано. В данной статье приводится пример приложения, которое использует функциональность Java в части шифрования и цифровой подписи. В LotusScript подобная функциональность не представлена. И реализация её с нуля не представляется мне простой задачей.
Есть ещё один аспект. Будучи скомпилированными, LotusScript и Java хранятся по-разному. Java хранится в агентах и библиотеках как прикрёплённый файл со скомпилированным кодом. Объектный код LotusScript хранится как байтовый массив данных в полях специального типа.
При желании можно извлечь jar-файл из тела агента или библиотеки, распаковать его и, используя свободно распространяемые утилиты (например, JAD), получить из скомпилированного кода исходные тексты. В Lotus Notes не происходит оптимизация и/или скрытие логики (obfuscation) при компиляции java-кода. Поэтому при декомпиляции файлов можно получить полностью идентичный код со всеми именами классов, методов и полей. Злоумышленник может сформировать свои элементы дизайна, используя полученный java-код и заменить их в вашем приложении, чтобы добиться нужного ему результата.
На сегодняшний день мне не известно о существовании программного обеспечения для декомпиляции объектного кода для LotusScript.
По этой причине я полагаю использование LS2J предпочтительным в случаях, когда необходимо использовать функциональность Java, но, в то же время, максимально усложнить задачу по анализу исходного кода приложения.
Использование механизмов создания и проверки электронной подписи в приложениях Lotus Notes
В этой статье приводится пример приложения, которое создаёт, а затем проверяет электронную подпись к документу Notes.
Использование Java в данном случае обусловлено желанием программно обрабатывать ситуации, когда содержимое документа не соответствует цифровой подписи. При использовании стандартных механизмов Lotus Notes для работы с цифровой подписью такой возможности нет. Пользователь лишь видит в строке статуса системное сообщение о том, что содержимое документа не соответствует цифровой подписи. Это приемлемо в случаях, когда пользователю надо получить визуальный сигнал о том, что содержимому документа не стоит доверять. Но в случаях, когда нарушение цифровой подписи должно влиять на логику выполнения программы, этот механизм не помогает.
Реализуем этот механизм, используя библиотеку классов Java. Сначала совсем немного теории.
Цифровая подпись работает по следующему принципу.
Для блока текста генерируется уникальная цифровая последовательность (дайджест). Затем к дайджесту применяется шифрование с открытым ключом. Дайджест шифруется секретной частью ключа.
Для проверки целостности текста делается следующее:
Для проверяемого текста генерируется дайджест.
Затем происходит попытка расшифровать цифровую подпись (зашифрованный дайджест).
Происходит сравнение расшифрованного дайджеста и дайджеста полученного из текста. Если текст не был изменён с момента его подписания, то расшифрованный дайджест, и дайджест, составленный из текста в момент проверки подписи, будут идентичны.
|
Тип элемента
|
Имя
|
Описание
|
|
Form
|
License
|
Пример формы для отображения документа, который будет подписан цифровой подписью.
|
|
View
|
($All)
|
Показывает список документов и содержит кнопки для подписания документа и проверки цифровой подписи
|
|
View
|
(License)
|
Показывает документ, который будет подписан, и который будет проверяться.
|
|
Agent
|
(Sign)
|
Подписывает документ
|
|
Script Library
|
SignatureProcessing.lib
|
Содержит функции для проверки цифровой подписи. Главная функция: isLicenseCorrect
|
В библиотеке SignatureProcessing.lib и в агенте aa_Sign функция (метод) getDocumentText() отвечает за формирование текстового блока, который будет подписываться и впоследствии проверяться. В случае внесения изменений в агент, следует соответствующим образом поменять логику работы этой функции и в библиотеке.
При использовании в реальных приложениях рекомендуется весь код из библиотеки SignatureProcessing.lib поместить внутрь другой библиотеки, в которой будет много другого часто используемого кода. В таком случае вы серьёзно осложните задачу хакеру.
Если библиотека с кодом проверки цифровой подписи будет существовать в системе отдельно от других, то хакеру будет легче подменить её на модифицированную библиотеку, функции в которой всегда возвращают нужное значение.
Код агента для подписания лицензии секретным ключом написан на Java. Вы можете его переписать на LotusScript с использованием LS2J.
Ключевым фактором защиты в примере, доступном для скачивания, является то, что хакеру будет неизвестен механизм формирования текстового блока для подписания.
Иначе – он может написать свой код, который сгенерирует цифровую подпись и заменит публичный ключ и подпись в теле документа.
Одним из способов, которым можно усложнить задачу хакеру, это «зашить» публичный ключ в код проверки цифровой подписи, вместо того, чтобы хранить его в документе.
Описание примера приложения, доступного для скачивания
Допустим, вы написали некое сложное и дорогостоящее приложение на Lotus Notes и намерены его распространять на коммерческой основе, говоря иначе – продавать.
Приложение на Lotus Notes – это, как правило, набор файлов с расширением *.nsf, из которых исключена информация об исходных кодах.
А что, если покупатель вашей программы даст скопировать приложение ещё кому-то?
Да, можно использовать серийные номера, которые указываются при инсталляции приложения. Но при передаче приложения третьей стороне также могут быть переданы и они.
Для защиты приложения от несанкционированного использования, будем использовать следующий подход:
Вместе с приложением пользователю передаётся электронный документ, в котором мы записываем название компании, которая купила это приложение и, к примеру, количество лицензий (рабочих мест). Эта информация подписывается секретным ключом, который есть только у нас. В электронном документе лицензии, который передаётся пользователю, хранится только открытый ключ и электронная подпись.
И при осуществлении тех или иных действий, регламентируемых лицензией, приложение будет проверять целостность цифровой подписи к лицензии и возможность осуществления той или иной операции.
При печати документов из системы «в шапке» документов будет использоваться информация из лицензии. Например, название компании. Это сильно снижает привлекательность несанкционированного использования системы.
Тут следует сделать небольшое отступление и сказать, что в наши задачи не входит написание непробиваемой защиты. Критерием хорошей защиты является себестоимость её взлома. Себестоимость взлома хорошей защиты выше продажной цены приложения.
Вы можете скачать базу данных, в которой реализованы механизмы создания и проверки цифровой подписи.
При открытии скачанной базы данных вы увидите представление с одним документом и двумя кнопками вверху "Подписать" и "Проверить".
Нажав на кнопку “Подписать”, вы подпишете документ. А нажатие на кнопку “Проверить” выполнит функцию проверки цифровой подписи.
|