Cómo generar y validar una clave de licencia de software?

Hay muchas formas de generar claves de licencia, pero muy pocas de esas formas son verdaderamente seguras. Y es una lástima, porque para las empresas, las claves de licencia tienen casi el mismo valor que el efectivo real.

Lo ideal sería que sus claves de licencia tuvieran las siguientes propiedades:

1. Solo su empresa debería ser capaz de generar claves de licencia para sus productos, incluso si alguien realiza ingeniería inversa completa de sus productos (lo que sucederá, hablo por experiencia). Ofuscando la algoritmo u ocultar una clave de cifrado dentro de su software es realmente fuera de la cuestión si usted es serio sobre el control de licencias. Si su producto tiene éxito, alguien hará un generador de claves en cuestión de días desde el lanzamiento.

2. Una clave de licencia debe ser utilizable en un solo equipo (o al menos debería ser capaz de controlar esto muy estrechamente)

3. Una clave de licencia debe ser corta y fácil de escribir o dictar por teléfono. No quieres que todos los clientes llamar al soporte técnico porque no entienden si la clave contiene una "l" o un "1". Su departamento de soporte le agradecería por esto, y tendrá costos más bajos en esta área.

Entonces, ¿cómo resuelves estos desafíos ?

1. La respuesta es simple pero técnicamente desafiante: firmas digitales usando criptografía de clave pública. Sus claves de licencia deben ser de hecho "documentos" firmados, que contienen algunos datos útiles, firmados con la clave privada de su empresa. Las firmas deben formar parte de la clave de licencia. El producto debe validar las claves de licencia con la clave pública correspondiente. De esta manera, incluso si alguien tiene acceso completo a la lógica de su producto, no pueden generar claves de licencia porque no tienen la clave privada. Una clave de licencia se vería así: BASE32 (CONCAT (DATA, PRIVATE_KEY_ENCRYPTED (HASH (DATA)))) El mayor desafío aquí es que los algoritmos clásicos de clave pública tienen grandes tamaños de firma. RSA512 tiene una firma de 1024 bits. No querrás que tus claves de licencia tengan cientos de caracteres. Uno de los enfoques más poderosos es utilizar criptografía de curva elíptica (con implementaciones cuidadosas para evitar las patentes existentes). Las llaves ECC son como 6 veces más cortas que las llaves RSA, para la misma fuerza. Puede reducir aún más los tamaños de firma utilizando algoritmos como el algoritmo de firma digital Schnorr (la patente expiró en 2008-bueno :) )

2. Esto se puede lograr mediante la activación del producto (Windows es una buena ejemplo). Básicamente, para un cliente con una clave de licencia válida, debe generar algunos "datos de activación", que es un mensaje firmado que incluye el id de hardware de la computadora como los datos firmados. Esto generalmente se hace a través de Internet, pero solo UNA VEZ: el producto envía la clave de licencia y el id de hardware del equipo a un servidor de activación, y el servidor de activación devuelve el mensaje firmado (que también se puede hacer corto y fácil de dictar por teléfono). A partir de ese momento, el producto no compruebe la clave de licencia en el inicio, pero los datos de activación, que necesita que el equipo sea el mismo para validar (de lo contrario, los DATOS serían diferentes y la firma digital no validaría). Tenga en cuenta que la comprobación de datos de activación no requiere verificación a través de Internet: es suficiente verificar la firma digital de los datos de activación con la clave pública ya incrustada en el producto.

3. Bueno, solo elimina caracteres redundantes como "1", " l", "0"," o " de tus llaves. Dividir la cadena de clave de licencia en grupos de caracteres.

Respuesta simple: No importa qué esquema use, se puede descifrar.

No castigue a los clientes honestos con un sistema destinado a prevenir a los hackers, ya que los hackers lo descifrarán de todos modos.

Un código hash simple vinculado a su correo electrónico o similar probablemente sea lo suficientemente bueno. Los ID basados en hardware siempre se convierten en un problema cuando las personas necesitan reinstalar o actualizar el hardware.

Buen hilo sobre el tema: http://discuss.joelonsoftware.com/default.asp?biz.5.82298.34

Al generar la clave, no olvide concatenar la versión y el número de compilación a la cadena en la que calcula el hash. De esa manera no habrá una sola llave que desbloquee todo lo que has lanzado.

