demande de rappel immédiat

Un point sur les notions de "Signature de programmes" dans le monde Windows.

Posted by Jean-Paul Blanc Friday, April 02, 2010 8:17:07 AM
Rate this Content 24 Votes

 

 

Dans le monde du développement Windows la signature de programme peut prendre un sens différent selon qu'on ce place du point de vue d'un développeur de code natif ("C", "C++") ou d'un développeur de code managé ("C#" etc.). Loin d'être opposées ces notions peuvent même êtres complémentaires pour les développeurs .NET.

A) La signature du code exécutable dans le cadre de l'administration du poste Windows.


1) Principe.

 

Cette signature est complètement indépendante du type de binaire l'exécutable. Elle est, par exemple, insérée dans l'exécutable à travers les évènements de post génération, qu'il s'agisse d'un programme natif (binaire) ou managé (Intermediate Language). Du point de vue pratique elle se concrétise pour l'utilisateur par un onglet supplémentaire dans les propriétées du fichier comme le montre l'image ci-dessous.

Propriètés d'un fichier signé 

2) A quoi sert cette signature ?


i) L'UAC (User acount Control), introduite dans Windows Vista, utilise cette signature. Lors du démarrage d'un exécutable téléchargé dupuis internet ou exécuté depuis une unité réputée non sûre, le système utilise cette signature pour avertir l'utilisateur comme le représentent les deux messages d'avertissement ci-dessous.

UAC Avertissement de sécurité fichier non signé

Résultat de l'exécution d'un programme non signé depuis une unité non sûre.

UAC Avertissement de sécurité fichier signé

Résultat de l'exécution d'un programme signé depuis une unité non sûre.

ii) AppLocker s'appuient aussi sur la signature. Il permet a un administrateur d'établir des règles de stratégies de groupes basées sur l'éditeur d'un programme. Un administrateur peut ainsi autoriser l'exécution de programmes provenant d'éditeurs authentifiés et interdire l'execution des programmes provenant d'éditeurs inconnus.

iii) En tant q'éditeur de programme je pensais que c'était un moyen de m'assurer que personne ne peut retoucher ou exploiter un exécutable pour y introduire du code à mon inssue. Mais non ! Un exécutable signé corrompue (comprendre modifié habillement) peut encore s'exécuter. Si je vérifie la signature, je constate quelle n'est plus valide comme le montre la copie d'écran ci dessous, mais le système accèpte encore de l'exécuter !

Exemple de signature non valide après corruption du code

 

3) Signature d'un exécutable.


Le programme qui permet de signer un exécutable est signtool.exe. Microsoft le distribue à travers les différentes versions des SDKs et des DDKs.

Il permet, par exemple, de signer du code à partir d'un certificat installé dans le magasin de certificats, en le désignant par son émetteur (/i) et le nom du sujet (/n).

signtool.exe sign /i UTN-USER /n silogix HelloNET.exe

Il permet aussi de signer directment à partir d'un certificat.

signtool.exe sign /f MonCertificat.pfx /p <mot-de-passe>  /v "Fichier-à-signer"

B) La signature de code managé ou création de nom fort.

 

1) Principe

 

Le code managé est composé d’Assemblies. Un Assembly est le bloc de construction de base des applications .NET; il constitue l'unité fondamentale dans le déploiement, le contrôle de version, la réutilisation, la portée d'activation et les autorisations de sécurité. Un Assembly fournit au Common Language Runtime (CLR) les informations dont il a besoin pour reconnaître les implémentations des classes qu’il comporte.
De sorte à ne pas retomber dans l’enfer des DLLs Microsoft à pourvu les Assemblies d’un Manifest qui décrit notamment les dépendances entre Assemblies, mais aussi d’un nom fort pour assurer l’unicité de chaque Assembly indépendamment de son nom de fichier. L’opération qui consiste à insérer un nom fort est un processus appelé signature.
Le nom fort constitue donc l’identité de l’Assembly. Il est constitué de son nom textuel, sa version, ses informations de culture (si fournies) plus un clef publique et une signature numérique. Il est généré à partir du fichier de l’Assembly en utilisant la clef privée correspondante. Une fois qu’un Assembly est signé, tous les Assemblies qui référencent cet Assembly doivent aussi posséder un nom fort.

2) A quoi sert le nom fort ?


