The EPS-AKA Protocol

184 Pages·2017·2.45 MB·French

ANNE´E2017
` ´
THESE / UNIVERSITE DE RENNES 1
sous le sceau de l’Universite´ Bretagne Loire
pour le grade de
´
DOCTEUR DE L’UNIVERSITE DE RENNES 1
Mention : Informatique
Ecole doctorale MATISSE
pre´sente´e par
Benjamin Richard
pre´pare´e a` l’Institut de Recherche en Informatique et Syste´mes
Ale´atoires (IRISA), UMR no6074
The`sesoutenuea` Rennes
´
Etude des protocoles le30Aout2017
devantlejurycompose´ de:
d’authentification et Michel FERREIRA ABDALLA
Directeurderecherches,CNRS/ENS(rapporteur)
de de´rivation de clefs Refik MOLVA
Professeur,EURECOM(rapporteur)
en 3 parties. Fre´de´ric CUPPENS
Professeur,IMTAtlantiqueRennes(examinateur)
Gilles MACARIO-RAT
Chercheur,OrangeLabsChatillon(examinateur)
Maria Cristina ONETE
PostDoc,U.Rennes1(examinateur)
Jacques TRAORE
Chercheur,OrangeLabsCaen(examinateur)
Pierre-Alain FOUQUE
Professeur,U.Rennes1(directeurdethe`se)
2
3
Remerciements
Enpremierlieu,jetiensa`remerciermondirecteurdethe`se,Pierre-AlainFouque,poursonsoutien,
sapatienceetsonaideauquotidien. Audela` desesindispensablesqualite´sscientifiquesdontj’ai
pu be´ne´ficier durant mes 3 anne´es de the`se, je tiens a` le remercier pour cette expe´rience, qui a
su m’aider a` grandir aussi bien d’un point de vue personnel que professionnel. Merci e´galement
a` Maria Cristina Onete, de s’eˆtre jointe a` cette the`se, pour son soutien au quotidien, et pour les
nombreuses discussions qu’on a pu avoir ensemble. Je remercie aussi Gilles Macario-rat pour
m’avoirencadre´auseind’Orange,d’avoiraccepte´demesuivreetdem’avoirfaitconfiancedurant
monchangementdesujetdethe`se.
Jetiensensuitea` remercierl’ensembledesmembresdujuryd’avoiraccepte´ departicipera` ce
jury. Unmercitoutparticuliera` MichelFerreiraAbdallaetRefikMolvad’avoiraccepte´ d’eˆtreles
rapporteursdecettethe`se.
Jevoudraie´galementremercierJannickDreieretSteveKraemer,pourm’avoiraccueillia` titre
occasionnel dans les locaux du Loria a` Nancy. Merci a` eux pour leurs disponibilite´s et pour les
e´changestoujourstre`sproductifsetinte´ressantsquenousavonseuensemble.
Jetiensa` remercierl’ensembledel’e´quipeDSSd’OrangeLabspourm’avoiraccueillidurant
ces trois anne´es de the`se. Un merci particulier a` Pascal pour avoir essaye´ en vain de recadrer
mes gouts cine´matographiques, Todor pour avoir su mettre un peu de lumie`re dans le monde
delastandardisation,Alexpournosnombreusespartiesdebasketetnosde´briefingsdel’actualite´
sportive,etsurtoutTiphaine,maresponsabledestagede3ie`mepre´fe´re´e. Merciauxautresthe´sards
de gale`re (Xiao, Maxime) a` qui je souhaite bon courage pour la suite. Merci a` tous les autres
Xavier, Ghada, Said, Kahina, Michael, Matthieu ... d’avoir participe´ quotidiennement a` la bonne
ambiancedecettee´quipe. Unepetitepense´eauxanciensLaura,Georgian,Aure´lien,Pierre,Amira,
Nizar, Wafa avec qui j’ai pu avoir a` la fois des conversations se´rieuses et prolifiques, mais aussi
des fou-rires tre`s agre´ables. Merci aussi a` tous les autres que je n’ai pas cite´, mais qui e´taient
pre´sentauquotidien!
Mercia` l’ensembledesmembresdel’e´quipeEMSECdel’IRISApourleuraccueiletpourla
bonneambiancequ’ilsontsuinstaurerauseindenosbureaux. Jetiensa` remercierl’ensembledu
groupedesthe´sardsmadeinEMSEC:AlbanleroidesSparesaubowling,Baptistemone´le`vede
beaufitudepre´fe´re´,Chenmonportugaispre´fe´re´,Claireunedespilie`resdelapausecafe´,Paulinela
bordelaisedeservice,Florentetses”pourquoipas”quandvousluiproposeza` manger,etRaphae¨l
letaulierdujeudisoir.
Merci aussi aux titulaires, Patrick le se´rieux du Badminton, Ste´phanie qui sait organiser des
soire´es barbecue a` merveille, et Adeline pour son aide et son soutien. Petite pense´e a` l’ancien,
Brice Minaud, sa pre´sence au badminton et sa sympathie quotidienne nous manque a` tous, et a`
la petite nouvelle, Ange`le, qui je suis sur, s’e´panouira a` merveille dans cette e´quipe. Merci a` toi
Cyrille, lemeilleurco-bureauqu’unthe´sardpuisseespe´rer. Mercimonamipourtoute l’aide que
tu m’as apporte´, nos fou-rires et nos chants. La meilleure ambiance e´tait chez nous a` ne pas en
douter :p Ah oui, merci aussi d’avoir supporter les 30 degre´s que j’imposai re´gulie`rement dans
notrebureau.
Jetiensa` pre´senta` remerciermafamillepourleuraideetleursoutien. Unremerciementtout
particulier a` Thomas et Charlotte. Vous m’avez offert plus qu’un canape´ pour dormir durant ces
troisanne´es. Mercia` vousmesparents,sansvousjeneseraipasl’hommequejesuisaujourd’hui.
Jevousdoisbeaucoup,etjevousenseraie´ternellementreconnaissant.
Merci a` toi mon amour, Kun, d’avoir su re´pondre pre´sent pendant les moments de doutes.
Cettethe`senousapermisdenousrencontrer,etrienquepourcelacettethe`sevalaitlecoupd’eˆtre
ve´cue. Cettethe`seprendfinmaisencequinousconcerne,cen’estquelede´but...
4
Re´sume´ en franc¸ais
Protocoles AKE
Latransmissiondedonne´espersonnellesentredeuxentite´sa` traversuncanalnonse´curise´ comme
Internetoulesvoixradiosauseindesre´seauxmobiles,estl’undesenjeuxmajeursencryptogra-
phie. L’e´tablissementd’uncanalse´curise´permetd’e´changerdesdonne´essensiblesengarantissant
leurs confidentialite´s et inte´grite´s durant leurs e´changes. Dans le but de garantir ses proprie´te´s,
l’utilisationdeprimitivescryptographiquestelsquedesalgorithmesdechiffrementauthentifie´,est
requise. Sesalgorithmesne´cessitentquelesdeuxentite´sposse`dentuneclefsecre`tecommune. Par
conse´quent,une´changeaupre´alabledeclefsentrelesdeuxentite´sdoiteˆtreeffectue´ entrelesdeux
entite´safind’e´tablirlecanalse´curise´. L’e´tablissementd’uncanalse´curise´sereposesurl’exe´cution
d’unprotocoled’e´changedeclefsauthentifie´s,appele´ AKE(AuthenticatedKeyExchange).
Proprie´te´sdese´curite´classiques. LesprotocolesAKEexe´cute´sentredeuxentite´sdoiventgaran-
tir l’e´tablissement d’un canal se´curise´, a` travers l’e´change d’une ou plusieurs clefs temporaires
(autrement appele´es clefs de sessions), en conside´rant la pre´sence potentielle d’un adversaire de
type ”Homme-du-Milieu” (MitM) capable d’observer et d’intercepter l’ensemble des commu-
nications entre ses entite´s. Cet attaquant peut eˆtre soit passif (espionnant les communications
e´change´es) ou actif (capable de stopper, re´ordonner et injecter les messages de son choix). Con-
side´rantlesadversairesdetypeMitM,lesprotocolesAKEdoiventgarantirlesproprie´te´ssuivantes:
• La confidentialite´ des clefs de sessions e´change´es : un adversaire ne peut pas obtenir la
moindreinformationa` proposdesclefsdesessionsdurantleure´tablissement.
• La confidentialite´ des secrets permanents : un adversaire ne peut pas obtenir la moin-
dre information a` propos des informations secre`tes permanentes qui sont utilise´es durant
l’exe´cutionduprotocole.
• L’authentification : toutes les entite´s qui doivent eˆtre authentifie´s durant le protocole AKE
nepeuventpaseˆtreimpersonnifie´esparunadversaire.
• La”non-rejouabilite´”desmessages: cetteproprie´te´requitlafraicheurdesmessagese´change´s
durantl’exe´cutionduprotocoleAKE.
Uneproprie´te´supple´mentaireprimordiale: lerespectdelavieprive´e. Lanotiondevieprive´e
peutprendrediffe´rentsens,commelesoulignentPftzmannetHansen[95]. Danscemanuscrit,les
notionsquiserontutilise´es,sontcellesquisonthabituellementutilise´espoure´tudierlesprotocoles
d’authentificationetdede´rivationsdeclefs,e.g.,laconfidentialite´ dedonne´escaracte´ristiquesdes
utilisateurs, et de trac¸abilite´. Les utilisateurs sont tous caracte´rise´s par des donne´es personnelles
permanentes qui les caracte´risent telles qu’un identifiant, des e´tats, une localisation etc. Un pre-
mier niveau de respect de la vie prive´e des utilisateurs est garanti par une proprie´te´ consistant a`
assurer la confidentialite´ de l’ensemble de ses donne´es. Cette proprie´te´ est essentiellement cap-
ture´eparl’incapacite´ pourunattaquantdetype”Homme-du-Milieu”d’obtenirdel’informationa`
5
6
proposdedonne´escaracte´ristiquesdesutilisateurs. Lanontrac¸abilite´ desutilisateursestlanotion
la plus forte, qui en plus de conside´rer la confidentialite´ des donne´es usagers, conside`re qu’un
attaquantnepeutpastracerunutilisateur,cequiestpotentiellementpossiblemeˆmesansavoirdes
informationssursesdonne´espermanentes. Eneffet,parexemple,enreliantcertainesinformations
temporelles,leprofildel’utilisateurpourraiteˆtreretrouve´.
Typiquement, les protocoles AKE requie`rent la garantie de non trac¸abilite´ des utilisateurs,
qui est globalement de´finit par le fait qu’aucun adversaire n’est capable de distinguer si deux
exe´cutions distinctes du protocole ont implique´ le meˆme client ou deux clients distincts. Dans
ce manuscrit, la non trac¸abilite´ des utilisateurs sera e´tudie´e en conside´rant les attaquants de type
”Homme-du-Milieu”. Une garantie plus forte, vus comme un anonymat total des utilisateurs, se
basesurlefaitquemeˆmeunhonneˆteparticipantnepeutpastracerl’identite´desautresparticipants
au sein des communications. Une telle proprie´te´ pourrait eˆtre atteinte, dans une certaine mesure,
sileprotocoleAKEreposaitsuruneauthentificationbase´esurungroupe,commeparexempleles
signaturesdegroupe.
Se´curite´ Prouvable. E´tudier la se´curite´ des protocoles cryptographiques (plus pre´cise´ment les
protocoles AKE) est essentiel. De tels protocoles ont e´te´ de´finis sans ne´cessairement avoir une
analyse de se´curite´ fiable. La se´curite´ prouvable est un outil ge´ne´rique et mathe´matiques pour
e´tudier la se´curite´ des protocoles en conside´rant l’ensemble des adversaires potentiels de´finis
au sein d’un mode`le de se´curite´. Ce mode`le de´finit les capacite´s des adversaires et fournit une
de´finition formelle des diffe´rentes notions de se´curite´ requises par le protocole e´tudie´e. De´finie
durantlesanne´es80,ilyaglobalementdeuxapprochespourformaliserlase´curite´ : soitonutilise
lemode`lecalculatoiresoitlemode`leformel. Bienquel’approchedesme´thodesformellespre´sente
de nombreux avantages, un inconve´nient important reste pre´sent : il ne prend pas en compte la
se´curite´ desprimitivessous-jacentesainsiquelatailledesparame`tresduprotocole. Celasignifie
que la preuve obtenue par un mode`le formel n’est pas facile a` quantifier a` partir du moment ou`
en pratique les primitives cryptographiques ne sont pas ide´alise´es et la taille des parame`tres est
indispensable pour e´valuer la se´curite´ d’un protocole. Par conse´quent, il nous semble pre´fe´rable
d’utiliser un mode`le et des preuves calculatoires afin de pouvoir fournir une analyse de se´curite´
desprotocolesaussiprochequepossibledelare´alite´.
Contexte de nos recherches
Nos recherches se focalisent sur une utilisation spe´cifique des protocoles AKE, ou` un serveur
mandataire est requis entre le client et le serveur. Un serveur mandataire peut eˆtre requis pour
diffe´rentes raisons d’ordre pratiques telles que l’e´loignement ge´ographique entre le client et le
serveur, le cout et la latence des communications, etc. La pre´sence d’une telle troisie`me entite´
interme´diaire qui acte au sein des communication entre client et serveur impliquent diffe´rentes
modifications a` la fois au niveau de l’e´tablissement du canal se´curise´ mais aussi au niveau des
communications au sein du canal se´curise´. Ce serveur mandataire est conside´re´ comme un four-
nisseur local de services de´le´gue´ par le serveur afin de ge´rer localement un certain nombre de
servicespouruncertainnombredeclients. Deplus,lapre´senced’unserveurmandataireimplique
denouvellesconside´rations(proprie´te´setadversaire)surlase´curite´. Enpratique,leserveurman-
dataire n’est pas force´ment conside´re´ comme une entite´ de confiance totale (comme le serveur
principal). Ainsi, nous conside´rerons les serveurs mandataires comme des entite´s partiellement
de confiance, qui peuvent eˆtre potentiellement malicieuses, i.e., qu’elles peuvent vouloir obtenir
desinformationssupple´mentairesouacque´riruneautonomieparrapportauserveur, supe´rieurea`
ce qui lui a e´te´ autorise´. En ce qui concerne les protocoles e´tudie´s dans ce manuscrit, nous con-
side´reronsquelesserveursmandatairesmalicieuxontpourobjectifd’apprendredel’information
7
a` propos des clients et serveurs, ainsi que de les impersonnifier sans en avoir l’autorisation. Le
canal se´curise´ est souvent e´tabli entre le serveur mandataire et le client, avec l’aide du serveur
principal. Dans notre manuscrit, nous nous sommes focalise´s sur deux types de protocoles AKE
enparticulier: lesprotocolesAKAutilise´sauseindesre´seauxmobiles3Get4Gafindese´curiser
la voix radio, ainsi que le protocole TLS dans le cas spe´cifique ou` celui-ci requie`re un serveur
mandataire. Dans cette section, nous fournissons diffe´rentes informations concernant le contexte
d’utilisationdecesdiffe´rentsprotocoles.
Re´seaux Mobiles. Au sein des re´seaux mobiles 3G et 4G, les protocoles AKA (Authenticated
Key Agreement) sont typiquement utilise´s entre deux entite´s : un client mobile et son propre
ope´rateur. Un des objectifs principaux pour les ope´rateurs est de fournir un certains nombres
de services (appels te´le´phoniques, envoie de SMS, connections internet etc.) a` l’ensemble de
ses clients, peu importe leurs localisations. En pratique, une troisie`me entite´, que l’on appellera
fournisseurlocaldeservicesestrequise. Lescommunicationsentrelefournisseurlocaldeservices
etunclientmobilesontexe´cute´esa` traversuncanalpubliquea` based’ondesradios,alorsqueles
communicationsentrelefournisseuretl’ope´rateursesituentauseind’uncœurdere´seause´curise´.
Pour une question de se´curite´, certains services ne peuvent eˆtre fournis qu’au sein d’un canal
se´curise´. Par conse´quent, il est indispensable de se´curiser les communications de la voix radio.
C’estla` quelesprotocolesAKAinterviennent. Nouspre´cisonsqu’auseindesarchitectures3Get
4G,uncertainnombred’entite´spassivesactesdurantl’exe´cutiondesprotocolesAKA.Ne´anmoins,
cesentite´snefontquedelaretransmissiondemessagessansmodifierleurscontenus.
Le fournisseur local de services n’est pas toujours une entite´ de confiance, pour les clients
mobiles et les ope´rateurs. D’un point de vue ge´ographique, on conside`re que le client a deux
possibilite´s : soit il se situe au sein du re´seau mobile ge´re´ par son propre ope´rateur, soit au sein
de celui d’un autre ope´rateur. Dans le premier cas, le fournisseur local de services est ge´re´ par
l’ope´rateur du client, et dans ce cas, ilest conside´re´ deconfiance par l’ope´rateur. Dans le second
cas, quand le client est en situation d’itine´rance, les services sont fournis par une entite´ locale
ge´re´eparl’ope´rateurlocal,quiestdiffe´rentdel’ope´rateurduclient. Parconse´quent,danslecasde
l’itine´rance,lefournisseurlocaldeservicesnepeuteˆtreconside´re´ quepartiellementdeconfiance,
malgre´ les diffe´rents accords d’itine´rances e´tablis entre les diffe´rents ope´rateurs. L’ope´rateur fait
confianceauxfournisseurslocaldeservicesuniquementpourfournircertainsservicesa`cesclients
enitine´rance,maisildoitsepre´munird’une´ventuelcomportementmalicieuxdeleursparts,ayant
pour objectif d’obtenir des informations secre`tes concernant les clients mobiles. A contrario,
les fournisseurs requie`rent diffe´rentes informations temporelles, telles que des clefs de sessions
indispensableafindese´curiserlavoixradio.
De´le´gationdelivraisondeservices. LeprotocoleHTTPS(HyperTextTransferProtocolSecure)
est utilise´ afin de se´curiser les communications entre un navigateur web (le client) et un site In-
ternet (le serveur), en utilisant le protocole TLS (Transport Layer Security). Ce dernier garantit
laconfidentialite´ etl’inte´grite´ desdonne´ese´change´es. TLSestunprotocoleasyme´triqueexe´cute´
entre deux entite´s, le client et le serveur. Si les deux entite´s sont e´loigne´es d’un point de vue
ge´ographique, une certaine latence des communications apparait, i.e., le transfert des donne´es
sera lent quelques soient les possibilite´s de routage. Une des approches pour atte´nuer cette la-
tence, consisteenlade´le´gationdelivraisondeservices, de´nomme´eCDN(ContentDeliveryNet-
work), ne´cessitant un re´seau de serveurs mandataires locales a` proximite´ des clients. Le serveur
mandataire stockera et de´livra les services aux clients qui sont a` proximite´ a` la place du serveur
principal. L’architecture CDN implique d’avoir une totale confiance envers les serveurs man-
dataires, a` partir du moment ou` l’ensemble des informations (notamment celles requissent pour
e´tablir le canal TLS) requissent pour de´livrer les services de´le´gue´s par le serveur doivent eˆtre
stocke´s au sein de ses serveurs mandataires. De plus, la pre´sence d’une telle entite´ implique cer-
8
tainesproble´matiquesge´ne´riquespourladivulgationinconditionnelledutraficdesclientsversles
serveurs,etplusglobalement,pourlase´curite´ globaledesprotocolesquise´curisentlescommuni-
cationsentreleclientetleserveur. Lesserveursmandatairessontsouventvuscommeinde´sirable
d’unpointdevuedelase´curite´,ainsiquepourlerespectdelavieprive´edesclients.
CloudFlare propose une variante aux CDNs, appele´e Keyless SSL [101], qui ame´liore la la-
tence et atte´nue certains risques, en particulier lorsque les serveurs principaux ne souhaitent pas
quelesserveursmandatairesposse`dentetutilisentdesinformationssecre`teslonguesdure´es(clefs
secre`tesetc.) enleursnoms. Danscecas,leprotocoleTLSestmodifie´etexe´cute´entenantcompte
de cette troisie`me entite´ interme´diaire (le serveur mandataire) et de son potentiel malicieux. En
effet, les serveurs mandataires ne sont pas ne´cessairement de confiance, et leurs possibles com-
portementsmalicieuxdoiventeˆtreprisencompte.
´
Etat de l’art
Se´curisationdelavoixradiodesre´seauxmobiles. LesprotocolesAKA,apelle´sUMTS-AKAet
EPS-AKA,sontutilise´srespectivementauseindesre´seauxmobiles3Get4Gafindese´curiserla
voixradioene´tablissantuncanalse´curise´ entreleclientmobileetlefournisseurlocaldeservices.
Pourcela,uneauthentificationmutuelledesdeuxentite´sainsiqu’une´changedeclefsdesessions
sont ne´cessaires. La se´curite´ des protocoles AKE, classiquement e´xe´cute´s entre deux entite´s, fut
introduiteparBellareetRogaway[40]. SachantquelesprotocolesAKArequie´rentunetroisie`me
entite´ et que celle-ci est active dans l’e´tablissement du canal se´curise´, le mode´le de se´curite´ clas-
sique fourni par Bellare et Rogaway [40] et l’extension propose´e par Bellare, Pointcheval et
Rogaway(BPR)[39]nepeuventpaseˆtredirectementimporte´spourmode´liserlase´curite´ despro-
tocoles AKA. Par conse´quent, le manque d’un mode`le de se´curite´ calculatoire complet et pre´cis
prenant en compte l’ensemble des caracte´ristiques des protocoles AKA, implique l’impossibilite´
defourniruneanalysedese´curite´ calculatoiredesesprotocoles.
Celafaitplusde15ansquelapremie`reversionduprotocoleAKA(UMTS-AKA)estutilise´e,
cequiexpliquepourquoiunelargelitte´raturee´xisteautourdelase´curite´ deceprotocole. Unim-
portantre´sultatsurlesproprie´te´sd’authentificationmutuelleetsurl’indistinguabilite´ desclefsde
sessions e´tablies, a e´te´ propose´ par Zhang, et Zhang et al. [109,110]. Ils y de´crivent diffe´rentes
faiblesses remettant au cause ces proprie´te´s de se´curite´. Ces faiblesses sont base´es sur la cor-
ruption des fournisseurs locaux de services et sur des attaques par rejeu. Ils proposent ainsi
certaines contre-mesures. Malheureusement, ces dernie`res sont encore vulne´rable a` un certain
nombre d’attaques et les contre-mesures propose´es ne prennent pas en compte les conside´rations
pratiques.
Les protocoles AKA sont instantie´s avec deux ensembles d’algorithmes cryptographiques :
TUAKandMILENAGE. Misea` partunee´tudedeGilbert [70]quifournitunee´tudehors-contexte
de la se´curite´ des algorithmes de MILENAGE montrant qu’ils fonctionnent globalement comme
un mode compteur sur l’algorithme AES qui de´rive successivement diffe´rentes clefs, il n’est pas
clair que les proprie´te´s prouve´es d’indistinguabilite´ sont vraiment utiles pour garantir la se´curite´
desprotocolesAKA. Deplus,pourautantquenouslesachions,lase´curite´ desalgorithmesTUAK
n’ajamaise´te´ e´tudie´.
Despreuvesdese´curite´ desprotocolesAKAonte´te´ propose´ dansplusieurspapiers[30,109],
spe´cialement quand ils sont instancie´s avec les algorithmes MILENAGE. Les re´sultats les plus
pertinentsutilisentdesoutilsautomatiquesdeve´rificationformelleafindeproposerunepreuvede
se´curite´. Ces outils se reposant sur des mode`les formelles, ces preuves ne sont pas facile a` quan-
tifier, au vus des approximations e´tablies autour des parame`tres et algorithmes cryptographiques.
Nousconside´ronsqueseuleuneanalysecalculatoirepeutfourniruneanalysedese´curite´ comple`te
9
et fiable en conside´rant les diffe´rentes caracte´ristiques des protocoles AKA (primitives cryp-
tographiques,taillesdeparame`tres,utilisationd’e´tatsetc.).
LamajeurepartiedespapiersconcernantlesprotocolesAKAsefocalisentsurl’analysedure-
spectdelavieprive´edesclientsmobiles. Troisprincipalesattaquesonte´te´ e´tablies: lesattaques
base´essurlesIMSIcatcher[62],IMSIpaging [97,98],etsurl’impersonificationdesfournisseurs
locaux de services par corruption [110]. Ces attaques prouvent que durant l’e´xe´cution des pro-
tocoles AKA, le niveau de respect de la vie prive´e des clients mobiles est insuffisant. De plus,
plusieursautresvulne´rabilite´se.g.[30,33,87,103,108,110]montrentquelesprotocolesAKAne
respectent les notions de respect de vie prive´e standardise´es par le 3GPP. De telles vulne´rabilite´s
rendent possibles l’espionnage et la surveillance de masse illicites, et plus spe´cialement donnent
lapossibilite´ a` desattaquantsd’identifieretdetracerlesclientsmobiles.
Les deux versions (3G et 4G) des protocoles AKA e´tant assez similaires, le protocole EPS-
AKAestsouventvuscommeaussifaible,d’unpointdevuese´curite´ etrespectdelavieprive´edes
clientsmobiles,queleprotocoleUMTS-AKA.Anotreconnaissance,aucuneanalysenecompare
lase´curite´ etlerespectdelavieprive´edesclientsmobilesdesesdeuxprotocoles.
E´tablissementd’uncanalse´curise´ danslecadredesde´le´gationsdelivraisondeservicesweb.
Auvusdesnombreusesutilisationsetdesonarchitecturenon-orthodoxe,l’ensembledesver-
sions du protocole TLS ont fait l’objet de nombreuses analyses de se´curite´, pour n’en citer que
quelqu’uns [24–28,34,36,46–50,54,58,61,67,69,71,74,75,79,81,83,84,89,94,105,107].
La dernie`re version de TLS (1.3) est actuellement en cours de standardisation, et est conc¸ue
pour e´viter les nombreuses faiblesses pre´sentes dans les diffe´rentes versions du protocole. La
dernie`re version de TLS 1.3 est disponible sur le lien suivant : https://tlswg.github.
io/tls13-spec/.
Traditionnellement, les communications se´curise´es sont e´tablies en utilisant des protocoles
d’authentification et d’e´changes de clefs (AKE) comme de´taille´s dans les mode´les de se´curite´
[39,40,56]. Ne´anmoins, TLS ne peut pas garantir la se´curite´ AKE traditionnelle a` cause de cer-
taines caracte´ristiques [73,81] du protocole notamment du au chiffrement des derniers messages
duprotocoleTLS.Parconse´quent,uneproprie´te´ dese´curite´ plusfaibleae´te´ formalise´,denomme´
ACCE (Authenticated and Confidential Channel Establishment), qui fournit une spe´cification
cryptographique pre´cise pour TLS. Krawczyk, Paterson, et Wee [81] ont prouve´ la se´curite´ de
TLS 1.2 quand l’authentification mutuelle est requise. Les premie`res versions de TLS 1.3 ont
aussie´te´ analyse´savecdesmode´lesdese´curite´ prochesdumode´leACCE[61,82].
Les sce´narios ne´cessitant une troisie`me entite´ interme´diaire active dans l’exe´cution du proto-
coleTLSn’ontpasrec¸uautantd’attentionqueleprotocoleTLSexe´cute´ classiquemententredeux
entite´s. A notre connaissance, aucun mode`le de se´curite´ n’a e´te´ propose´, adaptant le mode`le de
se´curite´ ACCE,pourunmode`ledese´curite´ incluantlesspe´cificite´sduesa` latroisie`meentite´.
Dans le contexte de la de´le´gation de livraison de services web, deux variantes aux architec-
tures CDN furent propose´es: Keyless SSL [101] et mcTLS [91]. Ces deux variantes ont pour
but de se´curiser les communications entre le client et le serveur de manie`re plus efficace que de
se´curiserinde´pendammentlescommunicationsentreclientetserveurmandataire,etentreserveur
mandataireetserveur. Autantquenouslesachions,seulementunpapier[101]aanalyse´lase´curite´
l’architectureKeylessSSL.StebilaetSullivanontfourniunedescription,unelisteinformelledes
notions de se´curite´ que Keyless SSL doit garantir, ainsi qu’une e´tude de la performance de cette
nouvellearchitectureafindevoirl’ame´liorationdelalatenceparrapporteauxarchitecturesCDN.
Malheureusement,aucuneanalysecalculatoireouformelledese´curite´ n’ae´te´ propose´.
Unesecondearchitecture,appele´emcTLS,ae´te´ propose´ afindeproposerunesecondealterna-
tivea` base deserveurs mandataires. Dans cette variante, le protocoleTLS est modifie´ afin quele
clientetleserveurpuissents’accorderexplicitementsurlade´le´gationdesautorisationsdelectures
etd’e´crituresdesserveursmandatairesinterme´diaires.
10
Contributions
Danslebutd’analyserlase´curite´del’ensembledesesprotocolesd’authentificationetdede´rivations
de clefs, les mode`les de se´curite´ doivent eˆtre e´tablis en prenant en compte l’ensemble des car-
acte´ristiques de ces protocoles, et notamment l’utilisation active et la se´curite´ de la troisie`me
entite´ interme´diaire. Dans un premier temps, nous fournissons un nouveau mode`le de se´curite´
AKEquiconside`relatroisie`meentite´ interme´diaireactifdanslescommunicationsclient-serveur,
comme une important part du mode`le. Les proprie´te´s de se´curite´ de ses protocoles, au sein de
ce nouveau mode`le, sont e´tablies en conside´rant a` la fois les adversaires de type ”Homme-du-
Milieu”,i.e. l’indistinguabilite´ desclefsainsiquelanon-impersonificationdesentite´squidoivent
eˆtre authentifie´, et le potentiel comportement malicieux des fournisseurs de services locales, i.e.
laconfidentialite´ desclefsdesessionsainsiquelemaintiend’unecertainede´pendancedesesen-
tite´senverslesserveursprincipaux. Dansunsecondtemps,unpremiermode`ledese´curite´ ACCE,
ge´ne´ralisant le mode`le ACCE en deux entite´s pour les protocoles qui font intervenir un serveur
mandataire interme´diaire actif dans les communications client-serveur. Ce mode`le de se´curite´
inte`grediffe´rentesnotionsdese´curite´, lesclassiques, i.e. l’authentificationdesdiffe´rentesentite´s
ainsiquelase´curite´ ducanale´tabli, maisaussideuxautresproprie´te´sprovenantduserveurman-
dataire, qui garantissent que le serveur mandataire ne puisse pas eˆtre plus de´pendant que ce que
serveurluiautorise(accountabilityandcontentsoundness).
Danscemanuscrit,nousfournissonsuneanalysedese´curite´dediffe´rentsprotocolesd’authen-
tificationetdede´rivationsdeclefsentroisentite´sdansdiffe´rentscontextes: lesprotocolesAKA
utilise´sauseindesre´seauxmobiles,etKeylessSSLutilise´sauseindescommunicationsentreun
navigateuretunserveurweb. Nousinsistonssurlefaitquedetellesanalysessontindispensables
vusquecesprotocolessontde´ja` imple´mente´setutilise´sauquotidien. Nousfournissonsuneanal-
yse de se´curite´ comple`te du protocole UMTS-AKA et nous prouvons que ce protocole atteint la
se´curite´AKEde´sire´ea`partirdumomentou` lesfournisseurslocauxdeservicesnesontpascorrupt-
ibles. Deplus,nousanalysonslase´curite´ duprotocoleEPS-AKAafindevoirs’ilgarantitplusou
moinsles meˆmesnotions dese´curite´ que leprotocole UMTS-AKA.Nousutilisons uneapproche
modulairea` basedere´ductionsafind’e´tablirlase´curite´ desesdeuxprotocoles: dansunpremier
temps, nous prouvons la se´curite´ de ses protocoles est atteinte sous la condition que l’ensemble
des primitives cryptographiques utilise´es sont pseudo-ale´atoires, et dans un second temps, nous
ve´rifiionsquelesdeuxinstantiationspossibles(TUAKetMILENAGE)peuventatteindreunetelle
proprie´te´. Nous proposons (a` notre connaissance) la premie`re analyse calculatoire comple`te et
rigoureusedesprotocolesAKAetdeleursdeuxinstantiations. Finalement,nousfournissonsune
analyse de se´curite´ du protocole Keyless SSL en capturant les diffe´rentes caracte´ristiques dues a`
lade´le´gationdeservicesa` unserveurmandataire. Notreanalysesoulignediffe´rentesfaiblessesde
se´curite´ etainsiquedesproble´matiquespratiques. Ainsi,nousproposonsunenouvelleversionde
KeylessSSLquigarantitunemeilleurese´curite´ danslenouveaumode`le3ACCE.
Une proprie´te´ transverse a` la se´curite´ mais indispensable au sein des re´seaux mobiles est le
respect de la vie prive´e des clients mobiles. Conside´rant les nombreuses faiblesses remettant en
causelerespectdelavieprive´edesclientsmobiles,notammentcellespermettantlasurveillancede
masseetlatrac¸abilite´,durantl’e´xe´cutiondesprotocolesAKA,VanDenBroeketal.[104]etAra-
pinisetal.[31]ontpropose´ respectivementdesvariantesdesprotocolesAKA.Nousutilisonsune
approchecalculatoireafindeprouverquel’ensembledesesvariantese´chouentencorepourgaran-
tir le respect de la vie prive´e des clients mobiles. Nous proposons des ame´liorations qui garan-
tissent l’ensemble des proprie´te´s lie´es a` la vie prive´e des clients mobiles de´finis par le 3GPP, en
conside´rantlesattaquantsdetype”Homme-du-Milieu”. Deplus,nousprouvonsquenosvariantes
sontoptimalesd’unpointdevuedelase´curite´ etdurespectdelavieprive´edesclientsmobiles,a`
partirdumomentou` lastructureglobaledecesprotocolesestmaintenue. Danscesens,nosvari-