FR2945367A1 - Procede de controle d'activation d'une application sur une plateforme securisee, par un acteur exterieur a la chaine de chargement. - Google Patents

Abstract

Procédé de fourniture, de contrôle d'authenticité et d'intégrité lors de l'installation d'au moins une application logicielle (A) sur au moins un objet portable (PO) : - mettant en oeuvre d'un paquet d'installation (P) comprenant : - l'application logicielle, « l'applet », (A) délivrée par un fournisseur d'application (AP), - une clé publique (K AP) du fournisseur d'application (AP) qui est insérée dans l'applet (A) par le fournisseur d'application (AP), - un certificat d'application (Sa) correspondant à une signature chiffrée de l'ensemble, applet (A)-clé publique (K AP) du fournisseur d'application, le certificat étant généré par une autorité de certification tierce (CA) avec une clef privée (K CA) de l'autorité de certification (CA), et comprenant les étapes suivantes chargement à partir du serveur de services (SP) du paquet d'installation (Pa) dans l'objet portable (PO), vérification du certificat d'authenticité (Sa) et activation de l'applet (A) installée, intègre et authentique, par un élément de sécurité extérieur (SAM) appartenant au fournisseur d'application (AP) ou à une autorité de gestion des droits (IPA).

Description

PROCEDE DE CONTROLE D'ACTIVATION D'UNE APPLICATION SUR UNE PLATEFORME SECURISEE, PAR UN ACTEUR EXTERIEUR A LA CHAINE DE CHARGEMENT La présente invention concerne le domaine technique des dispositifs portables intelligents autonomes tels que les dispositifs intelligents de contrôle d'accès ou encore des téléphones portables mettant en oeuvre des applications permettant de gérer des droits d'accès à des lieux ou des services. Dans le domaine ci-dessus, il est par exemple connu une technologie de gestion d'accès à des services de transport ou autres baptisée Calypso mettant en oeuvre des cartes d'accès intelligentes à communication sans contact. Chaque carte intelligente de technologie Calypso offre par la mise en oeuvre d'applications logicielles ou applets stockées dans la mémoire de la carte, des fonctionnalités de gestion d'accès aux réseaux de transport d'un ou plusieurs opérateurs à travers des opérations d'achat de droits et de débit / contrôle des dits droits lors de l'accès aux services. De telles fonctionnalités de contrôle d'accès peuvent également être mises en oeuvre dans le cadre d'autres dispositifs portables intelligents tels que des téléphones intégrant des technologies variées de communication sans contact. Ces téléphones mettent alors en oeuvre des applets de contrôle d'accès analogues à celles mises en oeuvre par les cartes intelligentes. De tels dispositifs portables autonomes donnent pleinement satisfaction dans le cadre de leur utilisation pour leur contrôle d'accès à un réseau ou un service géré par l'opérateur qui aura procédé à l'émission de la carte ou du téléphone. Toutefois, compte tenu de la grande versatilité de la carte et de sa faculté à mettre en oeuvre plusieurs applications, il serait intéressant de permettre au porteur de la carte d'avoir accès, au moyen de la carte intelligente déjà en sa possession, à d'autres services ou réseaux de transport que ceux initialement prévu au moment de la délivrance de la carte à son utilisateur. Une telle évolutivité des services disponibles serait également souhaitable pour d'autre type de dispositif portables intelligents tels que des téléphones portables. Il est donc apparu le besoin de moyens permettant à un grand nombre d'utilisateurs une mise à jour de leur dispositif portable autonome à distance sans avoir à se rendre dans un bureau de l'opérateur de transport tout en offrant une forte garantie de sécurité pour l'opérateur souhaitant mettre à disposition de nouvelles applications logicielles ou applets permettant un accès à ses services ou infrastructures.