Después de encontrar algunas teclas o parches flotando en astalavista.box.sk sabrás que lograste hacer algo lo suficientemente popular como para que alguien se molestara en romperlo. ¡Alégrense!

Además de lo que ya se ha dicho....

Cualquier uso de aplicaciones.NET es inherentemente rompible debido a los problemas de lenguaje intermedio. Un simple desmontaje del código.NET abrirá su producto a cualquier persona. Pueden omitir fácilmente su código de licencia en ese punto.

Ya ni siquiera puedes usar valores de hardware para crear una clave. Las máquinas virtuales ahora permiten a alguien crear una imagen de una máquina "con licencia" y ejecutarla en cualquier plataforma que elijan.

Si es un software caro, hay otras soluciones. Si no lo es, solo hazlo lo suficientemente difícil para el hacker casual. Y aceptar el hecho de que habrá copias sin licencia por ahí eventualmente.

Si su producto es complicado, los problemas de soporte inherentes serán crear algo de protección para usted.

El motor C#/. NET que utilizamos para la generación de claves de licencia ahora se mantiene como código abierto:

Https://github.com/appsoftware/.NET-Licence-Key-Generator .

Se basa en un sistema de "Verificación de Clave Parcial", lo que significa que solo un subconjunto de la clave que utiliza para generar la clave tiene que ser compilado en su distribuible. Usted crea las claves por sí mismo, por lo que la implementación de la licencia es única para su software.

Como se indicó anteriormente, si su código puede ser descompilada, es relativamente fácil eludir la mayoría de los sistemas de licencias.

No se cuan elaborado quieres ser

Pero creo que.net puede acceder al número de serie del disco duro.

Podría hacer que el programa le envíe eso y algo eles ( como el nombre de usuario y la dirección mac de la nic)

Calculas un código basado en eso y les envías la clave por correo electrónico.

Evitarán que cambien de máquina después de tener la llave.

He usado Crypkey en el pasado. Es uno de los muchos disponibles.

Solo puede proteger el software hasta cierto punto con cualquier esquema de licencia.

La única manera de hacer todo lo que pidió es requerir un acceso a Internet y verificación con un servidor. La aplicación debe iniciar sesión en el servidor con la clave y, a continuación, debe almacenar los detalles de la sesión, como la dirección IP. Esto evitará que la llave se use en varias máquinas diferentes. Esto generalmente no es muy popular entre los usuarios de la aplicación, y a menos que sea una aplicación muy costosa y complicada, no vale la pena.

Podrías simplemente tenga una clave de licencia para la aplicación, y luego verifique en el lado del cliente si la clave es buena, pero es fácil distribuir esta clave a otros usuarios, y con un descompilador se pueden generar nuevas claves.

