Блог разработчика

2 Sergey:

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

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

2 Norfolc

Замена ключей – тоже своего рода смена формата. В любом случае, технические сложности — ничто перед процедурой обмена ключей, особенно когда клиентов уже много.

2 Begemot.

Отследить относительно легко, но смысл такого обращения понять сложно. Как бы то ни было, постепенно добавляя взломщиками мелкие сложности, ты можешь со временем получить практически невзламываемую прогу.

0xDEADBEEF, поэтому, чтобы такое не происходило, нужно привязываться к железу (получать HardwareID на этапе покупки или делать систему активации с ограниченным числом активаций).
Ну ещё можно в следующих версиях заносить “ворованный” ключ в чёрный список.

0xDEADBEEF, ключ, защищённый подписью, может (должен?) быть персонализирован, т.е. содержать в себе имя и контакт владельца. С одной стороны, это может удержать приобретателя ключа от раздачи его налево и направо, а с другой стороны – многие пользователи чувствуют себя некомфортно, когда программа пишет, что зарегистрирована не на их имя.

Берешь Армадилу или еще какой Протектор и не ибешь себе моск 🙂

Активация спасает от всех этих проблем, но не ко всем типам продуктов подходит….

Зачем?

Решай проблемы по мере поступления…

Я не стирал, может барабашка:)
длина около 170 символов, типа как у аспра, ключ персонализированный + куча информации – дата, референс намбер, мыло… за все время на длину жаловались только два человека, че экономить то ?
Подпись нужна что бы кейген не сделать… собственно подпись это и есть ассиметрика:)

В алгоритме RSA для подписи используется приватный ключ, а для его проверки – публичный (вшит в программу). Шифровать данные в ключе не нужно. Нужно только их подписать. И этого вполне достаточно, чтобы удостовериться в правильности ключа.
А шифрование данных происходит публичным ключем. И расшифровать можно только приватным. Поэтому для шаровары это не подходит – прийдется вшивать приватный ключ в программу, что есть глупо.
А длина ключа – не проблема. Можно ключ слать файлом, а можно и в обычном текстовом виде и написать, чтобы сделали Copy/Paste.

Как раз запутался ты.
Вся соль в том, что шифрование производится публичным ключем, а расшифровка – приватным.
Прочитай хотябы википедию: http://ru.wikipedia.org/wiki/RSA
Сделано это для того, чтобы, например, я мог выложить в сеть свой публичный ключ и кто угодно мог послать мне сообщение, которое смогу только я прочитать и никто иной (ведь дешифровка производится привтным ключем).
И если этот кто-то хочет, чтобы я ему ответил шифрованным сообщением, то он сообщит мне свой публичный ключ.

Да, согласен. можно шифровать и приватным ключем (Прив.К), а расшифровывать публичным (Публ.К). Только это особого смысла не имеет.
С таким же успехом можно на “лицензинный ключ” (ЛК) наложить Base64 – будет та же самая шифровка. Ведь Публ.К вшит в программу и не составляет труда его оттуда получить и самому расшифровать ЛК.
Поэтому кракеру будет достаточно иметь расшифрованный ключ и пропатчить уже не проверку подписи, как в моём случае, а вызов дешифрации.

2 topmedia:

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

Кроме того, в вашей схеме нужно иметь механизм проверки валидности расшифрованных данных; в общем случае это – избыточные данные, причём, чтобы стать сопоставимым по уровню надёжности с DSA, этот механизм должен задействовать сопоставимый объём избыточных данных (ну ладно, вдвое меньший, но это мало что меняет). Без такого механизма кто-нибудь рано или поздно сгенерирует лицензию на “TopMedia” или на “Registered User”, а это почти так же плохо, как кейген.

2 Ippi: что-то я совсем заработался, не в два раза, а на 20%. Все-равно много.

Внутри ключа у меня дата, тип лицензии, кол-во лицензий и 8-байтовый ключ для расшифровки внутренних данных. Имя вообще не используется. Естественно, первый же кардер сможет получить константу для дешифрации данных имея на руках валидный ключ 🙁

С подписью нет никакой возможности спрятать в ключе эту константу, а такая схема используется почти во всех протекторах.

Длина ключа для меня очень важна. При нынешних 30 символах у меня несколько раз в неделю жалуются что не ключ не работает 🙁

2Begemot: Да, промахнулся. Извини, что необоснованно наехал.

В открытом виде давать константу? Или ключ все-таки шифруется?

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

Возможно ты прав, хотя непривычно давать ключ в открытом виде.

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

Сорри за некропостинг.
К вопросу о инкапсуляции имени, email’а и еще какой-то информации. Как я понял, суть цифровой подписи состоит не в генерации зашифрованного сообщения, содержащего исходные данные, а подписывании дайджеста (хэша) сообщения – как я понял, используется обычно SHA-1 – в результате ключик можно получить довольно короткий и фиксированной длинны. Из минусов – в ключе не передается какая-либо информация. Но для задачи генерации лицензии можно же попросить пользователя, чтобы он ввел имя, email, название организации и ключ, и сравнивать хэш этих данных с тем что в ключе. В принципе, к хэшу уже можно прицепить и некоторый набор данных – даты, ключевое значение для работы программы, еще что-либо коротенькое фиксированного размера. Если я все правильно понял, то остался такой вопрос – хочу кейген на php написать, openssl функции сами хэш высчитывают при подписывании или я сам могу хэш посчитать, дополнить его, и сгенерировать подпись по этим данным?

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