Afin d'atteindre cet objectif, l'invention concerne un procédé de fourniture, de contrôle d'authenticité et d'intégrité lors de l'installation d'au moins une application logicielle sur au moins un objet portable comprenant les étapes suivantes : mise en oeuvre d'un paquet d'installation comprenant : û l'application logicielle, appelée applet , délivrée par un fournisseur d'application, û une clé publique du fournisseur d'application qui est insérée dans l'applet par le fournisseur d'application, û un certificat d'application correspondant à une signature chiffrée de l'ensemble, applet - clé publique du fournisseur d'application, le certificat étant généré par une autorité de certification tierce avec une clef privée de l'autorité de certification enregistrement du paquet d'installation sur un serveur d'un fournisseur de services, chargement à partir du serveur du fournisseur de services du paquet d'installation dans l'objet portable, vérification du certificat d'authenticité par le fournisseur de service et/ou par l'objet portable à l'aide d'une clef publique associée à la clé privée de l'autorité de certification pour, en cas de vérification positive, conclure à l'intégrité et à l'authenticité de l'applet puis installer l'applet dans l'objet portable, activation de l'applet installée, intègre et authentique, par un élément de sécurité extérieur appartenant au fournisseur d'application ou à une autorité de gestion des droits, comprenant des opérations suivantes : û demande d'un paquet d'activation, à l'élément de sécurité, par l'applet installée, û fourniture par l'élément de sécurité d'un paquet d'activation comprenant : û des données d'activation, ù un certificat d'activation correspondant à une signature chiffrée, des données d'activation au moins, générée par le fournisseur d'application au moyen d'une clé privée du fournisseur d'application associée à la clé publique du fournisseur d'application, vérification de l'authenticité du certificat d'activation par l'applet installée, à l'aide de la clef publique du fournisseur d'application qu'elle intègre, pour en cas de vérification positive, passer l'applet en mode activé et/ou mettre en oeuvre les données d'activation. Au sens de l'invention les termes objet portable désignent tout système personnel portatif comprenant les ressources matérielles et logicielles nécessaire pour exécuter des processus informatiques, enregistrer et lire des données informatiques, protéger des données dans un ou plusieurs éléments de sécurité, communiquer avec des unités informatiques externes via au moins un réseau public et/ou privé de communication filaire et/ou hertzienne. Parmi les objets portables il est possible de lister, de manière non exhaustive, les dispositifs suivants : ù les cartes à puce en communication avec et/ou sans contact (en anglais contact and/or contactless microprocessor smartcard), ù les téléphones portables intelligents (en anglais smartphone), et éléments de sécurité associés ù les assistants numériques personnels (PDA pour en anglais Personal Digital Assistant), et éléments de sécurité associés ù les ordinateurs portables, et unités mémoire associées comme des clefs USB, ù les ordinateurs personnels et unités mémoire associées. Par ailleurs, dans le cadre de l'invention le terme applet ne saurait être entendu comme limitant l'invention au seul domaine de l'environnement Javacard / GP mais au contraire comme visant une application logicielle susceptible d'être mise en oeuvre dans tout type d'environnement matériel et logiciel d'exécution d'application adapté. L'insertion de la clef publique du fournisseur d'application dans l'applet du paquet d'installation permet à la clef publique du fournisseur d'application de faire un tout avec l'applet. Par ailleurs, le certificat d'application, à savoir la signature chiffrée de l'ensemble par la clef secrète de l'autorité de certification, permet de prévenir l'installation d'un paquet d'installation qui aurait été altéré au cours des différents transferts. En effet, dans l'éventualité où le paquet d'installation serait corrompu, le certificat d'application serait alors invalide de sorte que l'installation de l'applet serait rendue impossible lors de l'étape de contrôle ou de vérification d'intégrité. De plus, la sécurité ou le contrôle, résultant de la mise en oeuvre de la clé publique du fournisseur d'application après chargement de l'application sur l'objet portable, permet à l'invention de s'affranchir de la nécessité de recourir à une chaîne de livraison parfaitement définie et maîtrisée par le fournisseur d'application. Ainsi, il n'est pas nécessaire de limiter ou de connaître les différents intermédiaires entre le fournisseur d'application et l'objet portable. L'invention permet donc au fournisseur d'application de garder un contrôle complet et de bout en bout sur son application jusqu'à son activation dans un objet portable non connu à priori. Par ailleurs, l'intégration de la clef publique du fournisseur d'application dans l'applet vise à garantir l'intégrité de cette dernière sans toutefois imposer une confidentialité de l'ensemble de l'applet. L'invention permet donc d'éviter un chiffrement de l'ensemble de l'application logicielle ou applet qui induirait de longues séquences de déchiffrement lors de son instanciation ou de sa mise en oeuvre. De plus, l'intégration de la clé publique du fournisseur d'application au sein de l'applet évite d'avoir à gérer un lourd processus de communication de la clé publique du fournisseur d'application à l'objet portable indépendamment du paquet d'installation, ce qui est particulièrement avantageux quand l'objet portable ne peut être connu a priori du fournisseur d'application. Selon l'invention les données d'activation peuvent être de diverses natures et par exemple comprendre des droits et/ou des paramètres de fonctionnement de l'applet. Selon une variante de mise en oeuvre de l'invention, l'applet peut, lors de la requête du paquet d'activation, fournir à l'élément de sécurité un aléa antirejeu, qui est ensuite intégré par l'élément de sécurité dans le paquet d'activation avant sa fourniture à l'applet, le certificat d'activation correspondant à la signature chiffrée de l'ensemble comprenant au moins les données d'activation et l'aléa anti-rejeu. La mise en oeuvre d'un tel aléa anti-rejeu sécurise encore plus le processus d'activation de l'applet. Selon une variante de mise en oeuvre de l'invention, sous la condition de mise en oeuvre de l'anti-rejeu, il peut également être envisagé d'assurer l'identification précise de chaque applet instanciée et activée. A cet effet, le paquet d'activation peut comprendre un identifiant d'instance unique pour tout applet activée, l'identifiant d'instance étant généré ou fourni par l'élément de sécurité selon des paramètres du fournisseur d'application et le certificat d'activation correspondant à la signature de l'ensemble comprenant au moins les données d'activation et l'identifiant d'instance. Cette fourniture d'identifiant pourra être indépendante de l'objet portable et du fournisseur de service et réalisée selon des critères du seul fournisseur d'application propriétaire de l'élément de sécurité. De plus, l'identifiant d'instance pourra être différent de l'identifiant d'application qui résulte des phases de chargement, installation, personnalisation et qui est géré par le gestionnaire d'application de chaque objet portable appartenant à un système d'information. Ainsi le fournisseur d'application peut disposer d'une identification pour toutes les instances de son application en circulation. Selon l'invention, il peut également être envisagé un contrôle de l'authenticité de l'applet préalablement à tout chargement sur un objet portable. Ce contrôle consistera, par exemple, en une étape de vérification du certificat d'application réalisée par le fournisseur de service et/ou toute autorité déléguée ou indépendante, pour en cas de vérification négative interdire tout chargement de l'applet non authentique et/ou non intègre sur un objet portable.

