RAPPORT SUR LA RÉALISATION D UN DÉMONSTRATEUR DE PAIEMENT SÉCURISÉ SUR INTERNET UTILISANT LE PROCÉDÉ DE M. ATIG. N o DE PTR :

Transcription

1 RAPPORT SUR LA RÉALISATION D UN DÉMONSTRATEUR DE PAIEMENT SÉCURISÉ SUR INTERNET UTILISANT LE PROCÉDÉ DE M. ATIG N o DE PTR :

2 Table des matières Table des matières... i 1. Présentation Fonctionnement du prototype Présentation globale Fonctionnement du principe d authentification Les lois de codage Authentification par loi de codage Authentification par mot de passe Résultat de l authentification Développement Suivi du développement par l inventeur Commentaires d aspect général... 8 Annexe A Schéma général des sections de l application Annexe B Schéma relationnel du démonstrateur Annexe C Exemple d une démonstration C.1 Début de la démonstration C.2 Inscription d un nouveau client C.3 Choix des produits à facturer C.4 Authentification C.5 Authentification par la loi de codage C.6 Authentification par le mot de passe C.7 Authentification erronée C.8 Gestion de la base de données... 19

3 1. PRÉSENTATION Pour mettre en évidence le principe énoncé dans le brevet, le développement d un site (commerce fictif) d achat en ligne a été retenu, la démonstration du principe se faisant au niveau de l authentification du client veuillant procéder à une transaction. Le démonstrateur est en réalité une application de type client-serveur. Les principales raisons qui ont guidé ce choix sont : l une des cibles potentielles pour l implémentation du principe est le domaine des applications Internet; le démonstrateur étant installé sur une station informatique servant de serveur, celui-ci peut être accédé à l aide d un navigateur Internet supportant les Applets JAVA à partir de n importe quelle station reliée à Internet, permettant ainsi à l inventeur d effectuer des démonstrations à partir de quelconques stations; une démonstration du processus peut être faite chez un client sans que celui-ci n ait à télécharger d éléments spécifiques; l application est indépendante du système d exploitation (Windows, Unix, MacOS,...) sur lequel est effectuée la démonstration; l utilisation de l Internet permet de différencier les traitements effectuées du côté serveur et ceux du côté client. Ce rapport se veut ainsi être un résumé du fonctionnement du prototype réalisé, résumé qui s attarde plus en détails sur la section de l authentification des clients, soit celle qui met en pratique le principe énoncé dans le brevet. Dans les annexes de ce document sont donnés des schémas permettant de comprendre la structure de l application, ainsi qu un exemple de démonstration.

4 2. FONCTIONNEMENT DU PROTOTYPE Cette section décrit le fonctionnement du prototype réalisé. Les annexes A et B peuvent être consultées en tant que support visuel pour les différents cheminements. 2.1 PRÉSENTATION GLOBALE La démonstration commence par une consultation du site de commerce en ligne. L utilisateur qui effectue la démonstration doit se créer un client fictif (inscription en ligne) s il veut être capable d effectuer une transaction. Comme il peut exister plusieurs clients ayant les mêmes noms et prénoms, l utilisateur doit se choisir un identifiant unique (login). Une fois les coordonnées du client entrées, l utilisateur doit fournir les informations concernant sa carte de paiement (numéro et date d expiration), ainsi qu un mot de passe numérique. Finalement, il doit se créer une loi d encodage. Par la suite, le client consulte le catalogue des produits disponibles et, une fois sa sélection effectuée, accède à l authentification du client. Cette authentification peut se faire de deux façons : par l utilisation d une loi d encodage ou par l utilisation d un mot de passe, éléments qui ont au préalable été choisis par le client. Suivant la façon à l aide de laquelle il choisit de s authentifier, le serveur, à la réception des informations fournies par le client, vérifie si celles-ci sont valides ou non. Si elles le sont, la transaction est acceptée. Dans le cas contraire, la transaction est refusée. Dans le cadre de la démonstration, un individu peut faire au plus trois essais fautifs consécutifs. Si la certification est acceptée, le client peut, dans le cas de l utilisation d une loi d encodage, changer cette dernière. Par la suite, le client retourne au menu principal. De façon à permettre une meilleure visualisation des changements effectués, il est possible de consulter le contenu des différentes tables. Dans le cadre d une démonstration, cela peut s avérer utile pour repérer, par exemple, les diverses cartes d un client, ou pour simplement visualiser les factures émises. Enfin, une page donnant des explications générales sur le fonctionnement du démonstrateur est accessible à partir principal. 2.2 FONCTIONNEMENT DU PRINCIPE D AUTHENTIFICATION Cette section est en fait le coeur du démonstrateur car c est elle qui met en application le principe du brevet. Le brevet pose l idée qu il est possible d encoder un élément où la façon d encoder et/ou les paramètres du processus d encodage sont paramétrables. Cette façon de faire a été reprise dans le cadre du démonstrateur pour authentifier les transactions, c est-à-dire pour s assurer que les personnes voulant effectuer des transactions sont des clients légitimes du commerce. Cette authentification peut se faire de deux façons différentes : par une loi d encodage ou par un mot de passe.

