référentiel « architecture et sécurité - calypso · 2019-12-04 · 3.2.5 calypso..... 17 3.2.6...

Ministère de l’écologie, du développement durable et de l’énergie

Réf. : AFIMB_ReferentielArchitectureSecurite_v1.0

Classification : restreint – Copyright 2014

Page Date

1 / 93

19 mars 2014

Référentiel « architecture et sécurité »

des systèmes d’acceptation billettique

A F I M B




Page Date

2 / 93

19 mars 2014

PRÉAMBULE

Ce document est issu des travaux du groupe de travail « architecture et sécurité » mis en place par

l’AFIMB.

L’AFIMB souhaite remercier les membres de ce groupe de travail : ASK, CNA, CTS, Effia, GART,

GIE CB, Keolis, LMCU, Mercur, Nextendis, Novia Systems (Effitic), Parkeon, RATP, Région

Bretagne, RITMx, SNCF, STIF, Sytral, Thales, Tisseo, Transpole, UTP, Transdev, Viacités, VIX

Technology, Xerox (ACS Solutions) et Spirtech.

AUTEUR ÉDITEUR

Agence française pour l'information

multimodale et la billettique

(AFIMB)

LISTE DE RÉVISION

Version Date Modifications

v1.0 19-03-2014 Création.




Page Date

3 / 93

19 mars 2014

TABLE DES MATIÈRES

1 ABSTRACT ....................................................................................................................... 6

2 INTRODUCTION ................................................................................................................. 8

2.1 Objet du document ............................................................................................................................ 8 2.2 Présentation de l’AFIMB .................................................................................................................. 12 2.3 Audience et applicabilité du document .......................................................................................... 14 2.4 Cycle de vie du document ............................................................................................................... 14 2.5 Publication ........................................................................................................................................ 14

3 VUE D’ENSEMBLE ........................................................................................................... 15

3.1 Système d’acceptation billettique .................................................................................................. 15 3.2 Objet portable ................................................................................................................................... 16

3.2.1 Types et données ...................................................................................................................... 16 3.2.2 Secure element ......................................................................................................................... 16 3.2.3 Application ................................................................................................................................. 16 3.2.4 Application billettique ................................................................................................................. 17 3.2.5 Calypso ...................................................................................................................................... 17 3.2.6 Triangle ...................................................................................................................................... 18 3.2.7 Application billettique commune (ABC)...................................................................................... 18

3.3 Autres systèmes .............................................................................................................................. 18 3.4 Utilisateurs ....................................................................................................................................... 18

4 DESCRIPTION FONCTIONNELLE ........................................................................................ 19

4.1 Fonctions principales ...................................................................................................................... 19 4.2 Conditions ........................................................................................................................................ 19

4.2.1 Présentation .............................................................................................................................. 19 4.2.2 Sécurité ..................................................................................................................................... 20 4.2.3 Interopérabilité ........................................................................................................................... 20 4.2.4 Évolutivité .................................................................................................................................. 23 4.2.5 Optimisation des coûts .............................................................................................................. 24 4.2.6 Accessibilité de l’offre ................................................................................................................ 24

4.3 Fonctions élémentaires ................................................................................................................... 25 4.3.1 Introduction ................................................................................................................................ 25 4.3.2 Diagramme fonctionnel .............................................................................................................. 26 4.3.3 Liste des fonctions élémentaires ............................................................................................... 27

5 MODULES, SERVICES ET INTERFACES ............................................................................... 33

5.1 Principes ........................................................................................................................................... 33 5.1.1 Domaine billettique .................................................................................................................... 33 5.1.2 Modules ..................................................................................................................................... 33 5.1.3 Services ..................................................................................................................................... 33 5.1.4 Interfaces ................................................................................................................................... 34 5.1.5 Critères de définition .................................................................................................................. 34

5.2 Présentation des modules .............................................................................................................. 36 5.3 Description des modules ................................................................................................................ 38

5.3.1 M.PO – Commandes ................................................................................................................. 38 5.3.2 M.SECU – Sécurité billettique ................................................................................................... 39 5.3.3 M.APP – Accès à l’application ................................................................................................... 41 5.3.4 M.TRG – Triangle ...................................................................................................................... 42 5.3.5 M.MOD – Modèle de données ................................................................................................... 44 5.3.6 M.TRF – Règles tarifaires .......................................................................................................... 45




Page Date

4 / 93

19 mars 2014

5.3.7 M.MGR – Gestion applicative .................................................................................................... 46 5.3.8 M.MSG – Expédition-réception .................................................................................................. 48 5.3.9 M.MMI – Interface utilisateur ..................................................................................................... 49 5.3.10 M.ADM – Administration ............................................................................................................ 50 5.3.11 Environnement matériel et logiciel ............................................................................................. 51 5.3.12 Passerelle de paiement ............................................................................................................. 53

5.4 Présentation des services et des interfaces .................................................................................. 54 5.5 Description des services et des interfaces .................................................................................... 56

5.5.1 SRV.PO – Commandes objet portable ...................................................................................... 56 5.5.2 SRV.SAM – Commandes SAM ................................................................................................. 57 5.5.3 SRV.APP – Gestion des applications ........................................................................................ 57 5.5.4 SRV.ACC – Accès à l’application .............................................................................................. 58 5.5.5 SRV.AUTH – Sécurité des données .......................................................................................... 58 5.5.6 SRV.SECU – Gestion de la sécurité billettique .......................................................................... 59 5.5.7 SRV.TRG – Triangle .................................................................................................................. 59 5.5.8 SRV.MOD – Modèle de données .............................................................................................. 59 5.5.9 SRV.TRF – Tarification .............................................................................................................. 60 5.5.10 SRV.MSG – Collecte et distribution ........................................................................................... 60 5.5.11 SRV.MMI – Interface homme-machine ...................................................................................... 61 5.5.12 SRV.PRM – Gestion des paramètres ........................................................................................ 61 5.5.13 SRV.PAY – Paiement ................................................................................................................ 62 5.5.14 SRV.CTRL – Supervision billettique .......................................................................................... 62 5.5.15 SRV.TECH – Supervision technique ......................................................................................... 62 5.5.16 INT.API – API d’exécution ......................................................................................................... 63 5.5.17 INT.SRV – Gestion de services ................................................................................................. 63 5.5.18 INT.CMD – Transport de commandes ....................................................................................... 64 5.5.19 INT.SAM – SAM ........................................................................................................................ 64 5.5.20 EXT.PO – Objet portable ........................................................................................................... 65 5.5.21 EXT.NET – Réseau externe ...................................................................................................... 65 5.5.22 EXT.USER – Dispositifs d’IHM .................................................................................................. 65 5.5.23 EXT.PHY – Environnement physique ........................................................................................ 66

6 MODÈLES D’ARCHITECTURE ............................................................................................ 67

6.1 Introduction ...................................................................................................................................... 67 6.1.1 Objectif ...................................................................................................................................... 67 6.1.2 Durée de transaction perçue ..................................................................................................... 67 6.1.3 Disponibilité des autres systèmes ............................................................................................. 67 6.1.4 Types d’objets portables ............................................................................................................ 68 6.1.5 Gestion des droits de transport .................................................................................................. 69

6.2 Modèle totalement local .................................................................................................................. 72 6.3 Modèle distant maximal ................................................................................................................... 73 6.4 Modèles hybrides ............................................................................................................................. 75 6.5 Coexistence de différents modèles ................................................................................................ 76

7 VALIDATION DU RÉFÉRENTIEL .......................................................................................... 77

7.1 Pertinence des modules .................................................................................................................. 77 7.2 Objectifs du référentiel .................................................................................................................... 78

7.2.1 Évolutions normatives liées au transport ................................................................................... 78 7.2.2 Évolutions sécuritaires ............................................................................................................... 78 7.2.3 Évolutions des usages ............................................................................................................... 79 7.2.4 Évolutions des politiques tarifaires ............................................................................................ 79

7.3 Cas typiques ..................................................................................................................................... 79

8 SUITE DU RÉFÉRENTIEL ................................................................................................... 81

8.1 Spécifications ................................................................................................................................... 81




Page Date

5 / 93

19 mars 2014

8.2 Standardisation/normalisation ....................................................................................................... 82 8.3 Certification ...................................................................................................................................... 82 8.4 Évolutions techniques ..................................................................................................................... 82

9 ANNEXES ....................................................................................................................... 85

9.1 Glossaire ........................................................................................................................................... 85 9.2 Documents de référence ................................................................................................................. 92




Page Date

6 / 93

19 mars 2014

1 ABSTRACT

Les technologies mises en œuvre dans les systèmes billettiques sont en constante évolution, du fait

de l’enrichissement des fonctionnalités, mais également du fait de la mise à niveau des mécanismes

de protection contre la fraude. L’interopérabilité des systèmes billettiques locaux constitue une

préoccupation nouvelle, comme en témoignent le projet d’une application billettique commune aux

autorités organisatrices de transports, en France, et, au niveau européen, la création récente de la

« smart ticketing alliance » (STA).

Les autorités organisatrices de transports prennent en compte ces évolutions dans un cadre

budgétaire contraint. C’est dans ce contexte qu’elles ont souhaité le lancement par l’AFIMB d’une

démarche destinée à identifier les conditions permettant d’assurer sur le long terme une meilleure

capacité d’évolution des systèmes billettiques, une réduction de leur coût global et une meilleure

interopérabilité.

L’AFIMB a mis en place à cet effet un groupe de travail, animé par la société Spirtech. La réflexion

s’est concentrée sur le « système d’acceptation billettique » ou, dans la terminologie de la norme

ISO 24014 (IFM), le « medium access device ». Il s’agit des éléments du système billettique, tels que

les valideurs ou les serveurs de vente à distance, qui mettent en relation le client et le système

billettique par l’intermédiaire d’un objet portable.

Les conclusions de ce groupe de travail ont pris la forme d’un Référentiel « architecture et sécurité »

des systèmes d’acceptation billettique.

L'architecture du système d’acceptation billettique décrite dans le référentiel est fondée sur les

principes suivants :

• assurer l’indépendance entre le logiciel applicatif et l'équipement sur lequel il s'exécute ;

• séparer les parties communes à toutes les solutions et les parties spécifiques ;

• permettre la délocalisation de certaines fonctions ;

• utiliser des technologies génériques ;

• prendre en compte l'expérience acquise par les industriels ayant déjà intégré tout ou partie de

ces principes.

De ces principes découle naturellement une architecture modulaire : le système d’acceptation

billettique est constitué d’un nombre limité de modules logiciels.

En premier lieu, le référentiel recense les fonctions devant être assurées par les systèmes

d’acceptation billettique, puis il définit les modules logiciels de sorte que ceux-ci soient :

• spécifiques à une ou plusieurs fonctions, chaque fonction étant assurée par un seul module ;

• susceptibles d’être utilisés par un large ensemble de clients ;

• reliés par des interfaces normalisées réalisées par des services web ;

• remplaçables par tout fournisseur.




Page Date

7 / 93

19 mars 2014

Les services web assurent l’indépendance vis-à-vis du système d’exploitation (OS) et du matériel. Ils

offrent également toute souplesse pour placer un module soit dans le terminal qui communique avec

le support de titres, soit dans un équipement distant centralisant des traitements.

Le groupe de travail formule enfin en conclusion du référentiel des recommandations pour sa mise en

œuvre concrète. Il préconise :

• dans un premier temps, d’élaborer à partir du référentiel un recueil des exigences fonctionnelles

de l’architecture modulaire des systèmes d’acceptation billettique ; ce recueil d’exigences est

destiné à être intégré dans les appels d’offres des autorités organisatrices ;

• puis, de rédiger les spécifications fonctionnelles et techniques des interfaces et modules décrits

dans le référentiel ; de réaliser un démonstrateur permettant de vérifier la validité des choix

techniques.




Page Date

8 / 93

19 mars 2014

2 INTRODUCTION

2.1 Objet du document

Dans le cadre des missions de l’AFIMB, le présent document constitue un référentiel d’architecture et

sécurité des systèmes d’acceptation billettique (tels que définis au chapitre 3.1), pour une mise en

œuvre effective à l’horizon de cinq à dix ans.

Ce référentiel ne prend pas uniquement en compte les besoins des réseaux de transport français, car

il veille à généraliser autant que possible les solutions proposées à tout type de réseau de transport.

Ce référentiel est un guide à utiliser pour la conception de systèmes d’acceptation billettique. Il ne

décrit pas en détail les solutions techniques, qui devront être choisies en fonction des évolutions

technologiques des années à venir.

Objectifs

Le référentiel a pour objectifs de favoriser l’interopérabilité des systèmes d’acceptation billettique et la

réduction de leur coût global (investissement, fonctionnement et évolutions), pour toute taille de

réseau de transport, et en prenant en compte les nouveaux objets portables (dont les téléphones

mobiles NFC).

En effet, les AOT ont identifié les systèmes d’acceptation billettique comme ayant un fort potentiel de

réduction des coûts et d’amélioration de leur interopérabilité. L’interopérabilité visée est celle des

équipements et de leurs sous-ensembles, afin de faciliter les relations entre systèmes billettiques, et

de favoriser la disponibilité d’une offre de matériels et de logiciels génériques, interchangeables,

mutualisés et évolutifs.

En particulier, ce référentiel facilite la prise en compte des évolutions :

• évolutions normatives liées au transport ;

• évolutions sécuritaires ;

• évolutions des usages ;

• évolutions des politiques tarifaires.

Moyens

Les moyens utilisés dans ce référentiel pour atteindre ces objectifs sont :

• favoriser des objets portables et des applications interopérables, y compris au niveau de leur

contenu, en tenant compte des diverses solutions techniques disponibles : cartes sans contact

des transports, du monde bancaire ou de la vie quotidienne, téléphones mobiles NFC, clés USB

NFC, Application Billettique Commune (« ABC », voir chapitre 3.2.7), etc. ;

• faciliter les opérations de maintenance et de mise à jour, en particulier en minimisant et en

simplifiant les interventions humaines sur les équipements billettiques ;




Page Date

9 / 93

19 mars 2014

• favoriser l’indépendance vis-à-vis de la localisation des traitements, par exemple en permettant

de déplacer une fonction d’un équipement vers un autre ;

• faciliter l’utilisation de solutions non spécifiques au transport ;

• faciliter la concurrence entre les fournisseurs : réduire la dépendance vis-à-vis des fournisseurs,

afin qu’ils puissent proposer des solutions qui nécessitent peu ou pas de développements

spécifiques à chaque réseau ou à chaque évolution d’un composant ;

• réduire la dépendance vis-à-vis des délégataires de service public (DSP) : lors d’un

changement d’attribution de marché, le passage d’un système billettique à un autre doit se faire

au meilleur coût ;

• améliorer l’adéquation avec le niveau de sécurité souhaité ;

• aider concrètement les AOT à définir et exprimer leurs besoins lors d’appels d’offres.

Contraintes

De plus, les solutions proposées prennent en compte des contraintes spécifiques :

• la pérennité est une exigence forte :

- les systèmes doivent être utilisables pendant plusieurs années ;

- les systèmes doivent pouvoir évoluer progressivement ;

• les réseaux de transport sont de tailles très différentes ;

• des évolutions techniques pourraient donner lieu à des évolutions de ce référentiel.

Pour donner à un système d’acceptation billettique la capacité à évoluer au meilleur coût global pour

le système billettique, en assurant une sécurité adéquate, les éléments identifiés comme critiques

sont :

• l’évolution des communications sans contact ;

• l’évolution des composants sécurisés ;

• les évolutions logicielles ;

• l’interchangeabilité des fournitures : capacité à remplacer un système, un équipement ou un

logiciel par un autre.

Pour le présent référentiel, l’exigence de l’application du référentiel sans contact suffit pour s’assurer

que les systèmes d’acceptation billettique puissent traiter tous les types d’objet portable sans contact

utilisant le protocole ISO/IEC 14443.

Ce référentiel traite donc spécifiquement les autres éléments critiques.

Modules, services, interfaces et modèles

Afin de s’adapter au mieux aux besoins et contraintes énoncés ci-dessus, ce référentiel décrit les

modules fonctionnels qui composent les systèmes d’acceptation billettique, et les services et

interfaces entre ces modules.

Pour chacun de ces modules, ce référentiel indique ses caractéristiques dans les domaines suivants :

• niveau de sécurité ;




Page Date

10 / 93

19 mars 2014

• risques majeurs (techniques, financiers) ;

• contraintes sur les principes tarifaires ;

• contraintes sur l’infrastructure ;

• contraintes de mise en place en fonction de l’existant.

Pour un équipement donné, seul un sous-ensemble des modules décrits peut être utilisé. Ce

référentiel présente donc également des plusieurs modèles de systèmes d’acceptation billettique

ayant différentes combinaisons de modules fonctionnels.

De plus, ce référentiel décrit dans quels cas et comment plusieurs modèles pourraient être combinés

dans un même réseau, par exemple afin d’offrir le meilleur service à des clientèles diverses.

Référentiel et norme IFM

La norme IFM étant le fondement de toute démarche en matière d’interopérabilité, le groupe de travail

a veillé à la cohérence entre le projet de référentiel « architecture et sécurité » et la norme IFM.

À cet égard, il convient tout d’abord de rappeler que :

• la norme IFM porte sur les entités, les rôles et les acteurs d’un système billettique ;

• le référentiel porte sur un sous-ensemble du système billettique, le medium access device

(MAD) au sens d’IFM ou « système d’acceptation billettique » dans la terminologie du

référentiel ; plus précisément, le référentiel porte sur les éléments constitutifs du MAD, ainsi que

sur l’interopérabilité entre le MAD et les autres composants d’un système billettique

interopérable.

La norme IFM et le référentiel sont tous les deux fondés sur le principe de séparation des

responsabilités entre les produits (qui décrivent des droits de transport), les applications (qui portent

ou identifient ces droits), et le support la sécurité.

La norme IFM et le référentiel identifient de manière comparable trois groupes d’équipements :

IFM : composant Référentiel : équipement

Medium / Customer medium Objet portable

Medium Access Device (MAD) Système d’acceptation billettique

Autres (back-office, etc.) Autres systèmes

Le référentiel établit la liste des fonctions du MAD, de façon plus fine que la norme IFM, puis répartit

leur réalisation dans une architecture modulaire. Certaines de ces fonctions intrinsèques au MAD ne

sont pas décrites par la norme IFM, qui se situe au niveau des échanges entre rôles. Inversement,

certains rôles de la norme IFM n’apparaissent pas dans le référentiel, qui ne traite que du MAD.




Page Date

11 / 93

19 mars 2014

Il est cependant possible d’identifier des correspondances entre les modules du référentiel et

certaines des entités de la norme IFM, responsables de ces modules, comme indiqué dans le tableau

ci-dessous :

Module du référentiel1 Entité IFM2 Observations

M.PO Commandes Passerelle vers les objets

portables

Application

Owner Fonction technique standard

M.SECU Sécurité

billettique

Traitements cryptographiques

liés aux opérations billettiques

Application

Owner

L’entité Security Manager de la

norme IFM gère l’établissement et

coordination de la politique de

sécurité

M.APP Accès à

l’application

Lecture et écriture des

données de l’application

Application

Owner

M.MOD Modèle de

données

Gestion de structures de

données billettique

Product

Owner Par exemple : Intercode

M.TRF Règles

tarifaires

Application des règles

commerciales aux structures

de données billettiques

Product

Owner

M.MGR Gestion

applicative

Orchestration des modules de

l’équipement N.A.

M.MSG Expédition-

réception

Échange de données

d’exploitation avec d’autres

composants du système

billettique

N.A.

L’entité Collection and Forwarding

de la norme IFM gère les

échanges entre systèmes

billettiques

M.MMI Interface

utilisateur

Accès aux dispositifs

d’interaction avec les

utilisateurs

N.A.

M.ADM Administration Administration des modules N.A. Mises à jour, etc.

Le point fondamental à relever est qu’un module du MAD n’est jamais en correspondance avec

plusieurs entités IFM : cela signifie que le découpage en modules proposé par le référentiel est

cohérent avec la répartition des rôles décrite par IFM. Ce constat confirme également la validité du

découpage en modules proposé dans le référentiel.

Le référentiel s’analyse donc comme un approfondissement d’IFM portant sur le MAD. Établi en

respectant la répartition des rôles décrite par IFM, il complète la cette norme sur l’une des parties du

système billettique, le MAD, qui joue un rôle central dans la recherche de produits et de solutions

économiques, évolutives et interopérables.

1 Pour une présentation générale des modules, voir le chapitre 5.2.

2 Selon la figure 2 de la norme ISO 24014-1 :2007.




Page Date

12 / 93

19 mars 2014

2.2 Présentation de l’AFIMB

Opérationnelle depuis début 2011, l’Agence française pour l’information multimodale et la

billettique (AFIMB) est chargée notamment de promouvoir l’interopérabilité dans les domaines de

l’information multimodale et de la billettique, et de soutenir la normalisation dans ces domaines.

Rattachée à la Direction générale des infrastructures, des transports et de la mer (DGITM), l’agence

s’appuie sur l’expertise de la Mission des transports intelligents, du Centre d'études sur les réseaux,

les transports, l'urbanisme et les constructions publiques (CERTU) et des Centres d’études

techniques de l’équipement (CETE).

Elle s’appuie sur un comité d’orientation composé de représentants des autorités organisatrices de

transports, des opérateurs de transport, des usagers et des ministères concernés.

Sphère billettique

Le comité d’orientation de l’AFIMB a souhaité la mise en place d’un comité billettique comprenant des

représentants des domaines du transport, de la téléphonie mobile et du paiement électronique.

Ce comité a adopté une démarche d’ensemble, répondant aux demandes exprimées par les autorités

organisatrices de transports (AOT) :

• il s’agissait tout d’abord de définir les scénarios d’interopérabilité, en partant d’une évaluation

des besoins des usagers et en décrivant les solutions à apporter, qui pourront s’appuyer sur

des cartes transport, des téléphones mobiles NFC ou des cartes bancaires sans contact3.

Sur ce point, le comité billettique a conclu à l’intérêt d’une application billettique commune

(« ABC ») aux autorités organisatrices et permettant notamment aux usagers occasionnels4

d’acheter des titres courants tels que trajet unique, forfaits pour un ou plusieurs jours, aller-

retour aéroports-centre ville. On pourra ainsi se déplacer partout, dans tous les territoires NFC,

avec une même application sur un téléphone mobile NFC ou une carte sans contact.

L’appel à projets « déploiement de services mobiles sans contact NFC » lancé dans le cadre du

Fonds pour la société numérique a offert l’opportunité d’une mise en œuvre concrète de ce

projet.

• sachant que le déploiement de cette solution nécessite la mise à niveau des systèmes

d’acceptation billettique, il s’est agit ensuite de définir le référentiel technique à prendre en

compte lors de ces mises à niveau.

L’élaboration de ce référentiel technique est menée dans trois groupes de travail :

- « référentiel sans contact », chargé de définir les conditions techniques permettant

d’assurer la bonne communication par induction entre les systèmes d’acceptation

billettique et les objets portables sans contact, en particulier les téléphones mobiles NFC ;

3 À la publication de ce référentiel, quelques divergences d’exigence ou de plan de test sur le protocole sans contact existent entre les normes ISO et le standard EMV. Il est considéré que ces divergences seront résolues dans un délai compatible avec la période d’application de ce référentiel. Dans la suite du document, ces divergences ne sont donc pas prises en compte.

