Algoritmo seguro para crear claves de licencia?

Question

Me gustaría distribuir una aplicación, pero tengo una clave de licencia que pueden ingresar para desbloquear. ¿Cuál es un buen algoritmo para crear una clave concisa que contenga información sobre qué versión han comprado, así como cosas adicionales como la duración de la licencia, etc.?

Me doy cuenta de que esta protección puede romperse, pero hace que la gente honesta sea honesta. Puedo o no implementar la activación en línea, pero me preocupa principalmente una buena forma de generar estas claves.

Todos hemos visto esta situación, ¿qué algoritmo funciona mejor? ¿Debo solicitar un nombre de usuario en texto plano y usarlo para crear una clave de producto única basada en su propia información?

¿Existe un sistema que pueda usarse para hacer que sea casi imposible generar una clave válida?

Quizás una situación de cifrado de par de claves pública / privada donde solo el fabricante tiene la clave privada y los datos pueden ser validados por una clave pública, pero la clave pública no puede ser secuestrada para crear claves válidas.

Como esta es una clave de producto, sería genial si fuera bastante corta, 64 caracteres o quizás 128 máx., pero cuanto más corta mejor, 32 o menos sería genial.

Answer 1

No dijo en qué plataforma se encuentra, pero aquí hay una en Microsoft .Net:

http://jclement.ca/devel/dotnet/reallysimplelicensing.html

  

Esta página documenta una muy simple   esquema de licencia que puede usar con   su aplicación .NET Está destinado   ser bastante seguro, fácil de implementar   Y fácil de extender. La versión de muestra   le permite proporcionar archivos de licencia   con un nombre de cliente incrustado en ellos   pero puedes extenderlo fácilmente para agregar   otra información de identificación, máquina   enlaces, fechas de caducidad, etc.

     

Este esquema hace uso de Microsoft   Biblioteca RSA y firma XML. Básicamente   pones lo que quieras en un XML   Documente y firme ese documento. Entonces   puede proporcionar ese archivo a su   el cliente y la aplicación pueden leer   la información de licencia de ese   expediente. Dado que el archivo es digital   firmado el archivo de licencia NO puede ser   manipulado a menos que suelte su   clave privada (que realmente   no debería hacer).

Answer 2

Sin acceso a Internet y teclas de disparo

Con respecto al tamaño de la clave de serie, existe una compensación entre las claves legibles cortas / humanas ( menos seguro ) y con claves largas o posiblemente archivos de licencia ( más seguro ).

Si desea claves cortas y fáciles de leer que le permitan almacenar cosas como la fecha de vencimiento y las características, puede usar SKGL junto con Software Protector, que son de código abierto ( https://help.cryptolens.io/faq/what-is-skgl ).

Sin embargo, el inconveniente es que lo más probable es que usen criptografía simétrica y / o almacenen el algoritmo de generación de claves dentro de la aplicación. Esto significa que el usuario final puede intentar encontrar la clave de cifrado y / o el algoritmo (consulte http://www.codeproject.com/Articles/764610/Licensing-systems-in-NET ).

Acceso a Internet (o sin conexión con archivos de activación)

Una mejor alternativa es utilizar un sistema basado en la nube que realiza un seguimiento de todas las claves de licencia y le permite modificarlas en cualquier momento.

Si tiene un sistema de licencia basado en la web, puede mantener las claves más cortas y no tener que almacenar información dentro de la clave real (que es el caso con la mayoría de los sistemas basados ??fuera de línea).

Además, podrá admitir más modelos de licencia, por ejemplo, modelo basado en suscripción.

Las soluciones son:

• construya dicho sistema usted mismo , lo que tomará mucho tiempo y lo distraerá de las funciones principales de la aplicación.

• use un sistema de código abierto existente como punto de partida , aunque puede ser tentador ya que es de código abierto y gratuito, llevará tiempo llevarlos a la nube + configurar a sus necesidades particulares + mantenerlo. Los sistemas de código abierto que he observado tienden a tener una funcionalidad muy amplia, lo que contribuye a la complejidad.

• externalizar a terceros : la desventaja es que la mayoría de ellos no son gratuitos.

En mi opinión, todo el procedimiento debe subcontratarse a un tercero especializado en el desarrollo de ese componente en particular. Una vez que escala, es posible que deba cambiar la lógica de la licencia. En lugar de desarrollarlo usted mismo, es probable que el tercero ya admita ese escenario.

Existen varias soluciones ( asegúrese de buscar las que están basadas en la web ), Cryptolens es un ejemplo. Si está desarrollando una aplicación .NET, este es un ejemplo paso a paso: https: // help. cryptolens.io/examples/key-verification .

---

Descargo de responsabilidad : soy el autor de SKGL / Software Protector, el artículo sobre sistemas de licencias y Cryptolens.