5 2.2.1 Les lois de codage Les lois d encodage se divisent en deux catégories : les lois simples et les lois complexes. Une loi de codage simple est une façon définie d effectuer une opération sur une chaîne de caractères* dans le but d en générer une deuxième de même longueur, mais avec certains de ses éléments modifiés. Par exemple, dans la chaîne " ," une telle loi peut être utilisée pour remplacer tous les chiffres "0" par des chiffres "9" et vice-versa, donnant " ". Pour certaines lois simples, il peut être possible d en spécifier les paramètres, c est-à-dire de les paramétrer. Par exemple, une loi faisant l inversion d une chaîne de caractères ne peut pas être paramétrée (" " ne pouvant que donner " "). À l inverse, une loi qui interchange des valeurs peut l être (exemple donné dans le paragraphe précédent). Ces paramètres peuvent être déterminés de différentes manières. Cependant, dans le cadre du démonstrateur, ils sont soit choisis par le client, soit déterminés en fonction de paramètres variant d une transaction à une autre. Quant aux lois de codage complexes, elles sont en fait des combinaisons de lois d encodage simples. Par exemple, pour une chaîne donnée et deux lois simples A et B, A B et B A sont des lois complexes générant des résultats différents. * Dans le cadre du démonstrateur, les chaînes de caractères sont uniquement numériques. Le démonstrateur, pour ces cas, utilise le montant et la date de la transaction. Mathématiquement, cela signifie que les lois complexes ne sont pas associatives : F ( G ( x ) ) G ( F ( x ) ).

6 2.2.2 Authentification par loi de codage Il s agit d encoder à l aide d une loi simple ou complexe la série de chiffres constituée du numéro et de la date d expiration de la carte de paiement. L encodage se fait à l aide d une Applet JAVA à laquelle sont fournis l identifiant unique du client, ses numéro et date d expiration de sa carte de paiement, ainsi que sa loi d encodage. À l aide de la loi donnée, l Applet génère une série de chiffres qui est transmise au serveur avec l identifiant du client. Pour chaque carte associée au client donné, le serveur utilise la loi associée afin de décoder la chaîne reçue et de la comparer avec les informations de la carte associée. Si une correspondance est trouvée, l authentification est acceptée. Le schéma suivant donne une vue des données échangées et du séquençage des étapes de traitement du processus d authentification.

7 2.2.3 Authentification par mot de passe Il s agit d encoder, à l aide d une loi de codage fournie par le serveur, le mot de passe numérique du client. L encodage se fait à l aide d une Applet JAVA à laquelle sont fournis l identifiant et le mot de passe du client. L Applet génère alors une série de chiffres qui est renvoyée au serveur avec l identifiant du client. Une fois reçus, le serveur décode la série de chiffres à l aide de la loi qu il a fourni au client et recherche, pour le client donné, une carte de paiement ayant un mot de passe identique. Si une correspondance est trouvée, l authentification est acceptée. Le schéma suivant donne une vue des données échangées et du séquençage des étapes de traitement du processus d authentification Résultat de l authentification Si l authentification est acceptée, le compteur d essais fautifs est réinitialisé à 3 et le client débité du montant facturé sur la carte de paiement utilisée. Dans le cas contraire, le compteur d essais fautifs est décrémenté de 1. Si le compteur atteint 0, plus aucune transaction ne pourra être acceptée pour ce client, authentification valide ou non.