4 La pertinence d’une éventuelle mise en service d’objets portables de courte durée de vie dépend de la notion d’usager occasionnel (qui doit faire la part des usages exceptionnels et des usages récurrents, pour lesquels la distribution d’un objet portable pérenne est envisageable), du coût global de distribution des objets portables, et de la politique de contribution financière par le client lors de la délivrance de l’objet portable.




Page Date

13 / 93

19 mars 2014

ce référentiel et un plan de test associé ont été rédigés, et proposés au CEN en vue de la

réalisation d’une norme européenne ;

- « application billettique commune », faisant suite au groupe « scénarios d’interopérabilité

», en vue d’une mise en place concrète de cette application ;

- « architecture et sécurité », chargé de proposer une architecture évolutive des systèmes

d’acceptation billettique, permettant de faciliter l’intégration des schémas de sécurité

induits par l’acceptation de nouvelles applications billettiques ou de paiement.




Page Date

14 / 93

19 mars 2014

2.3 Audience et applicabilité du document

Le présent référentiel « architecture et sécurité » est destiné aux administrateurs, utilisateurs et

fournisseurs de systèmes billettiques :

• autorités organisatrices de transports, et leurs AMO ;

• exploitants de transports ;

• fournisseurs de systèmes billettiques, et de leurs composants (matériels ou logiciels).

Ce référentiel peut s’appliquer à tous les réseaux de transports, français ou non, qui envisagent de

mettre en place un système billettique, ou de faire évoluer un système billettique existant, dans les

cinq à dix ans à venir.

C’est un document auquel peuvent faire référence les appels d’offre comportant des systèmes

d’acceptation billettique.

2.4 Cycle de vie du document

Ce référentiel a été produit par le groupe de travail « architecture et sécurité » des systèmes

d’acceptation billettique, en coordination avec les autres groupes de travail de l’AFIMB dédiés à la

billettique.

Il est conçu pour rester pertinent pendant plusieurs années, mais du fait de l’émergence probable de

nouvelles technologies, l’AFIMB le réévaluera périodiquement. Le cas échéant, l’AFIMB en publiera

donc des révisions.

Les suites qui seront données à ce référentiel sont présentées au chapitre 8.

2.5 Publication

Le présent référentiel est publié sous forme électronique, au format ISO 19005-1:2005 (également

nommé « PDF 1.4 » et « PDF/A-1 »).

Il est disponible au téléchargement sur le site web de l’AFIMB :

http://www.developpement-durable.gouv.fr/-Agence-francaise-pour-l-.html

Mention légale

Tous les noms commerciaux et marques cités dans ce document sont déposés et sont la propriété

exclusive de leurs déposants.

http://www.developpement-durable.gouv.fr/-Agence-francaise-pour-l-.html




Page Date

15 / 93

19 mars 2014

3 VUE D’ENSEMBLE

3.1 Système d’acceptation billettique

Dans les systèmes billettiques actuels, dans la plupart des cas les équipements traitant des objets

portables sont autonomes (sans échange d’informations avec d’autres systèmes pendant ce

traitement) : valideurs, terminaux portables de contrôle, terminaux de point de vente, automates de

vente, etc. Ils sont généralement nommés « terminaux billettiques » ou plus simplement

« terminaux ».

Afin de rendre ces systèmes aussi universels que possible, certaines de leurs fonctions peuvent

parfois être déplacées vers des équipements distants, par exemple un système central.

Dans le présent référentiel, « système d’acceptation billettique » recouvre l’ensemble des

composants matériels et logiciels mis en œuvre pendant le traitement d’un objet portable. Le terme

« terminal » désigne exclusivement l’équipement en relation directe avec l’objet portable (celui qui

réalise matériellement la communication avec l’objet portable).

Par exemple :

• la partie d’un portillon d’accès qui réalise une transaction de contrôle d’accès avec un objet

portable, sans échange de données avec un autre équipement pendant la transaction, constitue

un système d’acceptation billettique ;

• lors d’une transaction de vente à distance, sont considérés comme constituant le système

d’acceptation billettique tous les composants matériels et logiciels mis en œuvre dans :

- l’équipement distant,

- le terminal,

- les moyens de communication entre eux.

• téléphone mobile NFC :

- en mode d’émulation carte, l’interface sans contact d’un téléphone mobile NFC est

considérée comme faisant partie de l’objet portable et non du système d’acceptation

billettique ;

- dans toutes les autres utilisations billettiques (consultation locale, transaction OTA, mode

terminal, etc.), lorsqu’un téléphone mobile NFC accède à un de ses propres secure

elements ou à d’autres objets portables, il constitue une partie (voire la totalité) du

système d’acceptation billettique.

Un système d’acceptation billettique interagit avec trois familles d’interlocuteurs :

• les objets portables ;

• les utilisateurs ;

• d’autres systèmes, généralement distants.




Page Date

16 / 93

19 mars 2014

3.2 Objet portable

3.2.1 Types et données

Les systèmes d’acceptation billettique accèdent aux données présentes dans un équipement en

possession des voyageurs, l’objet portable sans contact, qui matérialise la relation entre l’opérateur

de transport et son client.

Il existe principalement deux types d’objet portables utilisés en billettique :

• les cartes à puce sans contact, et les produits assimilés (qui ne possèdent pas de source

d’énergie) ;

• les équipements électroniques portables munis d’une interface NFC, tels que les téléphones

mobiles NFC.

Ces objets portables peuvent contenir des données de différentes natures :

Données Fonction

Identifiants

Différencier les voyageurs, corréler les voyages

Les identifiants ne sont généralement pas directement associés aux voyageurs,

afin de préserver leur vie privée

Données billettiques Permettre à des systèmes d’acceptation billettique de réaliser des traitements

sans communication avec d’autres systèmes (pendant ces traitements)

Données de sécurisation Garantir la légitimité des traitements

L’architecture des systèmes d’acceptation billettique et les données présentes dans les objets

portables sont interdépendants, les choix pour l’un conditionnant les choix pour l’autre.

3.2.2 Secure element

Lorsque l’objet portable contient des données de sécurisation secrètes, il comporte une partie dotée

de ressources matérielles assurant la protection de ces secrets : le secure element.

Une carte à puce sans contact à micro-processeur, telle qu’une carte Calypso, est elle-même un

secure element.

Un téléphone mobile NFC peut comporter plusieurs secure elements utilisables via l’interface NFC :

• la carte à puce de l’opérateur téléphonique ;

• une carte à puce solidaire du téléphone ;

• un dispositif amovible contenant lui-même une carte à puce, telle qu’une carte « SD » ou

« MicroSD ».

3.2.3 Application

Lorsque les données de l’objet portable utilisées par les systèmes d’acceptation billettique sont

contenues dans un secure element, elles sont issues d’une application, telle que définie par les

normes ISO/IEC 7816-4 et ISO/IEC 7816-5.




Page Date

17 / 93

19 mars 2014

Au sein d’un secure element, l’application réalise l’isolation sécurisée des ressources (données,

algorithmes, etc.).

Son utilisation est contrôlée par des secrets sous la responsabilité de l’émetteur de l’application.

Son administration est contrôlée par des secrets sous la responsabilité de l’émetteur du Secure

Element hôte.

Émission d’une application

Une application peut être intégrée dans un objet portable sans contact lors de sa fabrication (cas des

cartes sans contact), ou ajoutée à un secure element après son émission (cas d’une cardlet

téléchargée dans le secure element d’un téléphone mobile NFC).

Le secure element hôte peut être émis par l’émetteur de l’application, ou partagée par plusieurs

services (par exemple par un autre AOT ou par un émetteur hors du domaine du transport).

L’application peut être dédiée à un service, ou partagée par plusieurs services. Une application émise

par un tiers peut se trouver dans un secure element dédié, et une application dédiée peut se trouver

dans un secure element émis par un tiers.

Référentiel

Ce référentiel considère a priori que les données des objets portables sont dans une application

(donc dans un secure element). S’il y a lieu, des indications particulières sont données pour

l’acceptation d’autres types d’objets portables.

3.2.4 Application billettique

Une application qui est dédiée à la billettique, soit du fait de ses fonctionnalités intrinsèques, soit par

l’utilisation qui en est faite, est qualifiée d’application billettique.

Pour la France, l’AFNOR a normalisé le nom (« AID ») de l’application billettique de chaque réseau

de transport.

3.2.5 Calypso

Le standard Calypso décrit les fonctionnalités d’une application spécifiquement conçues pour

répondre aux contraintes de la billettique : vitesse de transaction, sécurité, et coût du support. Il ne

préjuge pas des données stockées dans l’application et peut ainsi être utilisé dans d’autres domaines

que la billettique5.

La plupart des réseaux de transports français, ainsi que de nombreux réseaux étrangers, ont mis en

place un système billettique acceptant des cartes Calypso Revision 1 ou Revision 2.

Le standard est actuellement en Revision 3.

5 Par conséquent, c’est l’utilisation d’une application Calypso pour le transport public qui en fait une application billettique, et non ses fonctionnalités intrinsèques.




Page Date

18 / 93

19 mars 2014

3.2.6 Triangle

La spécification Triangle décrit une application Calypso Revision 3 qu’il est possible de partager entre

de nombreux fournisseurs de services, en particulier billettiques, grâce à un enrobage par des

données interopérables des données spécifiques à chaque service, et à des contrôles réalisés par les

SAM sur les données interopérables.

3.2.7 Application billettique commune (ABC)

L’AFIMB propose aux réseaux français de gérer l’interopérabilité interrégionale, et éventuellement

internationale, avec une application billettique partagée appelée application billettique commune ou

ABC. Elle permet aux usagers occasionnels d’acquérir et d’utiliser des titres de transport courants

d’un réseau différent de celui ayant émis l’ABC.

L’ABC est une application Triangle.

3.3 Autres systèmes

Des systèmes tiers, souvent distants, supervisent le fonctionnement des systèmes d’acceptation

billettique. Ils leur fournissent les éléments logiciels (programmes et données) qui permettent

d’interagir avec les utilisateurs conformément à la définition commerciale des titres de transport. En

retour, ils obtiennent les données nécessaires à la vérification des opérations réalisées et à

l’administration du réseau.

Ces autres systèmes sont généralement des systèmes centraux, mais les évolutions actuelles des

réseaux informatiques rendent possible l’utilisation de systèmes distribués, en particulier à l’horizon

de cinq à dix ans.

3.4 Utilisateurs

Les utilisateurs des systèmes d’acceptation billettiques sont les voyageurs, les opérateurs pour les

équipements qui le nécessitent (par exemple pour les guichets), et les agents de maintenance.

La richesse de l’interface utilisateur est très variable, de quelques signaux lumineux et sonores pour

un valideur à un système écran/clavier/souris/haut-parleur.




Page Date

19 / 93

19 mars 2014

4 DESCRIPTION FONCTIONNELLE

4.1 Fonctions principales

Les fonctions principales d’un système d’acceptation billettique sont :

• mettre en relation le client et le système billettique, par l’intermédiaire de l’objet portable en

possession du client (dont l’application matérialise les contrats commerciaux avec l’exploitant) ;

• fournir au système billettique les informations relatives à l’utilisation des transports et utiles pour

leur exploitation.

Ces fonctions sont réalisées par l’utilisation de données décrivant les droits de transport accordés

légitimement aux clients (par exemple en échange d’un paiement6), dont des données d’utilisation.

L’application contient les informations permettant de l’associer aux contrats commerciaux qu’elle

matérialise. Selon l’architecture utilisée, les droits de transport eux-mêmes peuvent être stockés dans

l’application (cas d’une application billettique) ou dans une autre partie du système.

4.2 Conditions

4.2.1 Présentation

Les objectifs des systèmes d’acceptation billettique doivent être réalisés sous certaines contraintes

limitant la liberté de choix d’implémentation, ici nommées « conditions » :

• capacité à traiter tous les types d’objet portable, de secure element, d’application et de droits de

transport envisageables :

- cartes billettiques sans contact ;

- téléphones mobiles NFC ;

- autres types d’objets portables (cartes bancaires sans contact, etc.).

• garantir la confiance dans le système, par la capacité à gérer les procédures de sécurité

définies, dont :

- authenticité de l’application7, des données qu’elle contient, et des actions qu’elle réalise ;

- authenticité des données échangées avec un autre système ;

- non-répudiation des opérations réalisées ;

- confidentialité des données relatives à la vie privée (selon les recommandations de la

Cnil) ;

6 Dans certains cas, des droits de transport peuvent être accordés sans paiement par le client, par exemple conformément à la mission confiée à l’exploitant par l’AOT, ou dans le cadre d’une offre commerciale (fidélisation, etc.).

7 L’authenticité d’un secure element est contrôlée lors de l’installation de l’application dans ce secure element, elle est hors du périmètre de ce référentiel.




Page Date

20 / 93

19 mars 2014

- confidentialités des données d’exploitation stratégiques.

• pérenniser les investissements déjà réalisés, par exemple permettre le fonctionnement hors

ligne, pour les réseaux dont l'infrastructure informatique n'est pas adaptable à la généralisation

des opérations à distance ;

• favoriser l’évolutivité, et l’efficacité budgétaire, par la capacité d’utilisation de sous-systèmes

(matériels et logiciel) aussi génériques que possible, et ce pendant toute la vie de

l’équipement ;

• faciliter l’accès à l’offre pour les clients (par exemple, traiter les applications n’étant pas

associées par le système billettique à un client, ce qui permet l’émission d’applications sans

procédure d’enrôlement).

4.2.2 Sécurité

La réussite d’une attaque contre un système billettique pourrait avoir de graves conséquences

financières, mais également nuire gravement à l’image et à la réputation pour tous les intervenants du

système : les fournisseurs des technologies mises en œuvre, les fournisseurs d’équipements, les

exploitants de transports, les autorités organisatrices et également les élus.

Afin de limiter ces risques, de sorte que les clients et les AOT aient confiance dans le système

billettique, ce système doit être suffisamment protégé. La sécurité est l’outil qui assure cette

confiance.

Dans un système d’acceptation billettique, les fonctions de la sécurité sont principalement :

• garantir que les droits de transport (contrats, droits à réduction) ont été légitimement acquis ;

• assurer la confidentialité (vie privée, étanchéité entre partenaires d’interopérabilité) ;

• protéger contre l’évasion financière.

Plus les applications et leurs données sont interopérables, plus le risque est grand : ils sont plus

faciles d’accès, et il est plus intéressants de les attaquer. Pour réduire ces risques, il convient alors

de renforcer les moyens de protection ou de réduire l’intérêt d’une attaque (diminuer la valeur

associée, améliorer les moyens de détection d’attaques, accroître la pression culturelle/sociale,

augmenter la répression).

Toute application billettique doit être utilisée conformément à son niveau de sécurité. Par exemple,

dans l’ABC (dont l’interopérabilité est internationale car elle se base sur Triangle) une AOT peut

décider de ne pas stocker de droits de transport de valeur élevée (abonnement annuel, etc.), mais

uniquement des droits de transport de faible valeur et à courte échéance (forfait valable uniquement

le jour de son achat, etc.).

4.2.3 Interopérabilité

Pour un voyageur, l’interopérabilité est la capacité à voyager sur plusieurs réseaux, l’interopérabilité

idéale consistant à pouvoir voyager « n’importe où » (sous réserve de disposer des droits de

transport correspondants).




Page Date

21 / 93

19 mars 2014

Cette interopérabilité fonctionnelle est réalisée par les interopérabilités commerciales et techniques

décrites ci-après :

• interopérabilité de l’offre : concerne les droits de transport valides pour tous les moyens de

transport du bassin (ou à un sous-ensemble quelconque). En général c’est l’acceptation d’une

offre interopérable qui définit un bassin d’interopérabilité. La définition d’une offre interopérable

n’est pas dans le périmètre du présent document.

• interopérabilité des objets portables :

- les objets portables, leurs secure elements, leurs applications et leurs données doivent

pouvoir être traités par tous les systèmes d’acceptation billettique du bassin ;

- leurs mécanismes de mise en service doivent être aussi génériques que possible ;

- chaque type d’objet portable mis en œuvre dans le bassin peut n’être adapté qu’à une

partie de l’offre interopérable.

• interopérabilité des équipements : les systèmes d’acceptation billettique d’un même type

(valideur, automate de vente, etc.) doivent pouvoir :

- traiter tous les types d’objets portables (secure elements, applications et données)

susceptibles de matérialiser des droits de transport interopérables quelconques ;

- être utilisés de façon similaire par les clients ;

- être administrés par des mécanismes compatibles entre eux.

• interopérabilité des systèmes centraux : les systèmes centraux des exploitants doivent pouvoir

s’échanger les données nécessaires à la gestion globale du réseau du bassin. Cette

interopérabilité n’est pas dans le périmètre du présent document.

Pour l’objectif d’universalité des équipements, et de maîtrise des coûts, l’interopérabilité peut

également s’appliquer aux composants d’un système d’acceptation billettique. Par exemple :

• l’API de gestion du modèle de données Intercode peut être une librairie identique dans tous les

composants qui utilisent ce modèle de données ;

• la gestion de composants logiciels (suivi des versions, distribution des mises jour, etc.) peut

être rendue interopérable par utilisation de mécanismes génériques (tels que ceux définis par

l’OSGi Alliance).

Interopérabilité des systèmes d’acceptation billettique

L’interopérabilité des systèmes d’acceptation billettique avec les objets portables peut être réalisée

par les systèmes d’acceptation billettique, qui acceptent dans ce cas tous les types d’objet portable

existant dans le bassin d’interopérabilité. En cas d’extension du bassin d’interopérabilité, les

systèmes d’acceptation billettique sont mis à jour (ou de nouveaux systèmes d’acceptation billettique

sont mis en service). Cette solution n’est pas favorable à l’optimisation du coût car elle accroît le

nombre de mises à jour.

Par ailleurs, les systèmes d’acceptation billettique se doivent d’être interopérables entre eux, afin de

permettre l’interchangeabilité : un équipement ou un logiciel doit pouvoir être remplacé par celui d’un

autre fournisseur le plus facilement possible.




Page Date

22 / 93

19 mars 2014

Ce référentiel promeut une interopérabilité maximale des systèmes d’acceptation billettique, y

compris pour les composants, afin de favoriser l’optimisation des coûts.

Interopérabilité des objets portables

L’interopérabilité des systèmes d’acceptation avec les objets portables peut être réalisée par des

objets portables sans contact communs à tous les voyageurs, traités de la même façon par tous les

systèmes d’acceptation billettique du bassin d’interopérabilité. En cas d’extension du bassin

d’interopérabilité, de nouveaux objets portables sont émis pour les nouveaux voyageurs (ou les objets

portables existant sont mis à jour). Cette solution favorise l’optimisation du coût des systèmes


L’objet portable sans contact interopérable doit être facilement disponible :

• carte émise par une AOT ;

• objets portables de portée au moins nationale, émis hors du domaine transport :

- téléphone mobile NFC ;

- carte bancaire ;

- autre type de support générique qui serait disponible dans les cinq à dix ans.

Pour assurer un niveau de sécurité minimum dans les échanges avec l’objet portable, la mise en

œuvre de mécanismes de sécurité nécessite l’utilisation d’un secure element hébergeant une

application interopérable, et d’un jeu de données minimum. L’ABC est dédiée à cet usage

interopérable, mais d’autres solutions peuvent être envisagées de manière complémentaire.

Diversité des systèmes billettiques

Les systèmes billettiques actuellement opérationnels sont très variés, en particulier au niveau

international. Cela est en partie dû a un déficit de normes internationales, à la diversité des standards

disponibles (Calypso, ITSO, VDV, etc.), et à la diffusion de technologies non standard.

L’interopérabilité peut donc difficilement se baser uniquement sur les systèmes d’acceptation

billettiques (du fait de la grande diversité des systèmes billettiques existant), un objet portable

interopérable s’avèrera donc certainement nécessaire.

Les objets portables émis par les AOT françaises, et surtout étrangères, étant très différents les uns

des autres, les vecteurs d’interopérabilité envisagés sont :

• une application normalisée au niveau européen (à la publication de ce référentiel, ce type de

norme n’existe pas, mais est étudié par exemple pour une future évolution de la norme IFM) ;

• à défaut, une application normalisée par un pays européen, telle que l’ABC ;

• à défaut, une application émise hors du domaine transport.

Dans ce contexte, il est à noter que la norme IFM décrit actuellement une interopérabilité limitée à

des objets portables contenant une pluralité d’applications spécifiques à chaque partenaire de

l’interopérabilité.




Page Date

23 / 93

19 mars 2014

Conformité aux normes et standards

Dans la mesure du possible, les équipements doivent, au moment de leur mise en service, être

conformes aux normes et standards en vigueur :

• normes internationales : ISO/IEC 7816-4, ISO/IEC 14443, ISO/IEC 18092 et ISO/IEC 21481

(NFC), etc. ;

• en l’absence de normes internationales, normes nationales : Intercode, Intertic, etc. ;

• en l’absence de normes, standards usuels appropriés qui s’appuient sur des normes : Calypso,

Triangle, etc.

Le référentiel sans contact publié par l’AFIMB, et le plan de test associé, garantissent la capacité des

systèmes d’acceptation billettiques et des objets portables à communiquer entre eux.

4.2.4 Évolutivité

L’évolutivité est la capacité à modifier certaines parties d’un système sans le remettre en question.

Il est nécessaire que les systèmes d’acceptation billettique puissent s’adapter aux évolutions :

• des normes et standards liés à la billettique (Calypso, Intercode, IFM, etc.) ;

• des technologies « universelles » : cryptographie (AES, crypto. symétrique), communications

sans fil, etc. ;

• des usages (paiement au valideur, vente à distance, liste « verte », etc.) ;

• des offres commerciales.

Limitation des évolutions

Pour permettre l’introduction dans un système billettique de nouveaux composants matériels ou

logiciels sans nécessiter de modification préalable des autres composants, il faut s’assurer que les

nouveaux composants seront indiscernables des anciens par les équipements existants. La mise à

jour des équipements existants ne sera alors réalisée que lorsqu’il sera nécessaire de mettre en

œuvre les nouvelles fonctionnalités.

Pour favoriser ce type d’évolution8, les composants du système billettique doivent gérer les cas

inconnus par des traitements par défaut, et non les rejeter a priori. Cette exigence peut être incluse

dans les cahiers des charges émis par les AOT.

Par exemple :

• pour le traitement de l’ABC, les systèmes d’acceptation billettique ne rejettent pas a priori

certains types d’objets portables, car ils supposent que l’ABC n’est présente que dans des

objets qu’ils sont capables de traiter ;

• si la structure de fichiers de l’ABC évolue (la nouvelle structure étant compatible avec

l’ancienne), sa référence Calypso Revision 3 sera inconnue des équipements existants. Ils

devront donc la traiter comme une structure de fichier Triangle par défaut (celle ne comportant

aucune fonctionnalité optionnelle, comme les fichiers T2 Names) ;

8 Qui n’est pas toujours possible, par exemple pour le passage du protocole Innovatron au protocole ISO/IEC 14443.




Page Date

24 / 93

19 mars 2014

• pour admettre le changement de SAM, l’équipement effectue ses traitements en supposant que

le SAM auquel il a accès permet de les réaliser, et ne teste pas a priori le SAM (ce qui suppose

que le nouveau SAM permette effectivement les traitements réalisés par les équipements

existants).

4.2.5 Optimisation des coûts

La réduction des coûts globaux des systèmes d’acceptation billettique, incluant les coûts initiaux, les

coûts de fonctionnement et les coûts de mise à jour, est une exigence forte. Afin de la favoriser, ce

référentiel promeut :

• l’indépendance des AOT vis-à-vis des délégataires de service public : le changement de

