Brevet FR2795262A1 — publié le 20001222

CERTIFICAT DU FABRICANT DE MODULE D'IDENTITE DE PROTOCOLE D'APPLICATION SANS FIL La présente invention se rapporte à un procédé de sécurité utilisant la cryptographie à clef asymétrique, particulièrement, bien que non exclusivement, pour utilisation avec un module d'identité de protocole d'application sans fil. La cryptographie à clef asymétrique ou publique, telle qu'elle est maintenant bien connue, utilise une clef privée à laquelle seul un utilisateur a accès et une clef publique, qui peut être publiée ou distribuée à la demande pour l'utilisation de ceux souhaitant communiquer avec l'utilisateur. Une troisième partie souhaitant communiquer avec l'utilisateur obtiendra tout d'abord un certificat portant la clef publique de l'utilisateur, qui peut être obtenue à partir d'une autorité de certification (CA). La troisième partie est ensuite capable de crypter un message en utilisant la clef publique de l'utilisateur pour décryptage ultérieur par l'utilisateur utilisant sa clef privée. L'approche signifie qu'une paire d'utilisateurs peuvent communiquer en utilisant leurs propres paires de clefs privées sans jamais avoir à échanger leurs clefs privées. Toutefois, dans la pratique, l'effort de calcul nécessaire pour crypter les données est tel qu'il est rarement appropriée pour de grands messages. Toutefois, la technique est appropriée pour l'authentification, la non-répudiation et les services d'intégrité. En tant que telle, la technique est particulièrement appropriée et a été adoptée pour utilisation dans le Protocole d'Application sans Fil (WAP), par exemple. Le WAP est une spécification largement répandue dans l'industrie pour développer des applications qui fonctionnent sur des réseaux de communication sans fil. A des fins de référence, les spécifications WAP sont publiées par le Wireless Application Protocol forum Ltd. et présentement disponibles à http://www.wapforum.org. Les exigences pour l'authentification, la non- répudiation et les services d'intégrité sont particulièrement applicables aux besoins du commerce électronique et en particulier aux Fournisseurs de Services Financiers (FSP), par exemple, les banques. De façon traditionnelle, les biens et les services ont été achetés en utilisant des objets physiques, fussent-ils monnayage, billets de banque, chèques, cartes de crédit et débit, et analogues. Ceci a procuré au vendeur l'opportunité d'établir si le paiement est authentique. Par exemple, dans le cas de billets, ceci peut prendre la forme du toucher du papier alors qu'une inspection visuelle de l'hologramme et de la signature sur une carte de crédit peuvent suffire. Dans le cas de paiement de téléphone utilisant une carte de crédit, ou au lieu d'un achat en magasin, l'évaluation peut inclure la vérification du numéro de la carte par rapport à une liste d'exclusion. Toutefois, avec l'arrivée du commerce électronique et en particulier l'opportunité de transactions sans espèces sur la base de données maintenues dans un terminal individuel de communication tel qu'un téléphone mobile, il existe le problème d'évaluer une transaction où les parties ne sont pas en mesure de porter les vérifications physiques. Ainsi, il a été proposé d'utiliser la technique décrite ci-dessus pour aider à de telles transactions. Afin de fournir la sécurité pour des clefs privées utilisées dans l'authentification de clients WAP, de signatures électroniques et analogues, on a trouvé nécessaire d'utiliser un dispositif résistant à la falsification. Ce dispositif est connu en tant que module d'identité de WAP (WIM). Le WIM est utilisé en particulier en vue de mémoriser et de traiter des informations nécessaires pour l'identification et l'authentification de l'utilisateur. De façon caractéristique, un WIM peut être mis en #uvre en tant que carte à microprocesseur. Dans le cas d'un téléphone mobile, le WIM pourrait faire partie de la carte du Module d'Identité de l'Abonné (SIM) ou peut- être d'une carte à microprocesseur externe. Néanmoins, il reste un problème supplémentaire significatif de sécurité, à savoir la contrefaçon et la fraude en relation avec la fabrication du WIM lui-même. C'est un but de la présente invention de se protéger contre la contrefaçon et la fraude en relation avec la fabrication d'un WIM. C'est un but supplémentaire de la présente invention de procurer un procédé pour établir la confiance dans la sécurité d'un WIM fabriqué conformément à une gamme de techniques. Ainsi, conformément à un premier aspect de la présente invention, il est proposé un module d'identité de protocole d'application sans fil (WIM) inviolable incluant mémorisés sur celui-ci une paire de clefs publique-privée et un certificat de fabricant, dans lequel le certificat de fabricant contient un jeu de champs maintenant des données se rapportant à ladite paire de clefs, le certificat étant signé en utilisant une clef privée supplémentaire. De préférence, le certificat de fabricant est signé en utilisant la clef privée de fabricant, bien que dans certaines circonstances où le module est distribué à un utilisateur avant la création d'un certificat de fabricant, il est nécessaire de mémoriser un certificat initial de gestion et de signature associée en utilisant une clef privée initiale de gestion de façon à procurer un moyen pour valider la signature appliquée au certificat de fabricant. Conformément à un autre aspect de la présente invention, il est prévu un procédé de fabrication d'un module d'identité de protocole d'application sans fil (WIM), inviolable incluant les étapes consistant à mémoriser une paire de clefs publique-privée sur ledit module avec un certificat de fabricant signé en utilisant une clef privée supplémentaire. A nouveau, le certificat de fabricant est de préférence signé en utilisant la clef privée de fabricant bien que dans certaines circonstances où le module est distribué à un utilisateur avant la création d'un certificat de fabricant, il sera nécessaire d'inclure l'étape supplémentaire consistant à mémoriser un certificat initial de gestion et signature associée en utilisant une clef privée initiale de gestion de façon à procurer un moyen pour valider la signature appliquée au certificat de fabricant. Conformément à un aspect supplémentaire de la présente invention, il est prévu un procédé de validation d'un module d'identité de protocole d'application sans fil (WIM) inviolable sur lequel sont mémorisés au moins une paire de clefs publique-privée avec un certificat de fabricant signé en utilisant une clef privée supplémentaire, le procédé comprenant l'étape consistant à questionner un répertoire public afin d'obtenir un certificat de clef publique avec lequel vérifier la signature générée par la clef privée supplémentaire. Lorsque le certificat est généré après distribution à un utilisateur, il sera nécessaire de questionner à la fois la signature générée par la clef privée supplémentaire, et la clef privée de fabricant. Dans ce cas, la clef privée supplémentaire est une partie d'une clef publique-privée crée par le fabricant en tant que paire initiale de clefs de gestion dont le certificat correspondant est signé en utilisant la clef privée de fabricant. Conformément à un aspect encore supplémentaire de l'invention, il est proposé un procédé de validation de l'identité d'un terminal de communication pour mener les transactions sur un réseau comprenant l'établissement de l'identité d'un utilisateur du terminal connecté au réseau, l'interrogation du terminal en vue d'obtenir une clef publique ou une paire de clefs publique-privée mémorisée sur le terminal, de confirmer l'authenticité d'un certificat signé par le fabricant du module supportant la clef publique et ensuite de délivrer un certificat supplémentaire pour la clef publique dont le certificat est disponible pour supporter les transactions avec le terminal sur le réseau. De préférence, le fournisseur de service de réseau peut mener l'authentification du certificat de fabricant. De façon avantageuse, la clef privée au moins est mémorisée sur un module inviolable qui peut être intégré à un Module d'Identité d'Abonné (SIM) situé dans le terminal. Conformément à encore un autre aspect de l'invention, il est proposé un dispositif de communication présentant mémorisée sur celui-ci une pluralité de certificats supportant des opérations de sécurité incluant l'authentification et la non-répudiation, et incluant en outre un certificat de fabricant mémorisé sur un module inviolable, dans lequel le certificat de fabricant contient un jeu de champs maintenant les données concernant une paire de clefs publique-privée pour sécurité de la couche d'application, la clef privée au moins étant mémorisée sur ledit module, le certificat étant signé en utilisant une clef privée supplémentaire. En même temps, conformément à un autre aspect encore de l'invention, il est proposé un procédé destiné à satisfaire un émetteur de module d'identité de la provenance d'un module d'identité pour utilisation dans des transactions sur un réseau, comprenant l'approbation par l'émetteur d'un procédé de fabrication du fabricant de module et comportant le fait que le fabricant mémorise un certificat de fabricant signé avec sécurité par le fabricant sur un module produit conformément au procédé approuvé, dans lequel sur connexion au réseau d'un terminal contenant un module, la signature est vérifiée pour déterminer si c'est celle du fabricant. A des fins de compréhension de l'invention, on décrira maintenant un certain nombre de modes de réalisation de celle-ci à titre d'exemple et en se référant aux dessins annexés, sur lesquels La Figure la est un tableau illustrant le contenu d'un certificat de fabricant généré conformément au procédé de la présente invention ; La Figure lb est un tableau illustrant les indicateurs d'utilisation de clef faisant partie du contenu du certificat de fabricant de la Figure la ; La Figure 2 est un organigramme des étapes impliquées dans la création d'un WIM contenant le certificat de fabricant de la Figure 1 conformément à un premier mode de réalisation de l'invention ; La Figure 3 est un organigramme des étapes impliquées dans la création d'un WIM contenant le certificat de fabricant de la Figure 1 conformément à un deuxième mode de réalisation de l'invention ; et La Figure 4 est un organigramme des étapes impliquées dans la création d'un WIM contenant le certificat de fabricant de la Figure 1 conformément à un troisième mode de réalisation de l'invention. En se référant tout d'abord à la Figure la, le tableau représente le contenu d'un certificat de fabricant 1 de Module d'Identité (WIM) de Protocole d'Application sans Fil (WAP) qui est constitué d'un certain nombre de champs 2 qui servent à identifier le certificat 1 en se référant à un numéro de série 3, l'émetteur ou fabricant 4, la première et la dernière date de validité du certificat 5,6, la nature d'une paire de clefs publique-privée couvertes par le certificat 7 et finalement la clef publique elle-même 8. En plus de mémoriser le certificat de fabricant 1, le WIM peut également mémoriser des certificats supplémentaires devant être utilisés, par exemple, dans l'authentification client de Protocole de Couche d'échange Sûr (SSL), et de Sécurité de Couche Transport (TLS) et également pour signer des messages de Protocoles d'Extensions de Messagerie Internet à Usages Multiples Sûrs (S/MIME). En outre, le WIM peut mémoriser des certificats d'Autorité de Certification (CA) de confiance afin de permettre la vérification des serveurs SSL, TLS, et applications Java téléchargées, par exemple. De tels certificats peuvent être mémorisés par l'émetteur du WIM ou à un moment ultérieur par l'utilisateur. Lorsque l'espace disponible sur le WIM est insuffisant ou indisponible, plutôt que de mémoriser les certificats supplémentaires sur le module, ils peuvent être trouvés en se référant à une adresse Web ("Universal Ressource Location") (URL), mémorisés sur le WIM. La Figure lb définit davantage les types d'utilisation auxquels une paire particulière de clefs peut être appliquée. Ainsi, une paire de clefs peut être utilisée dans la non-répudiation 9 qui signifie la caractéristique intrinsèque de cryptographie asymétrique d'un utilisateur qui est incapable de répudier un message précédemment authentifié parce que, contrairement aux systèmes à clef privée, l'utilisateur a seul la responsabilité de protéger sa clef privée. Une paire de clefs peut être utilisée dans la génération d'une signature numérique 10 qui permet l'authentification de documents et les échanges d'authentification tels qu'utilisés dans la spécification de couche de transport sans fil (WTLS) du WAP. Une paire de clefs peut également être utilisée dans un accord de clef il utilisé pour négocier un secret, en utilisant un schéma de Diffie-Hellman. Finalement, une paire de clefs peut être utilisée pour le décryptage ou le désenveloppage 12 d'une clef qui est nécessaire lorsqu'une application installée dans un terminal de communication tel qu'un combiné de téléphone mobile reçoit une clef message chiffrée avec une clef publique qui correspond à une clef privée dans le WIM. L'application envoie la clef enveloppée au WIM. Le WIM la déchiffre en utilisant la clef privée et renvoie la clef désenveloppée à l'application de sorte qu'elle puisse être utilisée pour déchiffrer le message attaché. En se référant maintenant à la Figure 2, l'organigramme établit les étapes selon lesquelles, dans un mode de réalisation de l'invention, un WIM contenant un certificat de fabricant 1 est créé pendant la fabrication d'un WIM avant livraison à un utilisateur. Tout d'abord, une paire de clefs est générée en 13 à l'extérieur du WIM et ensuite sauvegardée en 14 sur un WIM, qui peut être intégré avec une carte SIM pour utilisation avec un terminal de communication tel qu'un combiné de téléphone mobile ou en tant que carte à microprocesseur spécialisée pour utilisation avec un tel terminal. Tout enregistrement de la paire de clefs existant à l'extérieur du WIM doit ensuite être supprimé en 15. Un certificat de fabricant contenant les informations décrites ci-dessus est ensuite créé en 16 à l'extérieur du WIM et signé en 17 en utilisant la clef privée de fabricant avant d'être sauvegardée en 18 sur le WIM. Dans une variante non illustrée du procédé ci- dessus, plutôt que de sauvegarder le certificat de fabricant directement sur le WIM, une adresse URL pointant vers l'emplacement du certificat peut être mémorisée sur le WIM, réduisant de ce fait les besoins en mémoire du WIM. Il est important de reconnaftre que dans le procédé décrit ci- dessus il n'existe aucun besoin que le WIM supporte soit la création d'une paire de clefs, soit la création d'un certificat de fabricant. En se référant à la Figure 3, le certificat de fabricant de WIM est à nouveau créé pendant la fabrication d'un WIM avant livraison à un utilisateur. Dans ce mode de réalisation, le WIM est prévu avec la fonctionnalité nécessaire afin de lui permettre de créer une paire de clefs de façon interne en 17 et d'accéder ensuite en 18 à la clef publique pour la génération externe en 19 d'un certificat de fabricant qui est signé en 20 en utilisant la clef privée de fabricant. Le certificat de fabricant (Figure la) est ensuite sauvegardé en 21 sur le WIM, quoiqu'en une variante non illustrée, plutôt que de sauvegarder le certificat de fabricant directement sur le WIM, une adresse URL pointant vers l'emplacement du certificat peut être mémorisée sur le WIM réduisant de ce fait les besoins en mémoire du WIM. Le fait que la paire de clefs soit générée à l'intérieur du WIM améliore la sécurité du procédé. Finalement, par rapport la Figure 4, ce mode de réalisation se rapporte à la génération interne d'un certificat de fabricant par un WIM une fois qu'il est en possession d'un utilisateur. Dans ce procédé, il est nécessaire de générer tout d'abord en 22 une paire initiale de clefs de gestion à l'extérieur du WIM et de sauvegarder en 23 cette paire de clefs, conjointement avec un certificat initial de gestion correspondant signé en 24 en utilisant la clef privée de fabricant sur le WIM. La paire initiale de clefs de gestion procurera une fonctionnalité seulement limitée pour autant qu'elle puisse être utilisée simplement en vue de certifier une paire de clefs générée par le WIM, et ainsi n'est pas capable de fournir aucune des fonctionnalités décrites ci-dessus se rapportant à la Figure lb. Le WIM peut ensuite être distribué à un utilisateur, ce sur quoi l'utilisateur délivre une instruction ou peut-être de façon plus utile, suivant la réception d'une instruction externe, telle qu'une poussée sur les ondes (OTA-Push), le WIM crée en 25 une paire de clefs de façon interne, suivant laquelle le WIM génère en 26 un certificat de fabricant correspondant signé en 27 en utilisant la clef privée initiale de gestion. De façon claire, afin de satisfaire une tierce partie externe de la légitimité d'un certificat de fabricant signé de cette manière, il sera nécessaire, en plus du processus de validation établi ci-dessous et applicable à tous les modes de réalisation établis ici, que cette partie valide également le certificat initial de gestion signé en 24 en utilisant la clef privée de fabricant telle qu'établie ci- dessous. Ainsi, après les procédés de fabrication établis ci- dessus, il est nécessaire dans chaque cas de valider le WIM avant qu'il puisse être utilisé en transactions commerciales par le dispositif de communication. Ainsi, l'Autorité de Certification, à savoir le FSP qui délivre le WIM, c'est-à-dire sur les fonds dont l'utilisateur dépend, doit être tout d'abord assuré que le WIM a été produit par un fabricant avec lequel il a précédemment agréé les procédés de production qui satisfont les exigences du FSP pour aller à l'encontre de la fraude, de la falsification et analogues. De façon plus pratique, l'Autorité de Certification peut déléguer la tâche de valider un nouvel utilisateur à une Autorité d'Enregistrement (RA) avec laquelle elle a une relation de confiance. Comme le dispositif de communication dans lequel le WIM est contenu forme une partie d'un réseau, le CA peut déléguer le fournisseur du service de réseau en tant que RA. Ainsi, afin de permettre des transactions commerciales, l'utilisateur établira un appel vers la RA pendant laquelle la clef publique 8 de WIM associée à la clef privée mémorisée dans le WIM est extraite et l'identité de l'utilisateur est confirmée par la RA d'une manière connue, telle que par l'intermédiaire d'une enquête personnelle pour des données personnelles, par exemple le nom de jeune fille de la mère ou le mot de passe à usage unique. La RA authentifie également la signature du fabricant sur le certificat (Figure la) contenant la clef publique 8 de WIM. En conséquence, la RA obtient la clef publique de fabricant à partir d'un certificat supplémentaire signé par une CA, dans ce cas, la FSP. En supposant que la signature numérique puisse être authentifiée, c'est-à-dire que la CA n'a pas révoqué ou suspendu le certificat couvrant la clef publique de fabricant, alors la RA peut délivrer un certificat pour la clef publique 8 de WIM. Ce certificat de clef publique est ensuite placé dans un dépôt où il est disponible pour le public pour utilisation dans le support de transactions commerciales. D'une manière claire, si le procédé de validation devait échouer, on saurait alors que le WIM est peut-être une contrefaçon. De plus, lorsque pour quelque raison que ce soit, la CA a retiré son support au fabricant, il sera seulement nécessaire d'informer la RA, suspendant ou révoquant ainsi le certificat applicable couvrant la clef publique de fabricant, afin d'éviter la validation du WIM. Une raison possible pour que la CA retire son support à un fabricant peut inclure une rupture dans les protocoles de sécurité à l'emplacement de fabrication sur lesquels l'approbation du fabricant était basée à l'origine. I1 sera clair à partir de ce qui est indiqué ci- dessus, que toutes les étapes menées par la RA pourraient être assumées par la CA elle-même. Toutefois, le fait que le fournisseur de service de réseau possède un accès aisé au dispositif de communication simplifie le processus de validation. De même, par l'intermédiaire des processus habituels de réseau, par exemple le transfert de l'Identité d'Abonné Mobile International (IMSI) et des Codes d'Identité d'Abonné Mobile Temporaire ((TMSI), le réseau procure le bénéfice de révéler la nature du dispositif dans lequel le WIM est installé. Cette information peut s'avérer utile pour le FSP en déterminant la capacité du dispositif à traiter avec différents services de transaction. I1 conviendra de reconnaître, en liaison avec ce qui précède, que l'existence d'un certificat de fabricant sur le WIM ou une adresse à laquelle il peut être trouvé peut procurer la confiance à une Autorité de Certification (CA) que la paire de clefs associée au certificat de fabricant (Figure la) a été placée de façon sûre sur le WIM. Une telle confiance résultera bien entendu du fait que la CA peut identifier le fabricant du WIM et, avec bon espoir, d'être assuré de l'intégrité de génération de leur paire de clefs. De manière claire, lorsque la CA est persuadée de l'intégrité de la paire de clefs, elle est en position de délivrer un certificat certifiant de l'identité de l'utilisateur du WIM pour utilisation ultérieure par ceux souhaitant communiquer avec ledit utilisateur. Ainsi qu'on l'a précédemment indiqué, en pratique, la CA vérifiera le certificat de fabricant en accédant tout d'abord à un certificat contenant la clef publique propre de fabricant. Cette clef publique peut ensuite être utilisée pour vérifier le certificat de fabricant lui-même. En outre, le fabricant peut aussi bien avoir un certificat de CA unique destiné à certifier toutes les paires de clefs, ou il peut avoir une CA supérieure destinée à certifier des CA intermédiaires qui certifient les paires de clefs réelles. Une CA supérieure utilisée par un fabricant particulier peut elle-même être certifiée par une CA de troisième partie qui certifie également la CA supérieure d'autres fabricants. Une telle hiérarchie de certification facilite la distribution sûre des certificats de CA supérieure de différents fabricants. REVENDICATIONS 1. Module d'identité de protocole d'application sans fil (WIM) inviolable incluant mémorisés sur celui-ci une paire de clefs publique-privée et un certificat de fabricant, dans lequel le certificat contient un jeu de champs maintenant des données se rapportant à ladite paire de clefs, le certificat étant signé en utilisant une clef privée supplémentaire. 2. Module selon la revendication 1, dans lequel la clef publique est maintenue dans un champ dudit certificat. 3. Module selon la revendication 1 ou la revendication 2, incluant en outre un certificat d'autorité de certification. 4. Module selon l'une quelconque des revendications précédentes, dans lequel le dernier au moins des certificats est mémorisé de façon externe audit module à un emplacement éloigné qui peut être dérivé d'une adresse mémorisée sur ledit module. 5. Module selon l'une quelconque des revendications précédentes, dans lequel la clef privée supplémentaire est la clef privée de fabricant. 6. Module selon l'une quelconque des revendications 1 à 4, dans lequel la clef privée supplémentaire est une clef initiale de gestion, le module présentant de plus, mémorisé sur celui-ci, un certificat initial de gestion signé en utilisant la clef privée de fabricant. 7. Procédé de fabrication d'un module d'identité de protocole d'application sans fil (WIM) inviolable comprenant les étapes consistant à mémoriser une paire de clefs publique-privée sur ledit module avec un certificat de fabricant signé en utilisant une clef privée supplémentaire. 8. Procédé selon la revendication 7, dans lequel la paire de clefs est créée de façon externe audit module. 9. Procédé selon la revendication 7, dans lequel la paire de clefs est créée de façon interne audit module. 10. Procédé selon la revendication 8 ou la revendication 9, dans lequel le certificat de fabricant est créé de façon externe au module. 11. Procédé selon la revendication 10 en annexe à la revendication 9, dans lequel on accède au module pour obtenir la clef publique afin de faciliter la création externe du certificat. 12. Procédé selon l'une quelconque des revendications 7 à il, dans lequel la clef privée supplémentaire est la clef privée de fabricant. 13. Procédé selon la revendication 9, comprenant les étapes supplémentaires consistant à mémoriser une paire initiale de clefs de.gestion créée de façon externe et un certificat initial de gestion signé en utilisant la clef privée de fabricant sur ledit module, et à mémoriser un certificat de fabricant créé de façon interne sur ledit module, dans lequel la clef privée supplémentaire est la clef privée initiale de gestion. 14. Procédé de validation d'un module d'identité de protocole d'application sans fil (WIM) inviolable, sur lequel est mémorisée au moins une paire de clefs publique- privée avec un certificat de fabricant signé en utilisant une clef privée supplémentaire, le procédé comprenant l'étape consistant à questionner un répertoire public afin d'obtenir un certificat de clef publique avec lequel vérifier la signature générée par la clef privée supplémentaire. 15. Procédé de validation de l'identité d'un terminal de communication destiné à mener des transactions sur un réseau, comprenant l'établissement de l'identité d'un utilisateur sur le terminal connecté au réseau, l'interrogation du terminal destinée à obtenir une clef publique d'une paire de clefs publique-privée mémorisée sur le terminal, confirmer l'authenticité d'un certificat signé par le fabricant de module supportant la clef publique et délivrer ultérieurement un certificat supplémentaire pour la clef publique, lequel certificat est disponible pour supporter des transactions avec le terminal sur le réseau. 16. Procédé selon la revendication 15, dans lequel le fournisseur de service de réseau réalise l'authentification du certificat de fabricant. 17. Dispositif de communication présentant mémorisée sur celui-ci une pluralité de certificats supportant des opérations de sécurité incluant l'authentification et la non-répudiation, et incluant en outre un certificat de fabricant mémorisé sur un module inviolable, dans lequel le certificat de fabricant contient un jeu de champs maintenant des données se rapportant à une paire de clefs publique-privée, pour la sécurité de couche d'application, la clef privée au moins étant mémorisée sur ledit module, le certificat de fabricant étant signé en utilisant une clef privée supplémentaire. 18. Dispositif selon la revendication 17, dans lequel au moins un certificat supportant des opérations de sécurité est mémorisé de façon externe audit dispositif à un emplacement distant qui peut être dérivé d'une adresse mémorisée sur ledit dispositif. 19. Procédé destiné à satisfaire un émetteur de module d'identité de la provenance d'un module d'identité pour utilisation dans des transactions sur un réseau comprenant l'approbation par l'utilisateur d'un procédé de fabrication du fabricant de module, et dans lequel le fabricant mémorise un certificat de fabricant signé de façon sûre par le fabricant sur un module produit conformément au procédé approuvé, dans lequel sur connexion au réseau d'un terminal contenant un module, la signature est vérifiée afin de déterminer si elle appartient au fabricant. 20. Procédé selon la revendication 19, dans lequel le certificat de fabricant est signé en utilisant la clef privée de fabricant telle que sur connexion au réseau un certificat de clef publique est obtenu avec lequel on vérifie la signature. 21. Procédé selon la revendication 19 ou la revendication 20, dans lequel la vérification de la signature est menée par l'émetteur. 22. Procédé selon l'une quelconque des revendications 19 à 21, dans lequel en suivant la vérification réussie d'une signature, un certificat de clef publique supplémentaire est rendu disponible pour supporter des transactions avec le terminal, la clef publique ayant été mémorisée dans le certificat de fabricant.