Chiffrement d’intégrité Ultimate

Le chiffrement d’intégrité lie le chiffrement des chaînes et le chiffrement du code (MSIL) intégrés à Babel au fichier assembly exact produit par Babel. Une chaîne ou une méthode chiffrée de cette manière ne se déchiffre correctement que lorsque l’application s’exécute à partir de ce fichier non modifié ; sur toute autre copie (un binaire corrigé, un octet modifié dans un éditeur hexadécimal, un fichier fusionné avec un autre build), le déchiffrement échoue, de sorte que les chaînes et les méthodes protégées ne redeviennent jamais correctes.

Sans lui, le chiffrement des chaînes et le chiffrement MSIL protègent le contenu de ce qu’ils masquent, mais le déchiffreur lui-même fonctionne de la même façon quel que soit le fichier dans lequel il se retrouve : une méthode ou une chaîne extraite de votre assembly et déposée dans un autre continue de s’y déchiffrer normalement. Le chiffrement d’intégrité comble cette lacune en liant le déchiffrement au fichier livré lui-même, si bien que déplacer les données protégées ailleurs suffit à les rendre inutilisables, sans que vous ayez à écrire ni à maintenir le moindre code de détection.

Le chiffrement d’intégrité est une protection différente de la détection de falsification. La détection de falsification réagit : elle vérifie l’image chargée et vous permet d’exécuter un code personnalisé (journaliser l’événement, afficher un message, quitter) lorsqu’elle ne correspond pas. Le chiffrement d’intégrité, lui, ne réagit pas du tout : il se contente de rendre les données chiffrées inutilisables hors du fichier dans lequel elles ont été construites. Les deux se combinent bien : la détection de falsification pour une réaction visible, le chiffrement d’intégrité pour qu’il n’y ait rien à récupérer même sans elle.

Panneau des propriétés de la cible dans Babel Desktop montrant Chiffrement des chaînes, Chiffrement Msil et Chiffrement d’intégrité, tous Activés — Le chiffrement d’intégrité se trouve à côté du chiffrement des chaînes et du chiffrement MSIL dans le panneau des propriétés de la cible de Babel Desktop

Prérequis

Le chiffrement des chaînes ou le chiffrement du code doit déjà être activé sur la cible. Le chiffrement d’intégrité n’a rien de son propre à protéger : il se limite à lier le déchiffrement de celui (ou de ceux) que vous avez activé. L’activer sans qu’aucun des deux ne le soit ne fait rien.
Assemblies de bureau .NET Framework 4+ ou .NET/Core uniquement, c’est-à-dire une image PE sous forme de fichier, chargeable. Il n’est pas pris en charge avec la publication en fichier unique, le découpage (trimming) ou NativeAOT : ces modes de publication ne conservent pas l’assembly sous la forme d’un simple fichier auquel Babel puisse se lier.
L’assembly n’a pas besoin d’un nom fort ; s’il en a déjà un, Babel vérifie aussi la signature de nom fort dans le cadre du même contrôle.
Au-delà de l’édition Ultimate de l’Obfuscator, il est également inclus avec les éditions Server et Data Center de Babel Licensing, qui intègrent l’édition Ultimate de l’Obfuscator.

Activer le chiffrement d’intégrité

Ligne de commande


babel myapp.exe --integrityencryption --stringencryption true

Tâche MSBuild Babel


<PropertyGroup>
  <IntegrityEncryption>true</IntegrityEncryption>
  <StringEncryption>true</StringEncryption>
</PropertyGroup>
 
<Babel IntegrityEncryption="$(IntegrityEncryption)" StringEncryption="$(StringEncryption)" />

Babel Desktop

Activez Chiffrement d’intégrité à côté de Chiffrement des chaînes ou de Chiffrement MSIL dans la liste des options de la cible. Babel Desktop signale ce paramètre si aucun des deux chiffrements n’est encore actif, puisqu’il n’y aurait alors rien à lier.

Exemple

Une cible qui chiffre déjà un espace de noms sensible avec le chiffrement MSIL, avec le chiffrement d’intégrité ajouté pour le lier :


<PropertyGroup>
  <MsilEncryption>true</MsilEncryption>
  <IntegrityEncryption>true</IntegrityEncryption>
</PropertyGroup>
 
<Babel MsilEncryption="$(MsilEncryption)" IntegrityEncryption="$(IntegrityEncryption)">
  <XmlRules>
    <Rules>
      <Rule name="encrypt-licensing" feature="msil encryption" exclude="false">
        <Target>Methods</Target>
        <Pattern>ACME.Licensing.*::*</Pattern>
      </Rule>
    </Rules>
  </XmlRules>
</Babel>

La règle sélectionne les méthodes que le chiffrement MSIL protège : le chiffrement d’intégrité ne change pas cette sélection, il se contente de lier le résultat au fichier de sortie de ce build. Les méthodes sont sélectionnées de la même façon avec ou sans lui : un filtre par expression régulière ou par caractère générique dans MsilEncryption lui-même, ou une règle XML comme celle ci-dessus avec feature="msil encryption". Sans filtre ni règle correspondante, MsilEncryption active la fonctionnalité mais ne sélectionne rien, si bien que le chiffrement d’intégrité n’a alors rien à lier non plus.

À retenir

Il s’ajoute aux autres protections : l’activer ne change pas les chaînes ou les méthodes qui sont chiffrées, seulement la manière dont leur déchiffrement est lié au fichier livré.
Un build qui échoue déjà à la limitation de la détection de falsification pour fichier unique, découpage ou AOT ignore aussi le chiffrement d’intégrité, pour la même raison : les deux ont besoin de l’assembly sous la forme d’un simple fichier chargeable.
Régénérer, signer de nouveau ou fusionner de nouveau l’assembly après l’obfuscation invalide la liaison, de la même façon que cela invaliderait un hachage de détection de falsification : appliquez le chiffrement d’intégrité dans l’étape de build Babel qui produit le fichier que vous livrez, pas avant qu’une étape ultérieure ne le modifie.

Voir aussi

Chiffrement des chaînes et chiffrement du code (MSIL) : les deux protections que lie le chiffrement d’intégrité.
Détection de falsification : une protection qui réagit et se combine bien avec lui.
Règles XML : sélectionner les méthodes que le chiffrement MSIL protège avec feature="msil encryption".

Chiffrement d’intégrité ★Ultimate