Brevet FR2960330A1 — publié le 20111125

Procédé d'émission d'informations à destination d'une Application hébergée sur un support multi-Application, et support associé La présente invention concerne un procédé d'émission d'informations à destination d'une Application sécurisée, c'est-à-dire protégée par des secrets qui en limitent l'accès aux seuls terminaux accrédités, par un terminal émetteur non-accrédité auprès de cette Application sécurisée. Dans tout le document, les termes « Application » et « Produit » sont entendus au sens défini par la norme ISO 24014-1 (« Application » et « Product ») avec toutes les déclinaisons (« Application Owner » pour Propriétaire d'Application, « Product Retailer » pour Distributeur de Produit, etc.). De même, le terme « Opérateur » est entendu au sens de « Service Operator » de l'ISO 24014-1. Les supports multi-Application sont des supports, généralement des cartes à puce, hébergeant des Applications différentes, comme des Applications de monétique (porte-monnaie électronique, EMV), des Applications de transports ou des Applications de télé- phonie. Ces Applications sont généralement sécurisées et n'autorisent l'accès à leurs données qu'à des terminaux accrédités. Les supports multi-Application sont propres à être connectés à des terminaux. Une fois un support multi-Application connecté à un terminal, le terminal active et fait fonctionner l'une ou plusieurs des Applications du support, selon la fonction du terminal. Toute- fois, pour pouvoir faire fonctionner une Application, le terminal doit être accrédité auprès de l'Application. Or, généralement, des Applications d'un même support ont des Propriétaires (« Application Owner ») différents qui ne se font pas forcément confiance et ne partagent leurs secrets, c'est-à-dire leurs conditions d'accès à leurs données, qu'avec des Opéra- teurs et des Distributeurs de Produits accrédités sur des terminaux accrédités. Cette relative étanchéité des systèmes permet une certaine confidentialité des données : il est ainsi impossible à un Opérateur de téléphonie mobile, Propriétaire d'une Application de téléphonie sur le support, de prendre connaissance des dernières transactions bancaires effectuées avec le support, ou bien à une banque de connaître les der- niers déplacements de son client. Cependant, cette organisation des supports multi-Application n'apporte pas entière satisfaction, dans la mesure où elle limite considérablement l'interopérabilité entre les systèmes utilisant une Application, et en particulier les ventes croisées ou à domicile. II est en effet impossible à un terminal de transmettre des informations à une Application auprès de laquelle ce terminal n'est pas suffisamment accrédité : par exemple un distributeur de billets de banque ne peut délivrer un titre de transport dans une Application pour lequel il n'est pas accrédité pour la vente ; de même pour un ordinateur personnel connecté à Internet, qui n'est pas accrédité du tout. Un objectif de l'invention est donc de fournir un procédé permettant le transfert d'informations, vers une Application sécurisée, par un terminal non suffisamment accrédi- té auprès de ladite Application. A cet effet, l'invention a pour objet un procédé d'émission d'informations du type précité, caractérisé en ce qu'il comporte les étapes suivantes : - dépôt, dans au moins une zone de mémoire tampon d'un support multi-Application, d'au moins une information à destination de l'Application sécurisée destina- taire, par le terminal émetteur non-suffisamment accrédité auprès de l'Application sécuri- sée destinataire ; - récupération et authentification de la ou chaque information et de son origine, dans la zone de mémoire tampon, par un terminal suffisamment accrédité ; et - action du terminal accrédité sur la ou chaque information. Le procédé selon l'invention peut comprendre l'une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou selon toute(s) combinaison(s) techniquement possibles) : - l'action du terminal accrédité sur la ou chaque information est un transfert de la ou chaque information, par le terminal accrédité, vers l'Application sécurisée destinataire; - l'action du terminal accrédité sur la ou chaque information est une utilisation im- médiate de la ou chaque information par le terminal accrédité ; - la ou chaque information comporte entre autres des informations d'identification de l'Application sécurisée destinataire et des données à destination de l'Application sécurisée destinataire ; - la ou chaque information comporte en outre des informations d'identification du terminal émetteur et/ou de son Propriétaire, permettant l'authentification des données et celle de son origine. - le terminal émetteur est accrédité auprès d'une autre Application sécurisée du support ; - la ou chaque information déposée dans la zone de mémoire tampon y est conservée jusqu'à ce qu'elle y soit récupérée par le terminal accrédité, ou bien périmée ; - la ou chaque informations déposée dans la zone de mémoire tampon y est orga- nisée par critère de façon à faciliter sa récupération par le terminal accrédité ; - l'Application sécurisée destinataire est hébergé dans le support multi- Applications. L'invention a également pour objet un support multi-Applications pour la mise en oeuvre du procédé présenté ci-dessus, support géré par un propriétaire de support et hébergeant des Applications, ce support comportant des moyens de connexion à un terminal émetteur d'au moins une information à destination d'une Application sécurisée, le ter- minai émetteur n'étant pas suffisamment accrédité auprès de cette Application sécurisée, le support comportant des moyens de connexion à un terminal accrédité auprès de l'Application sécurisée, caractérisé en ce qu'il comporte au moins une zone de mémoire tampon propre à stocker l'information. Le support multi-Application selon l'invention peut comprendre l'une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou selon toute(s) combinaison(s) techniquement possible(s) : - la zone de mémoire tampon est une Application du support ; - le Propriétaire de l'Application de zone de mémoire tampon est le Propriétaire du support ou de tout ou partie de son logiciel ; - la zone de mémoire tampon est associée à un module de gestion de files d'attente, propre à accélérer l'adressage de la ou chaque information déposée dans la zone de mémoire tampon. La présente invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple, et faite en se référant aux dessins annexés, sur lesquels : - la Figure 1 représente un support multi-Application selon l'invention, ainsi que des terminaux avec lesquels le support peut interagir, dans le cadre d'une mise en oeuvre d'un procédé selon l'invention ; - la Figure 2 représente une vue d'un détail marqué II de la Figure 1 ; - la Figure 3 représente un schéma simplifié présentant la mise en oeuvre d'un procédé selon l'invention ; et - la Figure 4 représente les principales étapes d'un procédé selon l'invention. Le support multi-Application 10 représenté sur la Figure 1 comporte une mémoire non volatile 14 qui héberge n Applications dont par exemple au moins une Ap- plication de transports, au moins une Application de monétique ou au moins une Application de téléphonie. Il comporte également des moyens de connexion 16 à des terminaux 20, 21, 22. Le support multi-Application 10 entre par exemple dans la composition de cartes à puce avec ou sans contact, de téléphones mobiles, de périphériques USB, ou de périphé- riques Bluetooth. Un propriétaire de support P gère le support 10, ainsi que tout ou partie de son lo- giciel. Chaque Application est gérée par un Propriétaire P,,..., P, d'Application. Chaque Propriétaire P1,..., Pn gère une unique Application respectivement En variante, un même Propriétaire P,,..., Pn gère plusieurs Applications Les Applications comprennent notamment k Applications sécurisées AS1,...ASk. Chaque Application sécurisée AS1,...ASk est protégée par des secrets J1,...,Jk. Les secrets J1,...,Jk sont nécessaires pour accéder à chaque Application sécuri- sée respectivement AS1,...ASk, notamment pour lire des données qui y sont enregistrées ou pour y écrire des données. Chaque Propriétaire P1,..., Pn de chaque Application sécurisée AS1,...ASk gère l'accès à son Application sécurisée AS1,...ASk. En particulier, il accrédite des terminaux 20, 21, 22 en leur communiquant les secrets J1,...,Jk de son Application sécurisée AS1,...ASk. La mémoire non volatile 14 héberge également une zone de mémoire tampon DMZ. Cette zone de mémoire tampon DMZ est accessible à tout équipement, notamment à tout terminal 20, 21, 22. Elle est propre à stocker des informations I, l' en provenance de terminaux émetteurs 20, 21 non suffisamment accrédité auprès d'Applications sécurisées destinataires respectivement ASL, AS1 du support 10, gérées chacune par un propriétaire PL, Pi c'est-à-dire en provenance de terminaux émetteurs 20, 21 ne disposant pas des secrets JL, Jj de chacune des Applications sécurisées destinataires ASL, AS;. La zone de mémoire tampon DMZ est également propre à être lue par des terminaux accrédités 22 auprès des Applications sécurisées ASL, AS). La zone de mémoire tampon DMZ est enfin propre à conserver les informations I, I' jusqu'à une date d'expiration des informations I, I' ou jusqu'à ce que les informations I, I' soient récupérées par le ou chaque terminal accré- dité 22. De préférence, la zone de mémoire tampon DMZ est une des Applications du support 10. De préférence, le Propriétaire de l'Application de zone de mémoire tampon DMZ est le Propriétaire de support P. En option, chaque terminal émetteur 20, 21 est suffisamment accrédité auprès d'une autre Application sécurisée du support 10, différente des Application sécurisées destinataires ASL, ASj. En variante, ASL et AS; désignent la même Application sécurisée destinataire. En variante, les Applications sécurisées destinataires ASL, ASj ne sont pas héber- gées par le support 10. Comme représenté sur la Figure 2, chaque information I, l' stockée dans la zone de mémoire tampon DMZ comporte notamment des données D, D', à destination de l'une respectivement ASL, ASi des Applications sécurisées destinataires, auprès de laquelle l'émetteur 20, 21 n'est pas suffisamment accrédité. Chaque information I, I' comporte éga- lement des informations d'identification ID, l"D du destinataire de l'information I, l', c'est-à-dire de l'Application sécurisée destinataire respectivement ASL, ASi et des informations d'identification IE, l'E du terminal 20, 21 émetteur de l'information I, I' et/ou de son propriétaire. Chaque information I, I' comporte éventuellement une date t, t' d'expiration de l'information respectivement I, l'. Chaque information I, l' comporte en outre un moyen pour le destinataire identifié par ID, l'D d'authentifier les données D, D' et leur origine identifiée par IE, l"E. Pour ce faire, par exemple, au moins une partie de chaque information I, I' est cryptée et/ou signée selon un secret partagé et/ou certifié entre chaque terminal 20, 21 émetteur des données D, D', chaque propriétaire PL, P; de chaque Application sécurisée destinataire ASL, ASi et par délégation les terminaux 22 accrédités auprès de chaque Application sécurisée destina-taire ASL, ASi. En variante, un identifiant unique référence chaque information I, l' auprès d'un serveur pour en authentifier le contenu et l'origine à la demande. Dans une autre va-riante, les terminaux 20, 21 ne sont pas les émetteurs, c'est-à-dire l'origine des informa- tions I, l', mais une passerelle vers un serveur autorisé qui est le vrai émetteur à authentifier. En option, et si son volume l'exige, la zone de mémoire tampon DMZ est associée à un module M, de gestion des files d'attente. Ce module M, est par exemple intégré dans la zone de mémoire tampon DMZ, ou au contraire supporté par le logiciel de tous les terminaux 20, 21, 22 qui l'utilisent. Le module M, est propre à accélérer l'adressage des informations I, l' stockées dans la zone de mémoire tampon DMZ. Le module MI est propre à organiser les informations I, l' par critère, par exemple en fonction de leurs informations d'identification ID, l"D du destinataire, de leurs informations d'identification IE, l'E de l'émetteur, de leur dates de péremption t, t', ou encore de tout autre critère disponible dans la zone de mémoire tampon DMZ. En option également, la zone de mémoire tampon DMZ est associée à un deuxième module M2 de gestion de la mémoire. Ce module M2 est par exemple intégré dans la zone de mémoire tampon DMZ, ou au contraire supporté par le logiciel de tous les terminaux qui l'utilisent. Le module M2 est propre à contrôler la date t, t' d'expiration des informations respectivement I, l' stockées dans la zone de mémoire tampon DMZ et à effacer les informations 1,1' lorsque la date t, t' d'expiration est dépassée. Le module M2 de gestion de la mémoire est également propre à assurer le recyclage de la zone de mémoire tampon DMZ. La mise en oeuvre d'un procédé 90 selon l'invention va maintenant être décrite, en regard des Figures 3 et 4. La Figure 3 illustre les différents échanges entre les terminaux 20 et 22 et le support 10 pour permettre l'émission de l'information I par le terminal émetteur 20 non suffisamment accrédité à destination de l'Application sécurisée destinataire ASL à travers la zone de mémoire tampon DMZ puis par l'intercession du terminal 22 suffisamment accrédité auprès de l'Application sécurisée destinataire ASL. Comme représenté sur la Figure 4, le procédé 90 selon l'invention comprend trois grandes étapes : une première étape 100 de dépôt de l'information I dans la zone de mémoire tampon DMZ du support 10, une deuxième étape 200 de conservation de l'in-formation I dans la zone de mémoire tampon DMZ et une troisième étape 300 de récupération de l'information I dans la zone de mémoire tampon DMZ et d'interaction du terminal 22 avec cette information I. La première étape 100 comporte une première sous-étape 102 de connexion du support 10 au terminal 20, une deuxième sous-étape 104 de constitution de l'information I, à partir des données D par le terminal 20 et son transfert vers la zone de mémoire tampon DMZ et une troisième sous-étape 106 d'organisation de l'information I dans la zone de mémoire tampon DMZ. Lors de la première sous-étape 102, le support 10 se connecte au terminal 20. Cette connexion est à contact (ISO 7816-2/3/etc., USB, FireWire, etc.) ou sans contact (ISO14443-1/2/etc. ISO15593, BlueTooth, etc.), Au cours de la sous-étape 104, le terminal 20 émet l'information 1 à destination de l'Application sécurisée destinataire ASL. Le terminal 20 n'étant pas suffisamment accrédité auprès de l'Application sécurisée destinataire ASL, c'est-à-dire ne détenant pas les secrets JL permettant de modifier le contenu de l'Application sécurisée destinataire ASL, il ne peut transférer cette information I directement à l'Application sécurisée destinataire ASL. Il dépose donc l'information I dans la zone de mémoire tampon DMZ. L'information I corn- prend les données D à destination de l'Application sécurisée destinataire ASL, ainsi que les informations ID d'identification du destinataire de l'information I, c'est-à-dire de l'Application sécurisée destinataire ASL, les informations IE d'identification de l'émetteur de l'information I, c'est-à-dire du terminal 20 et/ou de son propriétaire, et éventuellement la date t d'expiration de l'information I. Au cours de la sous-étape 106, l'information I est organisée dans la zone de mé- moire tampon DMZ par le module M, de gestion des files d'attente. Le module M1 orga- nise l'information I par critères, typiquement en fonction des informations d'identification ID du destinataire, des informations d'identification IE de l'émetteur, mais aussi en fonction de tout critère pertinent comme l'ordre ou l'horodate de dépôt dans la zone de mémoire tampon DMZ ou encore la priorité déclarée, etc. Une fois les transactions nécessaires effectuées entre le support 10 et le terminal 20, l'étape 100 est achevée. Le support 10 se déconnecte alors du terminal 20. Au cours de l'étape 200 de conservation de l'information I dans la zone de mémoire tampon DMZ, l'information I est préservée dans son intégralité. Tout autre terminal non suffisamment accrédité auprès d'au moins une des Applications sécurisées AS1,...ASk veille à préserver la ou chaque information I présente dans la mémoire tampon DMZ. En variante, l'étape 200 comporte au moins une sous-étape 202 de recyclage d'un emplacement de la mémoire tampon DMZ. Cette étape se déclenche par exemple lors de la connexion du support 10 au terminal 21 non suffisamment accrédité auprès de l'Appli- cation sécurisée AS; du support 10, le terminal 21 souhaitant effectuer une étape 100 concurrente, c'est-à-dire déposer l'information I' à destination de l'Application sécurisée AS;, alors que l'espace de stockage disponible dans la mémoire tampon DMZ n'est pas suffisant. Si la date de péremption t de l'information I est dépassée, son emplacement est alors recyclé au moyen du module M2 et l'information I' est inscrite à sa place. Dans un autre mode de réalisation, ce recyclage 202 de l'emplacement de l'information I est fait de façon anticipée lors de chaque consultation de la mémoire tampon DMZ. Lorsque l'information I n'a pas dépassé sa date t d'expiration elle est, lors de l'étape 300, transférée vers l'Application sécurisée ASL. L'étape 300 comporte une première sous-étape 310 de connexion du support 10 au terminal 22, une deuxième sous- étape 320 d'interaction entre le terminal 22 et l'information I, et une troisième sous-étape 330 de maintenance de la zone de mémoire tampon DMZ. Lors de la première sous-étape 310, le support 10 se connecte au terminal 22 suffisamment accrédité auprès de l'Application sécurisée destinataire ASL. Lors de cette sous-étape, le module MI inspecte les informations I, I' en attente pour toute Application sécurisée AS; pour laquelle le terminal 22 est suffisamment accrédité, dont l'Application sécurisée destinataire ASL. Lors de la deuxième sous-étape 320, itérée pour toutes les Applications sécurisées AS; ci-dessus, le terminal 22 récupère la ou chaque information I en attente pour l'Application sécurisée destinataire ASL. Cette deuxième sous-étape 320 comporte elle-même une première sous-étape 322 d'acquisition et d'authentification de l'information 1 et de son origine, une deuxième sous-étape 324 d'authentification du terminal 22 auprès de l'Application sécurisée destinataire ASL identifiée par l'information ID d'identification du destinataire et une troisième sous-étape 326, 328 d'action du terminal 22 sur l'information I. Dans le cas où l'Application sécurisée destinataire ASL est hébergée par le support 10, la sous-étape 326, 328 d'action du terminal 22 sur l'information I est une sous-étape 326 de copie de l'information I vers l'Application sécurisée destinataire ASL. En option, la sous-étape 326 inclut, lorsque l'Application sécurisée destinataire ASL le permet, l'établissement d'un lien vers l'information I d'origine dans la zone tampon DMZ, afin de faciliter la prévention d'un rejet intempestif lorsque la connexion est interrompue à ce stade. En option, le terminal 22 utilise les données D après leur copie dans l'Application sécurisée destinataire ASL. Dans le cas où l'Application sécurisée destinataire ASL n'est pas hébergée par le support 10, la sous-étape 326, 328 d'action du terminal 22 sur l'information I est une sous-étape 328 d'utilisation immédiate de l'information I, si celle-ci s'avère possible. Si-non, l'information I est laissée en l'état dans la zone de mémoire de mémoire tampon DMZ et n'est ni transférée, ni utilisée. Lors de la quatrième sous-étape 328, le terminal 22 utilise les données D pour un traitement instantané. En option, il insère au moins une nouvelle information I" dans la zone tampon DMZ, comme s'il n'était pas accrédité. Selon le besoin, l'information I initiale est conservée ou écrasée. Lors de la troisième sous-étape 330, le terminal 22 effectue des opérations de maintenance de la zone de mémoire tampon DMZ facilitant la reprise lorsque la séquence d'opération a été interrompue, et garantissant l'absence de rejet intempestif. Cette sous étape 330 se divise en une sous-étape 332 consistant à supprimer l'information I de la zone de mémoire tampon DMZ lorsque le transfert vers l'Application sécurisée destina-taire ASL est complet, puis, en option, une sous-étape 334 de ratification par la suppression du lien inscrit dans la sous-étape 326. Le support 10 est enfin déconnecté du terminal 22. Grâce à l'invention, un terminal non accrédité auprès d'une Application sécurisée peut donc transférer des informations à destination de l'Application sécurisée sur un support multi-Application, ce qui permet d'augmenter l'interopérabilité, principalement la vente croisée, entre les systèmes (terminaux plus Applications) des Propriétaires de différentes Applications. L'invention permet également, de façon transparente pour l'utilisateur, de faire fonctionner un support multi-Application comme s'il hébergeait une Application sécurisée dont il n'est en fait pas doté. REVENDICATIONS1.- Procédé (90) d'émission d'informations à destination d'une Application sécurisée destinataire (ASL), par un terminal émetteur (20) non suffisamment accrédité auprès de cette Application sécurisée destinataire (ASL), caractérisé en ce qu'il comporte les éta- pes suivantes : - dépôt (100), dans au moins une zone de mémoire tampon (DMZ) d'un support multi-Application (10), d'au moins une information (I) à destination de l'Application sécurisée destinataire(ASL), par le terminal émetteur non-suffisamment accrédité (20) auprès de l'Application sécurisée destinataire (ASL) ; - récupération et authentification (322) de la ou chaque information (I) et de son origine, dans la zone de mémoire tampon (DMZ), par un terminal suffisamment accrédité (22) ; et - action (326, 328) du terminal accrédité (22) sur la ou chaque information (I). 2.- Procédé (90) d'émission d'informations selon la revendication 1, caractérisé en ce que l'action (326, 328) du terminal accrédité (22) sur la ou chaque information (I) est un transfert (326) de la ou chaque information (I), par le terminal accrédité (22), vers l'Application sécurisée destinataire (ASL). 3.- Procédé (90) d'émission d'informations selon la revendication 1, caractérisé en ce que l'action (326, 328) du terminal accrédité (22) sur la ou chaque information (I) est une utilisation immédiate (328) de la ou chaque information (I) par le terminal accrédité (22). 4.- Procédé (90) d'émission d'informations selon l'une quelconque des revendications précédentes, caractérisé en ce que la ou chaque information (I) comporte entre autres des informations (ID) d'identification de l'Application sécurisée destinataire (ASL) et des données (D) à destination de l'Application sécurisée destinataire (ASL). 5.- Procédé (90) d'émission d'informations selon la revendication 4, caractérisé en ce que la ou chaque information (I) comporte en outre des informations (IE) d'identification du terminal émetteur (20) et/ou de son Propriétaire, permettant l'authentification des don-nées et celle de son origine. 6.- Procédé (90) d'émission d'informations selon l'une quelconque des revendications précédentes, caractérisé en que le terminal émetteur (20) est accrédité auprès d'une autre Application sécurisée du support (10). 7.- Procédé (90) d'émission d'informations selon l'une quelconque des revendications précédentes, caractérisé en ce que la ou chaque information (I) déposée dans la zone de mémoire tampon (DMZ) y est conservée jusqu'à ce qu'elle y soit récupérée par le terminal accrédité (22), ou bien périmée. 8.- Procédé (90) d'émission d'informations selon l'une quelconque des revendications précédentes, caractérisé en ce que la ou chaque information (I) déposée dans la zone de mémoire tampon (DMZ) y est organisée par critère de façon à faciliter sa récupération par le terminal accrédité (22). 9.- Procédé (90) d'émission d'informations selon l'une quelconque des revendications précédentes, caractérisé en ce que l'Application sécurisée destinataire est hébergé dans le support multi-Applications (10). 10.- Support multi-Application (10), géré par un propriétaire de support (P) et hébergeant des Applications (A1,...,An), ce support (10) comportant des moyens de connexion (16) à un terminal (20) émetteur d'au moins une information (I) à destination d'une Application sécurisée (ASL), le terminal émetteur (20) n'étant pas suffisamment accrédité auprès de cette Application sécurisée (ASL), le support (10) comportant des moyens de connexion (16) à un terminal (22) accrédité auprès de l'Application sécurisée (ASL), caractérisé en ce qu'il comporte au moins une zone de mémoire tampon (DMZ) propre à stocker l'information (I). 11.- Support multi-Application (10) selon la revendication 10, caractérisé en ce que la zone de mémoire tampon (DMZ) est une Application du support (10). 12.- Support multi-Application (10) selon la revendication 11, caractérisé en ce que le Propriétaire de l'Application de zone de mémoire tampon (DMZ) est le Propriétaire (P) du support (10) ou de tout ou partie de son logiciel. 13.- Support multi-Application (10) selon l'une quelconque des revendications 10 à 12, caractérisé en ce que la zone de mémoire tampon (DMZ) est associée à un module (MI) de gestion de files d'attente, propre à accélérer l'adressage de la ou chaque information (I) déposée dans la zone de mémoire tampon (DMZ).