délégataire doit pouvoir être fait au meilleur coût (par exemple un éventuel remplacement

d’équipements ou de logiciels de l’ancien délégataire par ceux du nouveau délégataire ne doit

pas avoir d’impact sur les autres équipements ou logiciels) ;

• l’indépendance vis-à-vis des fournisseurs : pour l’approvisionnement d’un système

d’acceptation billettique (ou d’un composant), il doit être possible de mettre en concurrence des

solutions de fournisseurs différents qui ne nécessitent pas d’adaptation spécifique des autres

équipements du système billettique ;

• l’utilisation de solutions conformes aux normes et aux standards, et de solutions issues d’autres

domaines d’activité : c’est un moyen favorisant l’interopérabilité, l’interchangeabilité,

l’indépendance vis-à-vis des fournisseurs, la mutualisation des développements et la

réutilisation (donc la pérennité des investissements).

Pour également favoriser la pérennité des investissements, il est nécessaire que les nouveaux

équipements soient autant que possible à l’état de l’art de la technologie et des standards ou normes.

Cette exigence est potentiellement plus coûteuse initialement, mais elle réduit le risque

d’obsolescence donc de mise à jour.

Évaluation des coûts

Afin de comparer de façon pertinente les différentes architectures proposées dans ce référentiel,

l’évaluation de leur coût précise non seulement la méthode utilisée pour cette évaluation, mais établit

aussi la base de comparaison.

Pérennité et évolution

Du fait des évolutions inévitables évoquées au chapitre 4.2.4, la capacité d’adaptation des systèmes

d’acceptation billettique est un facteur d’optimisation des coûts globaux car elle favorise :

• la réduction des coûts de mise à jour,

• mais également la pérennité de l’investissement initial.

4.2.6 Accessibilité de l’offre

Quel que soit le système billettique mis en place, il doit permettre de voyager sans procédure

complexe d’enrôlement.




Page Date

25 / 93

19 mars 2014

Les architectures de système d’acceptation billettique proposées dans ce référentiel tiennent compte

de cette contrainte.

4.3 Fonctions élémentaires

4.3.1 Introduction

L’objectif de la décomposition d’un système d’acceptation billettique en fonctions élémentaires est de

faciliter l’identification de composants indépendants, ce qui favorise l’évolutivité et l’interchangeabilité.

Les fonctions et les composants ne coïncident pas forcément : une fonction peut être assurée par tout

ou partie d’un ou plusieurs composants, chaque composant pouvant de son côté assurer tout ou

partie d’une ou plusieurs fonctions.

Certaines fonctions réalisées par les systèmes d’acceptation billettique, bien que fortement liées à la

billettique, n’en font pas partie et ne sont donc pas mentionnées dans ce document. Par exemple :

percevoir le paiement des droits de transport.

Applications billettiques

Pour matérialiser le lien entre les droits de transport et le client par un composant matériel, il est

nécessaire d’utiliser un objet portable. L’utilisation d’une application d’un secure element de cet objet

portable permet de sécuriser ce lien.

Malgré les évolutions technologiques qui auront lieu dans les cinq à dix ans, il est probable qu’un

nombre significatif de systèmes billettiques français et étrangers continueront à devoir être capables

de réaliser des transactions billettique sans connexion à un autre système. Ainsi, de nombreuses

applications contenant des droits de transport (ou le droit au transport) seront encore utilisées

pendant plusieurs années, même si d’autres solutions seront également mises en service.

Dans ce référentiel les fonctions liées à l’utilisation d’applications billettiques sont des fonctions

essentielles.

Interopérabilité et interchangeabilité

L’interopérabilité des fonctions, et des composants qui les réalisent, permet la mutualisation de ces

fonctions, de sorte que plusieurs systèmes billettiques indépendants peuvent partager des

composants de systèmes terminaux billettiques. Elle permet également l’interchangeabilité de ces

composants.

Couverture

Les fonctions élémentaires décrites dans les chapitres suivants recouvrent l’ensemble du cycle de vie

des objets portables lors de utilisation par les voyageurs : émission de l’application, chargement de

droits de transport (ou du droit au transport), constatation d’usage (validation) et contrôle.




Page Date

26 / 93

19 mars 2014

4.3.2 Diagramme fonctionnel

Le diagramme ci-dessous présente les familles de fonctions décrites au chapitre suivant, référencées

par la lettre « F » suivie d’un numéro, et leurs principales interactions :

F1Communiquer avec un

composant matériel sécurisé

F2Échanger des commandes

F5Communiquer avec

une application

F3Communiquer avec un SAM

F4Assurer la sécurité des

échanges avec l'application

F7Décoder et encoder les


F10Déterminer les nouvelles


F9Analyser les données

actuelles de l’application

F8Assurer la sécurité des


F14Communiquer avec des

systèmes distantsF13

Acquérir les règles de gestion

F15Superviser un SAM

F16Superviser le système

d’acceptation billettique

F11Interagir avec les utilisateurs

F12Fournir les données de

traitement des droits

F6Gérer la correspondance modèle

de données/structures de données

F17Conserver des données

F18Mettre à disposition les

ressources matérielles

F19Coordonner les fonctions




Page Date

27 / 93

19 mars 2014

4.3.3 Liste des fonctions élémentaires

Le tableau ci-dessous présente des familles de fonctions et des fonctions élémentaires des systèmes

d’acceptation billettique. Certaines peuvent ne pas s’appliquer à toutes les architectures ou à tous les

systèmes.

Réf. Fonction Commentaires ABC

F1 Communiquer avec un composant

matériel sécurisé

Fonctions de communication de plus bas niveau avec

un objet portable ou un SAM9.

Se décline selon chaque technologie de

communication utilisée.

F1.1 Gérer les protocoles ISO/IEC 14443

en tant que lecteur (PCD)

En conformité avec le référentiel sans contact de

l’AFIMB. ABC

F1.2 Gérer le protocole ISO/IEC 7816-3 Utilisé par les équipements accédant à l’objet portable

par ses contacts, et pour l’accès au SAM. -

F1.3 Gérer les protocoles NFC

(ISO/IEC 18092 et ISO/IEC 21481)

Cette fonction est présente dans équipements NFC,

en particulier les téléphones mobiles NFC, mais, sauf

évolution majeure dans les cinq à dix ans, ses

spécificités par rapport aux protocoles ISO/IEC 14443

(mode pair-à-pair, etc.) ne seront pas mises en œuvre

dans les systèmes billettiques.

-

F1.4

Gérer un protocole conforme à une

autre norme (actuelle ou future) qui

pourrait se généraliser dans les cinq

à dix ans, ou un protocole

propriétaire10

Cette fonction est présente en autant d’exemplaires

que de protocoles à traiter. -

F2 Échanger des commandes

F2.1 Échanger des APDU

ISO/IEC 7816-4

Les applications des objets portables et les SAM

communiquent par des échanges d’APDU conformes

à la norme ISO/IEC 7816-4.

ABC

F2.2 Échanger des commandes

propriétaires


que de formats de commandes à traiter. -

F3 Communiquer avec un SAM

Autant de fonctions F3.X différentes sont définies que

de types de SAM à traiter.

Nécessite la mise en œuvre d’échanges d‘APDUs

(F2).

F3.1 Communiquer avec un SAM Calypso ABC

F3.2 Communiquer avec un SAM non

Calypso


que de types de SAM à traiter. -

9 Sauf indication spécifique, dans ce document, le terme SAM désigne indifféremment une carte à puce ou un HSM.

10 Par exemple, pour les communications avec le SAM le protocole rapide « HSP » défini par Calypso.




Page Date

28 / 93

19 mars 2014

F4 Assurer la sécurité des échanges

avec l’application

Organiser les échanges avec l’application (F5), et si

nécessaire avec un SAM (F3), indépendamment de la

structure et de la signification des données

acheminées.

En l’absence d’application, cette fonction s’applique à

l’objet portable.

Pour les objets portables non sécurisés cette fonction

est absente (les fonctions F2 et F5 interagissent sans

intermédiaire).

F4.1 Assurer la sécurité d’une application

Calypso

L’ABC étant conforme aux spécifications Triangle, elle

utilise les mécanismes de sécurité Calypso.

Nécessite l’utilisation d’un SAM.

ABC

F4.2 Assurer la sécurité d’un objet

portable non Calypso


que de types d’objet non Calypso à traiter. -

F5 Communiquer avec une

application

Échanges avec l’application afin de lire et de modifier

ses données, via le secure element.

Autant de fonctions F5.X différentes sont définies que

de types d'applications à traiter.

Nécessite la mise en œuvre d’échanges d‘APDUs

(F2).

Peut nécessiter la mise en œuvre de procédures de

sécurisation (F4).

Se décline selon chaque technologie d’application

utilisée.


l’objet portable.

F5.1 Communiquer avec une application

Calypso


utilise les mécanismes d’accès du standard Calypso. ABC

F5.2 Communiquer avec une application

non Calypso


que de types d’application non Calypso à traiter. -

F6

Gérer la correspondance entre le

modèle de données et les

structures de données de

l’application

Se décline selon chaque combinaison de modèle de

données et de configuration d’application.


l’objet portable.

ABC

F7

Décoder et encoder les données

caractéristiques des droits de

transport

Peut nécessiter la mise en œuvre de procédures de

sécurisation des données caractéristiques des droits

de transport (F8).

Se décline selon modèle de données utilisé.

F7.1

Assurer une sécurité des données

conforme à un autre standard (actuel

ou futur) qui pourrait se généraliser

dans les cinq à dix ans, ou des

données non standard


bénéficie du modèle de données Triangle.

Peut fournir des données à traiter par une autre

fonction F7.X.

ABC

F7.2

Décoder et encoder parmi les

données Intercode de l’application

celles caractéristiques des droits de

transport

Peut être appliquée directement sur les données de

l’application, ou sur les données extraites des

données Triangle (F7.1).

-




Page Date

29 / 93

19 mars 2014

F7.3

Décoder et encoder parmi les

données de l’application celles


transport, conformément à un autre

standard (actuel ou futur) qui

pourrait se généraliser dans les cinq

à dix ans, ou des données non

standard.


que de types de données non Triangle et non

Intercode à traiter.

-

F8

Assurer la sécurité des données


transport

Générer ou vérifier les éléments de données

cryptographiques éventuellement associés aux

données caractéristiques des droits de transport,

indépendamment de leur hôte, si nécessaire en

utilisant un SAM (F4).

Plusieurs de ces fonctions peuvent être utilisées pour

un même jeu de données, par exemple pour des

données élémentaires différentes ou des

encapsulations successives.

F8.1 Assurer la sécurité des données

Triangle

L’ABC étant conforme aux spécifications Triangle, ses

données bénéficient de la sécurité des données

Triangle.

Nécessite la mise en œuvre d’un SAM Triangle11.

ABC

F8.2 Assurer la confidentialité des

données privées

Protéger les données billettiques relatives à la vie

privée contre tout accès non autorisé, conformément

aux exigences des autorités publiques (la CNIL pour

la France).

Peut nécessiter la mise en œuvre d’un SAM.

-

F8.3

Assurer une sécurité des données

conforme à un autre standard (actuel

ou futur) qui pourrait se généraliser

dans les cinq à dix ans, ou des

données non standard


que de types de données non Triangle à traiter.

Ces données peuvent être encapsulées dans les

structures Triangle.

-

F9

Analyser les données actuelles


transport

À partir des données caractéristiques des droits de

transport (décodés par F7), déterminer les actions

autorisées ou non (selon celle possibles pour le

système d’acceptation billettique considéré).

F9.1 Analyser localement les droits de

transport

Mise en œuvre lorsque :

- l’application contient la totalité des droits de

transport, et

- le terminal est un système d’acceptation billettique

(il possède les ressources permettant d’analyser les

droits de transport).

-

F9.2 Analyser localement le droit au

transport

Mise en œuvre lorsque l’application contient la

description du droit au transport.

Le terminal n’est pas un système d’acceptation

billettique (il ne possède pas les ressources

permettant d’analyser les droits de transport) mais il

possède néanmoins les ressources permettant

d’analyser le droit au transport.

-

11 Un SAM Triangle est un SAM Calypso contenant au moins les clés et paramètres définis par les spécifications Triangle. En général, il contient également les clés et paramètres permettant de gérer l’application locale.




Page Date

30 / 93

19 mars 2014

F9.3 Analyser à distance les droits de

transport

Mise en œuvre lorsque le terminal ne réalise aucun

traitement sur les données de l’application (ce n’est

pas un système d’acceptation billettique).

Les droits de transport peuvent être référencés par

exemple par identification de l’application.

-

F10

Déterminer les nouvelles données


transport

Détermination des nouvelles données caractéristiques

des droits de transport, à inscrire dans l’application

(après encodage par F7).

Cette fonction n’est présente que lorsque que le

système d’acceptation billettique modifie les données

de l’application.

F10.1 Déterminer les droits de transport

Mise en œuvre lorsque l’application contient les

données décrivant complètement les droits de

transport.

Par exemple :

- Locale : valideur ou automate de vente qui traite

immédiatement et sans connexion une application

contenant des données Intercode ; le terminal est

un système d’acceptation billettique.

- Distante : télédistribution dans une application

contenant des données Intercode de droits calculés

dans un système distant (le terminal ne possède

pas toutes les ressources permettant de déterminer

les données décrivant complètement les nouveaux

droits de transport).

-

F10.2 Déterminer le droit au transport

Mise en œuvre lorsque l’application contient la

description du droit au transport.

Par exemple :

- Locale : modification par un téléphone mobile NFC

des données en écriture libre de l’ABC contenue

dans la SIM (ou dans un autre secure element du

téléphone), après lecture d’une étiquette NFC ; pour

cette fonction le terminal est un système


- Distante : modification à distance des données

sécurisées de l’ABC contenue dans la SIM (ou dans

un autre secure element) du téléphone mobile NFC,

suite à la prise en compte par le système billettique

de la dernière validation par lecture d’étiquette

NFC, car le terminal ne possède pas toutes les

ressources permettant de déterminer la description

du nouveau droit au transport.

-

F11 Interagir avec les utilisateurs

Fonctions utilisant l’IHM des équipements locaux

(hormis l’interface de communication avec l’objet

portable) : voyants, écran, clavier, buzzer, portillon,

etc.

F11.1 Rendre universelle la gestion des

dispositifs d’IHM

Interface locale avec les dispositifs d’IHM, de sorte

que les fonctions de plus haut niveau (F11.2 et F11.3)

soient autant que possible indépendantes du matériel.

-

F11.2 Émettre des messages et des

actions vers l’utilisateur.

Texte, élément graphique, voyants, sons, vibrations,

portillon, etc. -

F11.3 Acquérir des messages et des

actions de l’utilisateur. Texte, boutons, etc. -




Page Date

31 / 93

19 mars 2014

F12 Fournir les données de traitement

des droits

Fournir les données qui décrivent les opérations

effectuées avec les objets portables, et qui permettent

de contrôler à posteriori l’utilisation des droits de

transport et également l’utilisation des transports.

F12.1 Collecter et agréger les données

caractéristiques des transactions

Les données caractéristiques des transactions

proviennent des données lues (F9) et inscrites (F10)

dans l’application.

-

F12.2 Sécuriser les données collectées

Si nécessaire, ajout d’éléments de sécurisation aux

données agrégées.

Peut nécessiter l’utilisation d’un SAM (F3, lien non

représenté dans le diagramme fonctionnel).

-

F12.3 Fournir des données de traitement

des droits

Gestion de la transmission des données, de leur

acquittement, et de leur suppression du système


Le destinataire des données peut être local ou distant,

selon l’architecture du système d’acceptation

billettique.

-

F13 Acquérir les règles de gestion

Obtenir les données qui conditionnent les traitements

réalisés avec les objets portables : règles tarifaires,

listes noires, listes de télédistribution, etc.

F13.1 Recevoir des données de gestion

Gestion de la transmission des données, de leur

acquittement, et de la suppression d’éventuelles

anciennes données.

Le fournisseur des données peut être local ou distant,


billettique.

-

F13.2 Sécuriser les données de gestion

reçues

Si nécessaire, vérification d’éléments de sécurisation

inclus aux données reçues.

Peut nécessiter l’utilisation d’un SAM (F3, lien non

représenté dans le diagramme fonctionnel).

-

F13.3 Distribuer les données de gestion

reçues

Mettre les données de gestion reçues à disposition

des fonctions traitant les données lues (F9) et inscrites

(F10) dans l’application.

-

F14 Communiquer avec d’autres

systèmes

Selon l’architecture choisie cette fonction peut être

mise en œuvre par n’importe quelle autre fonction du


F14.1

Établir et maintenir une connexion

avec un ou plusieurs autres

systèmes

Utilisation de solutions standard de communications

informatiques (ATM, TCP/IP, Ethernet, SSL, Wifi, FTP,

HTTP, SOAP, etc.).

-

F14.2 Sécuriser les communications avec

les autres systèmes

Utilisation de solutions standard de sécurisation de

communications informatiques (SSL, VPN IPSec,

etc.).

-

F15 Superviser le SAM

Selon l’architecture retenue, cette fonction peut ne pas

être mise en œuvre.

Met en œuvre les communications avec le SAM (F3).

F15.1 Mettre en service le SAM

Si le composant matériel qui héberge le SAM réalise

sa mise en service à l’aide de données échangées

avec un système distant pendant l’opération, il est

possible que ces données soient sensibles et ne

doivent pas être conservées.

-




Page Date

32 / 93

19 mars 2014

F15.2

Acquérir dans le SAM des données

d’administration et les mettre à

disposition d’autres fonctions

Le destinataire des données peut être local ou distant,


billettique.

Peut concerner par exemple :

- Des éléments d’identification.

- Des constatations d’utilisation.

- Des informations sur les données de mise en

service.

- Des informations sur les clés secrètes.

-

F15.3 Recevoir et inscrire dans le SAM des

données d’administration

Le fournisseur des données peut être local ou distant,


billettique.

Peut concerner par exemple :

- Des limitations d’utilisation.

- Des données de mise en service.

- Des clés secrètes.

-

F16 Superviser le système

d’acceptation billettique

Gestion technique du système d’acceptation billettique

ou de ses modules.

Utilise des solutions standard (OSGi, etc.).

Peut être répartie dans chaque module.

F16.1

Acquérir et transmettre des données

d’administration du système

d’acceptation billettique ou de ses

modules

-

F16.2

Recevoir et mettre en service de

nouveaux paramètres de

fonctionnement du système

d’acceptation billettique ou de ses

modules

-

F16.3

Recevoir et mettre en service de

nouveaux composants logiciels du

système d’acceptation billettique ou

de ses modules

-

F17 Conserver des données

volumineuses

Stocker pour une durée indéterminée des données

relativement volumineuses (par exemple des listes

noires ou des rapports d’activité), en résistant aux

ruptures d’alimentation.

-

F18 Mettre à disposition les

ressources matérielles

Ensemble d’API fournissant aux modules logiciels un

accès au ressources matérielles du système


-

F19 Coordonner les fonctions Orchestrer des fonctions du système d’acceptation

billettique. -

À chaque fonction est associé un indicateur de nécessité pour l’interopérabilité via l’ABC (colonne

« ABC »), définie selon le tableau suivant :

Code Niveau de nécessité

- Fonction sans relation directe avec l’ABC.

ABC Fonction nécessaire au traitement de l’ABC.




Page Date

33 / 93

19 mars 2014

5 MODULES, SERVICES ET INTERFACES

5.1 Principes

5.1.1 Domaine billettique

Tel que défini dans le présent référentiel, le périmètre d’un système d’acceptation billettique délimite

les traitements effectués lors d’une opération mettant en œuvre un objet portable. Certains de ces

traitements sont réalisés par des modules génériques, qui ne sont pas liés à la billettique (par

exemple le système d’exploitation). Les modules qui réalisent les traitements spécifiques à la

billettique, sont regroupés dans le domaine billettique12.

Tous les modules du domaine billettique communiquent entre eux par des services web (voir chapitre

5.1.3). Pour les interactions avec les modules externes au domaine billettique ils peuvent également

utiliser des interfaces (voir chapitre 5.1.4).

Le domaine billettique et le périmètre billettique recouvrent deux concepts différents. En effet, un

périmètre billettique délimite les éléments spécifiques à un bassin d’interopérabilité. Par exemple,

dans un système d’acceptation billettique pouvant traiter plusieurs périmètres billettiques, des

modules du domaine billettique peuvent être communs à des périmètres billettiques.

5.1.2 Modules

La modularité des composants d’un système d’acceptation billettique favorise l’interopérabilité,

l’interchangeabilité, la mutualisation, l’indépendance vis-à-vis des fournisseurs, la mise en

concurrence des fournisseurs, l’apparition d’une offre de modules et d’équipements génériques, et

par conséquent la réduction des coûts globaux.

L’administration des modules logiciels, par exemple selon le standard OSGi, est une fonction elle-

même assurée par un module logiciel.

Dans ce référentiel, chaque module interne au domaine billettique d’un système d’acceptation

billettique est identifié par une référence composée de la lettre « M » suivie d’un point et d’un code

mnémonique de quelques lettres (par exemple, « M.SECU »).

5.1.3 Services

Afin de favoriser l’interchangeabilité et l’évolutivité des modules qui les composent, les systèmes

d’acceptation billettique auxquels ce référentiel s’applique sont basés sur une architecture orientée

services (SOA) utilisant des services web.

12 Ce concept de domaine billettique coïncide avec le modèle défini par Europtima, au module M.SECU près.




Page Date

34 / 93

19 mars 2014

Ce type d’architecture permet aux modules internes au domaine billettique communiquer entre eux

par l’intermédiaire de services logiciels utilisant les technologies courantes du web, ce qui assure

l’indépendance entre le logiciel les ressources matérielles.

Un service est fourni et géré par un module, les autres modules pouvant utiliser ce service.

Un système de publication et de découverte de service permet à chaque module de signaler les

services qu’il offre, et de détecter les services offerts par les autres modules afin de s’y abonner.

Dans ce référentiel, toutes les interactions entre modules internes au domaine billettique sont décrites

sous forme de services web. Ces services sont identifiés par une référence composée des lettres

« SRV » suivies d’un point et d’un code mnémonique de quelques lettres (par exemple,

« SRV.PAY »).

5.1.4 Interfaces

Dans ce référentiel, les interactions qui ne sont pas des services sont des « interfaces » :

• Interactions entre les modules internes au domaine billettique et les autres parties du système

d’acceptation billettique, identifiées par une référence composée des lettres « INT » suivies d’un

point et d’un code mnémonique de quelques lettres (par exemple, « INT.API »).

• Interactions entre le système d’acceptation billettique et le monde extérieur, identifiées par une

référence composée des lettres « EXT » suivies d’un point et d’un code mnémonique de

quelques lettres (par exemple, « EXT.PO »).

Ce référentiel se base autant que possible sur des interfaces standardisées, afin de favoriser

l’indépendance entre le logiciel les ressources matérielles.

5.1.5 Critères de définition

Les modules, services et interfaces décrits dans ce référentiel répondent à des critères devant

permettre d’atteindre les objectifs définis en introduction (chapitre 2.1).

Ces critères de définition résultent de la collaboration entre les experts réunis pour la rédaction de ce

référentiel, qui sont ainsi parvenus à un découpage en modules réalisant un bon compromis entre ces

différents critères.

Dans les chapitres de description des modules (chapitres 5.3.1 à 5.3.10) est détaillée la pertinence du

contour du module vis-à-vis de chacun des critères. La synthèse présentée au chapitre 7.1 révèle la

