реализация ключей продукта

Я реализую небольшое приложение на языке C, которое позже я хотел бы продавать как условно-бесплатное ПО по разумной цене. Он начнется с 30-дневной пробной версии, и я уже совершенно уверен в том, как ее реализовать.

Проблема, однако, в том, что я не совсем уверен, как реализовать проверку ключа продукта. Я имею в виду, что покупатель может зарегистрироваться на моей веб-странице (после некоторого опробования продукта), заплатить за продукт и получить ключ продукта в форме aaaaa-bbbbb-ccccc-ddddd-eeeee через e -mail (или, возможно, доступен через его профиль на моем сайте). Пока проблем нет. Затем он / она опускает ключ в соответствующие ключевые поля в моем приложении, и бум приложение регистрируется.

Насколько я могу судить, для этого люди рекомендуют либо AES, либо RSA. Честно говоря, я учился в колледже по другому направлению (не по криптографии), и один курс по криптографии я проходил некоторое время назад. Но насколько я помню, AES - это симметричный алгоритм шифрования, что означает, что у меня будет только один ключ для шифрования и дешифрования, верно? Как я мог затем сгенерировать тысячи ключей продукта и по-прежнему проверять их в своем приложении (которое, кстати, не требует доступа в Интернет ... так что не нужно проверять сервер)?

Так что я думаю, что RSA будет лучшим вариантом? Но разве RSA не создает довольно длинные ключи (по крайней мере, длиннее требуемых 25 символов, указанных выше)?

В другом потоке я прочитал, что некоторые продукты даже не используют шифрование для генерации / проверки ключа продукта, а вместо этого просто используют некоторые проверки, такие как «добавьте символ 2. и 17., и это должно быть в сумме до x».

Какой самый быстрый, простой и безопасный способ добраться сюда? :-) Примеры кода были бы сахаром!

С уважением,

Себастьян

PS: О ... и, пожалуйста, не говорите мне, как мой ключ может и будет взломан в какой-то момент ... Я знаю об этом, и в первую очередь поэтому я не хочу проводить много времени с эта проблема, но в то же время не делает ее слишком легкой для случайного взломщика.


c encryption key product licensing
person Sebastian    schedule 14.03.2009    source источник

Ответы (5)


arrow_upward
35
arrow_downward

Симметричные алгоритмы ограничены тем, что любой начинающий взломщик с дизассемблером может найти ваш ключ (или алгоритм, использованный для его генерации) и создать «генерацию ключей».

По этой причине асимметричная криптология - лучший выбор. Основная посылка примерно такая:

  • Когда пользователь покупает у вас лицензию, вы собираете определенные идентифицирующие данные о пользователе и / или его среде (как правило, это просто полное имя; иногда также компания).
  • Вы делаете 128-битный хеш MD5 из этой информации.
  • Используя 128-битное шифрование Elliptic Curve, зашифруйте этот хеш с помощью private ключ на сервере.
  • 128-битный зашифрованный текст может быть представлен пользователю в виде 25-символьной строки, состоящей из букв и цифр (плюс разделительные тире для удобства чтения). Обратите внимание, что 26 букв + 10 цифр = 36 дискретных значений и 36 ^ 25> 2 ^ 128.
  • Пользователь вводит этот ключ продукта в диалоговое окно регистрации. Клиентское программное обеспечение преобразует его обратно в 128-битное число (16 байтов), расшифровывает его, используя открытый ключ криптографии EC, и сравнивает результат с хешем MD5 личной информации пользователя, который должен соответствовать тому, что использовалось для регистрации. .

Конечно, это всего лишь основная идея. Для получения дополнительных сведений и исходного кода см. Ключи продуктов, основанные на криптографии с эллиптическими кривыми.

