Использование jar-подписи как своего рода лицензионного ключа - PullRequest
Новая
       26

Использование jar-подписи как своего рода лицензионного ключа

1 голос
/ 15 апреля 2011

В связи с этим вопросом, могу ли / должен ли я использовать подпись jar для создания jar-файла защиты от несанкционированного доступа с информацией, встроенной для обеспечения выполнения во время выполнения числа пользователей, которым разрешено использовать приложение? Моя идея такова:

  1. Создать банку с одним классом, содержащим статическое поле с нужным количеством пользователей
  2. Подпишите банку и поместите в папку Grails war lib, указав путь к классам
  3. (Предположение, это правильно?) Я могу получить доступ к статическому полю в классе в файле jar со знаком из моего приложения grails, зная, что этот файл не был подделан (иначе исключение будет брошен), а также без какой-либо дополнительной работы, необходимой, например, "принятие" подписи.

Верно ли мое предположение шага 3? Это хороший подход к тому, что я пытаюсь сделать? Если нет, то какова стандартная практика?

Спасибо!

Ответы [ 2 ]

4 голосов
/ 15 апреля 2011

Это только «доказательство взлома», если пользователь должен запустить его в какой-либо среде, которая настаивает на том, что подпись присутствует и функционирует.Если вы передаете банку обычному человеку, который может запустить его в обычной JVM (не в виде апплета, не в виде веб-запуска), он может полностью удалить подпись.Если вы хотите попытаться остановить это, вам придется написать код для вызова Class.getSigners и взорваться, если вы не видели себя.Таким образом, им нужно запустить asm, чтобы написать этот чек на существование, и они будут хороши.

Подписание Java-кода позволяет некоторому контейнеру проверить, что файл JAR поддерживает целостность из своего источника.,Он не дает вам возможности создать защищенный от несанкционированного использования пакет.

2 голосов
/ 15 апреля 2011

Простая подпись JAR не будет работать. Подписание JAR - это все о клиенте, который доверяет вашему файлу JAR. Это не мешает клиенту создавать новый JAR из содержимого вашего JAR (с настройками) и запускать его как неподписанный JAR.

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

Обычный способ введения ограничений на одновременных пользователей - это внедрение отдельного менеджера лицензий / системы лицензионных ключей; например FlexLM. (И, конечно, это тоже можно победить, настроив свои классы, чтобы пропустить проверку лицензии.)

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

...