Selon l'invention, l'élément de sécurité peut être hébergé sur le serveur de service ou tout autre serveur distinct du serveur de service. Cette dernière option permet alors de différencier les fonctions et de répartir les responsabilités de manière à permettre au fournisseur d'application de contrôler au mieux l'usage qui sera fait de son application ou applet. Ainsi, l'élément de sécurité peut être hébergé sur un serveur distant d'une autorité de gestion des droits d'utilisation de l'applet. Selon l'invention les échanges de données entre l'objet portable et le serveur de serveur de service et d'éventuels autres serveurs peuvent être réalisés de toute manière appropriée via par exemple un réseau de communication public, dans le cadre d'un réseau de communication privé réel ou virtuel. Ces échanges de données peuvent également intervenir dans le cadre d'une communication directe entre, d'une part, l'objet portable, et d'autre part, le serveur de service et/ou le(s) autre(s) serveur(s) impliqué(s) selon l'invention dans le processus de chargement et d'activation. Ainsi, selon l'invention les échanges de données à partir ou à destination de l'objet portable peuvent être effectués en partie au moins dans le cadre d'une communication via un réseau public de communication auquel le serveur de services et l'objet portable, au moins, sont connectés. Cette communication via le réseau public peut être non sécurisée. Toutefois, selon l'invention les échanges de données à partir ou à destination de l'objet portable peuvent être effectués dans le cadre d'une communication sécurisée via le réseau public de communication avec authentification mutuelle du serveur de services et de l'objet portable. Dans le même esprit tous les échanges d'information via le réseau public à partir ou à destination de l'objet portable peuvent être effectués dans le cadre de communications sécurisées avec authentification mutuelle de l'objet portable et d'un serveur impliqué dans le processus de chargement et d'activation.

