Signature de code

La signature de code est le processus de signature numérique des exécutables et des scripts pour confirmer l'auteur du logiciel et garantir que le code n'a pas été modifié ou corrompu depuis sa signature. Le processus utilise un hachage cryptographique pour valider l'authenticité et l'intégrité. La signature de code a été inventée en 1995 par Michael Doyle, dans le cadre du plug-in de navigateur Eolas WebWish, qui permettait l'utilisation de la cryptographie à clé publique pour signer le code du programme d'application Web téléchargeable à l'aide d'une clé secrète, de sorte que l'interpréteur de code du plug-in puisse ensuite utiliser la clé publique correspondante pour authentifier le code avant de lui permettre d'accéder aux API de l'interpréteur de code.

La signature de code peut fournir plusieurs fonctionnalités utiles. L'utilisation la plus courante de la signature de code est d'assurer la sécurité lors du déploiement ; dans certains langages de programmation, elle peut également être utilisée pour aider à prévenir les conflits d'espace de noms. Presque toutes les implémentations de signature de code fourniront une sorte de mécanisme de signature numérique pour vérifier l'identité de l'auteur ou du système de construction, et une somme de contrôle pour vérifier que l'objet n'a pas été modifié. Elle peut également être utilisée pour fournir des informations de version sur un objet ou pour stocker d'autres métadonnées sur un objet.

L'efficacité de la signature de code en tant que mécanisme d'authentification pour les logiciels dépend de la sécurité des clés de signature sous-jacentes. Comme pour les autres technologies d'infrastructure à clés publiques (PKI) , l'intégrité du système repose sur la protection des clés privées des éditeurs contre tout accès non autorisé. Les clés stockées dans des logiciels sur des ordinateurs à usage général sont susceptibles d'être compromises. Par conséquent, il est plus sûr et plus judicieux de stocker les clés dans des dispositifs matériels cryptographiques sécurisés et inviolables appelés modules de sécurité matériels ou HSM .

De nombreuses implémentations de signature de code fourniront un moyen de signer le code à l'aide d'un système impliquant une paire de clés, une publique et une privée, similaire au processus utilisé par TLS ou SSH . Par exemple, dans le cas de .NET, le développeur utilise une clé privée pour signer ses bibliothèques ou exécutables à chaque fois qu'il crée. Cette clé sera unique à un développeur ou à un groupe ou parfois à une application ou à un objet. Le développeur peut soit générer cette clé lui-même, soit en obtenir une auprès d'une autorité de certification (CA) de confiance.

La signature de code est particulièrement utile dans les environnements distribués, où la source d'un morceau de code donné peut ne pas être immédiatement évidente - par exemple les applets Java , les contrôles ActiveX et d'autres codes de script Web et de navigateur actifs. Une autre utilisation importante est de fournir en toute sécurité des mises à jour et des correctifs aux logiciels existants. Windows , Mac OS X et la plupart des distributions Linux fournissent des mises à jour à l'aide de la signature de code pour garantir qu'il n'est pas possible pour d'autres de distribuer du code de manière malveillante via le système de correctifs. Cela permet au système d'exploitation récepteur de vérifier que la mise à jour est légitime, même si la mise à jour a été fournie par des tiers ou des supports physiques (disques).

La signature de code est utilisée sur Windows et Mac OS X pour authentifier les logiciels lors de leur première exécution, garantissant ainsi que le logiciel n'a pas été altéré de manière malveillante par un distributeur ou un site de téléchargement tiers. Cette forme de signature de code n'est pas utilisée sur Linux en raison de la nature décentralisée de cette plate-forme, le gestionnaire de paquets étant le mode de distribution prédominant pour toutes les formes de logiciels (pas seulement les mises à jour et les correctifs), ainsi que le modèle open source permettant une inspection directe du code source si souhaité. Les distributions Linux basées sur Debian (entre autres) valident les paquets téléchargés à l'aide de la cryptographie à clé publique.

