Ces exemples illustrent les mécanismes d'activation de dotNet Protector.
L'archive contenant les solutions de l'exemple ext disponible ici
Comment ça marche ?
Quand vous activez le verrou materiel, chaque methode est cryptée, mais la clé de décryptage n’est pas enregistrée dans l’assembly protégé. La runtime dotNet Protector a besoin d’une clé de licence pour décrypter les méthodes.
Le verrou matériel est un processus en 3 étapes :
1. Vous protégez votre assembly en activant le verrou materiel. Les méthodes sont cryptés, seule votre clé publique est enregistrée dans l’assembly protégé – pas de clé de décryptage.
2. Votre assistant d’activation, protégé avec dotNet Protector construit une ‘configuration matérielle’ à partir du materiel sur lequel il s’exécute. Cette config est cryptée avec votre clé publique et envoyée à votre serveur d’activation.
3. Votre générateur de licences (serveur d’activation) décrypte la config et construit une clé de licence. Le générateur de licence s’exécute de votre côté et contient votre clé privée, permettant le décryptage de la ‘config matérielle’ et le cryptage de la clé de licence.
Quand votre assembly s’exécute, la runtime dotNet Protector cherche la clé de licence, la décrypte avec votre clé publique et essaie de décrypter les méthodes.
Les paires de clés publique/privée
dotNet Protector enregistre des clés symétrique et paires publique/privée (il y en a plusieurs) dans un jeu de clés. Le jeu de clés est construit la première fois que vous exécutez dotNet Protector, à l’aide d’un générateur aléatoire cryptographique (il y a vraiment peu de chance que le même jeu de clés soit génére deux fois).
Dans la mesure ou une infrastructure de clé publique est très impliquée dans le processus d’activation, il est obligatoire que votre assembly et votre assistant d’activation soient protégés avec le même jeu de clés. Le générateur de licences utilisera la partie privée de ce jeu de clés pour générer les licences.
Activation de Composants (Dll)
dotNet Protector propose 2 modes d’activation de composants
Activer pour Exécuter : Dans ce mode, une licence est requise chaque fois que la dll s’exécute. Vous vendez votre dll suivant un modèle de redevance : chaque utilisateur final devra acquérir une licence pour l’utiliser.
Activer pour Referencer : Dans ce mode, une licence n’est requise qu’au moment de la compilation (licence design-time). Lors de l’exécution, une licence run-time est générée à partir de la licence design-time. Vous vendez votre dll suivant un modèle sans-redevance. Une licence est nécessaire pour le développeur qui utilise votre dll, mais pas pour le client final.
Le 3ème choix proposé par dotNet Protector est finalement seulement un choix hybride : si votre dll est consommée par une application windows, elle fonctionne en mode ‘activer pour référencer’, si elle est consommée par une application ASPNET, elle fonctionne en mode ‘activer pour exécuter’.
Activation d'application, Assistant d'activation, génération de clés