Генератор лицензий приложений [закрыто]
Я разрабатываю приложение для OSX с использованием XCode и Objective C (Cocoa), и мне нужна система для генерации лицензий для каждого проданного приложения.
система
- генерировать серийный номер без истечения срока действия
- создать серийный номер, который истекает (для пробных версий)
- ручка черный список
- содержит API для ввода и проверки номера лицензии из приложения OSX
есть что-нибудь там, чтобы сделать это или я должен реализовать его сам?
1 ответов
Я бы реализовал это одним из трех способов, в зависимости от того, насколько я параноик.
языке, который вы используете, не имеет значения.
метод 1: RSA-подписанные лицензии
это метод, который вы используете, если вы параноик о ком-то обратной инженерии генератора лицензий. Вы создаете пару ключей RSA и связываете открытый ключ с приложением. Каждый номер лицензии подписывается с помощью закрытого ключа, и приложение проверяет подпись с помощью открытый ключ. Поскольку вы единственный с закрытым ключом, существует почти нулевая опасность того, что кто-то сможет сделать генератор лицензий для вашего приложения.
недостатки: лицензионные ключи очень долго, вероятно, не менее 200 символов (четыре строки текста). Пользователи не захотят вводить их, им придется копировать и вставлять.
преимущества: почти нулевой шанс, что кто-нибудь напишет генератор лицензий. Нет повторяющихся затраты.
Метод 2: HMAC-подписанные лицензии
это метод, который вы используете, если вы менее параноик. Лицензии подписываются с помощью HMAC и секретного ключа, а закрытый ключ должен быть в комплекте с приложением. Вы можете запутать его, но он всегда будет возможно для умного человека, чтобы извлечь секретный ключ от вашего приложения.
недостатки: генератор лицензий возможен.
преимущества: короткие ключи. Вы можете выбрать использовать усеченный HMACs; 64-разрядная подпись может быть "достаточно хорошей" и будет только 16 символов в базе 16. Никаких текущих расходов.
Метод 3: Онлайн-проверка
этот метод является параноидальным и удобным, но он требует, чтобы пользователи имели подключение к интернету, и он требует запуска сервера. Каждая лицензия - это просто случайная строка символов. База данных на сервере сопоставляет случайные строки с лицензиями. Когда пользователь регистрирует приложение, он выполняет HTTP запрос на сервер для получения информации о лицензии, соответствующей указанной строке. Сервер отвечает лицензией, подписанной RSA.
недостатки: повторяющаяся стоимость сервера. Невозможно зарегистрироваться без подключения к интернету. Легко для вас, чтобы обнаружить пиратские ключи.
преимущества: короткие ключи. Никаких генераторов лицензий. Отозвать лицензию легко. Потеря продаж для тех, кто беспокоится, что вы выйдете из бизнеса.
временные лицензии
временные лицензии можно получить тремя способами.
онлайн
подписанный срок годности
подпись срок действия лицензии
очевидно, что если вы используете подписанные условия лицензии, то пользователи смогут стереть свои предпочтения, чтобы перезапустить срок лицензии, если они недобросовестны. НЕ попробуйте скрыть информацию о сроке лицензии, где пользователь не найдет ее, это нарушение доверия пользователя, что ваше приложение не будет делать ничего гнусного. Если бы я нашел какое-либо приложение, скрывающее данные на моем компьютере, я бы удалил приложение и отказался покупать что-либо у разработчика, я уверен, что некоторые другие пользователи чувствуют то же самое.
черные
если вы являетесь сервером онлайн-лицензий, это легко - черный список находится на сервере. В противном случае вам придется связать свой черный список с приложением, и он будет обновляться только каждый раз вы выпускаете новую версию.
возникает вопрос о том, следует ли блокировать тех, кто использует пиратские лицензии. На этот вопрос нет очевидного ответа: вы можете подумать, что было бы лучше сразу заблокировать пиратские лицензии, но принятие пиратской лицензии с предупреждающим сообщением на самом деле является возможностью продать новую лицензию.
кодирование
Я уверен, что вы можете придумать свой собственный способ кодирования лицензий. Я видел, как используется база 32, что приятно потому что это трудно неправильно понять (в отличие от базы 64). Я также видел схемы, использующие чередующиеся группы букв и цифр, что приятно, потому что легко запомнить свое место при чтении длинного ключа.
Анатомия лицензионного ключа
вот пример схемы для автономного лицензионного ключа с использованием HMAC:
AAXX-XXXX-YYYY-ZZZZ-ZZZZ-ZZZZ-ZZZZ
-
AA
: название продукта, сокращенное до двух букв -
XXXXXX
: a nonce -
YYYY
: дата срок действия, # дней с 1 января 2013 года, или 0 для unlimited -
ZZZZZZZZZZZZZZZZ
: подпись первой части ключа
для ключей RSA,ZZZ...
часть будет очень долго.
при использовании онлайн-сервера ключей ключ будет просто ZZZ...
и не должен быть очень длинным (12 или 16 символов).
заметка о взломе
это не возможно чтобы предотвратить кто-то от взлома вашего приложения, независимо от того, какую схему вы выберете. Умный инженер может разобрать ваше приложение и отключить проверку лицензирования. Любые методы, которые вы используете, чтобы помешать им, будут только замедлять их, а не останавливать.