pertinence globale du référentiel.

Des critères supplémentaires, non détaillés car constitutifs du référentiel, sont :

Abstraction Le logiciel doit autant que possible être indépendant du matériel et du système d’exploitation (considéré comme lié au matériel) , les liens entre le logiciel et le

matériel constituant un obstacle majeur à la modularité.

De plus, un module doit pouvoir être indépendant de la localisation du matériel qui l’héberge.

L’utilisation de services web est garante de l’abstraction vis-à-vis du matériel et de sa localisation.




Page Date

35 / 93

19 mars 2014

Performance La définition des services et des interfaces prend en compte, lorsque nécessaire, les critères de performance (temps de transaction) et d’utilisation de ressources matérielles, fortement dépendants des choix d’implémentation et donc du savoir faire des fournisseurs.

En pratique, un système d’acceptation billettique traitant une transaction de validation typique doit toujours pouvoir la réaliser en moins de 500 ms avec un objet portable NFC (tel qu’un téléphone mobile) de performances moyennes, et autant que possible inférieur à 250 ms avec un objet portable performant (tel qu’une carte sans contact dédiée).

Coût L’impact sur le coût global est une préoccupation constante. En particulier, les technologies libres de droits sont privilégiées.

Cohérence Afin de ne pas fragmenter excessivement l’architecture, les fonctions sont regroupées de façon cohérente et homogène au sein d’un nombre limité de modules.

Le tableau ci-dessous présente les critères détaillés pour chaque module :

1 Spécificité Les éléments communs à tous les systèmes d’acceptation billettique sont isolés des éléments spécifiques, en particulier pour permettre leur mutualisation au sein d’un même équipement.

En particulier, lorsque des traitements ou des données sont spécifiques à un périmètre billettique donné, ils sont isolés dans un module distinct13.

2 Évaluation Dans la mesure du possible, les modules sont définis de telle sorte que chacun puisse être évalué dans l’absolu, indépendamment des autres modules. Ce critère qualifie l’interchangeabilité et la sécurité des modules. Il est favorisé par l’utilisation de standards.

3 Standardisation Lorsque des normes (ou standards de fait) sont disponibles, elles sont utilisées pour interconnecter les modules, de sorte que les limites entre les modules recoupent les normes et standards courants.

Comme il n’existe actuellement aucun standard ou norme traitant des interactions internes aux systèmes d’acceptation billettique, ce critère n’est appliqué tel quel qu’aux modules externes. Pour les modules internes, il qualifie la capacité à favoriser de futurs standards.

4 Évolutivité Les fonctions qui évoluent à des moments différents sont dans des modules distincts. Réciproquement, il est possible d’intégrer dans un même module des fonctions dont les évolutions peuvent être synchronisées.

5 Disponibilité Ce critère évalue la pertinence industrielle et commerciale des modules. Afin de favoriser un marché concurrentiel, il doit permettre de répondre qualitativement à la question suivante : « existe(ra)-t-il des fournisseurs pour ce module ? ».

L’échelle de valeur utilisée pour décrire la pertinence du contour des modules est : faible, passable,

bonne, très bonne. Elle permet de répondre qualitativement à la question suivante : « dans quelle

mesure le découpage réalisé répond-il aux critères définis ? ». Par exemple, une pertinence faible

13 Lorsque ce type de module est en interaction avec un élément externe au système d’acceptation billettique, cet élément est également dédié au périmètre billettique de ce module.




Page Date

36 / 93

19 mars 2014

serait l’indication qu’un autre découpage des modules permettrait probablement de mieux répondre

au critère considéré.

5.2 Présentation des modules

Le diagramme ci-dessous est une représentation simplifiée de l’architecture d’un système

d’acceptation billettique quelconque, afin de visualiser de manière synthétique les modules définis par

ce référentiel.

Système d’acceptation billettique

Domaine billettique

Objet

portable ABC

Objets

portables

non ABC

Systèmes

distantsSystèmes

distantsAutres

systèmes

Expédition-réception

M.MSG

Gestion

applicative

M.MGR

Règles tarifairesRègles tarifairesRègles tarifairesM.TRF

Environ-

nement

matériel et

logiciel

Commandes

M.PO

Passerelle de

paiement

M.S

EC

U

SAM / HSM

ABC

SAM / HSM

non ABC

TriangleM.TRG

M.A

PP

Autres

technologies

Calypso

M.M

OD

IntercodeAutres

modèles de

données

Interface

utilisateur

M.MMI

AdministrationM.ADM

Ce schéma ne préjuge pas de la localisation des différents modules. En particulier, certains modules

peuvent être composés de sous-ensembles locaux ou distants.




Page Date

37 / 93

19 mars 2014

Le chapitre 6 présente des déclinaisons de ce schéma en différents modèles d’architecture

correspondant à des cas typiques de systèmes d’acceptation billettique.

Le tableau ci-dessous présente les familles de modules qui figurent dans le diagramme précédent et

qui sont décrites dans les chapitres suivants :

Module Présentation Fonctions

Services et

interfaces

spécifiques

M.PO Commandes

Passerelle entre le service web du domaine

billettique assurant l’accès aux objets

portables et l’interface avec l’Environnement

matériel et logiciel.

Également, gestion du routage de l’application

présente vers le périmètre billettique

approprié, avec gestion de priorité.

F2 INT.CMD,

SRV.PO

M.SECU Sécurité

billettique

Traitements cryptographiques liés aux

opérations billettiques. F2, F4, F8, F15

SRV.SAM,

INT.CMD,

INT.SAM

M.APP Accès à

l’application

Indépendamment de la valeur des données,

réalise leur lecture et leur écriture dans les

différents types d’application gérés.

Gère les contraintes de contrôle d’accès à

l’application (peut nécessiter l’utilisation d’un

SAM).

F3, F4, F5

SRV.PO,

SRV.SAM,

SRV.APP,

SRV.ACC,

SRV.AUTH,

SRV.SECU,

M.TRG Triangle

Encapsulation des données lues et inscrites

dans une application Triangle.

Gère les mécanismes de sécurité Triangle

éventuellement mis en œuvre (nécessite

l’accès au SAM d’un module M.SECU).

F6, F7.1, F8.1

SRV.ACC,

SRV.AUTH,

SRV.TRG

M.MOD Modèle de

données

Met en forme les données lues et inscrites

conformément aux différents modèles gérés.

Gère les éventuels mécanismes de sécurité

spécifiques (peut nécessiter l’accès à un

module M.SECU).

F6, F7, F8

SRV.ACC,

SRV.AUTH,

SRV.TRG,

SRV.MOD

M.TRF Règles tarifaires

Analyse et configure les données lues et

inscrites dans l’application selon les règles

commerciales à appliquer.

F9, F10, F15

SRV.SECU,

SRV.MOD,

SRV.TRF

M.MGR Gestion

applicative

Orchestre le comportement applicatif du

système d’acceptation billettique pour un

périmètre billettique donné.

F12, F13, F17,

F19

SRV.APP,

SRV.TRF,

SRV.MSG,

SRV.MMI,

SRV.PRM,

SRV.PAY

M.MSG Expédition-

réception

Gère les échanges de messages avec les

autres systèmes. F14

SRV.MSG,

SRV.CTRL

M.MMI Interface

utilisateur

Gère l’accès aux dispositifs d’interaction avec

les utilisateurs (interfaces avec les objets

portables exceptées).

F11 SRV.MMI

M.ADM Administration

Gère l’ajout, la suppression, la modification et

la supervision des modules du domaine

billettique.

F16 SRV.PRM,

SRV.TECH




Page Date

38 / 93

19 mars 2014

Note : tous les modules utilisent l’interface INT.API (API d’exécution) et l’interface INT.SRV (Gestion

de services), ainsi dans le tableau ci-dessus ces interfaces sont considérées implicites et ne sont

donc pas mentionnées.

Les modules hors domaine billettique sont :

Module Présentation Fonctions Interfaces

Environnement matériel

et logiciel

Système d’exploitation, machine virtuelle (par

exemple Java), librairies, etc. F18

Toutes

interfaces INT

et EXT Envoi de blocs de messages vers les différents

types d’objets portable et de SAM gérés, et

réception des messages de réponse.

F1

Passerelle de paiement

L’interface avec le module assurant le paiement

est dans le périmètre de ce référentiel, mais pas

le module lui-même (il n’y a donc pas de fonction

correspondant)

- SRV.PAY

5.3 Description des modules

5.3.1 M.PO – Commandes

Description

Le module M.PO réalise une passerelle entre :

• SRV.PO (Commandes objet portable) : service web du domaine billettique qui assure l’accès

aux objets portables, et

• INT.CMD (Transport de commandes) : interface avec l’Environnement matériel et logiciel qui

permet la communication avec les objets portables.

Il reçoit via SRV.PO des messages de commande sous forme d’APDU de réponse ISO/IEC 7816-4,

les fait parvenir à l’objet portable via le module Environnement matériel et logiciel. Il reçoit en retour

une réponse qu’il fournit, via SRV.PO, sous forme d’APDU de réponse ISO/IEC 7816-4.

De plus, il réalise le routage des d’applications14 par association à un ou plusieurs modules M.APP

(Accès à l’application, module fournisseur de SRV.PO), de sorte que l’application présente soit traitée

par le périmètre billettique approprié. Ce routage intègre un mécanisme de gestion de la priorité entre

plusieurs périmètres billettiques qui souhaiteraient traiter la même application..

Fonctions

Le module M.PO assure la fonction F2 (Échanger des commandes).

14 Tous les objets portables non ISO/IEC 7816-4 étant assimilés à des applications, voir INT.CMD (note 18).




Page Date

39 / 93

19 mars 2014

Services et interfaces

Le module M.PO ne fournit aucun service. Les services qu’il utilise sont :

Service Modules

Fournisseur Utilisateurs

SRV.PO Commandes objet portable M.APP M.PO

Les interfaces du module M.PO sont :

Interface Interlocuteurs

INT.API API d’exécution

M.PO

Environnement

matériel et

logiciel

INT.SRV Gestion de services

INT.CMD Transport de commandes

Pertinence du module

Le tableau suivant indique dans quelle mesure le contour du module M.PO, considéré pour chaque

critère indépendamment des autres modules et des autres critères, donne une réponse pertinente au

critère de définition considéré :

Critère Pertinence Commentaires

1 Spécificité Très bonne

Tous les types d’applications sont traités par le même module.

Le routage est commun à tous les types d’objets portables et

d’applications, y compris non billettiques. Il ne peut donc pas être

intégré à un périmètre billettique.

2 Évaluation Très bonne L’évaluation ne dépend pas des autres modules.

3 Standardisation Très bonne Le module coïncide avec des normes ou standard existant

(ISO/IEC 7816, PC/SC, etc.).

4 Évolutivité Bonne

Les fonctions assurées par le module évoluent à des moments

similaires, selon les évolutions normatives (généralement

indépendantes des autres modules).

5 Disponibilité Très bonne Non spécifique à la billettique (de futurs environnements matériels et

logiciels pourraient l’intégrer).

5.3.2 M.SECU – Sécurité billettique

Description

Un module M.SECU réalise les traitements cryptographiques liés aux transactions billettiques (pour

un ou plusieurs périmètres billettiques).

Il se compose d’une partie logicielle, qui fournit ses services aux autres modules, et d’une partie

matérielle lorsqu’il est nécessaire que les calculs cryptographiques soient réalisés dans un

environnement physique sûr dédié15 (SAM).

15 Lorsque cet environnement physique sûr n’est pas dédié à un type d’application, il peut être fourni par l’environnement d’exécution, le module M.SECU étant ainsi uniquement logiciel.




Page Date

40 / 93

19 mars 2014

Pour le traitement de l’ABC, un SAM Calypso contenant les clés Triangle est nécessaire.

Les services fournis par les modules M.SECU sont utilisés par des modules M.APP (Accès à

l’application), qui fournissent aux autres modules tous les services sécurisés par M.SECU.

Afin d’uniformiser les échanges avec les modules M.APP, tous les échanges avec un module

M.SECU sont réalisés sous forme d’APDU ISO/IEC 7816-4 (même lorsque le module M.SECU ne

comporte aucune carte à puce).

Lorsqu’un SAM est utilisé, il est relié au module Environnement matériel et logiciel par les interfaces

INT.SAM (SAM), pour la connexion physique, et INT.CMD (Transport de commandes).

Fonctions

Le module M.SECU contribue aux fonctions F2 (Échanger des commandes), F4 (Assurer la sécurité

des échanges avec l’application), F8 (Assurer la sécurité des données caractéristiques des droits de

transport) et F15 (Superviser le SAM).


Le module M.SECU n’utilise aucun service. Les services qu’il fournit sont :

Service Modules


SRV.SAM Commandes SAM M.SECU M.APP

Les interfaces du module M.SECU sont :



M.SECU

Environnement

matériel et

logiciel

INT.SRV Gestion de services

INT.CMD Transport de commandes

INT.SAM SAM




Page Date

41 / 93

19 mars 2014


Le tableau suivant indique dans quelle mesure le contour du module M.SECU, considéré pour

chaque critère indépendamment des autres modules et des autres critères, donne une réponse

pertinente au critère de définition considéré :

Critère Réponse Commentaires

1 Spécificité Très bonne Regroupement de tous les traitements de sécurité informatique.

2 Évaluation Très bonne Spécifications détaillées, non fragmentées (pour un type

d’application donné).

3 Standardisation Très bonne Mécanismes probablement modélisables sous forme canonique pour

tous les types de supports ou de données.

4 Évolutivité Bonne Traitements de même nature, ayant des moments d’évolution

comparables, et potentiellement indépendants des autres modules.

5 Disponibilité Très bonne Fonctions critiques nécessitant des fournisseurs spécialisés.

5.3.3 M.APP – Accès à l’application

Description

Un module M.APP réalise la lecture et l’écriture de données quelconques dans un type d’application

supporté (par exemple Calypso) par le système d’acceptation billettique, et la gestion de la sécurité

billettique. Un module M.APP différent est donc présent pour chaque type d’application.

Le module M.APP fournit des services aux modules M.TRG (Triangle), M.MOD (Modèle de données)

et M.TRF (Règles tarifaires). Il utilise pour cela les services du module M.PO (Commandes) pour

communiquer avec les objets portables, et du module M.SECU (Sécurité billettique). Il permet

également au module M.MGR (Gestion applicative) de déclarer les applications qu’il souhaite traiter.

Il assure la sécurisation de l’accès aux applications. Par exemple, le module M.APP dédié aux

applications Calypso (dont l’ABC) assure les échanges avec le SAM Calypso qui sont nécessaires à

l’authentification mutuelle requise par le mécanisme de session Calypso.

De plus, les services fournis par M.APP à M.TRG et M.MOD permettent de sécuriser les données

lues et inscrites dans les applications, et ceux fournis à M.TRF permettent la surveillance et la mise à

jour des paramètres de sécurité des modules M.SECU.

Fonctions

Un module M.APP assure les fonctions suivantes :

• F5 (Communiquer avec une application) ;

• F4 (Assurer la sécurité des échanges avec l’application) ;

• Si nécessaire, F3 (Communiquer avec un SAM), pour ce qui relève de la sécurité de

l’application concernée.




Page Date

42 / 93

19 mars 2014


Les services fournis ou utilisés par le module M.APP sont :

Service Modules


SRV.PO Commandes objet portable

M.APP

M.PO

SRV.APP Gestion des applications M.MGR

SRV.ACC Accès à l’application M.TRG, M.MOD

SRV.AUTH Sécurité des données M.TRG, M.MOD

SRV.SECU Gestion de la sécurité billettique M.TRF

SRV.SAM Commandes SAM M.SECU

Les interfaces du module M.APP sont :


INT.API API d’exécution M.APP

Environnement

matériel et

logiciel INT.SRV Gestion de services


Le tableau suivant indique dans quelle mesure le contour du module M.APP, considéré pour chaque




1 Spécificité Très bonne Isolation entre le contenant (objet portable, potentiellement non

spécifique à la billettique) et le contenu (les données billettiques).

2 Évaluation Bonne Interfaces coïncidant avec des standards, mais très diverses.

3 Standardisation Très bonne Mécanismes modélisables sous forme canonique pour tous les types

d’applications.



5 Disponibilité Bonne Possibilité de modules génériques (par type de support).

5.3.4 M.TRG – Triangle

Description

Le module M.TRG réalise l’encapsulation sécurisée des données des modules M.MOD (Modèle de

données) stockées dans une application Triangle, pour tous les périmètres billettiques traités par le


Le module M.TRG peut être unique et générique, et devrait n’évoluer que lors des mises à jour des

spécifications Triangle.




Page Date

43 / 93

19 mars 2014

Il s’appuie sur le module M.APP (Accès à l’application) dédié aux applications Calypso pour accéder

aux données, et lorsque nécessaire pour les sécuriser avec un module M.SECU (Sécurité billettique)

comportant un SAM Calypso.

Fonctions

Le module M.TRG assure les fonctions suivantes :

• F6 (Gérer la correspondance modèle de données/structures de données) ;

• F7.1 (Décoder et encoder des données lues dans l’application Triangle celles participant aux

données caractéristiques des droits de transport) ;

• F8.1 (Assurer la sécurité des données Triangle).


Les services fournis ou utilisés par le module M.TRG sont :

Service Modules


SRV.TRG Triangle M.TRG M.MOD

SRV.ACC Accès à l’application M.APP M.TRG

SRV.AUTH Sécurité des données M.APP

Les interfaces du module M.TRG sont :


INT.API API d’exécution M.TRG

Environnement

matériel et



Le tableau suivant indique dans quelle mesure le contour du module M.TRG, considéré pour chaque




1 Spécificité Très bonne Fonctions non dédiées à un périmètre billettique (indépendantes des

modèles de données).

2 Évaluation Très bonne Spécifications détaillées, non fragmentées.

3 Standardisation Très bonne Standard non propriétaire.

4 Évolutivité Très bonne Traitements couverts par un unique corpus de spécification,

moments d’évolution indépendants des autres modules.

5 Disponibilité Très bonne Possibilité de module générique.




Page Date

44 / 93

19 mars 2014

5.3.5 M.MOD – Modèle de données

Description

Chaque module M.MOD implémente un modèle de données billettique.

Un module M.MOD échange avec des modules M.TRF (Règles tarifaires) des structures de données

billettiques aussi indépendantes que possible du type d’application utilisé.

Pour le traitement des applications Triangle, le module M.MOD s’appuie sur le module M.TRG

(Triangle). Dans les autres cas, il s’appuie directement sur les modules M.APP (Accès à l’application).

Dans la mesure du possible, les modèles de données doivent être génériques. Les différentes

utilisations d’un même modèle (instanciations) sont gérées par les modules M.TRF. Un module

M.MOD ne doit pas gérer le modèle de données Triangle, qui est dévolu au module M.TRG.

Fonctions

Un module M.MOD assure les fonctions suivantes :

• F6 (Gérer la correspondance entre le modèle de données et les structures de données de

l’application) ;

• F7 (Décoder et encoder les données caractéristiques des droits de transport) ;

• si nécessaire, F8 (Assurer la sécurité des données caractéristiques des droits de transport),

pour ce qui relève de la sécurité de l’application concernée.


Les services fournis ou utilisés par le module M.MOD sont :

Service Modules


SRV.MOD Modèle de données M.MOD M.TRF

SRV.ACC Accès à l’application M.APP

M.MOD SRV.AUTH Sécurité des données M.APP

SRV.TRG Triangle M.TRG

Les interfaces du module M.MOD sont :


INT.API API d’exécution M.MOD

Environnement

matériel et





Page Date

45 / 93

19 mars 2014


Le tableau suivant indique dans quelle mesure le contour du module M.MOD, considéré pour chaque




1 Spécificité Très bonne Isolation entre les règles commerciale et le modèle de données.

2 Évaluation Très bonne Spécifications détaillées, non fragmentées (par modèle de données).


de modèles de données.




5.3.6 M.TRF – Règles tarifaires

Description

Un module M.TRF implémente les règles tarifaires qui correspondent à l’offre commerciale d’un des

périmètres billettiques du système d’acceptation billettique. Pour ce périmètre billettique, il prend en

charge la totalité des traitements qui dépendent de l’offre commerciale, et de la politique de gestion

de la sécurité billettique.

En fonction du type de transaction à réaliser, indiqué par M.MGR (Gestion applicative), un module

M.TRF analyse les données de l’application, déduit les nouvelles données à inscrire, réalise leur

inscription, et rend compte des opérations réalisées.

L’accès à l’application se fait via M.MOD (Modèle de données). La gestion de l’instanciation du

modèle de données pris en charge par M.MOD est intégrée à M.TRF. Si le système d’acceptation

billettique traite plusieurs périmètres billettiques, un module M.TRF différent est affecté à chacun

d’eux.

Le module M.TRF est le plus susceptible de présenter des caractéristiques spécifiques à chaque

domaine billettique, et également le plus affecté par les évolutions des règles commerciales. Ses

coûts de réalisation et d’évolution sont principalement liés aux tests, qui garantissent la continuité du

service lors des mises à jour.

Fonctions

Un module M.TRF assure les fonctions suivantes :

• F9 (Analyser les données actuelles caractéristiques des droits de transport) ;

• F10 (Déterminer les nouvelles données caractéristiques des droits de transport) ;

• F15 (Superviser le SAM), le module M.TRF assurant la communication avec le SAM

appartenant au même périmètre billettique.




Page Date

46 / 93

19 mars 2014


Les services fournis ou utilisés par le module M.TRF sont :

Service Modules


SRV.TRF Tarification M.TRF M.MGR

SRV.SECU Gestion de la sécurité billettique M.APP M.TRF

SRV.MOD Modèle de données M.MOD

Les interfaces du module M.TRF sont :


INT.API API d’exécution M.TRF

Environnement

matériel et



Le tableau suivant indique dans quelle mesure le contour du module M.TRF, considéré pour chaque




1 Spécificité Très bonne Isolation des règles tarifaires.


3 Standardisation Très bonne Mécanismes modélisables sous forme canonique pour tous les

périmètres billettiques.

4 Évolutivité Bonne

Évolutions fonctionnelles indépendantes des autres modules car

liées à des contraintes non techniques, mais dépendance vis-à-vis

des modèles de données (instanciation).

5 Disponibilité Très bonne Possibilité de modules génériques (par périmètre billettique).

5.3.7 M.MGR – Gestion applicative

Description

Un module M.MGR orchestre les actions requises pour traiter les objets portables d’un périmètre

billettique donné :

• gestion de la présence des objets portables et de leurs applications, avec le module M.APP

(Accès à l’application) ;

• transactions avec les objets portables, avec le module M.TRF (Règles tarifaires) ;

• échanges avec le système billettique, avec les modules M.MSG (Expédition-réception) ;

• stockage des données volumineuses (listes, rapports, etc.) ;

• interactions avec l’utilisateur, avec le module M.MMI (Interface utilisateur) ;

• demande de réalisation d’un paiement, avec le module Passerelle de paiement ;




Page Date

47 / 93

19 mars 2014

• gestion des paramètres de fonctionnement non liés à la billettique (communs à tous les

périmètres billettique), avec le module M.ADM (Administration).

Il met en forme les données de collecte et de distribution échangés entre un module M.MSG

(Expédition-réception) et des autres systèmes.

Il gère également le stockage des données volumineuses dans la mémoire de masse non volatile de

l’Environnement matériel et logiciel.

Il ne réalise aucun traitement qui dépende de l’offre commerciale, tous pris en charge par les modules

M.TRF.

Fonctions

