Por favor comente sobre este esquema de protección de software simple

Question

Me pidieron implementar un esquema de licencia para nuestro producto. Son productos muy caros con pocos clientes distribuidos en todo el mundo y, básicamente, cada uno de ellos tiene un entorno de diseño (una aplicación de Windows instalada en máquinas con una sola ventana, de 1 a 150 máquinas de cliente por cliente) y un servidor web que aloja el entorno de producción. (1 a 8 máquinas por cliente). Nuestro producto tiene licencia para el uso del servidor para que los clientes puedan usar cualquier número de clientes; hemos decidido no licenciar la parte del servidor (porque está sujeta a acuerdos de SLA), sino solo el cliente, porque, después de un tiempo sin capacidad para usar el cliente, el sistema se vuelve básicamente inútil.

Nuestra suposición básica es que el cliente es "suficientemente honesto" y lo único que nos gustaría cubrir es detener el entorno de diseño del cliente si no tiene una licencia adecuada con una licencia de vencimiento.

He evaluado diferentes productos de licencia y son demasiado caros o demasiado difíciles de administrar, por lo que se me ocurrió esta solución simple:

• La licencia será un simple archivo XML firmado, firmado usando la característica estándar de Firma XML de w3c, usando una clave privada que se entregará al departamento de administración en una llave USB; si pierden la copia, el esquema de licencia fallará pero será su culpa
• El cliente abrirá el archivo de licencia al inicio y comprobará su validez utilizando una clave pública incrustada en los binarios
• Si el XML de la licencia es válido y los datos que contiene (fecha de vencimiento y nombre del producto) son correctos que el trabajo del diseñador; si no, se mostrará un mensaje apropiado

¿Alguna idea sobre posibles problemas o cómo mejorar el escenario?

Answer 1

Todavía no he visto un esquema de licencia que no se haya roto en unas pocas semanas, siempre que haya suficiente interés. Su esquema se ve muy bien (aunque asegúrese de que si alguien realmente quiere, lo romperá).

Hagas lo que hagas, debes seguir el consejo de Eric Sink:

  

El objetivo debería ser simplemente "mantener   gente honesta honesta " ;. Si vamos   más allá de esto, solo dos cosas   suceder:

     

  
1. Peleamos una batalla que no podemos ganar. Aquellos que quieran hacer trampa tendrán éxito.
  
2. Dañamos a los usuarios honestos de nuestro producto al hacer que sea más difícil   uso.
  

Ya que está implementando un esquema de licencia para un programa diseñado para uso corporativo, puede ir incluso más simple y simplemente mantener algún tipo de identificación y fecha de vencimiento junto con una firma simple en el cliente y negarse a comenzar si la licencia expiró o la firma ha fallado. No es tan difícil de romper, pero no hay un esquema de licencia y si considera que sus clientes son honestos, esto será más que suficiente.

Answer 2

No queda completamente claro en tu pregunta cómo funciona tu esquema. ¿Cada instancia del software cliente tiene una clave diferente? ¿Cuánto dura la licencia? ¿Tienes una clave diferente por cliente? ¿Cómo se paga la licencia? ¿Cómo se renueva una licencia?

Si está intentando controlar la cantidad de usos del código del cliente, solo el primero lo hará.

Al final del día, en el mundo en el que pareces habitar, sospecho que tendrás que vivir con la confianza de que no hay infracciones flagrantes de tu licencia. La mayoría de las organizaciones de tamaño decente (lo que suena como si fueran sus clientes) tienen la responsabilidad de no infringir, lo que puede llevar a graves consecuencias si rompen los acuerdos de licencia. También se les auditará periódicamente y probablemente tenga algunos derechos legales para verificar su uso (si no, debe escribirlo en su contrato de licencia).

Donde se vuelve muy peligroso para usted es si el contenido de las llaves USB llega a la web. En ese sentido, cualquier esquema que use una clave publicada es vulnerable a una divulgación intencional de los secretos.

Estoy seguro de que hay mucha literatura sobre este tema, por lo que probablemente valga la pena que continúes tu investigación.

Por cierto, no estoy seguro acerca de su referencia a los SLA en la parte media sobre las licencias de su servidor. Las licencias y los SLA son muy diferentes. Una licencia es la obligación del cliente, un SLA es tuyo.

Answer 3

si les da la clave privada, ¿qué les impide crear más archivos XML firmados en lugar de comprarle licencias adicionales? o es una licencia de sitio? si es esto último, ¿qué es para evitar que creen licencias para otras personas / sitios?

en general, los esquemas de licencias de desarrollo vinculan la licencia a una máquina en particular usando la dirección MAC y / o el número de serie del disco duro, o algunas veces solo con una clave de activación (que generalmente es solo un hash de la información del hardware)

y normalmente la codificación se realiza con una clave privada que usted mantiene secreta, y la licencia se verifica con una clave pública; el cliente nunca tiene la clave privada, de lo contrario puede, si así lo desea, generar sus propias licencias

Answer 4

Estoy de acuerdo con Steven A. Lowe (no tengo 15 reputación, así que no pude votarlo).

Esto también parece demasiado complicado. ¿Quieres que sea irrompible? tu no puedes Cualquier guru suficientemente motivado encontraría una forma de evitarlo.

A veces, un esquema de licencia simple funciona mejor:

Sugiero un archivo encriptado simple que el administrador coloca en algún lugar al que pueda acceder el cliente: contendría el nombre del cliente y la fecha de vencimiento. Utiliza el nombre del cliente del archivo en todos los informes impresos (eso es lo que más le importa a PHBs Acerca de, de esa manera no utilizarían la licencia que imprime el nombre de otra persona).