c# - traducir - ¿Cómo generar y validar una clave de licencia de software?

foxlearn license (15)

Actualmente estoy involucrado en el desarrollo de un producto (desarrollado en C #) que estará disponible para descargar e instalar de forma gratuita pero en una versión muy limitada. Para acceder a todas las funciones, el usuario tiene que pagar una tarifa de licencia y recibir una clave. Esa clave se ingresará en la aplicación para "desbloquear" la versión completa.

Como usar una clave de licencia como esa es algo usual, me pregunto:

¿Cómo se resuelve eso generalmente?
¿Cómo puedo generar la clave y cómo puede ser validada por la aplicación?
¿Cómo puedo evitar que una clave se publique en Internet y sea utilizada por otros que no han pagado la licencia (una clave que básicamente no es "suya")?

Supongo que también debería vincular la clave a la versión de la aplicación de alguna manera para que sea posible cargar nuevas claves en las versiones de características.

¿Algo más en lo que deba pensar en este escenario?

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

Cualquier uso de aplicaciones .NET es intrínsecamente rompible debido a problemas de idioma 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 momento.

Ya ni siquiera puedes usar los valores de hardware para crear una clave. Las máquinas virtuales ahora permiten que alguien cree una imagen de una máquina con licencia y la ejecute en cualquier plataforma que elija.

Si es software caro hay otras soluciones. Si no lo es, hazlo lo suficientemente difícil para el hacker ocasional. Y acepte el hecho de que eventualmente habrá copias sin licencia.

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

Advertencia: no puede evitar que los usuarios pirateen, sino que solo facilita que los usuarios honestos hagan lo correcto.

Suponiendo que no desea hacer una compilación especial para cada usuario, entonces:

Genera una clave secreta para el producto.
Toma el nombre del usuario
Concatene el nombre del usuario y la clave secreta y el hash con (por ejemplo) SHA1
Descomprime el hash SHA1 como una cadena alfanumérica. Esta es la "clave de producto" del usuario individual
Dentro del programa, haga el mismo hash y compare con la clave del producto. Si es igual, ok.

Pero, repito: esto no evitará la piratería.

Recientemente he leído que este enfoque no es criptográficamente muy acertado. Pero esta solución ya es débil ( ya que el software en sí debe incluir la clave secreta en algún lugar ), por lo que no creo que este descubrimiento invalide la solución en la medida de lo posible.

Solo pensé que realmente debería mencionar esto, sin embargo; Si planeas derivar algo más de esto, ten cuidado.

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 alguna vez liberó.

Después de encontrar algunas llaves o parches flotando en astalavista.box.sk sabrás que has logrado hacer algo tan popular que alguien se molestó en romper. ¡Alegrarse!

Como mencionaron algunos otros, soy un gran oponente de ser hostil a los clientes por defecto, algo por lo que la industria de las licencias es notoria. Así que ampliaré una buena solución para su problema que también ofrece una buena experiencia de usuario UX .

Para comenzar, mencionó que tiene una versión "limitada" de su software que está utilizando para intentar convertir a los clientes a "actualización" para características adicionales. Entonces, lo que está buscando son licencias de funciones para su producto, por ejemplo, un cliente puede comprar una licencia para la función X o característica Y.

Construí Keygen con este tipo de licencias en mente. Keygen es una API REST de licencias que le permite administrar cuentas de usuarios, licencias y también hacer un seguimiento del uso / asociación de la máquina.

Lo que haría sería configurar 2 tipos de licencia (una política dentro de Keygen) donde una es una política base para la versión gratuita limitada y la otra es una política para la versión pagada.

No estoy seguro de lo que está usando para los pagos, pero supongamos que está usando algo como Stripe (bastante estándar en la actualidad) que ofrece webhooks . Keygen también tiene webhooks (ya sea que lo uses o no, todo esto sigue siendo aplicable). Puede integrar Keygen para hablar con su proveedor de pagos usando webhooks de ambos lados (piense: customer.created -> create licencia base para cliente, license.created -> cobrarle al cliente la nueva licencia).

Por lo tanto, al utilizar webhooks, podemos automatizar la 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 exigir a su cliente que ingrese una clave de licencia larga en un campo de entrada que luego puede validar; Creo que esta es una manera terrible de manejar la validación de licencias en su aplicación.

¿Por qué pienso eso? En primer lugar, está solicitando a su cliente que ingrese una clave de licencia tediosamente larga para el consumo de la máquina, y segundo, que requiera que usted y su cliente realicen un seguimiento de dicha clave de licencia tediosamente larga .

Está bien, entonces, ¿cuál es una alternativa? Creo que la mejor alternativa es hacer algo a lo que todos sus clientes están acostumbrados: permitirles crear una cuenta para su producto mediante 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 iniciar sesión con sus credenciales.

¿Qué ventaja te da eso? En primer lugar, elimina la necesidad de que usted y sus clientes realicen un seguimiento de las claves de licencia, ya que todo se maneja entre bastidores dentro de su cuenta de usuario y, lo que es más importante , ahora puede ofrecer a sus clientes licencias y máquinas de autoservicio. ¡activación! 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 activen su aplicación en una máquina no reconocida.

Ahora en la validación de la licencia : siempre que su cliente inicie sesión en su aplicación con su correo electrónico / contraseña, puede consultar en su cuenta de usuario las licencias que posee para determinar si pueden usar la función X o la función Y. Y como su aplicación ahora es de autoservicio , ¡puede permitir que sus clientes compren funciones adicionales directamente desde su aplicación!

Así que hemos introducido una tonelada de automatización a nuestro sistema de licencias, podemos otorgar licencias para funciones individuales (es decir, una versión limitada frente a una completa), hemos ofrecido un increíble UX para nuestros clientes y también hemos aliviado una de las razones más importantes para solicitudes de soporte: recuperación de clave de licencia.

De todos modos, esto se hizo largo pero espero que ayude a alguien!

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 en su código fuente la información esencial requerida para la generación de licencias.

En el pasado, he usado la biblioteca de licencias de Treek muchas veces, porque cumple con estos requisitos y ofrece un precio realmente bueno. Utiliza la misma protección de licencia para los usuarios finales y para sí misma, y nadie lo ha descifrado hasta ahora. También puede encontrar buenos consejos en el sitio web para evitar la piratería y las grietas.

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" que significa que solo un subconjunto de la clave que utiliza para generar la clave debe compilarse en su distribuible. Usted crea las claves usted 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 descompilado, es relativamente fácil eludir la mayoría de los sistemas de licencias.

Hay muchas formas de generar claves de licencia, pero muy pocas de ellas son realmente seguras. Y es una pena, 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:

Solo su compañía debe poder generar claves de licencia para sus productos, incluso si alguien invierte completamente sus productos (lo que sucederá, hablo por experiencia). Omitir el algoritmo u ocultar una clave de encriptación dentro de su software es realmente imposible si realmente desea controlar las licencias. Si su producto tiene éxito, alguien creará un generador de claves en cuestión de días a partir de su lanzamiento.
Una clave de licencia solo debe poder usarse en una computadora (o al menos usted debería poder controlar esto muy bien)
Una clave de licencia debe ser breve y fácil de escribir o dictar por teléfono. No desea que todos los clientes llamen al soporte técnico porque no entienden si la clave contiene una "l" o un "1". Su departamento de soporte se lo agradecería y tendrá costos más bajos en esta área.

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

La respuesta es simple pero técnicamente desafiante: firmas digitales que utilizan criptografía de clave pública. Sus claves de licencia deben ser, en realidad, "documentos" firmados, que contengan algunos datos útiles, firmados con la clave privada de su empresa. Las firmas deben ser 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 total 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 quieres que tus claves de licencia tengan cientos de caracteres. Uno de los enfoques más poderosos es usar la criptografía de curva elíptica (con implementaciones cuidadosas para evitar las patentes existentes). Las claves ECC son como 6 veces más cortas que las claves RSA, para la misma fuerza. Puede reducir aún más los tamaños de firma utilizando algoritmos como el algoritmo de firma digital de Schnorr (la patente expiró en 2008 - bueno :))
Esto se puede lograr mediante la activación del producto (Windows es un buen 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 la identificación del hardware del equipo como los datos firmados. Por lo general, esto se hace a través de Internet, pero solo UNA VEZ: el producto envía la clave de licencia y la identificación del hardware de la computadora a un servidor de activación, y el servidor de activación envía el mensaje firmado (que también puede ser breve y fácil de dictar a través de Internet). teléfono). A partir de ese momento, el producto no comprueba la clave de licencia al inicio, sino los datos de activación, que necesitan que la computadora sea la misma para validar (de lo contrario, los DATOS serían diferentes y la firma digital no se validaría). Tenga en cuenta que la verificación de los 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 incorporada en el producto.
Bueno, simplemente elimine los caracteres redundantes como "1", "l", "0", "o" de sus claves. Dividir la cadena de clave de licencia en grupos de caracteres.

