Як створюються ліцензійні ключі програмного забезпечення?

Ліцензійні ключі є дефакто-стандартом як заходи проти піратства. Якщо чесно, це вражає мене як (в) безпеку через невміння , хоча я справді не маю уявлення про те, як створюються ліцензійні ключі. Який хороший (безпечний) приклад генерації ліцензійних ключів? Які криптографічні примітиви (якщо такі є) вони використовують? Це дайджест повідомлень? Якщо так, то які дані вони б хеширували? Які методи використовують розробники, щоб утруднювати сухарики для створення власних ключових генераторів? Як виготовляються ключові генератори?

Що стосується ключів компакт-дисків старої школи, це було лише створенням алгоритму, для якого ключі CD (які можуть бути будь-якими рядками) легко генерувати та легко перевірити, але співвідношення ключів дійсних CD до недійсних CD -кейдів настільки мало, що випадкові відгадування ключів компакт-диска навряд чи отримають вам дійсну.

НЕПРАВІЛЬНИЙ ШЛЯХ ДІЯТИ:

І Starcraft, і період напіввиведення використовували одну і ту ж контрольну суму, де 13-та цифра підтверджувала перші 12. Таким чином, ви можете ввести що завгодно для перших 12 цифр, і вгадати 13-ту (існує лише 10 можливостей), що веде до сумнозвісного1234-56789-1234

Алгоритм перевірки є загальнодоступним і виглядає приблизно так:

x = 3;
for(int i = 0; i < 12; i++)
{
    x += (2 * x) ^ digit[i];
}
lastDigit = x % 10;

ПРАВИЛЬНИЙ ШЛЯХ ДІЙСНЯ

Windows XP займає досить небагато інформації, шифрує її та розміщує кодування букви / цифри на наклейці. Це дозволило MS одночасно підтвердити ваш ключ та отримати тип продукту (Домашній, Професійний тощо) одночасно. Крім того, потрібна онлайн-активація.
Повний алгоритм досить складний, але добре викладений у цій (цілком законній!) Роботі, опублікованій у Німеччині.

Звичайно, незалежно від того, чим ви займаєтесь, якщо тільки ви не пропонуєте онлайн-сервіс (наприклад, World of Warcraft ), будь-який тип захисту від копіювання - це лише стійла: на жаль, якщо будь-яка гра, яка вартує цінності, хтось зламається (або принаймні обійдеться ) алгоритм ключа CD та всі інші засоби захисту авторських прав.

РЕАЛЬНИЙ ПРАВИЛЬНИЙ ШЛЯХ ДІЯТИ:

Для онлайн-сервісів життя трохи простіше, оскільки навіть з двійковим файлом вам потрібно автентифікувати їх сервери, щоб користуватися ним (наприклад, мати акаунт WoW). Алгоритм ключових компакт-дисків для World of Warcraft - застосовується, наприклад, при купівлі ігрових карт - ймовірно, виглядає приблизно так:

1. Створіть дуже велике криптографічно захищене випадкове число.
2. Зберігайте його в нашій базі даних та роздруковуйте на картці.
   
   Потім, коли хтось вводить номер картки для відтворення, перевірте, чи є він у базі даних, а якщо він є, зв’яжіть це число з поточним користувачем, щоб його більше не можна було використовувати.

Для онлайн-сервісів немає причин не використовувати вищевказану схему; використання чого-небудь іншого може призвести до проблем .

Коли я спочатку писав цю відповідь, я вважав, що питання стосується "офлайн" перевірки ліцензійних ключів. Більшість інших відповідей стосуються перевірки в Інтернеті, що значно простіше в обробці (більшу частину логіки можна виконати на стороні сервера).

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

Я не дуже добре розбираюся в математиці, але мені вразило, що один із способів зробити це - використовувати математичну функцію, яка побудує графік

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

Як приклад, ми побудуємо цей графік, виберемо чотири точки і кодуємо в рядок як "0, -500; 100, -300; 200, -100; 100,600"

Ми зашифруємо рядок відомим і фіксованим ключем (жахливо слабкий, але він служить цілі), потім перетворимо отримані байти через Base32, щоб генерувати остаточний ключ

Потім програма може змінити цей процес (base32 на реальне число, розшифрувати, розшифрувати точки), а потім перевірити, що кожна з цих точок є на нашому секретному графіку.

Це досить невелика кількість коду, який дозволив би створити величезну кількість унікальних та дійсних ключів

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

Перевірте цю статтю на часткову перевірку ключа, яка охоплює такі вимоги:

• Ліцензійні ключі повинні бути досить легкими для введення.

• Ми повинні мати можливість передати в чорний список (відкликати) ліцензійний ключ у випадку повернення коштів або покупок з викраденими кредитними картками.

• Немає «телефонування додому» для тестування ключів. Хоча ця практика стає все більш поширеною, я все ще не ціную її як користувача, тому не прошу своїх користувачів миритися з нею.