Un module M.MGR assure la fonction F19 (Coordonner les fonctions), et contribue aux fonctions

suivantes :

• F12 (Fournir les données de traitement des droits) ;

• F13 (Acquérir les règles de gestion) ;

• F17 (Conserver des données volumineuses).


Les services fournis ou utilisés par le module M.MGR sont :

Service Modules


SRV.MMI Interface homme-machine M.MGR M.MMI

SRV.APP Gestion des applications M.APP

M.MGR

SRV.TRF Tarification M.TRF

SRV.MSG Collecte et distribution M.MSG

SRV.PRM Gestion des paramètres M.ADM

SRV.PAY Paiement Passerelle de

paiement

Les interfaces du module M.MGR sont :


INT.API API d’exécution M.MGR

Environnement

matériel et





Page Date

48 / 93

19 mars 2014


Le tableau suivant indique dans quelle mesure le contour du module M.MGR, considéré pour chaque




1 Spécificité Très bonne

Indépendant des moyens de réalisation des actions déclenchées.

Spécifique par type de système d’acceptation billettique (valideur

embarqué, automate de vente, etc.), pour un périmètre billettique

donné.

2 Évaluation Très bonne Spécifications détaillées, non fragmentées (par type de système

d’acceptation billettique).


périmètres billettiques, par type de système d’acceptation billettique.

4 Évolutivité Très bonne Moments d’évolution indépendants des autres modules.

5 Disponibilité Bonne Possibilité de modules génériques, mais fragmentation (par type de

système d’acceptation et périmètre billettique).

5.3.8 M.MSG – Expédition-réception

Description

Un module M.MSG fournit au module M.MGR (Gestion applicative) les ressources d’échanges avec

les autres systèmes des données billettiques.

Il communique avec les autres systèmes à l’aide du service SRV.CTRL (Supervision billettique) qu’ils

fournissent.

Un module M.MSG peut être spécifique à un périmètre billettique.

Fonctions

Un module M.MSG assure la fonction F14 (Communiquer avec des autres systèmes) pour un

périmètre billettique donné.


Les services fournis ou utilisés par le module M.MSG sont :

Service Modules


SRV.MSG Collecte et distribution M.MSG M.MGR

SRV.CTRL Supervision billettique Autres

systèmes M.MSG




Page Date

49 / 93

19 mars 2014

Les interfaces du module M.MSG sont :


INT.API API d’exécution M.MSG

Environnement

matériel et



Le tableau suivant indique dans quelle mesure le contour du module M.MSG, considéré pour chaque




1 Spécificité Très bonne Indépendance des autres modules, traitements non bloquants.



périmètres billettiques, par type de système d’acceptation billettique.




5.3.9 M.MMI – Interface utilisateur

Description

Un module M.MMI gère l’accès aux dispositifs d’interface utilisateurs (IHM), exceptée l’interface avec

les objets portables (voir EXT.PO) :

• dispositifs d’affichage (texte ou graphique) ;

• dispositifs de saisie (boutons, clavier, écran tactile, etc.) ;

• signaux sonores, lumineux ou mécaniques (vibreurs) ;

• dispositifs de contrôle d’accès (tripode, portillon) ;

• etc.

Il permet au module M.MGR (Gestion applicative) d’utiliser tout type de dispositif d’IHM, de façon

aussi indépendante que possible des caractéristiques spécifiques à chaque dispositif (par exemple le

nombre de pixels d’un écran).

Fonctions

Le module M.MMI assure la fonction F11 (Interagir avec les utilisateurs).




Page Date

50 / 93

19 mars 2014


Le module M.MMI ne fournit aucun service. Les services qu’il utilise sont :

Service Modules


SRV.MMI Interface homme-machine M.MGR M.MMI

Les interfaces du module M.MMI sont :


INT.API API d’exécution M.MMI

Environnement

matériel et



Le tableau suivant indique dans quelle mesure le contour du module M.MMI, considéré pour chaque




1 Spécificité Bonne Indépendance des autres modules, besoin de traitements non

bloquants, mais diversité des dispositifs d’IHM.

2 Évaluation Bonne Interfaces coïncidant avec des standards, mais très diverses.


de dispositifs d’IHM.

4 Évolutivité Bonne Moments d’évolution indépendants des autres modules, mais

diversité des dispositifs d’IHM.

5 Disponibilité Bonne Possibilité de module générique, mais diversité des dispositifs d’IHM.

5.3.10 M.ADM – Administration

Description

Le module M.ADM est en charge de l’administration des modules du domaine billettique du système

d’acceptation billettique : ajout, suppression, mise à jour, détection de dysfonctionnement, relations

avec le système tiers de gestion des modules, etc.

Il offre également au module M.MGR (Gestion applicative) un service de gestion des paramètres

fonctionnement du système d’acceptation billettique qui sont indépendants des périmètres

billettiques, en s’appuyant sur les ressources de l’Environnement matériel et logiciel.

Il communique avec les autres systèmes à l’aide du service SRV.TECH (Supervision technique) qu’ils

fournissent.

Fonctions

Le module M.ADM contribue à la fonction F16 (Superviser le système d’acceptation billettique).




Page Date

51 / 93

19 mars 2014


Les services fournis ou utilisés par le module M.ADM sont :

Service Modules


SRV.PRM Gestion des paramètres M.ADM M.MGR

SRV.TECH Supervision technique Autres

systèmes M.ADM

Les interfaces du module M.ADM sont :


INT.API API d’exécution M.ADM

Environnement

matériel et



Le tableau suivant indique dans quelle mesure le contour du module M.ADM, considéré pour chaque




1 Spécificité Bonne

Traitements indépendants des autres modules, mais de deux

natures différentes (administration des modules et gestion des

paramètres fonctionnement).

2 Évaluation Très bonne Spécifications détaillées, non fragmentées (par environnement

matériel et logiciel).


d’environnements matériels et logiciels.

4 Évolutivité Très bonne Évolutivité indépendante des modules eux-mêmes

5 Disponibilité Très bonne Non spécifique à la billettique (de futurs environnements matériels et

logiciels pourraient l’intégrer).

5.3.11 Environnement matériel et logiciel

Description

L’Environnement matériel et logiciel est l’ensemble des ressources matérielles et logicielles

nécessaires au fonctionnement des autres modules. C’est le système d’exploitation (Windows, Linux,

etc.) éventuellement complété d’un environnement virtuel (par exemple Java) ou de librairies.

Lorsque le système d’acceptation billettique est composé d’éléments indépendants, chacun peut

avoir un Environnement matériel et logiciel différent.

Le remplacement ou la mise à jour d’un module d’Environnement matériel et logiciel nécessite

généralement une nouvelle installation des sous-ensembles logiciels de tous les autres modules.




Page Date

52 / 93

19 mars 2014

Les environnements matériel et logiciel constituant des standards de fait sont :

• Windows, y compris ses versions embarquées et pour appareils mobiles ;

• Linux et BSD, y compris leurs versions embarquées ;

• OS X (Apple Computers)16 ;

• Java, et J2ME pour les appareils mobiles ;

• VxWorks ;

• Android, pour les appareils mobiles ;

• Technologies web :

- client : WebKit, Gecko, etc. ;

- serveur : Apache, MySQL, PHP, etc. ;

- protocoles et langages : HTTP, XML, Javascript, Ethernet, Wifi, SSL, TCP, IP, etc. ;

• Java Card, pour les secure elements.

Lorsque le système d’acceptation billettique est composé d’éléments indépendants, chacun peut

avoir un Environnement matériel et logiciel différent.

Architecture orientée services (SOA), services web

Afin de définir des modules évolutifs et interchangeables entre différents fournisseurs, il est

nécessaire d’utiliser un Environnement matériel et logiciel indépendant du matériel et du système

d’exploitation. Par conséquent, l’architecture des systèmes d’acceptation billettique est basée sur des

services web (par exemple de type SOAP ou REST).

Les fournisseurs d’équipements ou de modules devront veiller à ce que l’utilisation de ce type

d’architecture ne se fasse pas au détriment des performances. En particulier, les systèmes

d’acceptation billettique qui contrôlent l’accès aux transports doivent garantir des délais de

transaction (et entre transactions) suffisamment courts.

Un standard d’architecture orientée services pouvant gérer des services web est OSGi (« Open

Services Gateway initiative »).

Fonctions

Le module Environnement matériel et logiciel assure la fonction F18 (Mettre à disposition les

ressources matérielles).

Il assure également la fonction F1 (Communiquer avec un composant matériel sécurisé), pour un

tous les types d’interface avec les objets portables et les SAM, et contribue à la fonction F16

(Superviser le système d’acceptation billettique).


Le module d’Environnement matériel et logiciel ne fournit ni n’utilise aucun service.




Page Date

53 / 93

19 mars 2014

Les interfaces de l’Environnement matériel et logiciel sont :



Environnement

matériel et

logiciel

Tous les

modules INT.SRV Gestion de services

INT.CMD Transport de commandes M.PO, M.SECU

INT.SAM SAM M.SECU

EXT.PO Objet portable Objet portable

EXT.NET Réseau externe Réseau externe

EXT.USER Dispositifs d’IHM Dispositifs

d’IHM

EXT.PHY Environnement physique Environnement

physique

5.3.12 Passerelle de paiement

Description

Les transactions financières sont hors du périmètre de ce référentiel. Le paiement est mentionné

uniquement pour son interface avec le module M.MGR (Gestion applicative), qui dans certains

requiert un paiement en numéraire ou bancaire.

Fonctions

Le module Passerelle de paiement assure le paiement correspondant à une transaction billettique.

Cette fonction étant hors du périmètre de ce référentiel, elle n’est pas décrite ni référencée.

Interfaces

Le module Passerelle de paiement n’utilise aucun service. Les services qu’il fournit sont :

Service Modules


SRV.PAY Paiement Passerelle de

paiement M.MGR

Les interfaces du module Passerelle de paiement sont :


INT.API API d’exécution Passerelle de

paiement

Environnement

matériel et


Le module Passerelle de paiement peut posséder d’autres interfaces qui lui sont propres et en dehors

du périmètre de ce référentiel.

16 À l’heure actuelle aucun appareil sous iOS n’a d’interface NFC, et Apple n’a communiqué aucune feuille de route pour un éventuel support du NFC. L’environnement iOS n’est donc pas pris en compte.




Page Date

54 / 93

19 mars 2014

5.4 Présentation des services et des interfaces

Le diagramme ci-dessous est une représentation simplifiée des interfaces entre les modules d’un

système d’acceptation billettique quelconque, afin de visualiser de manière synthétique les services

définis par ce référentiel.


Domaine billettique

EXT.PO

EXT.NET

EXT.PO

INT.API

INT.SRV

SRV.SAM

SR

V.A

PP

SRV.PO

SR

V.A

CC

SR

V.S

EC

U

SRV.AUTH

SRV.TRG

INT.C

MD

SRV.MOD

SRV.MSG

SRV.MMI

SRV.PRM

SRV.PAY

EXT.USER

EXT.PHY

INT.SAM

INT

.AP

I

INT

.SR

V

Objet

portable ABC

Objets

portables

non ABC

Systèmes

distantsSystèmes

distantsAutres

systèmes

M.MSG

Passerelle de

paiement

M.MGR

M.TRF

Environ-

nement

matériel et

logiciel

M.MOD

M.TRG

M.SECU

M.APP

M.PO

M.ADM

M.MMI

SRV.TECH

SRV.CTRL

Référence

Légende :

Fournis-

seur

Utilisa-

teur

SR

V.T

RF

Référence

Service :

Interface :




Page Date

55 / 93

19 mars 2014

Services fournis par les modules

Le tableau suivant présente les services entre les modules décrits aux chapitres 5.2 et 5.3.

Service Description Modules


SRV.PO Commandes

Déclaration des applications à traiter,

signalement de la disponibilité d’une application.

APDU conformes ISO/IEC 7816-4, pour tout type

d’objet portable.

M.APP M.PO

SRV.SAM Commandes SAM

Sélection d’un SAM parmi ceux disponibles.

APDU conformes ISO/IEC 7816-4, pour tout type

de SAM.

M.SECU M.APP

SRV.APP Gestion des

applications Déclaration des applications à traiter M.APP M.MGR

SRV.ACC Accès à

l’application

Messages décrivant les actions élémentaires

possibles pour l’application considérée, et

contenant les données associées (lues ou à

écrire dans l’application).

M.APP M.TRG,

M.MOD

SRV.AUTH Sécurité des

données

Génération et vérification des signatures des

données des applications. M.APP

M.TRG,

M.MOD

SRV.SECU Gestion de la

sécurité billettique

Surveillance et mise à jour des paramètres de

sécurité billettique. M.APP M.TRF

SRV.TRG Triangle Messages entre les modules gérant les modèles

de données et le module Triangle. M.TRG M.MOD

SRV.MOD Modèle de

données

Messages entre des modules de gestion des

règles tarifaires et un module de gestion d’un

modèle de données.

M.MOD M.TRF

SRV.TRF Tarification Messages entre un module de gestion applicative

et un module de gestion des règles tarifaires. M.TRF M.MGR

SRV.MSG Collecte et

distribution

Messages contenant les données échangées

entre d‘autres systèmes et des modules de

gestion applicative.

M.MSG M.MGR

SRV.MMI Interface homme-

machine

Messages décrivant les interactions avec les

utilisateurs, telles que gérées par les modules de

gestion applicative.

M.MGR M.MMI

SRV.PRM Gestion des

paramètres

Acquisition et mise à jour des paramètres

globaux. M.ADM M.MGR

SRV.PAY Paiement Messages de demande de paiement et

d’acquittement (positif ou non) de ce paiement.

Passerelle

de paiement M.MGR

SRV.CTRL Supervision

billettique

Échange de données d’exploitation billettique

avec les autres systèmes.

Autres

systèmes M.MSG

SRV.TECH Supervision

technique

Échange de données de fonctionnement avec les

autres systèmes.

Autres

systèmes M.ADM




Page Date

56 / 93

19 mars 2014

Interfaces avec l’Environnement matériel et logiciel

Le tableau suivant présente les interfaces de l’Environnement matériel et logiciel. Les interfaces

normalisées (ou standard de fait) sont signalées.

Interface Description

Inte

rne

INT.API API d’exécution Interface programmatique permettant aux modules d’utiliser les

ressources matérielles du système d’acceptation billettique.

INT.SRV Gestion de

services Support des communications entre modules (gestion des services web).

INT.CMD Transport de

commandes

Communication avec les modules traitant des APDU (objets portables ou

SAM).

Standards : PC/SC, javax.smartcardio.

INT.SAM SAM

Protocole de communication avec les SAM ou HSM.

Norme : ISO/IEC 7816-3 (pour les SAM/HSM au format carte à puce).

Standard : PCI Express (pour les HSM sous forme de carte d’extension).

Exte

rne

EXT.PO Objet portable

Protocole de communication avec les objets portables.

Normes :

Interface sans contacts : ISO/IEC 14443, et référentiel AFIMB.

Interface à contacts : ISO/IEC 7816-3.

EXT.NET Réseau externe Communications avec les autres systèmes.

Normes : Ethernet, Wifi, TCP, IP, etc.

EXT.USER Dispositifs d’IHM Nature et comportement des dispositifs d’interaction avec le voyageur ou

l’opérateur, hors objet portable.

EXT.PHY Environnement

physique Alimentation électrique, protection physique, etc.

5.5 Description des services et des interfaces

5.5.1 SRV.PO – Commandes objet portable

Le service SRV.PO permet la sélection d’une application d’un objet portable, l’échange de

commandes avec cette application, et la gestion du canal utilisé pour ces échanges. Pour tous les

types d’objets portables les commandes échangée via SRV.PO sont les « APDU » décrits par la

norme ISO/IEC 7816-4.

Il relie le module M.PO (Commandes) et les modules M.APP (Accès à l’application).

Pour la sélection d’application, SRV.PO permet à chaque M.APP d’indiquer à M.PO les applications

qu’il souhaite traiter. Lorsqu’une de ces applications apparaît, SRV.PO en informe le M.APP

concerné, qui peut alors échanger des APDU avec cette application.

Le module M.PO est toujours dans l’équipement local à l’objet portable avec lequel la transaction est

réalisée. Lorsque cet équipement se trouve à distance de M.APP, il n’est généralement pas en

mesure de fournir des services. C’est par exemple le cas de la vente à distance réalisée avec un




Page Date

57 / 93

19 mars 2014

ordinateur personnel équipé d’un lecteur de carte à puce. Afin d’être indépendant de sa localisation,

le service SRV.PO doit donc être fournit par le module M.APP.

Une encapsulation d’APDU selon une syntaxe XML est décrite par exemple dans la spécification

Calypso Specifications – Product Remote Loading publiée par CNA (réf. 090424-

ProductRemoteLoading).

Modules concernés

Le service SRV.PO met en relation les modules suivants :

Service Modules


SRV.PO M.APP Accès à l’application M.PO Commandes

5.5.2 SRV.SAM – Commandes SAM

Le service SRV.SAM, fourni par le module M.SECU (Sécurité billettique), donne accès à toutes les

fonctions de sécurité billettique gérées par le module. Les messages échangés par ce service sont

des APDU ISO/IEC 7816-4, même lorsque le module M.SECU ne comporte aucune carte à puce.

Ce service permet également l’allocation d’un SAM parmi plusieurs disponible (jusqu’à plusieurs

milliers de SAM, comme dans le cas d’un HSM qui se comporte comme un grand nombre de SAM

virtuels).

Modules concernés

Le service SRV.SAM met en relation les modules suivants :

Service Modules


SRV.SAM M.SECU Sécurité billettique M.APP Accès à l’application

5.5.3 SRV.APP – Gestion des applications

Le service SRV.APP permet la gestion de la présence des objets portables et de leurs applications.

Le module utilisateur (M.MGR, Gestion applicative) est ainsi à même de déclarer au module

fournisseur (M.APP, Accès à l’application) les applications qu’il souhaite traiter.

Modules concernés

Le service SRV.APP met en relation les modules suivants :

Service Modules


SRV.APP M.APP Accès à l’application M.MGR Gestion applicative




Page Date

58 / 93

19 mars 2014

5.5.4 SRV.ACC – Accès à l’application

Le service SRV.ACC transporte, entre un module M.MOD (Modèle de données) quelconque – ou

M.TRG (Triangle) – et un module M.APP (Accès à l’application), des messages décrivant les actions

élémentaires possibles pour l’application considérée, contenant les données éventuellement

associées (par exemple celles lues ou à écrire dans l’application), pour tout modèle de données et

tout type d’application.

Pour les applications Calypso, ces messages permettent en particulier :

• la sélection de l’application ;

• la gestion de la session sécurisée ;

• le paramétrage de certains mécanismes, dont la ratification.

Il n’existe pas de standard pour ces échanges. Néanmoins, en France la RATP et la SNCF ont

chacune défini une spécification imposée aux fournisseurs pour les échanges entre des couches

logicielles équivalentes à M.MOD et M.APP.

Modules concernés

Le service SRV.ACC met en relation les modules suivants :

Service Modules


SRV.ACC M.APP Accès à l’application M.TRG Triangle

M.MOD Modèle de données

5.5.5 SRV.AUTH – Sécurité des données

Le service SRV.AUTH permet la sécurisation de données contenues dans les applications :

• vérification de la signature de données lues ;

• génération de la signature de données à écrire.

Il n’existe pas de standard pour ces échanges.

Modules concernés

Le service SRV.AUTH met en relation les modules suivants :

Service Modules


SRV.AUTH M.APP Accès à l’application M.TRG Triangle

M.MOD Modèle de données

SRV.AUTH étant en pratique un service générique de signature de données arbitraire, il peut

également être utilisé pour d’autres données que celles des applications. Ainsi, d’autres modules que

ceux indiqués ci-dessus pourraient s’y abonner afin de l’utiliser.




Page Date

59 / 93

19 mars 2014

5.5.6 SRV.SECU – Gestion de la sécurité billettique

Le service SRV.SECU assure la gestion des paramètres de contrôle de l’utilisation des fonctions de

sécurité billettique.

Par exemple, pour un SAM Calypso ce service permet de surveiller les compteurs et les plafonds

d’utilisation des clés, et éventuellement de mettre à jour ces plafonds.


Modules concernés

Le service SRV.SECU met en relation les modules suivants :

Service Modules


SRV.SECU M.APP Accès à l’application M.TRF Règles tarifaires

5.5.7 SRV.TRG – Triangle

Le service SRV.TRG transporte entre un module M.MOD (Modèle de données) quelconque et le

module M.TRG (Triangle) les structures du modèle de données d’un périmètre billettique géré par le

module M.MOD, encapsulées dans les structures de données Triangle lues dans l’application, ou à

encapsuler dans les données à inscrire.

Il permet également au module M.TRG d’indiquer au module M.MOD la validité des signatures

Triangle éventuellement présentes dans les données lues.


Modules concernés

Le service SRV.TRG met en relation les modules suivants :

Service Modules


SRV.TRG M.TRG Triangle M.MOD Modèle de données

5.5.8 SRV.MOD – Modèle de données

L’interface SRV.MOD transporte entre un module M.TRF (Règles tarifaires) et un module M.MOD

(Modèle de données) les éléments caractéristiques à la transaction billettique réalisée,

indépendamment du modèle de données utilisé.

La capacité à faire évoluer les règles tarifaires sans modifier la totalité du logiciel est une demande

forte des AOT. Il faut donc s’assurer que les modules M.TRF (Règles tarifaires) et M.MOD (Modèle

de données) soient aussi indépendants que possible, afin de réduire au maximum les risques de

modifications de SRV.MOD en cas d’évolution tarifaire ou de modèle de données.




Page Date

60 / 93

19 mars 2014

Il n’existe pas de standard pour ces échanges. Néanmoins, en France la RATP et la SNCF ont

chacune défini une spécification imposée aux fournisseurs pour les échanges entre des couches

logicielles équivalentes à M.MOD et M.TRF.

Modules concernés

Le service SRV.MOD met en relation les modules suivants :

Service Modules


SRV.MOD M.MOD Modèle de données M.TRF Règles tarifaires

5.5.9 SRV.TRF – Tarification

Le service SRV.TRF transporte entre un module M.MGR (Gestion applicative) et un module M.TRF

(Règles tarifaires) :

• les messages d’orchestration des transactions réalisées avec les objets portables ;

• les données de paramétrage tarifaire ;

• les données d’utilisation des objets portable (gestion de liste noire, rapports de transactions,

etc.).


Modules concernés

Le service SRV.TRF met en relation les modules suivants :

Service Modules


SRV.TRF M.TRF Règles tarifaires M.MGR Gestion applicative

5.5.10 SRV.MSG – Collecte et distribution

Le service SRV.MSG transporte entre un module M.MGR (Gestion applicative) et un module M.MSG

(Expédition-réception) les données :

• reçues par le module M.MGR depuis d’autres systèmes ;

• émises par le module M.MGR vers d’autres systèmes.

Ces données sont codées et structurées indépendamment du protocole de communication utilisé par

le module M.MSG.





Page Date

61 / 93

19 mars 2014

Modules concernés

Le service SRV.MSG met en relation les modules suivants :

Service Modules


SRV.MSG M.MSG Expédition-réception M.MGR Gestion applicative

5.5.11 SRV.MMI – Interface homme-machine

Le service SRV.MMI transporte entre un module M.MGR (Gestion applicative) et un module M.MMI

(Interface utilisateur) les messages décrivant les interactions avec les utilisateurs, de façon aussi

indépendante que possible du dispositif d’IHM mis en œuvre.