Comme cela a été indiqué plus haut, selon l'invention les échanges de données à partir ou à destination de l'objet portable peuvent aussi être effectués, en partie au moins, dans le cadre d'une communication directe filaire ou hertzienne entre le serveur de services et l'objet portable. Selon l'invention, le chargement du paquet d'installation sur l'objet portable peut également intervenir en dehors de tout réseau public de communication, en étant par exemple réalisé par le fabricant de l'objet portable ou un distributeur avant la fourniture de l'objet portable à un utilisateur final. Le paquet d'installation chargé pourra alors n'avoir fait l'objet d'aucune activation, l'étape d'activation étant initiée directement ou indirectement par l'utilisateur final lorsque que, par exemple, ce dernier souhaitera mettre en oeuvre les fonctionnalités offertes par l'applet.

Selon une caractéristique de l'invention, les étapes intervenant sur l'objet portable se déroulent dans un environnement et/ou des emplacements mémoire sécurisés de l'objet portable dénommé éléments sécurisés . Selon une autre caractéristique de l'invention, l'objet portable est une plateforme multi-applications. Selon encore une autre caractéristique de l'invention, les étapes intervenant sur l'objet portable sont réalisées sur un paquet déjà chargé et installé lors d'une nouvelle instanciation de ce paquet ou de l'applet correspondant. Il en va de même pour toute application pré chargée avant distribution de l'objet portable et qui serait installé et activée, ultérieurement, à la demande. Bien entendu les différentes variantes, caractéristiques et formes du procédé selon l'invention peuvent être mises en oeuvre en association les unes avec les autres, selon diverses combinaisons dans la mesure où elles ne sont pas incompatibles ou exclusives les unes des autres. Par ailleurs, diverses autres caractéristiques et avantages de l'invention ressortent de la description ci-après effectué en référence à l'unique figure qui illustre de manière schématique les différentes étapes d'une forme non limitative de mise en oeuvre du procédé, selon l'invention, de fourniture et de contrôle d'authenticité et d'intégrité d'une application logicielle ou applet. Ainsi, l'invention vise à fournir un procédé de fourniture d'une application logicielle A, désignée dans le cadre de la présente demande sous la terminologie applet, à un objet portable intelligent PO via un réseau de communications publique PN, tel qu'Internet ou encore un réseau de communication hertzien comme un réseau aux normes GSM, UMTS, CDMA ou encore EV-DO. L'objet portable PO est susceptible d'être, comme cela a été indiqué précédemment, n'importe quel type de système personnel portable intelligent comprenant les ressources matérielles et logicielles nécessaires pour exécuter des processus informatiques, enregistrer et lire des données informatiques, protéger des données dans un (ou plusieurs) éléments de sécurité, communiquer avec des unités informatiques externes via au moins un réseau public et/ou privé de communications filaire et/ou hertzien.

Dans une forme de réalisation préférée mais non strictement nécessaire, l'objet du portable pourra être une carte d'accès intelligente ou encore un téléphone portable ou un assistant personnel digital comprenant des fonctionnalités de communications sans contact avec des systèmes de contrôle d'accès, par exemple. L'applet A est développé par un fournisseur d'application AP pour permettre la mise en oeuvre d'au moins une nouvelle fonctionnalité par l'objet portable PO. Cette fonctionnalité peut, par exemple, être un accès temporaire ou permanent à un service de transport, à un service télématique ou encore à des programmes applicatifs variés fonctionnant sur l'objet portable OP. Afin de permettre au fournisseur d'application AP d'exercer un contrôle de l'applet A, celui ùci intègre dans l'applet A sa clé publique KPAP. Cette clé publique KPAP est destinée à être utiliser dans le cadre d'un protocole de génération/ vérification de certificats mettant en oeuvre une clé privée KSAP détenue exclusivement par le fournisseur d'application AP ou de toute autre autorité le représentant ; et la clé publique KPAP du fournisseur d'application AP. Ce protocole de contrôle sera utilisé à la fin du processus d'installation de l'applet A comme cela apparaîtra par la suite. L'intégration de la clé publique KPAP sera de préférence réalisée de manière que la clé publique KPAP ne puisse pas être facilement extraite de l'ensemble applet A + clé publique KPAP Afin de garantir l'authenticité et l'intégrité de l'applet A à un tiers, tel qu'un fournisseur de services, intermédiaire entre le fournisseur d'application et l'utilisateur de l'objet portable ou l'objet portable PO en lui même, il sera générer un certificat d'application Sa à savoir une signature chiffrée de l'ensemble applet A + clé publique KPAP selon un protocole de signature mettant en oeuvre une fonction de hachage, une clé privée KSCA émise par une autorité de certification tierce CA et une clé publique KPCA de l'autorité de certification. Le certificat d'application Sa est généré après succès de la certification par l'autorité de certification au moyen de sa clef KSCA.

