FR2932909A1

FR2932909A1 - Smart card event (sme) : tour de table (tdt) realise au sein d'une carte a puce. le tdt consiste a passer un evenement plus donnees a une liste d'applications pour traitement et/ou interrogation

Info

Publication number: FR2932909A1
Application number: FR0803415A
Authority: FR
Inventors: Michel Benchetrit
Original assignee: Individual
Current assignee: Individual
Priority date: 2008-06-19
Filing date: 2008-06-19
Publication date: 2009-12-25

Abstract

Procédé technique implémentée au sein d'une Carte à Puces dans laquelle cohabitent plusieurs applications étanches (Api), i=0,N avec N>0. Le procédé technique permet à une Source (1) ou (2) de générer un « Tour De Table ». Le « Tour De Table » (3) consiste à envoyer un événement associé à des données à une liste d'applications présentes sur la Carte. A la réception de cet événement associé à des données, les applications interrogées peuvent ou non réaliser un traitement et retourner des données (4) à la Source. Le fait que la Source puisse être une des applications de la carte, peut créer un lien (dialogue) inter application et automatiser certain traitement.

Description

DESCRIPTION DOMAINE TECHNIQUE La solution technique présentée dans cette description concerne le domaine des Cartes à Puces et consiste à apporter une solution au problème technique suivant:

Lorsque plusieurs applications sont présentes au sein d'une même carte à puce, 10 elles sont étanches et il n'est pas possible de réaliser une transaction qui mette en oeuvre plusieurs applications simultanément. ETAT ACTUEL Aujourd'hui les cartes à puces sont de plus en plus multi applicatives mais ne 15 proposent pas de mécanisme qui permette le dialogue ou les inter actions entre les applications.

Pourquoi disposer de tel mécanisme ?

20 Dans certains cas, des applications présentes au sein d'une même carte, bien que répondant à des spécifications fonctionnelles différentes et indépendantes peuvent être liées pour offrir de nouvelles fonctionnalités et/ou services.

Voici un exemple simple qui illustre ceci, Une Carte à Puce a deux applications : 25 O Application Bancaire (EMV ...) qui réalise des transactions en EURO ({) Cl Application de Fidélité qui gère une Balance en POINT.

L'émetteur de cette carte veut fidéliser ses porteurs en y ajoutant la fonctionnalité 30 suivante : Chaque EURO réalisé avec l'application Bancaire rapporte un POINT. Si la fonctionnalité est simple à exprimer, sa mise en place est complexe. En effet, en partant du principe que les applications sont étanches (ce qui est le cas car sinon il y aurait autant de cartes que de cas particuliers), la solution retenue dans la plupart des cas est qu'une deuxième transaction dite de fidélité est réalisée, ce 35 qui a des conséquences importantes :

O Développement d'une application côté Terminal (le parc des Terminaux est souvent hétérogène et l'émetteur de la carte ne maîtrise pas forcément ce parc). 40 O Une deuxième transaction doit être réalisée 4 saisie à nouveau du montant

L'idée exposée dans ce document (SME : Smart Card Event) se propose de réaliser de telle fonctionnalités sans aucune intervention en dehors de la carte. 45 DEFINITIONS Avant de décrire le mécanisme SME, juste un rappel sur l'architecture de Cartes à Puces sur lesquels on pourrait implémenter un tel mécanisme et quelques 5 définitions qui nous permettrons de mieux décrire ce mécanisme. On suppose que la Carte à Puce : Cl Dispose d'un Système d'Exploitation qui gère plusieurs applications O Dans la majorité des cas, une transaction avec la carte est réalisée au travers d'une application, cette application étant choisie à l'aide de la commande SELECT (SELECT ADF par exemple)

15 Nous appellerons Manager (GA) le composant logiciel du système qui gère les applications.

Un Logiciel est un composant logiciel au sein de la Carte à Puce qui répond à une spécification précise : EMV, CPA, Application TOTAL ... Seul, un logiciel ne peut rien faire : c'est un ensemble d'octets binaires qui peuvent être exécutés ou interprétés et présent dans la mémoire non volatile de la Carte (ROM, EEPROM ...).

25 Associé à des Données (ADF, EF, DF ...) un logiciel devient une Application. Plusieurs Applications peuvent être associées au même Logiciel (on parle alors de multi instances).

