PR ´ ESENTATION DES PROTOCOLES 63

3.1.5 Paiement de proximit´e en mode semi-connect´e

En mode semi-connect´e, nous supposons qu’un des acteurs n’a pas la possibilit´e d’interagir avec la plateforme de paiement. Cela correspond au cas o`u un porteur n’a pas de forfait permettant d’avoir acc`es aux donn´ees. Nous estimons que si un marchand se trouve dans une zone couverte, les accords le liant `a l’op´erateur qui g`ere la plateforme de paiement incluent un acc`es aux donn´ees pour le marchand. Nous proposons donc de traiter ce cas en faisant profiter au porteur l’acc`es du marchand aux donn´ees, ce qui permet ensuite de r´ealiser une transaction dans le mˆeme cadre que le mode tout-connect´e.

Flux

Les diff´erents flux de ce mode sont repr´esent´es en figure 3.6. Tout d’abord, le porteur qui souhaite r´ealiser une transaction initie le partage de connexion. Le marchand v´erifie ensuite que le porteur est l´egitime et donc que la connexion peut ˆetre partag´ee avec lui. Si c’est le cas, le marchand partage sa connexion et la transaction peut se r´ealiser en mode connect´e. Ainsi, les besoins de s´ecurit´e de ce mode sont :

– anonymat du porteur vis-`a-vis du marchand ;

– acc`es au partage de connexion r´eserv´e aux clients du service ;

– acc`es au r´eseau virtuel et partage d’acc`es `a ce r´eseau r´eserv´e aux marchands partenaires de l’op´erateur de t´el´ephonie sur mobile.

Figure3.6 – Flux correspondant au paiement de proximit´e en mode semi-connect´e

Protocole

Afin de faire b´en´eficier au porteur l’acc`es aux donn´ees du marchand, nous nous basons sur les protocoles de partage de connexion d´ej`a mis en œuvre dans le cadre des r´eseaux wifi : une variante du protocole EAP-TLS, Extensible Authentication Protocol - Transport Layer Security [IETd], le protocole EAP-TTLS, Extensible

64

CHAPITRE 3. ARCHITECTURE DE CONFIANCE POUR LES SERVICES DE TRANSACTIONS SUR TERMINAUX MOBILES

Authentication Protocol Tunneled Transport Layer Security [IETf]. Ce protocole permet une authentification mutuelle de la plateforme de paiement et du porteur qui souhaite b´en´eficier de la connexion tout en assurant la confidentialit´e de l’identit´e du porteur vis-`a-vis du marchand, ce que ne permettrait pas l’utilisation d’EAP-TLS. Cette adaptation est repr´esent´ee en figure3.7pour le cas o`u la demande de connexion r´eussit.

Le protocole EAP-TTLS suppose la pr´esence d’un serveur TTLS (Tunneled Transport Layer Security), qui permet de cr´eer un canal s´ecuris´e, d’un serveur AAA (Authentication Authorization Accounting), qui centralise les donn´ees

d’authenti-fication et autorise l’acc`es au r´eseau et d’un point d’acc`es, qui fait le lien entre le demandeur de connexion et la plateforme AAA. Ici, nous consid´erons que le ter-minal du marchand est le point d’acc`es et que la plateforme de paiement contient le serveur AAA et le serveur TTLS. Pour plus de facilit´e ici, nous consid´erons le protocole Radius mais les principes pr´esent´es ici sont adaptables `a tout protocole AAA. L’environnement d’ex´ecution s´ecuris´ee dans le terminal marchand prend en charge les diff´erents messages pr´esent´es ici. En particulier, nous supposons que le niveau de s´ecurit´e de l’environnement d’ex´ecution s´ecuris´ee suffit pour stocker les cl´es li´ees au protocole AAA et pour g´erer l’acc`es des porteurs au r´eseau. Ses capacit´es sont plus importantes que celles de la SIM marchand, ce qui permet de ne pas trop alourdir le protocole. De plus, l’environnement d’ex´ecution s´ecuris´ee g`ere directe-ment et de mani`ere s´ecuris´ee les p´eriph´eriques dont ceux permettant l’acc`es au r´eseau.

Les messages entre l’environnement d’ex´ecution s´ecuris´ee du terminal marchand et la SIM ou entre la plateforme de paiement et la SIM sont des requˆetes et r´eponses EAP [IETc]. Les en-tˆetes HDR correspondent ici aux en-tˆetes li´ees `a ce format. Les diff´erents messages EAP sont encapsul´es dans le protocole ISO 7816 [ISO] entre la SIM du porteur et l’environnement d’ex´ecution s´ecuris´ee du porteur.Ils sont ensuite ensuite encapsul´es dans un protocole de transmission de proximit´e entre les terminaux client et marchand. Finalement, ils sont encapsul´es dans le protocole Radius entre l’environnement d’ex´ecution s´ecuris´ee du terminal marchand et la plateforme. Ce sont les environnements d’ex´ecution s´ecuris´ee du porteur et du marchand qui prennent les diff´erentes traductions en charge. Conform´ement au protocole Radius [IETb], le TEE marchand et la plateforme de paiement utilisent un secret pr´e-partag´e pour, en particulier, chiffrer le message qui informe le TEE marchand du refus ou de l’acceptation par la plateforme de partager la connexion.