i) Un Assembly peut-être public ou privé. Les assembles public sont rassemblés dans le Global Assembly Cash (GAC) et pour des raisons d’unicité et de sécurité, ils doivent obligatoirement posséder un nom fort c'est-à-dire être signés.

ii) Signer un Assembly avec un nom fort permet de vérifier l’unicité afin d’éviter l’usurpation de nom. Cela permet aussi d'empêcher la coruption de l'Assembly. Le CLR pratique ainsi une vérification d’empreinte (Hash ou Digest). Le manifeste de l’Assembly contient une liste de tous les fichiers sur lesquels il s’appuie. Cette liste contient une empreinte de chaque fichier tel qu’il était au momment ou le manifeste à été construit. Au chargement de chaque fichier, son empreinte est calculée et comparée à la valeur stockée dans le manifeste. Si deux empreintes ne coïncident plus l’Assembly ne se charge pas.

3) Signature de code managé.

 

i) Création de nom fort.

La commande sn.exe sert à fabriquer le nom fort. Un fichier .snk doit contenir la clef qui sert à calculer le nom fort de l'assembly partagé.
sn –k Silogix.snk
Le fichier .snk doit être référencé par un attribut dans le fichier AssemblyInfo.cs :
[assembly: AssemblyKeyFile("../../Silogix.snk")]

ii) Assemblies à signature retardée.
Un composant signé par une entreprise engage la réputation de l'entreprise, pour cette raison, la clef privée d'une entreprise n'est pas mise à disposition de tous. Comme Les développeurs doivent pouvoir installer leurs Assemblies dans le GAC pour les tester il est possible de repousser la signature d'un Assembly à l'aide de l'attribut [AssemblyDelaySign(true)]. L'assembly peut alors être installé dans le GAC sans être signé. Il faut pour cela suivre la démarche suivante :

créer la clef de l'entreprise.
sn –k Silogix.snk
extraire la clef publique.
sn –p Entreprise.snk Silogix.public
installer sans vérification de signature.
sn –vr MonAssembly.dll
afficher le jeton de clef publique.
sn –t Silogix.public
Demander au GAC de ne pas vérifier la signature si le jeton est FD3612F5AED2BA79.
sn –Vr *, FD3612F5AED2BA79
Dans le fichier AssemblyInfo.cs, la clef publique seule sert à signer.
[assembly: AssemblyDelaySign(true)]
[assembly: AssemblyKeyFile("../../Silogix.public")]

Compléter la signature lorsque l'assembly est prêt à être distribué.
sn –R MonAsm.dll Entreprise.snk
Voir quels assemblies à signature retardée peuvent être installés et par qui.
sn –Vl
ATTENTION : Seul l'administrateur peut utiliser sn –Vr ou sn -vr, les développeurs peuvent, ensuite utiliser gacutil -i

Conclusion.

 

Un programme exécutable natif peut uniquement être signé, un programme managé peut contenir un nom fort ET être signé. Alors qu’un nom fort est stocké dans le fichier contenant le manifeste de l’Assembly, la signature est stockée dans un emplacement réservé de l’entêté PE (Portable Executable). En d’autres termes, le nom fort est traité par le CLR, la signature est traitée par le système d’exploitation.
Pour un Assembly les deux signatures sont complémentaires. Le nom fort permet de vérifier l’unicité et assure l’intégrité du code, cependant il ne fournit pas la notion d’accréditation ou de source de confiance, ce service est rendu par la signature du code. La signature du code demande à ce qu’un éditeur prouve son identité à une tierce partie (Autorité de certification). Le certificat est embarqué dans le fichier, un administrateur peut l’utiliser pour décider s’il a confiance ou non dans le code.
Dans la pratique il est possible d’insérer à la fois un nom fort et une signature numérique dans un Assembly, mais il est aussi possible d’utiliser l’un ou l’autre indépendamment. Pour un Assembly constitué de plusieurs fichiers, la signature numérique ne porte que sur le fichier contenant le Manifeste de l’Assembly. La signature numérique d’un Assembly peut-être utilisée (avec ou sans nom fort) quand il existe déjà une hiérarchie de confiance dans l’entreprise, mais aussi plus simplement quand l’entreprise utilise une stratégie basée sur l’identification des éditeurs.

Remarque : Dans le cas d’un Assembly le nom fort doit être assigné avant la signature du code.

Comments are closed on this post.