Функции защиты прикладных блоков

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

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

Числовой идентификатор блока. Число 0 зарезервировано как идентификатор самой платформы.
Различные теги защиты данных и соответствующие им значения. Поддерживается три типа значений:
- целое число;
- короткая строка или слово (16 символов);
- длинная строка или текст (256 символов).

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

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

Регистрация блоков на сервере

Предоставление пользователю прав на использование сетевой версии программы подразумевает продажу определенного количества лицензий – то есть учитывается количество клиентов, которые могут работать с серверной частью. В рамках лицензирования платформы различают лицензирование для локальной сети (максимальное количество клиентов сервера платформы) и для глобальной сети (максимальное количество клиентов прокси-сервера). Счетчик лицензий увеличивается при подключении очередного клиента, который идентифицируется по IP-адресу и имени компьютера, при подключении к серверу на Windows Server IP-адрес и имя компьютера дополняются именем пользователя Windows. Кроме того, возможно лицензирование прикладных блоков, разработанных на базе платформы. Количество лицензий для каждого прикладного блока хранится в базе данных защиты, которая располагается на сервере. Чтобы счетчик лицензий для прикладного блока увеличился при подключении клиента, работающего с этим прикладным блоком, прикладной блок должен зарегистрироваться, то есть "сообщить о себе" серверной части. Для этого во внутреннем языке объявлена функция КЗ_РЕГИСТРАЦИЯ_БЛОКА. Функция посылает серверу числовой идентификатор блока, в ответ на это сервер регистрирует блок, то есть увеличивает счетчик лицензий для этого прикладного блока на единицу. Если информация о регистрации этого же блока приходит с другого клиентского места – счетчик лицензий увеличивается еще на единицу, и т.д. Если максимальное количество лицензий для блока достигнуто – следующему клиенту будет отказано в подключении. При отключении клиента от сервера ресурс освобождается. Регистрация прикладного блока происходит в контексте клиентского места, то есть повторный вызов функции КЗ_РЕГИСТРАЦИЯ_БЛОКА с одного и того же клиента не увеличивает счетчик лицензий. При этом нужно отметить следующее: поскольку асинхронный вызов алгоритма – это создание отдельного потока подключения, то единственный вызов функции КЗ_РЕГИСТРАЦИЯ_БЛОКА в этом потоке приведет к освобождению лицензии, когда работа алгоритма завершится. Соответственно, многократный вызов функции в различных алгоритмах не является ошибкой, но первый вызов функции рекомендуется производить в потоке, который завершается при завершении работы клиентского места – например, при старте платформы (в обработчике события "Вход").

Получение значений тегов из базы данных защиты

Как было сказано выше, в специальном файле базы данных защиты хранятся числовые идентификаторы блоков и значения различных тегов, определяющие разрешения действий для каждого блока. Например, прикладной блок может содержать бланки, но часть этих бланков должна быть доступна только в случае, если пользователь оплатил обновление. Тогда в базе данных защиты может быть соответствующий тег, а в тексте прикладной программы анализируется значение этого тега: если одно значение – код бланка выполняется, если другое – не выполняется. Структура базы данных защиты формируется с помощью специальных средств. Прикладным программистам предоставляются необходимые теги и их возможные значения. Прикладной программист должен получать значения тегов из базы данных защиты и в соответствии с полученными значениями определять разрешения действий в прикладной программе. Для получения значений тегов объявлены три функции (в соответствии с возможными типами значений):

КЗ_СЧИТАТЬ_ЧИСЛО	–	получение значения типа "целое число";
КЗ_СЧИТАТЬ_СЛОВО	–	получение значения типа "короткая строка";
КЗ_СЧИТАТЬ_ТЕКСТ	–	получение значения типа "длинная строка".

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

Функция проверки ключа

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

Прикладному программисту предоставляется числовой идентификатор алгоритма генерации вопросов и ответов в электронном ключе и сама таблица вопросов и ответов. Обращение к алгоритму осуществляется с помощью функции внутреннего языка КЗ_ПРОВЕРКА, которая в ответ на строку вопроса возвращает строку ответа, а если ответ не найден – пустую строку. Эта функция должна периодически вызываться в тексте прикладной программы в качестве условия выполнения какой-то части прикладного кода: если на определенную строку вопроса получена правильная строка ответа – выполняются какие-то действия, иначе – действия не выполняются. Однако при таком подходе существует опасность, что если злоумышленнику станет доступен исходный код программы, он сможет восстановить по нему всю таблицу вопросов и ответов. Поэтому, чтобы усложнить ему эту задачу, рекомендуется периодически вставлять в исходный код "ложные" вызовы функции КЗ_ПРОВЕРКА, которые посылают несуществующую строку вопроса и "делают вид", что в зависимости от полученного результата изменяются какие-то условия, однако на реальные данные это влияния не оказывает.

Функции защиты в исходном тексте

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

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

Для сокрытия части исходных текстов с сохранение возможности перекомпиляции используются закрытые библиотеки.

Перечень функций:

КЗ_РЕГИСТРАЦИЯ_БЛОКА	–	служит для регистрации прикладных блоков серверной частью платформы.
КЗ_ПРОВЕРКА	–	реализует проверку легальности используемой версии с помощью механизма вопросов и ответов.
КЗ_СЧИТАТЬ_ЧИСЛО	–	позволяет получить из базы данных защиты значение тега типа "целое число".
КЗ_СЧИТАТЬ_СЛОВО	–	позволяет получить из базы данных значение тега типа "короткая строка" (не более 16 символов).
КЗ_СЧИТАТЬ_ТЕКСТ	–	позволяет получить из базы данных защиты значение тега типа "длинная строка" (не более 256 символов).
КЗ_КЛЮЧ_ФАЙЛ	–	позволяет получить путь к текущему ключевому файлу.