Le fournisseur d'application AP génère alors un paquet d'installation P comprenant : ù l'applet A intégrant la clé publique KPAP du fournisseur d'application. ù le certificat d'application Sa Le paquet d'installation P est transmis à un fournisseur de services SP qui l'enregistre sur son ou ses serveurs de manière à le rendre accessible via le réseau de communications publiques PN. Les infrastructures du fournisseur de services SP sont alors dimensionnées de manière à permettre le téléchargement simultané par un grand nombre d'utilisateurs du paquet d'installation P à partir des serveurs du fournisseur de services SP. Lorsque l'objet portable PO aura besoin d'utiliser la nouvelle application conçue par le fournisseur d'application AP, l'objet portable PO procédera au téléchargement du paquet d'installation P via le réseau public de communication PN à partir des serveurs du fournisseur de services SP. Le paquet d'installation P sera ainsi chargé dans l'objet portable PO. Les échanges d'informations entre l'objet portable et le fournisseur de services SP interviendront de préférence mais non nécessairement dans le cadre d'une communication sécurisée avec authentification mutuelle du serveur de services et de l'objet portable OP.

Dans le cadre d'un processus de chargement de l'applet A conforme à l'invention il sera procédé à un contrôle de l'intégrité de l'ensemble applet A + clé publique KPAP par la vérification du certificat d'application Sa. Ce contrôle d'intégrité peut être réalisé soit par le serveur de service SP préalablement au chargement du paquet d'installation sur l'objet portable PO ou en fin de la chaîne de transfert entre les différents acteurs. Ce contrôle d'intégrité peut aussi être effectué à tout moment de la chaîne de transfert par un acteur détenant la clef publique KpCA et la fonction de hashage associée, ou encore par tout autre objet portable pré-désigné. Le contrôle d'intégrité fait intervenir le calcul d'une signature de l'ensemble applet A + clé publique KPAP présent dans le paquet d'installation au moyen de la même fonction de hachage que celle utilisée par le protocole de signature et définie dans l'enveloppe du certificat d'application Sa. Au terme du calcul, il est obtenu une signature S de l'ensemble, applet A + clé publique KPAP, présent dans le paquet d'installation P. La procédure de contrôle d'intégrité fait également intervenir un déchiffrement du certificat d'application Sa présent dans le paquet d'installation au moyen de la clé publique de l'autorité de certification KpCA. Il est ensuite procédé à une comparaison entre le certificat d'application Sa et la signature S calculée.

En cas de comparaison positive, il est conclu à l'intégrité de applets A + clé publique KPAP. Dans le cas contraire, il est conclu à une corruption de l'applet A et le traitement du paquet d'installation P pourra être arrêté et annulé. S'il a été conclu à l'intégrité applet A + clé publique KPAP il est alors procédé à l'installation de l'applet A dans l'objet portable PO. Ensuite il est procédé à une activation de l'applet A par l'obtention d'un paquet d'activation Pa auprès d'un élément de sécurité SAM extérieur qui est la propriété exclusive du fournisseur d'application AP ou d'une autorité de contrôle. Ainsi toute activation de l'applet A fait intervenir une requête de l'applet A installée auprès de l'élément de sécurité SAM qui est par exemple hébergé sur un serveur distant d'une autorité de gestion des droits IPA accessible par le réseau public. Le serveur IPA est de préférence distinct du ou des serveurs du fournisseur services. Afin d'éviter tout rejeu, l'applet A peut aussi transmettre dans ou avec sa requête un nombre aléatoire ou aléa anti-rejeu al.