He implementado una activación única basada en Internet en el software de mi empresa (C#. net) que requiere una clave de licencia que se refiere a una licencia almacenada en la base de datos del servidor. El software golpea el servidor con la clave y se le da información de licencia que luego se encripta localmente usando una clave RSA generada a partir de algunas variables (una combinación de CPUID y otras cosas que no cambiarán a menudo) en el equipo cliente y luego la almacena en el registro.

Requiere algunos codificación del lado del servidor, pero ha funcionado muy bien para nosotros y pude usar el mismo sistema cuando nos expandimos al software basado en navegador. También le da a su gente de ventas gran información sobre quién, dónde y cuándo se utiliza el software. Cualquier sistema de licencias que solo se maneja localmente es completamente vulnerable a la explotación, especialmente con la reflexión en. NET. Pero, como todos los demás han dicho, ningún sistema es totalmente seguro.

En mi opinión, si no está utilizando basado en la web licenciar, no tiene sentido proteger el software en absoluto. Con el dolor de cabeza que el DRM puede causar, no es justo para los usuarios que realmente han pagado para que sufran.

Creo firmemente que solo el sistema de licencias basado en criptografía de clave pública es el enfoque correcto aquí, porque no tiene que incluir la información esencial requerida para la generación de licencias en su código fuente.

En el pasado, he usado Biblioteca de Licencias de Treek muchas veces, porque cumple con estos requisitos y ofrece muy buen precio. Utiliza la misma protección de licencia para los usuarios finales y para sí mismo y nadie lo ha descifrado hasta ahora. También puede encontrar buenos consejos en el sitio web para evitar la piratería y el cracking.

No es posible prevenir completamente la piratería de software. Puede evitar la piratería casual y eso es lo que hacen todas las soluciones de licencias.

Las licencias bloqueadas por nodo (máquina) son mejores si desea evitar la reutilización de las claves de licencia. He estado usando Cryptlex durante aproximadamente un año para mi software. También tiene un plan gratuito , por lo que si no espera demasiados clientes, puede usarlo de forma gratuita.

Al igual que algunos otros mencionados, soy un enorme oponente de ser hostil a los clientes por defecto, algo por lo que la industria de licencias es notoria. Así que voy a ampliar en una buena solución para su problema que también ofrece un buen cliente UX.

Para empezar, usted mencionó que tiene una versión "limitada" de su software que está utilizando para tratar de convertir a los clientes a "actualizar" para características adicionales. Entonces, lo que está buscando son licencias de características para su producto, por ejemplo, un cliente puede comprar una licencia para feature-X o feature-Y.

Construí Keygen con este tipo de licencias en mente. Keygen es una API REST de licencias que le permite administrar cuentas de usuario, licencias y también rastrear el uso/asociaciones de máquinas.

Lo que haría es configurar 2 tipos de licencia (una política dentro de Keygen) donde uno es una política base para la versión gratuita limitada, y el otro es una política para el pago versión.

No estoy seguro de lo que estás usando para los pagos, pero supongamos que estás usando algo como Stripe (bastante estándar hoy en día) que ofrece webhooks. Keygen también tiene webhooks (si lo utiliza o no, todo esto sigue siendo aplicable). Puede integrar Keygen para hablar con su proveedor de pago utilizando webhooks de ambos lados (piense: customer.created->crear licencia base para el cliente, license.created->cobrar al cliente por la nueva licencia).

Así que mediante la utilización de webhooks, podemos automatizar creación de licencias para nuevos clientes. Entonces, ¿qué pasa con la validación de licencias dentro de la propia aplicación? Esto se puede hacer de varias maneras, pero la forma más popular es requerir que su cliente ingrese una clave de licencia larga en un campo de entrada que luego puede validar; creo que esta es una terrible manera de manejar la validación de licencias en su aplicación.

¿por Qué pienso eso? Bueno, en primer lugar, está requiriendo que su cliente ingrese una clave de licencia tediosamente larga que está destinada a el consumo de la máquina, y en segundo lugar su necesidad de que usted y su cliente para realizar un seguimiento de dicha clave de licencia tediosamente largo.

Bien, entonces, ¿cuál es una alternativa? Creo que la mejor alternativa es hacer algo a lo que todos sus clientes están acostumbrados: permitiéndoles crear una cuenta para su producto utilizando un correo electrónico/contraseña. A continuación, puede asociar todas sus licencias y sus máquinas con esa cuenta. Así que ahora, en lugar de ingresar una clave de licencia, simplemente pueden registrar en el uso de sus credenciales.

¿Qué ventaja te da eso? En primer lugar, se deshace de la necesidad de que usted y sus clientes realicen un seguimiento de las claves de licencia, ya que todo se maneja detrás de escena dentro de su cuenta de usuario y lo más importante: ahora puede ofrecer a sus clientes licencia de autoservicio y activación de la máquina! es decir, dado que todas sus licencias y máquinas están asociadas con su cuenta de usuario, puede solicitarles que compren una licencia cuando activan su aplicación en una máquina no reconocida.

Ahora en validación de licencias : cada vez que su cliente inicie sesión en su aplicación con su correo electrónico/contraseña, puede consultar su cuenta de usuario para las licencias que poseen para determinar si pueden usar feature-X o feature-Y. Y dado que su aplicación ahora es autoservicio , puede permitir que sus clientes compren funciones adicionales directamente desde su aplicación.

Así que hemos hemos introducido un ton de automatización en nuestro sistema de licencias, podemos licenciar características individuales (es decir, una versión limitada vs.completa), hemos ofrecido un impresionante UX para nuestros clientes y también hemos aliviado una de las razones más importantes para las solicitudes de soporte: license key recovery.

De todos modos, esto se hizo largo, pero con suerte ayuda a alguien!

Soy uno de los desarrolladores detrás de la plataforma de licencias de software Cryptolens y he estado trabajando en sistemas de licencias desde la edad de 14 años. En esta respuesta, he incluido algunos consejos basados en la experiencia adquirida a lo largo de los años.

La mejor manera de resolver esto es configurando un servidor de claves de licencia al que cada instancia de la aplicación llamará para verificar una clave de licencia.

Beneficios de un servidor de claves de licencia

Las ventajas de una clave de licencia el servidor es que:

1. siempre puede actualizar o bloquear una clave de licencia con efecto inmediato.
2. cada clave de licencia se puede bloquear a un número determinado de máquinas (esto ayuda a evitar que los usuarios publiquen la clave de licencia en línea para que otros la usen).

Consideraciones

Aunque verificar licencias en línea le da más control sobre cada instancia de la aplicación, la conexión a Internet no siempre está presente (especialmente si se dirige a empresas más grandes), por lo que necesitamos otra forma de realizar la verificación de la clave de licencia.

La solución es firmar siempre la respuesta de la clave de licencia desde el servidor utilizando un criptosistema de clave pública como RSA o ECC (posiblemente mejor si planea ejecutarse en sistemas embebidos). Su aplicación solo debe tener la clave pública para verificar la respuesta de la clave de licencia.

Así que en caso de que no haya conexión a Internet, puede usar la respuesta de la clave de licencia anterior en su lugar. Asegúrese de almacenar tanto el date and the machine identifier in the response and check that it's not too old (eg. permite que los usuarios estén fuera de línea como máximo 30 días, etc.) y que la respuesta de la clave de licencia pertenezca al dispositivo correcto.

Nota siempre debe verificar la respuesta del certificado de clave de licencia, incluso si está conectado a Internet), para asegurarse de que no se ha cambiado desde que salió del servidor (esto todavía tiene que hacerse incluso si su API a la el servidor de claves de licencia utiliza https)