Ces messages peuvent concerner tous les types de dispositifs d’IHM utilisés dans les systèmes

d’acceptation billettique (voir chapitre 5.3.9).

Le module M.MGR est toujours dans l’équipement local à l’objet portable avec lequel la transaction

est réalisée. Lorsque cet équipement se trouve à distance de M.MMI, il n’est généralement pas en

mesure de fournir des services. C’est par exemple le cas de la vente à distance réalisée avec un

ordinateur personnel équipé d’un lecteur de carte à puce. Afin d’être indépendant de sa localisation,

le service SRV.MMI doit donc être fournit par le module M.MGR.

Il n’existe pas de standard pour ces échanges. Ce type de messages est néanmoins décrit selon une

syntaxe XML dans la spécification Calypso Specifications – Product Remote Loading publiée par

CNA (réf. 090424-ProductRemoteLoading).

Modules concernés

Le service SRV.MMI met en relation les modules suivants :

Service Modules


SRV.MMI M.MGR Gestion applicative M.MMI Interface utilisateur

5.5.12 SRV.PRM – Gestion des paramètres

Le service SRV.PRM permet de surveiller et de modifier les paramètres fonctionnement du système

d’acceptation billettique qui sont indépendants des périmètres billettiques.





Page Date

62 / 93

19 mars 2014

Modules concernés

Le service SRV.PRM met en relation les modules suivants :

Service Modules


SRV.PRM M.ADM M.ADM Administration M.MGR Gestion applicative

5.5.13 SRV.PAY – Paiement

Le service SRV.PAY transporte entre un module M.MGR (Gestion applicative) et un module

Passerelle de paiement les messages de demande de paiement et d’acquittement (positif ou non) de

ce paiement, indépendamment du moyen de paiement utilisé.


Modules concernés

Le service SRV.PAY met en relation les modules suivants :

Service Modules


SRV.PAY - Passerelle de paiement M.MGR Gestion applicative

5.5.14 SRV.CTRL – Supervision billettique

Le service SRV.CTRL permet au système d’acceptation billettique de fournir aux systèmes de

supervision de son périmètre billettique toutes les informations relatives à l’exploitation du réseau de

transport correspondant (transactions réalisées avec les objets portables, supervision du SAM, etc.),

et d’obtenir les nouveaux paramètres d’exploitation (listes noires, etc.).

Modules concernés

Le service SRV.CTRL met en relation les modules suivants :

Service Modules


SRV.CTRL - Autres systèmes M.MSG Expédition-réception

5.5.15 SRV.TECH – Supervision technique

Le service SRV.TECH permet au système d’acceptation billettique de fournir aux systèmes de

supervision de son périmètre billettique toutes les informations relatives à son fonctionnement

(rapports d’anomalie, etc.) et d’obtenir de nouveaux paramètres de fonctionnement (mise à jour de

modules, etc.).




Page Date

63 / 93

19 mars 2014

Modules concernés

Le service SRV.TECH met en relation les modules suivants :

Service Modules


SRV.TECH - Autres systèmes M.ADM M.ADM Administration

5.5.16 INT.API – API d’exécution

L’API d’exécution est l’interface programmatique fournie par l’Environnement matériel et logiciel et

permettant aux modules d’utiliser les ressources matérielles du système d’acceptation billettique.

Elle est spécifique à chaque Environnement matériel et logiciel : Linux, Windows, Java, etc.

Afin de définir des modules interchangeables entre différents fournisseurs, il est nécessaire d’utiliser

une API indépendante du matériel et du système d’exploitation.

Les standards éventuellement associés sont fonction de l’Environnement choisi (voir chapitre 5.3.11).

Modules concernés

Cette interface est utilisée par tous les modules du système d’acceptation billettique.

5.5.17 INT.SRV – Gestion de services

L’interface INT.SRV représente l’ensemble des ressources spécifiques aux services web, permettant

aux modules de communiquer entre eux. Les ressources de bases des technologies Internet sont

accessibles via l’interface INT.API (API d’exécution).

La technologie utilisée est indépendante de celle de l’Environnement matériel et logiciel.

Pour les services web eux-mêmes, les standards les plus usuels sont SOAP et REST.

Pour les mécanismes de découverte de services, les standards les plus usuels sont :

• DNS-SD (DNS Service Discovery)17 ;

• SSDP (Simple Service Discovery Protocol) ;

• UDDI (Universal Description Discovery and Integration) ;

• WS-Discovery (Web Services Dynamic Discovery).

Modules concernés

Cette interface est utilisée par tous les modules du système d’acceptation billettique.

17 DNS-SD est la technologie utilisée dans le projet EBSF.




Page Date

64 / 93

19 mars 2014

5.5.18 INT.CMD – Transport de commandes

Cette interface transporte les commandes échangées avec les objets portables ou les SAM au

travers du module Environnement matériel et logiciel, en s’appuyant sur l’interface INT.SAM (SAM)

ou EXT.PO (Objet portable).

Elle réalise également la gestion de la connexion logique aux objets portables (connexion, libération,

etc.).

Dans les systèmes d’exploitation usuels du domaine des ordinateurs personnels (Windows, Linux,

Mac OS X) l’interface standard pour les échanges avec une carte à puce (indépendamment du

protocole utilisé, avec ou sans contact) est l’API PC/SC18.

Dans l’Environnement matériel et logiciel Java, INT.CMD est l’API de la librairie

javax.smartcardio.

Cependant, ces API étant conçues pour l’utilisation de quelques cartes, elles ne sont pas adaptées

au HSM, qui se comporte comme la réunion d’un grand nombre de SAM (jusqu’à quelques milliers).

Une interface INT.CMD spécifique est donc nécessaire pour les échanges avec un HSM. La gestion

de cette interface nécessite l’installation de pilotes propriétaires dans l’Environnement matériel et

logiciel.

Modules concernés

Cette interface relie l’Environnement matériel et logiciel aux modules suivants :

Interface Modules reliés à l’Environnement matériel et logiciel

INT.CMD M.PO Commandes

M.SECU Sécurité billettique (dans le cas où un SAM est utilisé)

5.5.19 INT.SAM – SAM

L’interface avec les SAM sous forme de cartes à puce doit être conforme à la plus récente révision de

la norme ISO/IEC 7816-3 T=0 (et éventuellement T=1). Le protocole PPS doit être disponible, et doit

permettre d’atteindre un débit minimum de 200 kbps.

Dans le cas d’un HSM, dont la particularité de se comporter comme un grand nombre de SAM

simultanément disponibles, le standard PCI Express (PCIe) est généralement utilisé pour la

connexion matérielle.

Modules concernés

Cette interface relie l’Environnement matériel et logiciel aux modules suivants :

Interface Modules reliés à l’Environnement matériel et logiciel

INT.SAM M.SECU Sécurité billettique

18 Bien qu’initialement conçue pour les cartes à contact synchrones, conformes à l’ISO/IEC 7816-3, le standard PC/SC prend en compte les cartes sans contact (ISO/IEC 14443 ou non) et les cartes à contact asynchrones, qui sont hors du périmètre de l’ISO/IEC 7816-3.




Page Date

65 / 93

19 mars 2014

5.5.20 EXT.PO – Objet portable

L’interface avec les objets portable doit être conforme à la plus récente révision de la norme

ISO/IEC 14443 pour les interfaces sans contact, ou à la plus récente révision de la norme

ISO/IEC 7816-3 T=0 (et éventuellement T=1) pour les interfaces à contacts.

Interlocuteurs

Cette interface relie le système d’acceptation billettique aux interlocuteurs suivants :

Interface Interlocuteurs de l’Environnement matériel et logiciel

EXT.PO - Objets portables

5.5.21 EXT.NET – Réseau externe

L’interface EXT.NET regroupe l’ensemble des ressources de communication de l’Environnement

matériel et logiciel qui permettent de communiquer avec d’autres systèmes : Ethernet, Wifi, TCP, IP,

etc.

Interlocuteurs



EXT.NET - Autres systèmes

5.5.22 EXT.USER – Dispositifs d’IHM

L’interface EXT.USER correspond à la nature et au comportement des dispositifs d’interaction avec le

voyageur ou l’opérateur, hors objet portable.

Par exemple :

• messages affichés sur un écran.

• champs à saisir dans un formulaire ;

• nombre, couleur et comportement de voyants ;

• taille, position, couleur de boutons, ou de touches d’un clavier ;

• forme d’un boîtier (par exemple la taille et la position d’un réceptacle de carte) ;

• etc.

Interlocuteurs



EXT.USER - Voyageur, opérateur




Page Date

66 / 93

19 mars 2014

5.5.23 EXT.PHY – Environnement physique

L’interface EXT.PHY correspond à l’ensemble des interactions entre le système d’acceptation

billettique et son environnement physique.

Par exemple :

• alimentation électrique ;

• protection physique (étanchéité, résistance aux chocs, à la chaleur, à l’humidité, à l’intrusion,

aux perturbations électromagnétiques, etc.) ;

• liaison au sol ou à la maçonnerie ;

• etc.

Interlocuteurs



EXT.PHY - Environnement physique




Page Date

67 / 93

19 mars 2014

6 MODÈLES D’ARCHITECTURE

6.1 Introduction

6.1.1 Objectif

L’objectif de ce chapitre est de décrire différents modèles d’architecture de système d’acceptation

billettique, correspondant à des cas fréquents.

Ces modèles, leur sécurité, et le mode de gestion des données qui décrivent les droits de transport

sont interdépendants : une architecture meilleure dans un cas peut être moins bonne dans un autre.

Par conséquent, afin d’aider au choix des modèles à mettre en œuvre, pour chaque modèle présenté

dans les chapitres suivants sont indiqués ses avantages et inconvénients.

6.1.2 Durée de transaction perçue

Quel que soit le modèle d’architecture retenu, il doit permettre que la durée de transaction perçue par

les voyageurs soit suffisamment courte.

Cette durée correspond aux délais suivants :

• délai de transaction : durée des opérations d’accès au support de titres ;

• délai entre la constatation d’usage et la capacité à prouver la légitimité du voyage lors d’un

contrôle ;

• délai entre l’achat de droits de transport et la capacité à procéder à la première constatation

d’usage.

Par exemple :

• Dans un système Calypso classique, simultanément à la constatation d’usage sont inscrites

dans la carte les données permettant un contrôle sécurisé, ce qui constitue une transaction de

validation. Le délai perçu par le voyageur est donc uniquement la durée de cette transaction,

soit au plus quelques centaines de millisecondes.

• Dans un système à constatation d’usage sous la seule responsabilité du voyageur (tag-valideur,

etc.), les données sûres permettant le contrôle sont générées (et éventuellement inscrites dans

l’objet portable) par un autre système, une fois qu’il a reçu les données de constatation d’usage.

Le délai perçu par le voyageur est donc l’intervalle entre la constatation d’usage et le moment

où il pourra prouver à un contrôleur qu’il est en règle.

6.1.3 Disponibilité des autres systèmes

L’architecture d’un système d’acceptation billettique est fortement dépendante du niveau de

disponibilité des autres systèmes, potentiellement très éloignés :

• risques de perte totale de communication : fréquence, durée ;




Page Date

68 / 93

19 mars 2014

• temps de réponse lors des échanges ;

• dans une moindre mesure, débit d’information (le volume de données à échanger est

relativement faible).

Des systèmes distants fortement disponibles favorisent les architectures centralisées, où la plupart

des modules sont distants, et où l’objet portable contient aussi peu que possible de données

spécifiques à la billettique.

Une disponibilité moyenne peut être partiellement compensée par un modèle de gestion des droits de

transport adapté, par exemple par inscription immédiate de données temporaires ultérieurement (le

plus tôt possible) remplacées par des données plus générées (et éventuellement inscrites dans l’objet

portable) par un autre système, potentiellement très éloigné.

Une disponibilité faible limite les choix d’architecture et de modèle de gestion des droits de transport.

De plus, le modèle de gestion des droits de transport s’appliquant globalement au système billettique,

ce sont les systèmes d’acceptation billettique pour lesquels la disponibilité des systèmes distants est

la plus faible qui prévalent pour le choix de ce modèle.

6.1.4 Types d’objets portables

Les caractéristiques techniques des différents types d’objet portable déterminent les mécanismes

d’accès aux données de ces objets les mécanismes de sécurité à mettre en place dans le système

billettique, en particulier dans les systèmes d’acceptation, et le modèle de gestion des droits de

transport à mettre en place (droits de transport dans l’objet, droit au transport dans l’objet, etc.).

Une autre caractéristique majeure est le coût d’émission et de gestion des objets portables. Ce coût

doit être intégré au coût global du système billettique (coût de mise en place, et coût de gestion sur la

durée de vie du système).

Le choix d’un type d’objet portable est donc le fruit d’un compromis entre les coûts directement liés à

ces objets, et les conséquences de ce choix sur le coût des autres composants du système billettique

et sur sa sécurité.

Les principaux types d’objets portables sont :

• cartes sans contact dédiées à un bassin d’interopérabilité, par exemple :

- sécurité et interopérabilité élevées : standard Calypso ;

- sécurité et interopérabilité faibles : BSC ;

• cartes sans contact émises par des opérateurs non billettiques :

- cartes bancaires ou financière (cartes de débit, cartes de paiement, porte-monnaie

électronique, etc.) ;

- cartes d’identification (carte d’identité, carte d’étudiant, permis de conduire, etc.).

- carte de fidélité, etc. ;




Page Date

69 / 93

19 mars 2014

• objets portables NFC :

- clés USB : assimilées à des cartes sans contact d’un type correspondant au secure

element présent dans la clé ;

- téléphone mobiles : sécurisation des transactions billettiques par l’(U)SIM ou tout autre

secure element du téléphone.

6.1.5 Gestion des droits de transport

Droits de transport dans l’objet portable

La présence de la description complète des droits de transport dans l’objet portable permet aux

systèmes d’acceptation billettique de réaliser toutes les opérations possibles avec les objets portables

(contrôle, validation, débit, rechargement, etc.), les seules relations avec les autres systèmes relevant

de l’administration du système (mise à jour de règles tarifaires, gestion de listes noires, mise à jour de

logiciel, gestion de la sécurité, etc.).

Cette solution doit donc être utilisée lorsque les conditions suivantes sont réunies :

• objets portables non intégrés dans un dispositif ayant des capacités de communication avec un

autre système19, tels que les cartes sans contact, qui ne peuvent donc être traités par un

système d’acceptation billettique qu’avec la participation active du voyageur ;

• systèmes d’acceptation billettique totalement locaux, du fait d’une disponibilité faible des autres

systèmes.

En effet, si ces conditions sont réunies, une durée de transaction perçue par le voyageur (voir

chapitre 6.1.2) acceptable n’est possible qu’en stockant les droits de transport dans l’objet portable.

Les droits de transport étant dans des objets facilement accessibles à d’éventuels fraudeurs, ils

doivent être protégés contre toute modification illégitime tout en restant modifiables par les systèmes


Le cas particulier de la validation (constatation d’utilisation et consommation de droits de transport)

par débit bancaire20 (les droits de transport étant acquis et payés simultanément avec la validation)

ne sont pas dans le périmètre de ce référentiel, mais le modèle d’architecture choisi permettra de l’y

inclure si nécessaire.

Droit au transport dans l’objet portable

Ce modèle est intermédiaire entre le modèle des droits de transport (ci-dessus) et le modèle de

l’identifiant (ci-dessous).

La présence dans l’objet portable du droit au transport (déduit des droits de transport, et valide

uniquement pour le voyage en cours21) permet de réaliser localement la constatation d’usage et le

contrôle, mais nécessite une disponibilité suffisante des autres systèmes lors de la validation

(inscription dans l’objet portable de la preuve de prise en compte de la constatation d’usage).

19 Pouvant ainsi constituer tout ou partie d’un système d’acceptation billettique.

20 Aucune donnée spécifique à la billettique n’étant inscrite dans l’objet portable.

21 Et éventuellement pour le voyage suivant, en cas d’indisponibilité exceptionnelle des systèmes distants.




Page Date

70 / 93

19 mars 2014

Si le délai de validation était trop long, les cas où un contrôleur n’aurait pas de donnée fiable lui

permettant de déterminer s’il y a fraude seraient trop nombreux.

Cette solution permet un contrôle par un système d’acceptation billettique totalement local.

Elle nécessite que le voyageur possède un appareil capable de mettre en relation l’objet portable et

les autres systèmes, typiquement un téléphone mobile NFC.

Le droit au transport étant dans des objets facilement accessibles à d’éventuels fraudeurs, il doit être

protégé contre toute modification illégitime tout en restant modifiable par les systèmes d’acceptation

billettique.

Objet portable utilisé comme identifiant

Dans cette solution la seule donnée de l’objet portable utilisée par les systèmes d’acceptation

billettique est un identifiant de l’objet.

Elle nécessite que pour tous les cas d’usage de ces objets portables la disponibilité des autres

systèmes soit suffisante pour réaliser à distance toutes les opérations tout en garantissant une durée

de transaction perçue par le voyageur (voir chapitre 6.1.2) acceptable.

Si elle est applicable à tous les objets portables du bassin d’interopérabilité, alors tous les systèmes

d’acceptation billettique de ce bassin peuvent être constitués selon le modèle distant maximal (voir

chapitre 6.3).

Les objets portables, facilement accessibles à d’éventuels fraudeurs, sont exposés au risque

d’usurpation ou de génération d’un identifiant, qui est uniquement lu par les systèmes d’acceptation

billettique.

Afin de se protéger contre ce risque, il est nécessaire que l’identifiant soit sécurisé, par exemple :

• Signature stockée dans l’objet portable : une signature cryptographique, calculée à partir d’une

clé secrète et de l’identifiant (et éventuellement d’autres données), est inscrite dans l’application

avant sa mise en service. L’utilisation d’un algorithme de cryptographie asymétrique permet à

tout système d’acceptation billettique de vérifier cette signature dans délai satisfaisant et sans

nécessiter l’utilisation d’un composant physiquement protégé (SAM ou HSM). Cette solution

protège contre la création d’identifiant, mais pas contre l’usurpation, car l’identifiant et sa

signature peuvent être dupliqués. Cette protection peut néanmoins être suffisante dans les cas

où la duplication n’est pas exploitable, par exemple pour un identifiant à usage unique tel qu’un

billet de train valide pour un voyage donné (caractérisé par la combinaison d’un no de train, d’un

no de place, d’une date, du nom et prénom du voyageur, etc.).

• Authentification dynamique : l’application qui contient l’identifiant produit le résultat d’un calcul

cryptographique dépendant d’un challenge variable qui lui est fourni, d’un secret et de

l’identifiant (et éventuellement d’autres données). Les algorithmes de cryptographie

asymétrique étant trop complexes pour les performances des cartes à puces, y compris pour

les cinq à dix ans à venir, ce calcule doit être réalisé à partir d’algorithmes symétriques (DESX,

triple DES ou AES). Cette solution protège à la fois contre l’usurpation et la création

d’identifiants, mais nécessite que le système d’acceptation billettique dispose d’un composant

physiquement protégé (SAM ou HSM).




Page Date

71 / 93

19 mars 2014

Open Payment

Dans le contexte billettique, l’« Open Payment » consiste pour un valideur billettique à accorder des

droits de transport sur la base d’une transaction bancaire de paiement réalisée avec une carte

bancaire sans contact (ou un téléphone mobile NFC assurant les mêmes fonctions). Durant cette

transaction, aucune donnée billettique n’est inscrite dans la carte bancaire.

Le présent référentiel prend en compte ce mode de validation par l’intermédiaire des modules M.APP

(Accès à l’application) et M.MGR (Gestion applicative), qui mettent en relation la carte bancaire et la

Passerelle de paiement, le module M.MGR définissant le montant du paiement et prenant note de

son bon déroulement. Ces modules peuvent être spécifiques à l’Open Payment.

Le diagramme ci-dessous représente les modules et services directement mise en œuvre pour ce

type de transaction.


Domaine billettique

EXT.PO

EXT.NET

EXT.PO

INT.API

INT.SRV

SRV.SAM

SR

V.A

PP

SRV.PO

SR

V.A

CC

SR

V.S

EC

U

SRV.AUTH

SRV.TRG

INT.C

MD

SRV.MOD

SRV.MSG

SRV.MMI

SRV.PRM

SRV.PAY

EXT.USER

EXT.PHY

INT.SAM

INT

.AP

I

INT

.SR

V

Objet

portable ABC

Objets

portables

non ABC

Autres

systèmes

M.MSG

Passerelle de

paiement

M.MGR

M.TRF

Environ-

nement

matériel et

logiciel

M.MOD

M.TRG

M.SECU

M.APP

M.PO

M.ADM

M.MMI

SRV.TECH

SRV.CTRL

Référence

Services :

Fournis-

seur

Utilisa-

teur

SR

V.T

RF

Les services et interfaces spécifiquement mise en œuvre sont :

• EXT.PO (Objet portable) : communications sans contact avec la carte bancaire ;

• INT.CMD (Transport de commandes) : transport par l’environnement des commandes

permettant la détection d’une application bancaire ;




Page Date

72 / 93

19 mars 2014

• SRV.PO (Commandes objet portable) : M.APP indique à M.PO sa volonté de traiter les

applications ayant un AID bancaire, et M.PO indique à M.APP la disponibilité d’une telle

application ;

• SRV.APP (Gestion des applications) : M.MGR indique à M.APP sa volonté de traiter les

applications bancaires, et M.APP indique à M.MGR la disponibilité d’une telle application ;

• SRV.PAY (Paiement) : M.MGR demande à la Passerelle de paiement la réalisation d’un

paiement, et reçoit en retour le statut de l’opération.

6.2 Modèle totalement local

Lorsque tous les modules d’un système d’acceptation billettique sont locaux, aucune des opérations

qu’il doit réaliser avec les objets portables (contrôle, validation, débit, rechargement, etc.) ne

nécessite d’échanges simultanés avec d’autres systèmes.

Les seules relations avec les autres systèmes concernent de l’administration du système : mise à jour

de règles tarifaires, gestion de listes noires, mise à jour de logiciel, administration du SAM, etc.

Ce modèle est nécessaire lorsque la disponibilité des autres systèmes ne permet pas d’y déporter

certains des modules du système d’acceptation billettique.

Du fait de l’amélioration continue des réseaux de données, ce modèle sera sans doute de moins en

moins incontournable pour les équipements fixes pour lesquels la durée de la transaction avec l’objet

portable n’est pas critique, comme par exemple les automates de distribution de titres de transport.

En revanche, il sera probablement encore pertinent pendant plusieurs années pour les équipements

embarqués dans des véhicules (valideur bus, etc.) ou d’utilisation nomade (portable de contrôle).

Utilisation d’un SAM

Selon le principe retenu pour la gestion des droits de transport (voir chapitre 6.1.5), et le niveau de

sécurité choisi, la protection contre la fraude peut nécessiter l’utilisation d’un SAM22.

Ce SAM étant local, il est exposé à un risque de mésusage (suite à un vol ou un piratage, par

destruction, etc.). Il peut alors être nécessaire de mettre en place des protections particulières,

nécessitant éventuellement des mises à jour périodiques, comme le mécanisme de plafond des SAM

Calypso.

L’utilisation d’un SAM peut également être nécessaire pour sécuriser le fonctionnement du système

d’acceptation billettique, par exemple pour authentifier les données échangées avec les autres

systèmes23.

22 Y compris pour les équipements de contrôle, pour vérification de l’authenticité des données de l’objet portable données prouvant la légitimité du voyage (droits de transport authentiques, droit au transport authentique, identifiant authentique, etc.).