La clé publique utilisée pour authentifier la signature du code doit pouvoir être retracée jusqu'à une autorité de certification racine de confiance, de préférence à l'aide d'une infrastructure de clés publiques (PKI) sécurisée. Cela ne garantit pas que le code lui-même est fiable, mais seulement qu'il provient de la source indiquée (ou plus explicitement, d'une clé privée particulière ). Une autorité de certification fournit un niveau de confiance racine et est capable d'attribuer la confiance à d'autres par proxy. Si un utilisateur fait confiance à une autorité de certification, il peut alors vraisemblablement faire confiance à la légitimité du code signé avec une clé générée par cette autorité de certification ou l'un de ses proxys. De nombreux systèmes d'exploitation et frameworks contiennent une confiance intégrée pour une ou plusieurs autorités de certification. Il est également courant pour les grandes organisations de mettre en œuvre une autorité de certification privée, interne à l'organisation, qui offre les mêmes fonctionnalités que les autorités de certification publiques, mais qui n'est approuvée qu'au sein de l'organisation.

Les certificats de signature de code à validation étendue (EV) sont soumis à des exigences techniques et de validation supplémentaires. Ces directives sont basées sur les exigences de base et les directives de validation étendue du CA/B Forum. En plus des exigences de validation spécifiques à EV, les directives de signature de code EV stipulent que « la clé privée de l'abonné est générée, stockée et utilisée dans un module de chiffrement qui satisfait ou dépasse les exigences de la norme FIPS 140-2 niveau 2. »

Certaines applications, telles que la signature des pilotes en mode noyau de Windows 10, nécessitent un certificat de signature de code EV. De plus, l'IEBlog de Microsoft indique que les programmes Windows « signés par un certificat de signature de code EV peuvent immédiatement établir une réputation avec les services de réputation SmartScreen même si aucune réputation antérieure n'existe pour ce fichier ou cet éditeur. »

Il s'agit d'un exemple de certificat de signature de code EV décodé utilisé par SSL.com pour signer un logiciel. SSL.com EV Code Signing Intermediate CA RSA R3est indiqué comme le nom commun de l'émetteur, l'identifiant comme un certificat de signature de code EV. Le Subjectchamp du certificat décrit SSL Corp en tant qu'organisation. Code Signingest indiqué comme la seule utilisation étendue de la clé X509v3.

Certificat: Données: Version: 3 (0x2) Numéro de série: 59:4e:2d:88:5a:2c:b0:1a:5e:d6:4c:7b:df:35:59:7d Algorithme de signature : sha256WithRSAEncryption Émetteur : commonName = SSL.com EV Signature de code CA intermédiaire RSA R3 nom_organisation = SSL Corp nom de la localité = Houston nomdel'étatoudelaprovince = Texas nom du pays = États-Unis Validité Pas avant : 30 août 2019 20:29:13 GMT Pas après : 12 novembre 2022 20:29:13 GMT Sujet: 1.3.6.1.4.1.311.60.2.1.3 = États-Unis 1.3.6.1.4.1.311.60.2.1.2 = Nevada adresse de la rue = 3100 Richmond Ave Ste 503 businessCategory = Organisation privée code postal = 77098 nom commun = SSL Corp numéro de série = NV20081614243 nom_organisation = SSL Corp nom de la localité = Houston nomdel'étatoudelaprovince = Texas nom du pays = États-Unis Informations sur la clé publique du sujet : Algorithme à clé publique : rsaEncryption Clé publique : (2048 bits) Module: 00:c3:e9:ae:be:d7:a2:6f:2f:24 ... Exposant : 65537 (0x10001) Extensions X509v3 : Identifiant de la clé d'autorité X509v3 : ID clé : 36 : BD : 49 : FF : 31 : 2C : EB : AF : 6A : 40 : FE : 99 : C0 : 16 : ED : BA : FC : 48 : DD : 5F Accès aux informations d'autorité : Émetteurs d'autorités de certification - URI : http://www.ssl.com/repository/SSLcom-SubCA-EV-CodeSigning-RSA-4096-R3.crt OCSP - URI : http://ocsps.ssl.com Politiques de certification X509v3 : Politique : 2.23.140.1.3 Politique : 1.2.616.1.113527.2.5.1.7 Politique : 1.3.6.1.4.1.38064.1.3.3.2 CPS : https://www.ssl.com/repository Utilisation étendue de la clé X509v3 : Signature de code Points de distribution de la liste de révocation de certificats X509v3 : Nom et prénom: URI : http://crls.ssl.com/SSLcom-SubCA-EV-CodeSigning-RSA-4096-R3.crl Identifiant de la clé de sujet X509v3 : EC:6A:64:06:26:A7:7A:69:E8:CC:06:D5:6F:FA:E1:C2:9A:29:79:DE Utilisation de la clé X509v3 : critique Signature numérique Algorithme de signature : sha256WithRSAEncryption 17:d7:a1:26:58:31:14:2b:9f:3b ... 

L'autre modèle est le modèle de confiance à la première utilisation , dans lequel les développeurs peuvent choisir de fournir leur propre clé auto-générée. Dans ce scénario, l'utilisateur doit normalement obtenir la clé publique d'une manière ou d'une autre directement auprès du développeur pour vérifier que l'objet provient de lui pour la première fois. De nombreux systèmes de signature de code stockent la clé publique dans la signature. Certains frameworks logiciels et systèmes d'exploitation qui vérifient la signature du code avant l'exécution vous permettront de choisir de faire confiance à ce développeur à partir de ce moment-là après la première exécution. Un développeur d'applications peut fournir un système similaire en incluant les clés publiques avec le programme d'installation. La clé peut ensuite être utilisée pour garantir que tous les objets ultérieurs qui doivent être exécutés, tels que les mises à niveau, les plugins ou une autre application, sont tous vérifiés comme provenant de ce même développeur.

L'horodatage a été conçu pour contourner l'avertissement de confiance qui apparaîtra dans le cas d'un certificat expiré. En effet, l'horodatage étend la confiance du code au-delà de la période de validité d'un certificat.

Dans le cas où un certificat doit être révoqué en raison d'une compromission, une date et une heure spécifiques de l'événement compromettant seront intégrées au rapport de révocation. Dans ce cas, l'horodatage permet de déterminer si le code a été signé avant ou après la compromission du certificat.

Les développeurs doivent signer leurs applications iOS et tvOS avant de les exécuter sur un appareil réel et avant de les télécharger sur l' App Store . Cela est nécessaire pour prouver que le développeur possède un identifiant de développeur Apple valide. Une application a besoin d'un profil ou d'un certificat valide pour pouvoir s'exécuter sur les appareils.

Comme toute mesure de sécurité, la signature de code peut être contournée. Les utilisateurs peuvent être amenés à exécuter du code non signé, voire à exécuter du code qui refuse de valider, et le système ne reste sécurisé que tant que la clé privée reste privée.

Il est également important de noter que la signature de code ne protège pas l'utilisateur final contre toute activité malveillante ou tout bug logiciel involontaire de la part de l'auteur du logiciel. Elle garantit simplement que le logiciel n'a pas été modifié par une autre personne que l'auteur. Parfois, les systèmes sandbox n'acceptent pas les certificats, en raison d'un horodatage erroné ou d'une utilisation excessive de la RAM .

Microsoft implémente une forme de signature de code (basée sur Authenticode) fournie pour les pilotes testés par Microsoft. Étant donné que les pilotes s'exécutent dans le noyau, ils peuvent déstabiliser le système ou ouvrir le système à des failles de sécurité. Pour cette raison, Microsoft teste les pilotes soumis à son programme WHQL . Une fois le pilote validé, Microsoft signe cette version du pilote comme étant sûre. Sur les systèmes 32 bits uniquement, l'installation de pilotes qui ne sont pas validés par Microsoft est possible après avoir accepté d'autoriser l'installation dans une invite avertissant l'utilisateur que le code n'est pas signé. Pour le code .NET (géré), il existe un mécanisme supplémentaire appelé Strong Name Signing qui utilise des clés publiques/privées et un hachage SHA -1 par opposition aux certificats. Cependant, Microsoft déconseille de s'appuyer sur Strong Name Signing comme remplacement d'Authenticode.

Le groupe de travail sur la signature de code du CA/Browser Forum a décidé qu'à compter du 1er juin 2023, tous les certificats de signature de code (et pas seulement ceux des EA) devraient exiger le stockage des clés privées sur un support physique, comme dans un module de cryptographie matériel conforme au moins à la norme FIPS 140-2 niveau 2 ou aux critères communs EAL 4+. Les autorités de certification ont ensuite publié des annonces sur le respect de la décision.

Dans le contexte des appareils grand public tels que les consoles de jeux , le terme « code non signé » est souvent utilisé pour désigner une application qui n'a pas été signée avec la clé cryptographique normalement requise pour que le logiciel soit accepté et exécuté. La plupart des jeux de console doivent être signés avec une clé secrète conçue par le fabricant de la console, sinon le jeu ne se chargera pas sur la console (à la fois pour renforcer le verrouillage du fournisseur et pour lutter contre le piratage de logiciels). Il existe plusieurs méthodes pour obtenir l'exécution de code non signé, notamment les exploits logiciels , l'utilisation d'une puce de modification , une technique connue sous le nom d'astuce de swap ou l'exécution d'un softmod .

Il peut ne pas sembler évident au premier abord pourquoi la simple copie d'une application signée sur un autre DVD ne permet pas son démarrage. Sur la Xbox , la raison en est que le fichier exécutable Xbox (XBE) contient un indicateur de type de support, qui spécifie le type de support à partir duquel le XBE peut démarrer. Sur presque tous les logiciels Xbox, ce paramètre est défini de telle sorte que l'exécutable ne démarre qu'à partir de disques fabriqués en usine. La simple copie de l'exécutable sur un support gravable suffit donc à arrêter l'exécution du logiciel.

Cependant, étant donné que l'exécutable est signé, il n'est pas possible de modifier simplement la valeur de l'indicateur, car cela modifie la signature de l'exécutable, ce qui entraîne l'échec de la validation lors de la vérification.