Une Transaction est l'implémentation d'une ou plusieurs fonctionnalités d'une 30 Application. Une Transaction d'une Application X démarre en général suite au SELECT de l'Application. Cette sélection est réalisée en général à l'aide la commande SELECT ADF (ou GPO pour une transaction bancaire EMV) . Si le début d'une Transaction est clair, il n'en est pas de même de la fin d'une Transaction qui n'est pas toujours bien défini dans les spécifications d'Applications Cartes à Puces. 35 La délimitation d'une Transaction (Début et Fin) est importante car le mécanisme SME doit être implémenter au début et/ou la fin d'une Transaction. DESCRIPTION

SME (Smart Card Event) est une solution technique implémentée au sein d'une 40 Carte à Puce par le (GA) au début ou la fin d'une Transaction.

Il s'agit d'un événement associé à des données et avec lequel le (GA) réalise un Tour De Table , c'est à dire que l'événement est passé à un ensemble d'applications pour un éventuel traitement. Un Evénement est matérialisé par un ensemble de données élémentaires (TAGs) qu'on désigne par EDO (Event Data Object). Tout EDO doit au moins contenir un TAG élémentaire : Le code de l'événement ou identifiant de l'EDO. 10 20 45 Il peut exister plusieurs EDO au sein d'une même Carte : Un EDO par application, un EDO pour toutes les Applications ... ces EDO peuvent être personnalisés ou mis en dur ...

Le principe du SME est très simple : il s'agit pour le (GA) de passer à un ensemble d'applications un EDO afin que ces dernières puissent réaliser un traitement. La structure d'un EDO définie elle même l'ensemble des applications concernées, là encore cette liste peut être différente selon l'événement, la personnalisation ...

L'implémentation du SME est constitué des étapes suivantes :

1) Le (GA) est sollicité par une Source pour réaliser un Tour De Table . La source fournie un EDO. 2) Le (GA) passe l' EDO à toutes les Applications définies par l'EDO, ces applications peuvent :

a. Réaliser éventuellement un Traitement b. Retourner un ensemble de données : dans ce cas l'application doit au moins les données élémentaires suivantes : Priorité et Nom application

Le (GA) termine le SME en retournant à la Source les données reçues de toutes les Applications ayant participées au Tour De Table . Cette structure de données est désignée par ERDO (Event Response Data Object). La Source peut être soit :

Interne : c'est une Application de la Carte. La mise en place du SME se fait alors en début ou en fin de transaction par l'Application sélectionnée. Le SME 30 est dit SME Interne.

O Externe : c'est le Terminal (Terminal De Paiement, PC ...). La mise en place du SME se fait par le Terminal au travers d'une commande de type SELECT. Le SME est dit alors SME Externe. Dans le cas où le SME est externe, la priorité retournée par les applications peut être utiles dans la mesure où elle donne une évaluation de l'événement par chaque application.

40 La Source qui a initié le SME peut par exemple interpréter la priorité comme étant la volonté par une application de réaliser une transaction suite à cet événement. L'application qui traitera l'événement sera alors l'application qui aura donnée la plus forte priorité. 45 Le SME Externe peut être vu comme une extension de la commande SELECT. On pourrait imaginer une Carte qui traite un SELECT étendu dans lequel :