He implementado la activación por única vez 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 llega al servidor con la clave y se le da información de licencia que luego se cifra localmente mediante una clave RSA generada a partir de algunas variables (una combinación de CPUID y otras cosas que no cambiarán a menudo) en la computadora cliente y luego las almacena en la computadora cliente. el registro

Requiere algo de 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 brinda a su personal de ventas gran información sobre quién, dónde y cuándo se está utilizando el software. Cualquier sistema de licencias que solo se maneje localmente es totalmente vulnerable a la explotación, especialmente con la reflexión en .NET . Pero, como todos los demás han dicho, ningún sistema es completamente seguro.

En mi opinión, si no está utilizando licencias basadas en la web, no tiene ningún sentido proteger el software. Con el dolor de cabeza que puede causar el DRM, no es justo para los usuarios que realmente pagaron por sufrirlo.

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 forma de hacer todo lo que solicitó es requerir un acceso a Internet y una verificación con un servidor. La aplicación debe iniciar sesión en el servidor con la clave, y luego debe almacenar los detalles de la sesión, como la dirección IP. Esto evitará que la clave 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.

Puede simplemente tener una clave de licencia para la aplicación, y luego verificar 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.

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

El licenciamiento de nodo (máquina) es mejor si quiere evitar la reutilización de las claves de licencia. He estado usando Cryptlex desde hace aproximadamente un año para mi software. También tiene un plan gratuito , por lo que si no espera demasiados clientes, puede usarlo gratis.