23 Par exemple, dans le cas d’un équipement de distribution de titres équipé d’un monnayeur mais réalisant la vente à l’aide d’un système de vente à distance, un SAM local pourrait néanmoins s’avérer nécessaire afin de s’assurer que l’équipement ayant perçu un paiement en numéraire était légitime.




Page Date

73 / 93

19 mars 2014

Coût global

La partie du coût global liée aux équipements locaux est plus élevée que dans les modèles distants,

car ces équipements comportent tous les modules d’un système d’acceptation billettique.

En revanche, le système d’acceptation billettique totalement local pouvant fonctionner de façon

autonome pendant une durée assez longue (quelques jours), la partie du coût global liée à la

l’infrastructure de communication est plus faible que dans les modèles distants.

6.3 Modèle distant maximal

Le « modèle distant maximal » correspond à un système d’acceptation billettique dont toutes les

fonctions qu’il est possible de traiter à distance le sont.

Dans le diagramme ci-dessous, qui représente ce modèle, les seules fonctions traitées localement

sont celles assurées par les modules suivants, principalement le module M.PO (Commandes) pour

les échanges d’APDU avec le sous-ensemble distant réalisant les traitements tarifaires et pour les

accès à l’objet portable.




Page Date

74 / 93

19 mars 2014

Système d’acceptation billettique – Sous-ensemble distant 1


Sous-ensemble local

Domaine billettique

Objet

portable ABC

Objets

portables

non ABC

Environ-

nement

matériel et

logiciel


Sous-ensemble distant 2

Domaine billettique

Environ-

nement

matériel et

logiciel

Environ-

nement

matériel et

logiciel

Systèmes

distantsSystèmes

distantsAutres

systèmes

Domaine billettique

CommandesM1

Passerelle de

paiementAdministration

M.ADM

Expédition-réception

M.MSG

Règles tarifairesRègles tarifairesRègles tarifairesM.TRF

Gestion

applicative

M.MGR

M.A

PP

AdministrationM.ADM

AdministrationM.ADM

M.S

EC

U

SAM / HSM

ABC

SAM / HSM

non ABC

TriangleM.TRG

Autres

technologies

Calypso

M.M

OD

IntercodeAutres

modèles de

données

Interface

utilisateur

M.MMI

Interface

utilisateur

M.MMIGestion

applicative

M.MGR

Gestion

applicative

M.MGR

Des modèles proches, où quelques modules supplémentaires sont présents localement, par exemple

le module M.APP (Accès à l’application), sont possibles sans remise en cause des avantages

principaux du modèle distant maximal.

Utilisation d’un SAM

Ce modèle ne peut pas s’appliquer lorsqu’il est nécessaire de sécuriser le fonctionnement du sous-

ensemble local du système d’acceptation billettique. Par exemple, dans le cas d’un équipement de

distribution de titres équipé d’un monnayeur mais réalisant les opérations de vente à l’aide d’un

système de vente à distance (par exemple en utilisant un HSM), un SAM local pourrait néanmoins

s’avérer nécessaire afin de s’assurer que l’équipement ayant perçu le paiement en numéraire était

légitime.

Coût global

La partie du coût global liée aux équipements locaux est plus faible que dans les modèles locaux, car

ces équipements comportent peu de modules, qui sont de plus génériques.




Page Date

75 / 93

19 mars 2014

Cependant, la partie locale d’un système d’acceptation billettique totalement distant ne pouvant pas

fonctionner de façon autonome, la partie du coût global liée à la l’infrastructure de communication est

plus importante que dans les modèles locaux.

6.4 Modèles hybrides

Les modèles hybrides correspondent à des systèmes d’acceptation billettique pour lesquels la

localisation ou la temporalité des traitements est variable.

Par exemple, pour un équipement de vente :

• opérations de vente réalisées localement (SAM local), mais opérations de personnalisation

réalisées avec des traitements distants (HSM distant) ;

• traitement totalement local pour un périmètre billettique, et distant pour un autre ;

• traitement totalement local pour certains objets portables, et distant pour d’autres ;

• traitement décomposé en deux transactions successives, la première réalisée localement, de

façon autonome, lors de l’accès au transport (par exemple une montée dans un véhicule), et la

seconde réalisée ultérieurement avec l’aide d’équipements distants pour finaliser la mise à jour

des données de l’application.

Coût global

Le coût global de systèmes d’acceptation billettique en modèle hybride est très variable. Il s’étudie au

cas par cas, relativement au coût d’autres solutions.

Par exemple, dans le cas de la mise en service de nouveaux objets portable dans un système

existant, il peut être intéressant de traiter ces nouveaux objets selon le modèle distant maximal, ce

qui peut éviter des interventions matérielles et limiter les modifications logicielles sur les équipements

déjà installés, en continuant à traiter les précédents objets portables localement.

Particularités de la solution « tag-valideur »

L’architecture décrite dans ce référentiel prend en compte les modèles hybrides, dont un exemple est

la solution « tag-valideur », basée sur l’utilisation des téléphones mobiles NFC des voyageurs et

d’étiquettes NFC installées dans le réseau de transport.

Les transactions de validation (constatation d’usage, et consommation des droits de transport

correspondants si nécessaire) sont alors basées sur le mécanisme suivant :

• lors de l’accès au transport, le voyageur lit avec son téléphone l’étiquette NFC disposée à

proximité ;

• l’application du téléphone obtient les informations contenues dans l’étiquette (dont sa

localisation). Il peut également inscrire les données de validation correspondantes dans une

cardlet d’un secure element du téléphone ;

• dès que le réseau de données est disponible (3G, Wifi, etc.) le téléphone fournit les données de

validation à un serveur dédié et lui fournit les données de validation. Il peut également mettre

en relation le serveur et la cardlet du secure element, pour authentification cryptographique.




Page Date

76 / 93

19 mars 2014

Cette solution permet par exemple de déployer une offre sur téléphones mobiles NFC dans un

système billettique existant, même assez ancien24 , en ne mettant à jour que les terminaux de

contrôle.

Elle suppose un réseau sans barrières (tripodes, portillons, etc.) aux accès. De plus, n’étant pas

généralisable à tous les clients, elle doit coexister avec d’autres solutions.

L’utilisation d’une cardlet permet un niveau de sécurité plus élevé.

Le stockage de données de validation dans le téléphone permet l’utilisation de terminaux de contrôle

ne disposant pas d’une liaison permanente avec un serveur billettique. Cependant, l’environnement

logiciel et matériel d’un téléphone mobile étant peu sûr, il est fortement recommandé de stocker les

données de validation dans une cardlet et de les authentifier dès que possible avec un serveur.

Cette solution apparait attrayante du fait du faible coût d’acquisition et de mise en place d’étiquettes

NFC (relativement au coût de valideurs traditionnels). Il ne faut cependant pas négliger les coûts

spécifiques aux solutions à base de téléphones mobiles NFC (mise à disposition des secure

elements, développement et maintenance des logiciels des téléphones, etc.).

6.5 Coexistence de différents modèles

Le système billettique d’un bassin d’interopérabilité donné peut utiliser des systèmes d’acceptation

billettique d’une grande variété de modèles d’architectures, selon le type d’équipement25, selon le

type d’objet portable, etc.

24 Par exemple un système billettique dont les terminaux ne traiteraient que le protocole sans contact des cartes Calypso Revision 1 (« protocole Innovatron », également appelé « protocole B prime »).

25 Par exemple, une solution de vente à distance via l’ordinateur personnel des clients (modèle distant maximal) peut cohabiter avec des automates de distribution autonomes (modèle totalement local).




Page Date

77 / 93

19 mars 2014

7 VALIDATION DU RÉFÉRENTIEL

7.1 Pertinence des modules

Le tableau ci-dessous synthétise les évaluations de la réponse de chaque module à leurs critères de

définition26, qui correspond à la réponse à la question suivante : « dans quelle mesure le découpage

réalisé donne-t-il la meilleure réponse au critère considéré ? ».

Module

Critère

1

Spécificité

2

Évaluation

3

Standardisation

4

Évolutivité

5

Disponibilité

M.PO Commandes Très bonne Très bonne Très bonne Bonne Très bonne

M.SECU Sécurité

billettique Très bonne Très bonne Très bonne Bonne Très bonne

M.APP Accès à

l’application Très bonne Bonne Très bonne Bonne Bonne

M.TRG Triangle Très bonne Très bonne Très bonne Très bonne Très bonne

M.MOD Modèle de

données Très bonne Très bonne Très bonne Bonne Très bonne

M.TRF Règles tarifaires Très bonne Très bonne Très bonne Bonne Très bonne

M.MGR Gestion

applicative Très bonne Très bonne Très bonne Très bonne Bonne

M.MSG Expédition-

réception Très bonne Très bonne Très bonne Bonne Très bonne

M.MMI Interface

utilisateur Bonne Bonne Très bonne Bonne Bonne

M.ADM Administration Bonne Très bonne Très bonne Très bonne Très bonne

Exemple : Selon le critère Évaluation, la pertinence du module M.TRF (Règles tarifaires) est très

bonne, bien que l’évaluation de ce module soit difficile à réaliser (manque de procédures

d’évaluation, qui de plus dépendent fortement de la diversité des règles tarifaires

existant). En effet, une modification de son contour (y ajouter des traitements ou en

retirer) n’en faciliterait pas l’évaluation, il s’agit donc bien du meilleur découpage possible.

26 Le critère d’abstraction et le critère de performance étant constitutifs du référentiel, ils ne sont pas évalués.




Page Date

78 / 93

19 mars 2014

7.2 Objectifs du référentiel

7.2.1 Évolutions normatives liées au transport

Les normes et standards dédiés aux transports publics27 qui s’appliquent, ou pourraient s’appliquent

dans les prochaines années, aux systèmes d’acceptation billettique, évoluent régulièrement.

Les modules qui constituent le référentiel recoupent ces normes et standards, de sorte que l’évolution

de l’un d’entre eux de nécessite pas la modification de la totalité du système d’acceptation billettique :

Normes/standards Modules

Échanges entre les systèmes d’acceptation billettique et les autres systèmes : à l’heure

actuelle ces échanges ne sont pas normalisés. M.MSG

Modèle de données permettant de décrire les droits de transport : en France il s’agit de la

norme Intercode (NF P 99-405), d’autres standards existent en Europe (notamment VDV en

Allemagne et ITSO au Royaume Uni).

Modèle de données intermédiaire, qui organise la cohabitation de modèles de données

hétérogènes au sein de la même application : application Triangle 2.

M.MOD

M.TRG

Échanges avec les applications des objets portables : standard Calypso, spécifications

propriétaires.

M.APP

M.SECU

Protocole sans contact : référentiel sans contact AFIMB, protocoles propriétaires. M.PO

7.2.2 Évolutions sécuritaires

Du fait des impératifs de performance, l’authentification mutuelle entre l’objet portable et le système

d’acceptation billettique utilise une cryptographie de type symétrique, qui impose aux systèmes

d’acceptation billettique d‘avoir accès à un composant matériel sûr (SAM ou HSM).

Les techniques d’agression envers les algorithmes cryptographiques, envers leur implémentation et

envers les composants sûrs s’améliorant avec le temps, il est nécessaire de les mettre à jour tous les

cinq à dix ans.

Afin de limiter l’impact de ces évolutions sur le coût global du système billettique, grâce à l’utilisation

de services web pour la réalisation des interfaces, le module M.SECU (qui réalise les traitements

cryptographique) peut être placé à distance des objets portables, par simple paramétrage du module

M.APP (avec lequel M.SECU communique). Cela permet par exemple de mutualiser M.SECU pour

un grand nombre de systèmes d’acceptation billettique. Il suffit alors de le mettre à jour pour que tous

les systèmes d’acceptation billettique qui l’utilisent soient également à jour.

Le référentiel prend également en compte la possibilité de traiter la fonction SAM comme un

composant logiciel s’exécutant dans un composant matériel sécurisé. Il faut toutefois noter que cette

solution ne permet que l’amélioration de la résistance aux attaques sur les algorithmes ou sur leur

implémentation. Pour améliorer la résistance aux agressions physiques il reste nécessaire de

27 Ou conçus en tenant compte de contraintes spécifiques aux transports publics.




Page Date

79 / 93

19 mars 2014

remplacer le composant matériel. De plus, cette solution a des contraintes qui lui sont propres, car le

composant logiciel est lui-même un élément très sensible de la chaîne de sécurité, qui doit être géré

avec des protections adéquates28.

7.2.3 Évolutions des usages

Cas d’usage des objets portables et des systèmes d’acceptation billettique sont en constante

évolution. Par exemple, depuis quelques années se développent des solutions en ligne permettant le

paiement au valideur, l’autorisation de paiement en ligne ou la télécollecte des transactions.

La modularité du référentiel, son indépendance vis-à-vis du matériel, et vis-à-vis de la localisation de

chaque module, lui donne une grande souplesse qui permet la prise en compte des nouveaux usages

sans remise en cause des investissements initiaux.

7.2.4 Évolutions des politiques tarifaires

La fonction d’un système d’acceptation billettique la plus susceptible de variations d’un domaine

billettique à un autre, et d’évolutions fréquentes, est le logiciel en charge les données des objets

portables conformément à al politique tarifaires du domaine billettique.

Par conséquent, le référentiel a isolé cette fonction au sein d’un module, M.TRF, de sorte que les

règles tarifaires puissent subir des variations ou des évolutions majeures avec un minimum d’impact

sur le logiciel des équipements existants.

7.3 Cas typiques

Afin d’illustrer la pertinence du référentiel, ce chapitre présente son application à quelques cas

d’évolution d’un système billettique.

Introduction d’un nouveau titre de transport

Dans le cas de la mise en place d’un titre de transport basé sur de nouveaux principes de tarification,

la modularité du référentiel et la généricité de ses interface permettent ne pas remplacer la totalité du

logiciel des systèmes d’acceptation billettique, mais uniquement le module en charge des règles

tarifaires, M.TRF. De plus, il est possible de concevoir un module générique, utilisable dans des

équipements de fournisseurs différents.

Changement de délégataire de service public

À l’occasion des renouvellements d’attribution de marché de délégation de service public, la mise en

place d’un nouveau système billettique doit pouvoir se faire à moindre coût. Le risque de surcoût

porte essentiellement sur les systèmes d’acceptation billettique, qui sont nombreux, dispersés, et

parfois d’accès complexe pour les opérations de maintenance.

28 Dans le cas du téléphone mobile NFC utilisé comme système d’acceptation billettique Calypso, ces problématiques sont décrites dans le document « Calypso Specification – Calypso SAM in a NFC phone » (réf. 120214-SamNfcPhone).




Page Date

80 / 93

19 mars 2014

L’architecture définie dans ce référentiel assure l’indépendance entre le logiciel billettique (domaine

billettique) et son environnement d’exécution (environnement matériel et logiciel). Ainsi, pour adapter

des systèmes d’acceptation billettique existants à un nouveau système billettique, le nouvel opérateur

peut conserver les matériels existants et ne remplacer que les modules nécessaires. Au mieux, il n’y

a aucun module à remplacer, et il suffit de réaliser un nouveau paramétrage. Au pire, l’ensemble des

modules du domaine billettique est remplacé.

Ajout d’équipements à un système existant

Lors de l’extension d’un réseau de transport, il faut ajouter des systèmes d’acceptation billettique

sans remise en cause du système billettique existant. Le référentiel le permet par la généricité de ses

interfaces externes (SRV.TECH et SRV.CTRL).




Page Date

81 / 93

19 mars 2014

8 SUITE DU RÉFÉRENTIEL

8.1 Spécifications

À la suite de la publication du référentiel, il conviendra de poursuivre les travaux du groupe des par la

rédaction de deux types de spécifications :

• dans un premier temps : exigences fonctionnelles d’une architecture modulaire des systèmes

d’acceptation billettique ;

• dans un second temps : spécifications techniques des interfaces et services.

Exigences fonctionnelles d’une architecture modulaire des systèmes d’acceptation billettique

Il s’agit de rédiger et de proposer au plus tôt aux AOT un recueil des exigences fonctionnelles d’une

architecture modulaire des systèmes d’acceptation billettique, destiné à être intégré dans les appels

d’offre « billettique » ; l’accent sera mis sur les services web et les environnements matériels et

logiciels génériques, il sera précisé que le fournisseur retenu devra publier la description des

interfaces et des services de sa solution.

Les solutions conformes au référentiel publiées par les fournisseurs pourront être prises en compte

lors de la rédaction des spécifications techniques, et de leur évolution vers un standard international

(voir chapitre 8.3).

Une intégration rapide de ce canevas dans les appels d’offre des AOT permettra de limiter le risque

de retarder l’application par les fournisseurs des grands principes du référentiel.

Spécifications techniques des interfaces et services

Ce référentiel est un guide pour la rédaction des spécifications techniques des services et des

interfaces entre les modules d’un système d’acceptation billettique. Ces spécifications garantiront

l’interopérabilité entre les modules, et leur interchangeabilité.

Deux étapes sont prévues : dans un premier temps la rédaction de spécifications fonctionnelles pour

chaque service et interface, puis la rédaction des spécifications détaillées correspondantes. La

réalisation d’un pilote ou d’un démonstrateur permettrait d’éprouver les choix techniques faits lors de

la rédaction, et si nécessaire de les amender.

L’architecture décrite dans ce référentiel se fonde sur la séparation entre les modules et leur

environnement matériel et logiciel. Les interfaces qui permettent cette séparation doivent être traitées

en priorité, afin que les fournisseurs d’équipements puissent les prendre en compte au plus tôt.

Le risque que les AOT ayant déployé des systèmes d’acceptation avant la publication des

spécifications techniques soient contraintes de gérer pendant plusieurs années des systèmes non

standards sera d’autant plus faible que le délai de publication des spécifications techniques sera

réduit. En tout état de cause, il est préférable pour une AOT de disposer d’un système modulaire non

standard qu’à disposer d’un système non modulaire.




Page Date

82 / 93

19 mars 2014

8.2 Standardisation/normalisation

L’un des critères de définition des modules est la capacité de leurs interfaces à devenir des standards

internationaux (voir le chapitre 5.1.5). Ce critère sera respecté lors de la rédaction des spécifications

techniques, qui seront proposées aux organismes de normalisation internationaux appropriés dès

qu’elles seront suffisamment stabilisées.

Concernant le traitement de l’ABC, tous les modules devraient pouvoir être génériques, sauf celui des

règles tarifaires, M.TRF.

8.3 Certification

Pour la mise en place de la certification d’un système, deux approches peuvent être étudiées :

• certification globale : le système est considéré comme une boîte noire. Toute modification de du

système, même n’affectant qu’un de ses sous-ensembles, nécessite une certification globale ;

• certification par sous-ensemble : les différents sous-ensembles qui constituent le système sont

certifiés indépendamment les uns des autres. Une modification du système ne nécessite la

certification que des sous-ensembles concernés.

Une certification globale peut convenir à un système évoluant relativement peu. Mais plus un système

est sujet à de fréquentes évolutions, plus la certification par sous-ensemble est efficace.

Les objectifs de ce référentiel étant en particulier l’efficacité de la mise en œuvre d’évolutions

fréquentes, l’approche de certification qui conviendra le mieux au référentiel est la certification par

sous-ensemble. Ces objectifs ayant naturellement amené à la définition d’une architecture modulaire,

cette architecture est parfaitement adaptée à la certification par sous-ensemble.

La procédure de certification qui sera définie et mise en place à la suite de la publication des

spécifications détaillées devra donc permettre de certifier chaque module indépendamment des

autres29.

Environnements génériques

Il faudra veiller à ce que les mécanismes de certification mis en place permettent de profiter

pleinement de l’offre de matériels et logiciels massivement utilisés dans d’autres domaines d’activité,

ce qui est un des moyens d’atteindre les objectifs du référentiel de par son potentiel de réduction des

coûts globaux.

8.4 Évolutions techniques

L’horizon d’application pratique de ce référentiel est à cinq à dix ans. Dans cet intervalle, des

évolutions technologiques pourraient offrir des opportunités d’évolution du référentiel.

29 L’intégrateur des modules qui constituent un système d’acceptation billettique est responsable de la vérification du fonctionnement du système complet, par exemple pour ce qui concerne les performances.




Page Date

83 / 93

19 mars 2014

Ce chapitre présente, de façon non exhaustive, des évolutions qui peuvent être envisagée à la date

de publication du référentiel.

ISO/IEC 14443

Le groupe de travail de l’ISO en charge de la norme ISO/IEC 14443 prépare une extension à des

vitesses de communications supérieures, et un mécanisme de dialogue entre équipements actifs

(fonctionnellement similaire au mode « pair à pair » du standard NFC). Atteindre ces performances ou

bénéficier de ce nouveau mode de dialogue nécessiterait une mise à jour matérielle des systèmes

d’acceptation billettique actuels30. Cependant, du fait que le volume de données échangé lors d’une

transaction billettique est relativement faible, et que les objets portables non alimentés resteront très

utilisés, il ne semble pas nécessaire de les prendre en compte.

NFC : mode pair à pair

L’utilisation du mode pair à pair du standard NFC, qu’actuellement les équipements billettiques ne

peuvent pas traiter, pourrait se développer. Les équipements billettiques récents (ainsi que ceux des

années à venir) pourraient permettre ce mode NFC, il serait donc possible de l’activer par mise à jour

logicielle.

L’un des intérêts du mode pair à pair serait de traiter la carlet à travers la midlet, de sorte que la

midlet serait automatiquement informée de l’état courant de la cardlet. Cependant, une

désynchronisation resterait possible en cas de batterie épuisée. Le mode émulation carte devrait

donc rester disponible, et un mécanisme de gestion de la désynchronisation serait obligatoire. Enfin, il

sera peut-être possible à l’avenir de traiter la carlet à travers la midlet également en mode émulation

carte.

Bluetooth Low Energy

Le standard Bluetooth a introduit dans sa version 4 un mode de fonctionnement à très faible

consommation, dit « low energy » (LE), pour lequel des produits de contrôle d’accès à des locaux ont

été annoncés.

Mais à la date d’émission de ce référentiel, il ne semble pas y avoir eu d’étude sur une éventuelle

utilisation de cette technologie (ou d’une technologie équivalente) pour la billettique.

Du fait de l’obligation d’un geste volontaire du voyageur pour déclencher la transaction sans contact,

une des questions à traiter est celle de la portée. En particulier, dans le cas de valideurs proches les

uns des autres (et équipés d’une barrière), il faut que le voyageur puisse choisir facilement la barrière

qu’il souhaite ouvrir.

Les systèmes d’acceptation billettique actuels ne supportant généralement pas la technologie

Bluetooth, sa mise en service supposerait la mise à jour matérielle de tous les équipements, mais

sans remise en cause de ce référentiel.

30 Et probablement également ceux qui seront mis en service pendant quelques années, à cause des délais de publication de la révision de la norme, des délais de disponibilité de composants qui la prendront en compte, et des délais de disponibilité d’équipements utilisant ces composants.




Page Date

84 / 93

19 mars 2014

Triangle et Calypso

L’application billettique commune est basée sur l’application Triangle, elle-même basée sur les

spécifications Calypso Revision 3.

CNA a publié récemment la version 3.2 de la spécification Calypso Revision 3, qui propose les

nouvelles fonctionnalités suivantes :

• Support de clés AES.

• Chiffrement des échanges.

• Authentification préalable.

L’application Triangle 2 pourrait évoluer par la prise en compte des ces fonctionnalités, en particulier

les clés AES (ce qui pourrait n’affecter que le module M.SECU).