^ Si le paramètre P2 = '00' (identique à aujourd'hui) , un EDO prédéfini est construit et utilisé : D Evénement = SELECT 25 35 50 - Liste des applications = Une seule, celle définie par I' AID passé dans le champ DATA de la commande SELECT ^ Si le paramètre P2 = 'FF', alors les données correspondent à un EDO. STRUCTURES DE DONNEES

Ce qui suit est un exemple d'implémentation des structures de données EDO et ERDO . Une autre implémentation pourrait être choisie. 10 EDO : EVENT DATA OBJECT '9F1X' Template EDO M '9F2X' Identifiant EDO M '9F3X' Template Propriétaire EDO M 15 '9F4X'Octet De Contrôle EDO M '9F5X'Liste AID (Applications) O

M= Mandatory (Obligatoire) O = Optionnel

20 Identifiant EDO : '9F2X', 2 octets Obligatoire, ce Tag est constitué de 2 octets binaires qui identifient de manière unique l'événement.

Octet De Contrôle EDO : 19F4X', 1 octet 25 Cet octet indique au (GA) la liste des Applications concernées par le Tour De Table :

Bit 8 = 0 Toutes les Applications (Sauf Initiateur) (*) = 1 Utiliser les Applications définies dans Liste AID avec Bit 7

Bit 7 = 0 Applications à Exclure (Toutes sauf la liste) = 1 Applications à Inclure (Uniquement la liste)

Bits 6-1 RUF (*) Quand l'octet de Contrôle indique 'Toutes les Application', cela veut dire

^ Pour un SME Externe, Toutes les Applications de la Carte ^ Pour un SME Interne, Toutes les Applications de la Carte sauf celle qui a 40 générée le SME

Liste AID (Applications) : '9F5X', N octets Liste d'AID, chaque AID est constitué du TAG '84'. 45 Le TAG '84' est répété autant de fois que d'AID présents. 30 35 D'autres TAGs peuvent être rajoutés au template '9F3X' (Montant, Devise ...), TAGs spécifiques à chaque application et/ou événement. ERDO : EVENT RESPONSE DATA OBJECT '9F16X' ERDO Template M '9F7X' Nombre d'Applications M '9F8X' Réponse Application 1 M '84' Aid M '9F9X' Priorité M '9F8X'Réponse Application 2 M '84' Aid M '9F9X'Priorité M M= Mandatory (Obligatoire) O = Optionnel

Nombre d'Applications : `9F7X', 1 octet Obligatoire, ce Tag est constitué de 1 octet binaire et correspond au nombre d'Applications ayant retourné une réponse suite au Tour De Table

Réponse Application X : '9F8X', N octets Chaque Application impliquée dans le Tour De Table peut retourner une réponse 25 à l'initiateur du Tour De Table . Cette réponse est en capsulée dans un template '9F8X' qui comporte au moins deux tags

^ TAG '84' AID de l'application ^ TAG '9F9X' Priorité = 1 octet (00 priorité la plus faible, 255 la plus forte) D'autres TAGs peuvent être rajoutés au template '9F9X', TAGs spécifiques à chaque application et/ou événement. 30 MISE EN APPLICATION

Les chapitres qui suivent donnent quelques exemples de réalisation concrètes d'utilisation de SME. 1) PRIVATIF / FIDELITE

Aujourd'hui la plupart des compagnies pétrolières propose une carte privative qui permet d'acheter de l'essence et/ou des services dans les stations affiliées à la compagnie. Cette carte est dans la majorité des cas une carte à puce.

Ces même compagnies proposent souvent un programme de fidélité qui consiste à accumuler des points. Les points sont obtenus en réalisant des achats avec la carte privative. Ce programme est très souvent géré avec une autre carte, à piste.

Les inconvénients d'un tel système est :

Gestion de deux cartes. O Deux transactions doivent être réalisées.

UTILISATION D'UN SME INTERNE

L'utilisation d'une carte à puce avec deux applications : O L'application privative actuelle O Une application de fidélité (Balance de POINTS)

Après chaque transaction réalisée avec l'application privative, un SME pourrait être générée par l'application privative. L'application de Fidélité, sur réception de cet 30 EDO pourrait mettre à jour automatiquement son cumul de points.

AVANTAGES

Plus qu'une seule carte à gérer 35 Une seule transaction qui réalise l'achat et la mise à jour du cumul 6 5 ) BANCAIRE / FIDELITE Une Banque (émetteur de Cartes à Puce) veut fidéliser : ^ ses porteurs en privilégiant les paiements effectués à l'aide de sa carte bancaire. Cl Dynamiser son réseau (ensemble des commerces domiciliés auprès de cette 7 banque ) 10 15 Pour cela, elle veut mettre en place un programme de fidélité simple :

Chaque porteur de cette banque se voit affecter un cumul de point. Tout achat réalisé avec sa carte bancaire rapporte :

^ 2 POINTS pour chaque EURO dépensé dans son réseau 1 POINT pour chaque EURO dépensé en dehors de réseau

