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


361

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?


8
+1 pregunta interesante, ¿tal vez un respondedor pueda publicar enlaces a algunos buenos recursos sobre este tema para leer más? por favor :)
Jacob

44
Todos los esquemas DRM son esencialmente esquemas de oscuridad, ya que todo el código y los datos necesarios para que el programa se ejecute han sido proporcionados al usuario. El esquema se puede ofuscar arbitrariamente para dificultar la aplicación de parches, pero es seguro que el código se puede parchar para evitar cualquier comprobación.
caf

55
Las claves de CD son de hecho seguridad a través de la oscuridad. Hay varias formas de construirlos, pero todos necesariamente dependen de incorporar algún secreto en el programa que se requiere para verificar la clave.
Nick Johnson

44
Ahora se llaman claves de producto o claves de licencia , ya que es más probable que la mayoría del software que las usa se entregue en línea que por CD.
Joel Coehoorn

44
Me gustaría crear una aplicación algún día en la que tuviera que preocuparme por esto, el sueño de la infancia. Las aplicaciones web simplemente no son suficientes.
Znarkus el

Respuestas:


268

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 .


47
Mathematica tiene un proceso interesante. El producto viene con una clave única, y el archivo de instalación genera una segunda clave única (basada en su hardware). Ambas claves deben ingresarse en un formulario en línea con su nombre e información de registro, y luego le envían la clave real basada en esas dos claves que realmente desbloquean el software, pero solo para esa clave de producto específica y en su hardware específico.
Dan

18
Je, nunca supe de la 1234-56789-1234llave de Starcraft, pero recuerdo que solo tardó unos cinco minutos en "forzar" al verificador machacando el teclado e intentando nuevamente.
fmark

18
También recuerdo algunos productos de Microsoft en el pasado que le permitieron usar 111-1111111 como un cdkey válido (Visual Studio 6.0)
hannson

25
Nunca supe de 1234-56789-1234. En cambio, usamos trece tres! 3333333333333
ErikTJ

33
El problema con la activación en línea es que todos estamos jodidos si / cuando el editor cierra. Por favor no hagas esto. Esto sucede, y puede / sucederá incluso a Microsoft algún día.
Brad

56

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

ingrese la descripción de la imagen aquí

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.


66
No, Erik no lo haría. X es un número entero e Y es el piso de la función.
Joshua

¡Esto no es diferente a la antigüedad de la navegación por satélite anterior al GPS! youtube.com/watch?v=BBOsQBuCJfs
Brad

34

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.


21

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.


99
Realmente deseo el que había dado con el 'número utilizado una vez' que no había elegido Nonce como el nombre, dadas las ejem connotaciones negativas que me hacen reír cada vez que alguien sugiere decodificar uno.
Ed James

2
Tenga en cuenta que la tercera opción no funciona con cifrados de clave simétrica ya que el atacante podría simplemente realizar ingeniería inversa de la prueba en el texto sin formato, generar algo que pase y luego cifrarlo con la clave (conocida) y el cifrado (conocido). El uso de una cerveza casera no es la solución porque si puedes hacerlo por tu cuenta, deberías conseguir un trabajo en la NSA.
BCS

@BCS: Lo siento, debería haber sido más claro sobre el uso de criptografía de clave pública.
Andrew Aylett

Utilice un esquema de firma, no un esquema de cifrado para la versión de clave pública. (La firma RSA se parece un poco a "cifrado con la clave pública", pero no es totalmente lo mismo. Hay otros esquemas de firma que no tienen un esquema de cifrado asociado, como DSA.)
Paŭlo Ebermann

El problema con la criptografía de clave pública es que las claves (y, por lo tanto, las de serie) deben ser largas. Un par de claves RSA de 512 bits no es difícil de descifrar en estos días. Compárelo con las teclas de WinXP (5 grupos de 5 caracteres alfanuméricos) que tienen solo 128 bits de entropía pero aún son
difíciles de

17

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. .


fácil de resolver con un buen servicio al cliente - Box shot + Prueba de compra = Bloquear usuario ilegal, otorgar acceso de segundo usuario.
alexanderpas

1
Aquí hay algunas ideas adicionales sobre las claves de CD codinghorror.com/blog/2007/12/software-registration-keys.html
Richard Chambers

10

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.


1
Tenga en cuenta que mi ejemplo subestima enormemente la longitud de su clave. Estos esquemas generalmente requieren codificación base64 e implementación de copiar / pegar, pero permiten claves casi imposibles de adivinar que no están vinculadas a una máquina y no requieren activación (dos cosas muy importantes para muchos tipos de clientes)
userx

3
En lugar de usar RSA, puede usar curvas elípticas. Usan teclas más cortas y su longitud de bloque es menor. Al leer el Wiki, parece que un ECC de 256 bits es tan seguro como AES 128.
xanatos

Tenga en cuenta que las firmas digitales y el "cifrado por clave privada" no son lo mismo. En RSA se ven similares (aunque no lo son, debido a diferentes esquemas de relleno), otros esquemas de firma ni siquiera tienen un esquema de cifrado correspondiente.
Paŭlo Ebermann

@xanatos, 256 bits todavía es demasiado largo para escribir a mano. Considere las claves de 25 caracteres utilizadas por WinXP: solo tienen 128 bits de entropía.
finnw

1
@Mark: una firma suele ser solo un hash cifrado. Puede usar cifrado o firma, mi método funciona igual. Solo está tratando de crear una clave de licencia que no se puede generar fácilmente sin la clave privada y puede ser verificada por la clave pública. Este podría ser el mensaje completo encriptado (y verifica que parte de su contenido coincide con algo mágico) o simplemente un mensaje firmado (y verifica que la firma sea válida). Depende de su implementación.
userx

9

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.


1

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.


1

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.


0

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.