Защита программного обеспечения на основе usb flash drive и программных ключей

 Зотин А.Г.,

 Дамов М. В.,

ФГБОУ ВПО «Сибирский государственный аэрокосмический университет имени академика М.Ф Решетнева»,

г. Красноярск

 

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

 

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

 

– ограниченное количество запусков программы;

 

– ограниченные возможности по использованию части функций;

 

– ограничение функционала после выполнения ряда условий.

 

Для реализации защиты возможно использование следующих технологий: серийный номер, файловый ключ,  интернет-активация с учётом конфигурации компьютера, HASP-ключ (Hardware Against Software Piracy). Они могут применять по отдельности в простых случаях или в различных сочетаниях для реализации более сложных вариантов защиты.

 

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

 

Защита HASP включает в себя:

 

– электронный ключ HASP;

 

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

 

– схемы и методы защиты программ и данных, обнаружения и борьбы с отладчиками, контроля целостности программного кода и данных.

 

Основой большинства электронных ключей обычно является заказной чип с уникальным ПО. Аппаратные ключи можно классифицировать по нескольким признакам: интерфейсам подключения, открытости API ключа, поддерживаемым операционным системам и т.п. Принцип защиты заключается в том, что в процессе запуска программа опрашивает ключ, подключенный к компьютеру по определенному интерфейсу. В случае если ключ отвечает “правильно”, то программа функционирует в нормальном режиме. В противном случае, она блокирует доступ к определенным функциям или просто не запускается. Таким образом, любая защищаемая программа состоит непосредственно из самой программы и механизмов проверки ключа. Задача этих механизмов: проверить наличие ключа, получить его уникальный идентификатор и прочитать содержимое встроенной памяти.

 

Несмотря на простоту организации защиты HASP для разработчиков может встать вопрос о цене защиты, поскольку стоимость одного ключа в зависимости от его характеристик может быть в диапазоне от менее одной тысячи рублей до ста тысяч рублей и более [2]. Таким образом, при разработке и защите программного обеспечения со стоимостью меньше стоимости ключа становится не выгодным его применение.

 

Поскольку метод защиты HASP основан на привязке программы к некоторому параметру или совокупности уникальных параметров ключа и оборудования, то, используя USB FLASH DRIVE, мы можем достичь сходного эффекта при меньших денежных вложениях, так как USB FLASH DRIVE обладает серийным номером и ID которые не меняются при его форматировании.

 

Для реализации системы защиты на основе USB FLASH DRIVE необходимо получение информации об устройстве. В средах Windows XP/Vista/Seven информацию об устройствах предоставляет стандартная системная библиотека SetupApi.dll. Для реализации защиты понадобятся функции SetupDiGetClassDevsA, SetupDiEnumDeviceInfo, SetupDiDestroyDeviceInfoList, CM_Get_Device_ID_Size, CM_Get_Device_IDA, предоставляемые этой библиотекой [3].

 

Используя перечисленные функции можно получить ID и серийный номер USB FLASH DRIVE, выполнив следующие этапы:

 

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

 

Этап 2. Обработка данных каждого элемента из набора, полученного на этапе 1. При помощи функции SetupDiEnumDeviceInfo получаем информацию об элементе набора, после чего производим анализ идентификатора устройства, полученного на основе информации об элементе набора, является ли устройство USB-устройством. Для выполнения такой проверки вначале при помощи функции CM_Get_Device_ID_Size получаем размер строки идентификатора устройства, а затем непосредственно саму строку идентификатора воспользовавшись функцией CM_Get_Device_ID. В полученной строке идентификатора проверяем наличие фрагмента USBSTOR, и, если он присутствует, то данное устройство является USB FLASH DRIVE, то выполняется третий этап.

 

Этап 3. Получение ID и серийного номера устройства из строки идентификатора.

 

Этап 4. Вызов функции SetupDiDestroyDeviceInfoList для корректного завершения процесса получения информации об устройствах и освобождения занимаемых ресурсов.

 