En réponse à cette requête, l'élément extérieur de sécurité SAM fournit un paquet d'installation Pa comprenant des données d'activation Da telles que par exemple : des droits d'activation, des paramètres d'activation. Le paquet d'activation intègre le protocole d'anti-rejeu et fournit des données d'activation. Les données d'activation Da ne nécessitent pas de chiffrement mais sont accompagnées d'un certificat d'activation C;p faisant également parti du paquet d'activation Pa. Le certificat d'activation C;p correspond alors à une signature chiffrée de l'ensemble des données d'activation Da et de l'aléa al obtenu selon un protocole de signature mettant en oeuvre une fonction de hachage, et la clé privée KSAP, du fournisseur d'application, associée à la clé publique KPAP. La clé privée KSAP est détenue uniquement par l'élément de sécurité SAM. L'applet A procède alors au contrôle, du certificat d'activation C;p au moyen de la clé publique KPAP qu'elle possède, et n'accepte les données d'activation seulement si le certificat est valide et que son calcul a intégré l'anti re-jeu émis précédemment.

Ensuite si le contrôle du certificat C;p est positif l'applet A passe en mode activé conformément aux éventuels paramètres d'activation contenus dans les données d'activation Da.

Dans le cadre de cette activation, l'applet activée peut recevoir un identifiant d'instance unique attribué par le fournisseur d'application via des paramètres de l'élément de sécurité SAM. L'identifiant fera alors parti du paquet d'activation Pa et de l'ensemble signé par le certificat d'activation C.

L'application instanciée possède par ailleurs un identifiant d'application, propre au système dans lequel elle a été installée et instanciée. Afin de procéder à ces opérations cryptographiques de calcul de signature, de chiffrement, de déchiffrement, d'authentification, l'objet portable comprend de préférence des éléments de sécurité et/ou un environnement de sécurité SE. Dans une forme plus particulièrement préférée de mise en oeuvre, les différentes opérations de contrôle, de déchiffrement/chiffrement et d'installation sont effectuées dans ces éléments sécurisés SE. Bien entendu, diverses modifications peuvent être apportées à l'invention dans le cadre des revendications annexées.

Claims (14)