No sé qué tan elaborado quieres conseguir.

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 más (como el nombre de usuario y la dirección mac de la nic)

usted calcula un código basado en eso y le devuelve la clave por correo electrónico.

evitarán que cambien de máquina después de que tengan la llave.

Puede utilizar una solución de terceros gratuita 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 en línea que crea para usted, la emisión de claves por correo electrónico y el uso de claves en una computadora específica para Prevenir la piratería.

También debe tener cuidado de ofuscar / cifrar su código o puede ser fácilmente diseñado mediante ingeniería inversa usando software como De4dot y .NetReflector. Un buen ofuscador de código libre es ConfuserEx, que es rápido y simple de usar y más efectivo que las alternativas costosas.

Debe ejecutar su software finalizado a través de De4Dot y .NetReflector para realizar una ingeniería inversa y ver qué vería un cracker si hiciera lo mismo y asegurarse de que no haya dejado ningún código importante expuesto o no disfrazado.

Su software seguirá siendo crackable, pero para el cracker casual puede ser suficiente para posponerlo y estos simples pasos también evitarán que su código sea extraído 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

Respuesta simple: no importa qué esquema se use, se puede romper.

No castigue a los clientes honestos con un sistema destinado a prevenir a los piratas informáticos, ya que los piratas informáticos lo descifrarán de todas formas.

Un código hash simple vinculado a su correo electrónico o similar es probablemente lo suficientemente bueno. Las identificaciones basadas en hardware siempre se convierten en un problema cuando las personas necesitan reinstalar o actualizar hardware.

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

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 mediante la configuración de 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 clave de licencia

Las ventajas con un servidor de clave de licencia es que:

siempre puede actualizar o bloquear una clave de licencia con efecto inmediato.
cada clave de licencia se puede bloquear en cierta cantidad 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 la verificación de licencias en línea le brinda 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 del servidor mediante un sistema de cifrado de clave pública como RSA o ECC (posiblemente mejor si planea ejecutar en sistemas integrados). Su aplicación solo debe tener la clave pública para verificar la respuesta de la clave de licencia.

Por lo tanto, en caso de que no haya conexión a Internet, puede utilizar la respuesta de clave de licencia anterior. Asegúrese de almacenar tanto la fecha como el identificador de la máquina en la respuesta y asegúrese de que no sea demasiado antiguo (por ejemplo, permite que los usuarios estén desconectados por más de 30 días, etc.) y que la respuesta de la clave de licencia pertenece al dispositivo correcto.

Tenga en cuenta que siempre debe verificar el certificado de respuesta de la clave de licencia, incluso si está conectado a Internet, para asegurarse de que no se haya cambiado desde que abandonó el servidor (esto aún debe hacerse incluso si su API para el el servidor de clave de licencia usa https)

Protegiendo algoritmos secretos

La mayoría de las aplicaciones .NET se pueden diseñar mediante ingeniería inversa con bastante facilidad (existe un desensamblador proporcionado por Microsoft para obtener el código IL y algunos productos comerciales incluso pueden recuperar el código fuente, por ejemplo, en C #). Por supuesto, siempre puede 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 los usuarios honestos que están dispuestos a pagar no se olviden de pagar después de que caduque una prueba, etc.).

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

Implementación

Si no quieres implementar todo por ti mismo, te recomiendo que eches un vistazo a este tutorial (parte de Cryptolens )