Les points peuvent ensuite être convertis en cadeaux ... auprès de cette banque. 20 UTILISATION DE SME Un SME interne est utilisé. La carte est personnalisée de telle sorte qu'a la fin de toute transaction bancaire, un Tour De Table est généré. L'application de fidélité va intercepter toutes les transactions de DEBIT en EURO et va mettre 25 automatiquement son cumul de POINT à jour. Ce cumul peut être mis au jour même lors de paiements réalisés à l'étranger si ces paiements sont réalisés avec la puce.

DEFINITION DE LA EDO BANCAIRE 30 Cette EDO est donc utilisée par l'application bancaire (si elle a été personnalisée) à la fin de chaque transaction : appel vers le (GA) au dernier GAC (GENERATE APPLICATION CRYPTOGRAM).

'9F1X' 38 '9F2X' 02 00 01 événement transaction DEBIT '9F3X' 30 '9F4X'01 00 Octet Contrôle : TOUTES '9C' 01 Type Transaction '9F02' 06 Montant Transaction '5F2A'02 Devise Transaction '9A' 03 Date Transaction '9F27'01 Cryptogram Information Data

Quand l'application de Fidélité reçoit cet EDO, si :

o C'est une Transaction de DEBIT (Test du type d'événement et Type Transaction) ^ Si elle a été acceptée (CID = TC) ^ Si la Devise est en EURO 35 40 45 50

Alors, elle peut mettre à Jour son cumul de points, Nombre de transactions ... ou tout autre indicateur prévu par le Programme de Fidélité.

REMARQUES 1. Dans ce cas précis, il ne semble pas nécessaire de définir et retourner une ERDO 2. Il est clair que SME n'est pas un outil qui va tout automatiser dans la mesure 10 où dans cet exemple précis, l'application de Fidélité ne fera que ce qui aura été prévu (Spécifications FIDELITE). 3. Par contre SME offre un mécanisme qui permet d'exciter en quelque sorte l'application de Fidélité de manière automatique. 4. Le problème dans l'implémentation décrite ci dessus est que le Terminal n'est pas authentifié est que par conséquent rien ne garanti que les points accumulés sont légitimes.

20 La dernière remarque pourrait être bloquante, en fait plusieurs cas peuvent être imaginés :

CAS D'UN DEPLOIEMENT DE CARTES ON LINE 25 Si l'émetteur émet des cartes on line c'est à dire avec authentification de l'émetteur systématiquement alors l'authentification du Terminal n'a plus de sens car on sûr que la Transaction est réelle. Cela veut donc dire qu'un tel programme de fidélité pourrait être mis en place (par un émetteur on line ) sans aucune intervention 30 sur le parc de Terminaux de Paiement. Lors de la personnalisation de l'EDO, on peut rajouter un TAG qui sera testé par l'application de Fidélité afin de s'assurer qu'une authentification de l'émetteur a bien été réalisée.

CAS D'UN DEPLOIEMENT DE CARTES OFF LINE Si on n'est pas dans le cas précédent, il faudrait que la mise à jour du cumul de points soit associée à une authentification :

O Du Terminal ou 40 O De l'émetteur

Afin de s'assurer de la véracité de la Transaction bancaire.

Les spécifications EMV telle que définies aujourd'hui permettent une solution 45 relativement simple à mettre en oeuvre mais qui nécessite une modification côté Terminal :

O Pour les Terminaux participant à ce programme de Fidélité, un ou plusieurs TAGs doivent être rajoutés lors de leur initialisation. O Ce ou ces TAGs doivent être personnalisées dans la PDOL de l'application bancaire. 15 35 50 O Lors du GPO (début de transaction bancaire), le Terminal donnera ces TAGs à la Carte.

O Si ces TAGs sont inclus dans l'EDO, ils seront passés à l'application de Fidélité qui pourra alors authentifier ou non la véracité de ces données et mettre à jour ou non son cumul de points.

Ces TAGs Fidélité peuvent être un mot de passe, une signature (principe de la 10 SDA), une clé TDES ...

L'inconvénient majeur de cette solution est qu'elle touche au Terminal. Même si ces modifications sont mineures il faut bien comprendre que l'émetteur ne maîtrise pas le parc des Terminaux sur le terrain. 15 Une autre solution consisterait à modifier le programme de Fidélité en ne donnant des points que pour les Transactions réalisées dans le réseau de la Banque. Il faudrait alors pour ne pas avoir à modifier les Terminaux forcer une authentification émetteur pour toute transaction réalisée par un porteur de la 20 Banque X chez un commerce domicilié à cette même Banque. Ceci pourrait alors être réalisé à l'aide de deux SME internes :