8 3. DÉVELOPPEMENT L application se divise en deux parties : le serveur et le client. La partie serveur, en relation avec une base de données Access, a pour rôle de sauvegarder toutes les données nécessaires au fonctionnement de l application et d analyser celles fournies par l utilisateur. En fonction de celles-ci, les pages Web sont générées de façon dynamique. Les données fournies par le client peuvent être soit du texte, soit des sélections de liens hypertextes, soit des activations d éléments graphiques (boutons, menus déroulants). Cette partie utilise le langage de script ASP pour générer les pages HTML et communiquer avec la base de données. La partie client a pour rôle d effectuer des traitements spécifiques sur les données avant de les faire parvenir au serveur. Ainsi, ce ne sont pas les données initiales mais les données traitées qui transitent vers le serveur via le réseau Internet. Cette partie a été développée sous forme d Applets JAVA*. L environnement logiciel utilisé pour la réalisation du prototype est composé de : Windows 2000 Professionnel (système d exploitation); CodeWarrior (développement JAVA); Visual Studio Interdev (développement ASP et HTML); Microsoft IIS et Microsoft Personal Web Manager (interprétation des scripts ASP, serveur Web); ODBC (gestionnaire de base de données - pilote pour bases de données Microsoft Access). Pour fonctionner, l application nécessite un serveur Web qui soit capable d interpréter les scripts ASP. Ce serveur Web peut être installé sur une quelconque station de travail. Pour procéder à la démonstration, il s agit d accéder à la page principale de l application en entrant dans un navigateur Internet l adresse de la station serveur. La démonstration ne nécessite pas que la station de travail soit obligatoirement liée au réseau Internet. Dans le cas où il n y a pas de lien, le tout fonctionne simplement en local, c est-à-dire que la démonstration ne peut alors être faite que sur la station sur laquelle est installé le serveur Web. Cette possibilité s avère utile pour effectuer, chez des clients, des démonstrations sur des ordinateurs portables. * les Applets JAVA sont exécutées sur la station du client.

9 4. SUIVI DU DÉVELOPPEMENT PAR L INVENTEUR Le développement du prototype a été effectué de telle manière que l inventeur puisse en voir l évolution à un certain nombre d étapes. Étant une application Internet, il lui a été possible d en observer l avancement à partir de chez lui et de proposer des modifications. Ainsi, le prototype a connu cinq phases principales de développement, la dernière étant le produit final et celle dont le fonctionnement est explicité dans ce rapport. De façon générale, ces phases sont : développement d une première version du prototype. Dans cette version, les lois de codage ne sont pas encore paramétrables par le client. Ajout de la possibilité pour le client de paramétrer les lois de codage. Ajout de la possibilité pour un client de posséder plus d une carte de paiement. Ajout d un deuxième type d authentification qui utilise un mot de passe (password). Corrections mineures et finalisation du prototype. En plus de ces phases, suivant l entente conclue avec l inventeur, une copie, sur support de type CD-ROM, de tous les éléments nécessaires (codes sources, base de données) au fonctionnement du prototype sera remise lors de la finalisation du projet. Ces éléments permettront alors à l inventeur, s il le désire, de faire évoluer le prototype à sa guise pour les besoins de ses démonstrations, ou même, de le faire évoluer dans le but de passer de l étape de démonstrateur à l étape de produit commercial.

10 5. COMMENTAIRES D ASPECT GÉNÉRAL Le développement du prototype a permis a l inventeur de visualiser de façon concrète comment son invention peut être mise en application. Le prototype pourra alors être utilisé par l inventeur pour démontrer son principe à des clients potentiels. Il demeure que ce démonstrateur n est pas un produit commercialisable en tant que tel mais bien un support permettant de démontrer un principe initialement abstrait (décrit sur papier dans le brevet) et qu il doit être gardé à l esprit qu un développement sur une base commerciale du principe pourra amener à des produits dont l utilisation pourra se présenter de façon différente de celle proposée dans le prototype.

11 ANNEXES

12 A. SCHÉMA GÉNÉRAL DES SECTIONS DE L APPLICATION Le schéma suivant donne une vue des différentes sections (pages) de l application. Les flèches entre les boîtes indiquent les séquences normales des traitements possibles. Pour chaque boîte finalisant une séquence, il est possible de retourner à la page principale associée à cette section (Page d accueil du démonstrateur, Gestion de la base de données). En outre, à partir de quelque page que ce soit, il est possible d accéder au menu général. Enfin, dans la section du démonstrateur en tant que tel, les lignes en pointillés indiquent qu une séquence est optionnelle.

