¿Cómo se generan las claves de licencia de software?

Las claves de licencia son el estándar de facto como medida antipiratería. Para ser honesto, esto me parece (en) Seguridad a través de la oscuridad , aunque realmente no tengo idea de cómo se generan las claves de licencia. ¿Cuál es un buen ejemplo (seguro) de generación de clave de licencia? ¿Qué primitivo criptográfico (si lo hay) están usando? ¿Es un resumen del mensaje? Si es así, ¿qué datos estarían haciendo hash? ¿Qué métodos emplean los desarrolladores para dificultar que los crackers construyan sus propios generadores de claves? ¿Cómo se hacen los generadores clave?

Para las claves de CD de la vieja escuela, era solo una cuestión de inventar un algoritmo para el cual las claves de CD (que podrían ser cualquier cadena) son fáciles de generar y verificar, pero la proporción de claves de CD válidas a CD no válidas -keys es tan pequeño que es poco probable que adivinar al azar las claves del CD te dé una válida.

MANERA INCORRECTA DE HACERLO:

Starcraft y Half-life usaron la misma suma de verificación, donde el 13er dígito verificó los primeros 12. Por lo tanto, podría ingresar cualquier cosa para los primeros 12 dígitos, y adivinar el 13 (solo hay 10 posibilidades), lo que lleva a la infame1234-56789-1234

El algoritmo para verificar es público y se ve así:

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

MANERA CORRECTA DE HACERLO

Windows XP toma bastante información, la encripta y coloca la codificación de letra / número en una pegatina. Esto permitió a MS verificar su clave y obtener el tipo de producto (Hogar, Profesional, etc.) al mismo tiempo. Además, requiere activación en línea.
El algoritmo completo es bastante complejo, pero se describe muy bien en este artículo (¡completamente legal!), Publicado en Alemania.

Por supuesto, no importa lo que hagas, a menos que estés ofreciendo un servicio en línea (como World of Warcraft ), cualquier tipo de protección de copia es solo un bloqueo: desafortunadamente, si vale la pena algún juego, alguien se romperá (o al menos eludirá ) el algoritmo de clave de CD y todas las demás protecciones de derechos de autor.

REAL MANERA CORRECTA DE HACERLO:

Para los servicios en línea, la vida es un poco más simple, ya que incluso con el archivo binario necesita autenticarse con sus servidores para usarlo (por ejemplo, tener una cuenta WoW). El algoritmo de clave de CD para World of Warcraft, utilizado, por ejemplo, al comprar tarjetas de tiempo de juego, probablemente se parece a esto:

1. Genere un gran número aleatorio criptográficamente seguro.
2. Guárdelo en nuestra base de datos e imprímalo en la tarjeta.
   
   Luego, cuando alguien ingrese un número de tarjeta de tiempo de juego, verifique si está en la base de datos y, si lo está, asocie ese número con el usuario actual para que nunca se pueda volver a usar.

Para los servicios en línea, no hay razón para no usar el esquema anterior; usar cualquier otra cosa puede causar problemas .

Cuando originalmente escribí esta respuesta, se suponía que la pregunta se refería a la validación 'fuera de línea' de las claves de licencia. La mayoría de las otras respuestas abordan la verificación en línea, que es significativamente más fácil de manejar (la mayor parte de la lógica se puede hacer del lado del servidor).

Con la verificación fuera de línea, lo más difícil es garantizar que pueda generar una gran cantidad de claves de licencia únicas, y aún así mantener un algoritmo sólido que no se vea comprometido fácilmente (como un simple dígito de verificación)

No estoy muy versado en matemáticas, pero me llamó la atención que una forma de hacerlo es usar una función matemática que traza un gráfico

La línea trazada puede tener (si usa una frecuencia suficientemente fina) miles de puntos únicos, por lo que puede generar claves seleccionando puntos aleatorios en ese gráfico y codificando los valores de alguna manera

Como ejemplo, trazaremos este gráfico, elegiremos cuatro puntos y codificaremos en una cadena como "0, -500; 100, -300; 200, -100; 100,600"

Encriptaremos la cadena con una clave conocida y fija (terriblemente débil, pero tiene un propósito), luego convertiremos los bytes resultantes a través de Base32 para generar la clave final

La aplicación puede revertir este proceso (base32 a número real, descifrar, decodificar los puntos) y luego verificar que cada uno de esos puntos esté en nuestro gráfico secreto.

Es una cantidad bastante pequeña de código que permitiría generar una gran cantidad de claves únicas y válidas

Sin embargo, es mucha seguridad por oscuridad. Cualquiera que se tome el tiempo para desensamblar el código podría encontrar la función de gráficos y las claves de cifrado, luego simular un generador de claves, pero probablemente sea bastante útil para frenar la piratería casual.

Consulte este artículo sobre Verificación parcial de clave que cubre los siguientes requisitos:

• Las claves de licencia deben ser lo suficientemente fáciles de escribir.