3. 1. P R ´E S E NT A T IO N D E S P R O T O C O LE S 65

SIM Porteur TEE Porteur TEE Marchand Plateforme

Association

Req ID

Rep ID.{IDP.alea1}P KP p

T LS Start

M1: Req P roposition.aleaP

M2: Rep Choix.[CERT (P p)].aleaP p

{P M K}P KP p.{hash(M 1, M 2)}K

{Req Id.hash(M 1, M 2, P M K)}K

{Rep ID.{IDP.alea1}P K_{P p}}K

{Req Def i.alea2}K

{Rep Def i.CERT (P ).SIGP(alea2)}K

EAP Succ`es Association Initialisation Mise en place canal TLS Authentification du porteur

EAP over RADIUS

EAP over 7816 EAP over LAN

G´en´eration de PMK, Calcul de K = f(P M K, aleaP, aleaP p) Calcul de K F ig u r e 3. 7 – P ro to co le p ou r le m o d e se m i-c on n ec t´e

66

CHAPITRE 3. ARCHITECTURE DE CONFIANCE POUR LES SERVICES DE TRANSACTIONS SUR TERMINAUX MOBILES

Ce protocole se d´ecoupe en quatre phases. Tout d’abord, les deux terminaux sont associ´es. La deuxi`eme ´etape permet d’initier la demande de connexion. La SIM porteur transmet l’identit´e du porteur `a la plateforme. Afin de pr´eserver l’anonymat du porteur vis-`a-vis du marchand, nous transmettons l’identit´e du porteur, un al´ea la signature de ces deux ´el´ements par la SIM porteur chiffr´es avec la cl´e publique de la plateforme de paiement.

Ensuite, un tunnel TLS est mis en place. Comme le montre la figure 3.7, les messages M1 et M2 correspondent `a la proposition et au choix des fonctionnalit´es cryptographiques. L’envoi du certificat de la plateforme est optionnel. La carte SIM g´en`ere la cl´e pr´e-maˆıtre P M K et calcule la cl´e secr`ete K `a partir de P M K et des al´eas aleaP p, aleaP ´echang´es dans M1 et M2. La cl´e pr´e-maˆıtre chiffr´ee par la cl´e secr`ete de la plateforme de paiement lui est envoy´ee ainsi que le hach´e de M1 et M2 chiffr´e par K. La plateforme doit alors retrouver PMK et recalculer K pour initier la phase d’authentification de la plateforme. Le hach´e de M1, M2 et PMK permet `a la plateforme de prouver `a la carte SIM qu’elle poss`ede bien la cl´e priv´ee P KP p et qu’elle est capable de calculer K. La cl´e K est utilis´ee pour s´ecuriser les prochains messages.

La r´eponse d’identit´e du porteur est renvoy´ee au serveur qui transmet un d´efi `a la SIM porteur. Celle-ci s’authentifie aupr`es du serveur en transmettant son certificat et en signant le d´efi. Si cette authentification r´eussit, la plateforme autorise le terminal marchand `a partager sa connexion avec le terminal client. Cet ´echange suit le format d´efini dans [IETf]. En cas de succ`es, il s’agit d’un message chiffr´e avec la cl´e secr`ete SAN de type EAP-Success et encapsul´e dans un message RADIUS Access-Accept.

3.1.6 Transactions en mode tout-d´econnect´e

Dans cette partie, nous consid´erons que le transfert se r´ealise de la mˆeme mani`ere qu’il s’agisse d’un paiement marchand ou d’un transfert entre particuliers.

En mode d´econnect´e, les comptes des porteurs et la plateforme de paiement ne sont plus accessibles. Le m´ecanisme d’autorisation de la transaction ne peut donc ˆetre conserv´e. Deux solutions existent. La premi`ere consiste `a associer un porte-monnaie ´electronique associ´e au compte en ligne et stock´e dans l’appareil. Il serait approvisionn´e `a la demande du porteur `a partir de son compte en ligne. Une telle solution a ´et´e sp´ecifi´ee et valid´ee lors d’une collaboration avec le laboratoire Heudiasyc [HB12a, HB12b]. La deuxi`eme solution, que nous adoptons ici, consiste `a