Используя ID устройства и серийный номер, можно организовать в программе проверку по таймеру на наличие подключения соответствующего USB FLASH DRIVE и проверять события подключения и отключения устройства таким образом организовать простую защиту для собственных распространяемых мелкосерийно программ.

 

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

 

В качестве решения возможно использование парных файлов, которые будут подвергаться кодированию. Для большей надежности целесообразно организовать состав каждого из файлов состоит из двух блоков: контрольный блок, служебный блок. В контрольном блоке записывается информация о размере служебного блока, его md5-хэш-код, фрагмент ключа и другая служебная информация. Причем организовать запись можно следующим образом: В начале контрольный и служебный блоки заполняются произвольными символами. После чего в служебный блок в соответствии с выбранным алгоритмом записи записывается информация в содержащая данные: о ключе, ID устройства и серийный номер USB FLASH DRIVE, имя организации для которой сформирован ключ, тип лицензии, а также структура с описанием накладываемых ограничений на функционал с учетом двух режимов работы – со вставленным USB FLASH DRIVE или без него. Информация, размещаемая в служебном блоке, подвергается кодированию одним из возможных алгоритмов. После кодирования полученная последовательность данных согласно алгоритму записи интегрируется в соответствующие области памяти служебного блока. Затем формируется структура с информацией, которая в виде кода BASE64 и в соответствии с алгоритмом записи интегрируется в области контрольного блока. В программе следует использовать разные алгоритмы размещения информации в зависимости от кода, для чего целесообразно на ключевой файл выделять не менее 4 кб памяти. При организации защиты по времени действия в демонстрационном режиме или при отсутствии ключа, необходимо хранить информации о времени последнего запуска и завершения работы программы а также начальную дату, для повышения надежности шифрования, возможно использовать временную метку (разница между текущим временем и временем создания исполняемого файла) как параметр сдвига при организации алгоритма интеграции зашифрованных данных в служебные блоки файлов.

 

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

 

Стандарт шифрования данных DES (Data Encryption Standard) К достоинствам DES можно отнести простоту ключевой системы, высокую скорость аппаратной и программной реализации, достаточно высокую криптографическую стойкость алгоритма шифрования при заданной длине ключа. Алгоритм DES осуществляет шифрование 64-битовых блоков данных с помощью 56-битового ключа k. Процесс шифрования состоит в начальной перестановке битов входного блока, шестнадцати циклах шифрования и, наконец, конечной перестановке битов. Отметим, что все перестановки и коды подобраны разработчиками таким образом, чтобы максимально затруднить процесс вскрытия шифра путем подбора ключа, и являются обязательными для использования при реализации алгоритма DES в неизменном виде [4]. 

 

Алгоритм Blowfish разработан в качестве замены алгоритму DES. В настоящее время он широко распространен и имеет множество реализаций, в т.ч. аппаратных. Алгоритм также осуществляет шифрование 64-битовых блоков данных с переменной длиной ключа от 32 до 448 битов. К основным недостаткам можно отнести высокие требования к оперативной памяти и невозможность частой смены ключей, а также невозможность расширения ключа параллельно процессу шифрования и небольшой размер шифруемого блока. К основным достоинствам алгоритма Blowfish относится высокая скорость шифрования, простота алгоритма для реализации и отсутствие известных успешных атак на полнораундовую версию алгоритма [4].

 

Алгоритм RC2 разработан фирмой Lotus и Агентством национальной безопасности США и является основным и обязательным для реализации алгоритмов шифрования согласно стандарту защиты сообщений электронной почты S/MIME [4]. Алгоритм RC2 шифрует данные блоками по 64 бита с использованием ключей от 8 до 1024 бита. Алгоритм не подвержен атаке методом линейного криптоанализа, но может быть теоритически вскрыт методом дифференциального криптоанализа или атакой на связанных ключах, однако такие атаки практически не реализуемы на практике [4].

 

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

 

