Cómo detener el uso compartido de claves de licencia y la piratería

Todo proveedor que vende claves de licencia acaba encontrando una de las suyas en circulación. La mía estaba en un foro de soporte: un cliente había pegado su clave en un hilo público pidiendo ayuda, y para cuando la vi, tres desconocidos habían “agradecido” el mensaje. La clave hacía exactamente lo que hace una clave ingenua — desbloquear el software dondequiera que se escribiese, tantas veces como quisiera cualquiera. Eso no es una red de piratería; es uso compartido de claves corriente, y es la filtración que cuesta más ingresos a la mayoría de los proveedores. La buena noticia es que también es la más evitable.

Este artículo es una guía práctica y honesta para detener el uso compartido de claves de licencia: los controles que funcionan, cómo se combinan y — porque prefiero que confíes en mí a venderte de más — una declaración clara de lo que la protección realmente puede y no puede hacer.

Idea clave: detienes el uso compartido de claves vinculando cada clave a algo finito (una máquina, un número de puestos, un límite de activación), haciendo que las copias compartidas sean visibles mediante la revalidación en línea y manteniendo un interruptor de apagado (revocación) para las que se filtren de todos modos. No puedes hacer imposible el uso compartido — la comprobación se ejecuta en el hardware del usuario — pero puedes hacer que el uso compartido ocasional falle de forma fiable y que el crackeo serio cueste más de lo que vale.

Primero, entiende lo que una clave simple no puede hacer

La trampa es la cadena de clave casera: genera una clave de aspecto aleatorio, haz que la aplicación acepte cualquier cosa que coincida con el patrón y envíala por correo al comprarla. Parece protección, pero tiene dos propiedades fatales. Primero, cualquier cosa que la aplicación pueda validar por su forma, un atacante puede reproducirla — decompila la comprobación y se convierte en un generador de claves (explico el porqué en cómo licenciar tu software). Segundo, y más relevante aquí: una clave simple no tiene noción alguna de cuántas instalaciones debería permitir, así que nada impide que una clave desbloquee mil máquinas. El uso compartido de claves no es un fallo en ese modelo; es el comportamiento predeterminado.

Arreglar el uso compartido empieza por hacer que la clave signifique algo finito. Eso es lo que hacen los cuatro controles siguientes.

Control 1 — Bloqueo por equipo

El bloqueo por equipo vincula una licencia a una máquina concreta mediante una huella derivada de atributos estables del hardware y del sistema operativo. Activa una clave en una máquina y queda registrada contra esa huella; copia la misma clave a una segunda máquina y la huella no coincidirá, así que la licencia simplemente no se aplica allí. Este es el control más eficaz contra el uso compartido ocasional, porque “envía la clave por correo a un compañero” ahora sencillamente… no les funciona.

Lo único que hay que acertar es la tolerancia. Con una huella demasiado estricta, un cliente honesto que cambia una tarjeta de red o actualiza un disco queda bloqueado y abre un ticket enfadado. Una buena implementación permite una pequeña deriva para que los cambios de hardware corrientes no disparen el bloqueo, mientras que los cambios de gran calado siguen leyéndose como una máquina distinta. Cubrí la mecánica de las huellas y el problema de la tolerancia al cambio en profundidad en bloqueo por equipo y gestión de puestos — en lugar de repetirlo aquí, lee aquello para el cómo; este artículo trata de cómo encaja el bloqueo por equipo en el panorama anti-uso compartido.

Control 2 — Límites de activación y topes de puestos

El bloqueo por equipo impide que una clave se ejecute en otra máquina simultáneamente, pero por sí solo no impide que alguien active en una serie rotatoria de máquinas, ni que un equipo supere en silencio lo que pagó. Para eso están los topes de puestos y los límites de activación.

• Un número de puestos es la promesa “esta licencia se ejecuta en N máquinas a la vez”. Lo impone un servidor que registra cada activación y rechaza la N+1, devolviendo un resultado de límite de puestos y ningún arrendamiento — no hay contador del lado del cliente que parchear.
• Un límite de activación topa cuántas veces puede activarse una clave a lo largo de su vida, lo que atrapa el patrón de “reinstalar en una máquina nueva cada semana” que un número de puestos en vivo por sí solo podría pasar por alto.

La función acompañante crucial es la desactivación de autoservicio. El día después de que despliegues los topes de puestos, un cliente honesto retira un portátil, compra uno nuevo y no puede activar porque todos sus puestos los tienen máquinas que ya no usa. Si mover un puesto implica escribir a soporte, cada renovación de hardware se convierte en un ticket — y peor aún, hace que tus clientes legítimos se sientan como el enemigo. Déjalos liberar un puesto ellos mismos, desde un portal o un botón “desactivar este dispositivo” dentro de la aplicación, y el tope sigue impuesto sin castigar a los usuarios honestos.

Control 3 — Revalidación en línea

