language agnostic - ¿Cuál es un buen enfoque para desarrollar un simple generador/verificador de números de serie?

language-agnostic license-key (5)

Estoy trabajando en una aplicación que me gustaría vender algún día, ¡más temprano que tarde! Me gustaría desarrollar un esquema de número de serie razonablemente simple para protegerlo.

Una combinación simple de números / letras de no más de 25-30 caracteres alfanuméricos de largo (piense en las claves de los productos de Microsoft)
No requiere que el usuario ingrese ninguna información personal (como una dirección de correo electrónico) como parte de la verificación

He estado pensando en esto (muy poco), y creo que la criptografía de clave pública es un buen lugar para comenzar. Podría generar una cadena que identifique la licencia (como el número de serie integral SKU + plain ole), codificarla, encriptarla y codificar el número de serie + identificador en una clave alfanumérica de 25 dígitos (más o menos). La aplicación decodificaría la clave en un número de serie y "firma", generaría un hash identificador, descifraría la "firma" utilizando una clave pública correspondiente y la compararía con el hash identificador generado.

Básicamente, la clave del producto contiene dos datos: el número de serie que el usuario afirma poseer y una especie de firma que el programa puede usar para verificar esa afirmación. No sé si 25 caracteres alfanuméricos (que codifican 5 bits cada uno para un total realista de 120 bits) son suficientes para todo esto. Pero no tiene que ser criptográficamente seguro, lo suficiente como para que los códigos no sean fáciles de adivinar. Estoy bien con longitudes de clave cortas y hashes cortos.

En lo que respecta a la implementación, la aplicación está escrita en Objective-C para Mac OS X, pero dado lo fácil que es inyectar código en las aplicaciones de Cocoa, probablemente escriba el código de verificación en C.

No usaría ninguna criptografía fuerte, ya que tiene que descifrarla en el programa de todos modos, haciendo que los keygens o al menos las grietas sean fáciles de hacer.

Haría lo siguiente: tomar, digamos, un número de 25 dígitos. Ahora agregue algunas reglas, como: - el número debe ser divisible por 31 - debe comenzar y finalizar con la última letra ...

Genere siempre claves usando estas reglas. Use 20 reglas o más (más, mejor). Al implementar la aplicación, use un número menor de reglas, por ejemplo, 10 para verificar si la clave es válida. Estas reglas serán luego desarmadas y usadas para crear keygen.

En cada actualización habilite una de las reglas que no utilizó antes. Si las reglas se seleccionan correctamente, deshabilitará la mayoría de las claves generadas por keygens.

Como Redbeard 0x0A es correcto, las teclas de CD son para mantener honestos a los clientes honestos. Simplemente debe ser un poco menos difícil comprar su producto que encontrar un keygen.

Si está vendiendo su producto en línea, entonces la mejor manera de hacerlo es darles un archivo que contenga el número de serie. De esta manera, el número de serie puede ser el tiempo que desee y sus clientes que pagan no tengan que perder tiempo ingresando a una serie.

Un esquema en serie puede ser muy simple:

Tener un espacio serial grande (25 alfanuméricos es aproximadamente 10 ⁴⁴ , pero solo use un archivo serial y haga 80 char x 16 filas para un espacio clave de 10 ²³¹¹ )
Seleccione algunas reglas para reducir el espacio de número de serie válido a 100 veces más de lo que cree que va a vender en sus sueños más locos

Si su producto tiene un componente en línea (como cómo los juegos tienen multijugador en línea), puede reducir los números de serie válidos usando un generador de números aleatorios criptográficamente fuerte (para seleccionar un subconjunto de las claves basadas en reglas, reglas de productos para verificar serial, usos del servidor lista serial verdadera final). Cuando su producto solicita el servicio de su servidor, el servidor puede verificar la serie.

Me gusta el método de @ bh213, sin embargo, no va a evitar que se solucionen los cambios de clave a medida que actualiza sus reglas de número de serie.

En una nota de preferencia más personal, prefiero el generador de claves basado en un método de conjunto de reglas, porque si los piratas informáticos tienen que aplicar parches a un binario, puede obtener una mala revisión de su software debido a un parche de hacker malo y la batalla entre usted y piratas informáticos.

Mi preferencia se basa en una verdad universal del software: el software puede ser pirateado si es lo suficientemente popular, no existe un esquema, ningún método ingenioso que evite que esto suceda. Esta batalla es entre el desarrollador que tiene recursos limitados y tiempo limitado y un grupo de piratas informáticos con tiempo ilimitado en sus manos.

Su esquema de generación de claves es realmente solo para mantener honestos a los clientes honestos, es más fácil obtener un corte de cheque de Cuentas por Pagar de lo que es lograr que Security firme en un generador de claves.

Todas las reglas, ya sea desarrolladas a medida o basadas en cifrado, pueden descubrirse y descifrarse. Piensa para quién estás creando tu solicitud. Muchos de mis productos son para empresas, de modo que lo van a comprar o no lo harán. Por lo general, no van a ejecutar una versión pirateada en sus redes. No es probable que las personas que buscan un keygen compren tu producto independientemente. Solo quiere asegurarse de no molestar a su cliente hasta el punto en que ya no quiera comprar su aplicación.

Habiendo dicho eso, he escrito una biblioteca para este tipo de cosas para usar en mis aplicaciones basadas en encriptación AES. Lo estoy vendiendo por $ 25, y usa una frase de contraseña y una sal para hacer que su número de serie sea único. Si está interesado, puede encontrarlo aquí: http://simpleserials.com

Hay una publicación en el blog en sigpipe.macromates.com que explica cómo usar la clave criptográfica privada / pública para verificar un número de serie. Puede verificar que el usuario y el número de serie coincidan. (Firmando / Verificar). Probablemente agregue algo de sal, solo para estar seguro.

Como esta publicación es de 2004, debe considerar la longitud de clave recomendada en keylength.com .