13 B. SCHÉMA RELATIONNEL DU DÉMONSTRATEUR Le schéma qui suit donne une vue pour la base de données du démonstrateur des relations entre les tables. Pour chaque lien reliant deux boîtes (entités), le nombre directement à côté d une entité donne le nombre d instances de la seconde entité pouvant être reliées à une instance de la première. Par exemple, un client peut être associé à zéro ou plusieurs cartes de paiement alors qu une carte de paiement est associée à un unique client. Dans le schéma, la table des lignes de commandes temporaires peut sembler être un doublon de la table des lignes de commande. Cependant, celle-ci est nécessaire car elle sert à enregistrer de façon temporaire les produits sélectionnés par le client avant la certification de la transaction. Si la certification est effectuée avec succès, ces lignes de commande sont copiées de façon permanente dans la table des lignes de commande lors de la création de la facture. Dans le cas de démonstrations simultanées, il ne serait pas impossible que celles-ci soient effectuées en utilisant un même client. Pour éviter que toutes ces démonstrations ne génèrent une seule et même facture, chaque ligne de commande temporaire est associée à un identifiant unique qui identifie chaque session de démonstration. Ainsi, les démonstrations, dans le cas où les authentifications sont acceptées et où le même client est utilisé, généreront des factures distinctes.

14 C. EXEMPLE D UNE DÉMONSTRATION Cette annexe contient des images de l application (site). Pour donner un exemple de démonstration, le client fictif suivant sera utilisé : nom : Jacques prénom : Robert adresse : 1 LaRue, appartement 1 ville : LaVille code postal : téléphone : fax : identifiant unique (login) : Boby numéro de la carte de paiement : date d expiration de la carte de paiement : 0104 mot de passe : loi de codage : Il est important de mentionner qu un même client peut posséder de 0 à N cartes de paiement. Cependant, dans le cas où aucune carte n est créée, le client ne pourra en réalité jamais effectuer de transactions. Dans le cadre de l exemple, une seule carte est créée.

15 C.1 DÉBUT DE LA DÉMONSTRATION Toute personne veuillant effectuer une démonstration accède d abord à cette page. À cette étape, deux choix s offrent : créer un client fictif dans le but d effectuer la démonstration ou commencer immédiatement la démonstration en utilisant un client fictif déjà existant. C.2 INSCRIPTION D UN NOUVEAU CLIENT L inscription d un nouveau client se fait en 3 étapes, la première étant obligatoire, les 2 secondes optionnelles. Premièrement; les coordonnées du client fictif doivent être entrées.

16 Une fois les coordonnées validées, des cartes de paiement peuvent être entrées. Pour chaque carte, les deuxième et troisièmes étapes doivent être complétées. La deuxième étape consiste à fournir les informations sur la carte ainsi qu un mot de passe numérique. Quant à la troisième étape, elle consiste à créer une loi d encodage. L utilisateur se crée une loi complexe en imbriquant les lois simples. Pour certaines de ces lois, l utilisateur peut en paramétrer certaines variables. La loi générée est aussi une séquence de chiffres.

17 C.3 CHOIX DES PRODUITS À FACTURER À cette étape, le client choisit les produits à facturer. Dans le cadre de la démonstration, le montant à facturer sera utilisé comme paramètre variable lors de l authentification. C.4 AUTHENTIFICATION Le client est prêt à être facturé. Cependant, le système veut s assurer qu il est bien un client légitime. Pour certifier son identité, il peut procéder soit en utilisant sa loi de codage, soit en utilisant son mot de passe. Pour les deux types de certification, les montant et date de transaction sont utilisés comme paramètres variables pour les lois de codage.

18 C.5 AUTHENTIFICATION PAR LA LOI DE CODAGE L utilisateur entre son identifiant, ses numéro et date d expiration de sa carte de paiement, ainsi que sa loi de codage. Si les informations fournies sont valides, la certification est acceptée (comme le montre l image ci-dessous). Dans un tel cas, il est proposé au client de changer sa loi d encodage pour ses prochaines transactions (écran présenté précédemment dans le cadre de l inscription d un nouveau client).

19 C.6 AUTHENTIFICATION PAR LE MOT DE PASSE Il est aussi possible de procéder à la certification de la transaction en utilisant le mot de passe. Pour ce faire, l utilisateur doit entrer son identifiant (login) ainsi que son mot de passe, puis valider le tout. acceptée. Si les informations fournies sont valides (comme le montre l image ci-dessous), la transaction est

20 C.7 AUTHENTIFICATION ERRONÉE Pour les deux types de certification, il est possible que le client entre une ou des informations erronées. Dans le cadre de l exemple suivant, une authentification par loi de codage est tentée, mais avec une loi erronée. Suite à trois essais infructueux consécutifs, le compte du client est bloqué.

21 C.8 GESTION DE LA BASE DE DONNÉES Pour permettre à la personne faisant la démonstration de rechercher des éléments spécifiques dans la base de données, une section pour la gestion de celle-ci a été ajoutée. L ensemble des pages de consultation ont le même type d interface. L exemple pris est celui de la gestion des cartes de paiement.