Лицензионный ключ на 202 символа: как защитить программу без Ed25519 и RSA

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

Почему Ed25519 и RSA не подошли

Классические асимметричные алгоритмы, такие как RSA и Ed25519, требуют больших ключей и подписей. Для Ed25519 подпись занимает 64 байта, для RSA-2048 — 256 байт. В условиях, когда лицензионный ключ должен быть строкой из 202 символов (примерно 150 байт в Base64), разместить подпись вместе с полезными данными невозможно. Кроме того, пользователь должен вводить ключ вручную, что исключает использование длинных или нечитаемых строк. Даже если использовать сжатые форматы, асимметричные подписи остаются слишком громоздкими для такого ограничения.

Выбор схемы: симметричное шифрование + HMAC

Автор решил использовать комбинацию симметричного шифрования (AES-256 в режиме GCM) и HMAC-SHA256. Такой подход позволяет уместить все необходимые данные в 202 символа. Ключ шифрования и HMAC-ключ хранятся на стороне программы (защищённые обфускацией), что делает проверку возможной без обращения к серверу. Основной недостаток — при компрометации одного экземпляра программы злоумышленник может извлечь ключи, но для десктопного ПО это считается приемлемым риском. В отличие от веб-приложений, где ключи можно менять динамически, в десктопе обновление требует выпуска патча.

Как это работает

Лицензионный ключ формируется на сервере: полезные данные (например, срок действия, версия продукта, идентификатор пользователя) шифруются на секретном ключе, затем добавляется HMAC для целостности. Всё кодируется в Base64, получается строка длиной около 200 символов. Программа расшифровывает ключ, проверяет HMAC и извлекает данные. Если подпись не совпадает или срок истёк, ключ отклоняется. Такой механизм гарантирует, что ключ не был подделан и создан именно авторизованным сервером.

Как защитить лицензионный ключ от подделки без интернета?

Основная угроза — пользователь может попытаться модифицировать ключ, например, продлить срок действия. HMAC-SHA256 решает эту проблему: он вычисляется от зашифрованных данных и nonce, и любое изменение приведет к несовпадению хеша. Кроме того, AES-GCM сам по себе обеспечивает аутентифицированное шифрование, но HMAC добавляет дополнительный уровень защиты, особенно если nonce повторно используется. В итоге даже при офлайн-проверке злоумышленник не сможет создать валидный ключ без знания секретных ключей.

Технические детали реализации

Для шифрования используется AES-256-GCM с 12-байтовым nonce, который генерируется случайно и хранится вместе с зашифрованным текстом. HMAC-SHA256 вычисляется от зашифрованного текста и nonce. Размер полезных данных — около 64 байт, что вместе с nonce, HMAC и служебными полями укладывается в 150 байт, а после кодирования Base64 — в 200 символов. Автор отмечает, что выбор именно GCM позволяет избежать отдельной проверки целостности, но HMAC добавляет дополнительный уровень защиты от модификации. Nonce генерируется на сервере и включается в ключ, чтобы каждый ключ был уникальным.

Кого затронет и как

Решение ориентировано на разработчиков десктопных приложений, которым нужно реализовать офлайн-проверку лицензий. Пользователи получают удобный ключ, который можно скопировать из письма. Бизнес выигрывает от простоты развёртывания — не требуется постоянное интернет-соединение. В России и СНГ такой подход может быть особенно востребован из-за частых перебоев с доступом к облачным серверам. Кроме того, отсутствие зависимости от внешних сервисов снижает затраты на инфраструктуру.

Что будет дальше

Автор планирует опубликовать готовую библиотеку на GitHub с реализацией на C++ и Python. В будущем возможно добавление поддержки ECDSA с эллиптической кривой P-256, которая даёт подпись длиной 64 байта, но тогда придётся уменьшить полезные данные или увеличить длину ключа. Пока же найденное решение считается оптимальным для заданных ограничений. Библиотека будет включать примеры интеграции и документацию по настройке ключей.

Итог

Разработчик успешно решил задачу создания компактного лицензионного ключа, отказавшись от тяжёлых асимметричных алгоритмов в пользу симметричного шифрования с HMAC. Полученный ключ длиной 202 символа обеспечивает достаточную защиту для десктопного ПО без интернета. Следите за публикацией библиотеки — возможно, она упростит жизнь многим коллегам. Если вы ищете баланс между безопасностью и удобством, этот подход заслуживает внимания.