• Debemos poder poner en una lista negra (revocar) una clave de licencia en el caso de devoluciones de cargo o compras con tarjetas de crédito robadas.

• No "llamar a casa" para probar las claves. Aunque esta práctica se está volviendo cada vez más frecuente, todavía no la aprecio como usuario, por lo que no les pediré a mis usuarios que lo soporten.

• No debería ser posible que un cracker desarme nuestra aplicación lanzada y produzca un "keygen" que funcione. Esto significa que nuestra aplicación no probará completamente una clave para la verificación. Solo se probará parte de la clave. Además, cada versión de la aplicación debe probar una parte diferente de la clave, de modo que una clave falsa basada en una versión anterior no funcione en una versión posterior de nuestro software.

• Importante: no debería ser posible que un usuario legítimo escriba accidentalmente una clave no válida que parecerá funcionar pero fallará en una versión futura debido a un error tipográfico.

No tengo ninguna experiencia con lo que la gente realmente hace para generar claves de CD, pero (suponiendo que no quiera seguir el camino de la activación en línea) aquí hay algunas maneras en que uno podría hacer una clave:

• Exija que el número sea divisible por (digamos) 17. Trivial para adivinar, si tiene acceso a muchas teclas, pero la mayoría de las cadenas potenciales no serán válidas. Similar requeriría que la suma de comprobación de la clave coincida con un valor conocido.

• Exigir que la primera mitad de la clave, cuando se concatena con un valor conocido, descienda a la segunda mitad de la clave. Mejor, pero el programa aún contiene toda la información necesaria para generar claves y validarlas.

• Genere claves encriptando (con una clave privada) un valor conocido + nonce. Esto se puede verificar descifrando con la clave pública correspondiente y verificando el valor conocido. El programa ahora tiene suficiente información para verificar la clave sin poder generar claves.

Todavía están todos abiertos a ataques: el programa todavía está allí y puede ser parcheado para evitar la verificación. Puede que Cleverer cifre parte del programa utilizando el valor conocido de mi tercer método, en lugar de almacenar el valor en el programa. De esa manera, tendría que encontrar una copia de la clave antes de poder descifrar el programa, pero aún así es vulnerable a ser copiado una vez descifrado y a que una persona tome su copia legítima y la use para que todos puedan acceder al software.

Las CD-Keys no son una gran seguridad para las cosas que no están en red, por lo que técnicamente no necesitan ser generadas de forma segura. Si estás en .net, casi puedes ir con Guid.NewGuid ().

Su uso principal hoy en día es para el componente multijugador, donde un servidor puede verificar la clave del CD. Para eso, no es importante la seguridad con la que se generó, ya que se reduce a "Buscar lo que se pasa y verificar si alguien más ya lo está usando".

Dicho esto, es posible que desee utilizar un algoritmo para lograr dos objetivos:

• Tener una suma de verificación de algún tipo. Eso le permite a su instalador mostrar el mensaje "La clave no parece válida", únicamente para detectar errores tipográficos (Agregar tal verificación en el instalador en realidad significa que escribir un generador de claves es trivial ya que el hacker tiene todo el código que necesita. verificar y confiar únicamente en la validación del lado del servidor deshabilita esa verificación, a riesgo de molestar a sus clientes legales que no entienden por qué el servidor no acepta su clave de CD ya que no están al tanto del error tipográfico)
• Trabaja con un subconjunto limitado de caracteres. Intentando escribir una clave de CD y adivinando "¿Es esto un 8 o un B? Un 1 o un I? Un Q o un O o un 0?" - mediante el uso de un subconjunto de caracteres / dígitos no ambiguos elimina esa confusión.

Dicho esto, todavía desea una gran distribución y algo de aleatoriedad para evitar que un pirata simplemente adivine una clave válida (que es válida en su base de datos pero todavía en una caja en el estante de una tienda) y se burle de un cliente legítimo que compra esa caja. .

Si no está particularmente preocupado por la longitud de la clave, un método bastante probado y verdadero es el uso de cifrado de clave pública y privada.

Esencialmente tiene algún tipo de nonce y una firma fija.

Por ejemplo: 0001-123456789

Donde 0001 es su nonce y 123456789 es su firma fija.

Luego, cifre esto con su clave privada para obtener su clave de CD, que es algo así como: ABCDEF9876543210

Luego distribuya la clave pública con su aplicación. La clave pública se puede utilizar para descifrar la clave del CD "ABCDEF9876543210", que luego verifica la parte de firma fija.

Esto evita que alguien adivine cuál es la clave del CD para el nonce 0002 porque no tiene la clave privada.

El único inconveniente importante es que sus claves de CD serán bastante largas cuando utilice claves privadas / públicas de 1024 bits de tamaño. También debe elegir un nonce el tiempo suficiente para no cifrar una cantidad trivial de información.

El lado positivo es que este método funcionará sin "activación" y puede usar cosas como una dirección de correo electrónico o nombre de licencia como nonce.

