Le système d'activation est implémenté autour d'une infrastructure à clés publique/privée.
Les opérations qui doivent être effectuées chez votre client (lors de l'exécution du programme, de la demande d'une licence) utilisent votre clé publique, qui est embarquée dans votre assembly.
Les opérations qui doivent être effectuées chez vous (génération de clé produit, génération de licence) impliquent votre clé privée contenue dans le jeu de clés de dotNet Protector.
IMPORTANT : Votre jeu de clés doit rester privé. Vous ne devez jamais l'inclure dans un programme que vous distribuez à vos clients. Côté client, vous devez toujours utiliser les méthodes statiques de ActivationManager (ne requierent pas de jeu de clés); dotNet Protector se charge d'enregistrer la clé publique dans l'assembly et la runtime se charge de la trouver.
Si vous perdez votre jeu de clés, personne (pas même PV Logiciels) ne pourra distribuer de licences a vos clients. Vous devrez protéger à nouveau toutes vos applications avec un nouveau jeu de clés, recompiler vos outils de génération de licences et clés produit, redéployer vos applications et regénérer les licences.
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.
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.
Voir aussi
Système d'activation, guide et exemples