Page Date

85 / 93

19 mars 2014

9 ANNEXES

9.1 Glossaire

Les définitions ci-dessous décrivent des termes spécifiques à la billettique, ou l’utilisation spécifique à

la billettique de termes génériques.

ABC Voir application billettique commune.

AES Advanced Encryption Standard (également appelé Rijndael). Algorithme

de chiffrement symétrique conçu pour améliorer l’algorithme DES. Il

utilise des clés de 128, 192 ou 256 bits, et traite des blocs de données de

128 bits.

AMO Assistant à Maîtrise d’Ouvrage. Entité qui assiste le maître d‘ouvrage à

définir, piloter et exploiter un projet.

AOT Autorité Organisatrice de Transports. Selon le code des transports :

collectivité ayant pour mission d’organiser les transports publics.

API Application Programming Interface. Ensemble cohérent de ressources

logicielles mises à disposition par une bibliothèque logicielle, un système

d'exploitation ou un service.

Applet Logiciel applicatif s’exécutant dans le contexte d’un système

d’exploitation ouvert. Désigne le plus souvent un logiciel pour système

d’exploitation Java (ordinateurs personnels, carte à puce, téléphone,

etc.).

Application Ensemble cohérent des structures, éléments de données et modules

logiciels d’un secure element qui sont nécessaires à la réalisation de

fonctionnalités spécifiques (définition conforme à l‘ISO/IEC 7816-4:2005

et à ISO/IEC 7816-5:2004).

Application billettique Application dédiée à la gestion de l’accès aux transports publics

(définition conforme au DOcument FOnctionnel COmmun de la billettique

sur Mobile NFC).

Application billettique commune Application billettique permettant de stocker et d’utiliser des titres

occasionnels de tous les territoires qui l'acceptent, ainsi que des titres

interrégionaux. Elle est basée sur les spécifications Triangle et Calypso

Révision 3 de Calypso Networks Association.

Application d’interface voyageurs Dans un objet portable, ensemble des ressources logicielles externes

aux secure elements qui permettent à un utilisateur, via les dispositifs de

saisie et d’affichage de cet objet, de gérer les données d’applications

billettiques, en particulier celles des secure elements intégrés à cet objet

(définition conforme au DOcument FOnctionnel COmmun de la billettique

sur Mobile NFC).




Page Date

86 / 93

19 mars 2014

Application transport Ensemble des ressources logicielles d’un objet portable spécifiquement

dédiées à l’utilisation d’un système billettique (définition conforme au

DOcument FOnctionnel COmmun de la billettique sur Mobile NFC).

Par exemple :

- Pour une carte sans contact, une application transport est une

application billettique.

- Pour un téléphone mobile NFC, une application transport est la

combinaison d’une application billettique et d’une application

d’interface voyageurs.

Asymétrique Appliqué à la cryptographie, asymétrique désigne une méthode de

chiffrement qui repose sur l'utilisation d'une clé publique (qui est diffusée)

et d'une clé privée (gardée secrète par son détenteur). Ainsi, lors de

l’échange d’un message, l’interlocuteur qui utilise la clé publique n’a pas

besoin de protection (matérielle ou logicielle) pour cette clé.

Confidentialité : un expéditeur quelconque peut envoyer un message

chiffré avec la clé publique d’un destinataire choisi, qui est le seul à

pouvoir le déchiffrer avec sa clé privée.

Authenticité : il est possible de produire une signature avec la clé privée

et de la vérifier avec la clé publique, ce qui permet à quiconque de

vérifier l’authenticité des données ainsi signées.

RSA et ECC sont des algorithmes asymétriques.

Les calculs basés sur un algorithme asymétrique nécessitent des

ressources beaucoup plus importantes qu’avec un algorithme

symétrique.

Bassin Sauf indication contraire, dans ce document l’utilisation isolée du terme

bassin désigne un bassin d’interopérabilité.

Bassin d’interopérabilité Zone géographique sous la responsabilité d’une AOT.

Billet sans contact Carte à mémoire strictement sans contact, de sécurité rudimentaire,

généralement partiellement conforme à l’ISO/IEC 14443.

Par exemple, les produits « CTM512 », « SRT512 » et « Mifare

Ultralight » sont des billets sans contact.

Billettique Désigne indifféremment (conformément au DOcument FOnctionnel

COmmun de la billettique sur Mobile NFC) :

- L’ensemble des procédés et outils de gestion des contrats liant les

producteurs d’offre de déplacement, les financeurs et les utilisateurs

de cette offre dans lequel les billets papier ont été remplacés par des

supports de technologie plus avancée (carte à puce, carte magnétique,

etc.).

- L’ensemble des dispositifs utilisant l'informatique et l'électronique dans

les titres représentatifs d'une prestation de transport.

BSC Voir billet sans contact.

Cardlet Applet fonctionnant dans un secure element, dans un environnement

Java Card.

Certificat Données non confidentielles associées à un MAC ou à une signature qui

permet de les authentifier. Parfois utilisé comme synonyme de MAC ou

de signature.




Page Date

87 / 93

19 mars 2014

Clé Valeur numérique utilisée comme paramètre d’un algorithme

cryptographique. Une clé peut être secrète ou publique.

Composant Élément matériel ou logiciel accomplissant automatiquement un

ensemble de tâches.

Composite S’appliquant à un objet portable, indique que le secure element considéré

dans cet objet lui est lié mécaniquement (et non intrinsèquement), et peut

éventuellement en être ôté.

Un téléphone mobile NFC est un objet portable composite typique, à la

différence d’une carte à puce sans contact.

Contrat Sauf indication contraire, dans ce document l’utilisation isolée du terme

contrat désigne un jeu de données décrivant des droits de transport.

Habituellement, chaque contrat correspond à un titre de transport tel que

décrit par l’offre commerciale : billet unitaire, carnet, abonnement, etc.

Dans certains cas, un contrat peut également être utilisé pour décrire des

profils ou le droit au transport.

DES Data Encryption Standard (également appelé DEA, Data Encryption

Algorithm). Algorithme de chiffrement symétrique qui utilise des clés de

56 bits (ce qui en fait un algorithme obsolète), et traite des blocs de

données de 64 bits.

DESX Extension de l’algorithme DES, utilisant des clés de 120 bits. Dans le

contexte Calypso, les 128 bits de la clé sont utilisés.

Distant Désigne un équipement (ou la réalisation d’un traitement) ne se trouvant

pas à proximité immédiate de l’objet portable, par exemple des systèmes

centraux.

Diversification Dans le contexte des clés cryptographiques et des applications de cartes

à puce, calcul à partir d’une clé constante (dite clé maître) et d’une valeur

identifiant une application d’une nouvelle clé (dite clé diversifiée), propre

à cette application.

Domaine billettique Ensemble des modules d’un système d’acceptation billettique dont les

fonctions sont dédiées à la billettique.

Tous les modules du domaine billettique communiquent entre eux par

des services web. Pour les interactions avec les modules externes au

domaine billettique ils peuvent également utiliser des interfaces.

Droit au transport Données minimum nécessaires à la réalisation immédiate et sans

connexion à un autre système d’une constatation d’utilisation, obtenues

par analyse des droits de transport.

Le droit au transport est stocké dans une application, par exemple sous

la forme d’un unique contrat.

Après la constatation d’utilisation, le droit au transport est actualisé dès

que possible.

Droits de transport Données décrivant complètement et en détails les paramètres des

voyages autorisés (zone géographique, moyens de transport, nombre de

trajets, distance, période de validité, etc.).

Les droits de transports sont généralement structurés sous forme de

contrats.

DSP Délégataire de service public.




Page Date

88 / 93

19 mars 2014

ECC Elliptic Curve Cryptography. Algorithme cryptographique asymétrique

basé sur la structure algébrique des courbes elliptiques sur les corps

finis.

Par rapport aux autres algorithmes asymétriques, leur avantage est

d’utiliser des clés de taille très inférieure, pour une sécurité équivalente.

Exploitant Dans ce document, utilisé exclusivement comme synonyme d’opérateur

de transport, afin d’éviter les confusions avec les opérateurs d’autres

types de services.

HSM Hardware Security Module. Équipement connecté à un ordinateur d’un

système central, possédant les protections matérielles et logicielles

nécessaires au stockage et à l’utilisation de données secrètes (telles que

des clés cryptographiques) et éventuellement de données afférentes,

avec une capacité de traitement importante.

Sauf indication spécifique, dans ce document, le terme SAM s’applique

également aux HSM.

IFM Interoperable Fare Management, ensemble des normes relatives aux

systèmes de gestion tarifaire interopérables (voir chapitre 9.2).

IHM Interface homme-machine, partie d’un système réalisant une interaction

avec une personne sans utiliser d’équipement intermédiaire (écran,

clavier, souris, voyant lumineux, buzzer, etc.).

Initialisation Phase de configuration d’une application, en particulier la définition de

ses fichiers et l’assignation de son numéro de série.

Cette phase intervient après la fabrication du secure element, et est

suivie de la pré-personnalisation.

Intégrateur Fournisseur de système billettique.

Interface Flux d’information entre deux composants ou entités. Une interface n’est

pas « agissante » sinon ce serait un composant ou une entité.

Peut aussi être un élément contractuel régissant les interactions entre

plusieurs entités.

Pour les interactions entre les modules d’un système billettique, dans ce

référentiel seules celles entre le domaine billettique et les autres modules

sont qualifiées d’interfaces, celles entre les modules du domaine

billettiques étant des services.

Interopérabilité Capacité d’un composant à fonctionner avec d'autres composants

(existants ou futurs).

Lecteur Partie d’un terminal assurant les communications avec un objet portable,

et éventuellement avec un ou plusieurs SAM.

Librairie Ensemble cohérent de ressources logicielles, disponible de manière

indépendante de l’application logicielle principale.

Local Appliqué à un équipement ou à un traitement : caractérise le fait de se

trouver en totalité à proximité immédiate de l’objet portable (contraire de

distant).

Appliqué à une application : désigne toute application autre que l’ABC.

MAC Message Authentication Code. Résultat d’un calcul cryptographique

symétrique permettant d’authentifier les données non secrètes utilisées

pour ce calcul. Une clé secrète est nécessaire pour vérifier un MAC.




Page Date

89 / 93

19 mars 2014

Midlet Applet fonctionnant dans un environnement MIDP (Mobile Information

Device Profile, déclinaison de Java ME dédiée aux logiciels embarqués),

par exemple celui d’un téléphone mobile.

Par extension, désigne dans ce document un programme pour téléphone

mobile, qu’il utilise MIDP ou non.

MNO Mobile Network Operator. Opérateur de réseau de téléphonie mobile.

MVNO Mobile Virtual Network Operator. Opérateur virtuel de réseau de

téléphonie mobile. Le MVNO ne possède pas l’infrastructure technique

de téléphonie mobile, mais utilise celui d’un MNO.

NFC Near Field Communication. Technologie et norme de communication

sans-fil à courte portée, permettant l'échange d'informations à quelques

centimètres, et capable de fournir de l’énergie ; extension de la norme

ISO/IEC 14443.

Non-répudiation Voir répudiation.

Objet portable Équipement sans contact qui matérialise la relation entre le fournisseur

de service et son client. Il contient les données permettant d’identifier

cette relation, et éventuellement d’en décrire les différents paramètres.

Pour sécuriser ces données qu’il contient, l’objet portable peut intégrer au

moins un secure element, avec lequel il est possible de communiquer par

le protocole ISO/IEC 14443 (définition conforme aux spécifications

Calypso).

Par exemple :

- Carte à puce sans contact : le secure element est indissociable de

son interface sans contact.

- Téléphone mobile NFC : seuls le secure element (la SIM ou un autre

composant sécurisé du téléphone) et l’interface sans contact

constituent l’objet portable.

OEM Original Equipment Manufacturer. Fournisseur d’un élément d’un

équipement.

Par extension, qualifie généralement l’élément lui-même (par exemple,

un « lecteur sans contact OEM »).

Périmètre billettique Délimite les éléments spécifiques à un bassin d’interopérabilité.

Personnalisation Phase de chargement des données billettiques initiales dans une

application.

Cette phase intervient après la pré-personnalisation, et est suivie de la

phase d’utilisation.

Pré-personnalisation Phase de chargement des paramètres spécifiques à une application, et

lui permettant de fonctionner, en particulier ses clés secrètes.

Cette phase intervient après l’initialisation, et est suivie de la

personnalisation.

Profil Caractéristiques inhérentes au client qui peuvent lui conférer des droits :

droits de transport, réductions tarifaires, moyens de transports dédiés,

titres de transport spécifiques, autorisations particulières (par exemple

l’utilisation de portillons dédiés aux personnes à mobilité réduite), etc.

Généralement gérés comme des données d’émission de l’application

plutôt que comme des contrats.




Page Date

90 / 93

19 mars 2014

Proxy Logiciel client-serveur ayant pour fonction de relayer des requêtes entre

un logiciel client et un logiciel serveur (couches 5 à 7 du modèle OSI).

Également appelé serveur mandataire.

Par extension, désigne généralement tout logiciel dont la fonction

principale est de relayer des échanges, éventuellement avec un stockage

temporaire pour tolérer des périodes d’indisponibilité des moyens de

communication ou pour réduire les communications en amont.

Répudiation Dans le contexte de la sécurité informatique, la répudiation est la

contestation de l’émission ou de la réception d’un message, la non-

répudiation étant la capacité à prouver cette émission ou réception.

RSA Algorithme cryptographique asymétrique très courant, basé sur la

factorisation de grands nombres premiers. Également connu sous le nom

« PKCS #1 ».

SAM Secure Application Module. Carte à puce dédiée au stockage et à

l’utilisation de données secrètes (telles que des clés cryptographiques) et

éventuellement de données afférentes.

Sauf indication spécifique, dans ce document, le terme SAM désigne

indifféremment une carte à puce ou un HSM.

Secure element Composant matériel sécurisé dans lequel sont stockées des applications

et des données, en particulier les contrats commerciaux entre l'opérateur

d'un service et son client.

Il s’agit généralement d’un microcontrôleur sécurisé de carte à puce, qui

peut être indissociable de l’objet portable (par exemple une carte à puce

sans contact) ou être un composant, amovible ou non, d’un objet portable

composite (par exemple la carte SIM d’un téléphone mobile NFC).

Service Interactions applicatives réalisées sous forme de composant logiciel

offrant un service à des clients qui l’utilisent. L’utilisateur ne s’intéresse

qu’au résultat produit par le fournisseur, sans savoir comment ce résultat

est obtenu.

Pour les interactions entre les modules d’un système billettique, dans ce

référentiel seules celles entre le domaine billettique et les autres modules

sont qualifiées d’interfaces, celles entre les modules du domaine

billettiques étant des services.

Les services décrits dans ce référentiel sont des services web.

Service web Service implémenté avec les technologies courantes du web (protocole

HTTP, langage Javascript, formalisme XML, etc.).

Signature Résultat d’un calcul cryptographique asymétrique permettant

d’authentifier les données non secrètes utilisées pour ce calcul. Une clé

publique suffit pour vérifier un MAC. Par exception, dans le contexte

Calypso, signature est synonyme de MAC.

SIM Subscriber Identity Module ou Subscriber Identification Module. Carte à

puce amovible équipant un téléphone mobile dont elle sécurise les

communications, et étant susceptible de sécuriser d’autres services. La

(carte) SIM appartient au MNO ou au MVNO.




Page Date

91 / 93

19 mars 2014

Symétrique Appliqué à la cryptographie, symétrique désigne une méthode de

chiffrement où une seule clé secrète permet à la fois de chiffrer et de

déchiffrer, de sorte que l’émetteur et l’expéditeur d’un message protégé

par un algorithme symétrique doivent posséder la même clé secrète.

Les calculs basés sur un algorithme symétrique nécessitent des

ressources beaucoup moins importantes qu’avec un algorithme

asymétrique.

DES, DESX, TDES et AES sont des algorithmes symétriques.

Système d’acceptation billettique Composant d’un système billettique qui met en relation le client et le

système billettique via un objet portable et éventuellement des IHM :

valideur, outil de contrôle, automate de vente, système traitant la vente à

distance (terminal et midlet inclus), etc.

Exception : les bases de données sont toujours exclues des systèmes

d’acceptation billettique, même lorsqu’elles peuvent être sollicitées

pendant le traitement d’un objet portable.

Système billettique Ensemble cohérent des matériels et logiciels dédiés à la mise en œuvre

et à l’exploitation d’une billettique (telle que définie ci-dessus).

Tag NFC Étiquette électronique compatible avec la technologie NFC,

généralement conforme aux spécifications du NFC Forum.

TDES Triple-DES. Extension de l’algorithme DES, qui utilise des clés de 112 ou

168 bits. Dans le contexte Calypso, des clés de 112 bits sont utilisés.

Télébillettique Billettique sans contact, c'est à dire dans laquelle les informations

transmises entre la partie du système de péage directement liée au

réseau et celle directement liée à l'usager ne nécessitent pas

l'établissement d'un contact physique entre ces deux entités (définition

conforme au DOcument FOnctionnel COmmun de la billettique sur

Mobile NFC).

Terminal Équipement qui réalise matériellement la communication avec un objet

portable.

Peut constituer la totalité d’un système d’acceptation billettique, ou

seulement une partie.

Triangle Application Calypso Revision 3 assurant l’interopérabilité entre les

réseaux de transport la mettant en œuvre.

L’ABC est une application Triangle.

TSM Trusted Service Manager : gestionnaire d’application. Il gère et distribue

de façon sécurisée dans les secure elements de téléphones mobiles les

applications de fournisseurs de service.

Pour ce faire, il dispose de la connectivité vers les détenteurs de ces

secure element, dont les MNO et les MVNO (français et étrangers).

UICC Universal Integrated Circuit Card. Carte SIM.

Valideur Équipement automatique de contrôle de l’accès aux moyens de

transport. Peut ou non déclencher l’ouverture d’une barrière (tripode,

portillon), et dans certains cas possède une IHM.




Page Date

92 / 93

19 mars 2014

9.2 Documents de référence

Titre Référence

(Source)

Spécifications fonctionnelles de l’application billettique commune

v1.0

(http://www.developpement-

durable.gouv.fr/)

AFIMB – Référentiel sans contact :

Transport public — Système de gestion tarifaire interopérable —

Communication entre terminaux et objets sans contact

Partie 1 : Exigences d’implémentations pour l’ISO/IEC 14443 CEN/TC 278 WI 00278344

AFIMB – Plan de test du référentiel sans contact :

Transport public — Système de gestion tarifaire interopérable —

Communication entre terminaux et objets sans contact

Partie 2 : Plan de test pour l’ISO/IEC 14443

Transport public -- Système de gestion tarifaire interopérable (IFM) --

Partie 1: Architecture

ISO 24014-1:2007

(http://www.iso.org/)

Transport public -- Système de gestion tarifaire interopérable (IFM) --

Partie 3: Concepts complémentaires à la Partie 1 pour medias

multiapplications

ISO/TR 24014-3:2013


Interopérabilité des systèmes centraux billettiques (Interopérabilité du

Back-Office Billettique), INTERBOB

FD P99-503 Août 2006


Billettique appliquée aux transports - Règles d'interopérabilité pour la

codification des données billettiques (INTERCODE)

NF P99-405 Décembre 2009

(http://www. afnor.org/)

Billettique appliquée aux transports - Règles d'interopérabilité pour la

codification des données billettiques - Billets sans contact (INTERTIC)

XP P99-410 Septembre 2006


Billettique appliquée aux transports - Codification billettique française NF P99-502 Mai 2013


Calypso Specification Rev.3 – Portable Object Application 060708-CalypsoAppli v3.2

(http://www.CalypsoStandard.net/)

Calypso Specification – Triangle 2 Specifications 101101-Triangle2Appli v2.5


Calypso Specification – Calypso SAM in a NFC phone 120214-SamNfcPhone v1.4


Calypso Specifications – Product Remote Loading 090424-ProductRemoteLoading v1.1


Cartes d'identification -- Cartes à circuit intégré -- Partie 1 à 3: Cartes à

contacts

ISO/IEC 7816-1:2011

ISO/IEC 7816-2:2007

ISO/IEC 7816-3:2006


Cartes d'identification -- Cartes à circuit intégré -- Partie 4: Organisation,

sécurité et commandes pour les échanges

ISO/IEC 7816-4:2013


Cartes d'identification -- Cartes à circuit intégré -- Partie 5:

Enregistrement des fournisseurs d'application

ISO/IEC 7816-5:2004


Cartes d'identification -- Cartes à circuit(s) intégré(s) sans contact --

Cartes de proximité

ISO/IEC 14443-1:2008

ISO/IEC 14443-1:2008/Amd 1:2012

ISO/IEC 14443-2:2010

ISO/IEC 14443-2:2010/Amd 1:2011

ISO/IEC 14443-2:2010/Amd 2:2012

ISO/IEC 14443-2:2010/Amd 3:2012




Page Date

93 / 93

19 mars 2014

ISO/IEC 14443-3:2011

ISO/IEC 14443-3:2011/Amd 1:2011

ISO/IEC 14443-3:2011/Amd 2:2012

ISO/IEC 14443-4:2008

ISO/IEC 14443-4:2008/Amd 1:2012

ISO/IEC 14443-4:2008/Amd 2:2012

ISO/IEC 14443-4:2008/Amd 3:2013

ISO/IEC 14443-4:2008/Amd 4:2014


Technologies de l'information -- Télécommunications et échange

d'information entre systèmes -- Communication de champ proche --

Interface et protocole (NFCIP-1)

ISO/IEC 18092:2013


Technologies de l'information -- Télécommunications et échange

d'information entre systèmes -- Interface et protocole -2 en

communication de champ proche (NFCIP-2)

ISO/IEC 21481:2012


DOcument Fonctionnel COmmun de la billettique sur mobile NFC V1.0 au 23/10/09

(http://www.gart.org/)

Spécifications techniques et de sécurité de la billettique sur mobile NFC Version 1.2 au 15/07/2011

(http://www.utp.fr/)

Spécifications techniques AFSCM (http://www.afscm.org/)

Java Card Platform Specifications

Java Card 2.2.2

Java Card Classic 3.0.4

Java Card Connected 3.0.1

(http://www.oracle.com//)

GlobalPlatform – Card Specification v2.2.1

(http://www.globalplatform.org/)

GlobalPlatform – Card Contactless Services Card Specification v2.2 -

Amendment C

v1.1

(http://www.globalplatform.org/)

OSGi Release 5

(http://www.osgi.org/)

Technologies de l'information -- Techniques de sécurité -- Algorithmes

de chiffrement

ISO/IEC 18033-1:2005

ISO/IEC 18033-1:2005/Amd 1:2011

ISO/IEC 18033-2:2006

ISO/IEC 18033-3:2010

ISO/IEC 18033-4:2011


Technologies de l'information -- Techniques de sécurité

ISO/IEC 27001:2013

ISO/IEC 27002:2013

ISO/IEC 27003:2010

ISO/IEC 27005:2011

ISO/IEC 27014:2013


ANSSI – Référentiel Général de Sécurité RGS v1.0 du 6 mai 2010

(http://www.ssi.gouv.fr/)

PC/SC Workgroup Specifications Version 2.01.12

(http://www.pcscworkgroup.com/)

Gestion de documents -- Format de fichier des documents électroniques

pour une conservation à long terme -- Partie 1: Utilisation du PDF 1.4

(PDF/A-1)

ISO 19005-1:2005

ISO 19005-1:2005/Cor 1:2007

ISO 19005-1:2005/Cor 2:2011
