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

1) Максимальная простота и привычность с точки зрения пользователя. Везде где ставится вопрос о надежности защиты vs удобство пользователя, выбор делается в пользу последнего.
2) Максимальная надежность защиты при заданной 1). Защита НЕ должна быть непробиваемой! Достаточно защиты, которая не ломается без дизассемблирования / рефлектирования кода, а просто путем подмены файлов например.
3) Минимальная стоимость при 1) и 2)
4) Совместимость с регистраторами, т.е. вписаться в существующие схемы оплаты/выдачи ключей
5) Платформа .NET, из этого следует:
— не факт что имеется Full Trust
— нежелательно unmanaged код
— практически нет готовых навесных решений защиты
— есть все что нужно для криптографии
— у сборки есть сильное имя, которое можно использовать как публичный ключ для асимметричного криптования.
6) Интернет у пользователя имеется

После целого дня изучения форумов, я резюмировал следующую систему активации:

1. Пользователь покупает программу (предварительно скачивает/пробует) у регистратора, последний выдает ему серийный номер (S/N), который представляет собой уникальный код, ни от чего не зависимый, вроде guid'а, из списка.

2. Пользователь запускает программу и в ней заходит в окошко "Купить" и вводит S/N.

3. Программа вычисляет некий hardware id или OS id, назовем его ComputerID, с целью получить некий идентификатор, который более-менее уникален, специфичен для данного компьютера и не будет изменяться в ближайшее время.

4. Программа берет ComputerID и S/N, криптует их с помощью публичного ключа сборки и отправляет моему серверу. Таким образом заодно проверяется целостность сборки и исключается открытая передача приватной информации.

5. Сервер получает S/N, расшифровывает его private ключом, тем самым, которым была подписана сборка, и проверяет S/N по базе. Кроме наличия S/N, по моему усмотрению, проверяется количество/дата последней регистрации и т.п., так сказать, фрод-чек . После принимается решение о выдаче лицензии или отклонении запроса.

6. Если все ОК, сервер генерирует файл лицензии, который представляет собой текстовый файл (скорее всего XML), с цифровой подписью. Подпись представляет собой исходный ComputerID, зашифрованный с помощью имеющегося у сервера private-ключа сборки.

7. Файл отправляется клиенту, программа сохраняет его в папке своей установки. Этот файл нет необходимости прятать, т.к. он подойдет только для данного компьютера, и его нельзя изменить.

8. При следующем запуске, программа проверяет наличие файла лицензии, отыскивает в нем цифровую подпись и расшифровывает ее публичным ключом сборки. (Опять заодно проверяется целостность сборки.) В результате получается ComputerID, который сравнивается с вычисленным еще раз непосредственно. Если все ОК, программа запускается.

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

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

Итак, с точки зрения пользователя это обычная online регистрация программы, а с точки зрения разработчика нужно сделать всего 2 вещи: со стороны клиента написать функцию, которая передает информацию серверу, и функцию проверки лицензии, и со стороны сервера нужно написать простой скрипт проверки/выдачи лицензии.

Буду рад услышать замечания. Огромная просьба не скатываться во флейм по поводу того, что дескать все равно сломают! Это является очевидным, но тем не менее 100% топиков на тему активации этим заканчиваются. Больше инетерсует нет ли граблей в удобстве пользователя и не пропустил ли возможность легкого обхода активации, и как насчет надежности?

Выглядит вполе себе нормально, но:

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

Как ваш сервер отличит повторную активацию при замене оборудования от активации на втором, третьем и т.д. компьютере?

С уважением, Алексей Ровдо.

Здравствуйте, Ignoramus, Вы писали:

I>8. При следующем запуске, программа проверяет наличие файла лицензии, отыскивает в нем цифровую подпись и расшифровывает ее публичным ключом сборки. (Опять заодно проверяется целостность сборки.) В результате получается ComputerID, который сравнивается с вычисленным еще раз непосредственно. Если все ОК, программа запускается.

Насколько я знаю публичный ключ нельзя использовать для дешифровки. Это суть ассимитричного шифрования — 1-й ключ для шифрации, 2-й для дешифрации, друг друга они не меняют. И не слышал, чтобы можно было объявив один из ключей публичным или приватным вычислить на его основе ассимитричный ключ.

Здравствуйте, podovan, Вы писали:

P>Насколько я знаю публичный ключ нельзя использовать для дешифровки.
P>Это суть ассимитричного шифрования — 1-й ключ для шифрации, 2-й для дешифрации, друг друга они не меняют.
В разных алго по разному. В RSA например: то, что зашифровано одним ключом — пофигу каким private или public — можно расшифровать только противоположным ключом. Т.е. шифрованное private только publicом и наоборот. Правда это фича только самого RSA а не ассиметриков в целом.

P>И не слышал, чтобы можно было объявив один из ключей публичным или приватным вычислить на его основе ассимитричный ключ.
Верно.

Здравствуйте, Alexey Rovdo, Вы писали:

AR>Выглядит вполе себе нормально, но:

AR>Я бы по п.6 добавил, что в зашифрованную подпись входит и контрольная сумма XML-данных. Тогда можно было бы в файле-лицензии прописывать список активированных фич программы. Т.е. для одного дистрибутива активировать разные функции в программе простым вводом нового ключа.

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

AR>Как ваш сервер отличит повторную активацию при замене оборудования от активации на втором, третьем и т.д. компьютере?

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


Я вот что подумал — не слишком ли я заморочился? Ведь если предположить, что дизассемблирования/рефлексии не будет, то какой выигрыш дает вышеописанный метод по сравнению с т.н. методом 1000 паролей, когда набор хешей паролей тупо хардкодится в тело программы. Тогда никакого Интернета не надо, а уровень надежности защиты тот же. Единственное, я не смогу оперативно банить провинившиеся S/N и собирать статистику активаций, но это не так уж критично Что скажете?

Здравствуйте, Ignoramus, Вы писали:

I>Здравствуйте, Alexey Rovdo, Вы писали:

AR>>Выглядит вполе себе нормально, но:

AR>>Я бы по п.6 добавил, что в зашифрованную подпись входит и контрольная сумма XML-данных. Тогда можно было бы в файле-лицензии прописывать список активированных фич программы. Т.е. для одного дистрибутива активировать разные функции в программе простым вводом нового ключа.

I>Да, это можно. По сути так работает классическая цифровая подпись — при расшифровке получается хеш всего сообщения. К тому же, Вы правы, это дает дополнительные возможности, такие как контроль активации отдельных функций.

AR>>Как ваш сервер отличит повторную активацию при замене оборудования от активации на втором, третьем и т.д. компьютере?

I>Никак, это имхо не требуется. В этом и отличие от жесткой привязки к железу. Просто если некоторый номер начинает чересчур интенсивно активироваться, я это замечаю и в ручном режиме его баню.


I>Я вот что подумал — не слишком ли я заморочился? Ведь если предположить, что дизассемблирования/рефлексии не будет, то какой выигрыш дает вышеописанный метод по сравнению с т.н. методом 1000 паролей, когда набор хешей паролей тупо хардкодится в тело программы. Тогда никакого Интернета не надо, а уровень надежности защиты тот же. Единственное, я не смогу оперативно банить провинившиеся S/N и собирать статистику активаций, но это не так уж критично Что скажете?

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

I>Я вот что подумал — не слишком ли я заморочился?

Очень даже нормально