Seguridad y el modelo de leases

La versión honesta de cómo Keyright mantiene seguras las licencias — qué protege y qué no protege la criptografía, y cómo funciona el lease. Si estás evaluando Keyright para un producto real, lee esta página antes de publicar.

Qué se protege realmente — ¿la clave, o algo más?

La clave de licencia (LIC-…) es solo un identificador, no el secreto. No lleva derechos y no otorga nada por sí sola. Lo que tu aplicación confía es el documento firmado que el servicio devuelve en la activación — el lease (en línea) o un archivo de licencia firmado (offline). Ambos se firman con la clave privada RSA-2048 de tu producto, que reside solo en el servicio de emisión y se almacena cifrada en reposo (AES-256-GCM bajo una clave de cifrado de claves; en producción el servicio se niega a arrancar sin una). Tu aplicación integra solo la clave pública correspondiente y verifica la firma (PKCS#1 v1.5 / SHA-256).

Así que:

• Una clave filtrada permite a alguien intentar una activación contra tu límite de puestos — nada más. No puede otorgarse a sí mismo un nivel superior, más puestos ni un vencimiento posterior, porque todo eso está dentro del payload firmado que no puede producir.
• Si se abusa de una clave, la revocas (panel o /admin/licenses/{id}/revoke). Las revocaciones se propagan en línea de inmediato y offline mediante una lista de revocación firmada que el cliente consulta.
• Tu aplicación nunca confía en una cadena de clave que no haya visto firmada por el servicio. Falla de forma cerrada: sin firma válida ⇒ sin licencia.

Por qué una licencia de un solo puesto no puede ejecutarse en dos equipos — ni siquiera offline {#seats}

Dos controles independientes, y el offline es la parte importante:

1. Aplicación de puestos del lado del servidor (en línea). La activación cuenta equipos distintos contra el número de puestos. Un equipo nuevo que supere el límite recibe SeatLimit. Reactivar el mismo equipo es idempotente, por lo que nunca infla el recuento.
2. Vinculación por bloqueo de equipo (funciona sin red). Cada lease/archivo-offline firmado está vinculado a una huella de equipo (KRM1:…) derivada de identificadores estables de hardware/SO, con sal y hash. La huella está dentro del payload firmado, de modo que cuando el cliente valida, recalcula la huella de este equipo y comprueba que coincide. Copia un lease offline a un segundo equipo y la validación devuelve MachineMismatch — la firma está bien, pero no es este equipo.

Por eso offline no se convierte en una vía de escape: un lease offline se acuña para un ID de equipo (y sigue confirmando un puesto cuando se emite), de modo que no puede compartirse. Keyright tolera que cambie un componente “blando” (p. ej. renombrar un equipo) para que el mantenimiento normal no deje fuera a un usuario legítimo, mientras que el anclaje de hardware siempre debe coincidir.

Cómo debe leerse “irrompible”

Sé preciso sobre las dos amenazas distintas:

• Falsificación / manipulación — esto está criptográficamente cerrado. Nadie puede crear una licencia válida, subir de nivel, añadir puestos ni posponer un vencimiento sin tu clave privada, y esa clave nunca sale del servidor. Cambia un solo campo en un lease o archivo de licencia y la firma RSA ya no verifica, así que el cliente lo rechaza. En ese sentido los documentos son infalsificables y evidencian la manipulación.
• Un atacante decidido en un equipo que controla por completo es un problema distinto, y ninguna biblioteca de licenciamiento por sí sola lo resuelve. Alguien que pueda parchear tu binario compilado puede, en principio, saltarse la propia comprobación if (!info.IsValid) — eso es cierto en todos los productos de licenciamiento, porque la comprobación se ejecuta en su CPU. Keyright hace que la licencia sea infalsificable; proteger el código de aplicación es una capa aparte. Combina Keyright con Nebula.NET (ofuscación, anti-manipulación, cifrado de métodos) cuando eso importe. Preferimos decírtelo a fingir que una firma detiene a un depurador.

Otras cosas que la gente pregunta sobre seguridad, estabilidad y escala

• Estabilidad / resiliencia offline. La validación es local y sin estado — tras la activación tu aplicación no depende de que el servicio esté disponible para seguir funcionando (ese es el objetivo del lease). Una caída del servicio no deja tirados a los clientes activados dentro de su ventana de gracia.
• Escalabilidad. El servicio de emisión es sin estado por solicitud y escalable horizontalmente; la ruta caliente (/v1/activate, /v1/validate) es una operación de firma más una comprobación de puestos. Como los clientes validan offline entre activaciones, no incurres en una solicitud por cada arranque de la aplicación.
• Aislamiento multi-inquilino. Cada inquilino tiene su propia clave de firma y los datos están aislados por inquilino, de modo que la clave o las licencias de un proveedor nunca pueden verificar ni tocar las de otro.
• Resistencia al abuso. Los endpoints de cliente están limitados por tasa; los endpoints de administración requieren un token y están delimitados por rol (Read < Write < Manage < Own) con un registro de auditoría.
• Manipulación del reloj. Las pruebas y los vencimientos se comprueban contra una marca de tiempo persistida de primera observación; retrasar el reloj del sistema se detecta (ClockTampered) en lugar de premiarse.

---

El lease, explicado

¿Por qué emitir un lease en absoluto?

Un lease es un token de gracia firmado y de corta duración (por defecto 14 días) que el servicio devuelve en la activación. Es el equilibrio entre dos extremos malos: llamar a casa en cada arranque (frágil, poco respetuoso con la privacidad, se rompe cuando tu servicio parpadea) frente a confiar en un equipo para siempre tras una sola activación (incontrolable). El lease permite que un equipo activado se ejecute offline durante la ventana de gracia y luego vuelva a comprobar.

¿El producto tiene que volver a Keyright para renovar el lease?

Sí — pero de forma invisible y solo de vez en cuando. El patrón recomendado es llamar a ActivateAsync al arrancar: cuando el equipo está en línea refresca en silencio el lease de 14 días (idempotente, sin puesto extra); cuando está offline el SDK sigue validando contra el lease en caché. Así, un equipo normalmente conectado se renueva sin que nadie lo note, y los 14 días son simplemente cuánto puede permanecer completamente offline antes de tener que contactar con el servicio una vez. Puedes ampliar o reducir esa ventana (KEYRIGHT_LEASE_TTL_DAYS) para equilibrar la tolerancia offline con la rapidez con que surte efecto una revocación o un cambio de puestos.

¿Qué pasa si un equipo se queda offline después de la activación?

Sigue funcionando hasta que pase el leaseExpiresUtc del lease — la ventana de gracia. Reconéctate en cualquier momento antes de eso y el lease se refresca por otra ventana. Si la ventana transcurre sin contacto, Validate() devuelve Expired (“reconéctate para volver a validar”) y tu aplicación falla de forma cerrada. Para equipos que estarán offline mucho tiempo o para siempre, no te apoyes en el lease de 14 días — emite un lease offline de TTL largo (por defecto 365 días) o distribuye un archivo de licencia offline independiente. Consulta Activación y desactivación.

¿Puede un usuario simplemente editar el archivo de lease para prolongarlo para siempre?

No. El vencimiento (leaseExpiresUtc) es parte del payload firmado, no un ajuste aparte. Cámbialo — o el nivel, los puestos, la vinculación al equipo, cualquier cosa — y la firma RSA ya no coincide, así que el cliente rechaza el lease como SignatureInvalid y recae en sin licencia. No hay ningún campo que un usuario pueda cambiar. Retrasar el reloj para situarse dentro de una ventana antigua tampoco ayuda: eso es lo que atrapa la detección de manipulación del reloj. La única forma de obtener un lease más largo es que tú emitas uno.

¿Cómo funciona la activación offline, en un párrafo?

El equipo offline emite su huella; tú (con conectividad y un token de administración) acuñas un lease vinculado a esa huella con el TTL que elijas; el equipo lo importa y valida localmente para-siempre-hasta-el-TTL, sin red. Es el mismo mecanismo de lease firmado que la activación en línea — solo que entregado a mano en lugar de por HTTP, y vinculado a exactamente un equipo para que no pueda compartirse. Paso a paso: Activación offline / aislada.