El bloqueo por equipo y los topes de puestos se imponen en el momento de la activación, pero el uso continúa mucho después. La revalidación en línea es lo que mantiene viva la imposición: el cliente comprueba periódicamente con el servidor — normalmente refrescando un arrendamiento firmado de vida corta — para que la visión del servidor sobre quién usa una clave se mantenga al día.

Esto es lo que hace visible una clave compartida. Si una clave que vendiste como un único puesto muestra de repente activaciones de una docena de máquinas en tres países, la revalidación es cómo lo sabes, y el refresco del arrendamiento es donde puedes actuar. Y, crucialmente, lo haces sin hacer sufrir a los usuarios legítimos con cortes: como el cliente guarda en caché un arrendamiento válido, un breve parón de red queda cubierto por una ventana de gracia — el software sigue funcionando sin conexión hasta que el arrendamiento se acerca a la caducidad, y entonces reconcilia. Consigues imposición continua y resiliencia sin conexión, en lugar de tener que elegir entre ambas. El patrón completo de “primero sin conexión” está en la validación de licencias sin conexión explicada.

Control 4 — Revocación, el interruptor de apagado

A veces una clave se filtra pese a todo — se publica en un foro, o pertenece a un cliente que hizo un contracargo. Necesitas poder anular esa clave concreta, y eso es la revocación.

• En línea, una clave revocada cae al estado sin licencia en su siguiente revalidación. Como los arrendamientos son de vida corta, la “siguiente actualización” llega por sí sola, así que la clave publicada en el foro deja de funcionar para todos los que la usan sin que tú muevas un dedo después del clic.
• Sin conexión, distribuyes una lista de revocación firmada con una actualización de la aplicación — una lista de identificadores de claves muertas, firmada ella misma para que el cliente pueda confiar en ella — e incluso los clientes desconectados rechazan claves conocidas como maliciosas. Más lento (avanza al ritmo de tus versiones), pero significa que una instalación aislada (air-gapped) no está indefensa frente a una clave filtrada.

La revocación es lo que convierte una clave filtrada de una pérdida permanente en un problema temporal y recuperable.

La parte honesta: lo que no puedes hacer

Ahora la verdad que prometí. No puedes hacer imposible el uso compartido de claves de licencia ni la piratería. Todo control anterior se ejecuta, en parte, en hardware que controla el usuario, y cualquier cosa que se ejecuta en una máquina que alguien posee puede — con suficiente habilidad, tiempo y motivación — observarse, entenderse y eliminarse con un parche. Un atacante decidido con un decompilador y un depurador puede neutralizar una comprobación del lado del cliente. Eso no es un defecto de tu implementación; es una propiedad del universo en el que operas.

Así que el objetivo no es cero piratería. El objetivo es la economía: que el uso compartido ocasional y oportunista (la inmensa mayoría de tus pérdidas) falle de forma fiable y barata, y que el crackeo serio cueste más esfuerzo del que vale una licencia legítima para tu rango de precios. Ese es un objetivo alcanzable y honesto, y los controles de aquí lo logran. Dos cosas lo afinan aún más:

1. Mantén la imposición real en el servidor. El recuento de puestos y la revocación ocurren en infraestructura que el atacante no controla, así que ni siquiera un cliente parcheado puede concederse puestos de más ni des-revocar una clave muerta. La comprobación del cliente es una puerta rápida; el servidor es donde las reglas son reales.
2. Haz que el cliente sea difícil de parchear. Combina tus comprobaciones de licenciamiento con ofuscación para que el ataque de “simplemente elimínalo con un parche” cueste esfuerzo real. Escribí una guía centrada en esto — protege tus comprobaciones de licenciamiento en .NET — porque un sistema de licenciamiento y la ofuscación que lo protege son dos mitades de un mismo trabajo.

Hacer esto con Keyright

Keyright te da todos los controles anteriores como un único sistema: bloqueo por equipo con tolerancia al cambio, topes de puestos impuestos por el servidor, desactivación de autoservicio para que los usuarios honestos muevan puestos sin un ticket, revalidación en línea con una ventana de gracia sin conexión y revocación con un clic que llega tanto a los clientes en línea (en su siguiente actualización) como a las compilaciones sin conexión (mediante una lista de revocación firmada). Las claves de firma están aisladas por inquilino y la mitad privada nunca sale del servidor, así que una clave pública filtrada es inútil para falsificar. Los SDK para .NET, Node, Python y Java fallan de forma segura por diseño — toda ruta de fallo aterriza en el estado sin licencia, nunca en un desbloqueo accidental.

El plan gratuito basta para montar de principio a fin una imposición real de puestos y revocación antes de pagar nada — empieza gratis, o lee la guía de integración con .NET para ver las llamadas exactas de activación y revocación. Y como Keyright es compatible con Nebula, se combina de forma natural con compilaciones ofuscadas de .NET para que la mitad del cliente sea realmente difícil de parchear.