Ключи продуктов шифрования: шифрование с открытым и закрытым ключом

Question

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

Я генерирую наши ключи продукта на основе

• имя клиента (которое может быть строкой переменной длины)
• 6-значный серийный номер.

Было бы хорошо, если бы ключ продукта имел бы управляемую длину (16 символов или около того)

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

Каков соответствующий механизм для выполнения вышеуказанных требований?

ПРИМЕЧАНИЕ: это не остановить пиратство; это уменьшает вероятность того, что начинающие пользователи установят компоненты, которые им не нужны / неавторизованы для использования.

Answer 1

.NET поддерживает шифрование с открытым ключом различными способами, такими как http://msdn.microsoft.com/en-us/library/ms867080.aspx. Сказав это, вы получите лишь уверенность в том, что кто-то, имеющий полный доступ к выпущенному коду, не сможет выдать свои собственные ключи продукта. Ничто из этого не останавливает их от исправления клиента для принятия чего-либо в качестве действительного ключа. Вот где запутанность вписывается.

Answer 2

Даже не пытайтесь увлечься антипиратством. Это того не стоит. Я взломал бесчисленное количество приложений (молчаливо), и.NET самые простые. Но в действительности все они относительно легки с достаточным опытом. Если вы мне не верите, проверьте isohunt некоторое время.

tl; dr: Это проигрышная битва. Не борись с этим. Если вы действительно хотите выиграть, подайте в суд на нарушителей - но даже это заставляет вас проигрывать.

Answer 3

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

То, что я сделал, было сериализовать часть данных в двоичный файл. Данные включали в себя хэшированное название компании, код операции / дату истечения срока действия, а также оставляли место для будущих требований. Затем я разбросал биты по массиву, чтобы запутать его. Затем я сопоставил каждые 5 бит двоичного массива с 32-символьным алфавитом кода авторизации (0-9,az, исключая I/O/Q/S для удобства чтения по телефону).

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

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