• Зловмиснику не повинно бути можливим розбирати наше випущене додаток і виробляти з нього робочий "кейген". Це означає, що наша програма не повністю перевірить ключ для підтвердження. Тільки частина ключа має бути протестована. Крім того, кожен випуск програми повинен перевіряти різну частину ключа, щоб фальшивий ключ, заснований на попередньому випуску, не працював на більш пізній випуск нашого програмного забезпечення.

• Важливо: законному користувачеві не повинно бути випадково введено недійсний ключ, який, здається, працює, але не працює в майбутній версії через помилку друкарства.

Я не маю досвіду того, що люди насправді роблять для створення ключів компакт-дисків, але (якщо припустити, що ви не хочете йти по шляху активації в Інтернеті), ось кілька способів зробити ключ:

• Потрібно, щоб число було розділене на (скажімо) 17. Тривіальне для здогадки, якщо у вас є доступ до багатьох клавіш, але більшість потенційних рядків буде недійсним. Аналогічно вимагає, щоб контрольна сума ключа відповідала відомій величині.

• Потрібно, щоб перша половина ключа, з'єднана з відомим значенням, була хеширована до другої половини ключа. Краще, але програма все ж містить всю інформацію, необхідну для генерації ключів, а також для їх перевірки.

• Створюйте ключі, шифруючи (за допомогою приватного ключа) відоме значення + nonce. Це можна перевірити, розшифрувавши за допомогою відповідного відкритого ключа та перевіривши відоме значення. Програма тепер має достатньо інформації для перевірки ключа, не маючи можливості генерувати ключі.

Вони все ще відкриті для атаки: програма все ще є і може бути виправлена ​​в обхід чека. Cleverer може бути шифрувати частину програми, використовуючи відоме значення з мого третього методу, а не зберігати значення в програмі. Таким чином, вам доведеться знайти копію ключа, перш ніж ви зможете розшифрувати програму, але вона все ще вразлива для того, щоб бути скопійованою одного разу в розшифрованому стані та тим, щоб одна людина взяла їх законну копію та використала її, щоб всі інші мали змогу отримати доступ до програмного забезпечення.

CD-ключі не є надто безпекою для будь-яких немережевих речей, тому технічно їх не потрібно надійно створювати. Якщо ви перебуваєте на .net, ви майже можете перейти з Guid.NewGuid ().

Основне їх використання на сьогодні є для компонентів Multiplayer, де сервер може перевірити ключ CD. З цього приводу неважливо, наскільки надійно це було створено, коли воно зводиться до "Перегляньте все, що передано, і перевірте, чи хтось ще використовує це".

Зважаючи на це, ви можете скористатися алгоритмом для досягнення двох цілей:

• Майте якусь контрольну суму. Це дозволяє вашому інсталятору відображати повідомлення "Ключ не здається дійсним", а лише виявляти помилки друку (додавання такої перевірки в інсталяторі насправді означає, що написання генератора ключів є тривіальним, оскільки хакер має весь необхідний йому код. Не маючи перевірка і виключно посилання на перевірку на стороні сервера відключає цю перевірку, ризикуючи роздратувати ваших законних клієнтів, які не розуміють, чому сервер не приймає їх ключ CD, оскільки вони не знають про помилку друку)
• Робота з обмеженим набором символів. Намагаючись ввести ключ CD та здогадатися "Це 8 чи B? A 1 чи I? A Q чи O чи 0?" - використовуючи підмножину неамбітних символів / цифр, ви усуваєте цю плутанину.

Попри це, ви все ще хочете великого розповсюдження та певної випадковості, щоб пірат просто не вгадував дійсний ключ (це дійсно у вашій базі даних, але все ще знаходиться у коробці на полиці магазину) та накручує законного клієнта, який випадково купує цю коробку .

Якщо ви не особливо переймаєтесь довжиною ключа, досить перевіреним і вірним методом є використання шифрування відкритого та приватного ключів.

По суті мають якесь поняття і фіксований підпис.

Наприклад: 0001-123456789

Там, де 0001 - це ваше ніколи, а 123456789 - ваш фіксований підпис.

Потім зашифруйте це за допомогою приватного ключа, щоб отримати ключ CD, який має щось на зразок: ABCDEF9876543210

Потім поширюйте відкритий ключ разом із додатком Відкритий ключ можна використовувати для розшифрування ключа CD "ABCDEF9876543210", за допомогою якого ви потім перевіряєте фіксовану частину підпису.

Це заважає комусь здогадатися, що таке ключ CD для nonce 0002, оскільки у них немає приватного ключа.

Єдина основна сторона вниз - це те, що ваші ключі CD будуть досить довгими при використанні приватних / відкритих ключів розміром 1024 біт. Вам також потрібно вибрати досить недовго, щоб не шифрувати тривіальну кількість інформації.

