Filigraner des assemblages .NET pour tracer qui a divulgué une build

L”obscurcissement répond à la question « quelqu”un peut-il lire mon code ? ». Il ne fait rien pour une question différente et souvent plus douloureuse : « quelqu”un a divulgué mon logiciel — qui ? ». Quand une build que vous avez vendue à un client apparaît sur un forum, un site de partage de fichiers ou la machine d”un concurrent, l”obscurcissement ne peut pas désigner la source. Le filigranage, lui, le peut. Un filigrane est un marqueur discret, par licencié, cuit dans chaque copie afin qu”un assemblage divulgué puisse être tracé jusqu”au compte auquel il a été émis. C”est un outil différent pour un travail différent, et il se combine naturellement à la fois avec l”obscurcissement et le licensing.

Attribution, pas confidentialité

Il est utile d”être précis sur ce à quoi sert un filigrane. L”obscurcissement élève le coût de comprendre votre code. Un filigrane élève le coût de le divulguer en rendant la fuite attribuable. Les deux sont orthogonaux : une build obscurcie sans filigrane est illisible mais anonyme — une copie sur un torrent ne vous dit rien sur qui l”y a mise. Une build filigranée mais non obscurcie est parfaitement lisible mais traçable. Vous voulez les deux : difficile à comprendre et traçable jusqu”au licencié si elle s”échappe.

Ce recadrage compte car il change le critère de succès. L”obscurcissement « marche » si un attaquant renonce à essayer de lire le code. Un filigrane « marche » si, étant donné une copie divulguée, vous pouvez dire de façon fiable cette build a été émise au compte X. Rien dans le filigrane n”a besoin d”empêcher la fuite d”être utilisable — il doit rendre le divulgateur identifiable, ce qui est un dissuasif en soi une fois que les clients savent que les builds sont marquées individuellement.

Ce que doit être un bon filigrane

Toute « chaîne cachée » n”est pas un filigrane. Un filigrane utilisable a quatre propriétés :

• Unique par licencié. La build de chaque client (ou chaque copie activée) porte un marqueur différent — typiquement un identifiant par compte, ou un token opaque qui se mappe à l”un d”eux dans vos registres. Deux clients ne doivent jamais partager un marqueur, sinon l”attribution est perdue.
• Discret. Il ne devrait pas être une évidente chaîne CustomerId = "12345" posée dans les métadonnées, qui est la première chose que quiconque trouverait et supprimerait. Un bon marqueur n”est pas visiblement un marqueur — il se fond dans des structures qui portent normalement du bruit.
• Robuste au traitement ordinaire. Il doit survivre aux choses courantes qui arrivent à un fichier en transit : copier, zipper, renommer, déplacer entre machines. Il n”a pas besoin de survivre à un attaquant déterminé et conscient du filigrane (rien n”y survit), mais il ne doit pas tomber du simple fait d”être transmis.
• Vérifiable de façon déterministe. Étant donné une copie suspecte, vous devez pouvoir extraire le marqueur mécaniquement et le confronter à vos registres d”émission sans conjecture. Une attribution qui repose sur « ça ressemble à la leur » n”est pas une attribution.

La tension est entre discret et robuste : plus vous encodez le marqueur de façon redondante en de nombreux endroits, plus il est difficile à retirer, mais plus il y a de surface pour le remarquer. La réponse pratique est la redondance en plusieurs emplacements discrets, de sorte que retirer une copie ne détruise pas la marque.

Où la marque peut vivre

Un assemblage .NET a de nombreux endroits qui tolèrent la variation par build sans changer le comportement, ce qui est exactement là où un filigrane a sa place. Le point n”est aucune cachette unique mais que le marqueur soit tissé dans des structures qui varient normalement d”une build à l”autre, de sorte que sa présence ne soit pas voyante :

// The marker is derived, not a plaintext ID — an opaque value that maps
// back to a licensee only through your issuance records.
// e.g. marker = HMAC(issuanceSecret, licenseeId)  → a 128-bit token

L”idée directrice est d”encoder ce token opaque dans des parties incidentes et neutres en comportement de la build, plutôt que dans un champ qui crie « identité ». Comme le token est dérivé et non un numéro de compte littéral, même quelqu”un qui trouve une copie de celui-ci n”apprend rien sur le schéma ni sur d”autres clients, et il ne se résout en un licencié que via des registres que vous seul détenez. Un obscurcisseur bien conçu peut porter le marqueur à travers ses transformations de sorte que le filigranage et la protection se produisent en une seule passe plutôt qu”en une étape ajoutée qu”un attaquant pourrait comparer à une build non marquée.

Vérifier une fuite

Le flux de travail quand une copie suspecte fait surface est mécanique, ce qui est tout l”intérêt. Vous passez l”extraction sur le fichier, récupérez le token incrusté, et le recherchez dans les registres d”émission qui mappent les tokens aux comptes. Comme le token a été dérivé de façon déterministe (par exemple comme un HMAC sur l”id du licencié avec un secret que vous seul détenez), vous pouvez aussi re-dériver le token attendu pour n”importe quel compte et confirmer la correspondance, plutôt que de faire confiance à une seule table de recherche. Le résultat est une affirmation défendable — ce binaire porte le marqueur émis au compte X à la date Y — pas une intuition.

C”est aussi là que le filigranage et le licensing se renforcent mutuellement. Si chaque activation lie déjà une copie à un licencié, l”identité d”activation est une graine naturelle pour le filigrane, et le marqueur d”une build divulguée s”aligne sur le même compte que vos registres de licensing suivent déjà. La protection, l”activation et l”attribution finissent par raconter une histoire cohérente sur l”origine d”une build.

Limites honnêtes

Un filigrane est un dissuasif et un outil de traçage, pas du DRM. Trois limites valent la peine d”être énoncées clairement. D”abord, il n”empêche rien — une build divulguée tourne toujours ; le filigrane vous dit seulement à qui elle appartenait. Ensuite, il n”est pas irretirable : un attaquant qui sait que la marque existe, sait où elle vit et est prêt à dépenser de l”effort peut la retirer ou la corrompre, c”est pourquoi la redondance et la discrétion comptent et pourquoi vous ne devriez pas la survendre. Enfin, l”attribution n”est fiable que dans la mesure de vos registres d”émission et du secret de votre clé de dérivation ; si ceux-ci fuient, la valeur du schéma aussi.

Dans ces limites, il gagne sa place. La plupart des fuites ne sont pas des opérations sophistiquées de dé-filigranage — c”est un licencié qui remet discrètement une build à quelqu”un qui ne devrait pas l”avoir, souvent sans réaliser que la copie est marquée individuellement. Un filigrane discret, redondant et vérifiable de façon déterministe attrape exactement ce cas et, une fois que les clients savent que les builds sont marquées, le décourage d”emblée. Obscurcissez pour que le code soit difficile à lire, filigranez pour qu”une fuite ait un nom, et licenciez pour que chaque copie soit liée à un compte — trois couches, trois rôles, une réponse cohérente à « qu”est-il arrivé à mon logiciel après qu”il a quitté le bâtiment ».