Прокомментируйте эту простую схему защиты программного обеспечения

Меня попросили внедрить схему лицензирования для нашего продукта. Это очень дорогие продукты с небольшим количеством клиентов, редко распределенных по всему миру, и в основном каждый из них имеет среду разработки (приложение Windows, установленное на компьютерах с одним Windows, от 1 до 150 клиентских компьютеров на клиента) и веб-сервер, на котором размещена производственная среда. (От 1 до 8 машин на одного клиента). Наш продукт лицензирован для использования на сервере, поэтому клиенты могут использовать любое количество клиентов; мы решили не лицензировать серверную часть (потому что она подчиняется соглашениям SLA), а только клиент, потому что через некоторое время без возможности использовать клиент система становится практически бесполезной.

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

Я оценил различные продукты лицензирования, и они слишком дороги или слишком сложны в управлении, поэтому я пришел к такому простому решению:

  • Лицензия будет представлять собой простой подписанный XML-файл, подписанный с использованием стандартной функции XML-подписи w3c, с использованием закрытого ключа, который будет передан в административный отдел на USB-ключе; если они потеряют копию, схема лицензирования потерпит неудачу, но это будет их вина
  • Клиент откроет файл лицензии при запуске и проверит его действительность, используя открытый ключ, встроенный в двоичные файлы
  • Если лицензия XML действительна и данные в ней (срок годности и название продукта) верны, чем работа дизайнера; если нет, будет показано соответствующее сообщение

Есть идеи о возможных проблемах или как улучшить сценарий?

4 ответа

Решение

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

Что бы вы ни делали, вы должны следовать совету Эрика Синка:

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

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

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

Я согласен со Стивеном А. Лоу (у меня нет 15 репутации, поэтому я не смог его проголосовать).

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

Иногда простая схема лицензирования работает лучше всего:

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

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

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

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

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

Если вы пытаетесь контролировать количество использований клиентского кода, то только первый из них сделает это.

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

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

Я уверен, что есть много литературы на эту тему, поэтому, вероятно, вам стоит продолжить свои исследования.

Кстати, я не уверен в вашей ссылке на SLA в средней части о вашем лицензировании сервера. Лицензирование и SLA очень разные. Лицензия - это обязательство клиента, а SLA - ваше.

Другие вопросы по тегам