Contexte du projet

Ce retour d'expérience est basé sur la migration d'un outil d'analyse Python distribué à une cinquantaine de clients professionnels. L'outil traitait des données confidentielles (secteur médical) et était initialement protégé par IronLock v1 (RSA-2048, PBKDF2, fingerprint 3 sources). La migration vers v2 a été motivée par trois besoins :

  • Sécurité : passage à ECDSA P-384 et Argon2id suite à une politique de sécurité renforcée.
  • Robustesse : plusieurs clients avaient perdu leur licence après un changement de RAM — le fingerprint 3 sources était trop rigide.
  • Opérationnel : la gestion manuelle des licences (envoi par email) devenait ingérable à 50 clients.

La migration de licences est la partie la plus délicate d'une montée de version IronLock. Bien planifiée, elle est transparente pour les clients. Mal planifiée, elle génère un pic de tickets support.

Architecture de distribution

L'architecture mise en place pour 50 clients :

# Côté éditeur (serveur interne)
licence-server/
├── keys/
│   ├── private_p384.pem    # hors ligne, chiffrée AES
│   └── public_p384.pem     # embarquée dans loader
├── clients/
│   ├── client_001/
│   │   ├── fingerprint.json
│   │   ├── licence_v2.lic
│   │   └── history.log
│   └── ...
├── templates/
│   └── app_v2.ironenc      # payload chiffré unique
└── scripts/
    ├── generate_licence.sh
    └── renew_licence.sh

# Le payload chiffré est identique pour tous les clients
# Seule la licence change (liée au fingerprint du client)

Migration v1 → v2

La migration a été planifiée sur 4 semaines avec une période de double-validation :

# Semaine 1 : génération des nouvelles clés P-384
ironlock keygen --algo ecdsa-p384 --output keys/v2/

# Semaine 2 : recollecte des fingerprints clients
# Email aux clients : télécharger l'utilitaire fingerprint
ironlock fingerprint-tool --output fp_collector.exe

# Semaine 3 : migration des licences existantes
for client in clients/:
    ironlock migrate       --from v1       --old-licence clients/$client/licence_v1.lic       --fingerprint clients/$client/fingerprint_v2.json       --privkey keys/v2/private_p384.pem       --expires +365d       --output clients/$client/licence_v2.lic

# Semaine 4 : déploiement du nouveau loader v2 + licences
# Validation : chaque client teste avant que l'ancienne
# version soit désactivée

Résultat : 47 clients migrés sans incident. 3 clients ont nécessité un renouvellement de fingerprint (changement de machine entre la collecte et le déploiement).

Gestion des licences en production

Après la migration, le process de gestion des licences a été semi-automatisé avec un script Python interne :

import json, subprocess
from datetime import date, timedelta
from pathlib import Path

def renew_client(client_id: str, extend_days: int = 365):
    client_dir = Path(f'clients/{client_id}')
    
    # Lire la licence existante
    lic = json.loads((client_dir / 'licence_v2.lic').read_text())
    new_expiry = date.today() + timedelta(days=extend_days)
    
    # Regénérer avec nouvelle expiration
    subprocess.run([
        'ironlock', 'license',
        '--privkey', 'keys/v2/private_p384.pem',
        '--fingerprint', str(client_dir / 'fingerprint.json'),
        '--expires', new_expiry.isoformat(),
        '--output', str(client_dir / 'licence_v2.lic')
    ], check=True)

Monitoring et alertes

Un script cron vérifie quotidiennement les licences arrivant à expiration et envoie des alertes :

  • J-30 : email automatique au client avec lien vers le formulaire de renouvellement.
  • J-7 : relance + notification interne.
  • J-1 : alerte urgente, contact direct si pas de réponse.
  • J+0 : la licence expire, le programme se ferme avec un message clair.

Chiffres clés après 6 mois

  • Tentatives de bypass détectées : 3 (détectées par les logs anti-debug — sortie silencieuse, pas de fuite d'information).
  • Faux positifs anti-debug : 0 (avec score threshold=3).
  • Renouvellements de fingerprint : 8 (changements matériels légitimes), 0 rejet abusif.
  • Tickets support liés à la licence : 4 en 6 mois vs 23 en 6 mois avec IronLock v1.
  • Temps moyen de génération de licence : 12 secondes (script semi-automatisé).

Pièges rencontrés

  • Clients sur VMs légitimes — 6 clients travaillaient dans des VMs d'entreprise (Citrix, VMware Horizon). Le VM detector en mode "block" rejetait leur licence. Solution : passer en mode "warn" pour ces clients spécifiques.
  • Windows Update et fingerprint — une mise à jour majeure de Windows 11 a modifié l'OS GUID sur 3 machines. Le système de tolérance Argon2id a absorbé ce changement (source de poids 1, seuil à 10/14).
  • Antivirus faux positifs — deux clients avaient un EDR qui marquait le loader comme suspect. Résolu en ajoutant une signature Authenticode au loader.exe.

Conclusion

La migration vers IronLock v2 a réduit les tickets support de 80% et zéro bypass réussi en 6 mois. Le fingerprint 8 sources avec tolérance est le bon compromis entre sécurité et facilité d'usage client. Le point d'attention principal reste la gestion des environnements virtualisés légitimes : configurer le VM detector en mode "warn" plutôt que "block" pour les clients en environnement VDI.

🔐
PRODUIT LIÉ
IronLock v2.0
← Article précédent Retour au blog →