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

Question

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

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

• имени клиента (который может быть переменной длиной строки)
• 6 цифр серийного номера.

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

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

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