З іншого боку, цей метод працюватиме без "активації", і ви можете використовувати такі речі, як адреса електронної пошти чи ім'я ліцензіата як ніколи.

Ключова система повинна мати кілька властивостей:

• дуже мало ключів повинні бути дійсними
• дійсні ключі не можуть бути діючими, навіть враховуючи все, що має користувач.
• дійсний ключ в одній системі не є дійсним ключем для іншої.
• інші

Одним із рішень, яке має надати вам це, буде використання схеми підписання відкритого ключа . Почніть з "системного хешу" (скажімо, захопіть маки на будь-яких NIC, відсортовано та інформацію про CPU-ідентифікатор, а також деякі інші речі, об'єднайте все це разом і візьміть MD5 результату (ви дійсно не хочете бути обробка особистої інформації якщо вам не потрібно)) додайте серійний номер компакт-диска та відмовляйтесь завантажуватися, якщо якийсь ключ реєстру (або якийсь файл даних) не має дійсної підписи для блобу. Користувач активує програму, доставляючи вам крапку, і ви відправляєте назад підпис.

Потенційні проблеми включають те, що ви пропонуєте підписати практично все, тому вам потрібно припустити, що хтось виконає обраний звичайний текст та / або вибрані атаки на шифротекст . Це можна пом'якшити, перевіривши наданий серійний номер та відмовившись обробляти запит від недійсних запитів, а також відмовившись обробляти більше заданої кількості запитів із заданого s / n в інтервалі (скажімо, 2 на рік)

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

Також є поведінка DRM, яка включає кілька кроків до процесу. Один з найбільш відомих прикладів - один із методів Adobe для перевірки встановлення їх Creative Suite. Використовується традиційний метод CD Key, який обговорюється тут, тоді викликається лінія підтримки Adobe. Ключ CD надається представнику Adobe, і вони повертають номер активації, який користувач повинен використовувати.

Однак, незважаючи на те, що вони розбиті на етапи, це стає здобиччю тих же методів розтріскування, які використовуються для звичайного процесу. Процес, який використовується для створення ключа активації, який перевіряється на оригінальному ключі CD, був швидко виявлений, і були створені генератори, що включають обидва ключа.

Однак цей метод все ще існує як спосіб перевірити продукт користувачами, які не мають підключення до Інтернету. Вперед, легко зрозуміти, як ці методи будуть усунені, коли доступ до Інтернету стає повсюдним.

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

"Піратові" потрібно мати доступ лише до одного законного CD та його коду доступу, він може потім робити n копій та розповсюджувати їх.

Не важливо, наскільки криптографічно захищено ви вносити код, вам потрібно надати компакт-диск у простому тексті, або законний користувач не може активувати програмне забезпечення.

Більшість безпечних схем передбачає або користувач, що надає постачальнику програмного забезпечення деякі відомості про машину, яка запускатиме програмне забезпечення (серійні номери процесора, мак-адреси, ip-адресу тощо), або вимагає доступу до Інтернету для реєстрації програмного забезпечення на веб-сайті постачальників та натомість отримують маркер активації. Перший варіант вимагає багато ручного адміністрування і коштує його лише для програм із дуже високою цінністю, другий варіант може бути сфабрикований і абсолютно безумний, якщо у вас обмежений доступ до мережі або ви застрягли за брандмауером.

В цілому набагато простіше налагодити довірчі відносини зі своїми клієнтами!

Ви можете дуже легко використовувати та реалізовувати API безпечного ліцензування ( https://www.nuget.org/packages/SystemSoulLicense/ ) у ваших Програмних проектах, використовуючи його (вам потрібно завантажити настільний додаток для створення захищеної ліцензії з https: / /www.systemsoulsoftwares.com/ ) 1. Створює унікальний UID для клієнтського програмного забезпечення на основі системного обладнання (ЦП, материнської плати, жорсткого диска) (UID діє як приватний ключ для цієї унікальної системи) 2. Дозволяє дуже легко надсилати зашифровані рядки ліцензій до клієнтської системи, він перевіряє рядок ліцензії і працює лише над цією конкретною системою 3. Цей метод дозволяє розробникам програмного забезпечення або компанії зберігати більше інформації про програмне забезпечення / розробника / послуги дистриб'ютора / функції / клієнта 4. Він дає можливість контролювати та розблокувати функції клієнтського програмного забезпечення, економлячи час розробників на створення більшої версії для того ж програмного забезпечення із зміною функцій 5. Потрібно піклуватися про пробну версію також на будь-яку кількість днів. 6. Забезпечує ліцензію ліцензій, перевіряючи DateTime в режимі он-лайн під час реєстрації 7. ​​Він розблоковує всю технічну інформацію для розробників 8.Він має всі функції попереднього збирання та користувацькі функції, до яких розробник може отримати доступ при кожному процесі ліцензування для створення більш складного захищеного коду