Предложенные методы организации защиты позволят организовать защиту программного обеспечения на основе USB FLASH DRIVE и вспомогательных программных ключей. Для повышения надежности защиты на USB FLASH DRIVE размещаются несколько служебных зашифрованных файлов с информацией о параметрах ограничений защищаемого  ПО. Такая реализация будет значительно дешевле чем использование электронных ключе HASP и в тоже самое время позволит обеспечить приемлемый уровень защиты от квалифицированного пользователя.

 

Библиографический список

  1. Демьяненко С.В., Садовой Н.Н. Программное обеспечение защиты исполняемых файлов электронными ключами // Вестник Донского государственного технического университета. - №S2. – Т.9. – Ростов-на-Дону, 2009, с. 26-30.
  2. Аладдин-РД: Цены и заказ продуктов. [Электронный ресурс] – Электрон. дан. – Режим доступа: http://www.aladdin-rd.ru/buy/
  3. Microsoft Developer Network: Public Device Installation Function. [Электронный ресурс] – Электрон. дан. – Режим доступа: http://msdn.microsoft.com/en-us/library/windows/hardware/ff549791%28v=vs...
  4. Панасенко С. П. Алгоритмы шифрования. Специальный справочник. СПб.: БХВ-Петербург, 2009.

 

Антон (не проверено)
После прочтения у меня возник

После прочтения у меня возник ряд вопросов:
1. Как будет выполняться передача входных значений для регистрации ключа? То есть если Вы защищаете какой-то программный продукт таким методом, то производитель ПО сам выдает флешку? Или каким-то образом ключ будет сгенерирован на клиентской машине и зарегистрирован у производителя и будет привязан к серийному номеру ПО?
2. Файлы с необходимыми данными, которые Вы хотите шифровать будут храниться на флешке. А как Вы хотите решить проблему их случайного или специального удаления конечным пользователем или злоумышленником?

Михаил (не проверено)
По второму вопросу

Удаление служебных файлов с флешки никак не влияет на защищенность ПО. Скорее такое действие будет влиять на возможность доступа к функциям защищаемой программы. программы. Здесь возможны несколько подходов, выбираемых автором программы, например:
1. Главное - наличие флешки. Наличие данных на ней никак не влияет на возможность доступа к ПО.
2. Для доступа необходимы и флешка, и данные, при этом данные могут быть восстановлены с резервной копии на компьютере пользователя, или в личном кабинете клиента на сайте автора.
3. Для доступа необходимы и флешка, и данные, при этом данные могут быть восстановлены в ограниченном числе случаев по запросу, или механизм восстановления может быть не предусмотрен.
Спасибо за вопрос. Думаю, мы рассмотрим этот аспект подробнее в следующих статьях.

Антон (не проверено)
Тогда другой вопрос

Если рассмотреть ситуацию, когда используются и файлы данных и флешка. Что делать если пользователь потерял флешку? В таком случае это вызовет проблемы, если у разработчика/поставщика ПО записаны ключевые данные по потерянной флешке, то либо пользователь остался без лицензии на использование, либо ему надо новую флешку. Вот тут и потенциальная проблема, как быть в случае если разработчик ПО во Владивостоке, а диллер ПО в Москве? Ну а сам пользователь из Казани к примеру.

Михаил (не проверено)
А как в этом случае поступают

А как в этом случае поступают известные разработчики ПО? Насколько мне известно в случае 1С потеря или повреждение ключа без уважительных причин, это проблемы пользователя.
Вообще это уже исключительно организационный момент, и решение вопроса пользователя зависит не от технологии защиты, а от бизнес-процессов производителя и дилера ПО. Тут возможны варианты в диапазоне от "это проблемы пользователя" до "пользователь регистрирует в личном кабинете в качестве ключа новую флешку"
И второй момент. Мы описали технологию защиты для мелкотиражного ПО. Возникающие при этом бизнес-процессы и отношения в случае большого числа продаж ПО оставлены за рамками статьи. Хотя было бы интересно рассмотреть и этот аспект.

Александр (не проверено)
Ответ на коментарий вопрос №1

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

Тема заблокирована