L'un interne déclenché après le GPO (début de transaction bancaire). Cet EDO doit comporter l'identifiant de l'accepteur. Si ce dernier appartient au 25 réseau bancaire concerné, un ERDO est généré indiquant qu'une authentification émetteur doit être réalisée.

O L'autre interne en fin de transaction avec un EDO donnant l'indicateur émetteur authentifié ou non, le montant ... En fait la problème posé ci dessus dépasse le cadre du SME. Il faut bien comprendre que SME est un mécanisme générique qui permet à une source (Application interne d'une Carte ou Terminal) de passer un EDO (Evénement/Données) à une liste d'applications présentes dans la Carte. 30 35 ) BANCAIRE / PME

Deux applications présentes sur la Carte :

^ Application Bancaires (Transactions de DEBIT/CREDIT en EURO) ^ PME : Porte Monnaie Electronique L'émetteur de la carte désire avoir la fonctionnalité suivante :

^ Utilisation de l'application PME pour les montants inférieur à 10 { ^ Utilisation de l'application Bancaire pour les montants supérieur à 10 { Un SME Externe pourrait être utilisé. L'application PME donnera une priorité supérieur à celle de l'application Bancaire pour tout montant inférieur à 10 {, elle sera donc prioritaire au niveau du Terminal.

Ce mécanisme de Tour De Table existe aujourd'hui dans certaines 20 implémentation (Cas de MONEO en France par exemple).

Quel avantages à mettre ce mécanisme dans la Carte plutôt que dans les Terminaux :

25 ^ Le Parc de Terminaux est hétérogène, donc difficile à déployer ^ Dans la Carte le seuil pourrait être différent pour chaque porteur 10

Claims

REVENDICATIONS1. Procédé implémenté au sein d'une carte à puce (CAP) comportant au moins deux applications (Api) i=O,N avec N>O, qui consiste à faire traiter un événement par une ou plusieurs applications sans aucune sélection au préalable de ce(s) application(s). Ledit procédé comporte les étapes suivantes : a) Une application (APO) de la carte est sélectionnée pour réaliser une transaction (TO) b) A la fin et/ou début de cette transaction (TO), l'application (APO) envoi un événement au Manager (GA) en indiquant qu'elle désire effectuer un tour de table , c'est à dire envoyer l'événement à toutes les autres applications (Api), i=1,N c) Le Manager (GA) réalise le tour de table demandé en envoyant l'événement à toutes les applications (Api), i=1,N d) A la réception de l'événement, toute application (Api)i=1,N peut si elle le désire traiter l'événement et/ou retourner un compte rendu au Manager (GA) e) Le Manager, une fois le tour de table terminé envoi un compte rendu à l'application (APO). Le compte rendu correspond à l'ensemble des comptes rendus retournés par les applications (Api) i=1,N
2. Procédé implémenté au sein d'une carte à puce (CAP) comportant au moins une applications (Api) i=1,N avec N>O, qui consiste à sélectionner la ou les bonne(s) application(s) pour traiter un évènement. Ledit procédé comporte les étapes suivantes : a) Un Terminal (T) envoi à la carte à puce (CAP) une commande b) Le Manager (GA) traite cette commande et la convertit en un événement c) Le Manager (GA) réalise alors un tour de table en envoyant cet événement à toutes les applications de la carte à puce (CAP) d) Chaque application (APi) renvoie au Manager un indicateur indiquant si elle veulent traiter cet événement. Dans le cas où l'événement est traité par une 35 application (Api), l'application donne une priorité (Pi) e) Le Manager (GA) analyse alors l'ensemble des indicateurs et priorités (Pi) retournées par toutes les applications. Le Manager crée alors une liste comportant la ou les applications ayant donné la priorité la plus élevée qui veulent traiter l'événement. 40 f) Le Manager envoi un message pour traiter l'événement aux applications présente dans cette liste.
3. Procédé selon les revendications 1. et 2. selon laquelle l'ensemble des événements susceptibles d'être traités par les applications d'une carte à puce sont 45 identifiés et codifiés de manière unique. A chaque événement peut être associé des données.