Simulateur monétique
Le but de ce "sous-projet" est de faire une surcouche du framework dans un domaine précis afin d'en vérifier le fonctionnement. De plus, il permet de s'en servir de base de connaissances pour les futurs développeurs sur le simulateur. Cette documentation a pour objet de présenter l'implémentation monétique réalisée sur le simulateur de flux. Elle détaille, pour le scénario de démonstration retenu, les choix d’implémentation ainsi que l’organisation des composants et leurs stratégies.
- Des cartes à puce
- Un Terminal de Paiement Électronique
- Le Front-Office Acquéreur (via le SAA)
- Le réseau d’autorisation (e-RSB)
- Le Front-Office Émetteur (via le SAE)
Le composant Carte définit une carte physique.
C'est un composant de "haut niveau" contenant plusieurs sous composants
Architecture du composant :
- Sous composant "chip" : ce composant définit la puce de la carte. Elle contient des données et des fonctionnalités permettant le dialogue avec d'autres composants de type Input ou Input/Output. La puce contient de l'intelligence et est capable d'effectuer des opérations courantes. (Dans cette implémentation la puce permet la communication avec un terminal, l'établissement d'un canal sécurisé, l'authentification porteur, l'émission d'ARQC et la réception et traitement d'ARPC.)
- Sous composant "magstripe" : ce composant définit la piste magnétique de la carte (Track2). Elle contient des données publiques lisibles afin de permettre un nombre limité de traitements. C'est un composant de type Output (émission d'inforamtion seulement).(Dans cette implémentation la piste ne permet pas la vérification de PIN).
Stratégie du composant : La stratégie de ce composant est basée sur un traitement de message reçu selon deux paramètres : l'état d'avancement de la cinématique de paiement et le type de message reçu. La carte dispose en effet d'états selon l'avancement de la transaction (éteinte, canal sécurisé, porteur authentifié). En combinant un état et un type de message reçu, la carte est en mesure de choisir le traitement associé.
Un TPE est un appareil électronique capable de lire les données d'une carte bancaire, d'enregistrer une transaction, et de communiquer avec un serveur d'authentification à distance. Architecture du composant :
Stratégie du composant :
Le début de communication avec la carte a pour objectif de mettre en place le channel sécurisé et de choisir par la suite le protocole commun a adopter.
Il existe deux cinématiques d'authentification porteur entre ces deux composants :
- Authentification sans demande d'autorisation carte.
- Authentification avec demande d'autorisation carte.
Un Front Office est un système exploité par un établissement financier ou un prestataire de services gérant plusieurs établissements, il est soumis à de multiples contraintes comme l'étanchéité des données par exemple.
- Demande d’autorisation
Après authentification du porteur, la carte ou le TPE vont générer un ARQC (Autorisation ReQuest Cryptogram). Dans notre scenario, la carte demande l’autorisation. Elle va donc générer l’ARQC et la transmettre au TPE, en charge de le convertir vers un message compréhensible par son SAA (ISO 8583 de type 0100). Le TPE effectue une translation de type en ré-utilisant les données puis envoie le message 0100 vers le Front-Office Acquéreur. Le FOA dispatche le message via un routeur sur les réseaux. Le réseau analyse le PAN pour en extraire l’IIN et envoyer vers le SAE correspondant. - Processus d’autorisation
Le SAE reçoit un message 0100. L’algorithmique de la stratégie du Front Office Emetteur permet de définir si l’autorisation est donnée ou non. Dans le scénario de démonstration, un attribut du SAE permet de définir l’attitude à adopter : autorisation de toutes les transactions, rejet de toutes ou tirage d’un aléa pour la réponse. Le message 0110 de réponse à autorisation est alors créé en reprenant les informations du message 0100 et en y ajoutant les champs utiles (code réponse, numéros d’autorisation…). Le message réponse est alors re-routé jusqu’au TPE selon la même logique que précédemment. - Réponse à Autorisation
Le TPE reçoit un message de type 0110, il va alors le convertir en ISO7816 pour le communiquer à la carte. Ce message devient un ARPC (Autorisation ResPonse Cryptogram) transmis à la carte qui va pouvoir choisir ou non de délivrer sa validation finale de la transaction. Dans le contexte de la simulation, la carte valide toujours la transaction sans intelligence. Chacun des deux composants sauvegarde alors la transaction en mémoire.
Grâce aux composants et aux stratégies disponibles dans ce projet, il est possible de réaliser :
- le paiement
- l'autorisation
- télé-collecte