Brevet FR3032292A1 — publié le 20160805

DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne un élément sécurisé, tel qu'une carte à microcircuit ou un document d'identification comportant un microcircuit, et un procédé mis en oeuvre dans un tel élément sécurisé. Elle concerne plus particulièrement un élément sécurisé comportant une ressource informatique, telle qu'une application de signature électronique ou une clef cryptographique permettant de réaliser une signature électronique, et une interface de communication avec un lecteur externe. L'invention s'applique particulièrement avantageusement aux cartes et documents à microcircuit, destinés à être utilisés, notamment à des fins d'identification et de signature ou d'horodatage authentifié d'un document électronique, dans des environnements de niveau de fiabilité variable. ARRIERE-PLAN TECHNOLOGIQUE Les éléments sécurisés liés à un porteur, comportant un microcircuit, et utilisés à des fins d'identification, sont de plus en plus variés et répandus, qu'il s'agisse par exemple de cartes bancaires, de cartes de professionnels ou encore de pièces officielles d'identité. Un tel élément sécurisé peut par exemple servir à apposer une signature électronique sur un document électronique. Pour que cet élément sécurisé accepte d'apposer la signature qu'il contient, un utilisateur doit en général lui indiquer un code secret d'identification personnel (ou code PIN, selon l'acronyme anglo-saxon), connu uniquement de l'élément sécurisé et de son porteur attitré, et qui permet à ce dernier de s'identifier et de matérialiser son accord auprès de l'élément sécurisé. Lors d'une telle opération de signature électronique, les échanges d'informations correspondants doivent être sécurisés, c'est-à-dire authentifiés, confidentiels, et sans altération des informations échangées. Un tel l'élément sécurisé peut être utilisé dans un environnement considéré comme peu fiable, par exemple dans un lieu public, à partir d'un ordinateur en libre accès, ou encore donner accès à la ressource qu'il contient par l'intermédiaire d'un réseau informatique public. Lors de tels échanges, la politique de sécurité pour donner accès à ladite ressource doit correspondre à une sécurisation particulièrement forte, par exemple grâce à un chiffrement des données et à une authentification des entités interagissant avec l'élément sécurisé, et ce quitte à ralentir ou complexifier cet accès. En revanche, lorsque l'élément sécurisé est utilisé dans un environnement considéré comme fiable, il est avantageux que la politique de sécurité pour donner accès à la ressource contenue dans l'élément sécurisé corresponde à un accès moins sécurisé mais plus simple et plus rapide, par exemple parce qu'il n'implique pas de chiffrer les données échangées et de mettre en place des mécanismes d'authentification des entités interagissant avec lui. Il est ainsi connu d'utiliser plusieurs éléments sécurisés distincts, contenant la même ressource, chaque élément sécurisé étant adapté à un environnement différent. Mais cette solution est peu commode pour l'utilisateur, car elle l'oblige à porter sur lui plusieurs éléments sécurisés différents alors qu'ils contiennent la même ressource. Cela augmente par ailleurs les risques de perte de l'un des éléments sécurisés, et les risques de piratage de la ressource commune contenue dans ces éléments. Dans de tels cas, c'est d'ailleurs l'ensemble des éléments sécurisés qui doit être mis hors service. Il est également connu du document US 7,526,800 un procédé de protection des données présentes sur un ordinateur mobile destiné à subir de fréquents déplacements, et destiné ainsi à être connecté à des réseaux informatiques dans des contextes variés. Selon ce procédé, un mode de protection plus ou moins fort de ces données est sélectionné puis appliqué par ledit ordinateur mobile, en fonction de sa localisation et des caractéristiques physiques de ladite connexion. OBJET DE L'INVENTION Dans ce contexte, la présente invention propose un élément sécurisé comportant un microcircuit contenant une ressource informatique, et une interface de communication, conçu pour : - sélectionner, en fonction d'une information reçue par ladite interface de 30 communication, une politique de sécurité pour accéder à la ressource informatique, parmi au moins deux politiques de sécurité différentes, et pour - mettre à disposition ladite ressource informatique, par l'intermédiaire de ladite interface de communication, conformément à ladite politique de sécurité sélectionnée. Un utilisateur de l'élément sécurisé peut ainsi indiquer à ce dernier, par l'intermédiaire de l'interface de communication, quelle politique de sécurité mettre en oeuvre pour donner accès à ladite ressource informatique. Cela lui permet de choisir un niveau de sécurité plus ou moins fort pour la mise à disposition de la ressource informatique par l'élément sécurisé. Il peut ainsi adapter au mieux le fonctionnement de l'élément sécurisé, notamment en fonction du contexte d'utilisation. Disposer d'un seul élément sécurisé dont le fonctionnement peut être ainsi configuré est commode pour l'utilisateur, tout en favorisant quand cela est nécessaire la sécurité des échanges donnant accès à ladite ressource. Pour assurer au mieux la sécurité de ladite ressource, il est par ailleurs avantageux que la politique de sécurité pour accéder à cette ressource soit choisie directement par un utilisateur de l'élément sécurisé, plutôt que d'être choisi de manière automatique par des moyens informatiques, qui peuvent être exposés à des attaques malveillantes et à des dysfonctionnements. On peut prévoir également que ledit élément sécurisé est conçu pour vérifier que des données porteur reçues par l'intermédiaire de ladite interface de communication coïncident avec des données de référence mémorisées dans ledit élément sécurisé, et pour donner accès à la ressource seulement si les données porteur coïncident avec les données de référence. De telles données porteur peuvent par exemple comprendre un code d'identification personnelle (ou code PIN) connu uniquement de l'élément sécurisé et de son porteur attitré, ce qui lui permet avantageusement de s'identifier auprès de l'élément sécurisé et de lui matérialiser son accord pour la mise à disposition de la ressource informatique. De telles données porteur peuvent aussi comprendre des données biométriques caractéristiques du porteur attitré de l'élément sécurisé, comme par exemple une empreinte digitale, une image d'un iris, ou un enregistrement vocal. Plus généralement, elles comprennent des données liées au porteur attitré de l'élément sécurisé. D'autres caractéristiques non limitatives et avantageuses de l'élément sécurisé conforme à l'invention sont : - qu'il constitue une carte à microcircuit ; - qu'il constitue un document d'identification d'un porteur ; - que ladite ressource informatique comprend une clef cryptographique ; une telle clef cryptographique peut par exemple permettre de signer un document électronique ; plus généralement, une telle clef cryptographique permet de réaliser une opération à laquelle peut être associée une valeur légale, qu'il s'agisse d'une opération de signature électronique, d'ajout d'un sceau ou d'un horodatage électronique authentifié, ou encore d'une opération de déchiffrement, de livraison, ou de certification électronique ; - que ladite ressource informatique comprend un fichier ou un objet informatique, par exemple un pointeur, décrivant la localisation physique d'une clef cryptographique dans le microcircuit ; - que ladite ressource comprend une application de signature électronique, et - qu'il est conçu pour donner accès à ladite ressource en délivrant, par l'intermédiaire de l'interface de communication, des informations dont le niveau de protection est fonction de la politique de sécurité sélectionnée; une de ces politiques de sécurité peut notamment correspondre à un échange direct des données, sans protection, notamment sans chiffrement préalable. Ladite protection des données échangées peut ici être réalisée selon différentes modalités. Des données échangées peuvent ici être protégées en étant chiffrées, préalablement à leur transmission, par exemple. Elles peuvent également être protégées, tout en étant transmises sans être chiffrées, par l'ajout d'un code d'authentification de message, ou MAC (selon l'acronyme anglo-saxon de « Message Authentication Code »), accompagnant les données transmises, et permettant d'assurer leur intégrité. Un tel code d'authentification de message peut par exemple être produit à partir d'une clef cryptographique privée, par une transformation déterministe des données à transmettre. Les données échangées peuvent aussi être protégées à la fois par un chiffrement préalable à leur transmission, et par l'ajout d'un code d'authentification de message. Par protection des données, on désigne ci-dessous notamment l'un des types de protection décrit ci-dessus. D'autres caractéristiques non limitatives et avantageuses de l'élément sécurisé conforme à l'invention sont encore : - que ladite interface de communication comprend un clavier comportant des touches et que ladite information dépend de la touche activée par l'utilisateur ; - que ladite interface de communication comprend une interface de communication avec un lecteur externe et des moyens d'affichage ; - que lesdits moyens d'affichage comprennent un écran tactile, que ladite information dépend d'une position indiquée tactilement par le porteur sur l'écran tactile ; - que l'élément sécurisé est conçu pour afficher sur lesdits moyens d'affichage une information associée à ladite politique de sécurité sélectionnée ; cela permet d'informer l'utilisateur des modalités de mise à disposition de la ressource, et, de manière optionnelle de l'informer ou de lui rappeler le type de ressource ainsi mis à disposition ; à titre d'exemple, une telle information peut lui indiquer, lorsque cela est approprié, qu'un mode d'échange sécurisé a été sélectionné pour réaliser un horodatage (ou une signature) de document électronique ; et - que ladite information affichée comprend une information désignant ladite politique de sécurité sélectionnée. L'invention propose également un procédé mis en oeuvre dans un tel élément sécurisé, comportant les étapes suivantes : - une étape de sélection, en fonction d'une information reçue par ladite interface de communication, d'une politique de sécurité pour accéder à la ressource informatique parmi au moins deux politiques de sécurité différentes, et - une étape de mise à disposition de ladite ressource informatique, par l'intermédiaire de ladite interface de communication, conformément à ladite politique de sécurité sélectionnée à l'étape précédente. On peut prévoir également que ledit procédé comprenne : - une étape de vérification de données porteur reçues par l'intermédiaire de ladite interface de communication, au cours de laquelle ledit microcircuit vérifie que les données porteur coïncident avec des données de référence mémorisées dans ledit microcircuit, et - une séquence d'étapes au cours desquelles l'élément sécurisé donne accès à la ressource seulement si lesdites données porteur coïncident avec lesdites données de référence. Il est également prévu que ladite application de signature électronique, suite à la réception par l'intermédiaire de ladite interface de communication de données comprenant des données à signer : - vérifie que le niveau de protection desdites données reçues est conforme à la politique de sécurité sélectionnée, et - effectue une opération de signature électronique en utilisant une clef cryptographique privée contenue dans le microcircuit. L'invention propose également que, dans le procédé mis en oeuvre dans un élément sécurisé, le niveau de protection des informations délivrées par l'interface de communication est fonction de ladite politique de sécurité sélectionnée ; une de ces politiques de sécurité peut notamment correspondre à un échange direct des données, sans protection, notamment sans chiffrement préalable. Selon une autre possibilité, dans un tel procédé, le microcircuit peut utiliser des données complémentaires véhiculées par lesdites données porteur pour sélectionner une politique de sécurité à mettre en oeuvre pour donner accès à la ressource informatique. Lesdites données porteur reçues par l'interface de communication peuvent être calculées au préalable à partir de données de porteur initiales et d'une indication relative à la politique de sécurité sélectionnée, par une transformation déterministe. Une telle transformation déterministe peut par exemple comprendre une étape de concaténation des données porteur initiales et de l'indication relative à la politique de sécurité sélectionnée, puis par calcul d'un condensat à partir des données ainsi concaténées. D'autres caractéristiques non limitatives et avantageuses du procédé mis en oeuvre dans un élément sécurisé, conforme à l'invention, sont : - que l'interface de communication communique avec un module externe de communication, par l'intermédiaire d'ondes électromagnétiques, que le procédé comporte une étape de création d'un canal d'échanges sécurisés entre élément sécurisé et le module externe de communication, et que lesdites données porteur reçues par l'interface sont échangées en utilisant ce canal sécurisé ; - que l'élément sécurisé transmet à une interface homme-machine des données correspondant à des images comprenant des informations codées sous forme d'éléments distordus ou positionnés aléatoirement. L'invention prévoit également un procédé mis en oeuvre dans un élément sécurisé, conformément à l'invention, commandant des moyens d'affichage faisant partie de l'interface de communication, et au cours duquel : - les moyens d'affichage communiquent à un utilisateur une information désignant ladite politique de sécurité, précédemment sélectionnée en fonction de ladite information reçue par ladite interface de communication, - l'interface de communication reçoit une information qui confirme ou infirme que ladite politique de sécurité désignée par l'information affichée sur les moyens d'affichage est bien celle à mettre à oeuvre, et - le microcircuit donne accès à la ressource informatique, conformément à ladite politique de sécurité sélectionnée, si l'information reçue à l'étape précédente confirme que ladite politique de sécurité désignée par l'information affichée sur les moyens d'affichage est bien celle à mettre à oeuvre. Il est aussi prévu un procédé tel que décrit ci-dessus, au cours duquel, en outre, une interface homme-machine communique à un utilisateur une information associée à ladite politique de sécurité sélectionnée en fonction de ladite information reçue par ladite interface de communication. On peut prévoir également que ladite information communiquée comprend une information désignant ladite politique de sécurité précédemment sélectionnée, et que le procédé mis en oeuvre dans l'élément sécurisé comprenne en outre des étapes au cours desquelles : - ledit utilisateur confirme ou infirme que la politique de sécurité désignée par l'information communiquée par l'interface homme-machine est bien celle à 20 mettre à oeuvre, - le microcircuit donne accès à la ressource informatique, conformément à la politique de sécurité communiquée par l'interface homme-machine, si le choix de cette politique de sécurité a été confirmé lors de l'étape précédente, les informations échangées entre l'interface homme-machine et l'élément sécurisé 25 étant protégées. Selon les caractéristiques optionnelles du procédé conforme à l'invention, décrites ci-dessus, la politique de sécurité à mettre en oeuvre pour donner à ladite ressource peut donc être indiquée à l'élément sécurisé par un utilisateur, selon différentes modalités, plus ou moins fortement sécurisées. 30 Lorsque l'utilisateur et l'élément sécurisé échangent des informations par l'intermédiaire d'un canal considéré comme sécurisé, par exemple par l'intermédiaire d'un clavier situé directement sur l'élément sécurisé, ces échanges peuvent par exemple être réalisés directement, sans être protégés. L'utilisateur et l'élément sécurisé peuvent aussi échanger des informations par l'intermédiaire d'un canal considéré comme non sécurisé, par exemple par l'intermédiaire d'une interface homme-machine. Dans un tel cas, il est souhaitable de mettre en oeuvre des dispositions supplémentaires pour assurer la sécurité de ces échanges, par exemple, en prévoyant que l'utilisateur confirme le choix de politique de sécurité reçue par l'élément sécurisé avant que celui-ci ne soit mis en oeuvre, comme cela est décrit ci-dessus. Ces caractéristiques permettent d'assurer, dans différents contextes, la sécurité, l'authenticité et l'intégrité des informations échangées entre l'utilisateur et l'élément sécurisé pour indiquer à ce dernier la politique de sécurité à mettre en oeuvre. Lorsqu'un utilisateur choisit une politique de sécurité, plus ou moins sécurisée, plutôt qu'une autre, cela touche en effet de manière très profonde à la sécurité de fonctionnement de l'élément sécurisé. Il est donc crucial d'assurer, comme cela est fait ici, la sécurité, l'authenticité et l'intégrité des échanges d'informations correspondant. DESCRIPTION DETAILLEE D'UN EXEMPLE DE REALISATION La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. Sur les dessins annexés : - la figure 1 représente schématiquement les principaux éléments constituant un élément sécurisé conforme à l'invention, - la figure 2 représente schématiquement les principales entités d'un exemple d'environnement considéré comme fiable dans lequel un tel élément sécurisé peut être utilisé, - la figure 3 représente schématiquement les principales entités d'un exemple d'environnement considéré comme peu fiable dans lequel un tel élément sécurisé peut être utilisé, - la figure 4 représente schématiquement la structure générale des échanges ayant lieu entre un tel élément sécurisé, l'utilisateur d'un tel élément, et une application cliente, - sur la figure 5 est représenté un premier protocole permettant à un utilisateur de l'élément sécurisé de lui indiquer quelle politique de sécurité mettre en oeuvre pour donner accès à la ressource qu'il contient, - sur les figures 6 à 10 sont représentés cinq autres tels protocoles, - la figure 11 représente schématiquement une séquence d'échanges au cours desquels une application cliente accède à la ressource stockée par l'élément sécurisé, selon une politique de sécurité adaptée à un environnement fiable, sans protection des échanges, - la figure 12 représente schématiquement une séquence d'échanges au cours desquels une application cliente accède à la ressource stockée par l'élément sécurisé, selon une politique de sécurité adaptée à un environnement peu fiable, avec protection des échanges par chiffrement. Comme on peut le voir sur la figure 1, un élément sécurisé 100 conforme à l'invention comprend principalement : - une interface de communication 109 comprenant une interface 101 de communication avec un lecteur externe et, de manière optionnelle, un clavier 107, et des moyens d'affichage 110, par exemple un écran ou un écran tactile, et - un microcircuit 108 comprenant un processeur 102 réalisant des opérations logiques (par exemple un microprocesseur) et un module de mémorisation 103 (par exemple une mémoire non-volatile réinscriptible). Dans le module de mémorisation 103 sont enregistrées différentes données, notamment : - une ressource 104 que l'élément sécurisé peut mettre à disposition de l'extérieur par l'intermédiaire de l'interface 101, - des instructions et des données de référence 105 qui leur sont associées, permettant de vérifier l'identité d'un utilisateur de l'élément sécurisé 100, et - des instructions et des données 106 qui lui sont associées, permettant à l'élément sécurisé de mettre en oeuvre différentes politiques de sécurité pour donner accès à la ressource 104, selon le choix de politique de sécurité indiqué par l'utilisateur. La ressource 104 peut comprendre une clef cryptographique permettant par exemple de produire une signature électronique, ou, plus généralement, permettant de réaliser une opération à laquelle peut être associée une valeur légale. Une telle opération peut par exemple comprendre l'ajout d'un sceau ou d'un horodatage électronique, ou encore être une opération de déchiffrement, de livraison, ou de certification électronique. Selon une autre possibilité, la ressource 104 peut comprendre un fichier ou un objet informatique, par exemple un pointeur, décrivant la localisation physique d'une telle clef cryptographique dans le microcircuit 108. La ressource 104 peut également comprendre une application de signature électronique. Dans un autre mode de réalisation, l'élément sécurisé 100 peut comprendre plusieurs ressources informatiques distinctes, par exemple une clef cryptographique permettant de produire une signature électronique, et une autre ressource permettant d'attester du caractère officiel d'une opération de déchiffrement. Les données de référence 105 permettant de vérifier l'identité d'un utilisateur de l'élément sécurisé 100 comprennent des données liées au porteur attitré de l'élément sécurisé 100, comme par exemple un code PIN, ou des données biométriques telles que des données représentatives d'une empreinte digitale, d'une image d'un iris, ou d'un enregistrement vocal. Certaines des politiques de sécurité mises en oeuvre par l'élément sécurisé peuvent impliquer un accès protégé à la ressource 104. Les données 106 permettant la mise en oeuvre desdites politiques de sécurité peuvent donc comprendre notamment des clefs d'authentification, de chiffrement, publiques ou privées, des certificats électroniques permettant de vérifier l'identité d'entités informatiques, ou d'autres objets permettant de protéger les échanges donnant accès à la ressource 104. Les composants de l'élément sécurisé 100 présentés ci-dessus collaborent entre eux pour mettre en oeuvre des procédés tels que ceux décrits ci-25 dessous. Ces composants peuvent aussi remplir des fonctions supplémentaires comme par exemple autoriser des opérations bancaires. L'élément sécurisé 100 décrit ci-dessus peut par exemple être une carte à microcircuit ou un document d'identification. 30 La figure 2 représente schématiquement les principales entités d'un exemple d'environnement considéré comme fiable, dans lequel un tel élément sécurisé peut être utilisé. Ces entités comprennent notamment : - un élément sécurisé 100 conforme à l'invention, - une interface d'identification personnelle 201 servant d'interface avec ledit élément sécurisé 100, - un utilisateur 203, - un dispositif informatique 204. L'interface d'identification 201 peut être directement incluse dans le dispositif informatique 204, ou être simplement connectée à ce dernier. L'interface d'identification personnelle 201 peut par exemple être un clavier d'identification personnelle, ou « PINPad », selon la dénomination anglo-saxonne, comprenant un clavier et un écran. Selon une autre possibilité, l'interface d'identification personnelle 201 peut comprendre un écran tactile. Plus généralement, l'interface d'identification personnelle 201 est une interface homme-machine. De manière optionnelle, elle peut comprendre des capteurs conçus pour déterminer des données biométriques d'un utilisateur, telles que des données représentatives d'une empreinte digitale, d'une image d'un iris, ou d'un enregistrement vocal. Le dispositif informatique 204 héberge une application cliente 202 qui peut avoir accès à (ou utiliser) la ressource 104 stockée dans l'élément sécurisé 100. Le dispositif 204 peut en outre comprendre une interface homme-machine 205, tels qu'un écran, un clavier, un écran tactile, ou un haut-parleur. Cette interface homme-machine 205 permet notamment une interaction bidirectionnelle de l'utilisateur avec l'élément sécurisé 100 et une interaction bidirectionnelle de l'utilisateur avec l'application cliente 202. Un tel environnement est considéré comme fiable lorsque le dispositif informatique 204 est par exemple un ordinateur utilisé par le porteur attitré du dispositif, sur son lieu de travail habituel, et est sous son contrôle. Le fait que l'application cliente soit hébergée dans un dispositif informatique 204 qui communique directement et localement avec l'élément sécurisé, sans passer par l'intermédiaire d'un réseau informatique public, contribue fortement à la fiabilité d'un tel environnement. Dans un tel environnement, l'application cliente 202 peut accéder à la ressource 104 selon une politique de sécurité simplifiée n'impliquant pas de protection des échanges, comme expliqué ci-dessous en référence à la figure 11. La figure 3 représente schématiquement les principales entités d'un exemple d'environnement considéré comme peu fiable, dans lequel un tel élément sécurisé peut être utilisé. Ces entités comprennent notamment : - un élément sécurisé 100 conforme à l'invention, - une interface d'identification personnelle 201, telle que décrite ci-dessus, servant d'interface avec ledit élément sécurisé 100, - un utilisateur 203, - un dispositif informatique 301, tel qu'un ordinateur ou un terminal de connexion, - un serveur 302 hébergeant une application cliente 202, - une autorité de certification 303, - un réseau informatique public 304, par exemple le réseau Internet, par l'intermédiaire duquel le dispositif informatique 301, le serveur 302 et l'autorité de certification 303 peuvent échanger des informations. L'application cliente 202 peut utiliser la ressource 104 stockée dans l'élément sécurisé 100, en y accédant par l'intermédiaire du réseau public 304. L'interface d'identification 201 est par exemple incluse directement dans le dispositif informatique 301. Ce dernier peut en outre comprendre une interface homme-machine 205, telle qu'un écran, un clavier, un écran tactile, ou un haut- parleur. Cette interface homme-machine 205 permet à l'utilisateur d'interagir notamment avec l'élément sécurisé 100 et avec l'application cliente 202 et vice versa. Un tel environnement est considéré comme peu fiable notamment parce qu'un accès à l'élément sécurisé 100 est possible depuis un réseau public, et parce que des données confidentielles et/ou sensibles associées à ces échanges peuvent circuler sur ce réseau public. Plus généralement, cet environnement est considéré comme peu fiable car il n'est pas, dans sa globalité, sous le contrôle de l'utilisateur. Dans ce cadre, il est préférable de mettre en oeuvre une politique de sécurité pour donner accès à la ressource 104 qui soit sécurisée, notamment grâce à une protection (ici par chiffrement) des informations échangées entre l'application 202 qui souhaite utiliser la ressource 104 et la ressource 104 elle-même, comme décrit ci-dessous en référence à la figure 12. La figure 4 représente schématiquement la structure générale des échanges ayant lieu entre un élément sécurisé 100 conforme à l'invention, un utilisateur 203 d'un tel élément, et une application cliente 202. Sur cette figure, les actions se suivent dans le temps, du haut vers le bas. Pour que l'application cliente 202 puisse accéder à la ressource contenue dans l'élément sécurisé 100, des données porteur, telles que décrites ci- dessus, lui sont tout d'abord transmises par l'intermédiaire de l'interface d'identification personnelle 201 (échange d'informations Ti). L'élément sécurisé 100 vérifie alors que ces données porteur coïncident avec les données de référence 105 associées à son porteur attitré, lors de l'étape El. Lorsque les données porteur comprennent un code PIN, par exemple, cette vérification est réalisée en comparant un code PIN saisi sur le clavier 201 et un code PIN mémorisé 105. L'utilisateur indique ensuite à l'élément sécurisé la politique de sécurité à mettre en oeuvre pour donner accès à la ressource qu'il contient (échange d'informations T2). Dans certaines variantes d'exécution, la politique de sécurité à mettre en oeuvre peut être indiquée par l'utilisateur directement lors du transfert Ti des données porteur à l'élément sécurisé. L'application cliente 202 envoie ensuite une requête à l'élément sécurisé 100 pour accéder à la ressource 104 (échange d'informations T3), selon des modalités conformes à la politique de sécurité choisie par l'utilisateur. Lors de cet échange, des données à signer peuvent être transmises. En fonction de la politique de sécurité indiquée précédemment, cet échange peut par ailleurs débuter par la création de clefs de chiffrement et/ou par des étapes d'authentification de l'application cliente et de l'élément sécurisé. L'élément sécurisé 100 peut comporter des données accessibles à l'application cliente 202 et comportant une information indiquant la politique de sécurité à appliquer pour les échanges de données. On peut ainsi prévoir que l'application cliente 202 accède à de telles données, préalablement à l'échange d'informations T3, de manière à pouvoir réaliser ensuite l'échange d'informations T3 conformément à la politique de sécurité sélectionnée par l'utilisateur. L'élément sécurisé 100 peut aussi n'accepter d'interagir avec une application cliente 202 que lorsque celle-ci communique avec lui conformément à la politique de sécurité sélectionnée par l'utilisateur. Cette disposition permet de fiabiliser utilement un tel procédé. Elle permet aussi à une application cliente 202 de déterminer la politique de sécurité à utiliser pour communiquer avec l'élément sécurisé 100, par une suite d'essais, préalablement à l'échange d'informations T3. Dans ce dernier cas, l'application cliente tente de communiquer avec l'élément sécurisé 100 selon chacune des politiques de sécurité possible, testées successivement, et cesse ladite suite d'essais dès qu'une telle communication est établie avec succès, car cela indique alors que la politique de sécurité utilisée correspond à celle sélectionnée par l'utilisateur. L'élément sécurisé donne enfin accès à ladite ressource, toujours selon la politique de sécurité choisie par l'utilisateur (échange d'informations T4). Comme mentionné précédemment, donner accès à ladite ressource peut par exemple consister à générer une signature électronique relative aux données reçues lors de l'échange d'informations T3. Des exemples de politiques de sécurité envisageables sont donnés ci-dessous en référence aux figures 11 et 12. Les échanges décrits ci-dessus de manière générique peuvent être mis en pratique par différents protocoles, par lesquels un utilisateur de l'élément sécurisé lui indique quelle politique de sécurité mettre en oeuvre pour donner ensuite accès à la ressource qu'il contient. Sept protocoles de ce type sont décrits plus en détail ci-dessous. Sur les figures correspondantes (figures 5 à 10), les actions se suivent dans le temps, du haut vers le bas. Les sept protocoles représentés schématiquement sur les figures 5 à 10 sont décrits dans le cas non limitatif dans lequel les données porteur correspondent à un code PIN. Ils peuvent être généralisés aux différents types de données porteur décrits ci-dessus. Sur la figure 5 est représenté un premier tel protocole. Pour s'identifier auprès de l'élément sécurisé et lui indiquer la politique de sécurité choisie, l'utilisateur dispose dans ce cas de plusieurs codes PIN (PINi, PIN2,...,PIN1,...), chacun étant associé à une politique de sécurité différente (politique de sécurité numéro 1, numéro 2,..., numéro i,... ). L'utilisateur transmet l'un de ces codes PIN à l'élément sécurisé 100, par l'intermédiaire de l'interface d'identification personnelle 201 (échange d'informations T5). L'élément sécurisé contrôle alors que ce code PIN correspond bien l'un des codes PIN d'identification de son porteur attitré, lors de l'étape E2. L'application cliente 202 accède ensuite à la ressource 104 (échanges d'informations T3 et T4), selon la politique d'accès numéro i correspondant au code PIN « PIN; » qui a été transmis par l'utilisateur. Sur la figure 6 est représenté un deuxième tel protocole, proche du précédent. Au cours de celui-ci, l'utilisateur 203 transmet son code PIN d'identification à un dispositif auxiliaire 60 tel qu'un téléphone portable (échange d'informations TA1). Il indique également à ce dispositif auxiliaire 60 la politique de sécurité qu'il a choisie pour donner accès à la ressource, par exemple la politique de sécurité numéro i (échange d'informations TA2). A partir de ces données, un code PIN « PINi' » est calculé par le dispositif auxiliaire 60 selon une transformation déterministe (étape EA). Le code PIN « » peut par exemple être obtenu par concaténation et hachage du code PIN d'identification de l'utilisateur et d'une information indiquant la politique de sécurité choisie. Ce code « PINi' » est communiqué à l'utilisateur par le dispositif auxiliaire 60 (échange d'informations TA3). L'utilisateur 203 transmet alors ce code « PINi' » à l'élément sécurisé 100, par l'intermédiaire d'une interface d'identification personnelle 201 (échange d'informations T5). L'élément sécurisé contrôle ensuite que ce code « PINi' » est bien relié à son porteur attitré, lors de l'étape E2. Enfin, l'application cliente 202 accède à la ressource 104 (échanges d'informations T3 et T4), selon la politique de sécurité numéro i. Par rapport au protocole représenté sur la figure 5, les étapes auxiliaires supplémentaires TA1, TA2, EA et TA3 évitent à l'utilisateur de devoir se souvenir de plusieurs codes PIN différents. Le protocole représenté sur la figure 7 est proche des deux protocoles décrits ci-dessus, mais implique un chiffrement des données échangées entre l'élément sécurisé 100 et une interface d'identification personnelle 201. Au cours de ce protocole, l'utilisateur 203 commence par saisir son code PIN et indiquer la politique de sécurité que doit mettre en oeuvre l'élément sécurisé 100 sur l'interface d'identification personnelle 201 (échange d'informations T6). L'interface d'identification personnelle 201 transmet tout d'abord à l'élément sécurisé, lors de l'échange d'information T7, le choix de politique de sécurité de l'utilisateur. Il transforme ensuite cette donnée par concaténation avec le code PIN saisi par l'utilisateur, et utilise ensuite ces données transformées pour créer une clef de chiffrement temporaire destinée à chiffrer les informations échangées avec l'élément sécurisé 100 (étape E3). Cette étape permet aussi à l'élément sécurisé et à l'utilisateur de s'authentifier mutuellement, et de vérifier l'identité de l'utilisateur. Cette étape est par exemple réalisée conformément au protocole PACE (acronyme anglo-saxon de « Password Authenticated Connection Establishement », ou Etablissement de Connexion Authentifiée, par mot de Passe), décrit dans le document « Machine Readable Travel document - Technical report - Supplemental Access control for Machine readable travel documents version v1.01 du 11 novembre 2010 » produit par l'Organisation internationale de l'aviation civile (« ICAO »). L'application cliente 202 accède ensuite à la ressource 104 (échanges d'informations T3 et T4), selon la politique de sécurité ainsi indiquée. Lors d'un tel procédé, l'interface d'identification personnelle est amenée à créer ladite clef de chiffrement temporaire sur la base de données variant en fonction de la politique de sécurité choisie par l'utilisateur. L'établissement d'un canal d'échange sécurisé selon le protocole PACE, mentionné ci-dessus, est toutefois possible dans ce cas, car ledit choix de politique de sécurité est transmis à l'élément sécurisé (lors de l'étape T7), préalablement à l'établissement du canal d'échanges sécurisé (étape E3). Protéger ainsi les échanges entre l'interface d'identification personnelle 201 et l'élément sécurisé 100, et procéder à leur authentification mutuelle est particulièrement avantageux dans le cas où ils communiquent par l'intermédiaire d'ondes électromagnétiques, sans contact électrique direct. Des dispositifs malveillants peuvent en effet intercepter de telles ondes électromagnétiques, ou les utiliser pour émettre des informations, en tentant de faire croire, à des fins malveillantes, que ces informations émanent de l'interface d'identification personnelle ou de l'élément sécurisé. Le mode d'authentification utilisé par ce protocole permet par ailleurs à l'élément sécurisé de conserver (de manière temporaire) une trace de l'identification de l'utilisateur et de l'élément sécurisé. Le choix de politique de sécurité à mettre en oeuvre étant transmis à l'élément sécurisé avant l'établissement d'un canal d'échanges sécurisés, on peut prévoir de manière optionnelle, afin de renforcer la sécurité d'un tel procédé, une vérification a posteriori du choix de politique de sécurité reçu par l'élément sécurisé 100 lors de l'étape T7. Une telle vérification peut être réalisée en demandant à l'utilisateur une confirmation de ce choix, par exemple par l'intermédiaire du canal d'échanges sécurisé précédemment créé, ou par l'intermédiaire de moyens d'affichages, comme cela réalisé par exemple dans le protocole représenté schématiquement figure 8 et décrit ci-dessous. Dans un quatrième protocole, l'utilisateur 203 saisit directement son code PIN d'identification sur un clavier 107 équipant l'élément sécurisé 100. L'utilisateur indique sur ce même clavier quelle politique de sécurité l'élément sécurisé doit mettre en oeuvre pour donner accès à la ressource qu'il contient. Ce protocole a l'avantage de ne requérir de l'utilisateur de ne mémoriser qu'un seul code PIN, et de garantir physiquement la sécurité de ces deux échanges d'informations (qui correspondent aux échanges Ti et T2 de la figure 4). Dans un mode de réalisation alternatif, l'élément sécurisé comporte un capteur biométrique intégré et utilise une donnée biométrique afin d'identifier l'utilisateur. La figure 8 représente schématiquement un cinquième protocole par lequel un utilisateur 203 indique à l'élément sécurisé 100 quelle politique de sécurité mettre en oeuvre, par l'intermédiaire d'une interface homme-machine 205 telle qu'un écran tactile. Lors de ce protocole, l'utilisateur commence par transmettre son code PIN à l'élément sécurisé 100 par l'intermédiaire de l'interface homme-machine 205 (échange d'informations T9). L'élément sécurisé 100 contrôle alors que ce code PIN est bien celui de son porteur attitré, lors de l'étape El. L'élément sécurisé 100 transmet alors à l'interface homme-machine 205 une question à choix multiples (échange T10), chacun de ces choix correspondant à l'une des politiques de sécurité pour donner accès à la ressource 104. L'échange T10 étant réalisé entre l'élément sécurisé 100 et une interface homme-machine reliée matériellement de manière directe à ce dernier, il n'est pas nécessaire de protéger cet échange. L'interface homme-machine communique alors cette question à l'utilisateur (échange T11). Cette question peut par exemple être posée à l'utilisateur sous la forme d'une image affichée sur l'interface 205, ou sous la forme d'un message sonore émis par cette interface. Si deux politiques de sécurité différentes sont par exemple possibles pour donner accès à la ressource 104, ladite question pourra par exemple être posée sous la forme d'une image comportant deux sous-images associées chacune à l'un de ces politiques de sécurité. L'utilisateur indique alors quelle est la politique de sécurité à mettre en oeuvre en sélectionnant, avec un pointeur informatique tel qu'une souris informatique, la zone de l'image principale où est positionnée la sous-image correspondante. Afin de rendre imprévisible la réponse attendue pour une politique de sécurité donnée, chaque sous-image peut être positionnée aléatoirement au sein de l'image principale et la réponse indicative de la politique de sécurité à mettre en oeuvre, transmise entre l'interface homme machine et l'élément sécurisé 100, peut dans ce cas désigner la position courante de la sous-image sélectionnée. Pour permettre par ailleurs à l'utilisateur de vérifier que la question provient bien de l'élément sécurisé 100, lesdites sous-images peuvent correspondre à des sous-images spécifiques, préenregistrées dans l'élément sécurisé 100 par son porteur attitré lors d'une étape de personnalisation de l'élément sécurisé 100 (non détaillée ici). Le porteur attitré de l'élément sécurisé peut par exemple préenregistrer une image du bureau où il travaille habituellement, évocatrice pour lui d'un environnement considéré comme fiable, pour qu'elle soit utilisée dans le protocole décrit ci-dessus comme sous-image associée à une politique de sécurité pour donner accès à la ressource 104 sans protection des échanges. Dans une autre variante d'exécution, les sous-images associées à chaque politique de sécurité peuvent comprendre quelques mots (par exemple « accès protégé» ou « accès simple »), dont les lettres ont été distordues, par exemple selon un mécanisme de type « captcha », de manière à ce que seul un utilisateur humain puisse déchiffrer l'image. Une fois que la politique de sécurité pour donner accès à la ressource 104 a été indiquée par l'utilisateur, conformément au protocole décrit ci-dessus (échanges d'informations T12 et T13), l'application cliente 202 accède à la ressource 104 conformément à ladite politique de sécurité indiquée (échanges d'informations T3 et T4). La figure 9 représente schématiquement un sixième protocole par lequel un utilisateur 203 indique à l'élément sécurisé 100 quelle politique de sécurité mettre en oeuvre pour donner accès à la ressource qu'il contient. Dans ce protocole, l'élément sécurisé 100 s'assure que la politique de sécurité qui lui a été indiquée l'a bien été par l'utilisateur (et non par un logiciel malveillant, par exemple) en demandant à ce dernier de confirmer le choix de cette politique de sécurité. A cette fin, et pour assurer la sécurité de cette étape de confirmation, l'élément sécurisé est muni de moyens d'affichage 110. Les premières étapes de ce protocole sont les étapes Ti, El et T2, telles que détaillées ci-dessus lors de la description de la figure 4. A l'issu de ces étapes, l'élément sécurisé a contrôlé l'identité de l'utilisateur, et ce dernier lui a indiqué quelle politique de sécurité mettre en oeuvre. L'élément sécurisé affiche alors, sur ses moyens d'affichage 110 une image ou un texte correspondant à la politique de sécurité qui lui a été précédemment indiquée (étape E4). Selon une autre possibilité, l'élément sécurisé peut comprendre un haut-parleur, et émettre, lors de l'étape E4, un signal sonore correspondant à la politique de sécurité qui lui a été précédemment indiquée. L'utilisateur peut alors prendre connaissance de cette image, de ce texte, ou de ce signal sonore (échange d'informations T14), et confirmer, ou infirmer, lors de l'échange d'informations T15, qu'il s'agit bien de la politique de sécurité qu'il avait précédemment indiquée. Cette confirmation, ou cette infirmation, peuvent être transmises à l'élément sécurisé par l'intermédiaire de l'interface d'identification personnelle 201. Lorsque les moyens d'affichage 110 comprennent un écran tactile, elles peuvent aussi être transmises à l'élément sécurisé par l'intermédiaire de cet écran tactile. Elles peuvent aussi être indiquées à l'élément sécurisé de manière implicite ; par exemple, si l'utilisateur retire l'élément sécurisé de l'interface d'identification, cela correspond à une infirmation, tandis que s'il le laisse dans l'interface d'identification après l'étape E4, pendant une durée supérieure à une durée prédéterminée, cela correspond à une confirmation de la politique de sécurité affichée à l'étape E4. L'élément sécurisé 100 détermine lors de l'étape E5 si l'utilisateur a confirmé ou infirmé la politique de sécurité affichée à l'étape E4. Si le choix de cette politique de sécurité a ainsi été confirmé, l'élément sécurisé le met en oeuvre pour que l'application cliente 202 accède à la ressource 104 qu'il contient (étapes T3 et T4). Si au contraire le choix de cette politique de sécurité a été infirmé, alors l'élément sécurisé ne donne pas accès à la ressource qu'il contient, et le processus recommence depuis le début, comme cela est représenté sur la figure 9 (c'est-à-dire que l'élément sécurisé attend à nouveau que l'utilisateur lui transmette son code PIN ou, de manière plus générale, ses données porteur). La figure 10 représente schématiquement un septième protocole par lequel un utilisateur 203 indique à l'élément sécurisé 100 quelle politique de sécurité mettre en oeuvre pour donner accès à la ressource qu'il contient. Ce protocole, comme le précédent, comporte une étape de confirmation par l'utilisateur de son choix initial de politique de sécurité. Mais à la différence du protocole précédent, les informations échangées entre l'utilisateur et l'élément sécurisé transitent cette fois-ci par une interface homme-machine 205. Au cours de ce protocole, l'utilisateur 203 commence par saisir son code PIN sur une interface homme-machine 205 (échange d'informations T16). Ce code PIN est utilisé par ladite interface homme-machine et par l'élément sécurisé 100 pour créer des clefs de chiffrement temporaires destinées à chiffrer les informations échangées entre eux, à s'authentifier mutuellement, et à vérifier l'identité de l'utilisateur (étape E6). Cette étape est réalisée conformément au protocole PACE, dont l'intérêt a déjà été mentionné lors de la description de la figure 7. Un canal d'échanges sécurisés étant ainsi créé, l'utilisateur indique ensuite sur interface homme-machine la politique de sécurité que doit mettre en oeuvre l'élément sécurisé 100 (échange d'informations T17). L'interface homme-machine 205 transmet alors cette information, de manière protégée (ici par chiffrement) à l'élément sécurisé 100 (échange d'informations T18). Ce dernier transmet ensuite à l'interface homme-machine 205, toujours sous forme codée, une image, un texte, ou un message sonore désignant la politique de sécurité qui lui a été indiquée à l'étape T18 (échange d'informations T19). L'interface homme-machine communique alors cette image, ce texte, ou ce 20 message sonore à l'utilisateur (échange d'informations T20). De même que dans le protocole représenté sur la figure 8, une telle image ou un tel message sonore peuvent avoir été préenregistrés dans l'élément sécurisé 100 par son porteur attitré, lors d'une étape de personnalisation de cet élément, non détaillée ici. L'utilisateur confirme ou infirme ensuite, lors des échanges 25 d'informations T21 et T22, qu'il s'agit bien de la politique de sécurité qu'il avait initialement indiquée (à l'étape T17). La manière de confirmer ou d'infirmer ce choix de politique de sécurité est identique à ce qui a été décrit pour le protocole précédent, représenté sur la figure 9. Ce protocole se poursuit ensuite par les mêmes étapes E5, T3 et T4 que 30 le protocole représenté sur la figure 9. Les sept protocoles décrits ci-dessus permettent à l'utilisateur d'indiquer à l'élément sécurisé quelle est la politique de sécurité qu'il doit mettre en oeuvre pour donner accès à la ressource 104 qu'il contient. Deux exemples de telles politiques de sécurité sont maintenant décrits, en considérant le cas non limitatif dans lequel la ressource 104 est une application de signature, et peuvent être généralisés aux différents types de ressources informatiques 104 introduits ci-dessus. Une première telle politique de sécurité est représentée schématiquement sur la figure 11. Elle est bien adaptée à un environnement considéré comme fiable, tel que celui représenté sur la figure 2. Dans ce cas, les échanges entre l'application cliente 202 et l'élément sécurisé ne sont pas protégés. Ces échanges commencent par l'envoi, par l'application cliente, de données à signer (échange d'informations T3'). L'élément sécurisé 100 retourne ensuite à l'application cliente 202 soit une signature, soit lesdites données accompagnées d'une signature (échange d'informations T4'). Lors de ces échanges, l'élément sécurisé et l'application cliente peuvent notamment communiquer par l'intermédiaire de messages de type APDU (selon l'acronyme anglo-saxon « Application Protocol Data Unit ») conformes au standard ISO/IEC 7816-3 et ISO/IEC 7816-4, en particulier lorsque l'élément sécurisé communique avec l'interface d'identification 201 par l'intermédiaire de contacts électriques. La signature retournée à l'application cliente lors de l'étape T4' peut par exemple être produite par génération d'un condensat (par exemple par application d'une fonction de hachage) puis application au condensat d'un algorithme cryptographique utilisant une clé secrète (par exemple une clé privée) mémorisée dans le module de mémorisation 103. La génération du condensat peut être réalisée directement par l'élément sécurisé 100, ou être réalisée au préalable par l'application cliente 202. Dans ce dernier cas, l'application cliente ne transmet à l'élément sécurisé que les données extraites servant à produire la signature, et non la totalité desdites données à signer. Dans le cas où ladite extraction est réalisée directement par l'élément sécurisé 100, il peut être nécessaire de scinder lesdites données à signer en plusieurs blocs de données plus petits, pouvant ainsi être transmis sous forme de messages de type APDU. Un deuxième exemple de politique de sécurité pour donner accès à la ressource 104 contenue dans l'élément sécurisé 100 est représenté schématiquement sur la figure 12. Cette politique de sécurité est bien adaptée à un environnement considéré comme peu fiable, tel que celui représenté sur la figure 3. Dans ce cas, les échanges entre l'application cliente 202 et l'élément sécurisé sont protégés. Cette politique de sécurité est décrite ici dans le cas non limitatif d'une protection par chiffrement des données échangées. Ce cas peut être généralisé à d'autres types de protections des données échangées. Un tel chiffrement peut par exemple être réalisé conformément au protocole EACv2 (acronyme anglo-saxon de « Extended Access Control Version 2 », ou Contrôle d'Accès Etendu, version 2), tel que décrit dans le document « BSI TR-03110 : Advanced Security Mechanisms for Machine Readable Travel Documents. version 2.10, du 20 mars 2012 » produit par l'Office Fédéral Allemand de la sécurité informatique (« Bundesamt für Sicherheit in der Informationstechnik »). Dans ce cas, les échanges entre l'application cliente et l'élément sécurisé commencent par une étape E7 d'authentification de l'application cliente par l'élément sécurisé. Celui-ci s'authentifie aussi auprès de l'application cliente lors de l'étape E8. Lors de l'étape E8, des clefs de session permettant un chiffrement, une intégrité et une preuve d'authenticité très sûrs, et destinées à une utilisation limitée dans le temps sont également créées. L'application cliente envoie ensuite à l'élément sécurisé des données à signer, ces données ayant été chiffrées avec les clefs créées lors de l'étape E8 (échange d'informations T3"). Enfin, l'élément sécurisé 100 retourne à l'application cliente 202 soit une signature, soit lesdites données accompagnées d'une signature (échange d'informations T4"), toujours sous forme chiffrée. Comme pour la politique de sécurité, sans protection des échanges, représentée sur la figure 11, la signature retournée à l'application cliente lors de l'étape T4" peut par exemple être produite par génération d'un condensat (par exemple par application d'une fonction de hachage) puis application au condensat d'un algorithme cryptographique utilisant une clé secrète. Et, de même, les données à signer peuvent être scindées en blocs de données plus petits pour être ainsi transmises à l'élément sécurisés 100. Comme mentionné ci-dessus, les échanges entre l'application cliente et l'élément sécurisé peuvent être chiffrés conformément à la messagerie sécurisée décrite dans le protocole EAC. D'autres protocoles de chiffrement peuvent également être utilisés, comme le protocole PACE déjà mentionné, ou le protocole BAC (« Basic Access Control », tel que décrit dans le document 9303 produit par l'Organisation Internationale de l'Aviation Civile 'CAO). Ces protocoles peuvent être basés sur des schémas de chiffrement symétriques ou asymétriques. Dans le cas d'un schéma de chiffrement symétrique, le chiffrement est réalisé au moyen d'une clef partagée entre l'élément sécurisé et l'application cliente 202. Dans le cas d'un schéma de chiffrement asymétrique, après production de ladite signature, et avant de la transmettre à l'application cliente 202, l'élément sécurisé chiffre cette signature avec une clef publique propre à l'application cliente 202. L'intégrité et l'authenticité de cette clef publique peuvent être vérifiées par l'élément sécurisé grâce à un certificat électronique fourni par l'autorité de certification 303. Ce certificat comporte notamment une signature électronique de l'autorité de certification 303, qui peut être vérifiée par l'élément sécurisé 100 avant d'utiliser ladite clef publique. REVENDICATIONS1. Elément sécurisé (100) comportant un microcircuit (108) contenant au moins une ressource informatique (104), et une interface de communication (109), caractérisé en ce que : - il est conçu pour sélectionner, en fonction d'une information reçue par ladite interface de communication (109), une politique de sécurité pour accéder à la ressource informatique (104), parmi au moins deux politiques de sécurité différentes, et en ce que - il est conçu pour mettre à disposition ladite ressource informatique (104), par l'intermédiaire de ladite interface de communication (109), conformément à ladite politique de sécurité sélectionnée. 2. Elément sécurisé (100) selon la revendication 1, conçu pour vérifier que des données porteur reçues par l'intermédiaire de ladite interface de communication (109) coïncident avec des données de référence mémorisées dans ledit élément sécurisé, et pour donner accès à la ressource (104) seulement si lesdites données porteur coïncident avec lesdites données de référence. 3. Elément sécurisé (100) selon l'une des revendications 1 ou 2, constituant une carte à microcircuit. 4. Elément sécurisé (100) selon l'une des revendications 1 ou 2, constituant un document d'identification d'un porteur. 5. Elément sécurisé (100) selon l'une des revendications 1 à 4, dans lequel ladite ressource informatique (104) comprend une clef cryptographique. 6. Elément sécurisé (100) selon l'une des revendications 1 à 4, dans lequel ladite ressource informatique (104) comprend un fichier ou un objet informatique décrivant la localisation physique d'une clef cryptographique dans le microcircuit (108). 7. Elément sécurisé (100) selon l'une des revendications 1 à 6, dans lequel ladite ressource (104) comprend une application de signature électronique. 8. Elément sécurisé (100) selon l'une des revendications 1 à 7, conçu pour donner accès à ladite ressource (104) en délivrant, par l'intermédiaire de l'interface de communication (109), des informations dont le niveau de protection est fonction de la politique de sécurité sélectionnée. 9. Elément sécurisé (100) selon l'une des revendications 1 à 8, dans lequel ladite interface de communication (109) comprend un clavier (107) comportant des touches et dans lequel ladite information dépend de la touche activée par l'utilisateur. 10. Elément sécurisé (100) selon l'une des revendications 1 à 9, dans lequel ladite interface de communication (109) comprend une interface de communication avec un lecteur externe (101) et des moyens d'affichage (110). 11. Elément sécurisé (100) selon la revendication 10, conçu pour afficher sur lesdits moyens d'affichage (110) une information associée à ladite politique de sécurité sélectionnée. 12. Elément sécurisé (100) selon la revendication 11, conçu pour que ladite information affichée comprenne une information désignant ladite politique de sécurité sélectionnée. 13. Procédé mis en oeuvre dans un élément sécurisé (100) comportant un microcircuit (108) contenant au moins une ressource informatique (104), et une interface de communication (109), caractérisé par les étapes suivantes : - une étape de sélection, en fonction d'une information reçue par ladite interface de communication (109), d'une politique de sécurité pour accéder à la 20 ressource informatique (104) parmi au moins deux politiques de sécurité différentes, et - une étape de mise à disposition de ladite ressource informatique (104), par l'intermédiaire de ladite interface de communication (109), conformément à ladite politique de sécurité sélectionnée à l'étape précédente. 25 14. Procédé mis en oeuvre dans un élément sécurisé (100) selon la revendication 13, comprenant : - une étape de vérification de données porteur reçues par l'intermédiaire de ladite interface de communication (109), au cours de laquelle ledit microcircuit (108) vérifie que les données porteur coïncident avec des données de référence 30 mémorisées dans ledit microcircuit (108), et - une séquence d'étapes au cours desquelles l'élément sécurisé (100) donne accès à la ressource (104) seulement si lesdites données porteur coïncident avec lesdites données de référence. 15. Procédé mis en oeuvre dans un élément sécurisé (100) selon l'unedes revendications 13 ou 14, dans lequel ladite ressource informatique (104) comprend une clef cryptographique. 16. Procédé mis en oeuvre dans un élément sécurisé (100) selon l'une des revendications 13 ou 14, dans lequel ladite ressource informatique (104) comprend un fichier ou un objet informatique décrivant la localisation physique d'une clef cryptographique dans le microcircuit (108). 17. Procédé mis en oeuvre dans un élément sécurisé (100) selon l'une des revendications 13 à 16, dans lequel la ressource informatique (104) comprend une application de signature électronique. 18. Procédé mis en oeuvre dans un élément sécurisé (100) selon la revendication 17, dans lequel ladite application de signature électronique, suite à la réception par l'intermédiaire de ladite interface de communication (109) de données comprenant des données à signer : - vérifie que le niveau de protection desdites données reçues est conforme à la politique de sécurité sélectionnée, et - effectue une opération de signature électronique en utilisant une clef cryptographique privée contenue dans le microcircuit (108). 19. Procédé mis en oeuvre dans un élément sécurisé (100) selon l'une des revendications 13 à 18, dans lequel le niveau de protection des informations délivrées par l'interface de communication (109) est fonction de ladite politique de sécurité sélectionnée. 20. Procédé mis en oeuvre dans un élément sécurisé (100) selon l'une des revendications 15 à 18, prise dans la dépendance de la revendication 14, dans lequel le microcircuit (108) utilise des données complémentaires véhiculées par lesdites données porteur pour sélectionner une politique de sécurité à mettre en oeuvre pour donner accès à la ressource informatique (104). 21. Procédé mis en oeuvre dans un élément sécurisé (100) selon la revendication 20 tel que lesdites données porteur reçues par l'interface de communication (109) sont calculées au préalable à partir de données porteur initiales et d'une indication relative à la politique de sécurité, par une transformation déterministe. 22. Procédé mis en oeuvre dans un élément sécurisé (100) selon l'une des revendications 13 à 21, au cours duquel l'interface de communication (109) communique avec un module externe de communication, par l'intermédiaired'ondes électromagnétiques, comportant une étape de création d'un canal d'échanges sécurisés entre l'élément sécurisé (100) et le module externe de communication, et dans lequel lesdites données porteur reçues par l'interface (109), sont échangées en utilisant ce canal sécurisé. 23. Procédé mis en oeuvre dans un élément sécurisé (100) selon l'une des revendications 13 à 22, dans lequel l'interface de communication (109) comprend des moyens d'affichage (110), et au cours duquel : - les moyens d'affichage (110) communiquent à un utilisateur une information désignant ladite politique de sécurité, précédemment sélectionnée en fonction de ladite information reçue par ladite interface de communication (109), - l'interface de communication (109) reçoit une information qui confirme ou infirme que ladite politique de sécurité désignée par l'information affichée sur les moyens d'affichage (110) est bien celle à mettre à oeuvre, et - le microcircuit (108) donne accès à la ressource informatique (104), conformément à ladite politique de sécurité sélectionnée, si l'information reçue à l'étape précédente confirme que ladite politique de sécurité désignée par l'information affichée sur les moyens d'affichage (110) est bien celle à mettre à oeuvre. 24. Procédé mis en oeuvre dans un élément sécurisé (100) selon l'une des revendications 13 à 22, dans lequel une interface homme-machine (205) communique à un utilisateur une information associée à ladite politique de sécurité sélectionnée en fonction de ladite information reçue par ladite interface de communication (109). 25. Procédé mis en oeuvre dans un élément sécurisé (100) selon la revendication 24, dans lequel ladite information communiquée comprend une information désignant ladite politique de sécurité précédemment sélectionnée, et au cours duquel : - ledit utilisateur confirme ou infirme que la politique de sécurité désignée par l'information communiquée par l'interface homme-machine est bien celle à mettre à oeuvre, - le microcircuit (108) donne accès à la ressource informatique (104), conformément à la politique de sécurité communiquée par l'interface homme-machine (205), si le choix de cette politique de sécurité a été confirmé lors de l'étape précédente,et tel que les informations échangées entre l'interface homme-machine (205) et l'élément sécurisé (100) sont protégées.