¿Cómo se generan las claves de licencia de software?
Las claves de licencia son el estándar de facto como medida anti-piraterí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. ¿Qué es un buen ejemplo (seguro) de generación de claves de licencia? ¿Qué primitivo criptográfico (si lo hay) están usando? ¿Es un resumen de mensajes? Si es así, ¿qué datos estarían hash? ¿Qué métodos emplean los desarrolladores para dificultar que los crackers construyan sus propios generadores de claves? Cuan ¿se fabrican generadores de llaves?
9 answers
Para las claves de CD de la vieja escuela, era solo una cuestión de hacer un algoritmo para el que 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 claves de CD válidas y las claves de CD no válidas es tan pequeña que adivinar aleatoriamente las claves de CD es poco probable que obtenga una válida.
FORMA INCORRECTA DE HACERLO:
Starcraft y Half-life ambos usaron la misma suma de verificación, donde el dígito 13 verificó los primeros 12. Por lo tanto, usted podría introducir cualquier cosa para el los primeros 12 dígitos, y adivina el 13 (solo hay 10 posibilidades), lo que lleva a la infame 1234-56789-1234
El algoritmo para verificar es público, y se ve algo como esto:
x = 3;
for(int i = 0; i < 12; i++)
{
x += (2 * x) ^ digit[i];
}
lastDigit = x % 10;
FORMA CORRECTA DE HACERLO
Windows XP toma un poco de información, la encripta y coloca la codificación de letras/números en una etiqueta. Esto permitió a MS verificar su clave y obtener el tipo de producto (Hogar, Profesional, etc.) al mismo tiempo. Además, se requiere activación en línea.
El algoritmo completo es bastante complejo, pero se describe muy bien en este (completamente legal!) paper, published in Germany.
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 estancamiento: desafortunadamente, si se trata de un juego que vale la pena, alguien romperá (o al menos eludirá) el algoritmo de CD-key y todos los demás derechos de autor protección.
REAL FORMA 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 hacer uso de él (por ejemplo. tener una cuenta WoW). El algoritmo de clave de CD para World of Warcraft-utilizado, por ejemplo, al comprar cartas de tiempo de juego - probablemente se vea algo como esto:
- Generar un número aleatorio criptográficamente seguro muy grande.
- Guárdelo en nuestro base de datos e imprimirlo en la tarjeta.
Luego, cuando alguien ingrese un número de playtime-card, 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 no para usar el esquema anterior; usar cualquier otra cosa puede conducir a problemas.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-12-08 18:50:45
Cuando originalmente escribí esta respuesta fue bajo la suposición de que la pregunta estaba relacionada con la validación 'offline' 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 en el lado del servidor).
Con la verificación fuera de línea lo más difícil es asegurarse de que puede generar un gran número de claves de licencia únicas, y aún así mantener un algoritmo fuerte que no se vea fácilmente comprometido (como un dígito de control simple)
No estoy muy versado en matemáticas, pero me llamó la atención que una forma de hacer esto es usar una función matemática que traza un gráfico
La línea trazada puede tener (si utiliza una frecuencia lo 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"
Cifraremos la cadena con una clave conocida y fija (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 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 un gran número de único y válido claves a generar
Sin embargo, es mucha seguridad por oscuridad. Cualquiera que se tome el tiempo para desmontar el código sería capaz de encontrar la función gráfica y las claves de cifrado, a continuación, simular un generador de claves, pero es probablemente muy útil para frenar la piratería casual.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-09-16 11:40:35
Verifique este artículo sobre Verificación de Clave Parcial que cubre los siguientes requisitos:
Las claves de licencia deben ser lo suficientemente fáciles de escribir.
Debemos poder incluir en la lista negra (revocar) una clave de licencia en el caso de contracargos o compras con tarjetas de crédito robadas.
No "llamar a casa" para probar las llaves. Aunque esta práctica es cada vez más frecuente, todavía no lo aprecio como usuario, por lo que no pediré a mis usuarios que pongan consigo.
No debería ser posible que un cracker desmonte nuestra aplicación lanzada y produzca un "keygen" de trabajo a partir de ella. Esto significa que nuestra aplicación no probará completamente una clave para la verificación. Solo algunas de las claves deben ser probadas. Además, cada versión de la aplicación debe probar una porción diferente de la clave, para que una clave falsa basada en una versión anterior no funcione en una versión posterior de nuestro software.
Importante: no debe ser es 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.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-10-31 14:33:17
No tengo ninguna experiencia con lo que la gente realmente hace para generar claves de CD, pero (suponiendo que no quieres ir por el camino de la activación en línea) aquí hay algunas maneras en que uno podría hacer una clave:
Requiere que el número sea divisible por (digamos) 17. Trivial de adivinar, si tiene acceso a muchas claves, pero la mayoría de las cadenas potenciales no serán válidas. Similar sería requerir que la suma de verificación de la clave coincida con un valor conocido.
Requieren que el la primera mitad de la clave, cuando se concatena con un valor conocido, se reduce a la segunda mitad de la clave. Mejor, pero el programa todavía contiene toda la información necesaria para generar claves, así como para validarlas.
Generar claves cifrando (con una clave privada) un valor conocido + nonce. Esto se puede verificar descifrando utilizando 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.
Estos todavía están abiertos al ataque: el programa todavía está allí y puede ser parcheado para omitir la comprobación. Más inteligente podría ser cifrar 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 todavía es vulnerable a ser copiado una vez descifrado y a tener una persona que tome su copia legítima y la use para habilitar a todos de otra manera para acceder al software.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-06-21 21:31:15
Las claves de CD no son una gran seguridad para cualquier cosa que no esté en red, por lo que técnicamente no necesitan generarse 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 pase y verificar si alguien más ya lo está usando".
Dicho esto, es posible que desee utilizar un algorhithm para lograr dos objetivos:
- Tener una suma de comprobación de algún tipo. Eso permite a su instalador para mostrar" Clave no parece válido " mensaje, únicamente para detectar errores tipográficos (La adición de un cheque en el instalador en realidad significa que la escritura de un generador de claves es trivial como el hacker tiene todo el código que necesita. No tener la comprobación y confiar únicamente 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 CD Key, ya que no son conscientes de la errata)
- Trabaja con un subconjunto limitado de caracteres. Tratando de escribir en una clave de CD y adivinar " Es esto un 8 o una B? ¿un 1 o una I? ¿una Q o una O o un 0?"- mediante el uso de un subconjunto de caracteres/dígitos no ambiguos se 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 un estante de la tienda) y atornille a un un cliente legítimo que compra esa caja.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-06-10 00:45:19
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 tienen algún tipo de nonce y una firma fija.
Por ejemplo: 0001-123456789
Donde 0001 es su nonce y 123456789 es su firma fija.
A continuación, cifrar esto usando su clave privada para obtener su clave de CD que es algo como: ABCDEF9876543210
Luego distribuya la clave pública con su solicitud. La clave pública se puede utilizar para descifrar la clave de CD "ABCDEF9876543210", que luego verificar la parte de firma fija de.
Esto entonces evita que alguien adivine cuál es la clave de CD para el nonce 0002 porque no tienen la clave privada.
El único inconveniente importante es que sus claves de CD serán bastante largas cuando se utilizan 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 el nombre del licenciatario como el nonce.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-06-20 23:35:52
El sistema de claves debe tener varias propiedades:
- muy pocas claves deben ser válidas
- las claves válidas no deben ser derivables incluso teniendo en cuenta 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 darte esto sería usar un esquema de firma de clave pública . Comience con un "hash del sistema" (por ejemplo, agarra las MAC en cualquier NIC, ordenadas, y la información de CPU-ID, además de algunas otras cosas, concatenar todo junto y toma un MD5 del resultado (realmente no quieres manejar información de identificación personal si no tienes que hacerlo)) agrega el número de serie del CD y rehúsa arrancar a menos que alguna clave del registro (o algún archivo de datos) tenga una firma válida para el blob. El usuario activa el programa enviando el blob a usted y usted envía de vuelta la firma.
Los problemas potenciales incluyen que usted está ofreciendo firmar prácticamente cualquier cosa por lo que necesita asumir que alguien lo hará ejecute un ataque de texto plano y/o de texto cifrado elegido. Eso se puede mitigar comprobando el número de serie proporcionado y negándose a manejar solicitudes de personas invá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: Primero, un atacante hábil y determinado será capaz de eludir cualquier y toda la seguridad en las partes a las que tienen acceso sin restricciones (es decir, todo en el CD), lo mejor que puede hacer en ese sentido es hacer más difícil obtener acceso ilegítimo que obtener acceso legítimo. Segundo, no soy un experto, así que podría haber fallas serias en este esquema propuesto.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-06-21 23:26:42
También hay comportamientos 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 de clave de CD tradicional discutido aquí, luego se llama a la línea de soporte de Adobe. La clave del CD se entrega al representante de Adobe y este le devuelve un número de activación para que lo utilice el usuario.
Sin embargo, a pesar de estar dividido en pasos, esto cae presa de los mismos métodos de craqueo utilizado para el proceso normal. El proceso utilizado para crear una clave de activación que se comprueba contra la clave de CD original fue descubierto 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 verifiquen 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 vuelve ubicuo.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-06-21 19:44:57
Todos los algoritmos de protección de copia de CD solo afectan a usuarios honestos mientras no proporcionan protección contra la piratería en absoluto.
El "pirata" solo necesita tener acceso a un cd legítimo y su código de acceso, entonces puede hacer n copias y distribuirlas.
No importa cuán criptográficamente seguro sea el código, debe proporcionar esto con el CD en texto plano o un usuario legítimo no puede activar el software.
La mayoría de los esquemas seguros implican: el usuario 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 bien, requerir 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 una gran cantidad de administración manual y solo vale la pena para software de muy alto valor, la segunda opción puede ser falsificada y es absolutamente exasperante si tiene acceso limitado a la red o si está atrapado detrás de un cortafuegos.
En general, es mucho más fácil establecer una relación de confianza con sus clientes!
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-06-22 04:33:58