1. REVENDICATIONS1. Procédé de fourniture, de contrôle d'authenticité et d'intégrité lors de l'installation d'au moins une application logicielle (A) sur au moins un objet portable (PO) comprenant les étapes suivantes : mise en oeuvre d'un paquet d'installation (P) comprenant : l'application logicielle, appelée applet , (A) délivrée par un fournisseur d'application (AP), une clé publique (KpAP) du fournisseur d'application (AP) qui est insérée dans l'applet (A) par le fournisseur d'application (AP), un certificat d'application (Sa) correspondant à une signature chiffrée de l'ensemble, applet (A)-clé publique (KpAP) du fournisseur d'application, le certificat étant généré par une autorité de certification tierce (CA) avec une clef privée (KSCA) de l'autorité de certification (CA), enregistrement du paquet d'installation (Pa) sur un serveur d'un fournisseur de services (SP), chargement à partir du serveur de services (SP) du paquet d'installation (Pa) dans l'objet portable (PO), vérification du certificat d'authenticité (Sa) par le fournisseur de service (SP) et/ou par l'objet portable (PO) à l'aide d'une clef publique (KpCA) associée à la clé privée (KSCA) de l'autorité de certification (CA) pour, en cas de vérification positive, conclure à l'intégrité et à l'authenticité de l'applet (A) puis installer l'applet (A) dans l'objet portable (PO), activation de l'applet (A) installée, intègre et authentique, par un élément de sécurité extérieur (SAM) appartenant au fournisseur d'application (AP) ou à une autorité de gestion des droits (IPA), comprenant des opérations suivantes : û demande d'un paquet d'activation, à l'élément de sécurité (SAM), par l'applet (A) installée, û fourniture par l'élément de sécurité (SAM) d'un paquet d'activation (Pa) comprenant : û des données d'activation (Da),û un certificat d'activation (C;p) correspondant à une signature chiffrée, des données d'activation (Da) au moins, générée par le fournisseur d'application au moyen d'une clé privée (KSAP) du fournisseur d'application associée à la clé publique (KpAP) du fournisseur d'application, vérification de l'authenticité du certificat d'activation (C;p) par l'applet (A) installée, à l'aide de la clef publique (KpAP) du fournisseur d'application qu'elle intègre, pour en cas de vérification positive, passer l'applet (A) en mode activé et/ou mettre en oeuvre les données d'activation (Da).
2. 2. Procédé selon la revendication 1, caractérisé en ce que les données d'activation (Da) comprennent des droits et/ou des paramètres de fonctionnement de l'applet (A).
3. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que, lors de la requête du paquet d'activation, l'applet (A) fournit à l'élément de sécurité (SAM) un aléa anti-rejeu (al) qui est ensuite intégré par l'élément de sécurité (SAM) dans le paquet d'activation (Pa) avant sa fourniture à l'applet (A), le certificat d'activation (C;p) correspondant à la signature chiffrée de l'ensemble comprenant au moins les données d'activation (Da) et l'aléa anti-rejeu (al).
4. 4. Procédé selon la revendication 3, caractérisé en ce que le paquet d'activation (Pa) comprend un identifiant d'instance unique (ID) pour tout applet (A) activée, l'identifiant d'instance étant généré ou fourni par l'élément de sécurité (SAM) selon des paramètres du fournisseur d'application et le certificat d'activation (C;p) correspondant à la signature de l'ensemble comprenant au moins les données d'activation (Da) et l'identifiant d'instance.
5. 5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce qu'il comprend, préalablement à tout chargement de l'applet (A) sur un objet portable, une étape de vérification du certificat d'application (Sa), réalisée par le fournisseur de service (SP) et/ou toute autorité déléguée ou indépendante, pour en cas de vérification négative interdire tout chargement de l'applet (A) non authentique et/ou non intègre sur un objet portable (PO).
6. 6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que l'élément de sécurité (SAM) est hébergé au sein d'un serveur de service (SP).
7. 7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que l'élément de sécurité (SAM) est hébergé sur un serveur distant d'une autorité de gestion (IPA) des droits d'utilisation de l'applet (A).
8. 8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce que les échanges de données à partir ou à destination de l'objet portable (PO) sont effectués en partie au moins dans le cadre d'une communication via un réseau public de communication (PN) auquel le serveur de services (SP) et l'objet portable (PO), au moins, sont connectés.
9. 9. Procédé selon la revendication 8, caractérisé en ce que les échanges de données via le réseau public (PN) à partir ou à destination de l'objet portable sont effectués dans le cadre de communication sécurisée avec authentification mutuelle de l'objet portable (PO) et d'un serveur (SP).
10. 10. Procédé selon la revendication 8 ou 9, caractérisé en ce que les échanges d'information via le réseau public (PN) à partir ou à destination de l'objet portable (PO) sont effectués dans le cadre de communication sécurisée avec authentification mutuelle de l'objet portable (PO) et le serveur de services (SP).
11. 11. Procédé selon l'une des revendications 1 à 7, caractérisé en ce que les échanges de données à partir ou à destination de l'objet portable (PO) sont effectués en partie au moins dans le cadre d'une communication directe filaire ou hertzienne entre le serveur de services (SP) et l'objet portable (PO).
12. 12. Procédé selon l'une des revendications précédentes, caractérisé en ce que les étapes intervenant sur l'objet portable (PO) se déroulent dans un environnement et/ou des emplacements mémoire sécurisés (SE) de l'objet portable (PO).
13. 13. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'objet portable (PO) est une plateforme multi-applications.
14. 14. Procédé selon l'une des revendications précédentes, caractérisé en ce que les étapes intervenant sur l'objet portable (PO) sont réalisées sur un paquet d'installation (Pa) déjà chargé et installé lors d'une nouvelle instanciation de ce paquet ou de l'applet (A) correspondant.