person P Daddy    schedule 14.03.2009
comment
Большое спасибо за информацию. Предположим, я не могу использовать EEC по какой-то причине ... RSA не подойдет для метода 25-символьного ключа, потому что ключи RSA имеют минимальную длину 1024 бита, верно? - person Sebastian; 16.03.2009
comment
RSA может быть всего 384 бита, но это все еще слишком долго для вводимого пользователем ключа. Даже если вы различаете верхний и нижний регистр (что дает 62 незаметных символа), вам понадобится ключ длиной 65. А RSA на 384 битах очень слаб, так что ваш закрытый ключ, скорее всего, в любом случае будет скомпрометирован. - person P Daddy; 16.03.2009
comment
Я вижу здесь бесплатную реализацию ECC: codeproject.com/KB/security/Elliptic_Curves.aspx. Я не проверял, насколько он хорош. Если немного покопаться, наверняка найдутся другие. Вот довольно дешевый: ellipter.com. - person P Daddy; 16.03.2009
comment
Спасибо! выглядит хорошо, но, к сожалению, мой генератор ключей работает на Ruby, и, похоже, нет какой-либо библиотеки, поддерживающей ECC :-( Думаю, мне все же нужно использовать файлы лицензий (содержащие надежный 4k-битный шифр RSA): - ( - person Sebastian; 17.03.2009
comment
Может ли ваш код Ruby не взаимодействовать с модулем C, который обрабатывал шифрование? - person P Daddy; 17.03.2009
comment
Ты прав. Это тоже вариант :-) - person Sebastian; 17.03.2009
comment
Подобно тому, как пользователь может найти симметричный ключ с помощью дизассемблера, он может исправить ваш двоичный файл, чтобы заменить открытый ключ, используемый для проверки информации о лицензии (с ключом из пары ключей, которую они сгенерировали сами). Используйте самое простое, потому что, если кто-то захочет сломать вашу защиту от копирования, он это сделает. И вы не хотите вкладывать в это слишком много усилий. - person erickson; 20.12.2009
comment
@erickson: Я согласен с тем, что решительный взломщик создаст патч, если он не может создать генерацию ключей, и что никакая защита от копирования не является безопасной. Однако есть разные степени риска. Крекинг бывают трех основных видов: серийные номера, кейгены и патчи / исправленные двоичные файлы. Пользователи предпочитают первое, потому что им не нужно загружать код. Кейгены довольно легко сканировать на вирусы, а исправления - самые страшные. Исправления также с меньшей вероятностью будут работать после небольшого обновления программного обеспечения. Если вашему приложению требуется патч, это лучшая техническая безопасность, которую вы можете получить. - person P Daddy; 20.12.2009
comment
Да, я согласен. Это хороший момент: патч (созданный кем-то, кто, по-видимому, в лучшем случае является вором) очень пугает (или должен быть) для пользователей. - person erickson; 23.12.2009
comment
К сожалению, связанная статья «Ключи продуктов на основе криптографии с эллиптическими кривыми» была удалена из CodeProject. У кого-нибудь еще есть? Я попробовал archive.org, но он не загружает единственную найденную старую версию. - person Marc; 16.07.2010
comment
Google включает это сейчас на codeguru. Обновлю ссылку. - person P Daddy; 11.05.2012

arrow_upward
1
arrow_downward

Жизнь проще, если вы просто купите решение.

http://www.kagi.com/kagisolutions/index.php

Kagi позволяет собирать платежи и помогает управлять ключами.

person S.Lott    schedule 14.03.2009
comment
нет, извините, не вариант. Ориентировочная цена приложения составляет 4,99 евро, а комиссия Kagi слишком высока для продукта в этом ценовом диапазоне. - person Sebastian; 14.03.2009
comment
Самое смешное в том, что Каги больше не существует. - person dimiguel; 07.06.2017

arrow_upward
0
arrow_downward

Один парень написал в блоге, как он справился с вопросом о регистрационных номерах. Одна из его записей в блоге - Создание уникальных регистрационных номеров.

person mouviciel    schedule 14.03.2009

arrow_upward
0
arrow_downward

Да, RSA и AES - это две очень разные вещи:

  • RSA - это криптография с открытым ключом, включающая открытый ключ и закрытый ключ, и она довольно медленная. Основное использование - установка безопасного обмена сеансовым ключом симметричного шифрования.
  • AES - это симметричное шифрование, быстрое и безопасное.

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

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

Работа с криптографией - непростая задача. Как вы упомянули, вы ожидаете, что это будет взломано. Если вы делаете это самостоятельно, это почти наверняка произойдет. Вы все еще можете использовать свою собственную реализацию, чтобы «честные люди оставались честными», но поймите, что это все, что вам нужно. Если вам нужно что-то более сильное, вам следует приобрести раствор после тщательного изучения решений.

person dwc    schedule 14.03.2009

arrow_upward
0
arrow_downward

Вы можете ознакомиться с этой статьей Code Project. Он описывает реализацию программного ключа на основе MAC-адреса машины, на которой выполняется программное обеспечение. Метод не идеален, как признает сам автор, и немного отличается от того, что вы ищете, но, возможно, он может вам помочь.

person Dani van der Meer    schedule 14.03.2009