2026-06-14
Protegiendo la IP: cómo agregué un sistema de licencias a Heskala
Cuando decidí vender Heskala también como on-prem, apareció el problema más viejo del software: ¿cómo evitar que te lo pirateen? Acá cuento la solución que armé: licencias firmadas con criptografía asimétrica, verificación en el arranque y un guard que solo deja entrar al usuario con licencia válida.
Cuando decidí vender Heskala también como on-prem, apareció el problema más viejo del software: ¿cómo evitar que te lo pirateen? El código se entrega al cliente, corre en su propio servidor, no tengo control sobre él. La pregunta ya no es técnica, es de modelo de negocio.
La primera idea fue proteger el código fuente: ofuscar, compilar, esconder. La segunda fue un servidor de licencias central que se consulta cada vez. Ninguna me convenció. La ofuscación se rompe tarde o temprano, y un servidor central le cae mal a un cliente que compró el software justamente para no depender de nadie.
Entonces llegué a la solución correcta: criptografía asimétrica. Yo firmo el token en mi nube con una clave privada que nadie tiene. El cliente recibe un archivo con el token. El software on-prem verifica la firma con mi clave pública, que está embebida en el build. Si la firma es válida, el cliente compró esa licencia. Si no, no.
La clave privada nunca sale de tu nube. La clave pública viaja con el binario. Eso es todo el truco.
Por qué Ed25519 y no RSA
Ed25519 firma en 64 bytes, verifica en menos de un milisegundo, y las claves son ridículamente chicas. La librería viene en Web Crypto, así que funciona en el navegador y en Node sin dependencias extra. La otra opción razonable era RSA, pero sus firmas pesan 256 bytes y la implementación en Web Crypto es más quisquillosa. Para un caso de uso donde el cliente va a estar pegando un token en una pantalla, chico y rápido gana.
El flujo end to end
Desde el panel de super admin, lleno un formulario con el nombre del cliente, la edición, el tipo (vitalicia o suscripción) y la cantidad de asientos. La acción de Convex arma un objeto con esos datos, lo firma con la clave privada y me devuelve un token largo en base64. Se lo entrego al cliente.
El cliente lo pega en la pantalla de activación de su instalación on-prem. La aplicación lo guarda en localStorage, lo verifica contra la clave pública, y a partir de ahí deja entrar al usuario. El token se vuelve a chequear en cada navegación, no solo al inicio. Si alguien lo borra, vuelve a aparecer la pantalla de activación.
Como las suscripciones caducan, hay un heartbeat: la app on-prem le pega a mi nube una vez al día y actualiza la fecha del último contacto válido. Si pasan más días que el periodo de gracia sin que el servidor responda, el software se bloquea aunque el token siga siendo válido. Esto castiga al cliente que compra una licencia, la apaga y se la pasa al vecino: en algún momento va a tener que volver a conectarse y mi servidor le va a decir que esa licencia está revocada.
El heartbeat con gracia es la pieza más importante del sistema. Castiga al pirata, no al cliente legítimo.
El truco del lifetime para SaaS y Desktop
La edición SaaS y la Desktop usan el mismo backend que está en mi nube. No necesitan un token firmado: la decisión de si el cliente puede entrar vive en una sola tabla, company_subscriptions, y la controla Dodo Payments. Lo que agregué es un flag lifetime que, cuando está activo, ignora trialEnd, gracePeriodEnd y el estado de pago. El cliente que pagó vitalicio no se vuelve a preocupar nunca.
La pantalla de activación on-prem detecta la edición al compilar. Si el build es SaaS o Desktop, el guard es transparente: no aparece, no exige token. Solo on-prem muestra la pantalla y exige firma. Un solo componente, tres comportamientos.
Lo que aprendí en el camino
La criptografía asimétrica no es solo para blockchain. Es la herramienta correcta cuando una parte necesita ser la única autorizada a decir algo. Yo soy el único que firma licencias. El cliente es el único que las usa. Ninguno necesita confiar en el otro más allá de la firma.
También aprendí que un sistema de licencias se rompe cuando es molesto. Si el cliente legítimo tiene que andar renovando cada semana o se le bloquea la app sin aviso, te va a odiar más que al pirata. La gracia del heartbeat con gracia es esa: el sistema te da tiempo. El software sigue funcionando aunque el servidor esté caído. Solo se bloquea si pasan varios días y hay voluntad de bloquearlo.
Si te interesa el tema, te dejo dos ideas para llevar. La primera: la criptografía asimétrica resuelve más problemas de los que pensás. La segunda: cuando protegés tu software, no estás peleando contra los hackers, estás construyendo un modelo de negocio que respete al cliente que sí paga. Si la licencia es justa y el sistema no se rompe nunca, la gente paga.
#Software #Licencias #Ed25519 #SaaS #Heskala #Seguridad #Criptografía
Newsletter
Recibe los próximos posts
Sin spam. Solo cuando publique algo nuevo.
← volver al blog