El sistema de claves debe tener varias propiedades:

• muy pocas claves deben ser válidas
• las claves válidas no deben ser derivables, incluso dado todo lo que el usuario tiene.
• una clave válida en un sistema no es una clave válida en otro.
• otros

Una solución que debería proporcionarles sería utilizar un esquema de firma de clave pública . Comience con un "hash del sistema" (por ejemplo, tome los Mac en cualquier NIC, ordenados, y la información de ID de la CPU, además de algunas otras cosas, concatene todo junto y tome un MD5 del resultado (realmente no quiere ser manejo de información de identificación personal si no es necesario)) agregue el número de serie del CD y se niegue a arrancar a menos que alguna clave de registro (o algún archivo de datos) tenga una firma válida para el blob. El usuario activa el programa enviándole el blob y usted devuelve la firma.

Entre los posibles problemas se incluye que ofrezca firmar prácticamente cualquier cosa, por lo que debe suponer que alguien ejecutará un texto sin formato seleccionado o ataques de texto cifrado elegidos . Eso se puede mitigar verificando el número de serie proporcionado y negándose a manejar solicitudes de personas no válidas, así como negándose a manejar más de un número dado de consultas de un s / n dado en un intervalo (digamos 2 por año)

Debo señalar algunas cosas: en primer lugar, un atacante habilidoso y decidido podrá eludir cualquier seguridad en las partes a las que tiene acceso sin restricciones ( es decir, todo en el CD), lo mejor que puede hacer en esa cuenta es dificultar el acceso ilegítimo que el acceso legítimo. En segundo lugar, no soy un experto, por lo que podría haber serias fallas en este esquema propuesto.

También hay comportamientos de DRM que incorporan múltiples pasos al proceso. Uno de los ejemplos más conocidos es uno de los métodos de Adobe para verificar una instalación de su Creative Suite. Se utiliza el método tradicional de clave de CD discutido aquí, luego se llama a la línea de soporte de Adobe. La clave del CD se entrega al representante de Adobe y le devuelve un número de activación para que el usuario lo utilice.

Sin embargo, a pesar de estar dividido en pasos, esto cae presa de los mismos métodos de craqueo utilizados para el proceso normal. El proceso utilizado para crear una clave de activación que se compara con la clave del CD original se descubrió rápidamente y se hicieron generadores que incorporan ambas claves.

Sin embargo, este método todavía existe como una forma para que los usuarios sin conexión a Internet puedan verificar el producto. En el futuro, es fácil ver cómo se eliminarían estos métodos a medida que el acceso a Internet se vuelva omnipresente.

Todos los algoritmos de protección de copia del CD solo incomodan a los usuarios honestos y no brindan protección contra la piratería.

El "pirata" solo necesita tener acceso a un CD legítimo y su código de acceso, luego puede hacer n copias y distribuirlas.

No importa cuán criptográficamente seguro sea el código, debe proporcionarlo con el CD en texto sin formato o un usuario legítimo no puede activar el software.

La mayoría de los esquemas seguros involucran al usuario que proporciona al proveedor de software algunos detalles de la máquina que ejecutará el software (números de serie de la CPU, direcciones MAC, dirección IP, etc.) o requieren acceso en línea para registrar el software en el sitio web del proveedor y a cambio recibir un token de actividad. La primera opción requiere mucha administración manual y solo vale la pena para un software de muy alto valor, la segunda opción puede ser falsificada y es absolutamente irritante si tiene acceso limitado a la red o si está atrapado detrás de un firewall.

En general, es mucho más fácil establecer una relación de confianza con sus clientes.

Puede usar e implementar API de licencias seguras desde ( https://www.nuget.org/packages/SystemSoulLicense/ ) muy fácilmente en sus proyectos de software al usarlo (debe descargar la aplicación de escritorio para crear una licencia segura desde https: / /www.systemsoulsoftwares.com/ ) 1. Crea un UID único para el software del cliente basado en el hardware del sistema (CPU, placa base, disco duro) (el UID actúa como clave privada para ese sistema único) 2. Permite enviar una cadena de licencia cifrada muy fácilmente al sistema del cliente, verifica la cadena de licencia y funciona solo en ese sistema en particular 3. Este método permite que los desarrolladores de software o la empresa almacenen más información sobre software / desarrollador / servicios de distribución / características / cliente 4. Da control para bloquear y desbloquear las características del software del cliente, ahorrando tiempo a los desarrolladores haciendo más versiones para el mismo software con características cambiantes 5. También se preocupa por la versión de prueba por cualquier número de días 6. Asegura la línea de tiempo de la Licencia Verificando DateTime en línea durante el registro 7. Desbloquea toda la información de hardware a los desarrolladores 8.Tiene todas las funciones precompiladas y personalizadas a las que el desarrollador puede acceder en cada proceso de licencia para hacer un código seguro más complejo