¿Cómo se generan las claves de licencia del 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 claves de licencia? ¿Qué primitiva criptográfica (si hay alguna) están usando? ¿Es un resumen del mensaje? Si es así, ¿qué datos serían hashing? ¿Qué métodos emplean los desarrolladores para dificultar que los crackers construyan sus propios generadores de llaves? ¿Cómo se hacen los generadores de llaves?

Para las claves de CD de la vieja escuela, solo se trataba de inventar un algoritmo para el cual las claves de CD (que podrían ser cualquier cadena) son fáciles de generar y fáciles de verificar, pero la relación entre las teclas de CD válidas y el CD no válido -keys es tan pequeño que es poco probable que adivinar aleatoriamente claves de CD te otorgue una válida.

MANERA INCORRECTA DE HACERLO:

Starcraft y la vida media tanto utilizan la misma sum de control, donde el 13 dígitos verificó la primera 12. De esta manera, se puede introducir nada en los primeros 12 dígitos, y supongo que el día 13 (sólo hay 10 posibilidades), lo que lleva a la famosa 1234-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; 

CORRECTA MANERA DE HACERLO

Windows XP toma bastante información, la encripta y pone la encoding de letra / número en una pegatina. Esto permitió a MS verificar su clave y obtener el tipo de producto (Home, Professional, 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 documento (¡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 contra copias es solo un puesto: desafortunadamente, si vale la pena cualquier juego, alguien se romperá (o al menos evitará) ) el algoritmo de clave de CD y todas las otras protecciones de copyright.

REAL CORRECTA MANERA 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 hacer uso de él (por ejemplo, tener una cuenta de WoW). El algoritmo de clave de CD para World of Warcraft, utilizado, por ejemplo, cuando se compran tarjetas de tiempo de juego, probablemente se parece a esto:

  1. Genera un número aleatorio criptográficamente seguro muy grande.
  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 pueda volver a usarse.

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

Cuando originalmente escribí esta respuesta, asumí que la pregunta era sobre 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 desde el lado del servidor).

Con la verificación fuera de línea, lo más difícil es garantizar que pueda generar un gran número 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 soy muy versado en matemáticas, pero me sorprendió 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, de modo que puede generar claves eligiendo puntos aleatorios en ese gráfico y codificando los valores de alguna manera.

enter image description here

Como ejemplo, graficaremos este gráfico, seleccionaremos cuatro puntos y codificaremos en una cadena como “0, -500; 100, -300; 200, -100; 100,600”

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

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

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

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

Consulte este artículo sobre la verificación de clave parcial 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 contracargos o compras con tarjetas de crédito robadas.

  • No hay que “llamar a casa” para probar las llaves. Aunque esta práctica es cada vez más frecuente, todavía no la aprecio como usuario, por lo que no pediré a mis usuarios que la soporten.

  • No debería ser posible para un cracker desarmar nuestra aplicación lanzada y producir un “keygen” de trabajo a partir de ella. Esto significa que nuestra aplicación no probará completamente una clave para la verificación. Solo parte de la clave debe ser probada. 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 funcionará 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 parezca 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 desee ir por el camino de la activación en línea), aquí hay algunas maneras en que uno podría hacer una clave:

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

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

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

Estos todavía están abiertos al ataque: el progtwig todavía está allí y se puede parchear para eludir el control. Cleverer podría cifrar parte del progtwig utilizando el valor conocido de mi tercer método, en lugar de almacenar el valor en el progtwig. De esa manera, tendrías que encontrar una copia de la clave antes de poder descifrar el progtwig, pero aún es vulnerable a ser copiado una vez descifrado y a que una persona tome su copia legítima y la use para permitir que todos los demás accedan al software.

Las teclas de CD 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á en .net, casi puede 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 importa cuán segura se generó, ya que se reduce a “Buscar todo lo que se transfiere y verificar si alguien más ya lo está usando”.

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

  • Tener una sum de comprobació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 dicho control en el instalador en realidad significa que escribir un generador de claves es trivial ya que el pirata informático tiene todo el código que necesita. comprobar y confiar exclusivamente en la validación del lado del servidor deshabilita esa comprobació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. Intenta escribir una clave de CD y adivinar “¿Es esto un 8 o un B? A 1 o un I? Q o un O o un 0?” – al usar un subconjunto de caracteres / dígitos no ambiguos, se elimina esa confusión.

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

Si no está particularmente preocupado con la longitud de la clave, un método bastante probado y verdadero es el uso del 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 encripta esto usando tu clave privada para obtener tu 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 porción de firma fija de.

Esto entonces evita que alguien adivine qué es la clave del CD para el nonce 0002 porque no tienen la clave privada.

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

La parte positiva es que este método funcionará sin “activación” y puede usar cosas como una dirección de correo electrónico o el nombre del titular de licencia como nonce.

El sistema clave debe tener varias propiedades:

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

Una solución que debería proporcionarle esto sería usar 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 la CPU-ID, más algunas otras cosas, concatene todo junto y tome un MD5 del resultado (realmente no desea ser manejar información de identificación personal si no es necesario)) anexar el número de serie del CD y rechazar iniciar 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 progtwig enviándole el blob y envía la firma.

Los posibles problemas incluyen que está ofreciendo firmar prácticamente cualquier cosa, por lo que debe asumir que alguien ejecutará un texto simple elegido y / o los ataques de texto cifrado elegidos . Esto se puede mitigar comprobando el número de serie proporcionado y negándose a atender la solicitud de los no válidos, así como negándose a manejar más de un número determinado de consultas de una s / n dada en un intervalo (digamos 2 por año)

Debo señalar algunas cosas: en primer lugar, un atacante experto y determinado podrá eludir toda y cualquier seguridad en las partes a las que tienen acceso sin restricciones ( es decir, todo lo que contiene el CD), lo mejor que puede hacer en esa cuenta es dificultar el acceso ilegítimo a obtener 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 que se trata aquí, luego se llama a la línea de soporte de Adobe. La clave del CD se entrega al representante de Adobe y devuelve un número de activación para ser utilizado por el usuario.

Sin embargo, a pesar de dividirse en etapas, esto se debe a 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 original del CD se descubrió rápidamente, y se crearon 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 verifiquen el producto. En el futuro, es fácil ver cómo se eliminarían estos métodos ya que el acceso a internet se vuelve omnipresente.

Todos los algoritmos de protección contra copia solo de CD incomodan a los usuarios honestos sin proporcionar protección alguna 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 distribuirlos.

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 implican que el usuario proporcione al proveedor del 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 requiere acceso en línea para registrar el software en el sitio web del proveedor. a cambio recibes una ficha de activación. 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 tienes acceso limitado a la red o si estás atrapado detrás de un firewall.

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