La otra cara de la moneda: Hasp
Si hace unos días hablaba de cómo se puede emular una llave electrónica Hasp, hoy voy a tratar el tema de cómo asegurar nuestras aplicaciones con una llave Hasp.
Me puse en contacto con las oficinas de Barcelona de Aladdin (SafeNet) para preguntar por las llaves electrónicas, como las gestionan y qué seguridad ofrecen.
Lo primero que saqué en claro: es muy asequible.
Me imaginaba un coste demasiado alto, tanto como para hacer inviable la idea. Pero nada más lejos, es un producto cercano, elaborado, y fácil de implementar.
Tenemos diferentes modelos de llave, según necesidad del desarrollador:
- Hasp HL Basic: Llave más básica, que permite una sola licencia por llave. Carece de memoria programable, por lo que solo nos sirve para un software en concreto, y una validación de si existe o no la llave.
- Hasp HL Pro: Esta llave tiene memoria programable (112 bytes), lo que nos permite validar más de un programa con la misma llave, o partes de uno. Es decir, podríamos gestionar grupos de usuarios a través de la llave (El usuario básico solo pueda consultar, un usuario medio añadir pedidos, y un usuario con control total, por poner un ejemplo). Se pueden asegurar unas 38 aplicaciones/funciones con una misma llave.
- Hasp HL Max: Versión superior, con mayor capacidad de memoria programable, pudiendo gestionar unas 233 licencias diferentes (sea software completo, o modulos de cada uno).
- Hasp HL Time: Esta tiene la misma capacidad y función que la versión anterior, pero con un reloj interno añadido. Será útil cuando queramos controlar fecha y hora, sin depender de la del equipo (para evitar… modificaciones).
Existen otras llaves, por ejemplo para entornos de red. Teneis el listado completo aquí.
¿Cómo se gestiona una llave Hasp con nuestro proyecto? Es bien sencillo. Una vez compramos el producto (no voy a dar precio, aunque ya he dicho que es rentable, podeis hacer una llamada y os atenderán gustosamente), se nos asignará un VendorId (diferente para cada desarrollador/empresa). Las llaves cliente que compremos ya vendrán asignadas a ese VendorId.
Junto con las llaves cliente, tendremos una llave maestra, de la que extraemos el certificado que usaremos para validar nuestro soft.
Inicialmente tendremos dos maneras de gestionar la seguridad:
El primer método es automático, basta con seleccionar el ejecutable/librerías que queremos proteger, indicarle algún parámetro (frecuencia con la que tiene que verificar la llave, nivel de encriptación, FeatureId, que seria el númeo de licencia a utilizar) y nos lo hará automáticamente.
Otra manera, quizá más elegante, es a través de la API. Las utilidades que acompañan a la llave nos ofrecen un generador de código (para C#, VB, C y C++), con lo que solo tendremos que hacer copy/paste en el lugar que nosotros elijamos para validar la llamada.
Aunque también podemos hacerlo ‘a pelo’.
Dicho así, quizá no quede del todo claro, y parezca más complicado de lo que realmente es. Para ello existen manuales (en inglés, desde la propia web de aladdin) con diferentes lecciones, en las que comenzaremos con una protección automática, e iremos avanzando, pudiendo generar números de serie y demás.
Si alguno quiere proteger software, esta es una de las maneras más seguras de las que se dispone (aunque no infalible, claro está)
Lo mejor de todo esto, es que sabiendo como ‘burlar’ esta seguridad, podemos desarrollar métodos para evitarla (por ejemplo, buscando si existe el servicio de emulador Hasp, y deteniendo nuestra aplicación si este está activo).