security - services - ¿Cómo se generan las claves de licencia del software?
rsa c# (9)
Las claves de licencia son el estándar de facto como medida antipiratería. Para ser honesto, esto me parece (in) 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 clave de licencia? ¿Qué primitiva criptográfica (si la hay) están usando? ¿Es un resumen del mensaje? Si es así, ¿qué datos estarían hash? ¿Qué métodos emplean los desarrolladores para dificultar a los crackers construir sus propios generadores clave? ¿Cómo se hacen los generadores clave?
Consulte este artículo sobre la verificación de clave parcial que cubre los siguientes requisitos:
Las claves de licencia deben ser fáciles de escribir.
Debemos poder incluir en la 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 teclas. Aunque esta práctica es cada vez más frecuente, todavía no lo aprecio como usuario, por lo que no les pediré a mis usuarios que lo toleren.
No debería ser posible para un cracker desensamblar 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 verificación. Solo algunas de las claves deben ser probadas. 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 parece funcionar, pero falla en una versión futura debido a un error tipográfico.
Cuando escribí esta respuesta originalmente, se suponía 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 mucho más fácil de manejar (la mayor parte de la lógica se puede hacer desde el servidor).
Con la verificación fuera de línea, lo más difícil es asegurarse de que puede generar una gran cantidad de claves de licencia únicas y aún así mantener un algoritmo sólido que no se comprometa fácilmente (como un simple dígito de control)
No estoy muy versado en matemáticas, pero me pareció que una forma de hacer esto es usar una función matemática que traza una gráfica
La línea trazada puede tener (si usa una frecuencia lo suficientemente fina) miles de puntos únicos, por lo que puede generar claves al seleccionar puntos aleatorios en ese gráfico y codificar los valores de alguna manera
Como ejemplo, trazaremos este gráfico, seleccionaremos 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 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 un 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 de código bastante pequeña que permitiría generar una gran cantidad de claves únicas y válidas
Sin embargo, es mucha seguridad por oscuridad. Cualquier persona que se tome el tiempo de desensamblar el código podrá encontrar la función de gráficos y las claves de encriptación, luego simular un generador de claves, pero probablemente sea muy útil para reducir la piratería informal.
El sistema de claves debe tener varias propiedades:
- muy pocas claves deben ser válidas
- las claves válidas no deben ser derivadas 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 proporcionarle sería utilizar un esquema de firma de clave pública . Comience con un "hash del sistema" (por ejemplo, tome los macs de cualquier NIC, la información de ID de CPU, más algunas otras cosas, concatene todo y tome un MD5 del resultado (realmente no quiere estar manejo de información de identificación personal si no tiene que hacerlo)) agregue el número de serie del CD y rechace el inicio 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.
Los problemas potenciales incluyen que está ofreciendo firmar prácticamente cualquier cosa, por lo que debe asumir que alguien ejecutará un texto sin formato y / o ataques de texto cifrado seleccionados . Esto puede mitigarse verificando el número de serie proporcionado y negándose a manejar solicitudes de solicitudes no válidas, así como negándose a manejar más de un número dado de consultas de un s / n determinado en un intervalo (por ejemplo, 2 por año)
Debo señalar algunas cosas: primero, un atacante hábil y determinado será capaz de eludir cualquier seguridad en las partes a las que tiene 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 de lo que es obtener acceso legítimo. Segundo, no soy un experto, por lo que podría haber serias fallas en este esquema propuesto.
Las claves de CD no son una gran seguridad para cualquier cosa que no esté 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 sea que haya pasado y comprobar si alguien más ya lo está utilizando".
Dicho esto, es posible que desee utilizar un algoritmo para lograr dos objetivos:
- Tener una suma de comprobación de algún tipo. Eso permite que su instalador muestre el mensaje "La clave no parece válida", únicamente para detectar errores de escritura (agregar dicha comprobación 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. verifique y confiando ú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 clave de CD ya que no son conscientes del error tipográfico)
- Trabaja con un subconjunto de caracteres limitado. 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?" - al usar un subconjunto de caracteres / dígitos no ambiguos, se elimina esa confusión.
Dicho esto, aún 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 aún en una caja en un estante de una tienda) y atornille a un cliente legítimo que compre esa caja. .
No tengo ninguna experiencia con lo que la gente realmente hace para generar claves de CD, pero (suponiendo que no quiera ir por el camino de la activación en línea), aquí hay algunas maneras en que se puede crear una clave:
Requerir que el número sea divisible por (digamos) 17. Trivial para 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.
Requerir que la primera mitad de la clave, cuando se concatena con un valor conocido, se transfiera a la segunda mitad de la clave. Mejor, pero el programa aún contiene toda la información necesaria para generar claves, así como para 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 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á ahí y puede ser parcheado para evitar el cheque. Cleverer podría ser cifrar parte del programa usando 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 es vulnerable a que se copie una vez que se descifre ya que una persona tome su copia legítima y la use para permitir que todos los demás puedan acceder al software.
Para las claves de CD de la vieja escuela, era solo una cuestión de crear un algoritmo para el cual las claves de CD (que podrían ser cualquier cadena) sean fáciles de generar y fáciles de verificar, pero la proporción de claves válidas de CD a no válidas -keys es tan pequeño que es poco probable que adivinar aleatoriamente las claves de un CD le proporcione una válida.
MANERA INCORRECTA DE HACERLO:
Starcraft y Half-Life utilizaron la misma suma de comprobación, donde el 13º dígito verificó los 12 primeros. Por lo tanto, podría ingresar cualquier cosa para los 12 primeros dígitos y adivinar el 13º (solo hay 10 posibilidades), lo que lleva al 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 bastante información, la cifra y coloca la codificación de la letra / número en una etiqueta. Esto permitió a MS verificar su clave y obtener el tipo de producto (Casa, 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 this (¡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 copia es solo un estancamiento: desafortunadamente, si vale la pena jugar un juego, alguien se romperá (o al menos evitará) ) el algoritmo de clave de CD y todas las demás protecciones de derechos de autor.
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 cualquier uso del mismo (por ejemplo, tener una cuenta de WoW). El algoritmo de clave de CD para World of Warcraft (usado, por ejemplo, al comprar tarjetas de tiempo de juego) probablemente se parece a esto:
- Genera un número aleatorio seguro criptográficamente muy grande.
- Guárdelo en nuestra base de datos e imprímalo en la tarjeta.
Luego, cuando alguien ingresa 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 más pueda ser usado.
Para los servicios en línea, no hay razón para no usar el esquema anterior; Usar cualquier otra cosa puede llevar a problemas .
Si no está especialmente preocupado por la longitud de la clave, un método bastante probado 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.
Luego encripta esto usando tu clave privada para obtener tu clave de CD que es algo así como: ABCDEF9876543210
Luego distribuye la clave pública con tu aplicación. La clave pública se puede usar para descifrar la clave del CD "ABCDEF9876543210", que luego verifica la parte de la firma fija.
Esto evita que alguien adivine cuál es la clave del 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 al usar 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 puedes usar cosas como una dirección de correo electrónico o el nombre del titular de la licencia como nonce.
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 de clave de CD tradicional descrito aquí, luego se llama a la línea de soporte de Adobe. La clave del CD se le entrega al representante de Adobe y le devuelven un número de activación para que lo use el usuario.
Sin embargo, a pesar de estar dividido en pasos, esto se debe a los mismos métodos de craqueo que se utilizan para el proceso normal. El proceso utilizado para crear una clave de activación que se verifica con la clave del CD original 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 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 vuelve omnipresente.
Todos los CD solo protegen los algoritmos de protección contra los usuarios honestos y no ofrecen 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 distribuirlas.
No importa cuán seguro criptográficamente realice el código, debe suministrarlo 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 que requiera acceso en línea para registrar el software en el sitio web de los proveedores y a cambio recibir un token de activación. La primera opción requiere una gran cantidad de administración manual y solo vale la pena por un software de muy alto valor, la segunda opción puede ser falsificada y es absolutamente irritante si tiene acceso a la red limitado o está atascado detrás de un firewall.
En general, es mucho más fácil establecer una relación de confianza con sus clientes.