implementación para claves de producto [cerrado]

Question

Estoy implementando una pequeña aplicación en C, que me gustaría vender como shareware a un precio razonable más adelante. Comenzará con una prueba de 30 días, que ya estoy bastante seguro de cómo implementarlo.

Sin embargo, el problema que tengo es que no estoy muy seguro de cómo implementar la verificación de la clave del producto. Lo que tengo en mente es que el cliente puede registrarse en mi página web (después de probar el producto por un tiempo), pagar el producto y obtener una clave de producto en forma de aaaaa-bbbbb-ccccc-ddddd-eeeee a través de e -mail (o tal vez disponible a través de su perfil en mi sitio web). No hay problema hasta ahora. Luego, suelta la clave en los campos de clave apropiados en mi aplicación y boom la aplicación se registra.

Por lo que pude reunir hasta ahora, la gente recomienda AES o RSA para esto. Para ser honesto, fui en otra dirección en la universidad (no en criptografía) y la única clase de criptografía que tomé fue hace algún tiempo. Pero por lo que recuerdo, AES es un algoritmo de cifrado simétrico, lo que significaría que solo tendría una clave para el cifrado y descifrado, ¿verdad? ¿Cómo podría generar miles de claves de producto y aún validarlas en mi aplicación (que por cierto no requerirá acceso a Internet ... así que no volveré a consultar con un servidor)?

¿Entonces supongo que RSA sería el camino a seguir? ¿Pero RSA no produce claves bastante largas (al menos más largas que los 25 caracteres requeridos desde arriba)?

En otro hilo Leí que algunos productos ni siquiera usarán el cifrado para la generación / verificación de la clave del producto, sino que solo emplean algunas verificaciones como "agregar el carácter 2. y 17. y eso debería sumar un total de x".

¿Cuál es la forma más rápida, fácil y segura de llegar aquí? :-) ¡Las muestras de código serían azúcar!

Saludos,

Sebastián

PD: Oh ... y por favor no me digas cómo se puede descifrar mi llave en algún momento ... Lo sé, y eso es principalmente por lo que no quiero gastar mucho. de vez en cuando con este problema, pero al mismo tiempo no lo hago demasiado fácil para el cracker ocasional.

Answer 1

Los algoritmos simétricos son limitados, ya que cualquier cracker novato con un desensamblador puede encontrar su clave (o el algoritmo utilizado para generar una) y crear un "keygen".

Por esta razón, la criptología asimétrica es el camino a seguir. La premisa básica es algo como esto:

• Cuando el usuario compra una licencia de usted, usted recopila ciertos detalles de identificación sobre el usuario y / o su entorno (generalmente, este es solo un nombre completo; a veces también una empresa).
• Haces un hash MD5 de 128 bits de esta información.
• Usando un criptor elíptico de 128 bits, encripte este hash usando el clave privada en el servidor.
• El texto cifrado de 128 bits se puede representar al usuario como una cadena de 25 caracteres que consta de letras y dígitos (además de guiones de separación para facilitar la lectura). Observe que 26 letras + 10 dígitos = 36 valores discretos, y que 36 ^ 25 > 2 ^ 128.
• El usuario escribe esta clave de producto en su diálogo de registro. El software del cliente lo convierte de nuevo a un número de 128 bits (16 bytes), descifra eso usando la clave pública de su criptografía EC y compara el resultado con un hash MD5 de la información personal del usuario, que debe coincidir con lo que se usó para el registro .

Esta es solo la idea básica, por supuesto. Para obtener más detalles y el código fuente, consulte Claves de producto basadas en criptografía de curva elíptica .

Answer 2

La vida es más simple si simplemente compra una solución.

http://www.kagi.com/kagisolutions/index.php

Kagi le permite cobrar pagos y le ayudan a administrar las claves.

Answer 3

Un hombre ha blogueado sobre cómo manejó la cuestión de los números de registro. Una de sus entradas de blog es Generando números de registro únicos .

Answer 4

Sí, RSA y AES son dos cosas muy diferentes:

• RSA es criptografía de clave pública, que involucra una clave pública y una clave privada, y es bastante lenta. El uso principal es configurar un intercambio seguro de una clave de sesión de cifrado simétrica.
• AES es cifrado simétrico, que es rápido y seguro.

Dado que su aplicación no se comunica a través de canales públicos y el uso de la criptografía se limita a la activación / registro del producto, querrá utilizar un cifrado simétrico. Los beneficios de los cifrados de clave pública están en la gestión de claves, que manejará en su sitio web o por correo electrónico.

Tenga en cuenta que no tiene que distribuir la misma clave para cada cliente. Puede generar un hash de parte de la información de registro y XOR con otra cosa (una clave de sesión fija, tal vez). Envíe eso al cliente, y el programa podría generar el mismo hash y XOR será la clave que envió para producir la clave fija original.

Tratar con la criptografía no es algo que se haga a la ligera. Como mencionas, esperas que esto se resquebraje. Si está haciendo lo suyo, esto seguramente sucederá. Todavía puede usar su propia implementación para "mantener a las personas honestas honestas". pero date cuenta de que es lo más lejos que llegarás. Si necesita algo más fuerte, entonces debe comprar una solución después de hacer una investigación exhaustiva sobre las soluciones.

Answer 5

Puede consultar este Artículo del proyecto de código . Describe una implementación de una clave de software basada en la dirección MAC de la máquina donde se ejecuta el software. El método no es ideal, como admite el propio autor, y es un poco diferente de lo que está buscando, pero tal vez pueda ayudarlo.