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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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