Protegiendo algoritmos secretos

La mayoría de las aplicaciones.NET se pueden realizar ingeniería inversa con bastante facilidad (hay tanto un diassembler proporcionado por Microsoft para obtener el código IL y algunos productos comerciales incluso pueden recuperar el código fuente en, por ejemplo. C#). Por supuesto, siempre puedes ofuscar el código, pero nunca es 100% seguro.

En la mayoría de los casos, el propósito de cualquier solución de licencia de software es ayudar a las personas honestas a ser honestas (es decir, que honestas los usuarios que están dispuestos a pagar no se olviden de pagar después de que expire una prueba, etc.).

Sin embargo, es posible que todavía tenga algún código que de ninguna manera desea filtrar al público (por ejemplo. un algoritmo para predecir los precios de las acciones, etc.). En este caso, la única forma de hacerlo es crear un API endpoint al que su aplicación llamará cada vez que se ejecute el método. Requiere conexión a Internet, pero asegura que su código secreto nunca sea ejecutado por la máquina cliente.

Aplicación

Si no desea implementar todo usted mismo, le recomendaría echar un vistazo a este tutorial (parte de Cryptolens )

Puede usar una solución gratuita de terceros para manejar esto por usted, como Quantum-Key.Net Es gratis y maneja los pagos a través de paypal a través de una página de ventas web que crea para usted, la emisión de claves por correo electrónico y bloquea el uso de claves en un equipo específico para evitar la piratería.

También debe tener cuidado de ofuscar/cifrar su código o puede ser fácilmente ingeniería inversa utilizando software como De4dot y .NetReflector. Un buen ofuscador de código gratuito es ConfuserEx que es rápido y fácil de usar y más eficaces que las alternativas caras.

Debe ejecutar su software terminado a través de De4Dot y.NetReflector para hacer ingeniería inversa y ver lo que un cracker vería si hicieran lo mismo y para asegurarse de que no ha dejado ningún código importante expuesto o no disimulado.

Su software seguirá siendo descifrable, pero para el cracker casual bien puede ser suficiente para posponerlos y estos sencillos pasos también evitarán que su código se extraiga y reutilizado.

Https://quantum-key.net

¿Cómo usar ConfuserEx?

Https://github.com/0xd4d/de4dot

Https://www.red-gate.com/dynamic/products/dotnet-development/reflector/download