Генератор лицензий приложений

Я разрабатываю приложение для OSX, используя XCode и Objective C (Cocoa), и мне нужна система для генерации лицензий для каждого проданного приложения.

Система должна

  • генерировать серийный номер без истечения срока действия
  • генерировать серийный номер, который истекает (для пробных версий)
  • черный список чернил
  • содержит API для ввода и проверки номера лицензии из приложения OSX.

Есть ли что-то для этого или я должен сам реализовать его?

Ответ 1

Я бы реализовал это одним из трех способов, в зависимости от того, насколько я параноик.

Язык, который вы используете, не имеет значения.

Способ 1: лицензии, подписанные RSA

Это метод, который вы используете, если вы параноик о ком-то обратном проектировании вашего генератора лицензий. Вы создаете пару ключей RSA и объединяете открытый ключ с приложением. Каждый номер лицензии подписывается с использованием закрытого ключа, и приложение проверяет подпись с использованием открытого ключа. Поскольку вы единственный, у кого есть закрытый ключ, существует почти нулевая опасность того, что кто-то сможет создать генератор лицензий для вашего приложения.

Недостатки: лицензионные ключи очень длинные, возможно, не менее 200 символов (четыре строки текста). Пользователи не захотят вводить их, они должны будут скопировать и вставить.

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

Способ 2: лицензии, подписанные HMAC

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

Недостатки: возможен генератор лицензий.

Преимущества: короткие клавиши. Вы можете использовать усеченные HMAC; 64-битная подпись может быть "достаточно хороша" и будет содержать только 16 символов в базе 16. Нет постоянных затрат.

Метод 3: онлайн-проверка

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

Недостатки: периодическая стоимость сервера. Невозможно зарегистрироваться без подключения к Интернету. Легко для вас обнаружить пиратские клавиши.

Преимущества: короткие клавиши. Нет генераторов лицензий. Отзыв лицензии прост. Потеря продаж тем, кто беспокоится о том, что вы выйдете из бизнеса.

Временные лицензии

Временные лицензии могут быть выполнены тремя способами.

  • Интернет

  • Дата истечения срока подписки

  • Подписанный срок действия лицензии

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

Черные

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

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

Кодировка

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

Анатомия лицензионного ключа

Вот пример схемы для автономного лицензионного ключа с использованием HMAC:

AAXX-XXXX-YYYY-ZZZZ-ZZZZ-ZZZZ-ZZZZ
  • AA: имя продукта, сокращенное до двух букв
  • XXXXXX: nonce
  • YYYY: дата истечения срока действия, количество дней с 1 января 2013 года или 0 для неограниченного
  • ZZZZZZZZZZZZZZZZ: подпись первой части ключа

Для ключей RSA часть ZZZ... будет очень длинной.

При использовании онлайн-ключевого сервера ключ будет ZZZ... и не должен быть очень длинным (12 или 16 символов).

Заметка о растрескивании

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