Secure Tunnels for Constrained Environments

THESE DE DOCTORAT DE

L’INSA RENNES COMUE UNIVERSITE BRETAGNE LOIRE

ECOLE DOCTORALE N° 601 Mathématiques et Sciences et Technologies de l'Information et de la Communication Spécialité : Informatique Par Loïc FERREIRA Tunnels sécurisés pour environnements contraints

Thèse présentée et soutenue à Rennes, le 18 novembre 2019 Unité de recherche : IRISA Thèse N° : 19ISAR 18 / D19 - 18

Rapporteurs avant soutenance :

Céline Chevalier Maître de conférences, Université Panthéon-Assas Paris 2 Henri Gilbert Directeur du laboratoire de cryptographie, ANSSI

Composition du Jury :

Président Serge Vaudenay Professeur, EPFL Examinateurs Céline Chevalier Maître de conférences, Université Panthéon-Assas Paris 2 Henri Gilbert Directeur du laboratoire de cryptographie, ANSSI Gildas Avoine Professeur, INSA Rennes Sébastien Canard Ingénieur de recherche, Orange Labs Caroline Fontaine Directrice de recherche CNRS, ENS Paris-Saclay María Naya-Plasencia Directrice de recherche Inria, Inria Paris David Pointcheval Directeur de recherche CNRS, ENS Directeur de thèse Gildas Avoine Professeur, INSA Rennes Co-directeur de thèse Sébastien Canard Ingénieur de recherche, Orange Labs

Intitulé de la thèse :

Secure Tunnels for Constrained Environments

Loïc FERREIRA

En partenariat avec :

Document protégé par les droits d’auteur

Secure Tunnels for Constrained Environments

Loïc Ferreira

Supervisors: Gildas Avoine and Sébastien Canard

In memoriam Maria da Luz

Résumé en français

tablir une communication sécurisée entre des entités distantes est l’un des objectifs auxquels la cryptographie cherche à répondre. De tels tunnels sécurisés impliquent la Émise en œuvre d’algorithmes cryptographiques de nature (symétrique, asymétrique) et de complexité diérentes. Le besoin de communications sécurisées se manifeste particulièrement avec l’apparition d’objets connectés aux usages très divers et la multiplication des interactions entre ces objets. Le développement de l’Internet des Objets entraîne le déploiement accéléré d’objets dits « à bas coût ». Contrairement à un ordinateur personnel ou un smartphone, ces objets ont des capacités très limitées notamment en termes de calcul, de communication et d’alimentation en énergie. Néanmoins, ces objets participent à la gestion d’infrastructures et d’équipements parfois très sensibles (fourniture d’eau, d’électricité, pacemaker ou débrillateur implanté dans le corps humain, etc.). Les données échangées (dont les commandes reçues) par ces objets doivent donc être protégées à la hauteur de ces usages. Cela requiert un haut niveau de sécurité, permis en général par des mécanismes cryptographiques de relativement grande complexité calculatoire. Or les algorithmes usuellement implémentés sur un ordinateur ou un smartphone ne sont pas fonctionnels sur des objets connectés étant données les capacités réduites de ces derniers. Cette partie introduit les problématiques des protocoles de sécurité destinés aux objets à bas coût. Elle présente également les résultats obtenus au cours de ce travail de doctorat, dont l’objectif est d’analyser la sécurité de protocoles existants et de produire des mécanismes d’échange de clé applicables aux objets à bas coût, sans compromis entre sécurité et ecacité.

Contexte

L’un des buts de la cryptographie est de permettre à deux entités distantes de communiquer de manière sécurisée. Cet objectif est rempli quotidiennement et de manière transparente lorsque l’on utilise un ordinateur personnel ou un smartphone pour, par exemple, consulter un service bancaire ou parler avec une personne éloignée. La mise en œuvre d’un tel tunnel sécurisé est rendue possible par l’utilisation conjointe d’algorithmes cryptographiques qui ont chacun une fonction diérente. La cryptographie asymétrique intervient alors lors d’une phase qui précède la communication proprement dite. Les algorithmes asymétriques sont utilisés pour que les deux parties impliquées puissent mutuellement s’authentier (i.e. : avoir la garantie de leur identité respective) et permettre de partager des paramètres secrets. Ces paramètres sont ensuite manipulés par des algorithmes symétriques qui vont concrètement protéger les messages (par exemple vocaux, visuels) échangés entre les deux parties. Ils garantissent que ces messages ne sont accessibles qu’aux deux parties légitimes (propriété de condentialité) et qu’il est impossible de modier ces messages à l’insu des deux parties prenant part à la iv Résumé en français communication (propriété d’intégrité). Ces algorithmes qui remplissent des fonctions distinctes ont des caractéristiques techniques diérentes. D’une manière générale, les algorithmes symétriques sont beaucoup plus rapides que les algorithmes asymétriques. Mais, comme indiqué plus haut, les algorithmes asymétriques permettent de garantir des propriétés de sécurité que ne peuvent orir les algorithmes symé- triques. C’est la raison pour laquelle les deux types d’algorithmes sont généralement utilisés dans les protocoles de sécurité : bénéciant pleinement de leur complémentarité, ces protocoles atteignent un niveau de sécurité supérieur. L’une des propriétés de sécurité, fondamentale, rendue possible par la cryptographie asymétrique est la condentialité persistante (ou forward secrecy [Gün90; DvW92]) généralement obtenue par le protocole Die-Hellman (DH) [DH76]. Cette propriété garantit que la divulgation d’un paramètre secret permanent ne compromet pas la sécurité des communications eectuées antérieurement à cette divulgation. Cela permet donc de maintenir la sécurité des communications passées en dépit de la compromission d’un paramètre secret important et réduit l’étendue des conséquences d’une telle compromission. Avec l’émergence de l’Internet des Objets (Internet of Things ou IoT), une multitude d’« objets connectés » sont déployés. Ces objets à bas coût de production ont des capacités de calcul et de communication restreintes. De même ils disposent d’une ressource limitée en termes d’alimentation électrique (ainsi ils peuvent être alimentés à l’aide d’une batterie dont il s’agit d’économiser la consommation, voire ne recevoir d’énergie que lorsqu’ils entrent en communication avec un lecteur). Parmi les cas d’usage impliquant ces objets, on peut citer les réseaux de senseurs sans l (Wireless Sensor Networks ou WSN), la radio-identication (Radio Frequency Identication ou RFID), les cartes à puce, les unités de contrôle véhiculaires (Controller Area Network ou CAN), la domotique, l’IoT industriel et la téléphonie mobile. Ces objets participent à la gestion ou au fonctionnement d’infrastructures ou d’équipements qui rendent des services sensibles tels que la fourniture d’eau, d’électricité ou l’assistance médicale par le biais de pacemakers et de débrillateurs implantés dans le corps humain. Les commandes transmises à ces objets et les données récupérées auprès de ces derniers impliquent donc un niveau de sécurité à la mesure du service qu’ils contribuent à rendre. Or le niveau de sécurité d’un algorithme cryptographique est généralement lié à sa complexité. Si les ordinateurs personnels et les smartphones peuvent exécuter des algorithmes cryptographiques « lourds » et complexes, il n’en est pas de même des objets connectés. Se pose alors, pour ces objets, la diculté de résoudre la contradiction induite par une attente élevée en termes de sécurité et une faible capacité en termes de fonctionnalité et d’ecacité. Un champ de la cryptographie s’attache, approximativement depuis le début du millénaire, à concevoir des algorithmes cryptographiques fonctionnels pour des objets à bas coût. La grande majorité de ces algorithmes sont symétriques. S’agissant de la cryptographie asymétrique, à part quelques exceptions, les eorts tendent, avec des succès mitigés, à optimiser l’implémentation d’algorithmes usuels an de les rendre fonctionnels sur ces objets. Ces travaux constituent une étape importante et nécessaire. Néanmoins, l’établissement d’un tunnel sécurisé suppose plus de fonctionnalités et de propriétés de sécurité qu’un simple algorithme de chirement ou de hachage.

Objectifs

Etant données les capacités réduites des objets connectés, le choix peut être fait de réduire les fonctionnalités des protocoles de sécurité existants et de choisir des mécanismes cryptographiques peu « coûteux » an que le résultat soit implémentable et fonctionnel dans un objet disposant de faibles capacités. Cette démarche, bien qu’intéressante, n’est toutefois pas com- Contributions v plètement satisfaisante puisqu’elle pose notamment les questions de la souplesse du protocole ainsi obtenu et celle de la sécurité globale oerte. Ainsi, les protocoles existants destinés à l’établissement de communications sécurisées avec ces objets s’appuient sur deux principes généraux. Tout d’abord une seule fonction symétrique est mise en œuvre. Ensuite la sécurité s’appuie sur un unique paramètre secret, exploité par l’objet tout au long de sa vie. Cela ne permet pas de garantir les mêmes propriétés et donc le même niveau de sécurité rendus possibles par l’utilisation additionnelle de mécanismes cryptographiques asymétriques. En particulier, la divulgation de cette clé symétrique permanente aboutit à la compromission de toutes les communications futures mais aussi passées que l’objet a établies. L’objectif principal de cette thèse est de concevoir des protocoles d’échange de clé, destinés à permettre l’établissement de tunnels sécurisés entre objets à bas coût, orant un niveau de sécurité plus élevé que les protocoles existants tout en étant fonctionnels sur ces objets. Nous tentons de tirer prot des caractéristiques techniques intrinsèques des algorithmes symétriques pour aboutir à ce résultat en refusant le compromis entre sécurité et ecacité.

Contributions

Dans cette section nous décrivons brièvement les résultats obtenus au cours de ce doctorat. Ces résultats peuvent se classer en les trois catégories suivantes : • Nous avons procédé à l’analyse de protocoles symétriques (dont des protocoles déployés à grande échelle dans le monde) et montré qu’ils sourent de vulnérabilités. Ces défauts de conception permettent la mise en œuvre d’attaques (quasiment) pratiques. Nous en présentons une démonstration concrète en attaquant avec succès, dans un cadre expérimental, des cartes à puce implémentant l’un des protocoles analysés. • Nous avons conçu des modèles de sécurité que nous avons ensuite utilisés an d’analyser rigoureusement les protocoles que nous avons construits. • Nous avons élaboré des protocoles symétriques d’échange de clé authentié impliquant deux ou trois parties. Ces protocoles orent des garanties de sécurité supérieures aux protocoles existants. Ces propriétés et fonctionnalités additionnelles que nous avons obtenues incluent notamment la propriété fondamentale de condentialité persistante et aussi la reprise de session. Cette dernière est particulièrement avantageuse pour des terminaux aux ressources limitées en termes de communication et calcul. Les articles acceptés en conférence (et, pour la plupart d’entre eux, déjà présentés) au cours de ce doctorat sont les suivants :

[AF18b] Gildas Avoine and Loïc Ferreira. Rescuing LoRaWAN 1.0. In: FC 2018. Ed. by Sarah Meiklejohn and Kazue Sako. Vol. 10957. LNCS. Springer, Heidelberg, 2018, pp. 253–271. [CF19] Sébastien Canard and Loïc Ferreira. Extended 3-Party ACCE and Application to LoRaWAN 1.1. In: AFRICACRYPT 19. Ed. by Johannes Buchmann, Abderrahmane Nitaj, and Tajjeeddine Rachidi. Vol. 11627. LNCS. Springer, Heidelberg, July 2019, pp. 21–38.

Analyse cryptographique de protocoles symétriques [AF18b; AF18a; CF19] Analyse du protocole LoRaWAN. Le premier protocole de sécurité considéré est LoRaWAN. La version 1.0 de ce protocole est actuellement une norme de fait pour les réseaux IoT longue distance et à basse consommation (Low Power Wide Area Network ou LPWAN) et est déployé dans plus de cent pays dans le monde entier. L’analyse approfondie que nous avons eectuée montre que ce protocole soure de vulnérabilités. Nous décrivons précisément comment ces défauts peuvent être exploités pour mettre en œuvre diérents types d’attaque, y compris des attaques pratiques. Ces attaques permettent d’enfreindre l’intégrité et la condentialité des données applicatives et de rompre la disponibilité d’un réseau. Le premier type d’attaque aboutit à « désynchroniser » un terminal vis-à-vis du réseau (i.e. : le terminal est déconnecté du réseau). Le deuxième type d’attaque permet de rejouer et de déchirer des trames applicatives (sans connaissance de la clé correspondante). Cela permet donc de tromper des éléments essentiels du réseau (situés dans le cœur de réseau) ou le terminal distant. Ces attaques, dues aux défauts intrinsèques du protocole, ne s’appuient pas sur des défauts d’implémentation ou matériels. Elles sont applicables, avec forte probabilité, contre tout équipement implémentant le protocole LoRaWAN 1.0. Finalement, nous présentons des recommandations permettant de contrecarrer les attaques décrites tout en étant compatibles avec la spécication et en maintenant l’interopérabilité entre un équipement corrigé et un équipement original. Selon nous, ces contre-mesures peuvent être aisément mises en œuvre. Le protocole LoRaWAN 1.1 se destine à être le successeur de la version 1.0. Il a pour objectif de pallier les faiblesses de la version 1.0. Nous présentons des vulnérabilités encore présentes dans cette nouvelle version 1.1. On peut notamment citer la possibilité d’épuiser des paramètres de taille trop petite et donc d’interdire à un terminal de se connecter au réseau distant, de contraindre un terminal en version 1.1 à exécuter la version 1.0, ce qui permet d’exploiter les faiblesses de cette dernière, ou encore de rejouer et de déchirer des messages chirés. Ces vulnérabilités sont dues essentiellement au fait de s’appuyer conceptuellement sur la précédente version et de vouloir garantir une certaine compatibilité entre les deux versions. Elles sont également induites par l’introduction d’une entité supplémentaire dans l’architecture LoRaWAN : un serveur utilisé comme tiers de conance et jouant principalement le rôle de gestionnaire de clés. Là encore nous présentons des recommendations permettant de pallier ces diérentes vulnérabilités.

Analyse du protocole SCP02. Le second protocole analysé est le protocole de sécurité SCP02. Ce protocole est déployé dans plusieurs milliards de cartes à puce (dont les cartes SIM pour la téléphonie mobile). Nous montrons que le protocole SCP02 est sujet à une attaque de type padding oracle attack qui permet de déchirer, sans connaissance de la clé correspondante, des données applicatives transmises dans un tunnel sécurisé par SCP02. Nous fournissons les résultats de nos expérimentations pratiques obtenues à partir de 10 modèles diérents de cartes Contributions vii

à puce conçus par six encarteurs. A notre connaissance, il s’agit de la première attaque réalisée avec succès contre le protocole SCP02. Nous récapitulons également un ensemble de méthodes permettant de contrecarrer cette attaque et en proposons de nouvelles applicables dans le cas de SCP02. Cette attaque est possible pour deux raisons. Elle est tout d’abord rendue possible par les caractéristiques techniques intrinsèques du protocole (i.e. : l’ordre des opérations cryptographiques lors du déchirement d’un message). Ensuite l’implémentation du protocole dans les cartes à puce que nous avons testées fournit le canal auxiliaire permettant la mise en œuvre concrète de l’attaque. A ce stade, nous ne pouvons préciser si ce comportement diérencié de la carte s’explique par le code source du protocole ou par les contraintes techniques du composant qui l’implémente. Ces résultats, exploitant une technique d’attaque décrite en 2002, montre que la sécurité d’un mécanisme cryptographique (et de tout produit qui l’implémente) a une date d’expiration et doit être périodiquement analysé de nouveau à la lumière de l’état de l’art en cryptographie et en sécurité.

Ces diérents résultats ont été présentés à chaque consortium en charge de la spécication technique du protocole analysé. LoRa Alliance a produit un document de recommandations destiné à renforcer la sécurité des réseaux LoRaWAN 1.0. Par ailleurs, certains changement ont également été pris en compte dans la spécication de LoRaWAN version 1.1. Concernant SCP02, ces résultats ont contribué à la décision de GlobalPlatform de déconseiller ociellement l’usage du protocole, considéré comme obsolète. Par ailleurs, les fabricants des modèles de carte analysés ont eu communication de nos travaux préalablement à leur présentation en conférence (entre octobre 2017 et mars 2018). Ces travaux ont été présentés lors des conférences internationales Financial Cryptography and Data Security (FC, 2018), Cryptographic Hardware and Embedded Systems (CHES, 2018) et Africacrypt (2019). Ils sont décrits de manière détaillée dans les chapitres 3 et 4.

Conception de modèles de sécurité [CF19; ACF19]

Modèle de sécurité 3-ACCE. Nous avons étendu la notion de modèle de sécurité 3-ACCE et produit un cadre d’analyse qui permet de saisir les propriétés de sécurité que les protocoles à trois parties doivent, selon nous, garantir an d’établir des tunnels sécurisés entre plusieurs entités. Nous avons appliqué ce modèle au protocole LoRaWAN 1.1. Par un choix de paramètres et de déploiement appropriés nous décrivons une version légèrement modiée de LoRaWAN 1.1 et prouvons formellement que cette version est sûre dans notre modèle 3-ACCE.

Modèle de sécurité 3-AKE. Nous avons également conçu un modèle de sécurité permettant d’analyser les protocoles d’échange de clé authentié mis en œuvre entre trois parties. Ce modèle inclut la propriété de sécurité fondamentale de condentialité persistante.

Ces diérents travaux s’inscrivent dans le champ des protocoles tripartites et de leurs modèles de sécurité. Comme l’attaque théorique et les vulnérabilités contre le protocole LoRaWAN 1.1 l’illustrent (décrites dans le chapitre 3), ces protocoles supposent une analyse de sécurité rigou- reuse dans un cadre permettant de saisir des menaces fortes. Ces travaux s’inscrivent dans une démarche de meilleure compréhension et d’analyse de la sécurité de protocoles multipartites, lesquels reètent la complexité croissante des communica- viii Résumé en français tions et des interactions générées par l’IoT. Ces travaux ont été présentés lors des conférences internationales Africacrypt (2019) et European Symposium on Research in Computer Security (ESORICS, 2019). Ils sont décrits plus précisément dans le chapitre 5.

Conception de protocoles symétriques d’échange de clé authentié [ACF20; ACF19]

Protocole SAKE. Nous décrivons un protocole d’échange de clé authentié entre deux parties, que nous appelons SAKE. Bien que basé uniquement sur des fonctions symétriques, ce protocole garantit la propriété de condentialité persistante sans besoin de procédure additionnelle (telle qu’une phase de resynchronisation) ou de fonctionnalité supplémentaire (telle qu’une horloge synchronisée). L’idée sous-jacente est d’actualiser la clé symétrique principale à l’issue de chaque session. Nous résolvons le problème de la synchronisation entre les deux parties qui se pose alors avec un mécanisme simple et ecace. Le protocole SAKE garantit que, quel que soit l’état des deux parties en termes de synchronisation lors du démarrage d’une session, ces deux parties partagent une nouvelle clé de session et sont synchronisées une fois la session conclue correctement : notre protocole SAKE est auto-synchronisant. De même qu’avec un protocole basé sur des fonctions asymétriques (par exemple DH), SAKE permet d’eectuer un nombre virtuellement illimité de sessions. De plus nous prouvons formellement la sécurité du protocole. Nous décrivons également une variante du protocole, que nous appelons SAKE-AM. Utilisée conjointement avec SAKE, cette variante permet d’obtenir une implémentation qui hérite des diérentes propriétés de SAKE (notamment la propriété de condentialité persistante). Cette implémentation permet à n’importe laquelle des deux parties d’initier une session de telle sorte que la moindre part de calculs soit toujours réalisée par la même partie. Cette implémentation est particulièrement avantageuse dans le contexte de l’IoT où des terminaux à bas coût commu- niquent avec un serveur central disposant de ressources en termes de calcul notoirement plus importantes. A notre connaissance, SAKE est le premier protocole garantissant la propriété de condentia- lité persistante et basé sur des fonctions cryptographiques symétriques qui soit comparable au protocole DH (au-delà des diérences intrinsèques entre cryptographie symétrique et cryptographie asymétrique).

Protocole 3-AKE. Nous présentons également un protocole générique d’échange de clé au- thentié à trois parties pour l’IoT que nous appelons 3-AKE. Ce protocole est basé exclusivement sur des fonctions symétriques (pour ce qui concerne les échanges entre le terminal distant et le serveur central) et garantit la propriété de condentialité persistante, à la diérence de protocoles IoT similaires (dont ceux déployés à grande échelle). Ce protocole permet d’eectuer des reprises de session sans réduire la sécurité (en particulier la condentialité persistante est toujours garantie). Cette fonctionnalité permet de réduire les coûts de calcul et de communication et est donc particulièrement avantageuse pour les terminaux à faibles ressources. Notre protocole 3-AKE peut être mis en œuvre dans un contexte de déploiement IoT réel (impliquant une multitude de terminaux distants et de serveurs) de telle sorte que ce dernier bénécie des propriétés intrinsèques du protocole. Cela permet notamment à des terminaux (mobiles) de se connecter de manière sécurisée à des serveurs successifs à un coût (en termes de calcul et de communication) réduit et sans compromettre la sécurité des échanges eectués avec de précédents serveurs. Conclusion ix

Ces travaux ont été présentés lors de la conférence internationale European Symposium on Research in Computer Security (ESORICS, 2019). Ils sont décrits plus précisément dans les chapitres 6 et 7.

Conclusion

Au cours de ce doctorat nous avons étudié les moyens permettant l’établissement d’un tunnel sécurisé par des terminaux disposant de peu de ressources en termes de calcul, de communication et d’énergie notamment. Au départ de notre démarche, nous avons constaté que la plupart des protocoles de sécurité dédiés à l’IoT, basés sur des fonctions cryptographiques symétriques, ne garantissent pas des propriétés de sécurité fortes telles que la condentialité persistante. D’autres protocoles, s’appuyant sur des mécanismes asymétriques, ne sont pas fonctionnels sur ces terminaux. D’une manière générale, la plupart de ces protocoles privilégient l’ecacité au détriment de la sécurité (chapitre 1). Nous avons illustré (concrètement) ce constat par l’analyse de deux protocoles de sécurité largement déployés (chapitres 3 et 4). Dans un deuxième temps, nous avons recueilli et produit (lorsqu’ils faisaient défaut) les outils méthodologiques qui nous sont apparus nécessaires à la saine conception des mécanismes qui sont l’un des objectifs naux de notre travail (chapitre 5). Finalement, nous avons proposé de nouveaux protocoles d’échange de clé, présentant des propriétés accrues (en termes de sécurité et d’ecacité) relativement aux protocoles existants (chapitres 6 et 7). A présent nous considérons les perspectives ouvertes par les travaux entrepris au cours de ce doctorat et les voies qui demandent à être poursuivies.

Perspectives et questions ouvertes

Approfondissements. Le protocole SAKE (resp. SAKE-AM) décrit dans le chapitre 6 est constitué de cinq (resp. quatre) messages qui peuvent être réduits à quatre (resp. trois) si les deux parties prenantes sont synchronisées (relativement à leurs clés maîtres) au démarrage de la session. Chacun des messages du protocole dessert un objectif particulier : authentier les deux parties, détecter un décalage, rétablir la synchronisation. L’ensemble permet nalement d’atteindre la propriété de condentialité persistante. La suppression d’un message ouvre la possibilité d’une attaque, comme l’ont montré les nombreuses versions alternatives que nous avons explorées. Nous pensons que ce nombre de cinq messages est le moindre possible mais n’avons pas formellement répondu à cette question de l’optimalité. Au chapitre 5, nous présentons un modèle de sécurité 3-AKE. Il est utilisé pour analyser le protocole d’échange de clé à trois parties décrit au chapitre 7. Ce modèle dénit la sécurité notamment sur la notion d’indistinguabilité des clés de session. Le calcul de la clé de session « nale » suppose l’implication, dans des calculs préalables, de clés de session intermédiaires. Cela entre en contradiction avec le paradigme d’indistinguabilité des clés. Pour pallier cette diculté, nous avons limité les possibilités pour l’adversaire de tester extensivement les diérentes clés. Un modèle de sécurité plus approprié permettrait à la fois de conserver cette notion d’indistinguabilité et de ne pas restreindre les actions de l’adversaire. A cet égard, les modèles de Brzuska, Fischlin, Warinschi et Williams [BFWW11], Brzuska, Fischlin et Smart [BFS+13] ou Krawczyk [Kra16] peuvent servir d’inspiration. Finalement, procéder à l’implémentation des protocoles SAKE et 3-AKE sur des terminaux à bas coût permettrait de montrer concrètement leur ecacité. x Résumé en français

Condentialité persistante en cryptographie symétrique. Un équivalent symétrique du protocole Die-Hellman remplacerait avantageusement ce dernier. Quelques travaux ont été eectués en ce sens par le biais de généralisations algébriques du schéma DH [Par15; PN18] ou avec la notion de « fonction de conversion » [CK05] (construite à partir d’une fonction symétrique, une telle fonction permet de transformer le chiré correspondant à une certaine clé en le chiré correspondant à une autre clé). Ce champ a, pour l’instant, aboutit à des résultats mitigés et mérite d’être défriché.

Cryptographie post-quantique. L’un de nos objectifs a été de concevoir des protocoles d’échange de clé à la fois ecaces sur un terminal à bas coût et présentant de meilleurs propriétés de sécurité que les protocoles existants. Nous avons donc proposé des mécanismes basés sur des fonctions symétriques. Avec l’ère de la cryptographie post-quantique il est maintenant clair que les schémas cryptographiques asymétriques classiques les plus courants sont cassés. Si la plupart des fonctions symétriques semblent encore préservées, des menaces émergent contre certaines primitives [KLLN16a; CNS17; KLLN16b]. Ainsi, certaines fonctions symétriques (chirement, MAC) sûres dans un modèle classique ne sont pas résistantes dans un modèle quantique. En eet, à partir de ces primitives il est possible de dénir des fonctions faisant apparaître une structure interne (par exemple une période cachée) qui peut être révélée par la troublante magie de la mécanique quantique. Cela permet alors d’accéder à un paramètre secret (tel qu’une clé) de l’algorithme attaqué. L’étude de la sécurité quantique peut être prolongée des primitives aux protocoles. Au-delà de la possibilité de s’attaquer aux primitives qui constituent un protocole, on peut essayer de déterminer dans quelle mesure les caractéristiques techniques internes de ce dernier peuvent être exploitées pour l’attaquer. Plus généralement, la cryptanalyse quantique des primitives et des protocoles cryptographiques (y compris ceux que nous proposons dans cette thèse) est à poursuivre et à entreprendre, de même que la conception de modèles de sécurité appropriés au contexte quantique.

« Survivabilité » d’un protocole de sécurité. Ce qui peut surprendre de la part de certains protocoles IoT existants est la possibilité de les casser, parfois trivialement. Cela est dû aux caractéristiques intrinsèques à ces protocoles. Ainsi, les attaques contre le protocole LoRa- WAN 1.0 décrites au chapitre 3 reposent essentiellement sur la taille extrêmement réduite de certains de ses paramètres. Les concepteurs de LoRaWAN justient ce choix par le nombre limité d’échanges de clé qu’un terminal est censé eectuer au cours de sa vie. Néanmoins, nous avons montré comment contraindre un terminal à initier beaucoup plus de sessions que prévu, ce qui aboutit à des conséquences néfastes en termes de sécurité. Cet exemple conduit à nous interroger sur le comportement d’un protocole lorsque ce dernier n’est pas mis en œuvre dans les conditions requises par ses concepteurs. La notion que nous abordons ici ne correspond pas à la résilience ou à la performabilité. La première notion peut être dénie comme la capacité d’un système attaqué ou en présence de fautes à repasser d’un état dégradé à un état nominal [CMH+07]. La seconde permet d’apprécier comment un système peut résister et maintenir ses fonctionnalités nominales en présence d’attaques [Mey80; Mey92]. La notion que nous tentons de saisir se rapproche de celle de survivabilité [KSS03; SKH+02]. Intuitivement, il est souhaitable que les propriétés de sécurité « essentielles » d’un système soient préservées, ce qui implique de dénir à quoi celles-ci corres- pondent. Le développement de l’IoT entraîne le déploiement d’un grand nombre de terminaux physi- quement accessibles à l’attaquant et pour lesquels il n’y a pas de moyen simple permettant une Conclusion xi mise à jour sécurisée. Le concept de survivabilité peut donc utilement contribuer à la sécurité de ces terminaux et de leurs utilisateurs.

Contents

Résumé en français iii

1 Introduction 3 1.1 Motivation ...... 4 1.2 Basics on Key Establishment Protocols ...... 10 1.3 Current Protocols for Constrained Devices ...... 11 1.4 Contributions of this Thesis ...... 26

2 Preliminaries and Denitions 31 2.1 Notation ...... 32 2.2 Preliminaries ...... 32 2.3 Security Models ...... 35

3 Analysis of LoRaWAN 43 3.1 Introduction ...... 45 3.2 Protocol LoRaWAN 1.0 ...... 46 3.3 Attacks against LoRaWAN 1.0 ...... 49 3.4 Recommendations for LoRaWAN 1.0 ...... 62 3.5 Protocol LoRaWAN 1.1 ...... 63 3.6 Vulnerabilities in LoRaWAN 1.1 ...... 67 3.7 Recommendations for LoRaWAN 1.1 ...... 72 3.8 Other Analyses ...... 73

4 Analysis of SCP02 81 4.1 Introduction ...... 82 4.2 The SCP02 Protocol ...... 82 4.3 The Generic Padding Oracle Attack ...... 83 4.4 Application to SCP02 ...... 85 4.5 Countermeasures ...... 95

5 Security Models 99 5.1 The Need for a Suitable Security Model ...... 100 5.2 The 3-AKE Security Model ...... 101 5.3 The 3-ACCE Security Model ...... 105 5.4 Security Proofs in the 3-ACCE Model ...... 112 xiv Contents

6 SAKE: a Two-party AKE 139 6.1 Motivation ...... 140 6.2 Symmetric-key AKE Protocol with Forward Secrecy ...... 143 6.3 Proofs for SAKE ...... 148 6.4 SAKE-AM: a Complementary Mode of SAKE ...... 156 6.5 A Random-free Variant of SAKE ...... 158 6.6 Comparison with the DH Paradigm ...... 159

7 Three-party AKE 163 7.1 Introduction ...... 165 7.2 Description of the 3-party AKE Protocol ...... 167 7.3 Session Resumption Procedure ...... 172 7.4 Concrete Instantiation ...... 175 7.5 Security Proofs ...... 181

8 Conclusion 195 8.1 Summary of the Results ...... 195 8.2 Perspectives and Open Problems ...... 196

Bibliography 199

List of Figures 221

List of Tables 223

List of Algorithms 225

hc i tbigipeetdi eie ihdrn aaiiisi em fcomputation, of terms in capabilities dierent with devices in implemented being at aim which rpsdi h at ial epeettecnrbtoso hsthesis. been this have of Contents contributions which the solutions present dierent we describe Finally formally also past. We and the analyse in protocols. to proposed such used of methods security the the and prove devices, time low-resource to same dedicated the protocols at and functional, possible. fully as level being security these highest challenge: Therefore, the following providing devices. the constrained face (very) must includes list protocols This energy. and communication, S nti hpe,w rsn h oiain n iclisbhn uhniae e exchange key authenticated behind diculties and motivations the present we chapter, this In proposed been have protocols security several Things, of Internet the of arrival the With rtcl.Teepooosama hrn ertkymtra mn w rmore or two among material key secret a sharing at aim protocols These protocols. ate nodrt usqetyecag aai euemanner. secure a in data exchange subsequently to order in parties establishment tunnel ecure . Motivation 1.1 . urn rtcl o osrie Devices Constrained for Protocols Current 1.3 Protocols Establishment Key on Basics 1.2 . otiuin fti Thesis this of Contributions 1.4 .. h ieo optn ahnsadCryptography and Machines Computing of Rise The 1.1.1 .. ol fKyEtbihetProtocols Establishment Key of Goals Protocols Establishment Key of 1.2.2 Types 1.2.1 1.1.2 .. eino euiyModels Security of Design Protocols Existing of Analysis 1.4.2 Cryptographic 1.4.1 Summary Selective Proved Being of Importance 1.3.3 The Protocols the of 1.3.2 Overview 1.3.1 .. eino owr ertSmerckyProtocols Symmetric-key Secret Forward of Design 1.4.3 h edfrCytgahcPooosEceto osrie Devices Constrained on Ecient Protocols Cryptographic for Need The ...... soeo h ants fatetctdkyexchange key authenticated of task main the of one is ...... Introduction ...... 1 10 26 11 10 26 23 22 12 28 11 27 4 8 4

1 4 Chapter 1 Introduction

1.1 Motivation

1.1.1 The Rise of Computing Machines and Cryptography Symmetric and asymmetric cryptography. The rst and still a paramount goal of cryptography is to ensure condentiality of data. All along the history of mankind, dierent techniques have been devised to achieve this task. Some of them aimed at hiding the existence of the data, others aimed at hiding the meaning of the data. Since the birth of modern cryptography after World War II, new schemes have been conceived in order to ensure the condentiality of data. Applying the Kerckhos principle [Ker83a; Ker83b], these schemes are based on (simple) mathematics operations and make use of one unique secret parameter: the encryption key. The same secret key is used to encrypt the data and decrypt the ciphertext. This paradigm is called symmetric cryptography. To the best of our knowledge, the rst modern examples of such schemes are Lucifer [Fei73] and DES [Nat99]. Data condentiality is a crucial need when a communication occurs over an insecure channel. In such a context, prior to exchanging encrypted data, the secret key must be shared between the two parties involved in the communication. The issue of transmitting a secret key over an insecure channel has been given a solution with the seminal paper of Die and Hellman (DH) [DH76] which founded the eld of asymmetric cryptography. The basic idea consists in using two keys instead of one: a public key which can be surrendered to anyone, and a private key which must be known only to the legitimate party. Hence, any distant party B willing to communicate with some party A can use A’s public key to send or compute a secret value that A can yield in turn with its private key. Shortly after, Rivest, Shamir and Adleman (RSA) [RSA78] presented an asymmetric encryption (and a signature) scheme. Nowadays, with the sole purpose of key agreement (putting aside the question of authenticating the parties, necessary to ensure that the secret key is shared only by legitimate parties), these asymmetric schemes are extensively used in widely deployed protocols such as TLS 1.2 [DR08], TLS 1.3 [Res18], IKEv2 [KHN+14], SSH [YL06c; YL06a; YL06d; YL06b] to name a few.

Smaller, more pervasive computing devices. The need for and the development of modern cryptographic schemes has evolved with the eld of computer science. The Colossus and ENIAC machines, at the time of World War II, can be regarded as the rst electronic, digital computers. They opened the rst era of computing: the mainframe computers owned and used by governmental agencies or companies. Followed the era of mini and then personal computers (with machines such as the Hewlett-Packard HP 3000, the R2E Micral, or the DEC PDP-8), where the latter are owned and used by one person. With the invention of the rst micro-processor by Intel in 1971, the computers become smaller and faster. This opens the era of ubiquitous computing characterised by the widespread use of small computer products, such as personal digital assistants or smartphones [Kru09]. Following the prediction of Mark Weiser [Wei91] that “the most profound technologies [...] weave themselves into the fabric of everyday life until they are indistinguishable from it”, the rise of the Internet of Things (IoT) leads to the deployment of more pervasive and also more constrained devices with respect to their capabilities. It is expected that 125 billion connected objects be deployed by 2030 [IHS17]. They are nowadays used in various contexts, ranging from Wireless Sensor Networks (WSNs), Radio Frequency Identication (RFID) tags, smart cards, Controller Area Networks (CANs) for vehicular systems, smart home, medical care (eHealth), up to industrial Internet of Things. Compared to standard computing devices (e.g., personal computers, smartphones) these objects do not have the same level regarding energy resource, computation power, and memory size. Consequently, they cannot all eciently implement asymmetric schemes which imply an heavier circuitry (e.g., hc ups st eie lcrcsok.Mrn igle ag ebuhd n Preneel and Verbauwhede Yang, Singelée, Marin, shocks. electric deliver to is purpose which h eore hybn orsodt nuprbudi ead otevr constrained very the to regards in bound upper an to correspond benet they resources The ZigBee the of nodes all by shared key symmetric master static the attack) side-channel a (through against attack remote a mount to able were [MV15] Valasek and Miller few, a only mention To eso 2t 0 hc losepotn ao ekeso htvrin nvrinS,the S0, version In version. that of weakness major a exploiting allows which S0, to S2 version pnst eetv umr.Asrc oprsni o osbedet h nrni dierences intrinsic the to due possible corre- not 1.1 is Table comparison elds. strict A two summary. these selective in a operations to sponds dierent of results reasons). implementation obvious the for consider gures, even provide on to goal unable same are we the which achieve (for to implementing devices diculty in constrained the succeeds more illustrate barely to which devices, schemes, thesis. gifted asymmetric this more eciently in these target use our we not Nonetheless are devices. devices these that stress We devices. IoT several by used trollers results. implementation limited of their glimpse A to due circuitry, heavy an such implement to able are latter resources. the of send all to not able said, were patient, the to pump. related insulin the information to private commands retrieving pump,unauthorised insulin to an addition of in protocol and, communication proprietary the reverse-engineered also [MSY+16] messages, previous replayed successfully also the They compromising battery. its in exhausting succeeded by and availability device’s debrillator, proprietary implantable Marin, the an reverse-engineered of state. [MSG+16] protocol hypoglycaemic Preneel communication an and into Willems patient delivering Chothia, the allows Garcia, plunging patient Singelée, and specic insulin, a of estimates to amount that corresponding incorrect peripheral settings an pump wireless the implanted insulin Changing the an glucose. and between blood insulin the exchanged of level messages proper the reversed the has “encrypt” delivers [Rad11] to that Radclie used life. scheme patient’s encoding the the endanger clearly and a the risk replay to at denial-of-service to (up stored and shocks diagnosis, voltage device, high battery-powered and triggers the name which command exhausting as in such succeeded patient, they the device), to got implanted related authors data (the incorporates unencrypted issues that privacy to device uncovering access medical Besides implantable functions. debrillation an and analysed pacemaking [HHR+08] Maisel Morgan, the Defend, and on Clark, Kohno attack Ransford, Heydt-Benjamin, his Fu, Halperin, illustrated has lock. on smart Tierney eavesdropping L1 network. Conexis by Z-Wave Yale the merely keyless joins attacker node an a by when computed exchanged be data can from key downgrade symmetric to master device Z-Wave network’s a compel to how shown also retrieved has rst [Tie18] They Tierney mechanism. network. update over-the-air the network, through ZigBee worm a a over propagate driving. taking to and in then functioning succeeded and Area [RSWO17] car’s Controller O’Flynn the vehicle’s and in Weingarten the used Shamir, to units Ronen, connected electronic is multiple multimedia system connects the this which of that Network mechanism They fact update the braking. rmware exploited the and and protect steering system, to as used such password systems WiFi physical a certain guessed aects which attain. Cherokee, (not) Jeep do a devices constrained these that level security the show regularly eld academic security. and devices Constrained tables). look-up small and operations, symmetric arithmetic than simple numbers) on big based involving (essentially curve functions elliptic on operations exponentiations, modular Motivation 1.1 nodrt ihih h ieec ewe ymti n smerccytgah,we cryptography, asymmetric and symmetric between dierence the highlight to order In as but, devices, these of level security the enhance could schemes asymmetric likely, Highly eycnrtl,nwppr rrsac eut nthe in results research or newspapers concretely, Very sa lutainltu osdrsm microcon- some consider us let illustration an As 138 ) hs unrblte oeapotential a pose vulnerabilities These V). 5

1 6 Chapter 1 Introduction between symmetric and asymmetric cryptography. Rather we aim at highlighting the gap, with regards to the implementation eciency on constrained devices, that separates these two types of operations, which are commonly executed in key exchange protocols. We start with the Atmel ATmega128L [Atm11] (running at 7.37 MHz frequency) which equips the MICAz and MICA2 motes. A point multiplication on a 256-bit prime eld elliptic curve takes 1.28 seconds (second component in Table 1.1). This leads to an ECDH key exchange which lasts 4.14 seconds [LWG14]. This gure does not include any authentication step (e.g., a signature). On the Atmel ATmega2560 chip [Atm14] (at 16 MHz frequency), an ECDH key exchange corresponding to a 255-bit prime eld elliptic curve lasts 3.49 seconds [HS13]. The Ed25519 signature [BDL+12] computation and verication adds respectively 2.14 and 2.51 seconds [HS13]. In order to get a full key exchange the session key derivation step must be added. Nonetheless it involves usually only symmetric-key operations, hence it is much faster than the signed ECDH key exchange. Therefore the computation time for such a full key exchange on ATmega2560 lasts roughly 8.14 seconds (third component in Table 1.1). Furthermore, the time needed to send and receive the key exchange messages must be also added. On a MSP430 microcontroller [Tex03] (running at 8 MHz) a simple RSA 1024 decryption needs 43,368,720 cycles, and lasts 5.42 seconds [GAB19] (rst component in Table 1.1).

Table 1.1 – Selective comparison between symmetric (in blue) and asymmetric (in green) operations on constrained chips

Timea Modular exponentiation (cycles) (s) RSA 1024 decryption [GAB19] 43,368,720 5.42

Timeb Point multiplication (cycles) (s) 256-bit prime eld elliptic curve [LWG14] 9,420,788 1.28

Key exchange Energy (mJ)b Time (s)b ECDH (Curve25519)-Ed25519 [HS13] - 8.14 ECDH-ECDSA (160-bit prime eld) [MGSP08] 283.0 - Kerberos (AES 128) [MGSP08] 14.4 -

Time Energy Symmetric encryption Area (GE) (cycles/byte) (µJ/block)a AES 128 [BRS+15; MPL+11; BRS+15] 132a 2.18 2400c Speck 128/128 [BRS+15; BSS+13; BRS+15] 103a 1.44 1280d PRESENT 80 [DCK+15; YKPH11] 1053b - 1030c

aMSP430 bATmega128(L)/ATmega2960 c0.18 µm d0.13 µm

In comparison, the symmetric functions perform much better. On ATmega2560, encryption with the stream cipher Salsa20 [Ber08] requires 270 cycles/byte, and authentication with 128 With with ihtesce e tef hc ste nqeprmsaet authenticate. to message per unique then is which itself, key secret the with al .) soecnse ymti prtosae“ are operations symmetric see, can one As 1.1). Table 2832 o iecanlatcs[CS6.Frhroe h rcsiguis uha microcontrollers, as such units, processing the Furthermore, [NCOS16]. attacks channel side for signature ECDSA than an microcontroller and MSP430 exchange the a key on on ECDH instance, implement to For able schemes. are asymmetric and powerful other better More perform which enhancements. exist hardware devices exploiting and and chips implementation, their of eciency the lighter. faster, Better, [EKP+07]. consumption power higher magnitude as such algorithms symmetric than 1.1). Table in component and TelosB: Kerberos consumes on for process cost computation energy the total MICAz, On the asymmetric whether executed. on are depending operations dierently symmetric very or distributed is communication and tation a to respectively consumes Kerberos and ECDH-ECDSA is Kerberos consumes Kerberos with [NYHR05] Kerberos a on based MSP430 scheme the features two (which consider [MEM] at TelosB us running and Let microcontroller MICAz resources. on energy implemented limited protocols with exchange managed key be must processes Both chines. ones. asymmetric for in in encrypting corresponding decryption PRESENT than operation and purposes The encryption other schedule, value). for key pseudo-random block to a building generating because a (e.g., results as data these used authenticating that mention be or deem we also some Here IoT. can though of function even context symmetric general, the a in in recommended acceptable not are is parameters size shorter block the and size key the to and corresponding ATmega128 following on the ciphers excerpt block we lightweight [Atm11], of implementation the Regarding [LWG14]. cycles and takes [Ber06] Curve25519 Poly1305 Motivation 1.1 oegnrly in smercoeain EC perform (ECC) operations asymmetric ecient generally, More ma- communicating also but machines computing only not are devices these Furthermore, CTR 16 1 and Speck 224 90 ntecluaino h uhniaintg utradShaerpaeteuulecyto ftenonce the of encryption usual the replace Schwabe and Hutter tag, authentication the of calculation the In 256 2 AES ylst nrp n uhniaea authenticate and encrypt to cycles Speck ye,crepnsto corresponds bytes, eod LL2.Hwvrtomc piiainmyyedvleaiiiswihallow which vulnerabilities yield may optimisation much too However [LOL12]. seconds . 3 oewith mode btpiel litccrenesrespectively needs curve elliptic eld prime -bit btpiel litccrecnb optdi esthan less in computed be can curve elliptic eld prime -bit Speck aigi aoro ebrs oevr h nrycs orsodn ocompu- to corresponding cost energy the Moreover, Kerberos. of favour in saving % Br5 needs [Ber05] 128 64 94 1 ed respectively needs 128 o ebrsand Kerberos for % / . 96 9 and 128 oeeeg in hnteaymti rtclED-CS.O TelosB, On ECDH-ECDSA. protocol asymmetric the than ecient energy more % / 128 BS1]( [BSS+13] AES / 160 Speck 14 128 ai nrpinoeainrequires operation encryption basic a , . btpiel litccre h eodi h ymti-e protocol symmetric-key the is second The curve. elliptic eld prime -bit 4 , ae respectively takes Speck J(hr opnn nTbe11.Hne h ymti-e protocol symmetric-key the Hence, 1.1). Table in component (third mJ 177 eadn smercshms eea rn isa improving at aims trend general a schemes, asymmetric Regarding 128 22 AES 64 4 2288 ylsbt [HS13]. cycles/byte , 791 / H)mts[GP8.Tes rtcli nECDH-ECDSA an is protocol rst The [MGSP08]. motes MHz) btbokand block -bit 128 59 and 128 55 , , 085 579 yls naMP3 ircnrle,ecyto with encryption microcontroller, MSP430 a On cycles. osmsrespectively consumes AES o CHEDA ncnrs,o S40 encryption MSP430, on contrast, In ECDH-ECDSA. for % PRESENT nMCz CHEDAconsumes ECDH-ECDSA MICAz, On . , yls[S3,adapitmlilcto na on multiplication point a and [HS13], cycles 59 83 o ntne n hscreae iha with correlates this and instance, for , 612 16 o CHEDA iia gr sobserved is gure similar A ECDH-ECDSA. for % 132 96 bt lc.I otat on utpiainon multiplication point a contrast, In block. -byte and btky DK1] iels than less size A [DCK+15]. key) -bit ed respectively needs and CBC 1 245 hscrepnsrsetvl to respectively corresponds This 130 103 AES oeof mode , 853 . 9 ylsbt sefut opnn in component fourth (see cycles/byte ihnn fast lightning 128 6 Jand mJ , 276 yls nrpinol of only Encryption cycles. 2 . 143 18 [Nat01], 128 , 630 and ylsbt BS1] which, [BSS+15], cycles/byte 12 3175 1 ye with bytes , . 9 100 eodadvrdi less in veried and second 1 64 , . 964 TG5 oprdto compared [TPG15] ” PRESENT 44 , J hc corresponds which mJ, 3251 to , µ 549 e lc (fourth block per J 1 , and 000 283 and , AES 2 to 15239 oeslowly more 80 Jwhereas mJ , 128 14 3 Speck [BKL+07] 4320 resof orders 160 , 128 856 isfor bits cycles. 4 , AES of % , and and bits 446 192 7

1 8 Chapter 1 Introduction used in constrained devices have not increased their computational capabilities at the same rate as microprocessors for personal computers or smartphones [MMDF+12]. Therefore, the achievements may not be enough in order for very constrained devices to be able to implement asymmetric schemes, even optimised. These devices equip sensors and actuators which, despite (or because of) their very constrained resources (i.e., their low cost), are used in real-life deployments for home automation security, remote keyless entry, security management of infrastructures, and many other purposes that require establishing secure tunnels. In that context, there is a persistent need for smaller size, lower computation, energy, and memory resources devices, and lower production costs. Moreover, the post-quantum era opens. Although threats emerge against some primitives [KLLN16a; CNS17; KLLN16b], symmetric cryptography seems less vulnerable against quantum computing so far. Regarding the “classic” asymmetric algorithms the assessment is straightforward: they are all broken in a post-quantum world [Sho97]. It is still uncertain if post-quantum asymmetric algorithms more ecient than the classic ones will be devised. Consequently, considering using solely symmetric cryptography and its intrinsic lightweightness in order to establish secure communications is relevant in the context of constrained devices.

1.1.2 The Need for Cryptographic Protocols Ecient on Constrained Devices

From lightweight cryptographic primitives... The development of symmetric ciphers intended to be lightweight can likely be dated from the birth of the mobile telephony with the A5/1 [BSW01] and A5/2 [BBK03] encryption stream ciphers in the late 1980s. Research on this eld has become more intensive since 2010 with the proposal of numerous ciphers, mostly encryption and hash functions. Rather comprehensive surveys can be found in Biryukov and Perrin [BP17], and Hatzivasilis, Fysarakis, Papaefstathiou and Manifavas [HFPM18]. Several projects have been initiated in order to promote the design of ecient, lightweight and secure ciphers. For instance, the ECRYPT Stream Cipher Project (eSTREAM) [ECR08] organised by the European ECRYPT network between 2005 and 2008, focuses on stream ciphers, and includes a portfolio of functions intended to devices with highly restricted resources. The CAESAR competition [Ber19] dedicated to authenticated encryption (AE) functions ended in 2019 with a set of ciphers intended to resource constrained environments. In 2019, NIST started a Lightweight Cryptography competition [Nat19] which focuses on lightweight AE and hash functions. As illustrated by the aforementioned projects, most of the lightweight cryptographic functions belong to the eld of symmetric cryptography. Regarding lightweight asymmetric schemes, most of the work aims at adapting existing schemes to make them functional on a low-resource devices. Among the rare eective results, one can cite the Girault, Poupard and Stern [GPS06] (GPS) authentication and signature scheme (also known as cryptoGPS) which is an adaptation of the Schnorr scheme [Sch90], and targets as constrained devices as RFID tags. GPS has a similar limitation as the Schnorr scheme related to the usage of precomputed “coupons” that must be stored by the device. This narrows the number of GPS runs. Yet, a line of work aims at overcoming this drawback through periodic reload of coupons, or on-the-tag regeneration [HW08; NH09], as well as proposing improved variants of the protocol [GL04; CFR13].

... to lightweight cryptographic protocols. Establishing a secure tunnel between two (low-resource) parties implies implementing a protocol. The latter builds on cryptographic primitives in order to ensure several security properties (mutual authentication of the parties, condentiality and authenticity of data). As illustrated in Section 1.1.1, a very constrained ihrsett ihwih ucin nte19s tlast ayporeaysltoswhich solutions proprietary many to leads it 1990s: the in functions lightweight to respect with euiylvla tt-fteatprotocols. dedicated state-of-the-art protocols as current level the security Overall, often protocol. seemingly devices the narrows implement constrained and can to devices, that constrained devices all maintain to of suitable to types not order the is in requirement necessary a sometimes Such is security. clock) protocol’s Furthermore, synchronised the lost. a (e.g., procedure) is resynchronisation functionality end-device a extra this (e.g., an protocol by or regular sent detect the data to to independent valuable initiator procedure all the additional Meanwhile for an to it. wait unable solve must is responder, and and as end-device, issue the behave the the but only with server, can connection central For which problematic a party. server, a to the specic restore Therefore connects a for that allowed. session end-device not a an is initiate to converse to attributed ability is the possibility keep this protocols instance, Some runs. of number the compromise not do keys secret keys. long-term session some past as of disclosures known future property that fundamental guarantees a informally, based ensuring is in security lack their since they secrecy particular, key, protocols In symmetric the 1.1). static by Figure provided a (see “exibility” on schemes or asymmetric security of of use level these make same functions, that symmetric-key the on achieve built not Solely do protocols CFPR15]). [CS15; (e.g., questionable is security properties. security only and (possibly functionalities few all a secondly, ensure and to parties, used more) rstly, are (or functions principles: two symmetric-key main by one) two shared the is with key intended limitation symmetric protocols master this one current one overcoming each Therefore at ciphers instance). aim of for devices family constrained IPsec wide to or a TLS even (as or features functions, distinct asymmetric providing implement to unable is device Motivation 1.1 silsrtdi eto .,svrlpooosipyteueo sot one hc limits which counter (short) a of use the imply protocols several 1.3, Section in illustrated As ciphers block of evolution the mimic to seems protocols symmetric-key suitable of lack The iue1.1 Figure Gn0 v9] hspoet savr togfr fln-emscrt which, security long-term of form strong very a is property This DvW92]. [Gün90; rtcl o osrie eie:cretstainadexpectations and situation current devices: constrained for Protocols – Security

asymmetric

rd euiyfreciency for security trade protocols symmetric protocols expectations raof area Eciency and , onot do tantesame the attain forward 9

1 10 Chapter 1 Introduction

1.2 Basics on Key Establishment Protocols

1.2.1 Types of Key Establishment Protocols

The purpose of a key establishment (or key exchange) protocol is to enable two parties (possibly more) to share a secret value usually called a session key. In this section and in this thesis we will consider two-party protocols possibly aided with a trusted third party. In order to yield a secret key, the two parties share beforehand a common value. That can be a symmetric key or a public key certicate. In the rst case, condentiality of the symmetric key is necessary in order to guarantee the security of the key establishment protocol. Knowledge of this symmetric key allows an adversary to impersonate a legitimate party, and compute the secret value yielded by the protocol run. In the second case, integrity of the certicate is required otherwise an adversary could replace the certicate with one of her choice, which is similarly detrimental to the protocol’s security. The key establishment protocols can be broadly divided in two sets: key transport and key agreement protocols. A key transport protocol is a key establishment scheme where one party generates or obtains a session key, and then transfers it to the other party. A key agreement protocol is a key establishment mechanism where the session key is a function of input by all parties involved in the protocol run. The two parties involved in a successful protocol run are said to be partners. The purpose of the session key output by a run of the key establishment protocol is usually to establish a secure tunnel between the two partners. This secure tunnel may then ensure condentiality, integrity and authenticity of the data subsequently exchanged between the two parties. The rst property guarantees that data is available only to the two partners. The second property guarantees that data has not been altered by an unauthorised entity. The third property guarantees the origin of data.

AB (K)(K)  m0  −−−−−−−−−→  pre-accept  . . phase    m  ←−−−−−−−−−i

sk ← KDF(K, m0, . . . , mi) ( post-accept {·}sk phase ⇐======⇒

Figure 1.2 – Pre-accept and post-accept phases in a key establishment protocol. In this example, the two parties share a symmetric key K.

A key establishment protocol can be divided into two phases: a pre-accept phase and a post- accept phase. From the viewpoint of one party, the pre-accept phase ends when that party deems to be actually communicating with its intended party, and that the session key can be safely used to exchange data. This session key is used during the post-accept phase to securely exchange data between the two parties (see Figure 1.2). ae,Kha,Shg n cwn JS1]hv rpsda lentv a ocpuethe capture to way alternative an proposed have [JKSS11] Schwenk and Schäge Kohlar, Jager, efudi odadMtui B0a,adas nMnzs a oshtadVanstone and Oorschot van Menezes, can in protocols also 12). exchange Chapter and in key [BM03a], (mostly Mathuria on [MVO96] and study Boyd comprehensive in and rather found ones, be A deployed widely including limitations. protocols, their symmetric highlight several review we section, this In Devices Constrained for Protocols Current 1.3 secrecy. forward also and [BWJM97], attacks impersonation such key-compromise properties CF12; to security LLM07; additional resistance Kra05; capturing as KOY03; the allow CK01; what models Sho; extend adversarial BCK98; or dierent These [BR94; limit (e.g., LSY+14]). that perform rules to the allowed by is dierentiated are adversary which devised been have models 1.3). Figure (see achieve to supposed is call itself they (that model key an security Establishment the up al.’s Channel that set et ensures Jager to property the is in second which precisely, the purpose More purpose, specic any a for for used suitable be is to is suitable property is rst key The of session guarantee. that to to supposed similar is authentication, protocol entity establishment Consequently, key a keys. such of indistinguishability properties value, on random based proved a from be key cannot session 1.2 MAC-ed the TLS which and distinguish of encrypted Finished) to security these way the (called Since trivial messages phase). a protect provide pre-accept to messages the protocol used (i.e., Finished (TLS) phase is Security exchange key Layer key Transport session the the use The nalise for the [DR08]. particular and in 1.2 phase true version exchange is key in This the Nonetheless, key. between tunnel. session separation secure the the clear case: of up no set the with to is phase protocols this pre-accept exist protocols, the establishment there during only key used several is In key used. session the and computed is key session the same the with random a at by drawn output size) key same session (of call the We value that distribution. a ensuring from at indistinguishable aims is property run second protocol The claimed. as is identity properties: security corresponding two involved into the translates authentication This authenticating entity key. goals: secret main fresh a two sharing ensuring and at parties, aim protocols establishment key Most Protocols Establishment Key of Goals 1.2.2 Devices Constrained for Protocols Current 1.3 h ait fscrt oesi o iie othe to limited not is models security of variety The when moment the necessarily not is phases post-accept the and pre-accept the separates What ACCE AKE iue1.3 Figure        uhniae e Establishment Key Authenticated and h anpoete fteAEadAC euiymodels security ACCE and AKE the of properties main The – or nitnusaiiyo keys of indistinguishability authentication entity hne security channel authentication entity e indistinguishability key ACCE ,tescn rprycrepnst httescr channel secure the what to corresponds property second the ), AKE = rtcl.Btisedo urneigta the that guaranteeing of instead But protocols. uhniiyo plaintexts/ciphertexts of authenticity ciphertexts of indistinguishability h rtpoet isa eiyn htan that verifying at aims property rst The . AE uhprotocols. such (AKE) uhniae n oeta channel condential and authenticated AKE and uhniae n Condential and Authenticated ACCE rpsl.Multiple proposals. 11 .

1 12 Chapter 1 Introduction

1.3.1 Overview of the Protocols Generic protocols. The AKEP1 and AKEP2 protocols described by Bellare and Rogaway [BR94] are two ecient lightweight AKE based on two static master keys. Hence they do not provide forward secrecy. In both protocols, authentication of the parties is achieved by sending a challenge (pseudo-random values rA, rB) from which the responder must compute a value with one of the master keys (K0). AKEP1 is a key transport protocol where the responder B generates and sends to the initiator A a session key sk. AKEP2 (see Figure 1.4) is a key agreement protocol where the session key (sk) is computed with the other master key (K) and a pseudo-random value chosen by B.

AB (K, K0)(K, K0)

r −−−−−−−−−→A

mB ← BkAkrAkrB 0 τB ← MAC(K , mB) m , τ ←−−−−−−−−−B B

mA ← AkrB 0 τA ← MAC(K , mA) m , τ −−−−−−−−−→A A

sk ← KDF(K, rB) sk ← KDF(K, rB)

Figure 1.4 – The AKEP2 protocol

Dousti and Jalili [DJ14] describe a key agreement protocol, called FORSAKES, where the two parties use of a shared master key (K), and exchange random values (rA, rB) to perform the mutual authentication, and to compute the session key (sk). In order to provide forward secrecy, the master key is periodically updated (using a one-way function H). Figure 1.5 depicts the protocol. The master key is updated regularly at each time interval. This implies a perfect time synchronisation between the parties. Indeed, rstly, all the operations involving both parties must be done in the same time interval. Otherwise, the parties may use dierent master keys, which forbids from computing a shared session key. For instance, if the time interval falls due after one party computes a MAC tag, and the other party veries it, then either party uses a dierent master key. Therefore the time interval must be large enough in order for the parties be able to complete a whole protocol run. Secondly, the duration of the time interval must exactly be equal to the duration of a protocol run. Otherwise, corrupting either parties once they have accepted (but before the master key update) allows retrieving the current master key used to compute the session key, hence breaking the forward secrecy. Achieving a perfect time synchronisation may be quite complex (or even not possible) in any context, in particular with constrained devices. We also observe that the security model chosen by Dousti and Jalili does not allow revealing the key ik (only sk) as this would allow to trivially win the security experiment based on indistinguishability of the session keys. The protocols described in the ISO/IEC 11770-2 standard [Int08] propose dierent lightweight with ae S oe(e iue18.Ti oeesnilyihrt rmta fTS12btwith key and but handshake messages 1.2 the the TLS particular authenticate of (in to that keys functions from multiple symmetric inherits derive dierent essentially and mode ow, This message 1.8). shorter Figure a (see mode PSK a rates transactions server. protect remote to a order and card in (EMV) TLS-PSK banking apply a to between proposed done has [Uri10] with Urien done are run. computation protocol key ( session key and master authentication depicts shared on mutual 1.7 the only case, Figure built that [ET05]. version In (PSK) a mode exists variant. key there this pre-shared but so-called (EC)DH), the and RSA functions: wit symmetric-key (to schemes asymmetric [Har14] on Hardjono based cryptography, symmetric on protocol. IoT based an is as it Kerberos use Since to security. proposes (between its clock impair synchronised not and secure to a implies protocol the by Furthermore, specied time validity the exceed initiator the by by received Then key. master from request server authentication the client a entities: networks. Computer secrecy. forward provide none But server). key (e.g., assistance party the require third other a parties, two of involve Some functions. symmetric-key on built schemes Devices Constrained for Protocols Current 1.3 lhuhTS13[e1]i o pcal eiae ocntanddvcs tas incorpo- also it devices, constrained to dedicated specically not is [Res18] 1.3 TLS Although is version standard The protocol. client-server popular a is [DR08] protocol 1.2 TLS The addition, In secrecy. forward ensure not does Kerberos keys, symmetric static on Based A A ihtessinkey session the with and iue1.5 Figure m k ik sk, m τ K B A B 0 A A A 0 ← A ← from (respectively ← ← salwdt es eea ie h aessinky(sln si osnot does it as long (as key session same the times several reuse to allowed is , A S H MAC ← A A A ( n server a and ed to sends A K h OSKSprotocol. FORSAKES The – k k easteecytdssinkyto key session encrypted the relays KDF B B nldsavldt time validity a includes ) ( ( K B A K k k k m ik, t t ( ) ( ebrsv NH0]i e rnpr rtclta nbe two enables that protocol transport key a is [NYHR05] v5 Kerberos ,adtoped-admvle ( values pseudo-random two and ), A A S ,r K, sk k k r r A K seFgr .) h atrsae itntsai ymti key symmetric static distinct a shares latter The 1.6). Figure (see A 0 nodrt eiyta h eso e sntexpired. not is key session the that verify to order in ) A A A ) A rs eso e epcieyecytdunder encrypted respectively key session fresh a k B k r and B r osaeassinkywt h epo rse hr party: third trusted a of help the with key session a share to , B ) S K ,wihicessteetn fassinkydisclosure. key session a of extent the increases which ), B −−−−−−−−−→ ←−−−−−−−−− −−−−−−−−−→ .Anwssinky( key session new A ). m m m ` A 0 B ecytdby (encrypted , , A τ t τ A A 0 B and hk t B B k ik sk, h nse key nished the , ihadtoa aa h message The data. additional with , orsodt timestamps. to correspond m r S B C τ n timestamp a and ) , sk ← ← B r S ← ssae sflos Upon follows. as shared is ) xhne hogotthe throughout exchanged ) B KDF k MAC K A ) K ( k ,r K, t B ← ( fk k m ik, k A r A H n h session the and , A k and ( k r K r t B B A B A ) ) ) B (encrypted sand ’s norder in ) B 13 ’s

1 14 Chapter 1 Introduction key sk, used to protect respectively key exchange messages, the so-called Finished messages, and the application messages). In TLS 1.3 each master key has a nite lifetime but the latter can be as high as seven days. Moreover, the dierent master keys can be encrypted by the server with the same symmetric key (called Session Ticket Encryption Key or STEK). Therefore the disclosure of a master key or its encryption key STEK breaks forward secrecy. The same holds regarding TLS 1.2.

ASB (KA)(KA, KB)(KB)

A, B, r −−−−−−−−−−−−−−−−−−→A

ticketB ENC(KA, skkrAk`kB) ←−−−−−−−−−−−−−−−−−− ticket , ENC(sk, Akt ) −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→B A ENC(sk, t ) ←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−A

Figure 1.6 – The Kerberos v5 protocol. ticketB corresponds to ENC(KB, skkAk`).

Smart cards. The SCP02 [Glo18] and SCP03 [Glo14] protocols are used to establish a secure channel between a server or reader and a remote smart card (e.g., UICC/SIM card). They are built on a single core function (respectively DES/3DES and AES). These protocols are widely used to manage the content of SIM cards (update of secret parameters, install of applets). Their security is also based on static symmetric keys. Although the static master keys can be updated (the new master keys are protected with session keys computed with the current master keys), this depends on the overall security policy of the service provider that deploys the cards, and is not part of the SCP02 and SCP03 protocols per se. In addition, the session keys output by these two protocols depend on a monotonically increasing counter respectively 15 and 24-bit long which limits the number of runs. Furthermore, only the server can initiate a protocol run. As we will see in Chapter 4, SCP02 enjoys more crippling features. Figure 1.9 depicts the key establishment phase in SCP02. The message ow in SCP03 is similar to that of SCP02. The main dierences are the symmetric functions used to compute the messages and the session keys, and the fact that the sequence counter in SCP03 is incremented at the beginning of a protocol run, whereas in SCP02, it is incremented after a successful run.

Radio identication (RFID). In the RFID eld, several protocols based on a shared master key propose to update the master key throughout the protocol run. For instance, Le, Burmester, and de Medeiros [LBM07] propose O-FRAKE that aims at authenticating a tag to a server, and at computing a session key in order to establish a secure channel (see Figure 1.10). Only the server can initiate a protocol run. In order to ensure forward security, the master key is updated throughout the protocol run. To deal with the possible desynchronisation between iue1.7 Figure Devices Constrained for Protocols Current 1.3 ms sk fin ← C ← – ← PRF PRF n A-dwt h eso e ( key session the the and with client MAC-ed the and by respectively notation, far the so Abusing received server. and sent ( messages client of the transcript by mode. proposed PSK suites in cipher protocol of 1.2 TLS in establishment key The PRF ( ( K ( S C s label ms, ,label K, ( ( ) s label ms, 1 2 k k r r 3 C ← − − − − − − − − − −− − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − → − − − − − − − − − − − − − − − − − − − − − − − → ← − − − − − − − − − − − − − − − − − − − − − − − C k k k H psk r r ( S S msg ) ) - identity C AE )) r C ( AE r , k fin sk, S cs AE , , eoe httea esgsaeencrypted are messages nal the that denotes - cs list sk ( k fin sk, ). fin S ) C S ). sk ← ms msg C ) ← PRF ← C PRF PRF ( and s label ms, ( s label ms, ( msg ,label K, cs - S K list 3 orsodt the to correspond k ) H 2 1 eoe h list the denotes ( k k msg r r C C k k r r S S S )) ) ) 15

1 16 Chapter 1 Introduction

CS (K)(K)

r , cs-list −−−−−−−−−−−−−−−−−−−−−−−→C

hk, fk ← KDF(K, rC , rS, msgS) finS ← HMAC(fk, H(msgS))

r , cs, AE(hk, fin ) ←−−−−−−−−−−−−−−−−−−−−−−−S S

hk, fk ← KDF(K, rC , rS, mgC ) finC ← HMAC(fk, H(msgC ))

AE(hk, fin ) −−−−−−−−−−−−−−−−−−−−−−−→C

0 0 sk ← KDF(K, rC , rS, msgC ) sk ← KDF(K, rC , rS, msgS)

Figure 1.8 – The key establishment in TLS 1.3 protocol in PSK mode. KDF denotes the computation through intermediary steps of several keys (hk, fk, sk) with the pre-shared key K, and the HKDF function [KE10]. The underlying hash function for HMAC 0 0 and HKDF depends on the chosen ciphersuite cs. msgC , msgC and msgS, msgS correspond to the transcript of messages received and computed so far respectively by the client (C) and the server (S). iue1.9 Figure Devices Constrained for Protocols Current 1.3 auth Kenc Kcmac cnt – ← r ae on The based protocol. are SCP02 in establishment key The C ← cnt ← ( ← K KDF MAC1 S C , 1 + KDF K 0 ( ( ) ,cnt K, ( ( K DES ,r K, 0 cnt , S ) and k ← − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − → ← − − − − − − − − − − − − − − − − − − cnt ) 3DES sec k r psk cnt C - ) level . - , identity r τ C S , , auth ← auth MAC2 , auth S C r , S τ S S ( ca,sec Kcmac, Kcmac ← KDF Kenc MAC1 , MAC1 ← ← ( ,r K, K - KDF level KDF and , , K C ( k 0 ) k ( K cnt ,cnt K, MAC2 auth 0 cnt , k r S S ) ) ) ) functions 17

1 18 Chapter 1 Introduction the reader and the tag, the server keeps two consecutive values of the key: the current and the previous one. The server is always at most one step ahead of the tag. Therefore, if the tag does not update its master key, the server is able to catch up. But this implies that, in case of desynchronisation, the server computes the session key from the updated master key, whereas the tag still stores the previous value. Hence, an adversary that corrupts that tag can compute the previous session key with respect to the server (i.e., the adversary breaks the forward secrecy). In fact, since the server always keeps the previous value of the master key, together with the current one, the scheme is intrinsically insecure in strong security models (i.e., models that allow the adversary to corrupt any of the partners, once the targeted party has accepted).

CS (K)(K, K−1)

r ←−−−−−−−−−S

v1, v2, v3, v4, v5 ← PRF(K, rC krS) τC ← v2

r , τ −−−−−−−−−→C C

v1, v2, v3, v4, v5 ← PRF(K, rC krS) τS ← v3

τ ←−−−−−−−−−S

rC ← v1 K−1 ← K K ← v4 K ← v4 sk ← v5 sk ← v5

Figure 1.10 – The O-FRAKE protocol. Once the server (S) sends τS, the master key K is updated. The server keeps the previous master key K−1, in case the tag (C) does not receive τS, and does not update its own version of the master key.

Wireless sensor networks (WSN). The area of WSN requires also lightweight, ecient AKE protocols, and has been subject to numerous proposals. One can cite in particular the following ones. Perrig, Szewczyk, Tygar, Wen and Culler [PST+02] propose the SPINS protocol, based on one encryption function. This protocol implies a central server. This server generates and sends a fresh session key to pairwise sensors, encrypted with each sensor’s master key, which is static and set before the sensors are deployed on the eld (see Figure 1.11). SPINS includes a procedure to broadcast authenticated messages. The rst key k0 is transmitted to each node authenticated with the node’s master key. Each subsequent authentication key belongs to a one-way chain: ki = H(ki+1), i ≥ 0. The broadcast procedure is the following. At time ti, each node knowns key ki. At time ti+1, the server broadcasts a message mi+1 MAC-ed with key ki+1. Then, at time ti+1 + ∆ < ti+2, the server discloses ki+1. Each node can verify that hc hrsadrn atrkywt ahsno.Teiiilssinkyi ett each to sent is key session initial The sensor. each with key master dierent a shares which ai esgswt key with messages valid h e ncert h onn eie ec asvl aedopn nti hs senough is phase network. this ZigBee on sends eavesdropping a merely passively of [Zig14] Hence security ZigBee the device. in undermine joining device to the master to the key, clear master in a key share the to order In keys. master home. Smart key session new avoid a to initiate also to but server update the key by session sent the messages trigger chain). the to to particular order used (in between in is messages clock server key of synchronised central master replay (loosely) the the a and and implies chain, nodes protocol hash the The the all chain. of new length a the initialise by limited periodically is update key session of if the SPINS, checks one: function in it next one-way as the a because, of with deleted image computed the be chain as not a must (with to key encrypted belong master is keys The key session session one. previous subsequent the each with and key, MAC) master no static its with encrypted sensor compute can attacker an otherwise nodes, the all and server the between clock synchronised k Devices Constrained for Protocols Current 1.3 i ntesm ed akadSi rps iP[S4.I sas ae nacnrlserver central a on based also is It [PS04]. LiSP propose Shin and Park eld, same the In = K K K K H AS AS SA SA e a e a ( k ( ← ← ← ← K i +1 B S A A − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − → ← − − − − − − − − − − − − − − − − − − − − − − − k MAC MAC MAC MAC ) ( ) i n cetmessage accept and , +1 eadn h rao h mr oe eea rtcl aeueo static of use make protocols several home, smart the of area the Regarding sapeiaeof pre-image a is ( ( ( ( K K K K iue1.11 Figure A A A A , , , , 1) 2) 3) 4) k c i A +1 , τ k lhuhtekyi expired. is key the although A i h e salsmn nSISprotocol SPINS in establishment key The – τ τ = B A m k H ← ← c i c i n hnreplaces then and , ( B A +1 k MAC MAC i ← ← +1 Key . sk ) ENC ENC K hnasno receives sensor a When . ( ( r ← A K K k A , i SB SA , a a ( ( K +1 PRG K K A B ← − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − → r , r , SA SB e e xie ttime at expires ( ) A B sk , sk , k k B A k ) k k ) τ c i c A B A B 0 with , ) ) B ← c , B r MAC k A , t i τ +1 i , +2 B r H K K K K k B hrfr,tenumber the Therefore, . ( hspooo mle a implies protocol This . ahkyi computed is key Each . i BS BS SB SB K , e a e a +1 τ BS a B 0 ecytdwith (encrypted ← ← ← ← r , MAC MAC MAC MAC A k r K B ( ( ( ( B k K K K K A ) B B B B k , , , , B 1) 2) 3) 4) ) k 19 i ),

1 20 Chapter 1 Introduction

The WPA2 protocol [IEE04] used in WiFi communications is a client-server type protocol based on a shared static master key. From two 48-bit nonces (rC , rS) exchanged by the client and the server, several session keys are derived (see Figure 1.12). They are used to protect subsequent handshake messages (ek, ak), and application data (sk). WPA2 has been subject to several attacks by Vanhoef and Piessens [VP17; VP18] that allows replaying and decrypting encrypted messages, based on the ability to compel a device to reuse a session key whereas encryption is done in CTR mode. In Z-Wave S0 [Sil18] the master key is sent encrypted with a known (all zero) key. Hence eavesdropping on the key exchange phase undermines the security of the network. In Z-Wave S2 [Sig16] a static variant of the scheme ECDH scheme is used. Whereas the master device generates a fresh ECDH share, the joining device uses always the same share. The latter is printed on the joining device in the form of a QR code, or an hexadecimal string. Authentication is done by comparing the ECDH share received by the master device and the value printed on the joining device’s sticker. The secret key output by the ECDH exchange encrypts the master key (known also to all other devices members of the same Z-Wave network), and the ciphertext is sent to the joining device. Eventually, this master key is used to protect the messages exchanged between the devices. We observe that the authentication of the joining device relies upon the integrity of its sticker. If an attacker succeeds in replacing the sticker with one of her choice (corresponding to an ECDH public value chosen by her), then she can make a proper ECDH key exchange with the master device, and consequently receive the network’s master key. The legitimate user deems the authentication is valid since the received ECDH value is equal to the (fake) sticker on the joining device. Even if the legitimate user repeats the pairing procedure with his new device (which was unable to receive the master key during the Man-in-the-Middle attack), the same master key is sent to the latter. Hence, this scenario allows the attacker to decrypt all subsequent application messages exchanged between the legitimate devices, and to transmit valid messages. As one can see, on the one end, Z-Wave S2 tries to enhance the security through asymmetric cryptography, but, on the other hand, the protocol does not make use of all the properties enabled by the public key schemes due to the constrained resources of the Z-Wave devices (i.e., use of a static ECDH share, no forward secrecy, no proper entity authentication). Tierney [Tie18] has also shown how to compel a Z-Wave device to downgrade from version S2 to S0, which impairs the security.

Mobile telephony. In mobile telephony, the Universal Mobile Telecommunications System (UMTS)[3rda] and Long Term Evolution (LTE) [3rdb] system are based on static master keys shared between the user’s SIM card and a back-end server. From these static master keys (and random values exchanged throughout the protocol run), all the session keys are computed. The number of sessions is bounded by a 48-bit counter.

Controller area networks (CAN). In the eld of the automotive security, several protocols have been proposed based on symmetric-key functions (e.g., [VHSV11; GMVV12; BSNRN14; NR16; VBMP17]). They aim at authenticating the messages exchanged by vehicle control units in order to command sensitive elements of the vehicle (e.g., brake, steering). For instance, among the latest proposals, Radu and Garcia [RG16] describe LeiA where each session key is computed from the shared, static master key, and a (synchronised) counter. Rather than an interactive key agreement protocol, LeiA includes an extra procedure in order for the parties to resynchronise if needed. iue1.12 Figure Devices Constrained for Protocols Current 1.3 τ cnt τ k k sk ak, ek, C C 0 ← ← – ← atrkey master protocol. WPA2 in establishment key The MAC MAC cnt ( ← K S C 2 + ( ( k cnt ak, k cnt ak, ( ) PRF K ( ,r K, . k 1) + gk r C C ) sagopkysn yteserver. the by sent key group a is k ← − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − → − − − − − − − − − − − − − − − − → ← − − − − − − − − − − − − − − − − r S cnt ) cnt , psk cnt cnt 1 + , - 1 + , identity r r C S , , , τ τ c C τ C 0 S S , τ ← , S k k sk ak, ek, r S MAC cnt sagoa one eae othe to related counter global a is ( ak, ← c S ( cnt PRF ← cnt 1) + K ENC ( ← ) ,r K, k ( cnt k gk ek, r C S k k 2 + r c S S ) ) ) 21

1 22 Chapter 1 Introduction

Internet of Things. Regarding the IoT eld, the following protocols are widely deployed or strongly promoted. They all build their security on symmetric-key functions, and make use of a static and unique (per end-device) root key shared between the end-device and the back-end network. Sigfox [Sig17b; Sig17a] is a communication and security protocol dedicated to long-range, low-power devices (LPWAN). Each end-device connects to a central server. The data is protected with the same static symmetric keys, used during the whole end-device’s lifespan (Sigfox proposes no key exchange procedure). LoRaWAN 1.0 [LoR18a] and 1.1 [Sor17] are two versions of a protocol that aims at securing the communication between end-devices with low computational and energy resources (e.g., sensor, actuator) and a back-end server. The session keys are derived from the end-device’s root keys. As all the aforementioned protocols, these do not provide forward secrecy. In addition, due to the short size of the parameters (pseudo-random values or counters), the number of protocol runs is bounded. Furthermore, only the end-device (but not the central server) can initiate a session. In Chapter 3, we look in depth at these protocols and show that they suer from several weaknesses that lead to likely practical attacks. Contrary to the previous technologies, Narrowband IoT (NB-IoT), enhanced Machine-Type Communication (eMTC), Extended Coverage GSM IoT (EC-GSM-IoT) are cellular technologies. eMTC provides enhancements to the Long Term Evolution (LTE/4G) technology for machine type communications. NB-IoT is also based on LTE, whereas EC-GSM-IoT is based on GSM/EDGE technologies and dedicated to constrained end-devices. These technologies aims at decreasing the end-device complexity (hence its cost), power consumption, extending autonomy, and increasing coverage [GSM16]. The security of all these systems relies on the underlying technology (GSM, EDGE, LTE), hence on a static symmetric root key known to a central authority, likely the telecom operator. They inherit the intrinsic security limitations of the symmetric-key schemes they are built on.

1.3.2 The Importance of Being Proved

Despite the great value of the paradigm of provable security, only a few of the protocols described in Section 1.3.1 have been formally proved. Furthermore, the security models used do not grant the adversary the same powers, hence the resulting proof are not equally meaningful. Thus, in their proof for UMTS and LTE, Alt et al. [AFM+16] do not allow any server corruption. Furthermore, they allow the adversary to get either one or the other, but not both master keys needed to compute the session keys. Radu and Garcia [RG16] prove their protocol secure in the Dolev-Yao model [DY81]. They do not allow any party corruption, and their protocol does not provide forward secrecy either. In the security model of Dousti and Jalili [DJ14], the adversary has access to queries that allow registering new parties, sending data to some party, corrupting a party, and getting the session state (which includes the session keys, and public values such as the session identier – exchanged in clear throughout the protocol run –, the partner identier, the party’s role, and the time when the session is initiated). More signicantly, Dousti and Jalili dene security based on the session key indistinguishability, but do not consider entity authentication. In addition, their notion of “freshness” (used to dene the characteristics of the security experiment) demands that the targeted party have an actual partner (rather than demanding only that the targeted party accept with some intended partner). Furthermore, corruption of the targeted party or its intended partner is not allowed before both have computed the session keys, in contrast to stronger models where the adversary can corrupt either of these two parties as soon as the ed osdra“tog euiymdlt sesi htpoet side rvddb the by provided indeed is property that if assess to model security “strong” a consider do we sasmay al . oprstepooospeetdi eto .. ihrsetto respect with 1.3.1 Section in presented protocols the compares 1.2 Table summary, a As cnrtl,w osdra desr htcncruttetree at n t intended its and party targeted the corrupt can that adversary an consider we (concretely, a a such issues experiment, adversary (the their in that, observe We intervals. time regular at made is update The aus ec u hieof choice our Hence values. losvrulya niie ubro runs. of number unlimited an virtually allows protocols accepts). the party compare targeted to the criterion as same soon as the partner use the we to Hence regards in meet. importance to paramount want of we is level secrecy security forward Indeed, protocol. considered interworking channel. – possible secure Communication the (post-accept) Mobile the exploit for target System or or Global al., GSM), and et UMTS Alt (e.g., of technologies stronger that dierent on than between based adversary either are the [MW04; attacks to (e.g., These granted UMTS RKHP19]). powers against HC14; attacks [TM12; (e.g., exist LTE there and LTE, ASS09]) and ZF05; UMTS of protocol algorithms. establishment integrity key and condentiality underlying the of proof security a provided have attacks. and proof WPA2. security and a cross-mark both a dierent of by to existence followed correspond check-mark the A may indicates proof models. security each ( and that cross-mark symbolic), Note (computational, a settings protocol. follow the references against if attacks contrary, to the correspond On reference. corresponding the by criteria. signicant several Summary Selective 1.3.3 interactions. capture of also complexity must this from model result security that their Hence, operations of interleaved some parties. Moreover, the two models. than threat more strong involve against protocols analysis these cryptographic careful a accepted. require have they parties both once only possible is tag the of corruption keys). session the experiment recomputes security and the updated, win is limit trivially key time can the adversary if particular, the In then run. session, protocol a a of of duration duration the the to exceeds relation in dened them). not with is interacting duration the by (hence parties partners the intended desynchronise two to a the attempting and at from synchronisation, keys forbidden time master is the perfect adversary of a update assumed automatic is and it simultaneous important, More accepts. party targeted Devices Constrained for Protocols Current 1.3 eadn P2[E0] h eso escmuaini ae ntwo on based is computation keys session the [IEE04], WPA2 Regarding “#ses”. “#msg”. “PFS”. the on [AFM+16] Richard and Onete Macario-Rat, Fouque, Alt, [ST16] by Traoré provided and proof Sabt the protocol, Despite the for proof security a of lack the despite SCP03, Regarding “Security”. devices, constrained and on allowed, functional not fully is being at server aim the protocols corrupting these that [LBM07], fact the al. Despite et Le Van by used model the In 2 ed o li opoiea xasiels freferences. of list exhaustive an provide to claim not do We tidctsi h rtclgaate owr erc.W testa,i htcase, that in that, stress We secrecy. forward guarantees protocol the if indicates It tgvstenme fpsil esos h ybl“ symbol The sessions. possible of number the gives It tgvstenme fmsae xhne uigacretpooo run. protocol correct a during exchanged messages of number the gives It hc-ak( check-mark A Corrupt √ 2 qeyatrtessinky r optdbtbfr h master the before but computed are keys session the after -query 96 niae h xsec fascrt ro,adi followed is and proof, security a of existence the indicates ) o h ubro esosbfr h eso esrpa (in repeat keys session the before sessions of number the for 2 hsi h aefrUT,LTE, UMTS, for case the is This ∞ niae htteprotocol the that indicates ” 48 btpseudo-random -bit ,they ), 23

1 24 Chapter 1 Introduction presence of a passive adversary). Likewise, despite the fact that LoRaWAN 1.0 [LoR18a] does√ not limit the number of sessions, collisions occur on the session keys with high probability after 240 key exchanges (in presence of a passive adversary). Regarding LoRaWAN 1.1 [Sor17], the parameter j is implementation-dependent.3

“I/R”. It indicates if any (type of) party can be initiator or responder of a session. A check- mark denotes the armative whereas a cross-mark denotes the opposite. For instance, AKEP1 allows any party to initiate a session. On the contrary, only the server can initiate an SCP02 session (and only a smart card can respond to it).

“P2P”. It indicates if the key establishment is point-to-point between the two intended partners. A cross-mark denotes that a third party (e.g., key server) is required.

“Sync”. It indicates if an extra procedure or functionality (in addition to the key establishment procedure) is needed in order for the parties to guarantee some form of synchronisation. A “yes” answer implies a supplementary burden (e.g., in terms of computation, implementation surface, energy).

3According to us, it is likely that j = 1, as explained in Chapter 3. al 1.2 Table . urn rtcl o osrie Devices Constrained for Protocols Current 1.3 oaA 1.1 LoRaWAN 1.0 LoRaWAN L . PSK 1.3 TLS PSK 1.2 TLS ebrsv5 Kerberos FORSAKES -aeS2 Z-Wave S0 Z-Wave [NYHR05] O-FRAKE [PST+02] [LoR18a] [LBM07] Protocol ISO/IEC 11770-2 AKEP1, [Glo14] [Glo18] [Res18] [IEE04] [Zig14] [Sor17] [RG16] [Sig16] AKEP2 ZigBee [BR94] [Int08] [ET05] [PS04] [DJ14] [Sil18] SCP03 SCP02 WPA2 UMTS [3rdb] SPINS [3rda] LeiA LiSP LTE – oprsno eea e xhnepooos(l u n)i h symmetric-key the in one) but (all protocols exchange key several of Comparison setting CH1][DFK+17] [CHH+17] AM1][MW04] [AFM+16] AM1][TM12] [AFM+16] H1][RKHP19] [HC14] HD0][VP16] [HSD+05] P1][ABF+19] [PS18] BJ0][BK07] [BCJ+06] C0][CH14] [CM08] Z0][ASS09] [ZF05] C0][MS08] [CC04] V1][VP18] [VP17] eto 1.3.1 Section hpe 5 Chapter 3 Chapter 4 Chapter [LSY+14] [BJST08] [LBM07] Security [Tie18] [RG16] [BR94] [ST16] [ST16] PFS 2 2 #msg ≥ 1-5 16 × × 3 3 4 4 3 3 2 0 8 4 4 1 4 3 3 4 7 7 min( prmaster (per prmaster (per < < j key) key) #ses 2 2 2 2 2 2 ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ 15 56 48 48 24 2 2 16 20 48 , 2 24 ) I/R mc.7-13) (mech. mc.1-6) (mech. P2P Sync yes yes yes yes yes yes no no no no no no no no no no no no no no 25

1 26 Chapter 1 Introduction

1.4 Contributions of this Thesis

Our contributions are threefold:

• We analyse existing symmetric-key protocols (including widely deployed ones) and show that they suer from weaknesses that allow implementing likely practical attacks. As a concrete demonstration we provide the results of a successful attack done in an experimental setting against smart cards implementing one of the analysed protocols.

• We devise suitable security models that we subsequently use to analyse two symmetric- key protocols, including one that we have conceived.

• We present two- and three-party authenticated key exchange protocols in the symmetric- key setting that provide stronger security properties than the existing protocols. The additional properties and functionality that we obtain include the essential forward secrecy property, and session resumption. The latter functionality is particularly advantageous for low-resource end-devices with constrained capabilities in terms of communication and computation.

The papers accepted in conferences (and, for most of them, already presented) during this thesis are the following:

[ACF19] Gildas Avoine, Sébastien Canard, and Loïc Ferreira. IoT-Friendly AKE: Forward Se- crecy and Session Resumption Meet Symmetric-Key Cryptography. In: ESORICS 2019, Part II. Ed. by Kazue Sako, Steve Schneider, and Peter Y. A. Ryan. Vol. 11736. LNCS. Springer, Heidelberg, Sept. 2019, pp. 463–483. [ACF20] G. Avoine, S. Canard, and L. Ferreira. Symmetric-key Authenticated Key Exchange (SAKE) with Perfect Forward Secrecy. In: CT-RSA. (To appear). 2020. [AF18a] Gildas Avoine and Loïc Ferreira. “Attacking GlobalPlatform SCP02-compliant Smart Cards Using a Padding Oracle Attack”. In: IACR TCHES 2018.2 (2018). https : / / tches . iacr . org / index . php / TCHES / article / view / 878, pp. 149–170. issn: 2569-2925. [AF18b] Gildas Avoine and Loïc Ferreira. Rescuing LoRaWAN 1.0. In: FC 2018. Ed. by Sarah Meiklejohn and Kazue Sako. Vol. 10957. LNCS. Springer, Heidelberg, 2018, pp. 253–271. [CF19] Sébastien Canard and Loïc Ferreira. Extended 3-Party ACCE and Application to LoRaWAN 1.1. In: AFRICACRYPT 19. Ed. by Johannes Buchmann, Abderrahmane Nitaj, and Tajjeeddine Rachidi. Vol. 11627. LNCS. Springer, Heidelberg, July 2019, pp. 21–38.

1.4.1 Cryptographic Analysis of Existing Protocols [AF18b; AF18a; CF19]

As mentioned in Section 1.1, existing symmetric-key protocols do not provide as strong security properties as protocols based on asymmetric schemes. We enlighten this fact through the analysis of two protocols currently deployed worldwide, and implemented in a numerous amount of devices. ekess eitouesvrlatcs nldn ieypatcloe,ta rahthe breach that ones, practical likely including attacks, several introduce We weaknesses. CE,21)adArccyt(09.Te r ealdi hpes3ad4. and 3 Chapters in detailed are They (2019). Africacrypt and 2018) (CHES, data. sensitive transmit securely to world banking the in and cards), (UICC/SIM iyo -at uhniae e xhnepooos( protocols exchange key authenticated 3-party of rity model. devised. security have 3-AKE we The that one which among protocols, subsequently two are of that security models security the two analyse dene to we approach, applied security provable a use to order In ACF19] [CF19; Models Security of Design 1.4.2 Systems Embedded and Hardware Cryptographic 2018), (FC, Security Data and Cryptography being to 2018). prior March work and our 2017 of October details (between technical conference the the received manu- at have the presented cards Moreover, smart protocol. tested SCP02 the the of deprecate facturers to decided has this GlobalPlatform knowledge, submission, our of protocol. best SCP02 the the To against setting. attack experimental successful our rst in the practical is fully is attack the experiments our that of results the present have we with we and Furthermore, done setting, experimental channel. an secure in the attack within the implemented protected data retrieve eciently operators to allows network mobile companies, transport by deployed is protocol this cards, smart SCP02. of Analysis analysis. our version by subsequent yielded the suggestions and some [LoR18b], to also changes published incorporates recommending been 1.1 document LoRaWAN has A 1.0 LoRaWAN [AF18b]. in paper implemented our in be described attacks the of informed to order in recommendations present and version, aws. latest these this mitigate aect still that weaknesses the several keeping and specication, the equipment. with unmodied compliant and being patched time between same thwarting interoperability the at at aiming while recommendations practical attacks, physically to propose the used targeted we means the Finally the from to parameters. independent access secret are physical and potential protect settings), a on attack entail lean the not of not one do do (for they attacks equipment Likewise these protocol, bugs. the hardware of or weaknesses attack implementation inner dierent the two on present Based and condentiality, scenarios. data and integrity, data availability, network deliver that networks of energy). management water, to (e.g., up various and resources assets, surveillance sensitive provide valuable site to of activation, intended device geolocation remote are detection, measurement, intrusion objects telemetry These from services network. of between back-end types communications a securing and at objects aims (LPWAN) connected networks area wide low-power range, LoRaWAN. of Analysis Thesis this of Contributions 1.4 hs eut aebe rsne ntefloigitrainlcneecs Financial conferences: international following the in presented been have results These under was [AF18a] paper our While analysis. our of informed been has GlobalPlatform attack This protocol. SCP02 the against attack oracle padding a perform to how show We been has specication, LoRaWAN the promoting and developing of charge in Alliance, LoRa describe We version. previous the impair that aws the correcting at aims 1.1 version The several from suers it that show and protocol, the of analysis extensive an provide We 10 oeso mr ad rdcdb i ieetcr auatrr.Ti shows This manufacturers. card dierent six by produced cards smart of models h eodscrt rtcli C0.Ipeetdi atclrin particular in Implemented SCP02. is protocol security second The h rtpooo sLRWN hsITpooo eiae olong- to dedicated protocol IoT This LoRaWAN. is protocol rst The h rtmdl htw call we that model, rst The AKE .Ti oe atrsi particular in captures model This ). 3-AKE isa nlsn h secu- the analysing at aims , 27

1 28 Chapter 1 Introduction the forward secrecy property. In Chapter 7, we present a generic 3-party AKE and, based on it, a concrete instantiation, both in the symmetric-key setting. We use the 3-AKE model to formally prove the security of these two schemes.

The 3-ACCE security model. The second security model is based on the ACCE paradigm devised by Jager, Kohlar, Schäge and Schwenk [JKSS11] to cope with the diculty in proving the security of a protocol based on the indistinguishability of the session keys, when the latter are used during the key exchange phase. Our model allows analysing 3-party protocols which goal is to set up secure channels, hence its name 3-ACCE. First, we use this framework to prove the security of a generic LoRaWAN-like protocol. Then we present an adapted version of LoRaWAN 1.1 with stronger security properties, modied in order to mitigate the vulnerabilities described in Chapter 3. Applying the rst result, we formally prove the security of this protocol in our model, and describe how to concretely instantiate it.

These results have been presented during the following international conferences: Africacrypt (2019) and European Symposium on Research in Computer Security (ESORICS, 2019). They are described in greater detail in Chapter 5.

1.4.3 Design of Forward Secret Symmetric-key Protocols [ACF20; ACF19]

As witnessed by the protocols described in Section 1.3, achieving both eciency and security is a non-trivial task. Contrary to all the aforementioned protocols, we aim at describing lightweight protocols that are simple to deploy, and do not require complex practical requirements (e.g., time synchronisation between principals). Consequently, we propose two authenticated key exchange protocols that are built on symmetric-key functions solely, and ensure forward secrecy. These protocols do not make trade-o between eciency and security, and are analysed in a strong security model.

The SAKE protocol. First, we describe a two-party symmetric-key protocol that we call SAKE. Based on a shrewd synchronisation mechanism and a key evolving scheme, the protocol ensures forward secrecy.

The 3-AKE protocol. Then, we describe a generic 3-party authenticated key exchange protocol dedicated to IoT, that we call 3-AKE. It involves a (wireless) end-device, a server, and a trusted third party used as authentication and key server. Solely based on symmetric-key functions (regarding the computations done between the end-device and the back-end network), this protocol guarantees also forward secrecy. In addition, it enables session resumption without impairing security (in particular, forward secrecy is maintained). This allows saving communication and computation cost, and is advantageous for low-resource end-devices. We present a concrete instantiation of the 3-AKE protocol based on the two-party protocol SAKE. The 3-party key exchange protocol can be applied in a real-case IoT deployment (i.e., involving numerous end-devices and servers) such that the latter inherits from the security properties of the protocol. This results in the ability for a (mobile) end-device to securely switch from one server to another back and forth at a reduced (communication and computation) cost, without compromising the sessions established with other servers. euiy(SRC,21) hyaedtie nCatr n 7. and 6 Chapters in detailed are They 2019). (ESORICS, Security Thesis this of Contributions 1.4 hs eut aebe rsne tteErpa ypsu nRsac nComputer in Research on Symposium European the at presented been have results These 29

Contents I rlmnre n Denitions and Preliminaries edi re oeaoaemr ope ehnss n ofral nls h security the analyse formally chapters. to subsequent and the mechanisms, in complex protocols more of elaborate to order in need chapter this n . Notation 2.1 . euiyModels Security 2.3 Preliminaries 2.2 .. CEScrt Model Security ACCE 2.3.2 .. K euiyModel Security AKE 2.3.1 Encryption Authenticated Stateful Code Authentication 2.2.5 Message Permutation 2.2.4 Pseudo-random Function 2.2.3 Pseudo-random Conversations 2.2.2 Matching 2.2.1 epeettebsccytgahcdiin n uligbok we blocks building and denitions cryptographic basic the present we ...... 2 35 32 32 38 36 33 33 32 32 34

2 32 Chapter 2 Preliminaries and Denitions

2.1 Notation 7F A byte (equal to the hexadecimal value 0x7F) 00i Byte string made of i times the byte 00 var (4) A variable var which is 4-byte long |x| Absolute value of x xky Concatenation of bytes or string of bytes x and y bi|bi+1 Concatenation of bits bi and bi+1 $ x ←− E Value x chosen uniformly at random in the set E y ← F (x) Variable y to which the value F (x) is attributed {0, 1}∗ Set of all binary strings {0, 1}n Set of all n-bit strings ENC−1 Inverse function of function ENC Pr[A] Probability of event A

2.2 Preliminaries

In this section, we recall the denitions of the main security notions we use in Chapters 5, 6 and 7. The security denition of a pseudo-random function and pseudo-random permutation is taken from Bellare, Desai, Jokipii, and Rogaway [BDJR97], and that of a MAC strongly unforgeable under chosen-message attacks from Bellare and Namprempre [BN08]. We take the denition of a stateful authenticated encryption scheme (sAE) from Bellare, Kohno and Namprempre [BKN02] using the notation of Krawczyk, Paterson and Wee [KPW13]. We recall also the denition of matching conversations initially proposed by Bellare and Rogaway [BR94], and modied by Jager, Kohlar, Schäge, and Schwenk [JKSS11].

2.2.1 Matching Conversations s Let Ti,s be the sequence of all (valid) messages sent and received by an instance πi in chronological order. Let `(Ti,s) be the number of messages in Ti,s. For two transcripts Ti,s and Tj,t, we say that Ti,s is a prex of Tj,t if `(Ti,s) ≥ 1, and the messages in Ti,s are identical to the rst `(Ti,s) messages of Tj,t.

s t Denition 2.1 (Matching Conversations). We say that πi has a matching conversation to πj, if

s • πi has sent all protocol messages and Tj,t is a prex of Ti,s, or

t • πj has sent all protocol messages and Ti,s = Tj,t.

Remark. Dening matching conversations as per Denition 2.1 means that we use a post- specied session identier equal to the rst but not necessarily all messages of the protocol analysed. As explained by Jager et al., this asymmetry is necessary, due to the fact that protocol messages are sent sequentially. Therefore one of the two parties has to accept without knowing if the other party has received all messages. Indeed an adversary is always able to drop the last message in a protocol run.

2.2.2 Pseudo-random Function Let k be the security parameter. A pseudo-random function (PRF) F is a deterministic algorithm which given a key K ∈ {0, 1}k and a bit string x ∈ {0, 1}∗ outputs a string y = F (K, x) ∈ A A Tag Tag Tag h desr’ datg sde as dened is advantage adversary’s The h desr’ datg sde as dened is advantage adversary’s The τ { Code Authentication Message 2.2.4 adv (PRP) permutation pseudo-random cure 2.3 Denition adversary an and on y { Permutation Pseudo-random 2.2.3 in function negligible a is (PRF) function pseudo-random 2.2 Denition adversary an and challenger range and { Preliminaries 2.2 0 0 0 savldtgo message on tag valid a is = esg uhniaincode authentication message suorno permutation pseudo-random , , , { Fnly h desr upt t guess its outputs adversary the Finally, 3. Tecalne samples challenger The 1. 2. Fnly h desr upt t guess its outputs adversary the Finally, 3. 2. 1. 1 1 1 F prp . . . 0 Vrf Gen Vrf F } } } , ∗ k γ ahqeywt either with query values each query adaptively may adversary The samples challenger The ahqeywt either with query values each query adaptively may adversary The ( ( 1 n eun tag a returns and , where , A ,x K, (with } ) ae sipttekey the input as takes () h rbblsi algorithm probabilistic The . γ ) h euiyo R sde ihtefloigeprmn ewe challenger a between experiment following the with dened is PRP a of security The . h algorithm The . { sangiil ucinin function negligible a is 0 ) , { ∈ γ 1 } en oyoilin polynomial being Scr PRF) (Secure k Scr PRP) (Secure γ 0 A h euiyo R sde ihtefloigeprmn ewe a between experiment following the with dened is PRF a of security The . stescrt aaee,adabtstring bit a and parameter, security the is , 1 : } γ (with τ k . { ∈ m Tag . A . γ y y K ihrsetto respect with K MC ossso he algorithms three of consists (MAC) function A K 0 : (PRP) function A en oyoilin polynomial being . = = adv adv , MAC f o l rbblsi oyoiltm adversary time polynomial probabilistic all for if, message a , 1 ←− { ←− { $ F F $ } F prp F prf γ ( ( k k ,x K, ,x K, (with F 0 . 0 ( ( .Let ). ae siptakey a input as takes , A A , Tag 1 1 sadtriitcagrtmwihgvnakey a given which algorithm deterministic a is = ) = ) } } F ) ) f o l rbblsi oyoiltm adversary time polynomial probabilistic all for if, k k F γ . if if , : , unc F Gen G : m { G en oyoilin polynomial being

b b Pr[ b b Pr[ K 0 { n addt tag candidate a and , 0 0 1 = 1 = ←− , 0 ←− $ tews,i returns it Otherwise, . { ∈ { ∈ 1 $ ape key a samples , b b } 1 x x etesto l ucin fdomain of functions all of set the be unc F erm P k = or , or , = } k 0 0 otecalne.Tecalne ele to replies challenger The challenger. the to otecalne.Tecalne ele to replies challenger The challenger. the to k { × , , .Let ). b b { × 1 1 0 0 y y ] ] } } 0 and , − − = = , of of , 0 b 1 erm P 1 2 , 1 2 G G } K b b ←− { 1

$ . . ∗ ( ( } b . . x x { → γ { ∈ ←− { x K ) ) $ 0 k { → if if , Tag etesto l permutations all of set the be { ∈ .Tevrainalgorithm verication The ). rmteset the from 1 0 0 b b 0 τ } , , , 0 = 0 = 1 1 nfrl trandom. at uniformly for 0 1 ( = 0 } } false , } , k γ 1 1 . . nfrl trandom. at uniformly m } n message a and ssi ob a be to said is Tag } γ γ toutputs It . ssi ob a be to said is upt string a outputs . . Gen { 0 A , , , 1 Tag adv } k true : { . secure F prf MAC 0 K K m , ( 1 A se- A ← } 33 ∈ ∈ if ∗ , ) ,

2 34 Chapter 2 Preliminaries and Denitions

We require that a MAC be correct. That is, for all K ∈ {0, 1}k and for all m ∈ {0, 1}∗, we have that Tag.Vrf(K, m, Tag.MAC(K, m)) = true. The notion of strong unforgeability under chosen-message attacks (SUF-CMA) for a MAC Tag = (Tag.Gen, Tag.MAC, Tag.Vrf) is dened with the following experiment between a challenger and an adversary A:

1. The challenger samples K ← Tag.Gen(), and sets S ← ∅.

2. The adversary may adaptively query values m to the challenger. The challenger replies to each query with τ = Tag.MAC(K, m) and records (m, τ): S ← S ∪ {(m, τ)}. In addition, the adversary may adaptively query values (m0, τ 0) to the challenger. The challenger replies to each query with Tag.Vrf(K, m0, τ 0).

3. Finally, the adversary sends (m∗, τ ∗) to the challenger.

The adversary’s advantage is dened as

suf-cma ∗ ∗ ∗ ∗ advTag (A) = Pr[Tag.Vrf(K, m , τ ) = true ∧ (m , τ ) ∈/ S].

Denition 2.4 (SUF-CMA). A message authentication code Tag = (Tag.Gen, Tag.MAC, Tag.Vrf) with Tag.MAC: {0, 1}k × {0, 1}∗ → {0, 1}γ is said to be strongly unforgeable under chosen- suf-cma message attacks (SUF-CMA) if, for all probabilistic polynomial time adversary A, advTag (A) is a negligible function in k.

2.2.5 Stateful Authenticated Encryption We present two avours for the denition of a stateful authenticated encryption scheme. The rst one guarantees that the encryption scheme “hides” the plaintext such that it is not possible to distinguish the ciphertext corresponding to a given plaintext, and the ciphertext corresponding to a random value (real-or-random indistinguishability or RoR). The second guarantees that it is not possible to distinguish two dierent plaintexts based on their corresponding ciphertexts (left-or-right indistinguishability or LoR). Bellare et al. [BDJR97] have shown that both notions are equivalent. We use either denition to match with the specic security experiment considered in the proofs given in Chapters 5 and 7. The dierence between both denitions lies in the description of the Encrypt oracle. Fig- ures 2.1 and 2.2 describe respectively the RoR and LoR variants when the encryption function is a stateful authenticated encryption scheme which we dene below.

A stateful authenticated encryption scheme (sAE) consists of the following four algorithms StAE = (StAE.Gen, StAE.Init, StAE.Enc, StAE.Dec). The probabilistic algorithm StAE.Gen samples a key K from the set {0, 1}k: K ← StAE.Gen(). The deterministic algorithm StAE.Init initialises two states ste and std respectively for encryption and decryption: (ste, std) ← 0 StAE.Init(). The encryption algorithm, given as (C, ste) ← StAE.Enc(K, H, M, ste), takes as input a secret key K ∈ {0, 1}k, a header data H ∈ {0, 1}∗, a plaintext M, and the current en- ∗ 0 ∗ cryption state ste ∈ {0, 1} . It outputs an updated state ste, and either a ciphertext C ∈ {0, 1} 0 or an error symbol ⊥. The decryption algorithm, given as (M, std) ← StAE.Dec(K, H, C, std), takes as input a key K, a header data H, a ciphertext C, and the current decryption state std. It 0 outputs an updated state std, and either a value M, which is the message encrypted in C, or an error symbol ⊥. The security of an sAE scheme is dened with the following experiment between a challenger and an adversary A: hsgm atrsbt h oetaiyaditgiypoete fa of properties integrity and condentiality the both captures game This nti eto,w rsn w lsi euiymdl.W tr ihtescrt oe for model security call the we with that start parties, We two between models. protocols security exchange classic key two authenticated present we section, this In Models Security 2.3 2.2 Figure 2.1 Figure in function negligible a is ( scheme encryption cated 2.5 Denition as dened is advantage adversary’s Models Security 2.3 Fnly h desr upt t guess its outputs adversary the Finally, 3. samples challenger The 1. 2. return ( if ( ( u Encrypt h desr a dpieyqeyteecyto oracle encryption the oracle query adaptively may adversary The C C C return ( M M ( u Encrypt if C ← C C u 1 0 C ← 1 0 H , st , st , 0 u b st , H , u b ← ←− { = – – $ u = C u e 1 e 0 1 + Decrypt ⊥ ( experiment. counters The experiment. counters The ) ) C e b st , u 1 + M u ⊥ M ) ( st , ←− ←− 0 u (Secure ,H M, $ $ or ←− , 0 e $ hnreturn then 1 M , ) e StAE StAE Encrypt Encrypt } C ) StAE ← | M ← 1 sdsrbdb iue21(ep iue2.2). Figure (resp. 2.1 Figure by described as , 1 ) H , | ( = u u sAE C . . ( Enc Enc ⊥ . C and and k Enc b ) sAE ,st H, , . b and and ) ,st H, , hnreturn then . ( ( ,H M H, K, M H, K, ( h nrpinscheme encryption The v v ) ⊥ ,H M H, K, K adv f o l rbblsi oyoiltm adversary time polynomial probabilistic all for if, r ntaie o0 and 0, to initialised are r ntaie o0 and 0, to initialised are Decrypt Decrypt e b ← ) e b StAE sae ) StAE 1 0 ( st , st , b A st , ⊥ rce nthe in oracles rce nthe in oracles = ) . e e Gen e ) ) ) b

() Pr[ 0 { ∈ and , b ( v if Decrypt return if if ,st M, = 0 return if if ( v if Decrypt StAE ← b sync u > v ,st M, , ← sync u > v b b 1 0 = b then } 0 0 = then v ←− { sAE sAE sync sync ] $ v d of − 1 + ssi ob a be to said is ⊥ ) = d ( hnreturn then 1 + or ⊥ sync ) = ,H C, b ← ( 2 1 hnreturn then 0 or RR euiyeprmn.The experiment. security (RoR) sync LR euiyeprmn.The experiment. security (LoR) . false ,H C, ← ,

to to C false 1 . StAE C } StAE true true 6= ) . ← 6= ) Encrypt ← C hnreturn then false . C v Dec hnreturn then false . AKE v ttebgnigo the of beginning the at the of beginning the at Dec or euesaeu authenti- stateful secure ⊥ or ⊥ ( H ,H ,st C, H, K, ( H n h decryption the and oe,a described as model, ,H ,st C, H, K, sAE 6= 6= H A M H cee The scheme. v M , v adv d StAE sae ) d ) ( A 35 )

2 36 Chapter 2 Preliminaries and Denitions by Brzuska, Jacobsen, and Stebila [BJS16] (Section 2.3.1). We follow with the Authenticated and Condential Channel Establishment (ACCE) security model proposed by Jager, Kohlar, Schäge, and Schwenk [JKSS11]. This model aims at analysing protocols when the security cannot be based on the indistinguishability of the session keys (Section 2.3.2). The AKE model is one of the two main provable security tools that we employ in our work. We use the AKE model rst to prove the security of our two-party key exchange protocol SAKE in Chapter 6, and as a building block in order to devise an extended security model (that we call 3-AKE) described in Chapter 5, Section 5.2. In Section 2.3.2 we present the second main tool that we employ: the ACCE model. The latter is used in Section 5.3 to prove the security of a protocol aiming at establishing secure tunnels, and also as a building block to devise an extension of the ACCE model intended to the three-party case (that we call 3-ACCE). Besides the AKE and ACCE models that we mainly use, several other security models have been formerly proposed. We recall some of them in Section 5.1.

2.3.1 AKE Security Model In this section, we present the security model for authenticated key exchange protocols described by Brzuska, Jacobsen, and Stebila [BJS16], that we call AKE model. This model incorporates all the features that are usually considered when analysing key agreement protocols in the public-key setting (e.g., DH-based protocols with signature). In this model, the adversary has full control over the communication network. It can forward, alter, drop any message exchanged by honest parties, or insert new messages. Brzuska et al.’s model then captures adaptive corruptions but also forward secrecy. This appears in the denition of the security experiment.

2.3.1.1 Execution Environment

Parties. A two-party protocol is carried out by a set of parties P = {P0,...,Pn−1}. Each party Pi has an associated long-term key Pi.ltk. The nature of the long-term key is not specied here. It can be a pair of public and private keys, a symmetric key, or a combination of both types.

Instances. Each party can take part in multiple (sequential or parallel) executions of the protocol. Each run of the protocol is called a session. To each session of a party Pi, an instance s πi is associated which embodies this (local) session’s execution of the protocol, and has access to the long-term key of the party. In addition, each instance maintains the following state specic to the session.

• ρ: the role ρ ∈ {init, resp} of the session in the protocol execution, being either the initiator or the responder.

s • pid: the identity pid ∈ P of the intended communication partner of πi . • α: the state α ∈ {⊥, running, accepted, rejected} of the instance.

s • sk: the session key derived by πi .

s • κ: the status κ ∈ {⊥, revealed} of the session key πi .sk. • sid: the identier of the session.

s • b: a random bit b ∈ {0, 1} sampled at initialisation of πi . i ymkn nisac cetmlcosy(ento .) r(i ygesn h ertbtof bit secret the guessing by (ii) or 2.8), (Denition maliciously accept instance an making by (i) desra queries. Adversarial cetdmaliciously accepted 2.8 Denition the the execution an win the of can uses adversary experiment terms The This in adversary. above. dened an described is and environment security challenger the a where between played and experiment (2.2), and (2.1) requirements rectness 2.6 Denition Denitions Security 2.3.1.2 them. to queries following the issuing by instances the instances two Models Security 2.3 ento 2.7 Denition (b) (a) oeta h oino rsns noprtsarqieetfrfradsecrecy. forward An for requirement a incorporates freshness of notion the that Note variables the on requirements correctness following the put We frayprnrinstance partner any for (c) Test • • • • • where with Test Reveal NewSession π returns it then that dene say we we corrupted, then adversary, the by issued query running adversary. the to returned Send and produced is protocol the of message rst the partner intended and π Corrupt uhniae e xhneprotocol exchange key authenticated i i s s isac Diin2.9). (Denition -instance .κ .α ( ( ν 6= π π = π 0 ( i i sk s s i s π .α ) ( revealed ν < accepted π m , hsqeymyb se nyoc hogottegm.If game. the throughout once only asked be may query this : P i treturns it , s 1 i (Partnership) (Freshness) s Ett uhniain(EA)) Authentication (Entity ) i , = = hsqeyrtrstessinkey session the returns query this : ) ) π ( 0 hsqeyrtrsteln-emkey long-term the returns query this : . hsqeyalw h desr osn n message any send to adversary the allows query this : P j t π π h olwn uthold: must following the , ( i j t i s π ρ, , ⊥ nteAEscrt xeietwt neddpartner intended with experiment security AKE the in .α . i s sk tews tsmlsa needn key independent an samples it Otherwise . .α h adversary The = pid and h key The . and ⊥ = . accepted ν ) pid Otherwise . ninstance An hsqeycetsanwinstance new a creates query this : . P accepted π + = π w instances Two i i s h ntnessaei e to set is state instance’s The . j . t is pid of ∞ ν sk crutdwith -corrupted π = . b i s ∧ ehv that have we , scle the called is P A ) π π j π ⇒ sasmdt oto h ewr,aditrcswith interacts and network, the control to assumed is i i s s when i s . ( epnsacrigt h rtclspecication. protocol the to according responds sid ssi obe to said is AKE ( π π . i s i s = ninstance An and . A sk satoprypooo aifigtecor- the satisfying protocol two-party a is ) π susits issues j t ν 6= Test . π 0 sid π π ∧ ⊥ j t P ν < j i t s are .κ . i -challenge fresh sk P is ⇒ AKE π i 6= and , and , . partners i s ltk ν ν . π    sid -corrupted 0 revealed π i ihitne partner intended with s t query, -th i s of xeieti n ftoways: two of one in experiment faprotocol a of .α π π π π 6= π i j i i P s t s s . ⊥ . i . . .κ s = i pid sk pid sk If . if α tparty at ) sstto set is running , = π 0 sk = = o at hti not is that party a For . Corrupt i s ←− K and . π $ , sid P P j t sid P . m i j π sk j P = P i n returns and , Π s if , and revealed to .α j i ( n,if and, aigrole having , π ssi ohave to said is is P π j t 6= i . pid i ν s ) sid If . 0 P accepted sthe is -corrupted o any For . j . ρ if , π = . i s .α AKE (2.2) (2.1) ν sk init -th 37 6= ρ b , , , ,

2 38 Chapter 2 Preliminaries and Denitions

s s (a) πi .α = accepted and πi .pid = Pj when A issues its ν0-th query, 0 0 (b) Pi and Pj are ν- and ν -corrupted with ν0 < ν, ν , and

t s t (c) there is no unique instance πj such that πi and πj are partners. The adversary’s advantage is dened as its winning probability:

ent-auth advΠ (A) = Pr[A wins the EA game].

Denition 2.9 (Key Indistinguishability). An adversary A against a protocol Π, that issues s its Test-query to instance πi during the AKE security experiment, answers the Test-challenge correctly if it terminates with output b0, such that

s (a) πi is fresh with some intended partner Pj, and s 0 (b) πi .b = b . The adversary’s advantage is dened as

key-ind s 0 1 adv (A) = Pr[π .b = b ] − . Π i 2

Denitions 2.8 and 2.9 allow the adversary to corrupt an instance involved in the security experiment (once the targeted instance has accepted, in order to exclude trivial attacks). There- fore, protocols secure with respect to Denition 2.10 below provide forward secrecy. Note that we do not allow the targeted instance to be corrupted before it accepts. That is, this security model does not capture key-compromise impersonation attacks (KCI) [BWJM97].1

Denition 2.10 (AKE Security). We say that a two-party protocol Π is a secure AKE protocol if Π satises the correctness requirements (2.1) and (2.2), and for all probabilistic polynomial time ent-auth key-ind adversary A, advΠ (A) and advΠ (A) are a negligible function of the security parameter.

2.3.2 ACCE Security Model In this section we present the Authenticated and Condential Channel Establishment (ACCE) security model of Jager, Kohlar, Schäge, and Schwenk [JKSS11]. The AKE model described in Section 2.3.1 guarantees that the session key output by a key establishment protocol is indistinguishable from a random value. However there exist protocols where the session key is used during the key exchange phase. A famous example of such protocols is TLS 1.2 [DR08]. In TLS 1.2 the session key is used to protect messages (called Finished) which nalise the key exchange phase. Since these encrypted and MAC-ed Finished messages provide a trivial way to distinguish the session key from a random value, the security of TLS 1.2 cannot be proved based on indistinguishability of keys. The notion of ACCE is an alternative security model devised to circumvent the impossibility of using the AKE model in order to prove the security of TLS 1.2. The rst property captured by the ACCE model is entity authentication (as in the AKE model). But instead of guaranteeing that the session key is suitable to be used for any purpose, the second property ensures that the key is suitable for a specic purpose which is to set up an authenticated and condential channel. More precisely, in the Jager et al.’s security model the second property corresponds to what the secure channel itself is supposed to achieve. That is,

1In this thesis, we consider protocols not resistant to KCI attacks. h entosof denitions The ceet ietelnt fteplaintext. the of length the hide to scheme 2.3 Figure them. to queries following the issuing by instances the queries. security Adversarial the during parties the and instances the with queries interact following to the order experiments. dene We in adversary (2.2). an and to (2.1) given requirements correctness same the consider also Environment Execution 3. 2.3.2.1 Chapter in analyse we protocols the of properties security the capture 2.2.5). adequately Section (see encryption authenticated stateful of sense the an in Hence tunnel data. of condentiality and authenticity Models Security 2.3 esihl ea h rgnlmdlo ae ta.a ed o eur the require not do we as al. et Jager of model original the relax slightly We to order in al. et Jager of model original the of version modied slightly a present We ( u if Encrypt ( b if ( return C C C 2 • • • ← h rtclw nls nCatr3wt hsmdli ul nannlnt-iigecyto function. encryption length-hiding non a on built is model this with 3 Chapter in analyse we protocol The π C ← u 0 1 i s NewSession π then within (stored keys session tion Decrypt bit the on depending π H Encrypt model. AKE the in queries corresponding the to H , st , st , 0 .α π i i s s u = ihteecyto eso es(trdwithin (stored keys session encryption the with , . .α i s b C u e 0 e 1 1 + . 6= ⊥ ( b ) ) st , u ape trno ttebgnigo h euiyexperiment. security the of beginning the at random at sampled π π – 6= ←− ←− accepted i s i s $ $ or sync case In The session. tunnel. secure the establish to counters used scheme encryption authenticated stateful The M , e ( ( returns accepted ) π π StAE StAE C i ← s i s 0 M , ,H C, , Encrypt 1 ( parties M , P = ( = i C . . 0 ρ, , Enc Enc false ⊥ 1 M , ⊥ b u H , hnreturn then ,st H, , ) rcsl,i rcesa eitdb iue23 eedn ntebit the on depending 2.3, Figure by depicted as proceeds it Precisely, . h adversary The then , and pid hsqeydcyt h ciphertext the decrypts query this : hnreturn then ( ( and 1 ec ,M H, kenc, ec ,M H, kenc, ) and H , π ) . i s , π v . instances e b Send ) b i s ) hsqeyecyt h message the encrypts query this : Decrypt r ntaie o0 and 0, to initialised are π ape trno ttebgnigo h euiyexperiment. security the of beginning the at random at sampled osnthv ate hnaseiga answering when partner a have not does i s returns ( π ⊥ i s ⊥ 0 1 π m , st , st , A r h aea nteAEmdl(eto ...) We 2.3.1.1). (Section model AKE the in as same the are rce nthe in oracles i s . ck ) sasmdt oto h ewr,aditrcswith interacts and network, the control to assumed is e e 2 , ⊥ ) ) Corrupt fan of ) rcsl,i rcesa eitdb iue2.3, Figure by depicted as proceeds it Precisely, . ACCE accepting ( return if if ( v if if Decrypt P ,st M, ← sync u > v π π i ACCE sync ) i i s s , then . .α Reveal v b rtclalw salsigasecure a establishing allows protocol π d 1 + i 0 = s 6= ⊥ ) = C ( . to or instance ck euiyexperiment. security sync π ← accepted false i ihheader with s true fan of ) C ( ,H C, , hnreturn then π StAE i s 6= ← M ) hs ure r identical are queries these : C ttebgnigo every of beginning the at b hnreturn then π ) false . , accepting v Dec i s b If . or hnreturn then = Decrypt ( H H π dc ,C st C, H, kdec, π ⊥ i s ihtedecryp- the with , StAE i s 6= .α . b instance H ihheader with , 6= M v StAE ur,then query, encryption accepted ⊥ sthe is π d i s ) If . 39 ,

2 40 Chapter 2 Preliminaries and Denitions

2.3.2.2 Security Denitions An authenticated and condential channel establishment protocol (ACCE) is a two-party protocol satisfying the correctness requirements (2.1) and (2.2) (see the AKE model in Section 2.3.1), and where the security is dened in terms of an ACCE experiment played between a challenger and an adversary. This experiment uses the execution environment described above. The adversary can win the ACCE experiment in one of two ways: (i) by making an instance accept maliciously (Denition 2.11), or (ii) by guessing the secret bit during the channel security experiment (Denition 2.12). s Denition 2.11 (Entity Authentication (EA)). An instance πi of a protocol Π is said to have accepted maliciously in the ACCE security experiment with intended partner Pj, if s s (a) πi .α = accepted and πi .pid = Pj when A issues its ν0-th query, 0 0 (b) Pi and Pj are ν- and ν -corrupted with ν0 < ν, ν , (c) π0.κ 6= revealed for any instance π0 that accepted while having a matching conversation s to πi , and t s t (d) there is no unique oracle πj such that πi has a matching conversation to πj. The adversary’s advantage is dened as its winning probability: ent-auth advΠ (A) = Pr[A wins the EA game]. Denition 2.12 (Channel Security). An adversary A against a protocol Π breaks the channel s 0 security if it terminates the channel security game with a tuple (πi , b ) such that s s (a) πi .α = accepted and πi .pid = Pj when A issues its ν0-th query, 0 0 (b) Pi and Pj are ν- and ν -corrupted with ν0 < ν, ν , s (c) πi .κ 6= revealed, 0 0 s 0 (d) π .κ 6= revealed for any instance π such that πi has a matching conversation to π , and s 0 (e) πi .b = b . The adversary’s advantage is dened as

chan-sec s 0 1 adv (A) = Pr[π .b = b ] − . Π i 2 Compared to the original model of Jager et al. we slightly change the EA and CS security denitions in the following way. We allow the targeted party Pi to be corrupted but only upon s acceptance of its instance πi . That is, resistance to KCI attacks is not captured (we do so in view of proving the security of a symmetric-key protocol, hence not resistant to KCI attacks, in Chapter 3). Nonetheless, the model captures the forward secrecy property (if ν 6= +∞ and ν0 6= +∞). Doing so, we obtain a model similar as the one used by Li, Schäge, Yang, Kohlar and Schwenk [LSY+14] to prove the security of TLS 1.2 in PSK mode (i.e., a symmetric-key version of TLS 1.2). Denition 2.13 (ACCE Security). We say that a two-party protocol Π is a secure ACCE protocol if Π satises the correctness requirements (2.1) and (2.2), and for all probabilistic polynomial time ent-auth chan-sec adversary A, advΠ (A) and advΠ (A) are a negligible function of the security parameter. 2

eg,wtr energy). water, (e.g., Contents we Then protocol. the aws. of these release mitigating latest at this aiming aect recommendations that present 1.1 LoRaWAN of weaknesses equipment. several unmodied and with patched compliant between being interoperability time the same keeping the and at specication, while practical from the attacks, propose the suers we thwarting it Finally at condentiality. that aiming breach data recommendations show that and integrity, ones, we data practical and availability, likely network version, including the attacks, deployed several currently introduce We the weaknesses. is several which 1.0, of analysis resources sensitive deliver that networks of management detection, to intrusion up assets, and valuable surveillance of site geolocation activation, device remote measurement, telemetry L h eut fti hpe aebe ulse n[F8]ad[CF19]. and [AF18b] in published been have chapter this of results The present We 1.0. version of security the impair that aws several correcting at aims 1.1 Version extensive an provide we chapter, this In 1.1. and 1.0 exist: protocol the of versions main Two re.LRWNam tscrn omnctosbtenabc-n ewr and network back-end a between communications securing at aims LoRaWAN tries. protocol security IoT an is oRaWAN once bet.Teeojcsaeitne opoievrostpso evcsfrom services of types various provide to intended are objects These objects. connected . rtclLRWN1.1 LoRaWAN Protocol 3.5 1.0 LoRaWAN for Recommendations 3.4 1.0 LoRaWAN against Attacks 3.3 . rtclLRWN1.0 LoRaWAN Protocol 3.2 Introduction 3.1 .. eueChannel Secure 3.5.4 .. eso esComputation Keys Session Exchange Key and 3.5.3 Authentication 3.5.2 Architecture 3.5.1 Specications LoRaWAN the in Changes Implementation 3.4.2 Practical 3.4.1 Integrity Data of Lack 3.3.3 Desynchronisation Decrypt or 3.3.2 Replay 3.3.1 Authentication and Encryption Data 3.2.3 .. e Exchange Key 3.2.2 Overview 3.2.1 .. tak n Vulnerabilities and Attacks 3.1.2 Context 3.1.1 nlsso LoRaWAN of Analysis ...... elydwrdiei oethan more in worldwide deployed ...... 3 100 63 62 49 46 45 65 63 63 60 50 48 62 46 45 45 67 64 57 47 coun-

3 44 Chapter 3 Analysis of LoRaWAN

3.6 Vulnerabilities in LoRaWAN 1.1 ...... 67 3.6.1 Size of the Counters ...... 67 3.6.2 Size of the MAC Tags ...... 68 3.6.3 Known Encryption Keystream ...... 68 3.6.4 Downgrade Attack ...... 69 3.6.5 Lack of Data integrity ...... 70 3.6.6 Reuse of an Application Session Key ...... 70 3.6.7 Malicious or Corrupted NS ...... 71 3.7 Recommendations for LoRaWAN 1.1 ...... 72 3.8 Other Analyses ...... 73 3.8.1 On LoRaWAN 1.0 ...... 73 3.8.2 On LoRaWAN 1.1 ...... 75 eso nScin33hwt efr eea tak gis oaA .,icuiglikely including 1.0, LoRaWAN against attacks several perform to how 3.3 Section in show We ekesso h rtcl hs tak ontla nptnilsfwr rhrwr bugs. hardware or software potential on lean not do attacks these protocol, the of weaknesses Korea) (South Asia [Fea16], Netherlands) (France, Europe in deployed already are networks wide futmngmn) nutil(atqaesnos vlnh,oig,satct,wearables city, smart ooding), avalanche, sensors, (earthquake industrial management), (fault 2017). May (in Low- a up setting at aims company, Semtech by developed LoRa, protocol communication The ieiete onteti hsclacs otetree qimn n r independent are and equipment targeted the to access physical a entail not inner do the they on Likewise Based network. back-end data the and integrity, or data end-device availability, an network either the target breach and to condentiality, allow attacks These ones. practical Vulnerabilities and Attacks 3.1.2 equal cryptographically is it but 2018, in published 1.0.2. been version has to [LoR18a] 1.0.3 version addition, In (trac telematics vehicle systems), status). (security vehicle home information, connected wearables), (medical health and grids smart (irrigation), agriculture assets), valuable containers, (shipping tracking water), ity, worldwide deployed networks LoRa of map a represents covering 3.1 Figure at aims [Kim16]. network country) phase the with rst across (starting (the to USA India extend the [Sma16a], coverage [Bri16], people) expected Japan million (the in China launched [Kin16], are cities) Trials hundred already population. a providing the [Sma16b], of Zealand) half (New to Oceania coverage [Biz15], Africa) (South Africa [Mar16], private etc.), Proximus, Orange, KPN, LORIOT.io ZTE, (e.g., FastNet, providers Telecom, (SK operators telecom by [IoT19] [IoT19]. than more etc.) gathers suppliers, that network association manufacturers, an hardware is which Alliance, LoRa the 500 by designed is or It eight network. to up lifespan a have to and area, to urban years. supposed an ten is in power-supply, kilometers autonomous several an through with communicate end-device, LoRa A regulated) Wor]. (although [LoR17; free China) uses it for because (e.g., optimised license bands but spectrum frequency systems) a mobile require (2G/3G/4G not technology does cellular technology. LoRa IoT/M2M. a wireless to low-rate, similar long-range, somewhat a is on It based (LPWAN) Network Wide-Area Power Context 3.1.1 Introduction 3.1 Introduction 3.1 nti hpe efcso h w anvrin fLRWNta r dened: are that LoRaWAN of versions main two the on focus we chapter this In (electric- metering smart include to responding at aims LoRaWAN that [OA16] cases use The than more in deployed are networks LoRaWAN private and Public LoRa a of layer Control Access Medium the securing at aims that protocol a is LoRaWAN 2 1 • • ebr tlcmoeaos eiodco auatrr,dgtlscrt companies, security digital manufacturers, semiconductor operators, (telecom members https://www.thethingsnetwork.org https://www.loriot.io eso . Sr7 hc isa en h ucso fvrin10(etos3.5-3.6). (Sections 1.0 version of successor the being at aims which [Sor17] 1.1 version 3.2-3.4), (Sections 1.0 now is worldwide, name deployed currently ocial version whose the is and which 2016, in released [SLE+16] 1.0.2 version 863 1 ,adpiaeiiitvs(.. h hnsNetwork Things The (e.g., initiatives private and ), - 870 H nEurope, in MHz 902 - 928 H nteUSA, the in MHz 100 100 ilo oe and homes million onre worldwide countries 400 2 779 .Svrlnation- Several ). ilo people million - 787 H in MHz 300 45

3 46 Chapter 3 Analysis of LoRaWAN

Figure 3.1 – Worlwide map of LoRa networks in May 2017 (source: http://iot.semtech. com) from the means used to physically protect secret parameters. Several recommendations aiming at thwarting these attacks are presented in Section 3.4. In Section 3.6, we show that the latest version 1.1 of LoRaWAN still suers from several aws. We describe in Section 3.7 several ways to mitigate these vulnerabilities.

3.2 Protocol LoRaWAN 1.0

3.2.1 Overview A LoRaWAN network corresponds to a star-of-stars topology: a set of end-devices (ED) communicates with several gateways which relay the data to a Network Server (NS) in the back-end side. In turn NS delivers the data to one or more Application Servers (AS) which own the corresponding ED, optionally through intermediary servers such as an MQTT server (see Figure 3.2). The security mechanisms are based on a symmetric key (the master key) MK1 shared between an ED and NS. From this key, distinct per ED, two session keys are computed: the application e session key Ka guarantees the data condentiality between ED and AS; the command session e key Kc guarantees the data integrity between ED and NS (thus data integrity is not end-to-end provided between ED and AS3). When a frame is exchanged exclusively between ED and NS, e both data condentiality and data integrity are provided by the command session key Kc . An application payload, if present, is always encrypted. If no payload is carried the frame is only authenticated. Encryption is done with AES [Nat01] in CTR mode [DH79; Dwo01], and data integrity is provided with a tweaked version of AES in CMAC mode [Dwo05; SPLI06] (a prex block is added to the input). ED may establish an “activation” (namely a session) with NS through two ways. The pre-personalization (“Activation by Personalization”, ABP) consists in setting two session keys (and other parameters but not the MK1 master key) into ED before its deployment. An ED in ABP mode is then able to communicate with NS (and its AS) but not to renew the “session” keys. The other possibility (“Over the Air Activation”, OTAA) consists

3As acknowledged by the specication ([SLE+16], §6.1.4). with cetmsaei rtce iha with protected is message Accept h e xhnedn vrteari rgee hnE ed a sends ED when triggered is air the over done exchange key The au sda Dsotades( address short ED as used value value h nrpinfnto only. function encryption the of values pseudo-random two and key master the with made operations ( latter the of identier (static) the the with computed EUI- IEEE static two includes a with to responds Exchange Key 3.2.2 3.2 Figure on focus we chapter, this In deployed. is it once interface mode. radio OTAA the through NS with exchanges an with ED provisioning in 1.0 LoRaWAN Protocol 3.2 hstessinky eedmsl nasce n ttcvle(h atrkey master (the value static and secret a on mostly depend keys session the Thus 4 oepeieythe precisely More End-device rnd E – eeae yE.Temsaei rtce iha with protected is message The ED. by generated oaA ewr nvrin10 aaecagdbtenE n Sare NS and ED between exchanged Data with 1.0. encrypted version in network LoRaWAN onAccept Join 128 aaitgiy( integrity data data AES Gateway bt(ttc atrkey master (static) -bit erpinfnto sue opoetteJi cetmsae ic Dimplements ED since message, Accept Join the protect to used is function decryption = rnd MK 64 K esg seFgr .) h uecytd onRqetmessage Request Join (unencrypted) The 3.3). Figure (see message K K dnies(h ED’s (the identiers c e c a N e e aaecagdbtenE n Saeecytdwith encrypted are AS and ED between exchanged Data . DevAddr K 1 c (3) e atrkyadohrprmtr,alwn opromkey perform to allowing parameters, other and key master = = ) id aacndnilt ( condentiality data CMAC 16 k N MK id ,aped-admvlegnrtdb S( NS by generated value pseudo-random a ), AES AES and Network N Server ,adsvrl(pinl ai aaees h Join The parameters. radio (optional) several and ), 1 (3) uhniaintg n nrpe with encrypted and tag, authentication ). ( ( 24 MK 4 MK MK k Two is neteJi eus n onAccept Join and Request Join the Once bits. rnd 1 1 1 h onAcp epnefo Scontains NS from response Accept Join The . , , id E 128 0x01 0x02 E (2) K n h AS’ the and , btssinky r hncomputed: then are keys session -bit a e k k k ) 0x00 data data MQTT Server 32 ) ) onRequest Join · · · -bit 00 id CMAC A (7) ,adapseudo-random a and ), . esg hc NS which message uhniaintag authentication Application Server AES rnd MK (both N K ,a ), 47 1 a e ), .

3 48 Chapter 3 Analysis of LoRaWAN messages are exchanged, ED, NS and AS are able to communicate. After NS computes the e session keys, it transmits the application session key Ka to AS, which has thus no control on this key sharing phase, entirely handled by NS. The NS must keep the previous session keys, and the corresponding security parameters, until it receives a (valid) frame protected by the new security parameters. The security mechanisms between NS and AS are out of the LoRaWAN scope.

ED NS (MK1)(MK1)

$ 16 rndE ←−{0, 1} τE ← MAC(MK1, idAkidEkrndE) Join Request ← idAkidEkrndEkτE Join Request −−−−−−−−−−−→

Verify τE $ 24 rndN ←−{0, 1} τN ← MAC(MK1, rndN kidN kDevAddrkprms) −1 Join Accept ← AES (MK1, rndN kidN kDevAddrkprmskτN ) data ← rndN kidN krndEk00 ··· 00 e Kc ← AES(MK1, 0x01kdata) e Ka ← AES(MK1, 0x02kdata) Join Accept ←−−−−−−−−−−−

rndN kidN kDevAddrkprmskτN ← AES(MK1, Join Accept) Verify τN data ← rndN kidN krndEk00 ··· 00 e Kc ← AES(MK1, 0x01kdata) e Ka ← AES(MK1, 0x02kdata) post-accept phase ⇐======⇒

Figure 3.3 – Correct execution of LoRaWAN 1.0

3.2.3 Data Encryption and Authentication

In this section we describe the computations done in order to encrypt and provide integrity protection to a frame. The plaintext frame payload ptext is encrypted in CTR mode. From the following 16-byte block

Ai = 0x01 (1)k0x00 ··· 00 (4)kdir (1)kDevAddr (4)kfcnt (4)k0x00 (1)ki (1)

e e a secret keystream Si = AES(K,Ai), with K ∈ {Ka,Kc }, is produced and used to mask the payload:

ctext = (S0k · · · kSn−1) ⊕ ptext. cetmsae n trmiscntn uigteetr eso.T compute To session. entire the during constant remains it and message, Accept and AS, h eso key session The 32 nScin .. n ..,teatce,sadn ewe DadN,nesol oato the on act to only needs NS, and ED between 1.0. standing version attacker, protocol the LoRaWAN 3.3.2, the and against 3.3.1 found Sections have In we attacks the present we Hereinafter 1.0 LoRaWAN against Attacks 3.3 3.4 Figure key encryption the and data, key application session contain command cannot the payload is the used case a such In payload. is counter frame the the If in NS. and ED between exchanged exclusively commands contain may header frame The frame. elds, application other an of generation the depicts 3.4 Figure DevAddr that Note B plen (header frame whole the encrypt. identier “ unique are NS’ the from chosen are bits direction. frame’s the on depending used are counters dierent Two DevAddr received. or sent is frame or dir 1.0 LoRaWAN against Attacks 3.3 0 btln,this long, -bit A 32 = pcstedrcin( direction the species n a and ) 32 arbitrarily is,iiilsdto initialised bits), 0x49 Opts F btatetcto tag authentication -bit K B and sE’ drs wti ie oantok hsnb Sadsn nteJoin the in sent and NS by chosen network) LoRa given a (within address ED’s is – = (1) 16 DevAddr 0 eeaino napiainfaei oaA ..Tessinkey session The the 1.0. LoRaWAN in frame { application an of Generation edaei la.I hyhv ob nrpe hyms eicue nteframe the in included be must they encrypted be to have they If clear. in are eld and K bt r block prex -byte K sindb S The NS. by assigned ” k fcnt 0x00 fcnt c e a K e K , ledse box dashed blue sue when used is A = h rm vnulysn is sent eventually frame The . i c e edcrepnst h least the to corresponds eld · · · ie nyo h rtadls ye,adsaetesm parameters same the share and bytes, last and rst the on only dier } h rm counter frame the , K sue oecytthe encrypt to used is 0 a e 00 hdr sue when used is hntessinsat,admntnclyicesdwe (valid) a when increased monotonically and starts, session the when uplink (4) τ fsize of hdr k scmue with computed is command-only dir ¦ § K AES | B = . ( c e (1) hlen 0 . hlen k 0x00 i ¦ § - hdr AES k au ubr the numbers value CMAC application DevAddr ) fcnt k , { ∈ {z k ctext downlink - ctext ptext CTR ptext 8 id ( on K esgsaeecagdbtenE n NS. and ED between exchanged are messages , . . . , N ( ( c CMAC e k 16 : plen K, , 16 τ (4) esgsaeecagdbtenE and ED between exchanged are messages msb · } ) ala.Teecytdfaeapasin appears frame encrypted The payload. 24 is n n(pinl eld (optional) an and bits, · inatbt.Tecmad included commands The bits. signicant = ¥ ¤ ) k ) } fcnt 7 k ¤ ¥ 0x01 ( τ n h omn eso key session command the and n nrpe payload encrypted and DevAddr (4) AES (4) ). . fcnt k lcswti h ala to payload the within blocks 0x00 = ) stefaecutr( counter frame the is (1) lsb hdr k 7 ( ( hlen id DevAddr nlds among includes, N Opts F ) ctext and , + plen 25 seven , fsize of K which K (1) ) c e bits on 16 49 ∈ .

3 50 Chapter 3 Analysis of LoRaWAN air interface: she needs to eavesdrop on data exchanged between ED and the server, and to send data to any equipment. With these simple requirements, the attacker can replay frames, decrypt frames, and desynchronise an ED. In Section 3.3.3, we describe other kind of attacks where the attacker needs to act at some point on the link between NS and AS. Then the attacker can replay, forge, and, possibly, decrypt frames.

3.3.1 Replay or Decrypt

In LoRaWAN, encryption is done in CTR mode [DH79; Dwo01] which security is proved by Bellare, Desai, Jokipii, and Rogaway [BDJR97]. Likewise CMAC mode (also known as OMAC1 [IK03a; IK03b]), used to compute a frame’s authentication tag, is proved secure by Iwata and Kurosawa [IK03c], and Nandi [Nan09]. Of course this does not necessarily imply that a protocol based on these cryptographic primitives is secure in turn [Bel98; DPW11]. In particular the security of these encryption and authentication modes is no longer guaranteed in case of a misuse, namely if same session keys, counter blocks, and B0 prex block are reused. Based on the peculiarities of LoRaWAN, it is actually possible to compel ED or NS to reuse previous security parameters. We describe precisely how to perform such an attack against ED or NS, and its consequences.

3.3.1.1 Targeting the End-device (Attack A1)

Goal. The purpose of this attack is to compel ED to reuse previous session keys and other security parameters. When this happens, frames picked from a previous session become cryptographically valid anew, hence can be replayed. Moreover the same secret keystream is then used to protect the frames exchanged during the new session. This allows an adversary to decrypt frames. Since ED ends up reusing previous session keys (which are no longer shared with NS), this attack is also a kind of “desynchronisation” attack. However, contrary to the desynchronisation attacks described in Section 3.3.2, this “replay or decrypt” attack has more devastating consequences (and a higher complexity) than merely desynchronising ED and NS.

Key points. The encryption keystream Si = AES(K,Ai) used to protect a frame payload is e e produced from a session key K ∈ {Ka,Kc } and Ai block counters. Within a given session the blocks

Ai = 0x01 (1)k0x00 ··· 00 (4)kdir (1)kDevAddr (4)kfcnt (4)k0x00 (1)ki (1)

(as well as the prex block B0) depend mostly on the frame counter fcnt (set to 0 when the session starts and monotonically increased frame after frame), and on the DevAddr parameter (static during the whole session). The other parameters are the direction dir unchanged for a given direction, and the i block index which evolves the same way for each frame. Hence the way the keystream Si changes depends only on the DevAddr parameter and the session e key (usually Ka). For a given ED, which connects to the same NS (hence uses the same static idN parameter), the session keys depend mainly on a secret and static value (MK1) and two pseudo-random values (rndE, rndN ). Therefore, if one succeeds in compelling ED to reuse the same DevAddr, rndE and rndN parameters, this leads not only to the reuse of previous e e session keys Ka, and Kc , but also to the reuse of previous keystream Si and prex block B0. where cetmsaecrepnst h onRqeti et elyn onAcp esg allows message Accept Join a Replaying sent. it Request Join the to corresponds message Accept sai)ietr n the and identier, (static) The 2 au ahtm tcmue onRqetmsae vnwe rvosJi eus message Request Join previous a when even message, Request Join a computes it time each value hatarpa tak(SE1] 624.Hne Dhst eeaeanwpseudo-random new a generate to has ED Hence, states used §6.2.4). specication ([SLE+16], previously attack The containing replay message. messages a invalid Request thwart an Join receives ignore or shall response NS Accept that Join a receive not does multiple supply. power the second interface, air the rst multiple vectors: generate attack to two least ED at compel through messages. must achieved Join she of successful, harvest be attack: to the tacker achieve to used the 2 since Technique usable not is ED key. another master to ED’s intended with message protected Accept is Join message A ED. targeted the to NS both (re)use to ED compel to attacker the ( static is calculation message the particular in NS, by chosen are parameters the all that is key to message. correspond the message in Accept included Join parameters a the in again) carried (once data reuse will the ED Indeed Then ED. message. targeted Accept the to Join given sent a a of use replay to attack: ED the compel achieve to used 1 Technique respectively denoted parameters, security same the with protected order in a message) carries Request one Join before new messages a then send is to successful ED be compelling to (i.e., experiment this the is repeat must of success of one probability with The matches it collected. that expects and message, (necessarily attacker the most dierent by at a collected is to messages Accept corresponds Join one of each number where ED, the to NS by sent messages among value one only case multiple generate to ED ( probability high with happens paradox birthday the the to on due p only collision depends repeat a keys session the that the probability impose to able is attacker Attack. 1.0 LoRaWAN against Attacks 3.3 16 takvco:arinterface. air vector: Attack by sent previsouly messages Accept Join the on bear attacker the for choices possible The sessions dierent two with ends attacker the achieved, is attack the of phase rst this Once compels and session, given a on eavesdrops she process: whole the up speed can attacker The ln(2) 2 rnd MK 16 τ -bit E N rnd 1 aus oegnrly h takrcnevsrpo eea ieetJi Accept Join dierent several on eavesdrop can attacker the generally, More values. × hs aaeesaepoetdwith protected are parameters These . 2 sa uhniaintgcmue ntepeeiglswt h sai)master (static) the with elds preceding the on computed tag authentication an is h ups st aeE s wc h same the twice use ED make to is purpose The 16 rnd 2 E 16 dierent ausi eae otebhvoro Dwe tsnsaJi eus esg but message Request Join a sends it when ED of behaviour the to related is values E ' and 301 rnd rnd 24 esosonly. sessions N 1 rnd -bit /p (3) prms rnd E 2 E 2 = aus.Te h takrcmesE osn rs onRequest Join fresh a send to ED compels attacker the Then values). k 16 rnd nti cnro h blt fteatce omk Dgenerate ED make to attacker the of ability the scenario, this In rnd N id ausutlteepce au spoue neaan nsc a such In again. once produced is value expected the until values rnd sueu oteatce.Hne Dms eeaeo average on generate must ED Hence, attacker. the to useful is r lode yN.Teol ertprmtrivle in involved parameter secret only The NS. by dened also are N 16 au,teatce a elyapeiu onAcp message Accept Join previous a replay can attacker the value, N N /n E MK (3) aaeesaeped-adm e sasm htan that assume us Let pseudo-random. are parameters au htE sst opt h eso es hnthe Then keys. session the compute to uses ED that value au htmthswt n fteJi cetmessages. Accept Join the of one with matches that value ja k hsmasta Dhst send to has ED that means This . DevAddr 1 .Hne Di o bet eiyi h eevdJoin received the if verify to able not is ED Hence, ). p rnd = n N ja AES and / (4) 2 16 DevAddr k h ubro ie htteattacker the that times of number The . and prms n MK ja rnd rnd onAcp esgspreviously messages Accept Join (2 rnd N 1 - E h onrtn fti attack this of cornerstone The . 18) parameters. , and E rnd s aaee.Frtynt that note Firstly parameter. k old rnd τ DevAddr N N and rnd and , rnd (4) E 2 n p s 16 aus hscnbe can This values. ja E = E nodrfrteat- the for order In new /n DevAddr ausi re to order in values ≤ au.Let value. 2 1 ja . fe roughly after ) seFgr 3.5). Figure (see 2 id 16 onRequest Join N nodrto order In ic there since steNS’ the is values. n rnd ja be 51 E

3 52 Chapter 3 Analysis of LoRaWAN

ED AttackerNS  Join Request (rndE = xi)  −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→   Join Accept (rnd = y )  ←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−N i   e e e e  K ,K ← KDF(MK1,x i,y i) K ,K ← KDF(MK1,x i,y i)  c a c a  ul frame 0  −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→  s dl frame 0 old ←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−   .  .  .  j  ul frame  −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→   dl frame j  ←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

Join Request (rnd = x ) −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→E i+1

*** Join Accept (rndN = yi+1) ←−−−−−−−−−−−−−−−−−−−−− ←−−−−−−−−−−−−−−−−−−−−− Invalid Join Accept Join Request (rnd = x ) −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→E i+2

*** Join Accept (rndN = yi+2) ←−−−−−−−−−−−−−−−−−−−−− ←−−−−−−−−−−−−−−−−−−−−− Invalid Join Accept . .  Join Request (rnd = x = x )  −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→E i+u i    Join Accept (rndN = yi) Join Accept (rndN = yi+u)  ←−−−−−−−−−−−−−−−−−−−−− ←−−−−−−−−−−−−−−−−−−−−−   e e  Kc ,K a ← KDF(MK1,x i,y i) s dl frame 0 new ←−−−−−−−−−−−−−−−−−−−−− ←−−−−−−−−−−−−−−−−−−−−−   .  .  . ←−−−−−−−−−−−−−−−−−−−−−   dl frame j  ←−−−−−−−−−−−−−−−−−−−−− ←−−−−−−−−−−−−−−−−−−−−− 

Figure 3.5 – “Replay or decrypt” attack against ED in the “air interface” scenario hrfr,ti rcdr sas a ocletmlilsJi cetmessages. Accept Join multiples collect to way a also is procedure this Therefore, h culecagssneE,a hspit a o“ate” ete SnrA sal ocmuiaewt ED. with communicate to able is AS nor NS neither “partner”: no has point, this at ED, since exchanges actual the c frame s The frames. dierent protect m to order in keystream same counter of the twice uses ED achieved, is decryption. frame Impact: values. counter increasing have must NS frames by replayed sent subsequent actually the frames However of these. number the session on throughout depends AS frames or available of to number up is the choose value precisely virtually initial may (its attacker reference as the belong used not Hence and does ED counter by its if locally ED managed by rejected care be take shall to frame to has a attacker Indeed The sequentiality. tag. the authentication about and keystream correct cryptographically a ( session new the throughout ED replay. frame message. Impact: Accept Join new a sends free. it for message, NS) Request to Join unknown a (i.e., receives messages NS fresh time gets every she that ED, Note by sent messages Request Join the duration. reboot the on only depends ED by sent be message Request Join addition, new In reboots. latter the controlled. that remotely can such be tool ED could this to tool of shocks reboot variant an electric this a presents low-intensity ED port), transmit If of to once device. type used but, the another key, be possibly, destroys or, USB that regular (USB impulse a a port electric be use communication an to can available sends appears attacker it tool the device, Secondly, This a reboot. into [Ant17]. a plugged Killer” then “USB and a outage, of targeting power version impulses and electromagnetic temporary softest generator Firstly, a the considered. or to between be o lead also link turn can can the can ED means or attacker other to, the two supply, connected least continuous is At a ED ED. Join be by generator new must powered electric a attacker is remote the sends ED a self-powered, it If interrupt is battery. on, ED the switches If access ED network. to time back-end able Each the connect reboot. to repeatedly message to Request ED compel to order in duration). communication the to 5 the to uses response Request in Join messages valid Accept Join and invalid new send multiple to collect attacker messages. the to ED’s for to attacker enough messages the is Request allows It Join This subsequent messages. the NS. fear by may dropped ED Otherwise be response. a receive not did 1.0 LoRaWAN against Attacks 3.3 t s new . old 7 hshretn ehiu ilsaohravnae fteatce obd Sfo receiving from NS forbids attacker the If advantage. another yields technique harvesting a This before elapsed time the because ecient more be scenario second this that conceivable is It supply. power vector: Attack is message Accept Join a of window receiving shortest The { stepanetand plaintext the is 5 hours ct , . . . fcnt, euetetr ssin,yti samss flnug.Ide hswr osntdpc rcsl htare what precisely depict not does word this Indeed language. of misuse a is it yet “session”, term the use We n ⊕ otisa nrpe payload encrypted an contains ja c t s 16 = new asmn httetm eddt rcs h onmsae sngiil compared negligible is messages Join the process to needed time the that (assuming t etdrn session during sent ( = MAX onAcp esgs h taki civdatrroughly after achieved is attack the messages, Accept Join m _ FCNT ⊕ k k t s _ t s old old GAP rmsdanfo h rvosssin( session previous the from drawn Frames s ) old h esra.Tefaeo aecounter same of frame The keystream. the ⊕ } .Nt httes rm h takrrpasmyb n of any be may replays attacker the frame rst the that Note ). where , lentvl,teatce a nuneo h oe supply power the on inuence can attacker the Alternatively, ( h rm ala secytdin encrypted is payload frame The m s s old new 0 ⊕ otisa nrpe payload encrypted an contains c ). k fcnt t s 5 new t s new hs rmsaevldsnete r rtce with protected are they since valid are frames These = = ) stedwikfaecutr(nta pc case) specic that (in counter frame dowlink the is m 2 0 m 14 ⊕ ⊕ 1 + k t s m new 0 rmsi re odcieE (more ED deceive to order in frames Hence . Since . 5 eod Wr.I h attacker the If [Wor]. seconds 0 k m ,and ), CTR t s old and c s t s old = old oe neteattack the Once mode. 2 MAX t m 16 a erpae to replayed be can ) k = etdrn session during sent / t s 0 _ new 16 a prilyor (partially may m FCNT × ⊕ ehv that have we , 5 k _ t s seconds GAP old where , 2 = 53 14 = .

3 54 Chapter 3 Analysis of LoRaWAN completely) be retrieved (in an obvious manner if one message, m or m0, is known, or through analysis of m ⊕ m0 [MWES06]). According to the LoRaWAN specication ([SLE+16], §4.3.1.1), if ED sends to NS more than ADR_ACK_LIMIT = 64 frames without receiving any response, it has to ask an explicit acknowledgement to the server (ED sets the ADRACKReq bit to 1 within the frame header). The ED can then send up to ADR_ACK_DELAY = 32 more frames to the server. If still no frame has been received from the server, ED may switch to the next lower data rate that provides a longer radio range. Furthermore, if ED already uses its lowest available data rate, it shall not ask for such an acknowledgement. The specication provides no guidance on how ED shall behave in the latter case, or if it still does not receive an acknowledgement after it changed its data rate, or if it decides not to change its rate. We may reasonably assume that ED keeps sending frames. This means that the attacker has at her disposal at least ADR_ACK_LIMIT+ADR_ACK_DELAY = 64+32 = 96 frames usable for her decryption attempts. Moreover, if ED asks for an acknowledgement (the attacker is aware of that since the information ADRACKReq lies in the unencrypted frame header), the attacker can use any downlink frame drawn from session sold, and replay it to ED. Indeed, according to the specication, this is enough to respond to the acknowledgement request sent by ED.

Comment on some mitigation mechanisms. The LoRaWAN specication mentions two mechanisms that can be seen at rst sight as ecient ways to mitigate the “replay or decrypt” attack. Below we explain why these mechanisms are in fact not sucient to thwart our attack.

Duty cycle. The ducty cyle is a mechanism used to regulate the occupation rate of the radio channel by ED. Enforcing the duty cycle implies that ED must wait some time before sending a new frame, hence cannot repeatedly send a lot of messages. Therefore one could claim that the duration of the attack is greater than the gure we provide. However, the duty cycle is a regulation mechanism, not a security one (even if it could cleverly be used as such). Secondly, not all countries compel to use such a mechanism (e.g., the USA and India do not). For instance, in the USA, there is no “global” duty cycle related to the 902-928 MHz frequency band, but ED must respect a dwell time that does not forbid from sending as many frames as wished. Finally, ED may well be certied (by the LoRa Alliance [LoR]) and yet not apply the duty cycle. Indeed the LoRa Alliance certication procedure does not cover any regulatory testing [Hun17].

Retransmissions back-o . The specication describes also a mechanism aiming at limiting the number of messages ED can send whereas the back-end network remains silent. The critical situations considered by the specication are for instance an earthquake or a power outage on the back-end side. If ED sends a message that requires a response but does not receive any (i.e., its receiving window remains empty), then it may everlastingly send new requests. If all the ED that are aliated to the problematic back-end network behave in this manner, this ends with the air interface being ooded and eventually jammed with all the messages. Yet, this limitation mechanism is applied by ED when the back-end network remains silent. In our attack scenario, when ED sends a Join Request message it does receive a message that is classied (through its header) as a response (i.e., a Join Accept message), even though this (invalid) response is sent by the attacker. One could argue that a cryptographically invalid message is necessarily sent by an attacker since an integrity check (based on a CRC) is done at the radio level. However, regarding the downlink messages (received by ED), the specication states that “no payload integrity check is done at this level to keep messages as short as possible with minimum impact on any duty-cycle limitations of the ISM bands used” ([SLE+16], §3.2). Finally, atfor wait au sdrn rvosssinis session previous a during as value of few a or values all means this if clarifying without attacks, replay prevent to order in values onAcp esg oaohr hog ietcmaio ewe onAcp message Accept Join a between comparison direct Through another. to message Accept Join corresponding The replay. to wants she Request Join h rcdn auswt h Ds(ttc atrky ec only Hence key. master (static) And ED’s the time. with long values a preceding quite the for same the The remain likely unchanged. remains ED given a id to corresponds with message protected Accept is Join message a Accept encryption Join Before a clear), in (sent message Request same the triggers to message sent one uses be least to at have that may probability hence, The ED, dierent servers. from NS come several may or messages one the that Note server. to the increases success of on probability eavesdrop is the success case of a probability such overall In the provisioning. ED of time the identier the ED’s derives unique implementation the NS some instance, For sessions. dierent ED the several that between show established NS sessions and real-life of observations and “pseudo-random”, is mean success of probability the then pseudo-random exchanges. key the from of frequency the on depends attack “opportunist” an such of with index, its any choose cannot attacker the n Thus (say Got]). values [Ttn; few (e.g., a codes of source track open keeps several NS by that conrmed assume reasonably may We them. the to interest of is values possible all among pair such one attacker. only hence attacker, the by chosen the sets rnd message a such replaying attacker 1. method to Attack: then is goal The same sessions. the dierent twice two use to throughout NS parameters compel security same the use to Goal. A2) (Attack Server Network the Targeting 3.3.1.2 consequences. same the still to remains leads attack and decrypt” vector, or supply “replay power the the but through vector, possible interface a air receives the ED invalidates until this applied network, is mechanism limitation this if 1.0 LoRaWAN against Attacks 3.3 trdvle.I h au h takrwnst elysilblnst h evrsls (let list server’s the to belongs still replay to wants attacker the value the If values. stored N h takri ucsflwe Ssnsteexpected the sends NS when successful is attacker The rnd “ of track keep must NS specication, the to According N steuiu S dnie,hnesai.A ad the said, As static. hence identier, NS’ unique the is n id N jr ausN eeae.Teetols aaeesms orsodt the to correspond must parameters last two These generates. NS values N h aekn fatc a epromdaantN,amn tcmeln h server the compelling at aiming NS, against performed be can attack of kind same The i sa is 2048 = and , 1 + 24 n diinl(eiiae e xhne eoeN fre”ta au.Teduration The value. that “forget” NS before exchanges key (legitimate) additional 0 25 jr btped-admvle The value. pseudo-random -bit and onRqetmsae,hrpoaiiyt uce assto raises succeed to probability her messages, Request Join ieetJi eus esgs(htN a frotn) n edte to them send and “forgotten”), has NS (that messages Request Join dierent iswihae“ are which bits rnd n h e xhnei rgee yteJi eus esg.Hnean Hence message. Request Join the by triggered is exchange key The − N DevAddr (3) 1 h ne fteods n ftelts eevdvle) h a to has she values), received latest the of and oldest the of index the id k E id lothe Also . N rnd arbitrarily aaee ean nhne o ie Dthroughout ED given a for unchanged remains parameter (3) 1 2 − − k E prms DevAddr 24 , (1 rnd every DevAddr − rnd N 2 hsnb S(SE1] 611.If §6.1.1). ([SLE+16], NS by chosen ” feunypa)dpn ntegtwy hence gateway, the on depend plan) (frequency − and E 24 n 32 ) aaee eoekoigthe knowing before parameter (4) 1 + n 2 -bit jr DevAddr − τ k au a ecoe neadfralat all for and once chosen be may value (24+25) N rnd ' prms esos lentvl,teatce can attacker the Alternatively, sessions. DevAddr sa uhniaintgcmue on computed tag authentication an is n E jr eti number certain a rnd au utntbln otels of list the to belong not must value × valid (2 2 = DevAddr values. 2 - N − 18) − 24 au.Bt otayt Join a to contrary But, value. 49 epnefo h back-end the from response aaee smd of made is parameter o ntne fteattacker the if instance, For . k u “ But . τ DevAddr rnd N (4) aaee sindto assigned parameter N AES arbitrarily . a ayfo one from vary may freceived of ” 8192 n − 1 aaee from parameter 1 ,wihseems which ), DevAddr in . DevAddr rnd ECB osnot does ” 2 − E 24 mode. rnd 7 value rnd and , i bits and be 55 N is E

3 56 Chapter 3 Analysis of LoRaWAN

(received during the attack) and the one used as reference (beforehand eavesdropped by the attacker during session sold), the attacker is able to check if the rndN value repeats.

Attack: method 2. Another method can speed up the attack. In a rst phase the attacker collects a set of n + k, k ≥ 1, dierent Join Request messages from a given ED. Necessarily at least one of these messages contains a rndE value which is “forgotten” by NS. The other messages may carry rndE values known at the moment to NS. These messages must be ordered in the following way: rst the “forgotten” messages, followed by the others sorted in the same relative order as in the NS’ list.6 In a second phase the attacker sends continuously each Join Request message of its circular list. In response to each request NS responds with a Join Accept message. The attacker keeps starting new sessions until she receives twice the same rndN value (thanks to the birthday paradox). Then the attacker gets two dierent sessions protected with the same security parameters (if the DevAddr parameter remains unchanged). In order to 1 get twice the same rndN value with high probability (p = ), it is enough for NS to generate p 2 roughly 2 ln(2) × 224 ' 4,823 Join Accept messages per Join Request message. To achieve p this the attacker must start (n + k) × 2 ln(2) × 224 sessions. For instance, if NS keeps track of n = 10 rndE values, the attacker can use a list of n + 1 = 11 Join Request messages, and the number of sessions needed to achieve the attack is 53,049. This corresponds to less than 74 hours (at the rate of 5 seconds per key exchange). However to get twice the same security parameters without application frames protected with these parameters is pointless. Hence, during the second phase of this method the attacker has to let NS send several frames before starting a new session. Therefore the duration of the whole attack is likely greater than 74 hours.

Technique used to achieve the attack. In order to collect the Join Request messages, the attacker can iterate n + k times the procedure described in Section 3.3.1.1. Then she gets a list of messages correctly sorted and ready to be used. The Join Request messages usable by the attacker must come from the same ED since the session keys are computed with the ED’s master key (and also if the DevAddr parameter is closely related to ED – e.g., computed from its idE identier).

Impact. Once the attacker succeeds in compelling NS to compute once again the same security parameters, she eventually gets two dierent sessions (sold and snew) protected with the same security parameters. The attacker is then able to replay uplink frames and attempt decryption of downlink frames. According to the specication, when a new key exchange is done NS shall keep the previous security parameters until it receives a (valid) frame protected with the new security parameters, and then it can remove the previous ones ([SLE+16], §6.2.4). Yet, since the session keys and other security parameters are reused, the attacker can easily replay to NS a frame drawn from the previous session sold, thus “conrming” the new keys to NS. Then the server drops the current keys and is ready to use the new ones.

6More exactly the necessary condition is the following: each message collected by the attacker and common with the NS’ list must have a greater index than the index in the server’s list (0 being the index of the oldest message, n − 1 the index of the latest), so that the message is replayed once it has left the server’s list. ( hnE trsanwssinadsnsaohrJi eus esg,teatce replies attacker the message, Request Join another sends and session new a starts ED When teped-admvalues pseudo-random (the identier unique NS’ (the onAcp esg sdb h takrms eitne otetree D nedsc a such Indeed ED. targeted the to intended be must attacker the by used message Accept Join onikfaeatrae ubro etfae.Frisac,i Dsnsoeframe one sends ED if instance, receive For not ( does frames. elapse. days it sent four if of least react elapse number at to hour, may xed supposed per weeks a even is after or ED frame days if downlink rate, even low a noticed, a is at in abnormal measurement anomaly its something an sends before detects regularly ED server to If the be data. unless may collected response sensor the a a expecting say, without of, measurements behaviour some usual send The network. LoRaWAN a of operating to. Impact. sent is it ED the of key master the with protected is The message collect later. it to anytime message ammunition” 3.3.1.1 Request “desynchronisation Section Join these in the use described to and procedure response messages the Accept actual use Join an can several is attacker it verify the if to Moreover nor means replay, sent. no a just has is ED message indeed the protocol: LoRaWAN if the neither of peculiarities the to thanks message attack. the achieve to used Technique 3.6). Figure (see parameters security and keys session dierent likely compute message NS replayed and This message. message. Accept Request Join an Join eavesdropped contains ED’s the to replays and response NS in before NS by sent message Accept Join a on eavesdrop network. Attack. the from “disconnected” be is will NS, NS with by communicate sent to frames unable NS the ED, by Conversely, Thus dropped ED. perspective. be by server will discarded the frames not from those does invalid However This are server. though. they the frames since by protected computed sending from those ED than (say keys forbid NS session by dierent sent computes actually eventually those it from protected dierent transmitting values start uses and ED keys if session derivation, the key the derive In can it frames. message Accept Join (valid) a conversely. and points. Key NS, by ignored (ED are NS ED with by keys sent session frames new the the Therefore sharing “partner”). not no ED has with ends which exchange key successful Goal. A3) (Attack End-device the Targeting 3.3.2.1 from NS and ED replay precluding message lastingly single at a aims as which little describe, as we on communicating. scenarios based two attack, the of of kind one another in present we section, this In Desynchronisation 3.3.2 1.0 LoRaWAN against Attacks 3.3 rnd E rnd , hsatc isa dsoncig Dfo h ewr.Ta sE efrsa performs ED is That network. the from ED “disconnecting” at aims attack This nodrt efr uhadsnhoiainatc,a takrcns passively rst can attacker an attack, desynchronisation a such perform to order In uhadsnhoiainatc a ehrflbcuei a atnl itr the disturb lastingly can it because harmful be may attack desynchronisation a Such N rnd ( = ) h eso esaecmue,b ie DadN,wt w ttcparameters static two with NS, and ED given a by computed, are keys session The N x, ˜ = y ˜ y ) au ieetfo h rs n etb S( NS by sent one fresh the from dierent value nteoehn,and hand, one the on id rnd N ADR n h Dsmse key master ED’s the and , N _ ACK optdb S and NS, by computed _ LIMIT h takri bet elyapeiu onAccept Join previous a replay to able is attacker The ( rnd + ADR E rnd , _ ACK N rnd MK _ ( = ) DELAY E 1 yE) sso sE receives ED as soon As ED). by ,y x, ,adtovral parameters variable two and ), 4+3 96 = 32 + 64 = ) nteohrhand, other the on , rnd N = y .Hne ED Hence, ). or)may hours) y ˜ 6= 57 y ),

3 58 Chapter 3 Analysis of LoRaWAN

ED AttackerNS

Join Request (rnd =˜x) −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→E Join Accept (rnd =˜y) ←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−N . . Join Request (rnd = x) −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→E Join Accept (rnd =˜y) Join Accept (rnd = y) ←−−−−−−−−−−−−−−−−−−−−−N ←−−−−−−−−−−−−−−−−−−−−−N ˜e ˜e e e Kc , Ka ← KDF(MK1,x, y˜) Kc ,Ka ← KDF(MK1,x,y ) ul frame 0 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ Invalid frame dl frame 0 ←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− Invalid frame . . ul frame j −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ Invalid frame dl frame j ←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− Invalid frame

Figure 3.6 – Desynchronisation attack against ED prnrd ihteitne D(.. dnie ythe by identied (i.e., ED intended the with “partnered” hni osntrcieavldase rmN,te ti osbet icnetE neand once ED disconnect to possible is it then NS, from answer valid a receive not does it when the only keep and parameters security previous the drop can it then and keys, new the with hnN stores NS Then keys session New session. new a start to ED for waits She ( following. the do can attacker The ai onRqetmsae u ofae rtce ihayo h e optdsession computed new the of any with protected frames no but messages Request Join valid onRqetmsaet esr hti sntrjce yN.Hwvr h esg sprotected is message the However, NS. by rejected not is it that sure be to message Request Join pcainde o eadtesm eadn ED. regarding same the demand not does specication network. already back-end the has connect it to keep since unable will NS gets it by starts ED NS), discarded it Hence before continuously when message. message then message the Accept Accept is received Join Join which “false” valid request a a (same) receive sends the not attacker sending does the ED (e.g., if session case, new a a such in Indeed, all. for fresh (i.e., messages and keys ED. session and valid NS latest desynchronise the to keeps NS if generally, More m keys. session same the The share not server). the to new hence keys received, session not new computes (and server on eavesdropped previously she message and us computed latest Let the and parameters. one, security valid latest of the number keys: few session Let of a sets one. most two at only stores stores NS NS that that assume assume may We keys. protected frame valid ones. a new receives it until counters) NS. corresponding to the unknown (and and keys valid session time moment previous same the the (at at it is receiving message from the NS Therefore forbidding while collection). message, its a of such compute to ED targeted is message valid a such forge to attacker the for so sessions enough a start by to ED targeted the for that wait “forgets” to has server attacker the the that (i.e., list server’s the to the for wait, to received previously NS. of track with Request keys keep Join to session valid same a the NS share to longer replaying no in will succeeds ED attacker corresponding an the If message, keys. session new computes and Attack. conversely. and ED, by ignored are send may AS) (and NS frames being without the exchange Therefore key message). the completes NS case, that In network. the from ED given a necting Goal. A4) (Attack Server Network the Targeting 3.3.2.2 1.0 LoRaWAN against Attacks 3.3 seskeys hsatc sbsdo h blt o h takrt ahrmlil n e onRequest Join new and multiple gather to attacker the for ability the on based is attack This the keep must NS that states specication The up. take to challenge another has the attacker on The leans She message. Request Join fresh a uses attacker the following: the is trade-o A supposed is NS since rejected be may it message, Request Join previous a replays attacker the If e eso es h takrms edsuccessively send must attacker the keys, of sets new 7 seskeys hsi nrdcdi eso .. fteseicto n osntapa nvrin101 loteLoRaWAN the Also 1.0.1. version in appear not does and specication the of 1.0.2 version in introduced is This 32 btatetcto a optdwt h Dsmse key master ED’s the with computed tag authentication -bit h aekn fdsnhoiainatc a edn gis S iiga discon- at aiming NS, against done be can attack desynchronisation of kind same The seskey i +1 7 pnrcpino vld onRqetmsae Sgnrtsanew a generates NS message, Request Join (valid) a of reception Upon r hncmue.TeE stores ED The computed. then are ) e ti nla bu o Ssol eaei trcie ucsieyseveral successively receives it if behave should NS how about unclear is it Yet i +1 rnd eoeE ed rm,teatce meitl ed oN onRequest Join a NS to sends immediately attacker the frame, a sends ED Before . i seskeys etecret(ai)ssinky ue yE n St xhneframes). exchange to NS and ED by (used keys session (valid) current the be E rnd au nlddi h elydJi eus esg on ogrbelong longer no to message Request Join replayed the in included value E i and aus.Hwvri Dsnsaantesm onRqetmessage Request Join same the again sends ED if However values). rnd seskeys E seskeys rnd au) lentvl h takrmysn rn new brand a send may attacker the Alternatively value). i +2 E aus hsmasta h takrhst xet or expect, to has attacker the that means This values. i hl Dstores ED while +2 hc elc h nomdkeys unconrmed the replace which seskeys 2 − 32 . id i m +1 E e onRqetmsae norder in messages Request Join new nywieN trsboth stores NS while only seskeys aaee ihnteJi Request Join the within parameter MK i +1 1 ec DadN do NS and ED Hence . ec h probability the Hence . rnd seskeys seskeys N value i +1 59 i .

3 60 Chapter 3 Analysis of LoRaWAN

Technique used to achieve the attack. In order to get a new Join Request message the attacker can use the technique described in Section 3.3.1.1 aiming at compelling ED to generate multiple Join Request messages. The attacker can gather several such messages and use these anytime later as “desynchronisation ammunition”.

Impact. The consequences of this attack against NS are the same as the one against ED: the targeted ED is disconnected from the network. Unaware that NS does not share the same security parameters, it may keep sending uplink frames for quite a long time while NS is unable to process them. Conversely, the frames NS may send cannot be processed by ED.

3.3.3 Lack of Data Integrity (Attack A5) The LoRaWAN protocol aims at providing data condentiality and data integrity on the air interface, between ED and NS. However the data exchanged between NS and AS are only encrypted but not integrity protected since NS is the only one to own the key used to compute an authentication tag. Hence AS is not able to verify if a (encrypted) payload has been modied. The specication recommends to implement (at the application level) an integrity protection mechanism. Moreover the specication seems to imply that such a mechanism is in fact optional since “Network servers are considered as trusted” ([SLE+16], §6.1.4, p. 32). This is a bold statement. Firstly the threat may not come only from NS (even if it can also be dishonest or compromised). An attacker may target the link (and intermediary servers) between NS and AS. Secondly, it is obvious that encryption only does not provide data integrity, but it may even not be sucient to guarantee data condentiality due to the malleability of the operation mode (in particular in the LoRaWAN case with the counter mode).

Goal. The purpose of the attacker is either to modify or to decrypt an encrypted payload. The frame carrying the payload may be sent by ED to AS or sent in the converse direction. Contrary to the attacks described in Sections 3.3.1 and 3.3.2, the attacker here must be able to act on the link between NS and AS. For instance the attacker could target and try to intrude on a (not or poorly protected) MQTT server used to relay data between NS and AS [Lun17].

Attack on data integrity. Data encryption is done in counter mode, therefore it is possible to change the plaintext by ipping bits of the ciphertext. If the content of an encrypted payload or merely the format of the unencrypted content is known, the attacker can replace or alter the data with accuracy. For instance, if ED is a sensor the attacker could change the measurement (temperature, humidity, etc.) sent. If ED is a presence sensor, the attacker may change a (binary) value notifying an intrusion into the opposite value notifying that everything is quiet. If ED is an actuator, the attacker could change a command ordering to close a window into a command ordering to open it. The attacker could also truncate the encrypted payload in order to hide information to AS or ED. If the recipient is AS, it is not able to detect that the payload is modied since there is no authentication tag. If the recipient is ED, it is not able to detect the modication since the authentication tag is computed by NS after the attacker modies the frame (in fact ED will validate the frame).

Attack on data condentiality. The attacker may try to guess the plaintext corresponding to an encrypted frame as follows. She eavesdrops on a frame which payload is of the form c = k⊕m, where k is the keystream, and m the plaintext to recover. She makes a guess m0 regarding the nert rtcinbtenE n S ti osbet eev oho them. of both deceive to possible end-to-end is provide it not attacker AS, does an LoRaWAN and worst since ED However, the between protected, frames. protection duly delete integrity were to frames be application would the do If could server). MQTT an as such forge to it use can she AS. Then to totally). intended or above, payloads (partially described keystream encrypted attack corresponding oracle” the “command gets the also through she data decrypting frame. in the succeeds decrypt does to attacker AS order likely in NS, parameters by received veried the is uses counter and uplink it, the Since check not choice. her of ciphertext any forge authenticity. data the on veries counter. Attack ED reused because a only, carrying try frames downlink one the subsequent make On reject can will it). attacker and does the counter NS ED, frame (since is counter recipient frame the the if veries contrary, unlikely AS because counter), frame rst and learn to order attacker in the owns If she acting. correct. specimen before is such guess behaves, one her ED with how if experiments understand do to expected may AS) the she ED, or on targets ED rely kind (either may this recipient attacker Using the the completed. of AIES15], be behaviour CHVV03; likely [AP13; will attack command oracle” the “command and of correct be ( will correct decryption is the guess Hence the If ED). computes to attacker or The server AS). and ED by shared commands of message a chooses and plaintext, 3.7 Figure 1.0 LoRaWAN against Attacks 3.3 al . umrssteatcsw aefudaantLRWN1.0. LoRaWAN against found have we attacks the summarises 3.1 Table AS, and NS (between server intermediary some of protection of lack a to due not is attack This the If plaintext. corresponding the knows she if keystream the recover can attacker The payload encrypted same the (using tries several make can attacker the AS, is recipient the If End-device – nbe rva tak gis DadA,b modifying by AS, and ED against attacks trivial enables line) dashed red a with tako aaitgiy h ako aaitgiybtenN n S(outlined AS frames. and encrypted NS genuine between integrity data of lack The integrity. data on Attack Gateway u fteatce ucesi eoeigakeystream a recovering in succeeds attacker the If rmasto ai plctv esgs(.. rde list predened a (e.g., messages applicative valid of set a from m = Network Server m 0 then ) c 0 = c c 0 ⊕ = ( u MQTT Server c ⊕ ⊕ ( m m 0 = ) 0 ⊕ u c ) n sends and , ⊕ ( u Application ⊕ Server m = ) c k 0 t the (to tcan it k ⊕ 61 u .

3 62 Chapter 3 Analysis of LoRaWAN

Table 3.1 – Attacks against LoRaWAN 1.0. nja is the number of Join Accept messages usable by the attacker. njr is the number of Join Request messages usable by the attacker. m is the number of new session keys sets stored by NS.

Probability Attack Complexity Impact (# Join message) of success Replay or decrypt 216 Downlink frame replay. (A1) ' 1 (ED, Section 3.3.1.1) nja Uplink frame decryption. Replay or decrypt, Uplink frame replay. njr method 1 (NS, Sec- n ' Downlink frame decryp- jr 224 tion 3.3.1.2) tion. (A2) Replay or decrypt, Uplink frame replay. 13 1 method 2 (NS, Sec- ' 2 (njr + 1) Downlink frame decryp- 2 tion 3.3.1.2) tion. Desynchronisation (A3) 1 1 ED desynchronisation (ED, Section 3.3.2.1) Desynchronisation (A4) m 1 ED desynchronisation (NS, Section 3.3.2.2) Uplink frame replay, Data integrity (Sec- (A5) - 1 forgery, decryption. tion 3.3.3) Downlink frame forgery.

3.4 Recommendations for LoRaWAN 1.0

Hereinafter, we propose practical recommendations aiming at thwarting the attacks described in Section 3.3. Obviously, one could merely advise the replacement of the protocol with a more secure protocol. Yet, we take into account that there are already many deployed LoRaWAN networks. Hence, as an additional constraint, we aim at proposing improvements that can solve the issues as best as possible while at the same time remaining compliant with the specication, and keeping the interoperability between patched and unmodied equipment. All the attacks can be mitigated if both ED and NS are corrected. Otherwise, the attacks targeting an unmodied equipment remain possible.

3.4.1 Practical Implementation Against attack A5: implement end-to-end data integrity between ED and AS. This must be done at the application level. In addition, AS must not blindly trust NS and should verify every security parameter it receives. In particular, if AS receives the application session e key Ka from NS, it should verify that the key is fresh (not reused). Similarly AS must keep track of the frame counters (both uplink and downlink counters) in order to avoid frame replays.

Against attack A4: verify that the session keys are shared. We suggest to implement it in the following way. Straight after the key exchange is done, NS must send a so-called DevStatusReq command and verify (authentication tag) the DevStatusAns response from ED, or verify, if it comes earlier, the rst frame sent by ED. The lack of response must be read into this as an issue (ED or NS under attack). In addition NS must keep all sets of session keys from the last valid one up to the latest btenE,N n S.J scnetdt S n,psil,t S h Ssresremain servers AS The AS. to possibly, and, NS, to connected is JS JS). and NS ED, (between au nodrt eetareplay. a detect to order in value evr(S,trigteoiia -at rtcl(ewe DadN)it -at protocol 3-party a into NS) Join and called ED entity (between third protocol a 2-party also and original 1.0 introduces the version It turning replacing release. (JS), at previous Server aims this It to [Sor17]. corrections 2017 providing in at published been has 1.1 version LoRaWAN Architecture 3.5.1 1.1 LoRaWAN Protocol 3.5 maintained. the Nonetheless, 1.1. Version back-end the connect to all. unable for message being and Accept up once Join ends blocked invalid ED and an Eventually, network, responding messages). by Request (simply Join values its counter to possible to According all use A4). the to and if ED A2 Indeed, attacks hazardous. enables (which is this messages us, Request Join of replay a preventing application transport also can message conrmation key the Yet, data. ED). (by recommen- done Two is [LoR18b]. conrmation the published recommending ours: been document to has A correspond 1.0 LoRaWAN 3.3. dations in Section implemented in be described attacks to the changes of informed been has cation, 1.0. Version Specications LoRaWAN the in Changes 3.4.2 the However DM04]. [Blo70; lters Bloom as such rnd techniques ecient memory of and replay tationally a ED. detect per sessions A1: of attack Against number the lower articially to not order in ED each for used the produce to the NwkAddr to corresponds Let message way. Accept following Join message. received Request one. the valid Join that last sent verify the then A3: becomes attack set This Against keeps NS others. then the sets, all unapproved drops keys yet and the the only If of keys latest. one session the to of from belong set starting tag this keys, authentication all the with with tag match authentication that the checks a it (carrying frame), frame uplink uplink an receives NS When one. computed 1.1 LoRaWAN Protocol 3.5 gis takA:generate A2: attack Against utemr,edt-n aaitgiybtenE n Srmisunenforced. remains AS and ED between integrity data end-to-end Furthermore, the turn to also recommends document The lentvl,E a efr eso e omto ihNS. with conrmation key session a perform can ED Alternatively, N aaee en undit one,i seog o Dt tr h atreceived last the store to ED for enough is it counter, a into turned being parameter = H rnd speetdi eto .,ti eso iesfo eso . nsvrlways. several in 1.0 version from diers version this 3.5, Section in presented As oaAlac,i hreo eeoigadpooigteLRWNspeci- LoRaWAN the promoting and developing of charge in Alliance, LoRa ( rnd rnd N E NwkAddr aus h one utntoelp n n ieetcutrms be must counter dierent one and overlap, not must counter The values. N rnd , one,adtessinkycnrain(oeb D aebeen have ED) by (done conrmation key session the and counter, N id , rnd E ercmedt opt the compute to recommend We eteleast the be rnd ) rnd where N N auswt orepetition. no with values E aaee stre noacutr n eso key session a and counter, a into turned is parameter one osntoelp hna takrcncompel can attacker an then overlap, not does counter rnd H sacliinrssatfunction. collision-resistant a is N 25 values. rnd inatbits. signicant E aaee noacutr hsam at aims This counter. a into parameter tmyb mlmne sn compu- using implemented be may It DevStatusAns DevAddr NwkAddr one utb used be must counter A epne ranother or response, aaee nthe in parameter scmue as computed is rnd 63 N

3 64 Chapter 3 Analysis of LoRaWAN present in the architecture. The role of the latter servers, as in version 1.0, is merely to use the session key computed by the other entities, and to exchange encrypted frames with ED. Figure 3.8 depicts the architecture of a typical LoRaWAN network in version 1.1.

Network Join Application End-device Gateway Server Server Server

i1 i2 data integrity (Kc , Kc )

e data condentiality (Ka)

Figure 3.8 – LoRaWAN network in version 1.1. Data exchanged between ED and NS are e e encrypted with Kc . Data exchanged between ED and AS are encrypted with Ka.

LoRaWAN 1.1 oers three sub-protocols to establish a session, called Join procedure, Rejoin type 1 procedure, and Rejoin type 0/2 procedure. The Join procedure is the standard way to start a session (it inherits from version 1.0). The Rejoin type 1 procedure is an “emergency” method aiming at reconnecting ED in case of total loss of the cryptographic context by NS. The Rejoin type 0/2 procedure is mainly used to change the radio parameters, even if it may also be used to update the session keys. In the remaining of this chapter we consider the method likely the most used to execute the protocol, that is the Join procedure.

3.5.2 Authentication and Key Exchange LoRaWAN 1.1 is a protocol based on shared (static) master keys. Each ED stores two distinct 128-bit master keys: a communication key MK1, and an application key MK2, and JS owns the list of all the master keys. All the cryptographic operations are based on the AES block cipher. Initiated only by ED, the key exchange is made of four main messages. The rst two (Join Request and Join Accept) are used to mutually authenticate ED and JS, and to share the data used to compute the 128-bit session keys. The other two (RekeyInd and RekeyConf) are used to validate the session keys. Figure 3.9 depicts a session establishment in version 1.1. The Join Request message sent by ED carries three main parameters: JS’ identier idJ (64 bits), ED’s identier idE (64 bits), the current ED’s counter cntE (16 bits). These parameters are protected with a 32-bit MAC tag computed with AES-CMAC keyed with the master key MK1. For the sake of clarity, we slightly simplify the formulas and do not make appear the with a with with knt h iihdmsae nTS hs esgs rtce ihtessinky,aeused are keys, session the with protected messages, these TLS, in messages Finished the to Akin The h eso keys session The counters The the with encrypted are message Accept Join the in carried data The ( eie h A a,adcmue onAcp epne hsmsaecrisacounter a carries message This response. Accept Join a computes and tag, MAC the veries tag MAC the in involved and sent also is (which type message’s the to corresponding value h pcain,o oN i uhacase a such (in NS to or specication), the protocol). secure allegedly but keys session counters, two these From to initialised Computation Keys Session 3.5.3 phase. These exchange key response. the RekeyConf conclude channel). a to secure the sends through NS sent (i.e., turn, messages In post-accept other context. any as security computed its are messages of NS, by change, the the and tag MAC 3.3.1.1). Section in shown as ECB to subject is 1.0, LoRaWAN protocol, the of version previous the id protected is message key The [Sor17]. specication the to reader interested the refer and description JS the turn, Since In JS. to message the forwards and ED), the that that from received checks value NS last message, the Request than greater Join the of reception Upon computation). 1.1 LoRaWAN Protocol 3.5 24 J nodrt aiaetessinky,E ed pca esg aldRkyn httriggers that RekeyInd called message special a sends ED keys, session the validate to order In is,N’identier NS’ bits), etb D hsam tfridn elyo rvosJi cetmsae oE (which ED to messages Accept Join previous of replay a forbidding at aims This ED. by sent MK KDF oe n h atrkey master the and mode, CMAC 1 mk prms n Dsidentier ED’s and ucincrepnsto corresponds function K 0 a optdudra(ttc atrkey master (static) a under computed tag cnt c n oooial nrae rsetvl yE n S tec e session. new each at JS) and ED by (respectively increased monotonically and i 1 aaeesaentrlvn otermiigo hscatr esi their skip we chapter, this of remaining the to relevant not are parameters , K cnt E K KDF c i 1 MK c and i 2 , J onAccept Join , K K K counter. K mk τ id c i J c a 3 cnt 2 i e id c e 1 N ( , and , k ,x K, K J K = = ( J n h atrkeys master the and , 24 c e τ id onRequest Join c i sn uigtekyecag)aeuiu e D hyare They ED. per unique are exchange) key the during (sent E K 2 r ie yJ oN truha nendb h specication the by undened an (through NS to JS by given are MK = ) k K E is,adohrparameters other and bits), MAC KDF a = e K h A a novsi diinteparameters the addition in involves tag MAC The . = a e sgvnb Sete oA truhapooo nendby undened protocol a (through AS to either JS by given is : c e MAC AES 1 AES neE eevsteJi cetmsae tvrsthe veries it message, Accept Join the receives ED Once . mk ( = = MK ( ( ( MK − K K, MK 1 KDF KDF a = e 3 ( id , MK 0x06 secytdwt e needn fLoRaWAN, of independent key a with encrypted is 1 id 1 id , id , J c a J ( ( k 1 k MK MK MK k E cnt cnt , id J x ) k k . E id E 0x00000000000000 MK k 1 1 2 J k cnt , , E cnt cnt , k cnt MK k id cnt 3 E N hc sdrvdfo Dsmaster ED’s from derived is which , J J J k prms k k k 2 k E τ DadJ opt four compute JS and ED , id prms id id E ) . N J J k k k AES cnt sc srdoparameters). radio as (such cnt prms cnt k τ J E E E ) ) erpinfnto in function decryption ) ) one svld(i.e., valid is counter ) . cnt 128 E cnt and -bit 65 J

3 66 Chapter 3 Analysis of LoRaWAN

ED NS JS (MK1, MK2)(MK1, MK2)

←−−−−−−−−−−−→mutual auth.

cntE ← cntE + 1 τE ← MAC(MK1, idJ kidEkcntE) Join Request ← idJ kidEkcntEkτE Join Request −−−−−−−−−−−−−→

Verify cntE Join Request ======⇒

Verify τE cntJ ← cntJ + 1 MK3 ← KDFmk(MK1, idE) τJ ← MAC(MK3, idJ kcntEkcntJ kidN kprms) −1 Join Accept ← AES (MK1, cntJ kidN kprmskτJ ) e i1 i2 Kc kKc kKc ← KDFc(MK1, cntJ kidJ kcntE) e Ka ← KDFa(MK2, cntJ kidJ kcntE) Join Accept Join Accept ←−−−−−−−−−−−−− ⇐======Ke, Ki1 , Ki2 , Ke ⇐======c c c a

cntJ kidN kprmskτJ ← AES(MK1, Join Accept) MK3 ← KDFmk(MK1, idE) Verify τJ and cntJ e i1 i2 Kc kKc kKc ← KDFc(MK1, cntJ kidJ kcntE) e Ka ← KDFa(MK2, cntJ kidJ kcntE) Compute RekeyInd RekeyInd ======⇒ Verify RekeyInd Compute RekeyConf RekeyConf ⇐======Verify RekeyConf post-accept phase ⇐======⇒

Figure 3.9 – Correct execution of LoRaWAN 1.1. Double line arrows indicate the use of secure channel keys. There are two secure channels: ED-NS (LoRaWAN), and NS-JS (additional protocol).

only known to JS and AS [Yeg17]). The KDFc function, on input a key K and a value x, outputs n nend–pooo ogaatedt nert ewe SadA) h messages The AS). and NS between integrity data guarantee to protocol – undened and – where with AES AES h function The ota on,E a edpoetdmsae otentok h esgsaeecytdwith encrypted are messages The network. the to messages protected send can ED point, that To ti noe eidclybsdo rde rqec,wihmasta ti o available not is it procedure, that 1 means type which frequency, Rejoin predened the for a will. As on (because at ongoing based channel). is periodically secure session current invoked a the is if through it only sent available is is request procedure rst 0/2 the type Rejoin the However session network. new dures). the a from initiate “disconnected” to good) unable for be not to (if ED lastly brings which be exhausted, and be can counters short such points. Key Counters the of Size allows 3.6.1 still version last this network. of LoRaWAN a been peculiarities of have some security 1.0 Nonetheless, the LoRaWAN impairing against 1.1. attacks version practical with likely corrected to lead that vulnerabilities Several MAC key the uses function MAC a the on direction, based downlink are the which direction) the of on version (depending tweaked functions dierent two with MAC-ed are dierent a use NS and AS direction, downlink the In direction. counter. header uplink frame the the of in part used type, is frame counter the of irrespectively with addition, encrypted In is AS. and ED between exchanged Channel Secure 3.5.4 values three following the 1.1 LoRaWAN in Vulnerabilities 3.6 . unrblte nLRWN1.1 LoRaWAN in Vulnerabilities 3.6 hr r w te ehd htalwE oiiit eso tes-aldRji proce- Rejoin so-called (the session a initiate to ED allow that methods other two are There 1.0: version in as same the is frame encrypted an of format The additional an upon relies (and NS and ED between only integrity data provides LoRaWAN - - K CMAC CTR k MAC endas dened c e n xhne ewe DadN.An NS. and ED between exchanged and and b hc upti rnae to truncated is output which KDF orsod otedwln A ucinwihotu stuctdto truncated is output which function MAC downlink the to corresponds h counters The K c e K a or c e sde as dened is AES MAC he ieetfaecutr r sd hyare They used. are counters frame dierent Three . K a e - CMAC KDF k eedn ntemsaetp.A type. message the on depending    ( K cnt K K K c i a 1 K , ( c c c e i i E 2 1 ,x K, aboki re oteipt,adotu a output and input), the to prexed is block (a , c cnt i 2 = = = x , = ) J = ) AES AES AES r respectively are hdr AES 32 MAC k ( ( ( is nteuln ieto,tefnto sdis used function the direction, uplink the In bits. ctext K, K, K, ( K, plcto message application 0x04 0x03 0x01 b ( 0x02 K k τ c i . 1 k k k x , x x x k k k k x 16 ) 0x0000 0x0000 0x0000 k k K btand -bit MAC 0x0000 c i 1 n orsod o(tweaked) to corresponds and , omn message command b ( ) ) ) K ) 24 . c i secytdwith encrypted is 2 btln.I slkl that likely is It long. -bit x , 32 ) btec.Oeframe One each. -bit 32 sencrypted is bttg In tag. -bit K 16 a e bits. and 67

3 68 Chapter 3 Analysis of LoRaWAN

Technique 1. The specication states that if the cntE counter wraps around, then ED must use a dierent idJ value (parameter used in the Join Request and Join Accept messages, and in the session keys computation). In fact, idJ kcntE behaves as a counter where idJ corresponds to the most signicant bits, and cntE to the least signicant bits. Therefore it may not be enough to exhaust the cntE counter in order to stuck ED. However, we do think that, due to lack of clarity of the specication regarding the rationale in storing more than one idJ value into ED, and the fact that LoRaWAN 1.1 inherits from the previous version of the protocol, it is likely that only one idJ value be stored into ED (as in the previous version, where cntE is a pseudo-random value). Moreover it has been shown in Section 3.3.1.1 that it is possible to compel ED to repeatedly send Join Request messages, hence to likely use all the cntE values. Therefore exhausting ED’s counter appears feasible. Assuming that ED sends one Join Request message every 5 seconds [Wor], the duration of 16 this attack is 2 × 5 seconds ' 91 hours. Note that, if ED stores k samples of idJ values, the duration of the attack is k × 91 hours. The only remaining possibility in order for ED to connect the back-end network is the Rejoin type 1 procedure. This is an “emergency” procedure aiming at reconnecting ED in case of total loss of the cryptographic context by NS, and the latter is not compelled to respond to a Rejoin type 1 Request (especially if NS did not lose this context).

Technique 2. Now, let us assume that ED stores several idJ values. Then the attacker can target the cntJ counter. As said above, the attacker can compel ED in repeatedly sending Join Request messages. Each Join Request message triggers a new Join Accept response, hence consumes a new cntJ value. Yet, cntJ is 24-bit long, whereas cntE is 16-bit long. Therefore, in order for ED to send as many Join Request messages as possible cntJ values, ED must store 24 16 a number of idJ values equal to |cntJ |/|cntE| = 2 /2 = 256. The duration of this attack is 224 × 5 seconds = 2.66 years. This is a very long attack, yet less than the expected lifespan of ED (up to 10 years), and it ends up with ED being possibly unable to connect the back-end network ever again.

3.6.2 Size of the MAC Tags

As in version 1.0, the MAC’s output is 32-bit long in LoRaWAN 1.1. Hence, MAC forgeries are worth considering, and, in combination with the fact that data encryption is done in CTR mode, so are attacks against data integrity. The duration of such forgeries is higher if the attacker acts on the air interface (in particular if she targets ED) than if she is able to act in the back-end network.

3.6.3 Known Encryption Keystream

Key points. Per specication, ED must send a (encrypted) RekeyInd message as long as it does not receive a RekeyConf response (up to a xed number of RekeyInd messages, afterwards ED must start a new session). Conversely, NS must respond to each RekeyInd message with a (encrypted) RekeyConf response. The (plaintext) content of both kind of messages is known (static value described in the specication). Hence, an attacker can get multiple valid encryption keystreams for free. If she succeeds in forging a valid MAC tag, then she can get messages carrying the plaintext of her choice. Of course, simple encryption does not provide data integrity, and the attacker needs to forge a valid MAC tag. However this provides a way to compute encrypted messages which underlying plaintext is semantically correct. a pligta eso) h a edi oteugae D hnE cet h message the accepts ED Then ED. upgraded the to it send can she version), that applying was DPrmeuRq uyylRq hs omnsaeitne oE.ADRParamSetupReq ED. to intended are commands These DutyCycleReq. ADRParamSetupReq, hrfr,acretdpomn fLRWN11myihrttew ftepeiu version. previous the of aws the inherit may 1.1 LoRaWAN of deployment current a Therefore, a gets attacker successful a Therefore, multiple with respond to NS compels This ED). from messages RekeyInd the receives (which eso .,te eea tak r osbeaantte(prdd ED. (upgraded) the against already possible are is attacks ED several Since then NS). 1.1, as version well (as 1.1 version to upgraded is it point some At 1.0. version may 1.1 version in ED an even Hence, 1.0. version implementing NS an faces it when 1.0 version nbe h rpa rdcyt takaantE seScin3311.Ide,terueof reuse the Indeed, 3.3.1.1). Section (see ED against attack decrypt” or “replay the enables Impact. identier same the keep ED that possible is it side, back-end id the on registered and provisioned 2. Scenario 1.0. version attacker to NS back (when an falls 1.0 If version and 1.1. with LoRaWAN accordance execute in NS computed and message ED Accept Both Join a 1.1. on version eavesdropped to upgraded is NS point, 1. Scenario 3.3). Section (see 1.0 LoRaWAN against possible shown been have that attacks the to succumb points. Key Attack Downgrade 3.6.4 NS. or be ED also target could to which attacker commands, the proprietary by the exploited dening exhaust frames). allows passively Request specication to Join 1.1 is way LoRaWAN the a DutyCycleReq (including the is frames attacks. rate uplink this the subsequent of increasing favour rate Hence, to transmission order the in change value to used highest its at the parameter of this value the change to used is other encrypt Impact. new a attacker the to provides which exchange, key new of a batch initiate must it limit, between this reaches disposal that her demand at China) has Europe, attacker USA, (e.g., areas geographical several in remaining the use can attack. and the session) mount the to message continue order RekeyConf to in rst ED messages the for sends order She (in messages. ED these to all collects adversary The messages. tag). MAC other valid the a use compute then (i.e., can message adversary valid The a forge keys). RekeyInd to session rst new try the the to lets uses messages (and to NS messages ED that these compels so all This NS collects NS. reach adversary by The sent messages messages. RekeyConf multiple the send discard or messages, RekeyInd the used. Technique 1.1 LoRaWAN in Vulnerabilities 3.6 E h parameter The NS by sent message RekeyConf the receiving from ED forbid can adversary the Similarly, f nadto,tesm atrkyue nvrin10i sda the as used is 1.0 version in used key master same the addition, in If, . n esgsi h onikaduln directions. uplink and downlink the in messages h nrpe ala fteRkyn n eeCn omnsis commands RekeyConf and RekeyInd the of payload encrypted The cnro1ealstedsnhoiainatc seScin3321.Seai 2 Scenario 3.3.2.1). Section (see attack desynchronisation the enables 1 Scenario 8 nti cnro Di eso . ae rtN nvrin10 hn tsome at Then, 1.0. version in NS rst faces 1.1 version in ED scenario, this In nti cnro Di eso . sdpoe,adcmuiae ihN in NS with communicates and deployed, is 1.0 version in ED scenario, this In codn oteseicto,a Dipeetn eso . utfl akto back fall must 1.1 version implementing ED an specication, the to According btln omns h olwn omnscnb fitrs oteattacker: the to interest of be can commands following The commands. long -bit n = nodrt olc h esras h takrcnfri Sfo receiving from NS forbid can attacker the keystreams, the collect to order In ADR _ ACK _ LIMIT n = 64 8 ADR sa most at is btecyto esra.Teatce a s tto it use can attacker The keystream. encryption -bit and _ ACK 2 15 _ LIMIT 2 rms(nete ieto) e,we ED when Yet, direction). either (in frames 15 oehls,tedfutstig [Wor] settings default the Nonetheless, . aaee.Teatce a hnset then can attacker The parameter. 16 -bit cnt n E 64 = MK one.Moreover, counter. n hrfr,the Therefore, . − 1 atrkyin key master 1 RekeyConf 8 btlong. -bit n − 69 1

3 70 Chapter 3 Analysis of LoRaWAN session keys and encryption keystreams can be obtained when the 16-bit monotonically increasing counter cntE that ED uses in version 1.1 meets same values as the 16-bit pseudo-random parameter rndE used by ED in version 1.0. Moreover the desynchronisation attack is also possible with scenario 2. It may be possible that, when executing version 1.0, ED implements also the recommendations published by LoRa Alliance [LoR18b] which aim at strengthening the security of version 1.0. With respect to the desynchronistion attack, this document recommends that ED initiate a new key exchange if it does not receive a response from the back-end network after ADR_ACK_LIMIT uplink frames. We observe that, even in such a case, the desynchronisation attack can be detrimental to the network availability. Indeed the regular behaviour of ED may imply sending one frame per hour or even per day. Since ADR_ACK_LIMIT = 64, several days or weeks may elapse without the back-end network being able to communicate with ED. Likewise, all the data sent meanwhile by ED will be lost, and unusable by the network. With respect to scenario 2, if ED enhances version 1.0 with the LoRa Alliance recommendations then the “replay or decrypt” attack (see Section 3.3.1) is mitigated, because in such a case the pseudo-random values involved in the session key derivation are replaced with monotonically increasing counters.

3.6.5 Lack of Data integrity Key points. There is no end-to-end data integrity provided by LoRaWAN between ED and AS. The specication demands data integrity be guaranteed by an additional (and undened) protocol between NS and AS. At the same time, a companion document [Yeg17] demands that data integrity (and other security properties such as data condentiality and mutual authentication) be ensured hop by hop between the components of a LoRaWAN network. Managing data security in such an hop-by-hop fashion is hazardous because it does not take into account the intermediate servers between NS and AS. Handing down security properties that is, according to us, incumbent upon the LoRaWAN protocol may lead to security breaches, as some of these servers (such as a MQTT server) have been shown to be insecurely managed [Lun17].

Impact. An attacker that succeeds in accessing a weak point between NS and AS can exploit the lack of data integrity in a LoRaWAN application frame, and alter or truncate the frame. It may also be possible to break data condentiality by applying a kind of “message oracle attack” (see Section 3.3.3). The attacker rst makes a guess regarding the plaintext data encrypted in some message. She replaces the alleged message with a (per specication dened) LoRaWAN command. Based on the behaviour of AS (it may apply the commands chosen by the attacker, or reject the message), the attacker learns if her guess is correct (hence deduce the plaintext data).8

3.6.6 Reuse of an Application Session Key

e Key points. The session key Ka used by AS to encrypt application messages is either sent by JS to AS (through a protocol undened by the specication), or sent by JS to NS (which e relays it to AS with the corresponding encrypted application frame). In the latter case, Ka is encrypted with a key known only to JS and AS. The LoRaWAN specication does not make e clear the properties of the security scheme used to wrap Ka. We observe that if this scheme does not provide non-replayability of the messages, then it may be possible to compel AS to e reuse a previous application session key Ka. 8Rupprecht, Kohls, Holz, and Pöpper [RKHP19] have shown (though in another context) the consequences of the combination of encryption in CTR mode and lack of data integrity. with. owns AS that assume us Let observation. following the provide we communication the that claims [Sor17] 1.1 version specication the time, same the At ED. with the with nitreir evro S.Orproei o oeaoaeo h iclyo achieving of diculty the on elaborate to not is purpose Our NS). or server intermediary an communicate to later allowed time legitimately some is them it use AS any to against order attacker so in act the frames can frame, these NS application store malicious The and an ED. interface) encrypt against air to the key on session (e.g., future collect a can uses AS If decryption. frame Impact. also chooses NS that Recall AS keys. compel session and application values, future of or pair current the any past, choose use can and NS compute corrupted to or malicious a parameters), these of used. Technique parameters AS to send relaying to of order key charge in encrypted in the be (e.g., also JS may from NS received specication, per Nonetheless, JS. from cnt key session application the key, surrendering master from forbid application nor the allow Regarding provider. not communication does the specication to the given be may key master more. do possibly also can It keys 3.6.6. Section in described scenario the apply can JS from points. Key NS Corrupted or Malicious 3.6.7 decryption process. However decryption valid. the is of integrity output data since correct is it deems ED frame, that of reception [MWES06]. analysis statistical key through or in known, retrieved, is two completely message the or either of partially if combination be manner the can obvious to plaintexts an two equal Therefore the is Hence messages keystream. encrypted plaintexts. same two corresponding the the with of key, encrypted combination same are bitwise the counter, the with same protected the sessions) to distinct corresponding two and from to (each frames messages application dierent new two in back Indeed, send done to is these key encryption replay same Since can that attacker ED. uses the AS Hence Furthermore, anew. AS. valid to cryptographically messages become key this with ED one. previous a with AS) Impact. and ED between integrity application data corresponding end-to-end the of (and lack key the application to current due the frame, replace can she where AS and used. Technique 1.1 LoRaWAN in Vulnerabilities 3.6 h cnro ecie nScin .. n .. ml tign supin (intruding assumptions stringent imply 3.6.7 and 3.6.6 Sections in described scenarios The master application and communication the that states [Yeg17] specication companion A a with AS by encrypted then frame application The also. arises issue Another J DevAddr K eakoldethat acknowledge We . MK a e n neddt D sMCe yN wt h urn A eso e) Upon key). session MAC current the (with NS by MAC-ed is ED, to intended and , current 1 fA essaps key past a reuses AS If by encrypted messages previous the all key, session application past a reuses AS If and aaee hc sivle nteecyto esra ( keystream encryption the in involved is which parameter aiiu rcrutdN hc eevsteecytdapiainkeys application encrypted the receives which NS corrupted or malicious A MK cnt eso e ilsruhygrae ti nla o Dbhvswt the with behaves ED how unclear is It garbage. roughly yields key session J If h takrat nawal rtce nemdaypitbtenNS between point intermediary protected weakly a on acts attacker The 2 oAS. to utb trda Swihi hni hreo on h e exchange key the doing of charge in then is which JS at stored be must cnt K E a e hskyi optdfo h w aibeparameters variable two the from computed is key This . cnt and J cnt utb hce yJ.Hne Smyrcieta parameter that receive may AS Hence, JS. by checked be must K CTR a J e h takrcnrpa oA l rms n loattempt also and frames, old AS to replay can attacker the , r eevdb Sfo S(n fA osntke track keep not does AS if (and NS from AS by received are oe h takrcndcytapiainmessages. application decrypt can attacker the mode, K a e .Teeoe ti ocial htJ eyuo NS upon rely JS that conceivable is it Therefore, ). MK MK 2 e oA.Therefore AS. to key S 2 i n optsthe computes and computation. ) previous cnt session E and K 71 e a

3 72 Chapter 3 Analysis of LoRaWAN

idJ cntJ cntE

MK1 AES DevAddr fcnt § ¤ ¦ ¥

e Ka AES § ¤ ¦ ¥

e Figure 3.10 – Application session key derivation (Ka) and encryption keystream computation (Si) in LoRaWAN 1.1 the latter but rather to point out some issues left unattended in the specication due to its lack of clarity and the limited security perimeter it covers. That is, under the same scenario, and with the same capabilities (e.g., breaking into an MQTT or NS server), an attacker can be more detrimental to LoRaWAN 1.1 than to a state-of-the-art protocol. In particular, the LoRaWAN specication seemingly considers the protocol as involving two parties only (ED and the back-end network), and does not make clear the security properties it is supposed to guarantee, nor the powers of the adversary it aims at defending against. A third party reduces the security of a client-server type connection (as in LoRaWAN 1.0) by increasing the attack surface. Whereas a given ED is bound to a given JS, many NS servers may relay the data between an ED and its JS and AS. Thus the security of a whole network can be shattered by a malicious NS or the weakest NS which relays data back and forth between many ED and AS. In Chapter 5, we devise a security model that addresses the LoRaWAN protocol in its 3- party setting (ED, NS-AS co-localised, JS), and allows capturing the security properties it should guarantee. Then we use this security model in order to provide a security proof of a LoRaWAN1.1 protocol modied in order to mitigate the aforementioned aws.

3.7 Recommendations for LoRaWAN 1.1

In this section, we present several recommendations aiming at mitigating the attack scenarios described in Section 3.6. The recommendations take as most as possible into account the need to keep the interoperability between a patched equipment and an unmodied equipment.

R1 – Exhaustion of counter. Against the scenario described in Section 3.6.1 based on the size of the counters, we recommend that ED store enough idJ values such that exhausting counter cntE be not possible.

R2 – MAC tag forgery. Thwarting a MAC tag forgery (Section 3.6.2) is not possible without increasing the size of the tag. We recommend the latter even though this forbids two entities (patched and unmodied) from being able to communicate.

R3 – Known encryption keystream. In order to preclude the scenario described in Sec- tion 3.6.3, we recommend that ED and NS perform a proper session key conrmation prior to ehv rvddapeiedsrpino t ol t mlmnain h ehia means technical the implementation, its goal, its of description precise a provided have we accepted. been have they after or submission under were CF19] [AF18b; papers our while . olwn h oaAlac eomnain LR8] e,a niae nScin3.4.2, Section in indicated as Yet, [LoR18b]. recommendations Alliance LoRa the following 1.0 onRqetmsaei a sent. has it message Request Join nptnilipeetto rhrwr us n r ieyt escesu gis any against successful be to lean likely not are do 1.0. and weaknesses, LoRaWAN protocol bugs, implementing the and hardware equipment resistant to or equipment tamper due implementation a attacks, targeted using The potential the (e.g., Element). on to values Secure ED secret access a monitor protect as physical to to such a used ability module entail means the the as not from such do independent assumptions attacks are strong the on either Likewise lean targeting not NS. attacks do or described attacks have Our we NS. addition or In ED them consequences. of tangible each the for and and used, attacks new presented have We weaknesses. several from suers it that itself. (e.g., protocol LoRaWAN attacks the generic to and unrelated etc.) consid- attacks) storage, technical web keys with attacks, (secret deal hardware management reviews network the the of as Most such done. eration been have LoRaWAN on analyses Few 1.0 LoRaWAN On 3.8.1 published been have that 1.1 and 1.0 LoRaWAN on analyses independent recall we section this In Analyses Other 3.8 lters Bloom as such techniques can ecient DM04]. countermeasure memory [Blo70; This and NS). computationally from using received implemented (when encryption be key frame session a application in the counters of as and track the well counters, keep includes as must computation This AS key 3.6.7, decryption. session and application and 3.6.6 NS. the Sections in corrupted in used or described parameters malicious scenarios all & attack key the session thwart to application order an of Reuse – R6 of AS) (by track keeping and parties, implementing two is, counter. these That frame between 1.0. version the level for application as the way at same the integrity mitigated data be can 3.6.5) (Section AS and ED integrity. data of the Lack to – response R5 a indeed is receives as it way message same the that the verify message to Accept ED Join (see allows the counter This compute ED’s can 1.1. exhausting 1.0 version at version in aiming in attack NS Thirdly, the 1.0) 3.6.1). version Section modied version this execute (against can allows 1.1 this version rare in be ED should Secondly, circumstance versions. a both such when implement us, 1.0 likely to version will According to NS version. fallback since this to only refuse implementing must NS faces 1.1 it version in ED Firstly, countermeasures. distinct attack. Downgrade – R4 attack. the RekeyInd/RekeyConf of of extent number the reduced lower a to on order based in but applied, commands de- one be the can as 1.1 LoRaWAN procedure same in the scribed Alternatively, frame. command or application any transmitting Analyses Other 3.8 ncnrs oteewrs ehv rvdda xesv nlsso h rtcladshow and protocol the of analysis extensive an provided have we works, these to contrast In gis h takdsrbdi eto ..,w ugs three suggest we 3.6.4, Section in described attack the Against h takdet h ako n-oeddt nert between integrity data end-to-end of lack the to due attack The cnt E and cnt J h pikaddwln frame downlink and uplink the , ieie in Likewise, 73

3 74 Chapter 3 Analysis of LoRaWAN

Lifchitz [Lif16] notes that, since the rndE and rndN parameters are pseudo-random, a reuse is possible due to the birthday paradox. Hence, under the strong assumption that the rndE value is “forced” (i.e., ED controlled by an attacker), a keystream reuse happens with high probability p after 2 ln(2) × 11 × 224 ' 16,000 sessions, or 22 hours if a key exchange is done in 5 seconds. According to us, if both rndE and rndN values repeat, this leads to a session keys reuse. In order for a keystream to repeat, it is necessary for the DevAddr parameter to be reused as well. Moreover the gure of 22 hours corresponds to a continuous series of key exchanges without any intermediary application frame being sent. The purpose of such an attack is likely to manipulate (decrypt, replay) such frames. Therefore, the time needed to collect these frames must be taken into account, and, in all likelihood, the duration of this attack is higher. Furthermore it is unclear where the numbers come from. We may assume that NS keeps track of 10 rndE values, and the attacker uses 11 dierent Join Request messages, randomly choosing one at each try. However NS unlikely accepts every such message since the same message (hence the same rndE value) is picked after roughly 4 tries. Hence the number of sessions needed to get a reuse of both rndE and rndN values is higher than the provided number 16,000, as well as the duration of the attack. The number of 10 stored values seems also to be implementation specic. Yet we cannot claim this is the genuine purpose of [Lif16]. Lifchitz’s analysis is made on version 1R0 of the protocol [SLE+15] published in January 2015. We observe that this attack is unlikely successful against an NS implementing version 1.0.2 (the current 1.0 version) published in July 2016. Indeed, according to the specication, NS must receive a valid uplink frame protected by the new security parameters before dropping the current ones and using the new ones. The attack described by Lifchitz leads to the computation of the same session keys two dierent times. Yet, with high probability, these keys are fresh (i.e., never used previously by NS with a legitimate ED) because the attacker has no control on the rndN parameter. This means that the attacker has to forge a valid uplink frame if she wants to compel NS to use these keys. That is, the attacker must forge a valid 32-bit authentication tag. Lifchitz indicates also that an alternative way to attack ED is to replay to NS a previous Join Request message (because the server keeps track of a “certain number of [rndE]values”), leading to ED being disconnected from the network. Finally, Lifchitz observes that the encryption scheme does not hide the length of the plaintext which may help an attacker to deduce the underlying data.

Miller [Mil16b; Mil16a] proposes a denial of service attack against NS by ooding the server. He notes also the possibility to replay Join Request messages. Moreover, since the application frames are protected with a 32-bit authentication tag, forgery attempts may be tried mainly against NS, according to Miller.

Tomasin, Zulian, and Vangelista [TZV17] indicate that ED may be precluded from joining the network after a certain number of sessions, depending on the NS’ behaviour. This may happen either “naturally” (if NS keeps track of all received rndE values), or due to an attack (if NS decides to exclude ED which it repeatedly receives Join Request messages replays from – the frames being replayed sent by an attacker). We observe that if the rndE value repeats there is a more detrimental attack than a DoS, namely the “replay or decrypt” attack described in Section 3.3.1.1. Moreover Tomasin et al. recommend to use a 16-bit counter for rndE instead of a pseudo- random value, and to increment the counter only when a (valid) Join Accept message is received. This aims at ensuring that the rndE counter is shared by ED and NS. According to us, this is incorrect because it is possible to replay any Join Accept message. In addition, this recommen- hscnb oei h rm one rp rud codn oteato,telte may latter the author, the to According around. wraps counter frame the if done be can This reused) (i.e., ontmninaynvlatc rvleaiiycmae owa a enosre regarding observed been has what to compared vulnerability or attack novel any mention not do contribution this detail 5.4. We and protocol. 5.3 shed 3-party Sections to this 5, enables by Chapter that implied in approach requirements security security at provable the aiming a on used recommendations light have several we vulnerabilities proposed Finally, new latter. and described the 1.1, have mitigating LoRaWAN of we aspect of addition, 3-party security In new the version. the latest impairing analysis its our in in introduced addressed protocol have the we analyses, previous to contrast In 1.1 LoRaWAN On 3.8.2 that whereas believe NS latter by the received make been case. to has the ED acknowledged) not to be is on to it acknowledgement later (demanding an it frame such send uplink on and subsequent eavesdrop it, a can observes receiving attacker Yang from An Hence, ED. ED acknowledge. deceive forbid to to response, supposed used is be it can frame this uplink that the to related not is response counter in encryption the to (due payload encrypted the mode). modifying by plaintext us. the to modify according unlikely any seems discard attacks must such same NS of the specication, feasibility (with per the value and, Hence, However counter replay. counter. NS, frame frame frame targets session the attacker same same Yang’s of the the Moreover size twice always keys). the using uses session exceeds from ED that ED where frames forbids mode of specication ABP amount the an the sends of it case if the or (in keys), reset is ED if keytsream). happen encryption and counter, frame the (namely reused are parameters security some the compute to suggests specication the because strength, the rnd signal of distribution radio the the (hence on ED inuencing by produced output generator if bit only message Request exactly Join is a counters accepts two NS the If between counters. dierence the both between dierence Join the ED a greater Hence sends the message. it ED’s (when receiving ED from latter to its the respond increments forbidding can while she NS, messages, before Accept message) Join Request any replay easily can tacker NS). invalid by an discarded carry continuously they is since NS by discarded same then are the messages reuses the receiving these ED from does And Hence ED attacker NS. only) messages. The (once by Request 3.3.2.2. forbids sent Section she message in message, Accept described Request Join one Join the the a for as sends and kind ED once same when network the following: the of from is ED attack disconnecting This allows which all. attack another to leads dation Analyses Other 3.8 uu,Pria n iln BG8 aeatra nlsso oaA ..Terresults Their 1.1. LoRaWAN of analysis threat a make [BPG18] Gidlund and Pereira, Butun, in NS by sent frame the But frame. uplink an of reception the acknowledge to NS ask can to ED attacker an allows AS and NS between integrity data of lack the that also indicates Yang if frames decrypt to and frames previous replay to possible is it that observes [Yan17] Yang random the of distribution the make to possible is it that also show al. et Tomasin Finally, at- an Since ED. with synchronisation strict a keeps NS if happen also may issue Another 9 E oai cnweg u eak [Tom19]. remarks our acknowledge Tomasin ausfo ai measurements. radio from values rnd rnd E au.TeeoeE ssuksnei ep sn h same the using keeps it since stuck is ED Therefore value. E one hl Sde o.Temr h takrrpasti procedure this repeats attacker the more The not. does NS while counter 9 1 hnE’ esg slkl rejected. likely is message ED’s then rnd E rnd au nsbeun Join subsequent in value E rnd aus eit by deviate values) E au (which value 75

3 76 Chapter 3 Analysis of LoRaWAN the LoRaWAN 1.0 architecture. Among the few threats they consider relevant (the others being physically intruding an ED and deploying a rogue gateway), Butun et al. describe an attack aiming at exhausting the daily quota of frames ED can send, which is based on a technical limitation that they incorrectly attribute to LoRaWAN (citing another paper [AVTP+17] that mentions in fact Sigfox with respect to that limitation). They suggest several recommendations in order to improve the security of LoRaWAN 1.1 such as protecting the secret keys stored by ED in a tamper-resistant module (as recommended by the specication [Sor17]), using public-key cryptography in order to update the master keys, or replacing the cntE and cntJ parameters (used as input in the session keys derivation) with a nonce negociated during the key exchange (and to be used during the next key exchange). Seemingly, one nonce only, sent by ED, is used in that proposal. The goal seems to preclude a reuse of the nonce. NS keeps track of all received nonces, and discards any key exchange message carrying an reused value. The rationale behind Butun et al.’s proposal is unclear to us since the current cntE and cntJ parameters are monotonically increasing counters which are not supposed to wrap around (under the same session keys). In addition, in that proposal, the nonce must be updated after a successful key exchange. Therefore, a simple attack appears feasible. Upon reception of a RekeyInd command, NS deems that the key exchange is correct, and updates the nonce (in particular, the nonce used during the current key exchange is stored in the list of old nonces). Let us assume that an attacker forbids ED from receiving the RekeyConf command sent by NS. Then the key exchange is not successful from ED’s perspective. Hence, following Butun et al.’s proposal, it does not update the nonce, and uses the same nonce during the next key exchange. Yet this nonce is an old one for NS, which discards the Join Request message. Since ED does not receive a response from NS, it keeps using the same nonce (which is continuously rejected by NS). ED is then unable to reach the back-end network once and for all.

In LoRaWAN 1.1, the MAC tag of an uplink frame is computed with two session keys: the rst i1 i2 16 bits with Kc , the last 16 bits with Kc (cf. Section 3.5.4). This computation aims at allowing an intermediate NS (called forwarding NS) to verify an uplink frame in a roaming conguration. Consequently Stöhr [Stö17] devises the following attack scenario. If the attacker is able to know independently whether either 16-bit string of the MAC tag is correct, she can forge a valid MAC tag with at most 2 × 216 trials instead of 232. The attacker can lean on the behaviour of the back-end network to achieve her attack (e.g., the NS servers may return dierent error codes, or respond faster depending on the validity of the two pieces of the MAC tag). This scenario highlights that the size of the MAC tags may not be long enough in order to provide enough resistance against forgeries.

Dönmez and Nigussie [DN18b] investigate the possible vulnerabilities due to the fallback mechanism allowed in version 1.1. They consider the case when ED in version 1.1 faces NS in version 1.0 (and then switches back to version 1.0) and conclude, predictably, that the attacks against version 1.0 become possible anew. Yet they do not consider the case when the 16-bit monotonically increasing counter that ED uses in version 1.1 meets same values as the 16-bit pseudo-random parameter used by ED in version 1.0. They also investigate the case (not treated by the LoRaWAN specication) when ED in version 1.0 faces NS in version 1.1 (which is assumed by Dönmez and Nigussie to fall back to version 1.0), and come essentially to the same conclusion.

Dönmez and Nigussie [DN18a] consider the possibility to perform against LoRaWAN 1.1 (i.e., when both ED and NS implement that version) the attacks targeting version 1.0 (summarised in [DN18b]) and conclude they are not feasible. “ rpigaround. wrapping whole hsmasta Di obde neadfralfo ecigtebc-n ewr.Neither network. back-end the reaching from all for and once forbidden is ED that means This upon relies integrity data point, this at that, way the by means (which iuseakoldeta ehns iiga nuigsnhoiainrmist edened. be to remains synchronisation ensuring at aiming mechanism a that acknowledge Nigussie synchronisation essential this network. maintain back-end to the how and explain ED Nigussie between and exchange. Dönmez key nor subsequent Song any keys and perform the Kim to to unable respect remain with parties desynchronised both then case, are a parties replacement two such the The In triggers sent received. evolution. which messages message, not the that still is of other when keys, one the arises the of while issue of reception keys) An upon new exchange. follows the key party use the other to during the ready Then is mechanism keys. (it update current move this the rst rst holds that the the observe makes during We party keys keys. one master session that initial next computed implies the the newly (or perform the keys to with current Song keys exchange) the and key session replace Kim to current of then proposal the and the using exchange, apply in key to essentially suggest consists and latter keys), The symmetric [KS17]. master static on based is counter it JS’ without key, session a previous how 3.6.7 a reuse Section in to explain AS we compel by contrast, can sent In NS values this). corrupted) counter do (or the NS of malicious only track demands keep the to specication for JS (the counter recommend ED increasing Nigussie monotonically which and ED) this Dönmez from uses received derivation. faithfully (previously key ED the message value, Indeed Request counter ED. Join old not an any but carries JS AS to replay target can to NS allows malicious the this also that involves observe computation We keys session possible). if not frames) be application decrypt latter or the replay to possibility the counter (hence the reuse key session a suggest NS home the Eventually, tag). frame whole uplink the an verify of cannot tag MAC servers the these partially since least bits at verify serving to both able §12.2.1) be and may §11.3.1 NS (cf. [Yeg17] forwarding document and specication companion NS of the a clarity to and of according §6.1.2.3) lack Nonetheless, (cf. the point. [Sor17] acknowledge this We regarding incorrect. specication is 1.1 LoRaWAN this the us, to according Yet, frame. application serving session application the computing keeps AS) 1.1. (and version ED in on propose as eavesdrop they key mitigation, to a operator As the wrong. enabling is without data procedure payload JOIN application the the manage to operator network that claims key] specication master 1.1 [application LoRaWAN The 1.1. LoRaWAN in JS of communication existence which the the 1.0 layers: and version application scheme to the back and fall communication to the key ED protect master compel to can access only NS can key case, it one a key, uses such master AS). in communication and Indeed, the ED layer. owns (between application NS layer the when application that the note and Nigussie NS) and and Dönmez ED (between layer communication the Analyses Other 3.8 hnwrigwt 11NtokSre,teapiainssinkyi eie nyfo the from only derived is key session application the Server, Network v1.1 a with working when ial,Dne n iuseosreta h rtclde o rvd owr erc (as secrecy forward provide not does protocol the that observe Nigussie and Dönmez Finally, They NS. malicious a by enabled possibilities the investigate also Nigussie and Dönmez so-called (the servers NS intermediary of involvement the that claim Nigussie and Dönmez keys master two uses 1.1 LoRaWAN 10 ömzadNgsi cnweg u eak Dn9.RgrigKmadSn’ rpsl ömzand Dönmez proposal, Song’s and Kim Regarding [Dön19]. remarks our acknowledge Nigussie and Dönmez 32 and btMCtag. MAC -bit MK cnt forwarding J 1 aae yJ rp rud(ept h atta h pcaindemands specication the that fact the (despite around wraps JS by managed hrfr surrendering Therefore . S ewe Dadits and ED between NS) hrfr the therefore , [o1] 6113.Dne n iuseso htti statement this that show Nigussie and Dönmez §6.1.1.3). ([Sor17], ” cmuiainmse key] master [communication MK 10 MK 1 cnt and E 1 home oN eet h ups ftedouble-key the of purpose the defeats NS to one aae yE.I,i uhacs,a case, a such in If, ED. by managed counter MK 2 Setnstepsiiiyt le an alter to possibility the extends NS nodrt rporpial separate cryptographically to order in a esredrdt the to surrendered be may 16 isol nta of instead only bits should eiythe verify 32 77

3 78 Chapter 3 Analysis of LoRaWAN

Remark. In Chapter 6, we describe an authenticated key exchange protocol in the symmetric-key setting that provides forward secrecy, and explicitly deals with the synchronisation issue.

In turn, Han and Wang [HW18] propose that ED and JS update the LoRaWAN master keys prior to each new key exchange. Their proposal implies exchanging two additional messages during the key exchange phase. According to us, this proposal leads also to a synchronisation issue. One party (ED or JS) has to make the rst move (i.e., replacing its current master keys with the new ones). Then the other party does the same upon reception of some message sent during the key exchange phase. If this message is not received, then the parties are desynchronised with respect to their master keys. In such a case, they are unable to perform any subsequent key exchange. Han et al. do not deal with this issue, and leave it unsolved.

Eldefrawy, Butun, Pereira, and Gidlund [EBPG18] perform a formal security analysis of LoRaWAN 1.1 using the Scyther verication tool. They conclude to the absence of weaknesses in the protocol. Yet they acknowledge that there may still exist vulnerabilities not found due to the limitations of the model they employ. It could be advantageous to do an in-depth analysis with such a verication tool based on a more extensive model. 3

hssosta h taki ul rcia noreprmna etn.Gvnta ilosSIM billions that Given setting. experimental our in practical fully is attack the that shows This Contents the against attack successful rst the is this is knowledge, estimate, our to protocol. dicult of SCP02 although best cards, the aected To of high. number potentially the year, every produced are cards with done This experiments channel. secure protocol. the this within against attack protected oracle data retrieve padding eciently a to perform allows to exchange key attack how the show after and established SCP02, channel secure in the phase consider we chapter, this In 1.0. LoRaWAN cards. smart is of SCP02 industry GlobalPlatform, the by by promoted used protocols most symmetric-key the of likely set wider a Among tunnel. S h eut fti hpe aebe ulse n[AF18a]. in published been have chapter this of results The our of results the present we and setting, experimental an in attack the implemented have We in phase exchange key the weaken that aws exploit to how seen have we 3, Chapter In ie,nml mr ad.I sue ytasotcmais ntebnigwrdadby and world banking the in companies, transport by used is It cards. smart namely vices, oientokoeaos(ICSMcrs otasi estv aatruhasecure a through data sensitive transmit to cards) (UICC/SIM operators network mobile protocol symmetric-key a is CP02 . Countermeasures 4.5 . Introduction 4.1 . plcto oSCP02 to Application Attack Oracle Padding 4.4 Generic The Protocol 4.3 SCP02 The 4.2 .. xeietlRslso h opeeAttack Complete the of Results Experimental 4.4.4 .. Discussion Side-channel Timing the 4.4.3 Leveraging 4.4.2 .. iigSide-channel Timing 4.4.1 10 oeso mr ad rdcdb i ieetcr manufacturers. card dierent six by produced cards smart of models ...... nlsso SCP02 of Analysis ...... mlmne naseictp fcntandde- constrained of type specic a in implemented ...... 4 95 82 82 85 83 93 89 86 91

4 82 Chapter 4 Analysis of SCP02

4.1 Introduction

GlobalPlatform is an organisation that aims at dening technical mechanisms related to the chip technology (e.g., smart cards, application processors, SD cards, USB tokens, secure elements), used to securely add and remove applications, and related parameters, into the chips. This initiative aims also at facilitating the interoperable deployment and management of applications on these types of device, regardless of the manufacturer, as well as “promot[ing] a global infrastructure for smart card implementation across multiple industries” [Glo18]. Several Secure Channel Protocols (SCP) are specied by GlobalPlatform. Most of them are based on symmetric-key cryptography (e.g., SCP01, SCP02, SCP03, SCP81). Regarding the protocols status, SCP01 (based on the DES algorithm) is now deprecated. SCP02 (based on 3DES) is currently the most deployed symmetric-key based SCP protocol1, while the use of SCP03 (based on AES) seems to be less widespread.2 SCP02 is a protocol aiming at establishing a secure channel between a card and an “o- card entity”. The main purpose of the protocol (yet not the only one) is the management of a (remote) card. Through the secure channel established with SCP02, applets, les, secret data (e.g., encryption keys, PIN codes), etc., may be transmitted and stored into the card. According to GlobalPlatform, SCP02 is used by transport companies, in the banking world and by mobile network operators (UICC/SIM cards). According to GSMA [GSM19], in 2018 there are over 5 billion unique subscribers to mobile services, and 5.6 billion of SIM cards used worldwide as estimated by the SIMalliance [SIM18]. A typical usage of the SCP02 protocol is the management of a specic application storing user credentials (e.g., for payment or transport transactions) located in the UICC card that is plugged into a smartphone. Depending on the context, an additional security protocol (e.g., TLS [DR08] or SCP80 [ETS17]) may be used together with SCP02. For instance, in order for a remote server to send SCP02 commands to the UICC, a SCP02 channel is established between the remote server and the UICC through the intermediary of an application on the smartphone. In addition a second secure channel is established between the remote server and the application on the smartphone (e.g., with TLS or SCP80). This second security layer embeds the SCP02 commands sent by the server. The data exchanged between the server and the application are then protected with the two security layers, whereas the data exchanged between the application on the smartphone and the UICC are protected with SCP02 only.

4.2 The SCP02 Protocol

SCP02 aims at establishing a secure tunnel between an “o-card entity” and a card [Glo18]. For simplicity, we will use the term “server” to refer to the party involved in the communication with the card. SCP02 is based on symmetric-key algorithms. The card and the server share one or several sets of symmetric keys. A set is made of three keys (which value may be equal). From that set, session keys are computed each time a new channel is established. The card manages a sequence counter related to a given keyset. Its initial value is 0 and incremented after each successful session (established with that keyset). Once the sequence counter has reached its maximum value, the card must not start anymore a session with the corresponding keyset. Since the operations done during the key exchange phase are not signicant for the remainder of this chapter, we skip the corresponding description, and refer to the SCP02 specication [Glo18].

1Last release: March 2018 [Glo18]. 2Last release: July 2014 [Glo14]. h adn rceatc sbsdo h atta eiebhvsdrnl depending dierently behaves device a that fact the on based is attack oracle padding The header genuine (the a ebsdo h aueo h epne(rsneo bec ftersos,tp:e.g., type: response, the of absence or dierence (presence That response plaintext). the of of bytes nature or the bits on the some based behaviour, (e.g., be dierentiated information may that some From get data. to padding tries (encryption) attacker the of correctness the on Attack Oracle Padding Generic The 4.3 command encrypted the in carried tag the with it compares and tag MAC a recomputes card The command. decrypts previous the on computed tag MAC the to equal is ciphertext command next the for used to call one applying rst in a consists of multiple a is length data which string a a get [Int11]: to in order described in method added are the none) to according bytes of to string equal byte xed a with padded (always) is with done is are commands the that consider we chapter the of remainder tag. MAC-ed. the encryption MAC and data In a encrypted Moreover with integrity. allowed. protected data not and is is encrypted level are solely security card lowest the the by commands, sent the responses Regarding the and server the by Attack Oracle Padding Generic The 4.3 pnrcpino necytdcmad h adde h ees prtos is it First operations. reverse the does card the command, encrypted an of reception Upon The encryption Data command. a of computation MAC and encryption data the depicts 4.1 Figure sent commands the exchange, key the during negotiated level security the on Depending pad 8 iue4.1 Figure bt A tag MAC -byte MAC ctext ctext 3DES h S 771MCagrtm3 lokona rti A” sue It1.It [Int11]. used is MAC”, “retail as known also 3, algorithm MAC 9797-1 ISO The . 3DES 80 hni erhsfravldpdigdata padding valid a for searches it Then . z n h A tag MAC the and sapne otepanet hna aynl ye sncsay(possibly necessary as bytes null many as then plaintext, the to appended is h au ftes VfrteMCcmuaini usually is computation MAC the for IV rst the of value The . nrpinadMCcmuaino omn aawt SCP02 with data command a of computation MAC and Encryption – hdr in hdr hdr hdr hdr CBC IV 0 τ scmue ntecmadheader command the on computed is DES a ertivdfo h header the from retrieved be can ENC | oewt ulI It7.Pirt nrpinteplaintext the encryption to Prior [Int17]. IV null a with mode = - Kenc CBC 00 τ 8 ptext ptext ptext ptext - MAC eoete h aal ftesre’ command. server’s the of eld data the then become }| ¦ § ctext ctext ENC oteipt n hnaiigtecluainwith calculation the nalising then and input, the to {z ¥ ¤ pad pad Kcmac MAC IV ENC MAC { pad hdr } hdr ENC 0 fteecytdcommand). encrypted the of h litx,adapadding a and plaintext, the , ¦ § n eoe t ial,the Finally, it. removes and MAC τ τ DES ¥ ¤ lc [Int17]. block 00 8 h IV The . ptext 83

4 84 Chapter 4 Analysis of SCP02

“regular” or error message, value, etc.) or on the duration of the operations performed (or not) by the device. Regarding the symmetric-key encryption case, the whole decryption procedure usually includes (among other possible operations) the MAC verication, and the padding extraction and verication. It is commonly recommended to provide data authenticity and condentiality by applying the so-called Encrypt-then-MAC (EtM) paradigm [Kra01; BN08].3 Nonetheless some cryptographic mechanisms apply other methods (e.g., MAC-then-Encrypt in TLS 1.2 [DR08], Encrypt-and-MAC (E&M) in SSH [YL06c; YL06a; YL06d; YL06b]) but also in SCP02. Therefore, if a padding data is used during the encryption process, and the padding data must be, during the decryption procedure, veried prior to the MAC computation, then it may be possible to perform an attack aiming at retrieving sensitive data. If one follows the MtE or the E&M method (as in SCP02), the whole decryption procedure involves (usually) three main steps:

1. the evaluation of the decryption function on the encrypted data,

2. the extraction and verication of the padding data,

3. the computation of the MAC tag on the remaining decrypted data.

Once the ciphertext is decrypted, either the padding data is valid and can be removed, and the MAC computation can be done, or the padding data is invalid and the MAC tag cannot be computed (at least on the genuine data). Let us illustrate the attack with an example. For the sake of clarity, we use the specics of SCP02, namely the encryption function (and the corresponding block size), and the padding scheme. Let C be the last encrypted block carried in a protected command, and let V be the block used as IV during the encryption operation that yields C (V denotes either the null IV if the command carries one encrypted block only, or the previous encrypted block if the command carries two or more encrypted blocks). Let b0| · · · |b5 be 6-byte plaintext data corresponding to C. In SCP02, the encryption is done with 3DES in CBC mode. Since the plaintext length is smaller than 8 bytes a padding data is appended, and this yields B = b0| · · · |b5|80|00. The encryption process outputs

C = ENC(V ⊕ B)

= ENC((v0 ⊕ b0)| · · · |(v5 ⊕ b5)|(v6 ⊕ 80)|(v7 ⊕ 00))

Conversely the decryption operation outputs

−1 ENC (C) ⊕ V = (v0 ⊕ b0)| · · · |(v5 ⊕ b5)|(v6 ⊕ 80)|v7 ⊕

v0| · · · |v7

= b0| · · · |b5|80|00 = B

Let us consider an adversary who replaces V with V˜ . If the block V˜ is randomly generated, likely the decryption operation does not yield a valid padding data. If the block V˜ is carefully chosen by replacing the last two bytes of V v5|v6 with (v5 ⊕ g ⊕ 80)|(v6 ⊕ 80), where g is some

3Some encryption modes (e.g., [Nat04]), coupled with a security proof [Jon03], correspond to the MAC-then- Encrypt (MtE) paradigm. where the of malleability the on leans attack the see, can we with wihecyto ilsteblocks the yields encryption (which valid, j to 4.3 Section in presented attack oracle SCP02. padding of the case apply particular to the how explain we section, this In SCP02 to Application 4.4 in length until the nds one method rightmost (this the padding from valid starting a bytes yields all block min( testing modied by the search of is linear decryption complexity the a (which or dichotomous other [BU02] size), the any Urtubia block using as and found data the be padding Black can the by retrieve length proposed can padding attack the algorithm unknown, the If since necessary byte. plaintext not unknown is it Yet attack. the of blocks two of made is ciphertext the that blocks encrypted of pair each successively block targeted the within encrypted bytes get to order in pivot the all provides eventually procedure This not. or correct oracle ciphertext new byte plaintext the retrieving allows step, yields byte valid plaintext is the data of padding value the the if reveals knowing verication) padding the precisely, (more operation Obviously value the on depends this result following the yields decryption the then byte, SCP02 to Application 4.4 ≥ oeta h egho h adn shlflsnekoigti au hresteduration the shortens value this knowing since helpful is padding the of length the that Note that generality of loss without assume (we 4.1 Algorithm by described is attack overall The blocks dierent with process that Iterating example, our In valid. is data padding the if only and if correct is operation decryption The 4 0 ftepanett ereecrepnst oeta w blocks two than more to corresponds retrieve to plaintext the If • • If .Btti rr)cs ses omanage. to easy is case (rare) this But ). ,h d, ( 0 b If If v O C 5 i tews.Tersos rmteoal vnulyrvasi h takrsguess attacker’s the if reveals eventually oracle the from response The otherwise. b b ⊕ − hc h takrnest e cest.Teoal returns oracle The to. access get to needs attacker the which , ⊕ 5 5 1) + 1 g b ⊕ ⊕ g sthe is 5 ⊕ ⊕ g g ⊕ 80 tp where steps ⊕ ⊕ V 80 ˜ g = ENC k CBC 80 80 ⊕ ) C C 00 | ( 80 v 6= = sbitwt ieetvalues dierent with built is nldsa es n yeo adn,i.e., padding, of byte one least at includes hsmyas il ai adn i h rcdn erpe ye r qa to equal are bytes decrypted preceding the (if padding valid a yield also may this − i +1 V(qa to (equal IV 1 = 80 80 ( C ⊕ hntepdigdt s(iey invalid. (likely) is data padding the then , hntepdigdt svalid. is data padding the then , 80 b ) h 5 b ⊕ ⊕ i fadol if only and if stepdiglength). padding the is +1 V g ˜ ) where , ⊕ = ( = 00 80 C 0 8 : , b v ⊕ nSP2.I h eane fti hpe eassume we chapter this of remainder the In SCP02). in . . . v 0 0 b V | · · · | 0 | · · · | b ( i b i , C +1 ⊕ b , o ahbyte each For . 5 C 5 C k C . = − b k stepanetbt on uigteprevious the during found byte plaintext the is . b . 0 − v 2 V 4 ) ˜ 4 C , g 1 | · · · | | | ,teatce ple loih . yusing by 4.1 Algorithm applies attacker the ), nohrwrs h euto h decryption the of result the words, other In . ( ( g rdcdb elcn successively replacing by produced b v k n ahrsligcpetx ssn oan to sent is ciphertext resulting each and , 5 5 − ⊕ 1 ⊕ ( ) v , g CBC g 5 ( ⊕ C ⊕ ⊕ n k b 80 b − 80 i 6 = oe n ssteblock the uses and mode, 5 3 h takrwnst eree a retrieve, to wants attacker the ) ) C , ) | 80 | ( | 00 ( v litx bytes plaintext v k ). 6 − 6 | 4 00 ⊕ 2 ⊕ ) , 80 80 . . . 1 B ) ftepdigdt is data padding the if ) | , 0 v | ( v , log 7 C 7 . . . 0 2 C , ( , d b B ) 1 0 ) k b , . . . , where , − ( 1 C , − > k v V 000 80 i 1 5 | C , v sa as As . d g i +1 b 85 0 is is 5 2 j ) : ,

4 86 Chapter 4 Analysis of SCP02

Algorithm 4.1 Regular padding oracle attack FindBlock FindBlock(V,C) for i = n − 1 down to 0 bi ← FindByte(bi+1) // bn = 80 end for return b0 ··· bn−1

FindByte(b) for g = 00 to FF V˜ ← in V replace vi|vi+1 with (vi ⊕ g ⊕ 80)|(vi+1 ⊕ b) send V˜ kC to the oracle O r ← O(V˜ kC) if r = 1 return g end if end for

4.4.1 Timing Side-channel

As soon as the valid ciphertext V kC is changed into V˜ kC, the MAC verication yields an error, the padding data being valid or not, because the ciphertext is modied. In SCP02 this ends with the smart card outputting an error code. Furthermore, among the smart cards we have tested, an error code is always sent, and the same error code is provided whatever the validity of the padding data. Therefore we have used the time spent by the smart card during the whole decryption procedure to build the oracle O. The experiments we have done with several cards (labeled Card A to Card J) show that the card’s response time when the padding data is valid is higher compared to the case when the padding data is invalid. This leads to two observations. Firstly, the MAC tag is seemingly not veried when the padding data is invalid. Secondly, the response time reects the computation time. Depending on the smart card, the timing dierence ranges from quite low to unexpectedly high. For instance, for Card B, the timing dierence when the padding data is valid (15.60 ms) and invalid (14.83 ms) is less than 1 ms, while for Card C, the timing dierence between both cases (84.34 ms vs. 25.17 ms) is higher than 59 ms. The gures we provide correspond to the expected values regarding both padding possibilities, and using a command that carries two encrypted blocks and the 8-byte MAC tag. The experiments we have made with each card show that the two distributions corresponding to the response time when the padding is valid (DR) and when it is invalid (DW ) are clearly distinguishable and almost disjointed. Figure 4.2 illustrates the results corresponding to four of the attacked smart cards. For each conguration (valid and invalid padding), 5000 encrypted commands have been sent to the smart card, in order to get these measurements. Let tmin be a lower bound of the values corresponding to DR. If a response time is lower than tmin it is highly likely a wrong guess (since we never observed that a correct guess corresponds to a response time lower than tmin). Hence, in such a case, one attempt only allows discarding an incorrect value. On the other hand, if a response time is higher than this threshold tmin, it is rather likely a correct guess (since we observed only a very few number of values corresponding to DW that are higher than this threshold). Yet it is also possible that it corresponds to a wrong iue4.2 Figure SCP02 to Application 4.4

Number of samples Number of samples 100 150 – 100 200 300 50 0 0 ie h omn’ aal carries eld data command’s ( The invalid time. is ( it valid when is and data padding line) the blue when cases of number the of Distribution aa,adthe and data), 14 31 (a) (c) 16 adF, Card adE, Card 32 18 ie(ms) Time ie(ms) Time 20 8 m m bt A tag. MAC -byte 33 28 = 0 = 22 34 24 26 35 28 D

W Number of samples

ihrsett h response the to respect with line) red dashed , Number of samples 20 40 60 80 100 120 m 0 20 40 60 80 0 45 +2 20 nrpe lcs(nldn padding (including blocks encrypted (b) (d) 50 adC, Card 40 adJ, Card ie(ms) Time ie(ms) Time m m 60 55 28 = 0 = 80 60 D R continuous , 100 65 87

4 88 Chapter 4 Analysis of SCP02 guess with an unexpected long response time. Therefore, in order to detect a right guess, several trials may be necessary. As we will see in Section 4.4.2, this heuristic allows having a success probability close to 1. Moreover, in order to increase the discrepancy of the response time when the padding is valid and when it is invalid, we prepend extra blocks R0, ..., Rm−1 to the ciphertext, following the same technique as [CHVV03], so that the MAC verication (when it is actually done) involves also these additional blocks. That is, instead of V kC, the smart card receives as the encrypted data the string R0k · · · kRm−1kV˜ kC. Indeed, during the decryption operation, the DES function (or its inverse) is called around 3q times, where q is the number of plaintext blocks. During the MAC verication, the same function is called at least q + 2 times.5 Therefore the timing dierence separating a valid and an invalid padding is proportional to roughly q + 2. As an illustration, Figure 4.3 depicts the distributions DW and DR corresponding to Card B for several values m (for each graph, the abscissa axis has the same 6-ms amplitude). The dierence between the mean values corresponding to DR and DW is 4.6 times higher when m = 28 (3.7 ms) compared to m = 0 (0.8 ms).

1,500 800

600 1,000

400

500

Number of samples Number of samples 200

0 0 13 14 15 16 17 18 21 22 23 24 25 26 Time (ms) Time (ms) (a) m = 0 (b) m = 9

1,200 800

1,000 600 800

600 400

400 Number of samples Number of samples 200 200

0 0 30 31 32 33 34 35 39 40 41 42 43 44 45 Time (ms) Time (ms) (c) m = 18 (d) m = 28

Figure 4.3 – DR (continuous blue line) and DW (dashed red line) corresponding to Card B with dierent values m.

5Optionally the IV used during the MAC computation is encrypted. In such a case the DES function is called at least q + 3 times during that operation. h vn orsodn to corresponding event The Moreover that have we Hence, and times, Hence to time corresponding response event corresponding the as soon as and Let independent. are trials if Hence size g of Therefore set a found. from correctly random be at drawn uniformly are the bytes nd to probability the then independent, is actually Let is guess. distribution wrong the a discard to necessary attempts [CHVV03]. al. et Canvel as reasoning Complexity. Side-channel Timing the Leveraging 4.4.2 SCP02 to Application 4.4 seult byte a to equal is D Let Let + • • • R Pr[ Let . n h orc au for value correct the and one), correct the before tried values incorrect of for values incorrect for choice the K t t etersos iecrepnigt ra ihsm value some with trial a to corresponding time response the be R 1 ` ≤ Therefore . t etenme fatmt eesr odtc ih us,and guess, right a detect to necessary attempts of number the be t p min t i ≤ min etepoaiiyt n h byte the nd to probability the be t sde uhthat such dened is min eaayetecmlxt fteatc ple oSP2floigtesame the following SCP02 to applied attack the of complexity the analyse We hntedsrbto is distribution the when , b h usqettil Therefore trial. subsequent the g i fadol if only and if scret(hc rbblt is probability (which correct is + g cuswe h itiuinis distribution the when occurs τ − D + r icre wihpoaiiyis probability (which discarded are W = − and p p p and , cuswe h itiuinis distribution the when occurs g K 0 ' = X j R p sdtce wihpoaiiyis probability (which detected is =0 τ (1 − p − = ' = ' τ 0 n 1 − p (1 erespectively be ahbt a aeayo the of any take can byte Each . − − (1 ' 0 = X (1 j ` 1 − h rbblt fabddcso hntedistribution the when decision bad a of probability the τ − =0 − − − 1 − τ ) ` D hrfr,ti ipie into simplies this Therefore, . 1 + − n 1 ` − · − ) R − t K (1 = − ) j ] n slwrthan lower is R n τ olwn u ersi,w icr guess a discard we heuristic, our Following . )(1 × τ − − (1 τ + ye is bytes K b + K 1 1 i 1 = R − , − R + + − − 0 Pr[ ) etepoaiiyo a eiinwhen decision bad a of probability the be n j ≤ + τ (1 + 1 − ` ` (1 − + ` 2 K ), ) ) t > t 1 n < i ahbt a h aepoaiiyto probability same the has byte each , + n p (1 − ` R − − D ` 2 − = 2 1 − W 1 n t + − min min ` p if , ) − τ fw sueta l ye are bytes all that assume we If . 2 ) (1 0 ` D − 1 × hntedsrbto is distribution the when , ) t > t − R (i.e., K 1 if , . . . R − + ` t > t K ) × min g osbevle.Aguess A values. possible j e sasm htall that assume us Let . − W where p ). n K 1 = − min K R 1 oevri the if Moreover . W ucsietimes. successive .Teeoethe Therefore ). tmost at j h ubrof number the stenumber the is K R D − W 89 g 1 ]

4 90 Chapter 4 Analysis of SCP02

If each byte bi is uniformly drawn at random among ` possible values, the average number of `+1 values g to be tested before the right one is found is 2 . `−1 The average number of trials to nd one byte is 2 KW + KR. The overall complexity is `−1 then Z = n × 2 KW + KR to retrieve a n-byte string. Since the burden in the complexity lies on the number of wrong attempts, slightly increasing KR allows increasing the overall probability of success p while it marginally increases the complexity Z. Indeed, if τ+ < 1, p is an increasing function of KR.

Application to SCP02. The attack is then the following. When looking for a byte bi, for each possible value g, a modied ciphertext V˜ kC is sent to the targeted smart card. The dierent response times are collected until a decision can be taken (which means in practice KW ' 1 attempt to discard a wrong guess and KR ∈ {1, 2, 3} attempts to detect a right guess). If the decision is that the guess is correct, the trials are stopped and the attack continues with the byte bi−1. Otherwise, another guess value g is tested. Algorithm 4.2 describes this timing attack (we assume without loss of generality that C includes at least one byte of padding, i.e., 80). For a given value g, the Stop procedure returns true as soon as a response time is lower than tmin or if the number of successive response times higher than tmin reaches KR. The Correct procedure returns true if the number of successive response times higher than tmin is equal to KR.

Algorithm 4.2 Padding oracle attack based on the card response time FindBlock FindBlock for i = n − 1 down to 0 bi ← FindByte(bi+1, . . . , bn) // bn = 80 end for return b0 ··· bn−1

FindByte(bi+1, . . . , bn) for g = 00 to FF j = 0 do get a new ciphertext V kC V˜ ← in V replace vi|vi+1| · · · |vn with (vi ⊕ g ⊕ 80)|(vi+1 ⊕ bi+1)| · · · |(vn ⊕ bn) send R0k · · · kRm−1kV˜ kC as encrypted data to the smart card tj ← response time j = j + 1 until Stop(t0, . . . , tk−1) = true if Correct(t0, . . . , tk−1) = true return g end if end for

As soon as a cryptographic error occurs on the smart card side (e.g., the smart card receives a message with an invalid MAC tag, which happens when the attacker changes V kC into V˜ kC), eg,TSo C8) netedt r eevdb h plcto ntesathn,te are they smartphone, the on application the by received are data the Once SCP80). or TLS (e.g., necessary The setting. experimental our in successful fully is described have we attack The iue4.4 Figure 4.4). Figure (see card smart attacker the man-in-the-middle SCP02 and local the smartphone a break the as to on behaves order malicious application It in A the data. attack between sensitive applet). the these the apply retrieve by can to data, provided smartphone and encrypt service the channel, to on the used Trojan to key a respect symmetric or with a application user (e.g., the data between secret authenticate SCP02 carry to of may or means which the applet, the by an (e.g., only such commands protected upload SCP02 commands) is UICC. SCP02 the applet encrypted and the the application Therefore (i.e., the UICC. output the the to and SCP80), sent or is TLS channel to secure respect second (with this into decrypted That embedded smartphone. are the applet on the application carry channel the that secure commands and another SCP02 server the addition, remote is, through In the UICC, applet between smartphone. the the established the and send be server on to remote can application order a an In between of smartphone. established a intermediary is into the channel plugged SCP02 is a that UICC, UICC the an to into applet an of upload scenario. case Real ones: following the are succeed to order in conditions Discussion 4.4.3 take to have we attempt, each for each used perform is bytes to ciphertext the order new account in a into Since started obtained. be be to must has retrieving) ciphertext session new new a a Hence Therefore trial. stopped. is session the SCP02 to Application 4.4 2. Tesce nomto ssn tapeitbeposition. predictable a at sent is information channel. secret secure The such each 5. through sent is card. information the secret with same channel The secure (new) 4. a up sets repeatedly server remote The 3. 1. aedo nSP2ecytdcmad n edmddcmad otecard. the directly to can commands she modied where send point a and at commands card encrypted the SCP02 and on server eavesdrop remote the between sits attacker The h takri bet iciiaersos ie orsodn oavldada invalid an and valid a to corresponding times response padding. discriminate to able is attacker The UICC – otemmr pc ftelgtmt plcto ( application legitimate the of ( space application memory malicious the The to UICC. an targeting attack oracle Padding SCP02 b h takcnb re ntefloigra s-aeo C0:the SCP02: of use-case real following the in tried be can attack The i +1 , . . . V Smartphone , k b C n led on,adchange and found, already crepnigt h aepanetta h takam at aims attack the that plaintext same the to (corresponding 3 rSCP02/TLS or SCP02/SCP80 TR DATA STORE V accordingly. ntevci’ smartphone. victim’s the on ) eoeserver Remote omn)aeue to used are command) 3 a access has ) 91

4 92 Chapter 4 Analysis of SCP02

The attacker can proceed as follows. First she succeeds in getting the victim download a malicious application (embedded in an apparently inoensive application deployed on a popular store) into his smartphone. Then the malicious application can use a vulnerability lying in the legitimate application in order to escalate privileges, and to get access to the application memory space as described by Davi, Dmitrienko, Sadeghi, and Winandy [DDSW11]. The latter assumes that a aw in the legitimate application is exploitable. Alternatively the attacker can use a Trojan embedded in a popular application, or in a game (such as Trojans Dvmap or Tordow in Pokemon Go or Telegram). Once into the smartphone, the Trojan may escalate privileges to gain root access [Kiv], or inject a malicious code into system libraries, which will then be executed with system rights [Unu]. To that point, the Trojan is able to get access to the memory space of the legitimate application. Hence, it can read the genuine SCP02 commands, and modify it. The crafted command is then sent to the UICC, completing the process initiated by the legitimate application.

Fullling the conditions of success. Let us assume that encrypting the applet with SCP02 yields k blocks C0, ..., Ck−1 (possibly transmitted to the card through several successive STORE DATA commands), and that a 16-byte symmetric key lies in the blocks Ci, Ci+1, i + 1 ≤ k − 1. The number of SCP02 sessions a card can establish is bounded (to 215) as per specication. Hence the number of trials the attacker can make is also limited. Therefore if (and only if) the attacker needs to decrypt the whole encrypted applet, it may happen that the key be out of reach. However, if the attacker knows the position of the key within the encrypted data (condition 5), she can directly target the corresponding encrypted blocks (whatever the size of the encrypted applet). In such a case, the attacker uses rst the blocks Ci, Ci+1 as described by Algorithm 4.2. The block Ci is changed into C˜i in order to incorporate the attacker’s guess g, and the string C˜ikCi+1 is placed into a SCP02 command data eld (with a trailing 8-byte arbitrary MAC tag, and an optional leading string R0k · · · kRm−1). This fake SCP02 command is then sent to the UICC by the malicious application. Based on the time elapsed until the UICC sends back a response, the attacker knows if her guess is correct or not. The attacker uses the blocks Ci, Ci+1 to retrieve the 8 bytes of the symmetric key encrypted as Ci+1, and the blocks Ci−1, Ci in order to get the 8 bytes of the symmetric key encrypted as Ci. The attacker expects a clean and stable response time (condition 2). Yet it may happen that this time value be inuenced by surrounding activities. In such a case more sophisticated statistical tools may be used by the attacker (e.g., see [CHVV03; AP16]). Another necessary condition is that the same secret be repeatedly sent through the secure channel (condition 4). The nominal behaviour of the underlying application protocol could not be as expected by the attacker. Yet this condition could be fullled if, upon reception of the cryptographically invalid command (modied by the attacker), the underlying application within the card triggers a message asking the server for a new delivery of the same message (which contains the secret). Also, upon reception of an error code, the server could decide to send again the command carrying the secret. If the remote server sends again this command only or the whole applet, it is very likely that the symmetric key lie at the same position within the command and the applet. Hence condition 5 remains fullled. This error code may be sent either by the card itself (because the command it received has been modied by the attacker), or by the attacker. By default, in SCP02, the responses sent by the card are not encrypted nor protected with a MAC tag. Then the server may keep sending the same command (if not everlastingly, at least many times, which allows the attacker to retrieve a substring of the secret) until it is acknowledged by the card. `−1 The complexity per byte is 2 KW + KR. The gures provided in Section 4.4.4 assume that rn A swl) ewr bet s nivldpdigdrn h nrpinprocedure. encryption the during padding invalid an use to able were We well). as MAC wrong the case a such In attacker). the by modied one (the command invalid an receives it when lo ir S mr adRae) otc edr(mie 31SatCr edrUSB), Reader Card Smart 5321 (Omnikey reader contact a Reader), Card Smart USB Micro Alcor seTbe41.Pirt h tak ehv aetil nodrt e h distributions the get to order in trials made have we attack, the to Prior 4.1). Table (see invalid), cryptographically is procedure attacker the by sent command modied the (because changes successive the perform to secret the of values version dierent encrypted the same (with the reuse can she Then attacker the for possible be also may it Moreover complexity. overall the decrease would That e nara otx,teavrayta a cest nSP2ecyto rcei bet e a get to able is oracle encryption SCP02 an to access has that adversary the context, real a in Yet o epne oluc h tak ehv sddrn ye fSP2cmad( command SCP02 of types dierent used have We attack. the launch to responses not results. and Experiments card. targeted the of specimen a with tests pro- o ine decryption perform the can during attacker padding the Alternatively, invalid an cedure. yields bytes encrypted these changing probability, to close very distribution and tag), MAC wrong a (and padding valid a to D forth. so and procedure, attacker the to same given the is again secret sends the and of channel version secure encrypted card new new smart a the up by sets closed procedure is server channel the the Since procedure, receive). Java moment to single the response and (a the sent and card is send smart command to the the command from moment received measured the The is between time. response time response a elapsed the the measures to and equal card the is to time the it sends carrying it, command modies and which encrypted card procedure, an smart the channel, with the channel Through SCP02 n an keys. up session sets shared procedure server computes the Then retrieve). to has an First following. Prox’N’Roll). (SpringCard one SmartCard, contactless Contacted a Four Corp and 7. (Broadcom Windows readers on laptop running inner E6430 the Latitude used: Dell been and have EliteBook readers HP card laptops two smart the on the done with with managed been communication is The reader the SCP02). and (including card cards smart for protocols several ments bench. Test Attack Complete the of Results Experimental 4.4.4 would tested so have behaving we cards card smart a the Yet of none attack. that the so. stress We to behave specication. necessary SCP02 above, the listed from diverge 4 and 3 conditions the only. once data) secret the carries (that command encrypted the on eavesdrop to needs attacker values. remaining the test to exhaustive able an is through attacker attack the the if complete attack, then dictionary and a secret or the search of substring a only retrieve to than lower be can to belong over bytes distributed uniformly is byte each SCP02 to Application 4.4 bt erti ett h ad oyo htecytdcmadi ie oteattacker the to given is command encrypted that of copy A card. the to sent is secret -byte R ehv aeeprmnswith experiments made have We the is kinematic The attacker. the and server legitimate the both simulates program Our channel secure the close not does card targeted the if easier made is attack the Furthermore, o ahsatcr.Ti ssrihfradsnew w h adkeys. card the own we since straightforward is This card. smart each for ehv eeoe h takwt h aaOA irr SD hc imple- which [SSD] library OPAL Java the with attack the developed have We n bt tigi suornol eeae tesce au h attacker the value secret (the generated pseudo-randomly is string -byte g D ,adsn h oie omnst h ad hswudremove would This card. the to commands modied the send and ), W stesatcr a h agt ehv sdcmad and commands used have we target, the was card smart the As ycagn h riigbtso h nrpe aa ihhigh With data. encrypted the of bytes trailing the changing by ` 10 256 = mr ad rdcdb i ieetcr manufacturers card dierent six by produced cards smart javax { eg,tesce ssm oto I oeo password). or code PIN of sort some is secret the (e.g., 00 , . . . , . smartcardio D W FF orsod oa nai adn ada (and padding invalid an to corresponds } oee h lhbtsz h secret the size alphabet the However . akg.Teeprmnshave experiments The package. transmit n bt ert This secret. -byte D R ade the handles , corresponds U KEY PUT D W and 93 ,

4 94 Chapter 4 Analysis of SCP02

STORE DATA, GET DATA, GET STATUS), including commands that are not supposed to carry an application payload (however these commands, when protected, carry the encrypted padding and the MAC tag). Yet our purpose is to show that it is indeed possible to retrieve plaintext bytes whatever the command used, be it a command not supposed to carry data besides possible ags (e.g., GET STATUS, GET DATA), or commands which are intended to transmit sensitive data to the smart card (e.g., PUT KEY, STORE DATA). We observe that the payload carried in a PUT KEY command is encrypted with 3DES in CBC mode, as any command payload in secure mode. However, prior to be transmitted through the secure channel, the plaintext data is rst encrypted (with 3DES and another session key than the one used to provide data condentiality throughout the secure channel). We stress that we do not break this inner encryption layer. Yet, the padding oracle attack allows retrieving all the (encrypted) bytes sent through the secure channel even when this “sensitive” command is used. The maximum data size for a command is 255 bytes. Without the MAC tag, there remain 247 bytes = 30 DES blocks + 7 bytes. The attack involves two useful blocks V and C. This leaves at most 28 extra blocks Ri in order to amplify the timing discrepancy. In practice we have used either 0 or 28 random blocks depending on the targeted smart card. In the best case (i.e., KW = KR = 1), the average complexity to retrieve n bytes of plaintext `+1 15 is Z = n × 2 . The number of available SCP02 sessions is at most 2 (i.e., the maximum value of a keyset’s sequence counter). Since a new session has to be established for each trial, the maximum number of plaintext bytes that can be retrieved in the best case is bounded by 215 8 2 × `+1 < 2 , if ` = 256.

Table 4.1 – Experimental results for the padding oracle attack with n = 16 (pseudo-random) bytes of plaintext.

µ µ t τ Manufacturera Card W R min m + K K Z Z/n (ms) (ms) (ms) (%) W R A 39.60 42.59 41.00 28 0.16 1 3 2055.71 128.48 1 B 40.19 43.94 42.00 28 0.44 1 3 2077.78 129.86 C 25.17 84.34 75.00 0 0.00 1 2 2043.95 127.75 2 D 26.64 34.36 32.00 0 0.00 1 2 2066.54 129.16 3 E 15.61 25.65 23.00 0 0.00 1 2 2134.03 133.38 F 31.81 34.48 33.00 28 0.48 1 3 2109.71 131.86 4 G 15.64 18.53 17.00 0 0.28 1 3 2103.62 131.48 5 H 25.18 84.86 72.00 0 0.00 1 2 2048.34 128.02 I 25.90 35.85 32.00 0 0.06 1 3 2108.60 131.79 6 J 14.32 19.92 17.50 0 0.10 1 2 2094.85 130.93

aFor condentiality purpose, the manufacturer names and the card identiers are not provided in this thesis.

Table 4.1 summarises our results. The gures provided are the mean corresponding to the 300 tests roughly that we have performed with each smart card. For each card, we provide the expected response time in case of an invalid padding (µW ) and valid padding (µR), the threshold tmin used to detect a correct guess, the number m of additional blocks Ri used to increase the computation time discrepancy, the probability τ+ that an invalid padding yields a high response with use for recommended is scheme padding bit-oriented This plaintext). with invalid only the is which hrfr tsesta h rcei eoe.W bev oee htee hsshm may scheme this even that however observe We removed. is oracle the that seems it Therefore high. potentially is cards smart impacted of number the Therefore, h erpinof that decryption duration, the Let calculation attack. the (dictionary) in a discrepancy value perform a secret to or order outputs error in decryption distinct exploited the a be when yields could receiver this the If of string. behaviour empty the valid. an on is depending block oracle, decrypted an any provide scheme, still padding this to respect With reached. is string empty the scheme. padding byte that this arbitrary means An to This respect lowing. most. with at invalid block is one all-zero in is carried block is last data which padding plaintext the any Therefore possible. as few yields as decryption the value correctly, secret guesses a attacker for the looks (if and attacker set Black the size by if reduced noticed conceivable a as be Yet, to still belonging may values. byte the attack block each of dictionary possible for byte a look all each cannot Urtubia, enumerate if attacker to more the has because any but random, usable at independently not drawn is uniformly oracle unless is padding block form the plaintext latter Therefore the to of length). equal padding byte bit a block no to contains respect block with decrypted padded the correctly is block decrypted form form any the the of of padding padding byte-oriented bit-oriented a a changing slightly [PW08], Watson and terson after. removed scheme. whole data padding the padding Resistant the During and data. rst, padded veried the pad be on must to tag tag is MAC MAC [Vau02] the the Vaudenay compute procedure, by to decryption proposed then x and simple rst, A plaintext the formerly. proposed been have attack data. padding the MAC Countermeasures 4.5 GSM19]. [SIM18; year every billions their in produced are SCP02 implementing likely cards others). than faster to up B) probability the above since (i.e., valid time actually response is use we heuristic the H), Card D, Card C, (Card cards some guess. for right fact, in But made). is to equal byte plaintext ( byte per ( attempt wrong a ( discard attempt to trials of number the time, Countermeasures 4.5 nte ceerssigpdigoal tak n rpsdb lc n rui stefol- the is Urtubia and Black by proposed and attacks oracle padding resisting scheme Another However easy. not is vulnerability this by aected cards smart of number the Estimating retrieve to attack the of duration The byte per complexity the see, can we As for value minimum the experiments, our In x CBC h eevrrmvsalmthn riigbtsutlete itntbt sfudor found is byte distinct a either until bytes trailing matching all removes receiver The . 680 K Z/n oeb S It7,wt lgtdrne h ubro optional of number the dierence: slight a with [Int17], ISO by mode R B ,teaeaecomplexity average the ), Cr ) tdpnsmil ntesatcr tef(oecr ed response a sends card (some itself card smart the on mainly depends It C). (Card s ). h takrtisalpsil values possible all tries attacker The . V 0 k C 80 yields x t i uhacs,a es n diinlatmtwt h aevalue same the with attempt additional one least at case, a such (in min itntfo h atpanetbt spce,adtedt spadded is data the and picked, is byte plaintext last the from distinct eea onemaue iiga iiaigapdigoracle padding a mitigating at aiming countermeasures Several slow. is ) ENC sosre yBakadUtba[U2,adpoe yPa- by proved and [BU02], Urtubia and Black by observed As 10 − 1 ( · · · Z C n ) oretrieve to 0 16 = ⊕ ae h adn rce(lot aih Indeed, vanish. (almost) oracle padding the makes Z/n V 1 0 ye agsruhyfrom roughly ranges bytes K ie,teboki qa to equal is block the (i.e., ( = sams pia coeto (close optimal almost is R B V is n K 0 16 = 2 ⊕ n changes and W nodrt eal ocretyda nd correctly to able be to order in B ,tenme ftil odtc right a detect to trials of number the ), τ ) + ye,adteaeaecomplexity average the and bytes, ⊕ htawoggesyed high a yields guess wrong a that V ( V K k C ⊕ R V 1 = eteecyto fsome of encryption the be B into 0 = ) seog odtc a detect to enough is 160 V 00 B 128 0 d = ⊕ where , Cr ,Card A, (Card s . 0 V B 5 .Moreover ). isms be must bits 0 ⊕ 000 80 If . B B d 0 Then . sthe is i ⊕ into 00 B 95 d g 0 ,

4 96 Chapter 4 Analysis of SCP02 contains at least two distinct bytes, then there is at least one remaining byte after the padding extraction. If all bytes in B ⊕ B0 are equal, then no byte remains after the padding removal. If the attacker is able to detect such a case, she knows that B = B0 ⊕ (y| · · · |y) where each byte y can take at most 256 values. Therefore this leaves at most 256 candidates for B.

Equal computation or response time. Canvel et al. [CHVV03] suggest to make error responses time-invariant by simulating a MAC verication even when there is a padding error. This implies carefully implementing the decryption procedure in order to eliminate all timing channels. Indeed AlFardan et al. [AP13] have shown that even a tight channel can be exploited. In addition, the latter authors warn that adding random delays during the decryption procedure may not be sucient if the delays follow a uniform distribution. This change would merely increase the complexity of the attack. In turn, Askarov, Zhang, and Myers [AZM10] propose a mitigation scheme that applies to a broad class of computations. With respect to SCP02, this means sending the responses at scheduled times (that is somehow padding the response time to an upper bound). These authors observe that this does not prevent timing leaks, yet it bounds the amount of information provided through this side channel as a function of the elapsed time.

Resistant operation mode. Another x is to replace the CBC mode with an authenticated encryption algorithm as suggested by Kupser, Mainka, Schwenk, and Somorovsky [KMSS15]. The latter proposal or another construction than E&M may be a suitable choice since Paterson and Watson [PW12] extend the results of Bellare and Namprempre [BN08] to prove that the E&M construction using CBC mode with a padding method as its encryption component is not generically secure in the chosen ciphertext setting.6 They also prove that the EtM construction (known to be secure in general when padding is not considered) is also secure when a padding method is used.

PUT KEY command. In addition to these countermeasures, in the SCP02 case, one may use the PUT KEY command in order to send secret values to the smart card (e.g., symmetric keys). The data eld of such a command corresponds to the output of a double encryption process: rst with a session key dierent than the one used to encrypt and MAC the other commands, then with these same secure channel session keys. Therefore, applied to a PUT KEY command, the attack breaks the upper encryption layer but not the inner one, and yields the data encrypted under this additional session key but not the genuine plaintext data.

Server side. Furthermore, the attack can be mitigated by limiting, on the server side, the number of times the same secret value is sent to the smart card. Since the attacker needs to make several trials (each one implying setting up a new secure channel) in order to get one byte of plaintext, this simple mitigation forbids or drastically reduces the amount of data the attacker can retrieve.

6Bellare, Kohno, and Namprempre [BKN04] prove that a particular Encode-then-Encrypt-and-MAC construction is secure when a padding method is used. But the encoding function is assumed to be collision resistant (the computation of the authentication tag involves a sequence number unique per message that aims at precluding collisions between two encoded messages). 4

eueti oe ofral rv h euiyo hs w schemes. two these of security the prove formally to model this use We ecall we AE.Ti oe atrsi atclrtefradsceypoet.I hpe ,w present we 7, Chapter In property. secrecy forward the particular in captures model This (AKE). Contents it. instantiate the concretely prove to how formally describe we and result, model, rst our the in protocol Applying this 3. of mitigate security Chapter an to order present in in we described modied Then properties, vulnerabilities security the protocol. stronger LoRaWAN-like with generic 1.1 LoRaWAN a of version of name adapted its security hence the channels, prove secure to setup framework to is goal whose protocols setting. symmetric-key the in instantiation, concrete a it, on based and, AKE 3-party generic a adversary. the to during attributed property, powers security and some dened break are to rules tries where and experiment challenger specic a a faces adversary the where model T h eut fti hpe aebe ulse n[C1]ad[CF19]. and [ACF19] in published been have chapter this of results The the on based is model security second The that model, rst The models. security two dene and approach this use we chapter, this In 3-AKE facytgahcshm.Ti prahcnb sdb en fa adversarial an of means by used be can approach security This the regarding scheme. evidences cryptographic convincing a providing at of aiming paradigm a is proach) approach security provable he . euiyPof nte3AC Model 3-ACCE the in Proofs Security 5.4 Model Security 3-ACCE The 5.3 Model Security 3-AKE Model The Security Suitable a for 5.2 Need The 5.1 .. xeddScrt Proofs Security Extended 1.1 LoRaWAN with Security 5.4.3 3-ACCE 5.4.2 Models Existing with Comparison Denitions 5.3.4 Security Environment 5.3.3 Execution 1.1 LoRaWAN against Scenario Attack 5.3.2 An 5.3.1 Denitions Security Environment 5.2.2 Execution 5.2.1 .. -CEScrt o eei -at Protocol 3-party Generic a for Security 3-ACCE 5.4.1 isa nlsn h euiyo -at uhniae e xhneprotocols exchange key authenticated 3-party of security the analysing at aims , euiyModels Security ...... o,mr dqaey h eutoitscrt ap- security reductionist the adequately, more (or, ...... ACCE ...... aaim talw nlsn 3-party analysing allows It paradigm...... 3-ACCE is,w s this use we First, . 5 105 100 112 101 109 103 116 105 119 112 106 111 101

5 100 Chapter 5 Security Models

5.1 The Need for a Suitable Security Model

Establishing a secure communication between two parties is a fundamental goal in cryptography as well as formally proving that such a protocol is secure. In their seminal paper, Bellare and Rogaway [BR94] propose a security model for the symmetric 2-party setting, and describe provably secure mutual authentication and key exchange protocols. Subsequent models have been proposed (e.g., [BWJM97; BPR00; CK01; CBH05; LLM07; MSW08; Cre09; JKSS11] to name a few). Of particular interest are the security models proposed to analyse real-world protocols such as TLS [MSW08; JKSS11; KPW13], IPsec and IKE [FS99; CK02; Cre11], SSH [BKN02]. All these models consider protocols in a 2-party setting. However there exist concrete deployments making use of protocols dened or improperly seen as 2-party schemes, that involve, in fact, three (or more) entities, which dierent cryptographic operations are attributed to. For example, the 3G/4G mobile phone technology can be described at rst glance as a 2-party scheme involving, on the one hand, a set of end-devices, and, on the other hand, a backend network owned by the operator. However, when the end-device is abroad, the communication is relayed by a server aliated with a dierent operator. Such a protocol, unlike classical 2-party setting, requires three participants, and known 2-party security models cannot be seamlessly applied to such a 3-party setting. Whereas the eld of 2-party protocols has been intensively investigated, the 3-party case has received less attention so far. Yet, unsurprisingly, this does not prevent 3-party protocols from being deployed in real-life, despite the lack of a suitable security model that allows seizing precisely, and incorporating their specics. This is illustrated by the works summarised below, and also by the protocol LoRaWAN 1.1.

Existing 3-party security models. Alt, Fouque, Macario-Rat, Onete, and Richard [AFM+16] analyse the authenticated key exchange of the 3G/4G mobile phone technology in its complete 3-party setting (with the addition of components from the core network). Based on their formal analysis, they describe how to provide a much stronger security with a small modication which can be easily incorporated in the protocol (despite previous results which indicate privacy aws and suggest strong changes). Regarding the same key exchange scheme, Fouque, Onete, and Richard [FOR16] use a 3-party security model to show that several remediations proposed in order to thwart end-device-tracking attacks are, in fact, ineective. In addition, they propose an improvement that aims at mitigating these attacks while retaining most of the 3G/4G key exchange scheme structure. Regarding the secure channels, Bhargavan, Boureanu, Fouque, Onete, and Richard [BBF+17] consider the use of TLS 1.2 [DR08] when it is proxied through an intermediate middlebox (such as a Content Delivery Network (CDN)). They propose the notion of 3(S)ACCE-security in order to analyse such a setting. This model extends the classical 2-party authenticated and condential channel establishment (ACCE) model of Jager, Kohlar, Schäge, and Schwenk [JKSS11] to the 3-party setting. It adds in particular to the properties of entity authentication and channel security a third property aiming at “binding” several entities involved in the protocol. Bhargavan et al. describe several attacks targeting a specic CDN architecture, and show that the latter does not meet its claimed security goals. Naylor, Schomp, Varvello, Leontiadis, Blackburn, Lopez, Papagiannaki, Rodriguez, and Steenkiste [NSV+15] describe a multi-context TLS protocol (mcTLS) which extends TLS to support middleboxes, in order to oer in-network services. With mcTLS the middlebox becomes visible to the client and the server. In addition these two end-points control the (read, write) privileges attributed to the middlebox. mTS hc is npriua,a upriglgc let n en lotseamlessly almost being and client, legacy supporting at particular, in aims, which (mbTLS) oeigsvrl(eunilo aall xctoso h -at protocol 3-party the of executions parallel) or (sequential several modeling instances. Session key long-term a given is party Each ED. with keys session share set a (KS), Servers Key entities. Protocol Environment Execution 5.2.1 messages. new insert secrecy. or forward parties, also honest captures by model exchanged 3-AKE message Our any drop alter, forward, can It of model. indistinguishabiliy 3-AKE the our on of based relevance the protocols the on of Hence built security keys. is the session which prove the to al. meant et not Bhargavan is of consequently model the with contrasts This key. operations. from inspiration Taking this 2.3.1). Section 2, Chapter the (see [BJS16] Stebila and Jacobsen, Brzuska, our a of present experiments we section, this In Model Security 3-AKE The 5.2 related 3, Chapter in described model vulnerabilities, This the version. and parties. that LoRaWAN, several to of between 1.1 channels version secure by establish motivated to is is goal 3-party main which the protocols, of security the prove formally to 7. used Chapter in is presented model This protocols. exchange cost the to ignored remain would otherwise, security. that, the subtleties of enlighten to and analysed setting. properly multi-middlebox in guarantees that record-layer observe at limited They achieves aims and middlebox. model complex the Their is to [Res18]. model context) 1.3 their the TLS through with (dened instantiate rights they ne-grained that providing model, their in secure called struction model proxies security accountable the a with that propose establishment showing They channel mcTLS, insecure. against fact attacks in of is types several latter describe [BBD+18] Onete and Fouque, that model security explicit and goals. an mcTLS security in that these prove achieves requirements formally actually security not proposal do of their they set guarantee, a et to list Naylor supposed [NLG+17] Although are al. mbTLS extensions). et TLS Naylor new and on [NSV+15] (based al. deployments TLS current in integrated Model Security 3-AKE The 5.2 nour In This LoRaWAN-like 3-party analysing allows that model security a present we 5.3, Section In key authenticated 3-party analysing allows that model security a present we 5.2, Section In be to order in models security suitable deserve protocols 3-party that illustrate works These Delignat-Lavaud, Boureanu, Bhargavan, connections, TLS proxied of context same the In propose [NLG+17] Steenkiste and Karagiannis, Gkantsidis, Li, Naylor, turn, In 3(S)ACCE 2-AKE 3-AKE 3-AKE oe oicroaetetrepriso our of parties three the incorporate to model oe fBagvn orau oqe nt,adRcad[B+7,w extend we [BBF+17], Richard and Onete, Fouque, Boureanu, Bhargavan, of model oe isa nlsn -at rtcl hs anga st il session a yield to is goal main whose protocols 3-party analysing at aims model euiymdl h desr a ulcnrloe h omncto network. communication the over control full has adversary the model, security 2-AKE u oe osdr he eso ate:aset a parties: of sets three considers model Our ahparty Each E oe ett uhniain e nitnusaiiy,a ecie by described as indistinguishability), key authentication, (entity model feddvcs(D,adaset a and (ED), end-devices of 3-AKE P i anan e finstances of set a maintains euiymdl nanthl,w s h security the use we nutshell, a In model. security ( ACCE-AP X 3-AKE ,addsrb eei -at con- 3-party generic a describe and ), fsres(S htwl eventually will that (XS) servers of rtcl n hi interleaved their and protocol, uhniae n condential and authenticated ltk P i . . Instances K fAtetcto and Authentication of ACCE Π ahinstance Each . = ideo TLS middlebox { oin and notion, π i 0 π , i 1 . . . , AKE 101 }

5 102 Chapter 5 Security Models

n n πi has access to the long-term key Pi.ltk of its party parent Pi. Moreover, each instance πi maintains the following internal state:

n • The instance parent πi .parent ∈ K ∪ E ∪ X indicating the party owning that instance.

n • The partner-party πi .pid ∈ K ∪ E ∪ X indicating the intended party partner. A party in one of the three sets can be partnered with a party belonging to any of the two other sets.

n n n • The role πi .ρ ∈ {ed, ks, xs} of Pi = πi .parent. If Pi ∈ E, then πi .ρ = ed. If Pi ∈ K, n n then πi .ρ = ks. If Pi ∈ X , then πi .ρ = xs.

n • The session identier πi .sid of an instance.

n • The acceptance ag πi .α ∈ {⊥, running, accepted, rejected} originally set to running when the session is ongoing, and set to accepted/rejected when the party accepts/rejects the partner’s authentication.

n • The session key πi .ck set to ⊥ at the beginning of the session, and set to a non-null n bitstring once πi computes the session key.

n n n n • The key material πi .km. If πi .parent ∈ K (resp. πi .parent ∈ X ) and πi .pid ∈ X (resp. n n πi .pid ∈ K), then πi .km is set to ⊥ at the beginning of the session, and set to a non-null n n bitstring once πi ends in accepting state. Otherwise πi .km is always set to ⊥.

n n • The status πi .κ ∈ {⊥, revealed} of the session key πi .ck.

n n • The transcript πi .trscrpt of the messages sent and received by πi .

n • The security bit πi .b ∈ {0, 1} sampled at random at the beginning of the security experiments.

n • The partner-instances set πi .ISet stores the instances that are involved in the same protocol n n run as πi (including πi ).

n n • The partner-parties set πi .PSet stores the parties parent of the instances in πi .ISet (in- n cluding πi .parent).

Adversarial queries. The adversary A is assumed to control the network, and interacts with the instances by issuing to them the queries described below. In our 3-AKE model, we use familiar queries. Nonetheless we require some restrictions regarding the Test-query. This query aims at “evaluating” the quality of a key output by any of the 2-AKE runs done during a 3-AKE session. We use the vanilla real-or-random experiment. Nonetheless, some session keys output during a 3-AKE session are used in the same session, which allows the adversary to trivially distinguish between a “real” session key and a random key. Consequently, we forbid the adversary from issuing a Test-query with respect to a key as soon as this key is used (i.e., as input to a function). Moreover, we require the adversary to be stateless with respect to the Test-query. That is, the key kb sent in response to a Test-query cannot be used to interact with instances, nor contribute to answering other Test-challenges. Instead of proving that the key is good, one could consider proving that the key is good to be used for some purpose [BFS+13; Kra16]. But we chose not to use a weaker notion than the more established ones despite the necessity of these restrictions. eadta,frayinstance any for that, demand 5.1 Denition with partnered sets the and dene a we during Consequently, instance 2.1). an Denition (see conversations matching of sid notion the use we run, Partnership. Denitions Security 5.2.2 Model Security 3-AKE The 5.2 ob h rncit ncrnlgclodr falte(ai)msae etadrcie by received and sent messages (valid) the all of order, chronological in transcript, the be to • • • • • • • • • • • • • • • π j u ∃ π π π π π. π π Send | dene Test we revealed, been not has that party a For Reveal Reveal dene that we say corrupted, we been then not adversary, the by issued query partner intended and NewSession π not does (it query this to respect of with track stateless keep is adversary the Moreover, a issuing session. from the adversary the forbid a we answering attacks, and trivial preclude to order In key If game. the running Corrupt π. j k i i j k i r arieprnrdif partnered pairwise are n u ` n v s m g ISet PSet ...... ISet sid parent . km parent sid parent | sid k ( ( g 0 π π ( = ( ( and i n = | ←− KEY = = i π n π π = ( $ ) 6 = M , i P m hsqeymyb se nyoc e arieprnrdisacsthroughout instances partnered pairwise per once only asked be may query this : i i treturns it , n n π π π π π (Correctness) nodrt en h atesi ewe w ntne novdi a in involved instances two between partnership the dene to order In ) ) = { i = = . j v j i u n PSet k ) s ck hsqeyrtrstessinkey session the returns query this : k ` P . sthe is ( hsqeyrtrsteln-emkey long-term the returns query this : Let . . . . ) . sid π sid km P π π sid π i hsqeyalw h desr osn n message any send to adversary the allows query this : π , k P , i n k s j i i v m 2-AKE b ρ, , .α n returns and , . . ). 6= . i parent n 6= parent . j 6= = π. parent π . Test P , ⊥ trscrpt ν ⊥ 6= ⊥ i pid n ISet π t ur sudb h desr,te esythat say we then adversary, the by issued query -th . ⊥ k and ISet i and m accepted and } calnea ona h orsodn key corresponding the as soon as -challenge ) pid Otherwise . u,bt osby h atmsae esyta w instances two that say We message. last the possibly, but, run, . hsqeycetsanwinstance new a creates query this : ck = = π . be = π = ) . π trsisacsprnrdwith partnered instances stores π edethe dene We nigi nacpigsae h olwn odtoshold: conditions following the state, accepting an in ending P P k = s i n { i P m π . k j . π ck k i ck i . n π π ck K ∈ i X ∈ n b E ∈ . k ` where , i sid n π , ν = hni returns it then , . = . ck = ck + = i m π = π π π π , j v j = u i n . k ` π . ck ∞ ck . k ` epnsacrigt h rtclspecication. protocol the to according responds j π ck k u π , . 1 j u 6= . sid correctness 6= . k 6= s = ck ⊥ π , ⊥ hn edethe dene we Then, . ⊥ π = j u i n π , . g ck ⊥ ( j v π π h key The . tews tsmlsa independent an samples it Otherwise . } ν P i n P j . v i . . + = i ck km is fa3AEpooo sflos We follows. as protocol 3-AKE a of . ltk and , ν π , ∞ -corrupted of π j u . π k i n . P trscrpt b i and , π n i scle the called is i If . n tparty at .κ 3-AKE Corrupt π sstto set is o at hthas that party a For . ) i n π . M i n PSet . ck P to ateigwith partnering π i ( aigrole having , i Test n sue during used is P π revealed trsparties stores is i i n ) Test If . ν sthe is -challenge -revealed π -query, 2-AKE i n .α ν 103 If . -th π 6= ρ i n , . .

5 104 Chapter 5 Security Models

The last two conditions aim at “binding” the six instances involved in a 3-AKE run. Function g corresponds typically to the session key derivation function used by Pi (ED) and Pj (XS) together. Figure 5.1 depicts the links between the six instances involved in a correct protocol run.

(Pk) ` s πk KS πk

m v πi πj (Pi) ED XS (Pj) n u π πj i ck

Figure 5.1 – The six instances involved in a correct 3-AKE run

Security of a 3-AKE protocol is dened in terms of an experiment played between a challenger and an adversary. This experiment uses the execution environment described in Section 5.2.1. The adversary can win the 3-AKE experiment in one of two ways: (i) by making an instance accept maliciously, or (ii) by guessing the secret bit of the Test-instance. In both, the adversary can query all oracles NewSession, Send, Reveal, Corrupt, and Test.

Entity authentication (EA). This security property must guarantee that (i) any instance n m ` s u v π ∈ {πi , πi , πk, πk, πj , πj } ending in accepting state is pairwise partnered with a unique instance, and (ii) the output of a 2-AKE run done between Pk and Pi is used as root key in a 2-AKE run done between Pi and Pj.

Denition 5.2 (EA). An instance π of a protocol Π is said to maliciously accept in the 3-AKE security experiment with intended partner P˜, if ˜ (a) π.α = accepted and π.pid = P when A issues its ν0-th query.

(b) Any party in π.PSet is ν-corrupted with ν > ν0.

0 0 (c) Any instance in π.ISet is ν -revealed with ν > ν0.

(d) There is no unique instance π˜ such that π.sid =π. ˜ sid, m n u v or there is no instances πi , πi , πj , πj ∈ π.ISet such that m v • πi .pid = πj .pid ∈ K, n m • πi .parent = πi .parent ∈ E, u v • πj .parent = πj .parent ∈ X , and m n n u v u • g(πi .ck, πi .trscrpt) = πi .ck = πj .ck = g(πj .km, πj .trscrpt).

The adversary’s advantage is dened as its winning probability:

ent-auth advΠ (A) = Pr[A wins the EA game]. ehv ecie nCatr3 h rtclLRWN11(eto .)adsvrlaws several and 3.5) (Section 1.1 LoRaWAN protocol the 3, Chapter in described have We .,weesagvnE sbudt ie S ayN evr a ea h aabtenan between data the relay may servers NS many JS, given a to bound is ED given a whereas 1.1, rnigN oacp lhuhn D(n osbyn S satal novdi h session. the in involved actually is JS) she no JS, possibly keys), of (and these behalf ED under on no (computed NS although message to accept RekeyInd choice to consistent her NS a bringing of provide keys hand, If other sending 5.2). the in Figure on succeeds (see can, scenario hand, attack one following the RekeyInd the on the allows attacker, verifying This is the JS. partner, from as ED received accept keys to with order message NS in AS. malicious does, and NS a ED that by many operation shattered cryptographic between be forth can and network back whole data a relays of which security NS the weakest Thus the AS. or and a JS version of its In security and surface. the ED attack reduces the JS) increasing by (namely the 1.0) party LoRaWAN of third powers in (as the A and nor connection network), guarantee, against. type to back-end client-server defending supposed the at is aims and it it properties (ED security adversary only the parties clear make two specication not 1.1 involving LoRaWAN does the as Seemingly, protocol 3.6). the (Section protocol considers the of security the impairing 1.1 LoRaWAN against Scenario Attack An 5.3.1 Model Security 3-ACCE The 5.3 parameter. security the of function adversary time polynomial probabilistic all 5.4 Denition provide below 5.4 Denition to secrecy. respect with forward secure protocols Therefore, attacks). the trivial in preclude involved party a corrupt to as dened is advantage adversary’s The correctly its 5.3 Denition session. protocol 3-AKE a during performed runs 2-AKE the than more no indistinguishability. Key Model Security 3-ACCE The 5.3 Let (b) (a) N ntnein instance No (d) (e) eilsrt h atrwt h olwn cnro uigtekyecag hs,teonly the phase, exchange key the During scenario. following the with latter the illustrate We adversary an allow indistinguishability key and authentication entity of denitions The Aypryin party Any (c) Test π. susits issues π.α qeyt instance to -query b fi emntswt output with terminates it if π ˜ = = etels ntnein instance last the be b accepted 0 guessing ν ( KyIndistinguishability) (Key 3-AKE 0 t query. -th π. π. PSet ISet nodrt itnus rmrno h eso e uptb n of any by output key session the random from distinguish to order in Security) π is a enqeidin queried been has uigte3AEscrt experiment, security 3-AKE the during adv ν hsscrt rpryms urne htteavraycndo can adversary the that guarantee must property security This crutdwith -corrupted . key Π protocol A π. - 3-AKE ind b ISet 0 ( uhthat such , A = ) oedi cetn state: accepting in end to euiyeprmn u osm on,i re to order in point, some to (up experiment security . A nadversary An Π ,

Pr[ ν > ν adv s3AEscr if 3-AKE-secure is Reveal π. Π ent b 0 - auth . = queries. b ( 0 A ] A − ) and gis protocol a against 2 1

. Π adv nwr the answers aiscretes n for and correctness, satises π.α ˜ Π key - ind = ( accepted A ) r negligible a are Test Π htissues that , -challenge when 105 A

5 106 Chapter 5 Security Models

The attacker is then able to send valid messages to NS on behalf of ED (the same session keys are used to compute the RekeyInd message and the subsequent messages of the post-accept phase).

A (ED) NS A (JS) (attacker) (victim) (attacker)

τE ← rand() jr˜ jr˜ jr˜ ← · · · kτE −−−−−−−−−→ Verify cntE ======⇒ ja˜ ja˜ ←−−−−−−−−− ⇐======ja˜ ← rand() sk˜ ⇐======sk˜ ← rand() ri˜ Compute ri˜ with sk˜ ======⇒ Verify ri˜ with sk˜ rc ⇐======Compute rc with sk˜

Figure 5.2 – Impersonation of ED to NS based on a weak protocol between NS and JS. Double line arrows indicate the use of secure channel keys.

This scenario implies being able either to impersonate JS to NS, or to break the channel security established (with a protocol undened by the LoRaWAN specication) between NS and JS. Hence, this attack allows the attacker to impersonate ED to NS although the attacker does not know the ED’s master keys, nor does she (directly) target the LoRaWAN 1.1 protocol. It is conceivable because of the way the cryptographic operations in LoRaWAN are shared between ED, NS and JS, and interleaved with the undened protocol used between NS and JS. This highlights how the security of LoRaWAN crucially depends on this additional protocol. Analysing LoRaWAN implies taking the latter into account. LoRaWAN 1.1 is a 3-party protocol, not a 2-party protocol between a client (ED) and a backend network (NS-JS). Assessing its security (as a 3-party protocol) needs care. Therefore, it requires a suitable security model that incorporates all its subtleties, and makes explicit the security requirements which, for some of them (such as the protocol between NS and JS), are barely mentioned in the specication despite their crucial role in the overall security of a LoRaWAN network. In Sections 5.3.2 and 5.3.3, we describe a security model, that we call 3-ACCE, which aims at capturing the security goals of such 3-party protocols. In Section 5.3.4 we compare our 3-ACCE model with existing ones, and enlighten the need for such a model. In Section 5.4.1, we use this model to prove the security of a generic LoRaWAN-like protocol. Then, in Section 5.4.2, we provide a security proof of a concrete LoRaWAN 1.1 protocol modied in order to mitigate the aws presented in Chapter 3.

5.3.2 Execution Environment We describe the execution environment related to our model, using the notation of the ACCE model of Jager et al. [JKSS11] (see Chapter 2, Section 2.3.2), and Bhargavan et al. [BBF+17]. We use the ACCE paradigm because LoRaWAN 1.1 mixes up the key exchange phase and the post-accept phase. The key exchange phase involves two messages (the so-called RekeyInd and h olwn nenlstate: internal following the key long-term protocol the 3-party to the access of has executions parallel) or (sequential several modeling instances. Session set a and Servers, Network of model. AKE an in entities. as Protocol keys, of indistinguishability cannot on we based Therefore, protocol phase. [DR08], the exchange 1.2 of key TLS security the in the conclude messages prove to Finished used the are to (i.e., messages Akin messages LoRaWAN post-accept channel). these other secure any subsequent as the keys, through session sent the with computed messages) RekeyConf Model Security 3-ACCE The 5.3 orc xcto fteprotocol the of execution correct A • • • • • • • • • • • • hntessini non,adstto set and ongoing, is session the when π The or π cluding The as run The The once bitstring non-null a to set and state. session, the of beginning the The once keys session keys. decryption session and the encryption the to corresponding bitstring The authentication. partner’s the The π If The party a with partnered be only can with. protocol the running The instance: The j i i n n u P .ρ . .ρ P parent i ate-ntne set partner-instances role k eso identier session euiybit security e material key ate-ate set partner-parties partner-party eso keys session ntneparent instance cetneag acceptance J ∈ = = J ∈ π ns ns P i π n then , π i i n - - (including = . server client .ρ i = n . parent P { ∈ π i i n u oe osdr he eso ate:aset a parties: of sets three considers model Our π π E ∈ ahparty Each . parent if π ed i i n and n π i n . π .ρ i n π b , . , i = n . ck i n ns π π km π π π ape trno ttebgnigo h euiyexperiments. security the of beginning the at random at sampled = . π . pid i n i n i n pid j u i n P - π j v . .α e to set client . . J js parent itself). itself). i .ρ parent i π n sid e to set . ltk If . . i n J ∪ N ∪ E ∈ J ∈ PSet fJi evr.Ec at sgvnaln-emkey long-term a given is party Each Servers. Join of = {⊥ ∈ . P ISet fa instance. an of P fispryparent party its of P , i ns ⊥ i ns E ∈ i and , ⊥ = anan e finstances of set a maintains - J ∪ N ∪ E ∈ trsthe stores N ∈ Π trsthe stores - client ttebgnigo h eso,adstt non-null a to set and session, the of beginning the at , server if π running novsfu instances four involves P a nyb atee ihaparty a with partnered be only can j π v π j . then , i n parent accepted i n N ∈ .ρ .ρ , js { ∈ = niaigteparty the indicating } instances parties . π , of P ns accepted = ed i n j .ρ P - P , N ∈ P server i niaigteparty the indicating / ns i { ∈ rejected j = oevr ahinstance each Moreover, . aeto h ntne in instances the of parent - N ∈ server htaeivle ntesm protocol same the in involved are that π ns a eprnrdwt either with partnered be can i n if . - , parent , client π rejected π } i n k ` π Otherwise . . . pid hntepryaccepts/rejects party the when parent i n , , If . Instances ns π E π E ∈ j u - i n P feddvcs set a end-devices, of , server . π } i parent = π . j v E ∈ Π i n rgnlystto set originally , P P π ahinstance Each . nsi accepting in ends k } i P km k ` then , nsc case, a such In . = hton that owns that J ∈ k uhthat such spresumably is J ∈ sstto set is π π { i n i π π n π i i 0 n maintains computes . i n π , ltk . ISet P .ρ P i k 1 . i . . . , = ⊥ J ∈ E ∈ 107 (in- π ed N at ⊥ i } n .

5 108 Chapter 5 Security Models

n u v ` • πi .sid = πj .sid 6=⊥ and πj .sid = πk.sid 6=⊥

n u v ` • πi .ck = πj .ck = πj .km = πk.km 6=⊥

n u v ` Then, the partner-instances set and the partner-parties set are dened as π.ISet = {πi , πj , πj , πk} n u v ` and π.PSet = {Pi,Pj,Pk}, ∀π ∈ {πi , πj , πj , πk}.

n Encrypt(π ,M0,M1,H) n i Decrypt(πi ,C,H) if πn.α 6= accepted then return ⊥ n i if πi .α 6= accepted then return ⊥ u ← u + 1 n if πi .b = 0 then return ⊥ 0 0 $ (C , ste) ←− StAE.Enc(kenc, H, M0, ste) v ← v + 1 $ 1 1 (M, std) ← StAE.Dec(kdec, H, C, std) (C , ste) ←− StAE.Enc(kenc, H, M1, ste) if C0 =⊥ or C1 =⊥ then return ⊥ if v > u or C 6= Cv or H 6= Hv n then sync ← false b ← πi .b b b if sync = false then return M (Cu,Hu, ste) ← (C , H, ste) ⊥ return Cu return

Figure 5.3 – The Encrypt and Decrypt oracles in the 3-ACCE security experiment. StAE is the stateful authenticated encryption scheme used to establish the secure tunnel. The counters u and v are initialised to 0, and sync to true at the beginning of every n session. In case πi does not have a partner when answering a Decrypt query, then sync = false.

Adversarial queries. An adversary may interact with the instances by issuing the following queries.

n • NewSession(Pi, ρ, pid): this query creates a new session πi with role ρ, executed by party n Pi, and intended partner-party pid. The instance’s state is set to πi .α = running.

n n 0 • Send(πi ,M): the adversary can send a message M to πi , receiving a response M , or n an error message ⊥ if the instance does not exist or if πi .α = accepted.(Send queries in an accepting state are handled by the Decrypt query.)

n n n • Reveal(πi ): this query returns the session keys πi .ck and the key material πi .km of an n instance πi ending in accepting state.

• Corrupt(Pi): this query returns the long-term key Pi.ltk of Pi.

n n • Encrypt(πi ,M0,M1,H): it encrypts the message Mb, b = πi .b, with header H, with n n n the encryption session keys (stored within πi .ck) of an accepting instance πi (if πi .α 6= n accepted, then πi returns ⊥).

n • Decrypt(πi ,C,H): this query decrypts the ciphertext C with header H, with the decryp- n n n tion session keys (stored within πi .ck) of an accepting instance πi (if πi .α 6= accepted, n then πi returns ⊥). Figure 5.3 depicts this oracle. ebro rmBagvne l BF1] st aesr hti oeE salse a establishes ED some if that sure make to is [BBF+17], al. et Bhargavan from borrow we h desr’ datg owni endwt w ae:the games: two with dened is win to advantage adversary’s The ligoeo h olwn inn conditions. winning following the of one lling 5.5 Denition that adversary instance the denition. an experiment, following exists security there the establishing EA terminates, to of aim the it the In when with ED. if, is some channel it successful that and secure is sure a NS make if that to Conversely want between we communication involved. JS, a also a and is NS that an JS between a established is is there NS, some with communication set the dierent in a participates parties to party two third the belonging a to one that addition (each guarantee In session we instance. communication, unique the a in with involved partnered explicitly is state accepting in ending (EA). authentication Entity session. a Reveal in involved parties the the all and “bind” requirement to additional order an in include we property but authentication property), entity length-hiding the the in (but of way Security similar a 2.2.5). Section in 2, authenticated Chapter an length-hiding over see of transmitted variant, sense is tinguishability the data in all channel phase condential post-accept and the in (ii) and protocol, cation instance Correctness. π PSet key instances two the that during instance say We if an partnered message. by last received the and possibly, sent but, messages exchange, (valid) the all dene of we order, Consequently, chronological 2.1). Denition (see conversations matching Partnership. Denitions Security 5.3.3 Model Security 3-ACCE The 5.3 i n euiyof Security . • • • • • • . π π π π. ED π ∀ π , π j i i i n v n n i n Corrupt hne security channel PSet . . . . π . – sid sid ck parent ISet { ∈ desr ninstance An – adversary nigi nacpigsae h olwn odtoshold: conditions following the state, accepting an in ending π = π = i = n π = ACCE i .α n trsisacsprnrdwith partnered instances stores i n π π . π , (EA) π , sid h orcns in correctness The nodrt en h atesi ewe w ntne,w s h oinof notion the use we instances, two between partnership the dene to order In j { u = Encrypt k ` j u = . P . . ck j u sid sid P i π , accepted = P , . rtcl sde yrqiigta i h rtcli eueauthenti- secure a is protocol the (i) that requiring by dened is protocols i = 6= j nisac ssi to said is instance An v E ∈ 6= π j π , P , j π ⊥ u ⊥ ae nbt,teavraycnqeyaloracles all query can adversary the both, In game. and , . j v k sid ` , k . } km π } , j hn edethe dene we Then, . u π. . Decrypt parent and = ISet hsscrt rpryms urne htayinstance any that guarantee must property security This π π π k ` i n . = 3-ACCE i n km fparent of . = . pid { π π 6= i n j v = ⊥ π , . aiiul accept maliciously parent P sde sflos edmn ht o any for that, demand We follows. as dened is j u k π , P π E i J ∈ i n j v , E ∈ and , π , N = 3-ACCE k . ` , P } ssi to said is J j π and .Teproeo hspoet,that property, this of purpose The ). sAE N ∈ i n . PSet | ateigwt h sets the with partnering π. bsdo h eto-ih indis- left-or-right the on (based , π ISet fteavraysced nful- in succeeds adversary the if aiiul accept maliciously k ` trsprisprnrdwith partnered parties stores aiiul accepts maliciously . 3-ACCE parent | niyauthentication entity 4 = sid π i n ob h rncit in transcript, the be to = and rtcl sdened is protocols P NewSession k π J ∈ j u r pairwise are if according ISet , game, Send and 109 π i n ,

5 110 Chapter 5 Security Models

n – No instance in πi .ISet was queried in Reveal queries. n – No party in πi .PSet is corrupted. u u u n – There is no unique πj | (πj .parent ∈ N ∧ πj .sid = πi .sid), ` ` n or there is no πk ∈ Pk.Instances | πk.km = πi .ck.

u NS adversary – An instance πj of parent Pj ∈ N is said to maliciously accept if at least one of the following two conditions holds u u (a) – πj .α = accepted and πj .pid = Pi ∈ E. u – No instance in πj .ISet was queried in Reveal queries. u – No party in πj .PSet is corrupted. n n u n – There is no unique πi | (πi ∈ Pi.Instances ∧ πj .sid = πi .sid), ` ` n ` u or there is no πk | (πk.parent = Pk ∈ J ∧ πi .pid = Pk ∧ πk.km = πj .ck). v v (b) – πj .α = accepted and πj .pid = Pk ∈ J . v – No instance in πj .ISet was queried in Reveal queries. v – No party in πj .PSet is corrupted. ` v ` – There is no unique πk ∈ Pk.Instances | (πj .sid = πk.sid), n n n n v or there is no πi | (πi .parent ∈ E ∧ πi .pid = Pk ∧ πi .ck = πj .km).

` JS adversary – An instance πk of parent Pk ∈ J is said to maliciously accept if ` ` – πk.α = accepted and πk.pid = Pj ∈ N . ` – No instance in πk.ISet was queried in Reveal queries. ` – No party in πk.PSet is corrupted. v v ` – There is no unique πj ∈ Pj.Instances | (πj .sid = πk.sid), n n n ` n or there is no πi | (πi .parent ∈ E ∧ πi .pid = Pk ∧ πk.km = πi .ck). The adversary’s advantage is dened as its winning probability:

ent-auth advΠ (A) = Pr[A wins the EA game].

Channel security (CS). In the channel security game, the adversary can use all oracles. At some point, the adversary sends a challenge M0, M1 (issuing a query Encrypt) to some instance n n πi , and gets Cb the encryption of Mb, b = πi .b. The adversary is successful if it guesses b. That n n is, it must output an instance πi and its security bit. The security bit πi .b is chosen at random at the beginning of the game.

Denition 5.6 (CS). An adversary A breaks the channel security if it terminates the channel n security game with a tuple (πi , b) such that

n • πi .α = accepted

n • No instance in πi .ISet was queried in Reveal queries.

n • No party in πi .PSet is corrupted. ett idn” hsett idn rpry httetreprisivle ntessintake session the in involved parties three the that property, binding entity This binding”. “entity ed enb ett uhniain na3prystigapoet htgaate o only not guarantees that property a setting 3-party a in authentication” “entity by mean do We ihrsett h sAE-security. the to respect with middleware) (the server intermediary an when TLS of security the analyse to used is which hti,w ontdmn h lnt-iig rpry(.. h ihrethdstelnt of length the hides ciphertext the (i.e., property “length-hiding” the demand not do we is, That The h desr’ datg sde as dened is advantage adversary’s The esgsbtde o aeayaddvle ntecnrr,i h oe epooe edo we NS. propose, by we done model operations the genuine in the contrary, retain the and On authentication, forwards value. (ED) merely added client middlebox any consider the have 1.2, not TLS does with but instantiated messages secrecy. when forward propose, consider they not protocol does 3-party and authentication, client is handle This modularity. party. not third of lack a possible of involvement a unavoidable despite choice, the our also protocol. of but party, 2-party reason given classical the a a to in partner parties the unique tie a what “dimensions” three the to and extend to authentication way entity a the is on, properties: two into We separate JS. to a is been of JS have help by would established the channel option with expecting a ED ED such an an of enlist is purpose to there the only is NS, because it an JS guarantee data, by a additional relays requested this NS, NS is demand an When JS with a network. session session When the a a derivation. connect as establishes key to used ED the merely an of not part when is been the that has JS establishing means to (hence This prior ED oracle). exchange, purported derivation key the property the keys and this in NS Secondly, involved between parties. actually channel is these involved ED “bind” parties secure an to all order that by in JS ensured protocol, to be the guarantees it of that execution demand correct we Firstly, a middleware. the in ways. the between two of established in behaviour channels property the this decrypt audit extend to hence able middleware, be the should and server client that partner, its as server a secure remains 1.2 TLS Obviously schemes. encryption the for plaintext) corresponding the relax we Yet properties. security channel model the Our length-hiding and [KSS13]. stateful corresponding authentication modes the the entity DH reuse the and and with RSA and deal model, in mode, to adversarial 1.2 DHE notation and TLS in environment of [DR08] execution security 1.2 same the the TLS the prove on of follows to built security al. is the et latter prove Kohlar the to by turn [JKSS11] used In al. et server. Jager the by and introduced client the between involved is Models Existing with Comparison 5.3.4 parameter. security the of adversaries function time negligible polynomial a probabilistic are all for and ness, 5.7 Denition Model Security 3-ACCE The 5.3 oevr spitdotb hraa ta. hi oe a w anlmttos tdoes it limitations: main two has model their al., et Bhargavan by out pointed as Moreover, identies client a whenever that requiring property a includes al. et Bhargavan of model The 2 1 • 3-ACCE u oe osntrqiefradsceyete eas fteueo ttcsmercky nLoRaWAN. in keys symmetric static of use the of because either secrecy forward require not does model Our called is property This ocmest o h rporpi prtosta Si nbet efr.Another perform. to unable is NS that operations cryptographic the for compensate to π i n . b = euiynto epooetksisiainfo hto hraa ta.[BBF+17], al. et Bhargavan of that from inspiration takes propose we notion security b ( 3-ACCE adv accountability -security) AEAD Π chan - sec ( ( sLHAE A . n[BBF+17]. in = ) -at protocol 3-party A

euiyue yJgre l n s the use and al. et Jager by used security ) Pr[ A isteC game CS the wins Π s3AC-eueif 3-ACCE-secure is A , adv ] Π ent − - auth 2 1

. ( A 2 ) 1 nadto,i the in addition, In and Π normdl we model, our In aiscorrect- satises adv ACCE sAE Π chan -security. - model sec ( 111 A )

5 112 Chapter 5 Security Models

The ACCE-AP model of Bhargavan et al. [BBD+18] allows capturing a context where several middleboxes are interspersed between a (TLS) client and a server. It aims at providing ne- grained rights (dened through contexts) to the middleboxes. We choose instead to use the intuitive and elegant 3-ACCE model since, in our setting, one intermediate server only (NS) is involved, which predened rights are attributed to. Moreover, the authors of [BBD+18] observe that their model is complex and achieves limited record-layer guarantees in multi-middlebox setting.

5.4 Security Proofs in the 3-ACCE Model

5.4.1 3-ACCE Security for a Generic 3-party Protocol

In this section we describe a generic 3-party protocol Π. Next, we show that Π is generically secure in the 3-ACCE model described in Sections 5.3.2 and 5.3.3.

5.4.1.1 Description of the Generic 3-party Protocol

Figure 5.4 depicts our view of the 3-ACCE protocol Π between ED, NS and JS. It is composed of two distinct protocols denoted P and P 0 respectively. P is a 2-ACCE protocol between ED and NS, and P 0 is a 2-ACCE protocol between NS and JS. The details of the protocol Π are given in Figure 5.5.

P P 0 ED NS JS 2-ACCE 2-ACCE Π 3-ACCE binding

Figure 5.4 – 3-ACCE protocol Π

Π is generic in the sense that it depicts a whole class of protocols. Informally, this class corresponds to 3-party protocols where one entity behaves mostly as a key server (JS), whereas the post-accept phase is managed by the other two entities (ED, NS). Moreover, the P component has the following features. Its key exchange is made of four main messages: the rst two with the major purpose of exchanging the material intended for the key derivation, and the last two in order to conrm the session keys or to authenticate the parties. For example, TLS-PSK [ET05], SRP [Wu00], and SIGMA-R [Kra03] can be instances of P . As we will see in Section 5.4.2, LoRaWAN 1.1 is such another instance.

5.4.1.2 Main Theorem and Sketch of Proof

Based on the security of P and P 0, we show that Π is 3-ACCE-secure according to Denition 5.7.

Theorem 5.1. The protocol Π is a secure 3-ACCE protocol under the assumption that P is a secure 2-ACCE protocol, and P 0 is a secure 2-ACCE protocol, and for any probabilistic polynomial time gis h -CEscrt of 2-ACCE-security the against where cetwtotN rJ en novd ec h desr a rttyt mesnt Sto NS advantage impersonate an to to try protocol corresponds rst This of can execution session). adversary 2-party the a Hence in involved. as being ED JS or NS without accept targets. adversary the JS) NS, (ED, party which depending parts proof. of Sketch adversary 5.5 Figure Model 3-ACCE the in Proofs Security 5.4 Dadversary. ED 5.4.3.1. Section in proof full a provide and 5.1, Theorem for proof of sketch a here give We Protocol eiyRekeyConf Verify Compute Accept Join Verify adv adv n E Π chan Π ent DN JS NS ED , A n - auth – - P N sec nte3AC euiyeprmn against experiment security 3-ACCE the in and , obeln rosidct h s ftescr hne keys. channel secure the of use the indicate arrows line Double protocol of execution Correct sk ( ( A A e ss osdrteE-euiypoet.W pi h ro nothree into proof the split We property. EA-security the consider rst us Let ogl paig nodrt escesu,teavrayms aeED make must adversary the successful, be to order in speaking, Roughly ) ) n ⇐ ======← − − − − − − − − − − − ⇐ ======otacp phase post-accept J ≤ ≤ ======onRequest Join onRequest Join Request Join r epcieytenme fE,N,adJ parties, JS and NS, ED, of number the respectively are onAccept Join RekeyConf RekeyInd n + n + E E n n · · E N n n · P N N n n J and , · · J n n · ⇒ ⇒ ⇒ ⇒ ⇒ adv 3 J J adv eiyJi Request Join Verify 2 adv B + P, ent eiyRekeyInd Verify adv 1 P chan adv client P - sa desr gis h -CEscrt of 2-ACCE-security the against adversary an is P chan 0 auth adv P chan i uhacs oN n oJ r novdi the in involved are JS no and NS no case a such (in - P ent sec - Π ( 0 sec , P, ent B - - client ( sec aeof made , auth B client 0 ( - + ) B auth ( 1 B + ) 0 ( 3 + ) B 0 ( n 3 + ) 1 B N adv + ) Π 0 ) · adv ← − − − − − − − − − − → h desr a lotyt bypass to try also can adversary The . ======⇐ ======⇐ adv P ======P ent adv adv ======0 onRequest Join Request Join uulauth. mutual , onRequest Join [RekeyInd] onAccept Join - lf)and (left) client P chan auth P, ent P chan 0 P ent server 0 0 - , - auth - server sk ( sec auth - B sec ( 1 ( B + ) ( B ( B 1 B 0 ) Vrf RekeyInd] [Verify Compute Request Join Verify P 1 ) 1 2 + ) ⇒ ⇒ ⇒ adv ⇒ ) 0 + rgt components. (right) adv B P ent p 0 0 , - jr server auth sa adversary an is Π ent Protocol sk 2 + - auth ( B p 1 ja ( ) A P P ) 0 . 0 113

5 114 Chapter 5 Security Models the intermediate NS in order to get from JS all the necessary material (Join Accept message, session keys sk) in order for ED to accept. This implies necessarily that a server adversary be able to impersonate a legitimate NS to JS, that is to break the EA-security of P 0 (corresponding to ent-auth an advantage advP 0,server(B1)). Finally, the adversary can try to make ED and NS have dierent sid. In order to be successful, the adversary has to provide a valid RekeyInd message to NS dierent than the one computed by ED. This implies either forging such a message, or getting the keys used to compute it and transmitted by JS to NS. We reduce both possibilities to the chan-sec channel security with respect to P on the one hand (advP (B0)), and to the channel security 0 chan-sec with respect to P on the other hand (advP 0 (B1)). Since we have ruled out the impersonation of NS to ED, and the impersonation of NS to JS, ED uses the Join Accept message sent by JS upon reception of the Join Request message computed by ED. Therefore, ED and JS compute the P -session keys with the same inputs (and n ` the same function). Hence they output the same keys (that is πi .ck = πk.km). In addition, ED and NS have matching conversations (that is, they share the same sid). Accounting for the fact that the reduction must guess the identity of the three parties involved, the advantage of an ED adversary is bounded by

ent-auth ent-auth chan-sec chan-sec advΠ,E (A) ≤ nE · nJE nN · advP 0,server(B1) + advP (B0) + advP 0 (B1) ent-auth +advP,client (B0)

where nJE ≤ nJ is the number of JSs that can be partnered with a given ED.

NS adversary. First we deal with the winning condition (a). The adversary can try to impersonate ED to NS in order to preclude the existence of a partner to NS. This implies breaking the EA- ent-auth security of P when the server side is targeted. The corresponding advantage is advP,server (B0). Then the adversary can try to impersonate a legitimate JS to NS, in order to preclude the ent-auth involvement of JS in the protocol run. This corresponds to an advantage advP 0,client(B1). The only cryptographic operation that NS does in order to accept is verifying the RekeyInd message it gets from ED with the keys provided by JS. Therefore the adversary is successful if, on the one hand, it provides some keys sk to NS (through the P 0 secure channel), and, on the other hand, it sends to NS a RekeyInd message computed under these keys sk. Note that the adversary can be successful even if a legitimate JS is involved in the protocol.3 This is possible if the adversary forges a valid P 0 application message carrying the keys sk it has chosen. This can be reduced to the channel security with respect to P 0, which corresponds to the advantage chan-sec advP 0 (B1). The remaining possibility in order for the adversary to win is to provide a RekeyConf message so that NS and ED do not share the same sid (i.e., they do not have matching conversations).4 This is possible either if the adversary forges such a message, or if the adversary is able to get the keys used to compute the message, and transmitted by JS to NS through a secure channel with respect to P 0. We reduce either possibility respectively to the channel security with respect to P chan-sec 0 chan-sec (advP (B0)), and to the channel security with respect to P (advP 0 (B1)). Furthermore, since we have ruled out the impersonation of JS to NS, and also the possibility to forge P 0 u ` application messages, NS and JS share the same P session keys. That is πj .ck = πk.km. Accounting for the fact that the reduction must guess the identity of the three parties involved,

3 The adversary sends rst a fake Join Request message to NS (random MAC tag, correct counter cntE ). Then the adversary sends a random Join Accept to NS followed by session keys sk of its choice, and a RekeyInd message computed under sk (as depicted in Section 5.3.1 by Figure 5.2). 4Forging a RekeyInd message is already ruled out because we have precluded the impersonation of ED to NS. with where cetmsae hs w osblte r epcieybuddb h probabilities the by bounded respectively are possibilities two These message. Accept valid hta ntnemlcosyacps hti eflo h aesesa nteE proof. EA the in as steps same the follow we is That accepts. maliciously instance an that this messages, Accept Join and Request Join that probability guarantees the a possibilities to in corresponding carried message, either data forging the implies on depend keys these same the share NS reduced and be JS to can that respect which guarantees with direction), security either channel (in the channel secure to the through exchanged messages the same the advantage an to corresponds ( condition through winning in adversary NS an of advantage Join a or message Request Join a p either forges adversary the if possible is This keys. session same JS. to a intended forge message) to same try the share can not adversary do the JS and NS that have to to respect with security break to able adversary keys an some implies This JS. a adv such of of involvement EA-security the the preclude to order in ( condition through winning in adversary NS an of advantage the Model 3-ACCE the in Proofs Security 5.4 ja p aigacuto l h ate novd h datg faJ desr sbuddby bounded is adversary JS a of advantage the involved, parties the all of account Taking eadn h Spoet of property CS the Regarding dierent compute JS and ED make to try can adversary the Finally, the involved, parties the of identity the guess must reduction the that accounting Therefore, the share they is that conversation, matching a have JS and NS that guarantees this far, So ( condition Regarding Sadversary. JS a adv P ent 5 seScin5.4.2.1). Section (see ≤ ieetssinky r lkl)ue nete ieto nodrt protect to order in direction either in used (likely) are keys session Dierent 0 n P , sid - client Π ent auth E n n 0 , J adv N E E plcto esg arigtekeys the carrying message application - ≤ auth ( J sid π · ( sk ≤ B n Π ent j v n . , ( N 1 ie,d o aeamthn ovrain,teavraycntyt og n of one forge to try can adversary the conversation), matching a have not do (i.e., p J sid E n - A ) fiscoc,adaRkyn esg optdunder computed message RekeyInd a and choice, its of auth b and , hnteavraycnpoeda ne odto ( condition under as proceed can adversary the Then . E ) adv ≤ = stenme fE htcnb atee ihagvnJ.Therefore JS. given a with partnered be can that ED of number the is nti etn,teavraycns r oiproaeN oJ,which JS, to NS impersonate to try rst can adversary the setting, this In ( n A ≤ ≤ P, ent π P n N ) k ` server J - 0 . · auth ≤ E sid hntecin iei agtd hc orsod oa advantage an to corresponds which targeted, is side client the when + n p n 5 ≤ P a E J n n b ecnrdc h atrt h hne euiyof security channel the to latter the reduce can We .Fnlyteavraywn fN n Dd o hr h same the share not do ED and NS if wins adversary the Finally ). ( + ,teavraycns r oiproaealgtmt St NS to JS legitimate a impersonate to try rst can adversary the ), 0 · J N B hc orsod oa advantage an to corresponds which , n adv n · J 0 p · π adv N n . + ) n b i n N P ent J . Π n P ck 0 P ent , + - client n J adv adv 0 auth 0 E , eapytefloighp.Frtw ueottepossibility the out rule we First hops. following the apply we - J server adv = plcto esg cryn onRqeto RekeyInd a or Request Join a (carrying message application auth E · P ent P ent ( π adv adv B P, ent 0 0 k ` , , ( - - server client 1 auth . server auth B P km - 2 + ) auth P chan 1 P ent sid 0 ) 0 ( hn nodrt aeta SadJ ontshare not do JS and NS that have to order in Then, . ( , . ( sid - client adv B auth ( B - ( B sec adv 1 π 1 sk 2 + ) ie,te onthv acigconversation), matching a have not do they (i.e., 0 + ) k ` P chan ( ) ( . B 0 B sid erdc uhapsiiiyt h channel the to possibility a such reduce We . P chan 0 1 0 - adv 2 + ) 2 + ) sec adv = - sec ( P chan B π P chan ( 0 adv j 1 v adv B 0 ) . - 1 sid .Rln u l hs possibilities these all out Ruling ). sec - + ) sec P chan P chan p ). ( b 0 0 ( B jr sbuddby bounded is ) B n adv - 1 - sec sec + 1 E + ) a + ) J sbuddby bounded is ) ( ( p P chan ( P a B B sk ja p 0 .Ta spoiigt NS to providing is That ). n 0 1 jr 1 n plcto messages. application ec,rln u both out ruling Hence, . + ) E + ) - hsipisfriga forging implies This . sec E P J + J ( ssinky.Since keys. -session ( ( p P p adv adv B p jr ja 0 jr 1 ( ) + ) adv P ent hn norder in Then, . P chan + 0 p . , - client p auth ja P chan - ja sec 0 ) ) ( ( - . sec B B p 1 0 jr ( ) ) B and 115 1 ) P . ).

5 116 Chapter 5 Security Models

ent-auth This leads to an advantage equal to advΠ (A). This leaves two possibilities in order for the adversary to be successful: either it targets directly the secure channel between ED and NS, or it targets the secure channel between NS and JS. We can reduce the latter possibility 0 chan-sec to the CS-security of P corresponding to an advantage advP 0 (B1). Regarding the former possibility, the adversary can rst try to get the P session keys (sk) sent by JS to NS (which we 0 chan-sec reduce to the channel security with respect to P leading to an advantage advP 0 (B1)). Then chan-sec the adversary can try to break the channel security with respect to P (advP (B0)). We have also to take into account that the session keys sk are sent by JS to NS through the secure channel provided by P 0. Since the CS-security of P relies implicitly on the indistinguishability of sk from random, we have to rely on the real-from-random indistinguishability for the plaintexts 0 chan-sec guaranteed by the channel provided by P (which we reduce to advP 0 (B1)). Accounting that the reduction must guess the identity of the parties involved, the advantage of the adversary is bounded by

chan-sec chan-sec chan-sec ent-auth advΠ (A) ≤ nE · nN · nJ advP (B0) + 3advP 0 (B1) + advΠ (A).

5.4.2 3-ACCE Security with LoRaWAN 1.1 In this section, we use the generic result of Section 5.4.1, and apply it to LoRaWAN 1.1. For this purpose, we have to (i) show that LoRaWAN 1.1 fullls the structure of the protocol Π proved to be secure by Theorem 5.1, (ii) prove that the underlying protocol P = PLoRaW AN is 2-ACCE- 0 0 secure, and (iii) choose a 2-ACCE-secure instantiation for the protocol P = P LoRaW AN . As described in Chapter 3, Section 3.5, a typical LoRaWAN network involves four entities: ED, NS, JS, and AS. But only the rst three are actually involved in the key exchange, and the channel establishment. Moreover, in actual deployments, AS is often co-localised with NS. Another reason to opt for such a deployment is that LoRaWAN does not provide end-to-end data integrity between ED and AS which leads to trivial attacks (see Section 3.6.5). Thus, AS is e in fact merely a functionality handled by NS, and the latter is given the four session keys Ka, e i1 i2 Kc , Kc , Kc (see Section 3.5.3). Hence, we instantiate LoRaWAN accordingly: our protocol is made of three active entities (ED, NS, JS) which the dierent cryptographic operations are attributed to. This makes the attack scenarios presented in Sections 3.6.6 and 3.6.7 ineective.

5.4.2.1 2-party Protocol P in LoRaWAN 1.1 is 2-ACCE Secure In this section, we use the ACCE security model described in Chapter 2 (we rename 2-ACCE this model in order to distinguish from the 3-ACCE model). Since LoRaWAN is based on static symmetric keys, we dene the long-term key of each party to be ltk = (pk, sk, mk), made of (i) a private key sk, (ii) the corresponding certied public key pk, and (iii) a master symmetric key mk. If Pk ∈ J , the three components of ltk are dened. Otherwise, Pj.ltk = (pk, sk, ⊥) if Pj ∈ N , and Pi.ltk = (⊥, ⊥, mk) if Pi ∈ E. Each party Pi ∈ E has a unique master key mk, shared with a party Pk ∈ J . The master key mk is dened as mk = (MK1,MK2) where MK1 and MK2 are respectively ED’s communication master key, and application master key (see Section 3.5.2). Let PLoRaW AN correspond to the messages exchanged, and the operations done between a client (ED) and a server (NS-JS) based on LoRaWAN 1.1. We claim with the following theorem that the protocol PLoRaW AN is a secure 2-ACCE protocol. Let StAEclient (resp. StAEserver) be the AEAD function used by the client (resp. server) to encrypt and MAC the messages in LoRaWAN 1.1. hoe 5.2. Theorem hti oaA osntpoiefradscey(o rtcsaantkey-compromise against protects (nor secrecy forward provide not does LoRaWAN is That ai one poaiiya most at (probability counter valid onAcp esg.Hence message. Accept Join the message: Accept Join desr gis h R-euiyof PRF-security the against adversary parties, where ktho proof. of Sketch of StAE PRP-security the against adversary an rpi ucinue ocmueaJi eus n eeIdmsae h A function MAC the the and message: tag, RekeyInd MAC a Request’s Join and the Request compute Join to a used compute to used function graphic party. factor a adds security the to event advantage this an reduce We message. underlying RekeyConf the valid of a forging in succeeds adversary same the share not a provide to ability adv the on lies message Accept Join valid a forge to adversary an of ability advantages the to respectively function encryption the and function, game). [BWJM97]). security attacks channel impersonation the and game authentication involved partner) entity presumed (the its experiments experi- (and security security party the channel the of the in corruption and any authentication forbid we entity but the accordingly, dene ments and 2.3.1, Section 2, Chapter adversary time polynomial against probabilistic experiment any security for and protocol, 2-ACCE secure a is Model 3-ACCE the in Proofs Security 5.4 adv adv adv egv eeasec fpoffrTerm52 n rvd ulpofi eto 5.4.3.3. Section in proof full a provide and 5.2, Theorem for proof of sketch a here give We eadn h evravray h esnn sqiesmlr is eiels ahcrypto- each idealise we First similar. quite is reasoning the adversary, server the Regarding by bounded is experiment EA the winning in adversary client a of advantage the Therefore, a compute to used function cryptographic each idealise we adversary, client a Regarding AES prp P chan P ent P, ent ecnie rtacin E)avray n hnasre N-S adversary. (NS-JS) server a then and adversary, (ED) client a rst consider We . client - - q auth auth ( - µ sec B stenme fisacsprparty, per instances of number the is 2 stebtlnt fteMCtag, MAC the of length bit the is ( ( ( 2 + ) A A A q ) ) ) adv · ne h supinthat assumption the Under − ecnie the consider We n ≤ ≤ ≤ µ C AES prf AEAD (1 where , sid + q q q − ( 2 h B · adv ie,i hyd o aeamthn ovrain.Ti spsil fthe if possible is This conversation). matching a have not do they if (i.e., · ( n 2 1 n + n + ) − C function C C P ent β KDF n n P ) + · C adv C hnteavrayi ucsfli h letadtesre do server the and client the if successful is adversary the Then . - adv n auth oa AN LoRaW +2 stenme fcin ate,and parties, client of number the is n Pr[ S adv mk S StAE sae adv adv ( StAE sae ) 2-ACCE A adv ogr onAccept Join forgery StAE ucinue ocmueteMCky( key MAC the compute to used function 2 AES prp adv ) AES prf β server 2 AES prf server MAC − β StAE sae AES ( 1 ( MAC prf B ( ,adavldMCtg(probability tag MAC valid a and ), ( server B ( B B AES 2 client B 1 + ) euiymdlo ae ta.[KS1 ecie in described [JKSS11] al. et Jager of model security , 1 3 en bet itnus uhcagscorresponds changes such distinguish to able Being . StAE ) 3 β ) B ( 2 + ) , ) B ( 1 .Tkn con falpsil letinstances client possible all of account Taking ). adv n sdt opt htmsae(orsodn to (corresponding message that compute to used stebtlnt ftecounter the of length bit the is and , B 0 adv navrayaanttePFscrt of PRF-security the against adversary an C 2 + ) 3 client + ) − (resp. MAC prf StAE sae ( µ B + KDF adv adv 3 ( and β ] server B ) navrayaanttesEscrt of sAE-security the against adversary an n (2 ≤ 0 AES prf StAE sae S ) c β and , StAE ( stenme fcin rs.server) (resp. client of number the is ) and p B − ( ja server 3 B ) )+ 1) 1 KDF = server ) adv 2 + ( B q adv + 3 adv AES prp h ubro ntne per instances of number the a 2 + ) − r sAE-secure, are n µ ucin sdt compute to used functions AES prf S ( AES prp B · n ( adv adv 2 C B ( ) B ota on,the point, that To . · 1 2 + ) cnt (1 AES prf StAE sae 2 − + ) MK µ A − J are nthe in carried ) ( client adv B and , nte2-ACCE the in 2 adv 1 3 − ) ,teMAC the ), P ( β MAC prf B MAC prf + ) oa AN LoRaW 3 AES B ) ( 0 B ( n san is B 0 S , 117 + ) 0 B ) i 2

5 118 Chapter 5 Security Models the session keys involved in the calculation of the RekeyInd message. Being able to distinguish prf prf these changes corresponds respectively to the advantages advMAC(B0), and 2advAES(B1). To this point, the probability to forge a valid Join Request message corresponds to the probability to −µ prf −µ forge a valid MAC tag (that is 2 ). Hence Pr[forgery Join Request] ≤ pjr = advMAC(B0)+2 . Finally, the only remaining possibility for the adversary is that client and server do not share the same sid (i.e., they do not have a matching conversation). This implies forging a valid RekeyInd message. We reduce this event to the security of the underlying AEAD function StAEclient used advsae (B ) to compute that message (corresponding to an advantage StAEclient 3 ). Taking account of all possible server instances adds a factor q · nS, where nS is the number of server parties, and q the number of instances per party. Therefore, the advantage of a server adversary in winning the EA experiment is bounded by advent-auth(A) ≤ q · n advsae (B ) + 2advprf (B ) + 2−µ + advprf (B ) P,server S StAEclient 3 AES 1 MAC 0

In addition, we have also

prf −µ Pr[forgery Join Request] ≤ pjr = advMAC(B0) + 2 prf prf prp Pr[forgery Join Accept] ≤ pja = advAES(B1) + advMAC(B0) + advAES(B2) +2−(µ+β) · (2β − 1)

Regarding the CS experiment, we rst abort if there exists an instance of some client or server ent-auth party that accepts maliciously, which adds an advantage advP (A). Then we idealise the e e i1 i2 cryptographic functions used to compute the session keys Ka, Kc , Kc , and Kc . Being able prf to distinguish the change leads to an advantage 2advAES(B1). Finally we reduce the ability to win the CS experiment to the security of the underlying AEAD functions that are used to encrypt messages in either direction: StAEclient and StAEserver. This corresponds to an advsae (B ) + advsae (B ) advantage StAEclient 3 StAEserver 3 . Taking account of all possible instances adds a 2 factor q · nC · nS. Therefore, the advantage of an adversary in winning the CS experiment is bounded by advchan-sec(A) ≤ q2·n ·n advsae (B ) + advsae (B ) + 2advprf (B ) +advent-auth(A) P C S StAEclient 3 StAEserver 3 AES 1 P

5.4.2.2 Meeting 3-ACCE Security As seen in Chapter 3, Section 3.6, and also exhibited by Theorem 5.2, the genuine LoRaWAN 1.1 protocol suers from several aws that forbid from concluding regarding its security. In particular, the (too) short size of several parameters (notably the size µ of the MAC output) provides useless security bounds in Theorem 5.2. Therefore, applying the recommendations presented in Section 3.7 in order to mitigate these vulnerabilities, we modify LoRaWAN 1.1 in the following way in order to yield PLoRaW AN .

• We demand that the size µ of the MAC output be high enough so that the security bounds ent-auth chan-sec advP and advP be tight (recommendation R2). • We slightly change the behaviour of JS as follows: JS veries entirely the Join Request message (including ED’s counter cntE), and the RekeyInd message. It sends the session keys sk to NS only if the RekeyInd message is valid. This change aims at precluding an attack that allows the adversary to trivially win the EA experiment. Indeed, if JS does where sepandi eto ..,tecrflcoc fti rtcli rca oteoealsecurity overall the to crucial is protocol this of choice careful the 5.3.1, Section in explained As L 1.3. TLS only uses 1.3 TLS that recall We authentication. mutual with mode, (EC)DHE eso fLRWN1.1. LoRaWAN of version Proof. 5.3.3. Section games authentication. of Entity sequence a through proceed adversary We an 5.1. and Theorem challenger of a proof between full BR04] the [Sho04; give we section, this In for Proof Security Extended 5.4.3.1 Proofs Security Extended 5.4.3 guarantees also version nal the that assume reasonably may 2-AKE we protocol, the of be draft to earlier proved is 1.3 TLS schemes. 2-ACCE with instantiated and as such authentication, mutual with protocol mode, the RSA dene protected or we well Therefore, how are. and keys functions, master cryptographic LoRaWAN the the of that security illustrates the of 5.3.1 independently Section as in protocol described unreliable scenario an attack choosing the Indeed, network. LoRaWAN a of protocol of structure protocol 2-ACCE-secure the the fullls 1.1 to LoRaWAN of version adapted our Hence Model 3-ACCE the in Proofs Security 5.4 obnn l h bv ihTerm51 eoti the obtain we 5.1, Theorem with above the all Combining protocol security companion the dene we Now • • • cetmsae e,J a ogaateta Dscesul opee h rtcl(it protocol the completes successfully ED that guarantee no has JS Yet, message. Accept h opnnssrone ihbakt nFgr . eitteeadtoa operations. additional these depict 5.5 Figure in brackets with surrounded components The Sfo eevn h rtRkyn esg,adti rastetasrp equality. transcript the breaks forbid this merely and to message, has RekeyInd adversary rst the the Indeed, receiving experiment. from EA NS the the win allows and trivially messages pre-accept to RekeyInd only the multiple adversary send separate sending ED clearly because that to Secondly, demand order We phases. in post-accept response. Firstly RekeyConf R3). a (recommendation receive to message not message one does RekeyInd it a as send long must as ED NS that states specication LoRaWAN genuine The to ED for order in message Accept Join the alter or drop accept). Join to not the adversary sends the it for as enough soon is as accepts it that means this message, RekeyInd the verify not nadto,w eadta Dapyrcmedto 1wiham tpeldn a precluding at aims 3.6.1). which Section R1 (see recommendation exhaustion apply counter ED that demand we addition, In (recommen- avoided be version to that fallback of no R4). vulnerabilities that dation the so and NS) possible, (including be 1.1 version 1.0 LoRaWAN implement entities all that require We scrt.Since -security. Let E AES scr JS1;KS3.Alternatively, KSS13]. [JKSS11; -secure , N adv , - GCM J Π ent niaersetvl at from party a respectively indicate , X - auth , AES ( A AEAD ) - CCM etepoaiiyta an that probability the be is ecnie h niyatetcto xeietdsrbdin described experiment authentication entity the consider we First nrpinshmsaeue,ti implies this used, are schemes encryption MG8,or [McG08], P oa AN LoRaW 2-AKE P 0 oa AN LoRaW Π scr DG1] lhuhti eutapist an to applies result this Although [DFGS15]. -secure . ChaCha20 P rsial ekn h euiyo LoRaWAN, of security the weakens drastically 0 oa AN LoRaW P E X 0 , oa AN LoRaW - P desr uces with succeeds, adversary Poly1305 N A 0 oa AN LoRaW . , J a ede sTS13[e1]in [Res18] 1.3 TLS as dened be can ehv that have We . 3-ACCE hti sdbtenN n JS. and NS between used is that N1] L . skont be to known is 1.2 TLS [NL15]. ob L . D0]i DHE, in [DR08] 1.2 TLS be to AEAD scrt foradapted our of -security 2-ACCE nrpinschemes encryption Π AEAD n corresponds and , adv X Π ent scrt for -security { ∈ - encryption auth E ( , A N ) , 119 J ≤ } ,

5 120 Chapter 5 Security Models

ent-auth ent-auth ent-auth advΠ,E (A) + advΠ,N (A) + advΠ,J (A).

ED adversary. Let Ei be the event that the adversary succeeds in making an instance maliciously accept during Game i, where the instance belongs to a party Pi ∈ E.

Game 0. This game corresponds to the EA-security game of the 3-party protocol Π described in Section 5.3.3 when the adversary targets ED. Therefore we have that

ent-auth Pr[E0] = advΠ,E (A).

Game 1. In this game, the challenger aborts the experiment if it does not guess which party Pi ∈ E the instance that will maliciously accept belongs to, and the corresponding partner-party Pk ∈ J . Therefore 1 Pr[E1] = Pr[E0] × . nE · nJE where nE is the number of parties in E and nJE ≤ nJ is the number of parties in J that can be partnered with a party in E.

Game 2. Now the party Pi ∈ E and its party partner Pk ∈ J are xed. We want to rule out the event that there is no unique instance of some party in N that is partnered (i.e., shares the n same session identier sid) with some instance πi of the party Pi ∈ E. If the adversary succeeds in forging valid Join Accept and RekeyConf messages, this implies n (in particular) that there is no such instance of some party in N that is partnered with πi (in addition, this implies that there is no instance of Pk that has computed the Join Accept message). Therefore we want to preclude such an event. Forging these messages corresponds ent-auth to the advantage advP,client (B0) for a client adversary B0 of breaking the EA-security of the protocol P . Note however that precluding such a forgery does not imply the existence of a u n unique instance πj ∈ Pj.Instances for some party Pj ∈ N that is partnered with πi . Indeed there is, in this execution of the 3-party protocol Π, other means to rule out the existence of such an instance. Nonetheless, ruling out the forgery of a Join Accept message implies necessarily ` the existence of an instance πk ∈ Pk.Instances that computes that message. Therefore we have

ent-auth Pr[E1] ≤ Pr[E2] + advP,client (B0).

Game 3. Now we want to rule out the event that the adversary gets from Pk valid parameters with respect to P (Join Accept message, session keys sk) so that the adversary be able to reply to Pi without any party of N being involved. But rst we add an abort rule. In this game, the challenger aborts the experiment if it does 0 not guess which party Pj ∈ N is partnered with Pk with respect to protocol P . Therefore

1 Pr[E3] = Pr[E2] × . nN

Game 4. In this game, the challenger aborts the experiment if an adversary succeeds in 0 impersonating Pj to Pk. This implies an adversary B1 able to break the EA-security of P when targeting the server side. Therefore

ent-auth Pr[E3] ≤ Pr[E4] + advP 0,server(B1). ehv that have We (resp. uigGame during ( condition Hence experiment. the the compute is to That permutation same equal. the and inputs same the by computed from message Request Join the uses addition, In that such instance but message but message RekeyInd with security channel the to events these reduce to can We respect message. by RekeyConf transmitted a keys, or suitable RekeyInd have the to getting way or only message, the RekeyInd Now 2). Game in message and a such of forgery the by of execution the in involved 5. Game Model 3-ACCE the in Proofs Security 5.4 Let that have we 5, Game to 0 Game from probabilities all Collecting that have also We of execution the point, this To if experiment the aborts challenger the game, this in Therefore, Sadversary. NS adv π π j u π j u E p pnrcpino h onRqetmsaesn by sent message Request Join the of reception upon i Π ent n ontsaetesm eeIdo eeCn esg.Ti mle ihrfriga forging either implies This message. RekeyConf or RekeyInd same the share not do b n oiproainof impersonation no and , , i a h rbblt htteavraywn hog odto ( condition through wins adversary the that probability the ) E - auth eteeetta h desr ucesi aiga ntnemlcosyaccept maliciously instance an making in succeeds adversary the that event the be P a ofr ehv ue u h o-xsec fa instance an of non-existence the out ruled have we far, So π ). nteoehn,adt h hne euiywt epc to respect with security channel the to and hand, one the on π a ( i n π A j adv u i k ssteJi cetmsaecmue by computed message Accept Join the uses ` Pr[ = ) a o optdi.W have We it. computed not has hog odto ( condition through . e scnie h inn odtos( conditions winning the consider us Let km Π ent π ≤ ≤ ≤ = ≤ ≤ , N i n - π Pr[ = auth . k ` sid n n n n n n π optsteJi cetmsae ec h xsec fta instance. that of existence the hence message, Accept Join the computes π E ( E E E E E E i n i n A = 4 . · · · · × · ] E ck a o uptta esg,o if or message, that output not has ) n n n n n ≤ π 0 n P hrfr,t htpit h desr a ocac fwinning of chance no has adversary the point, that to Therefore, . ≤ J J J J J ] j u E E E E E J Pr[ . E sid with p n n Pr[ n n × + a P + E N N N N . P adv j + Pr[ 5 adv a E · · · · to + ] π ,weeteisac aeti in is parent instance the where ), Pr[ between p 2 i n r P r P adv P, ent E + ] + b P P, ent Therefore, . es osdrasqec fcagsrltdto related changes of sequence a consider rst We . adv client 1 E k adv Pr[ client - ] [ [ auth - P chan E E auth ae lc) hrfr ohinstances both Therefore place). takes 3 adv + ] P chan 5 4 E P ent + ] + ] ( - π ( 0 5 B P, ent sec , B π - server i 0 = ] n adv auth - 0 client sec i n 0 - ( ) adv adv (because auth ) B and ( P, ent 0 ( B π + ) . B P chan P ent client ( 0 - i n B auth 0 1 + ) , - π server ) 0 eevsteJi cetmsaesent message Accept Join the receives auth - adv ) j u sec a ( adv B scret Hence correct. is P π n ( and ) π ( ( P chan 0 B j u k ` π B ) eso es ec h uptis output the Hence keys. session u oGm .Reciprocally, 2. Game to due , 0 0 i n P chan eevscretyta message that correctly receives 1 + ) π P ) 0 - rcl htw aerldout ruled have we that (recall sec i n k b - + sec eevsavldRekeyConf valid a receives fa Savray Let adversary. NS an of ) to ( adv B adv ( P 1 π B π + ) P chan j j u N π j 1 a u nodrt opt a compute to order in , 0 P, ent ) i rs.cniin( condition (resp. ) n ∈ P . vrrcie valid a receives ever . . client - adv sid - sec 0 P auth nteohrhand. other the on j ( π . P ent 6= B Instances ( j u 0 B 1 , - server π π ) steunique the is auth 0 i j n u ) . and sid ( B sif is 1 π htis that ) k ` 121 use b π π p )). i n k a `

5 122 Chapter 5 Security Models

Gamea 0. This game corresponds to the EA-security game of the 3-party protocol Π described in Section 5.3.3 when the adversary targets NS, and tries to win through condition (a). Therefore we have that a Pr[E0 ] = pa.

Gamea 1. In this game, the challenger stops the experiment if it does not guess which party Pj ∈ N and its partner-party Pi ∈ E the adversary targets. Therefore

a a 1 Pr[E1 ] = Pr[E0 ] × . nE · nN

a Game 2. Now the parties Pj ∈ N and its partner-party Pi ∈ E are xed. In this game, the challenger aborts the experiment if the adversary succeeds in forging valid Join Request and RekeyInd messages, hence impersonates Pi to Pj. This event corresponds exactly to the event that an adversary against the EA-security of the protocol P wins when the ent-auth server side is targeted. The advantage of such an event is advP,server (B0). Therefore

a a ent-auth Pr[E1 ] ≤ Pr[E2 ] + advP,server (B0).

a a Game 3. So far the parties Pi and Pj are xed. Moreover, due to Game 2, for any instance u u u n πj ∈ Pj.Instances such that πj .α = accepted and πj .pid = Pi, there is an instance πi ∈ Pi.Instances that is involved in the protocol Π (i.e., at least this instance computes a Join Request 0 message) under the assumption that the run of protocol P between Pj and some party in J which is the intended partner of Pi is executed honestly. However, precluding the adversary to break the EA-security of P when the server side is targeted does not imply in general the n existence of such an instance πi ∈ Pi.Instances. Indeed, the only cryptographic operation u that πj does in order to accept is verifying the RekeyInd message with keys that it does not even compute but receives from some party in J . Therefore, if the adversary, on the one hand, succeeds in sending keys sk of its choice to Pj, it can, on the other hand, provide a consistent RekeyInd message (computed under sk), bringing Pj to accept although no party in E is actually involved. This is possible either if the adversary impersonates to Pj some party in J , or if the adversary forges a valid P 0 application message (carrying the keys sk chosen by the adversary). We preclude such events in the subsequent sequence of games. But, before considering this case, the challenger aborts the experiment if it does not guess which party Pk ∈ J is the intended partner of Pi (during the execution of protocol P ). There are nJ parties in J . However each party in E may communicate with a limited number of parties in J . That number is nJE ≤ nJ. Therefore we have that

a a 1 Pr[E3 ] = Pr[E2 ] × . nJE

a Game 4. In this game we want to preclude the impersonation of Pk to Pj. Therefore, the challenger aborts if an adversary succeeds in making Pj accept with Pk as its purported partner. Therefore a a ent-auth Pr[E3 ] ≤ Pr[E4 ] + advP 0,client(B1).

Gamea 5. Now we want to preclude the possibility for the adversary to forge a valid P 0 application message. This event can be reduced to the channel security with respect to P 0. Therefore we have a a chan-sec Pr[E4 ] ≤ Pr[E5 ] + advP 0 (B1). inn h xeiettruhcniin( condition through experiment the winning cetmsaeadthe and message Accept Therefore also have we However keys). Therefore these with consistent message RekeyInd a and keys some (i.e., p same the shares that instance unique to respect to with respect security with channel security the channel to event rst the reduce can keys session the is (that message RekeyConf a compute by to sent used keys the get to by adversary messages) by RekeyInd received and one Request the Join not the to addition (in shared π is message Accept Join the Game in out by computed by used to are provides Since keys adversary sends. These it permutation). message a RekeyInd is the function derivation key the cause of impersonation an out by sent message Request P Join the receives that make to adversary the for possibility the out ruled if instance Therefore, messages. RekeyInd and Game Model 3-ACCE the in Proofs Security 5.4 a i n j olcigaltepoaiiisfo Game from probabilities the all Collecting that have we point, this To We happens. event either if experiment the aborts challenger the game, this in Therefore, If of impersonation no Since . Instances and ≤ ≤ ≤ = Pr[ = ≤ ≤ ≤ π i n a π π osntuetesm onAcp esg,i optsdierent computes it message, Accept Join same the use not does 6. π n n n n n n n j u k ` i h nywyt aethat have to way only the , n E E E E E E E π π to hsmasthat means this , j i u n · · · · · · · E ofrw aerldottepsiiiyfrteavrayt og ai onRequest Join valid forge to adversary the for possibility the out ruled have we far So a n optsteJi cetmessage. Accept Join the computes and , . n n n n n n n π π and ck 0 a .Therefore, 2. N N N N N N N i n j ] v ihdrn esi orcl eie by veried correctly is keys dierent with · = hneto (hence n n Pr[ n n n Pr[ π + J J J J J π j u E E E E E Pr[ adv k ` E E hr hs w messages. two these share · · · · · . km π 2 Pr[ a 1 a E Pr[ Pr[ adv Pr[ π + ] j u P, ent ] P + i n P 5 . a server oeatraievldRkyn esg,o h eeIdmessage RekeyInd the or message, RekeyInd valid alternative some E adv - hsipisete ogr fsc esg,o h blt fan of ability the or message, a such of forgery a either implies This . eso keys. session π ] auth k E E E P chan adv π π 3 a j ≤ P u to 5 4 6 + ] i a a a n j u hog h euecanlpoie by provided channel secure the through ) k π P chan + ] + ] + ] ( Pr[ cet eas thsbe rvddwt h eesr material necessary the with provided been has it because accepts - eesrl eevsteJi cetmsaesn by sent message Accept Join the receives necessarily i P, ent ae lc (Game place takes n 0 B P sec . adv P server 0 sid j - - adv adv adv sec ( E n ogr fa of forgery a and , ) auth 0 B Hence . 6 a ( P, ent 0 = + ] π B P ent P chan P chan + ) ( server sid i n B - 0 0 1 π π auth , π . - ) client π 0 j sid u auth j u adv Pr[ j - - u ) j adv u sec sec with sid cet yasmto,ti mle htete the either that implies this assumption, by accepts ( osntrcieteegniemsae rman from messages genuine these receive not does orcl eevsteedt eas ehv ruled have we because data these receives correctly B 6= ( ( ( E P chan a a oevr u oteE-euiyof EA-security the to due Moreover, . B B B P ent 0 .Ta is That ). 6 a oGame to 0 ) π 0 1 0 1 π , 0 = ] - ) + ) client + ) - j u auth sec j u a . hrfr,teavrayhsn hneof chance no has adversary the Therefore, . sid π ) hr xssa instance an exists there 4), + ( i n adv adv ( B . adv B si h eeCn esg etby sent message RekeyConf the if is π 0 n owre ysm instance some by forwarded and 1 P + ) j u P chan P chan 2 + ) π P, ent 0 a 0 0 cetsc aeil(nGame (in material a such accept k ` plcto esg neddto intended message application π server ,w aethat have we 6, adv - - - ed to sends auth sec j sec u adv sn te es u hsi ruled is this But keys. other using ( ( P chan B ( B 0 B P P chan 1 1 + ) 0 ) - 0 n h eodeett the to event second the and , sec ) - + π sec ( adv B j v adv ( 1 P hneto (hence B ) P ent . 1 0 ). P, ent 0 ) P , - client server auth π - + auth eso es(be- keys session k ` π ∈ adv ( i B n ( P B π 1 P ocompute to k P, ent ) 0 j u . ) , h Join the ) server Instances π π - auth k ` i n Since . sthe is π π ( j a v B 123 j u P sk 5). 0 ∈ is j ) .

5 124 Chapter 5 Security Models

b Now let Ei be the event that the adversary succeeds in making an instance accept maliciously during Gameb i through condition (b), where the parent instance is in N .

Gameb 0. This game corresponds to the EA-security game of the 3-party protocol Π described in Section 5.3.3 when the adversary targets NS, and tries to win through condition (b). Therefore we have that b Pr[E0] = pb.

Gameb 1. In this game, the challenger aborts the experiment if it does not guess which party Pj ∈ N and partner-party Pk ∈ J the adversary targets. Therefore

b b 1 Pr[E1] = Pr[E0] × . nN · nJ

b Game 2. Now the parties Pj ∈ N and Pk ∈ J are xed. v The only cryptographic operation that πj does in order to accept is verifying the RekeyInd message with keys sk that it does not compute but receives allegedly from Pk. Therefore, if v the adversary, on the one hand, succeeds in sending to πj keys sk of its choice, it can, on the v other hand, provide a consistent RekeyInd message (computed under sk), bringing πj to accept although no party in J (neither in E) is actually involved. This is possible either if the adversary 0 impersonates Pk to Pj, or if the adversary forges a valid P application message (intended to 0 Pj). We can reduce both events to the channel security with respect to P . Therefore we have

b b chan-sec Pr[E1] ≤ Pr[E2] + advP 0 (B1).

b Game 3. In this game we want to preclude the impersonation of Pk to Pj. Therefore, the challenger aborts if an adversary succeeds in making Pj accept with Pk as its purported partner. Therefore b b ent-auth Pr[E2] ≤ Pr[E3] + advP 0,client(B1).

b ` Game 4. Since no impersonation of Pk to Pj takes place, there is an instance πk ∈ Pk.Instances that computes the Join Accept message and the P session keys sk upon reception of the Join v v Request message forwarded by πj . Moreover πj .α = accepted and we have ruled out the 0 v forgery of a P application message (intended to Pj). Therefore, necessarily πj receives a Join ` Accept message and session keys sk, and these messages are computed by πk. v ` Now, the only reason why the transcript of the messages exchanged between πj and πk may v ` ` 0 dier (i.e., πj .sid 6= πk.sid) is that πk receives a P application message (carrying a Join Request v or a RekeyInd message) dierent than the one sent by πj . This implies the ability to forge a 0 ` 0 valid P application message intended to πk (i.e., with dierent P session keys than the ones ` used in the opposite direction). Hence, in this game, the challenger aborts the experiment if πk 0 v ever receives a valid P application message but that message is not computed by πj . We can reduce this event to the channel security with respect to P 0. We have

b b chan-sec Pr[E3] ≤ Pr[E4] + advP 0 (B1). v v So far, we have shown that for any instance πj ∈ Pj.Instances such that πj .α = accepted v ` ` v and πj .pid = Pk, there exists an instance πk ∈ Pk.Instances such that πk.sid = πj .sid. More- 0 ` v over, the EA-security of P implies that πk is the unique instance of Pk that shares with πj the P 0 handshake messages. This guarantees that the whole transcript of the P 0 messages is shared v ` ` v ` only by πj and πk. That is, πk is the unique instance of Pk such that πj .sid = πk.sid. where cetmsaebut message Accept desr a ocac fwnigteeprmn hog odto ( condition through experiment the winning of chance no has adversary the compute to permutation same the Game in out by received the compute to order instances by received message Game of instance no but message Request Game P Game Model 3-ACCE the in Proofs Security 5.4 i olcigaltepoaiiisfo Game from probabilities the all Collecting point, this To if experiment the aborts challenger the game, this in Therefore, E ∈ 6 P k b b b p n sietdi hsJi eus esg.Ta is That message. Request Join this in identied is rsmbycmue h onRqetrcie by received Request Join the computes presumably 6. 5. b 7. E J P π ≤ ≤ = Pr[ = ≤ ≤ ≤ ≤ ≤ ≤ i n eso esi fte ontuetesm onAcp message. Accept Join same the use not do they if is keys session nti ae h hlegraot h xeietif experiment the aborts challenger the game, this In nti ae h hlegraot h xeieti tde o us hc party which guess not does it if experiment the aborts challenger the game, this In π b ofrteei ninstance an is there far So and n j v ) htis That 2). E Pr[ n n n n n n n n Pr[ bcueafreyo a of forgery a (because π N N N N N N N N stenme fEsta a eprnrdwt ie JS. given a with partnered be can that EDs of number the is π i n E E · · · · · · · · E k ` and n n n n n n n n 5 b P 0 b 6 s h aeJi eus esg adtesm eiainfnto)in function) derivation same the (and message Request Join same the use b ] J J J J J J J J ] ] j P P ≤ · ≤ a o eti.Teeoew have we Therefore it. sent not has j Pr[ Pr[ n Pr[ n n n π Pr[ u oGame to Due . π eso es utemr,the Furthermore, keys. session Pr[ E E E E k ` Pr[ j v J J J J . s h aeJi eus n onAcp esgs n h same the and messages, Accept Join and Request Join same the use E E E E ( km · E p Pr[ Pr[ E 2 3 4 Pr[ b b b 1 b P jr + ] + ] + ] 6 ] b 7 b Pr[ + ] = Pr[ + ] eso es Hence keys. session E E + E adv adv adv 7 6 b b π 5 b p Pr[ + ] + ] + ] k ` ja P . P chan P ent P chan km i + ) ogr fJi Request Join of forgery E p p 0 0 0 ogr fJi Accept Join of forgery adv a optdta esg.Therefore message. that computed has P , - client jr jr b 5 b auth h nyrao why reason only The . - - Pr[ π Pr[ = ] 0 sec sec ,ti esg srcie by received is message this 2, adv + plcto esg neddto intended message application i n P ent + ( ( 0 ( E , b p B B B - ∈ client P ent auth adv ja oGame to 0 7 b 1 1 1 0 0 = ] ) + ) , + ) - P client π auth E ( i n i P ent + B . 4 b . Instances 0 pid ] adv , adv 1 - client adv ( . auth × 2 + ) B π = i n 1 P ent P chan n P ent 2 + ) . ( b 1 0 ck 0 P E , 0 B - P client , J ,w aethat have we 7, k adv auth - client auth - 1 . P sec = 2 + ) eso escmue by computed keys session j adv ] htcmue h onRequest Join the computes that ] P chan ( ( Therefore . π ( ≤ B B ≤ 0 B k ` π 1 1 P chan . 1 adv Pr[ - i ) + ) n km Pr[ sec P 2 + ) 0 π and j i n - ( E P chan sec E vrrcie ai Join valid a receives ever B = adv vrrcie ai Join valid a receives ever 0 7 b 1 6 b ( adv + ] π ) + ] π B - b sec k P chan ` j π v .Ta is That ). 1 0 . ol o compute not would ) P chan k ` p km ( p . P B 0 ja - 6 jr sec j 1 . - hrfr,the Therefore, . . hrfr both Therefore ) sec a enruled been has ( B ( 1 B ) 1 ) π k ` 125 are

5 126 Chapter 5 Security Models

Therefore we have that

ent-auth advΠ,N (A) ≤ pa + pb chan-sec chan-sec ent-auth ≤ nE · nN nJE · advP (B0) + 2advP 0 (B1) + advP 0,client(B1) ent-auth +advP,server (B0) ent-auth chan-sec +nN · nJ nEJ (pjr + pja) + advP 0,client(B1) + 2advP 0 (B1) ent-auth ≤ nE · nN · advP,server (B0) ent-auth chan-sec +(nE + 1) · nN · nJ · advP 0,client(B1) + 2advP 0 (B1) chan-sec +nE · nN · nJ pjr + pja + advP (B0)

because nEJ ≤ nE, and nJE ≤ nJ.

JS adversary. Let Ei be the event that the adversary succeeds in making an instance accept maliciously during Game i, where the instance parent is in J .

Game 0. This game corresponds to the EA-security game of the 3-party protocol Π described in Section 5.3.3 when the adversary targets JS. Therefore we have that

ent-auth Pr[E0] = advΠ,J (A).

Game 1. In this game, the challenger aborts the experiment if it does not guess which party Pk ∈ J the instance that will maliciously accept belongs to, and the corresponding partner-party Pj ∈ N . Therefore 1 Pr[E1] = Pr[E0] × . nJ · nN

Game 2. Now the party Pk ∈ J and its partner-party Pj ∈ N are xed. We want to rule out the event that there is no unique instance of Pj that is partnered (i.e., shares the same session ` identier sid) with any instance πk of Pk that ends in accepting state. v ` The non-existence of an instance πj ∈ Pj.Instances that is presumably partnered with πk implies that a server adversary successfully breaks the EA-security of P 0. Therefore, in this game, the challenger aborts the experiment if the adversary succeeds in breaking the EA-security of P 0 when the server side is targeted. Hence we have that

ent-auth Pr[E1] ≤ Pr[E2] + advP 0,server(B1).

0 v Game 3. So far, the EA-security of P ensures that πj is the unique instance to share the 0 ` ` handshake messages related to P exchanged with πk. However, in order to accept, πk has to receive in addition valid Join Request and RekeyInd messages (carried in P 0 application ` 0 messages). In turn, πk sends P application messages carrying a Join Accept message and session v ` v keys sk. This implies necessarily that πj is the unique instance such that πk.sid = πj .sid unless one of these P 0 application messages is forged by an adversary. Therefore, in this game, the challenger aborts the experiment if the adversary succeeds in forging P 0 application messages. We reduce this (in)ability to the channel security with respect to P 0. Therefore chan-sec Pr[E2] ≤ Pr[E3] + advP 0 (B1). ie,bt ntne opt h same the compute instances both (i.e., eie orcl h onAcp trcie si htmsaei optdby computed is message that if is receives it Accept Join the correctly veries h aedrvto function). derivation same the by sent way message only Request the Join Therefore the forgery. of Request Join a of event the out ruled also have we by Moreover computed is message this that but message message. Accept Join same the by computed message impersonate cannot 6. Game Therefore message. if experiment by forwarded protocol 5. Game to intended protocol messages of RekeyInd execution the triggered presumably has instance unique 4. Game Model 3-ACCE the in Proofs Security 5.4 adv olcigaltepoaiiisfo ae0t ae6 ehv that have we 6, Game to 0 Game from probabilities the all Collecting is That experiment. the winning of chance no has adversary the point, this to up Hence, if point, this To if experiment the aborts challenger the game, this in Hence, instance an of non-existence The party which guess not does it if experiment the aborts challenger the game, this In Π ent , J - auth P oti on h desr sual ofreaJi eus esg Gm )and 5) (Game message Request Join a forge to unable is adversary the point this To o,frec instance each for Now, ( sxed. is o h party the Now A π k π ` Pr[ = ) π Pr[ Pr[ k ` j a o optdsc esg.Teeoew have we Therefore message. a such computed not has v π eevsavldJi eus esg u oisac of instance no but message Request Join valid a receives = ≤ ≤ ≤ ≤ ≤ ≤ to j v π E E i ∈ n 4 π 5 P ] ] eie orcl h onAcp esg trcie,i od necessarily holds it receives, it message Accept Join the correctly veries n n n n n n n k P ` j π ≤ ≤ J J J J J J J j to i mle ogr.Teeoe nti ae h hlegraot the aborts challenger the game, this in Therefore, forgery. a implies n . · · · · · · · Hence . Pr[ E Instances Pr[ n n n n n n n P 0 P N N N N N N N ] k E E i · Gm ) hsipisthat implies This 2). (Game 5 n n n n Pr[ Pr[ Pr[ 6 E ∈ Pr[ + ] Pr[ + ] E E E E P J J J J π k E E E π ( (Pr[ (Pr[ · i n Pr[ .Therefore ). p uhthat such k 3 2 π ` Pr[ π htpeual optstemsae ihrsetto respect with messages the computes presumably that 1 . jr + ] + ] ck ] k ` i n pnrcpino onRqetpeual etby sent presumably Request Join a of reception upon π E ogr fJi Request Join of forgery E E ogr fJi Accept Join of forgery + i ∈ n E ∈ P 6= 4 hrfr,w aencsaiythat necessarily have we Therefore, . adv adv 6 5 4 Pr[ = ] Pr[ P p P + ] + ] + ] eso esbcuete s h aeipt,and inputs, same the use they because keys session π ja k i k ` . P chan P ent . Instances E + ) Instances . p p π 0 0 km adv , 6 - jr jr server k ` auth 0 = ] - . sec + ) E sid adv + P chan eesrl mle that implies necessarily 3 ( 0 ( ] p B P B = P chan adv × ja . - 1 sec 0 1 + ) ie,hscmue h onRqetand Request Join the computed has (i.e., + ) htcmue h onRqetmessage Request Join the computes that π ) uhthat such n - ( P chan j v 1 sec E B . 0 J sid π adv 1 adv ( . k ` + ) - B sec . ssncsaiyteJi Request Join the necessarily uses ] 1 P ent ] P chan + ) ( ≤ 0 ≤ B adv 0 , π - server auth 1 π i Pr[ n - Pr[ + ) sec adv k ` P ent vrrcie onAccept Join a receives ever .α 0 ( E ( , E - server B B P ent adv auth 6 = 5 1 0 1 + ] , + ] + ) - ) server auth accepted π P ent ( i n B 0 p , p P - server adv π ja 1 auth and ( jr i ) k ` B . a uptthat output has . π pnreception upon 1 P ent k ` ) ( π 0 . B , km - server k ` auth 1 hr sa is there , ontuse not do ) = ( P B π i 1 i n ) E ∈ 127 . π π ck i n i n .

5 128 Chapter 5 Security Models

Therefore, we have ent-auth ent-auth ent-auth ent-auth advΠ (A) ≤ advΠ,E (A) + advΠ,N (A) + advΠ,J (A) chan-sec chan-sec ent-auth ≤ nE · nJE nN · advP (B0) + advP 0 (B1) + advP 0,server(B1) ent-auth +advP,client (B0) chan-sec chan-sec ent-auth +nE · nN nJE · advP (B0) + 2advP 0 (B1) + advP 0,client(B1) ent-auth +advP,server (B0) ent-auth chan-sec +nN · nJ nEJ (pjr + pja) + advP 0,client(B1) + 2advP 0 (B1) chan-sec ent-auth +nJ · nN nEJ (pjr + pja) + advP 0 (B1) + advP 0,server(B1) chan-sec chan-sec ≤ nE · nN · nJ 2advP (B0) + 3advP 0 (B1) + 2pjr + 2pja ent-auth ent-auth +advP 0,client(B1) + advP 0,server(B1) ent-auth ent-auth +nE nJ · advP,client (B0) + nN · advP,server (B0) chan-sec ent-auth ent-auth +nN · nJ 3advP 0 (B1) + advP 0,client(B1) + advP 0,server(B1) because nEJ ≤ nE, and nJE ≤ nJ.

Channel security. Now we prove the channel security property.

chan-sec Proof. Let advΠ (A) be the advantage of the adversary in winning the channel security 1 experiment. Let Ei be the event that the adversary wins in Game i, and advi = Pr[Ei] − 2 .

Game 0. This game corresponds to the channel security game described in Section 5.3.3. Therefore 1 1 Pr[E ] = + adv = + advchan-sec(A). 0 2 0 2 Π

Game 1. In this game, the challenger proceeds as in the previous game but aborts and chooses a bit b uniformly at random if there exists an oracle of some party in E ∪ N ∪ J that accepts maliciously. In other words, in this game we make the same modications as in the games performed during the entity authentication proof. Hence we have ent-auth adv0 ≤ adv1 + advΠ (A).

Game 2. In this game, the challenger aborts the experiment if it does not guess the three parties involved in the session. Therefore 1 adv2 ≥ adv1 × nE · nN · nJ because nJE ≤ nJ, and nEJ ≤ nE. n u v ` n Let πi , πj , πj , and πk be the four instances sharing the same bid, with πi .parent ∈ E, u v ` πj .parent = πj .parent = Pj ∈ N , and πk.parent = Pk ∈ J , such that, in the one hand, n u n u v ` πi and πj are partnered (πi .sid = πj .sid), and, in the other hand, πj and πk are partnered v ` (πj .sid = πk.sid).

Game 3. In this game, the challenger aborts the experiment if the adversary is able to nd v ` πj .b or πk.b (that is if the adversary wins the experiment when targeting the NS-JS link). We can reduce such an event to the channel security with respect to P 0. Therefore chan-sec adv2 ≤ adv3 + advP 0 (B1). hnkydwt h eso es n h eto-ih euiynto seuvln othe to equivalent is notion security left-or-right the and keys, session the with keyed when adv adv Let game. Proof. Authentication. Entity 5.2. Theorem of proof full the give we section, this In for Proof Security Extended 5.4.3.2 with CS-security the break to is successful be to adversary to the respect for possibility only the Now by provided channel the Therefore through (sent random. plaintexts distinguishing in succeeds adversary to the respect for with indistinguishability real-from-random plaintexts the Hence [BDJR97]. security notion left-or-right real-from-random guarantees latter The function. channel encryption this underlying of security the the upon Indeed relies plaintexts. the for indistinguishability real-from-random by keys sent session also corresponding the distinguishing to in respect with to security channel respect the with security channel the breaking 5. Game to respect with security channel the to the get to of try rst can adversary the successful, 4. Game Model 3-ACCE the in Proofs Security 5.4 olcigaltepoaiiisfo ae0t ae5 ehv that have we 5, Game to 0 Game from probabilities the all Collecting an if experiment the aborts challenger The rule. abort an add we game this in Therefore, π P ent P, ent j v adv hog h euecanlpoie yteprotocol the by provided channel secure the through ) server - - auth auth Let Π chan ( ( P adv A A adv o,teavraycntyt target to try can adversary the Now, o h nyrmiigpsiiiyi re o h desr ob ucsflis successful be to adversary the for order in possibility remaining only the Now - sec htis That . ) ) P P ent onstepoaiiyta evr(SJ)avraysced.W aethat have We succeeds. adversary (NS-JS) server a that probability the bounds k ( ≤ P, ent A to - client auth adv - = ) auth P ( ≤ ≤ ≤ ≤ ≤ ≤ j P, ent ( A A hog h euecanlpoie by provided channel secure the through client - ) auth ) n n adv adv n n n etepoaiiyta h adversary the that probability the be onstepoaiiyta let(D desr uces and succeeds, adversary (ED) client a that probability the bounds P E E E E E ( is ecnie h niyatetcto property. authentication entity the consider we First 0 · · · · · A 1 0 . n n n n n + + ) N N N N N adv adv adv · · · · · n n n n n adv 4 3 J J J J J adv Π ent · ≤ ≤ P P, ent adv adv adv adv adv - 5 auth P server adv adv P eisipiil nteiaiiyo uha adversary an such of inability the on implicitly relies - auth ≤ 0 oa AN LoRaW 3 4 P chan 5 2 Therefore . ( + 2 + 3 + 5 4 + adv A ( + + - A ) adv sec adv adv adv P P chan ) adv adv P ( . π B P chan Π ent eso es( keys session h nblt fa desr nbreaking in adversary an of inability The . i n P chan P chan - 0 0 P chan P chan sec nLRWN1.1 LoRaWAN in sk 3 + ) - 0 0 or 0 0 auth - sec ( - - - - B sec sec rmrno.Teessinky are keys session These random. from π sec sec ( ( 0 j u B A adv ( ( ) ( ( B B . ie,teE-Sln) nodrt be to order In link). ED-NS the (i.e., 1 B B ) ) 1 1 1 1 P P chan ) ) ) ) A 0 . . + 0 ecnrdc hspossibility this reduce can We . sk + + - isteett authentication entity the wins adv P sec etby sent ) adv adv 0 ( htcanlguarantees channel That . B Π ent Π ent Π ent 1 - ) auth - - auth auth + P ( A adv ( ( k A A ) to ) ) Π ent P - j auth teparent (the P ( A 0 from ) ) 129

5 130 Chapter 5 Security Models

Client adversary. Let Ei be the event that the adversary succeeds in making a client instance accept maliciously during Game i.

Game 0. This game corresponds to the EA game of the 2-party protocol P when the client side is targeted. Thus we have

ent-auth Pr[E0] = advP,client (A).

Two dierent clients (EDs) cannot share the same transcript because they will at least dier with the client identiers. On the client side, each session is individualised with the parameters idE, idJ , cntE (they appear in clear in the rst message sent by the client). On the server side, each session is individualised with the parameters idJ , idE, cntJ . The Join Accept message sent −1 by a server instance cannot repeat unless a collision appears in the function AES (MK1, ·). An adversary can then try to forge a valid Join Accept message. This will be handled in the successive experiments described below.

s Game 1. In this game, the challenger tries to guess which client instance πi will be the rst instance to accept maliciously. If the guess is wrong, then the game is aborted. Hence 1 Pr[E1] = Pr[E0] × q · nC where nC is the number of client parties, and q the number of instances per party.

s Game 2. In this game we replace the KDFmk function used by πi to compute the key MK3 FKDFmk KDF with a random function MK1 . We do the same for any server instance that uses the mk s function with the same master key MK1 as πi in order to compute MK3. We use the fact that the master key MK1 is uniformly drawn at random. Therefore distinguishing Game 1 and Game 2 implies an algorithm B1 able to distinguish the KDFmk function from a random function. Hence Pr[E ] − Pr[E ] ≤ advprf (B ) = advprf (B ). 1 2 KDFmk 1 AES 1

s Game 3. In this game we replace the MAC function used by πi to verify the Join Accept τ FMAC message (verication of J ) with a random function MK3 . We do the same for any server s instance that uses the MAC function with the same master key MK3 as πi in order to compute τJ . MK ← FKDFmk (id ) MK Since 3 MK1 E , we use the fact that the key 3 is uniformly drawn at random. Therefore distinguishing Game 2 and Game 3 implies an algorithm B0 able to distinguish the MAC function from a random function. Hence

prf Pr[E2] − Pr[E3] ≤ advMAC(B0).

Game 4. The server instance computes the Join Accept message in the following way: −1 Join Accept = AES (MK1, cntJ kidN kprmskτJ ). In this game we replace the AES decryption function used by the server instance with a random permutation PermMK1 . Moreover if a client instance uses the same master key MK1 to “decrypt” the Join Accept message, then we AES Perm−1 replace the encryption function with the inverse permutation MK1 . We use the fact that MK1 is uniformly drawn at random. Therefore distinguishing Game 3 and Game 4 implies −1 an algorithm B2 able to distinguish AES (MK1, ·) from a random permutation. Hence

prp Pr[E3] − Pr[E4] ≤ advAES(B2). hc atrkey master which AES onAccept Join the received has that instance uncorrupted other some by computed message Accept Join adm ec,w a euetefreyo eeCn esg othe to message RekeyConf a of forgery the StAE reduce can we Hence, random. key master which the function knowing 6, instance Game server In the use. to to and instance client the to accessible the by output are message. that output has that to far) conversation so matching messages a exchanged having of instance transcript server no exists instance there client the but same if the aborts share challenger not the do game, instances two the that so 7. Game algorithm MK key master same function 6. Game of (correctness conditions both that probability the Hence session. cnt instance client the key to master accessible which cnt only knowing is instance that server permutation the random to and truly a evaluating by is that than greater not (and message that Accept probability Join the as value some instance server the to and value correct instance client the key to master compute accessible which to knowing only is able that be function random adversary truly the that 3, assume Game to us Let correct. be must verications both veries client to conversation if iment by sent message rst 5. Game Model 3-ACCE the in Proofs Security 5.4 h keys The from computes instance client the 4, Game to Due J J ( hrfr h ubro eann orc ausfor values correct remaining of number the Therefore . 2 aaee:teeare there parameter: MK server suiomydana adm hrfr itnusigGm n ae6ipisan implies 6 Game and 5 Game distinguishing Therefore random. at drawn uniformly is F π F 1 MK KDF i ucinue ocmueta esg.Therefore message. that compute to used function s MK KDF B , τ nti aew elc the replace we game this In ofr h nypsiiiyfrteavrayt i sfrigaRkyofmessage RekeyConf a forging is win to adversary the for possibility only the far, So nti ae ewn oesr httecin instance client the that ensure to want we game, this In K 1 · vrrcie onAcp esg u osre ntnehvn matching a having instance server no but message Accept Join a receives ever ← J ) 2 τ ˜ bet itnus the distinguish to able 2 2 a c a e − ← ucinhsbe elcdwt rl admfunction random truly a with replaced been has function τ ie,tepoaiiythat probability the (i.e., , ed h aefraysre ntneta ssthe uses that instance server any for same the do We . Perm µ hti nyacsil otecin ntneadt h evrisac knowing instance server the to and instance client the to accessible only is that J K τ ˜ . π KDF F n hcsthat checks and MK c i i s svldwe h desr ik onAcp esg trno snot is random at message Accept Join a picks adversary the when valid is MK MK MAC 2 n (optionally) and , a uptta esg.AtrrciigteJi cetmsaethe message Accept Join the receiving After message. that output has MK c 3 π KDF 2 Pr[ ( 2 ucin and function, i s 1 id as hrfr,w d naotrl.Tecalne brsteexper- the aborts challenger The rule. abort an add we Therefore, . oue hrfr,tekeys the Therefore, use. to ( cnt E J 2 MK a π k β 5 cnt Pr[ i s ] = Pr[ J osbevle for values possible − nodrt compute to order in k τ AES ˜ 3 id E E Pr[ E oue hrfr h rbblt fteavrayt rvd a provide to adversary the of probability the Therefore use. to and k 6 N 4] ] cnt cnt cnt k E ( − KDF K MK prms K − 6 cnt KDF J J Pr[ J τ ] ˜ a a e e k Pr[ ≤ screti tmost at is correct is sotu by output is = scret nodrt cettemsaea valid, as message the accept to order In correct. is id r sdt opt h eeCn message. RekeyConf the compute to used are J a 2 E aet evrd ehv that have we veried, be to have ) adv , k N E ucinfo admfnto.Hence function. random a from function a τ 7 · τ ˜ J ) k ucinue by used function ] 5 ) sa most at is ) ] prms ≤ ucinhsbe elcdwt rl random truly a with replaced been has function KDF prf o oevalue some for ≤ adv cnt π sid 2 a Perm i − s ( ) B K StAE sae hrfr eada br ue nthis In rule. abort an add we Therefore . µ J K vrrcie ai esg RekeyConf message valid a receives ever MK KDF Perm scmue ytecin yeautn a evaluating by client the by computed is ahnwssintigr e value new a triggers session new Each . 1 × a e c = ) e euetefc httemse key master the that fact the use We . MK , server 2 2 K 1 a − β MK − nGm ,the 2, Game In . adv 1 c 2 cnt oue Let use. to i µ 2 − 1 ( ( β oevrteavrayprovides adversary the Moreover . (2 and , B cnt π 1 τ 1 ˜ J 3 AES prf β i s ( ) . onAccept Join n orc value correct a and is J ocompute to − . k ( K 2 id B 1) β a 1 e N / − π ) β KDF r nfrl rw at drawn uniformly are 2 π . k i s β u i etebtlnt fthe of length bit the be s prms ie,saigtesame the sharing (i.e., tayssin Since session. any at eevseatythe exactly receives ≤ F sAE KDF a MK KDF ) K 2 ucinwt the with function oevalue some β k a e scrt fthe of -security 1 τ mk ˜ − c iharandom a with ) = .Hnethe Hence ). 1 hti only is that tthe at KDF cnt K J c e MK Due . mk , cnt u K 131 -th = c i J 2 1 ,

5 132 Chapter 5 Security Models

s To that point the only way for an adversary to make πi accept maliciously is to send a RekeyConf message dierent from all the messages sent by all the server instances, such that RekeyConf is valid. However, in such a case the challenger aborts. Therefore

Pr[E7] = 0. Collecting all probabilities from Game 0 to Game 7, we have that ent-auth advP,client (A) = Pr[E0]

= q · nC · Pr[E1] prf ≤ q · nC Pr[E2] + advAES(B1)

prf prf ≤ q · nC Pr[E3] + advMAC(B0) + advAES(B1)

prp prf prf ≤ q · nC Pr[E4] + advAES(B2) + advMAC(B0) + advAES(B1)

−µ −β prp prf ≤ q · nC Pr[E5] + 2 (1 − 2 ) + advAES(B2) + advMAC(B0)

prf +advAES(B1)

prf −µ −β prp ≤ q · nC Pr[E6] + advAES(B1) + 2 (1 − 2 ) + advAES(B2)

prf prf +advMAC(B0) + advAES(B1) sae −µ −β prp ≤ q · nC Pr[E7] + advStAEserver (B3) + 2 (1 − 2 ) + advAES(B2) prf prf +advMAC(B0) + 2advAES(B1)

sae −µ −β prp prf ≤ q · nC advStAEserver (B3) + 2 (1 − 2 ) + advAES(B2) + advMAC(B0)

prf +2advAES(B1)

Server adversary. Let Ei be the event that the adversary succeeds in making an server instance accept maliciously during Game i.

Game 0. This game corresponds to the EA game of the 2-party protocol P when the server side is targeted. Thus we have ent-auth Pr[E0] = advP,server (A).

t Game 1. In this game, the challenger tries to guess which server instance πj will be the rst instance to accept maliciously. If the guess is wrong, then the game is aborted. Hence 1 Pr[E1] = Pr[E0] × q · nS where nS is the number of server parties, and q the number of instances per party.

t Game 2. We replace the MAC function used by the server instance πj to verify the rst τ FMAC message from the client instance (verication of E) with a random function MK1 . We do the same for any client instance that uses the MAC function with the same master key MK1 as t πj in order to compute τE. We use the fact that the key MK1 is uniformly drawn at random. Therefore distinguishing Game 1 and Game 2 implies an algorithm able to distinguish the MAC function from a random function. Hence prf Pr[E1] − Pr[E2] ≤ advMAC(B0). ae6. Game st edaRkyn esg ieetfo l h esgssn yaltecin instances, Therefore client aborts. the challenge all the case, by a sent such messages in However, the valid. all is from RekeyInd dierent that such message RekeyInd a send to is Hence message. the the to compute message to RekeyInd a used forging function of possibility the reduce can The message. that output keys has that far) to so conversation messages matching keys exchanged a of having transcript instance same client the no sharing exists there but RekeyInd message algorithm an implies 5 Game the and distinguish 4 to Game able distinguishing Therefore random. at drawn uniformly key master F 5. Game the distinguish to able algorithm Therefore an function. implies 4 Game and key 3 master Game the that fact the use KDF and 4. Game knowing instance client the most and at instance server the to key accessible the only is that 2, function Game random to Due message. message 3. Game Model 3-ACCE the in Proofs Security 5.4 MK KDF ota on,teol a o navrayt aetesre instance server the make to adversary an for way only the point, that To K 2 n a K K ed h aefraycin ntneta ssthe uses that instance client any for same the do We . c i ucinwt h aemse key master same the with function 2 c c e e MK 2 , , iharno function random a with onRequest Join − K K µ erpaethe replace We erpaethe replace We nti ae h hlegraot ftesre instance server the if aborts challenger the game, this In instance server the if aborts challenger the game, this In c c i MK Therefore . i 1 1 1 , , oue hrfr h rbblt fteavrayt rvd orc value correct a provide to adversary the of probability the Therefore use. to K K 2 c i c i 2 2 as n (optionally) and , and , π j = t KDF Pr[ Pr[ nodrt compute to order in K id E E a e KDF KDF J a τ 4 3 r nfrl rw trno,det ae4adGm ,we 5, Game and 4 Game to due random, at drawn uniformly are k Pr[ ] E ] ucinfo admfnto.Hence function. random a from function id − − E ← n MK a E Pr[ Pr[ k ucinue by used function ucinue ytesre instance server the by used function F 5 cnt Pr[ MK KDF ] F E E K − 1 MK MAC 5 E 4 E suiomydana adm hrfr distinguishing Therefore random. at drawn uniformly is a 1 e c Pr[ ] ] k ed h aefraycin ntneta ssthe uses that instance client any for same the do We . 2 r sdt opt h eeIdmsae ic the Since message. RekeyInd the compute to used are ≤ 1 ≤ τ ] ( E E − id adv adv MK u hr sn letisac hthsotu the output has that instance client no is there but 6 J Pr[ K ] k ≤ KDF prf KDF prf id a e 1 E euetefc httemse key master the that fact the use We . adv E as 3 a c k ] ( π ( cnt B B ≤ π j StAE sae t 1 j 1 t ocompute to = ) = ) 2 E nodrt compute to order in − client ) µ scmue yeautn truly a evaluating by computed is . adv adv ( B 3 AES prf AES prf KDF ) KDF sAE . ( ( K B B a a e scrt fthe of -security 1 1 n ) ) ucinwt h same the with function iharno function random a with π π ucinfo random a from function . . π j j t t j t π vrrcie valid a receives ever vrrcie valid a receives ever ocompute to j t cetmaliciously accept K c i 1 and Pr[ StAE K E K MK 6 π c i c e 2 0 = ] j t , τ We . client K (i.e., E 133 2 c i is is 1 .

5 134 Chapter 5 Security Models

Collecting all the probabilities from Game 0 to Game 6, we have that ent-auth advP,server (A) = Pr[E0]

= q · nS · Pr[E1] prf ≤ q · nS Pr[E2] + advMAC(B0)

−µ prf ≤ q · nS Pr[E3] + 2 + advMAC(B0)

prf −µ prf ≤ q · nS Pr[E4] + advAES(B1) + 2 + advMAC(B0)

prf −µ prf ≤ q · nS Pr[E5] + 2advAES(B1) + 2 + advMAC(B0) ≤ q · n Pr[E ] + advsae (B ) + 2advprf (B ) + 2−µ + advprf (B ) S 6 StAEclient 3 AES 1 MAC 0 ≤ q · n advsae (B ) + 2advprf (B ) + 2−µ + advprf (B ) S StAEclient 3 AES 1 MAC 0 Therefore we have that ent-auth ent-auth ent-auth advP (A) ≤ advP,client (A) + advP,server (A) sae −µ −β prp prf ≤ q · nC advStAEserver (B3) + 2 (1 − 2 ) + advAES(B2) + advMAC(B0)

prf +2advAES(B1) +q · n advsae (B ) + 2advprf (B ) + 2−µ + advprf (B ) S StAEclient 3 AES 1 MAC 0 h ≤ q n · advsae (B ) + n · advsae (B ) S StAEclient 3 C StAEserver 3 prf prf + (nC + nS) advMAC(B0) + 2advAES(B1)

prp −µ −β i + nC · advAES(B2) + 2 nC(1 − 2 ) + nS In addition, we have also prf −µ Pr[forgery Join Request] ≤ pjr = advMAC(B0) + 2 prf prf prp −µ −β Pr[forgery Join Accept] ≤ pja = advAES(B1) + advMAC(B0) + advAES(B2) + 2 (1 − 2 )

Channel Security. Now we consider the channel security property.

chan-sec Proof. Let advP (A) be the advantage of the adversary A in winning the channel secu- chan-sec rity experiment against an instance of some client or server party. That is advP (A) = s 1 s Pr[πi .b = b] − 2 , where (πi , b) is the tuple output by the adversary when it terminates the 1 CS game. Let Ei be the event that the adversary wins in Game i, and advi = Pr[Ei] − 2 .

Game 0. This game corresponds to the CS game of the 2-party protocol P . Therefore 1 1 Pr[E ] = + advchan-sec(A) = + adv . 0 2 P 2 0

Game 1. In this game, the challenger aborts and chooses a bit b uniformly at random if there exists an instance of some client or server party that accepts maliciously. Hence we have ent-auth adv0 ≤ adv1 + advP (A). h rbblt for probability The adv the breaking in attacker an A Otherwise challenger. have we Therefore 3. Game in to response the to response instance. adversary function random a key that fact encrypt keys the to session server) use the We (resp. client messages. the the by MAC used scheme and encryption authenticated underlying the of 4. Game functions the distinguish to able algorithm MK as functions the key session the K 3. Game instance its and party, server or client some to sponding Therefore adversary. the by targeted instance server unique a is there 2. Game Model 3-ACCE the in Proofs Security 5.4 client c i If indices the knows it is That targets. it instance the knows adversary the far, So is instance which guess not does it if experiment the aborts challenger the game, this In π 1 StAE sae , i s K A 2 K nodrt opt hs eso es euetefc httemse keys master the that fact the use We keys. session these compute to order in r nfrl rw trno.Teeoedsigihn ae2adGm mle an implies 3 Game and 2 Game distinguishing Therefore random. at drawn uniformly are a client e (resp. c i client hrfr hs esaerno.Teadversary The random. are keys these Therefore . 2 iharno function random a with B A ( (resp. nti aew osrc nadversary an construct we game this In ofr o n letinstance client any for far, So client nti aew elc the replace we game this In A B client adv A KDF 3 client ) server K A (resp. (resp. 2 K A (resp. client a ≤ e c (resp. server c e B iharno function random a with ihtesm atrkey master same the with ownteC xeiet oevr yasmto,teavnaeof advantage the assumption, by Moreover, experiment. CS the win to ) , adv client K adv B (resp. B c upt tuple a outputs ) i server A 3 1 A client , adv (resp. + StAE sae server server K adv sAE owrsany forwards ) A c i 4 (resp. 2 server bet i h Seprmn gis let(ep server) (resp. client a against experiment CS the win to able ) n admfunction random a and , server ≤ .I owrsany forwards It ). KDF prf B scrt fteatetctdecyto ceei tmost at is scheme encryption authenticated the of -security adv π adv ( server F B j t .Otherwise ). c MK KDF B rs.cin instance client (resp. 3 ( 2 ) StAE sae B server .Hence ). odtecretvalue correct the nd to ) = 1 1 c + ) KDF erpaeas the also replace We . adv π ( adv client π i s isabta admadsnsi oischallenger. its to it sends and random at bit a ips ) KDF i s rs.sre instance server (resp. b , 4 adv Encrypt F ( 1 c MK B MK KDF = ) × ucinue ocmuetessinkeys session the compute to used function 3 then , c KDF prf + ) B adv Decrypt q 2 and a client 1 2 B ed h aefrayisac htuses that instance any for same the do We . and , a · client 3 adv ( ( n . π B B KDF 1 C i s (resp. client 1 , StAE sae = ) F · KDF (resp. · π ( ) n MK KDF π π i a s j S ur to query t j . t server (resp. hti atee with partnered is that ) B rmrno ucin.Therefore functions. random from , adv . 2 B a a · client KDF ) server B ihtesm atrkey master same the with sue ocmuetesession the compute to used is ( ur to query 3 b B server π 2 + sa es h rbblt for probability the least at is B 3 i (resp. s a ) eae stechallenger the as behaves ) ,edn nacpigstate, accepting in ending ), server F . ucinue ocompute to used function Encrypt gis the against ) adv MK KDF forwards ) Decrypt 1 c AES prf B sue ocompute to used is server ( ( B · ) 1 n ed the sends and , sbito an on built is ) ) ( . sAE · ) b n sends and , π MK i oits to i s , -security . s MK corre- 1 sAE and K 135 c e 2 ,

5 136 Chapter 5 Security Models

Collecting all the probabilities from Game 0 to Game 4, we have that

chan-sec advP (A) = adv0 ent-auth ≤ adv1 + advP (A) 2 ent-auth ≤ q · nC · nS · adv2 + advP (A) 2 prf ent-auth ≤ q · nC · nS adv3 + 2advAES(B1) + advP (A)

2 prf ent-auth ≤ q · nC · nS adv4 + 2advAES(B1) + advP (A) ≤ q2 · n · n advsae (B ) + advsae (B ) + 2advprf (B ) C S StAEclient 3 StAEserver 3 AES 1 ent-auth +advP (A)

5.4.3.3 sAE Security in LoRaWAN 1.1

Here we give a sketch of proof for the sAE-security of the AEAD functions StAEclient and StAEserver used in LoRaWAN 1.1.

Sketch of proof. Bellare and Namprempre [BN00] show that the Encrypt-then-MAC (EtM) construction is IND-CCA and INT-CTXT if the underlying symmetric encryption function is IND-CPA and the underlying MAC function is SUF-CMA-secure. Moreover, Rogaway and Shrimpton [RS06] show that an AEAD encryption scheme that is IND-CCA and INT-CTXT provides AE-security. In addition, the CTR mode is proved IND-CPA by Bellare, Desai, Jokipii, and Rogaway [BDJR97] under the assumption that the block cipher is a good PRF. Iwata and Kurosawa [IK03c] show that CMAC is SUF-CMA-secure if the underlying block cipher is a good PRP. Finally we recall that the AEAD encryption schemes used in LoRaWAN 1.1 follow the EtM paradigm. One, StAEserver used to encrypt downlink messages, is composed of AES-CTR and a tweaked version of AES-CMAC. The second AEAD scheme, StAEclient used to encrypt uplink messages, is composed of AES-CTR, and a concatenated hash combiner made with a tweaked version of AES-CMAC. Moreover a monotonically increasing counter (embedded in each frame’s header) is used to compute the encryption keystream, and involved in the MAC computation. Hence the sAE-security of the AEAD functions StAEclient and StAEserver. 5

hsi atclrycnein ntecneto o hr e f(o-eore end-devices (low-resource) of set a where IoT of context the in convenient particularly is This Contents values. pseudo-random setting). public-key the in used commonly (i.e., model security strong capabilities). computational heavier has (which constrained). server most back-end the amount a is smallest with practice, the communicates in (which, while party run, same protocol the a that by of such done responder implementation always is or an calculation initiator yields of either This be responder. can the party and any initiator the between roles the it call We on secrecy. Exchange the based forward Key in solely guarantee Authenticated secrecy is does forward present yet we of and protocol issue functions, exchange the symmetric-key key tackling authenticated at The aims that setting. symmetric-key scheme two-party a chapter, this secrecy. in forward from benet some not for then can heavy which too are devices, low-resource algorithms of public-key However class scheme. Die-Hellman the on based K h eut fti hpe aebe atal ulse n[ACF20]. in published partially been have zero chapter of this use of makes results which The SAKE of variant a devise to a possibility in the secure investigate and we sound Finally are protocols the that show we approach, security provable a Using inverting allows that SAKE, of mode complementary a SAKE-AM, describe we addition, In describe, we 4, and 3, Chapters in protocols deployed widely two of cryptanalysis the After hpe .I atclr hycnpoiefradscey silsrtdb protocols by illustrated as secrecy, forward provide can in they illustrated particular, as In cryptography, 1. symmetric-key Chapter in protocols than properties security protocols exchange ey . oprsnwt h HParadigm DH the with Comparison 6.6 SAKE for Proofs 6.3 . admfe ain fSAKE of Variant Random-free A SAKE of Mode 6.5 Complementary a SAKE-AM: 6.4 Secrecy Forward with Protocol AKE Symmetric-key 6.2 Motivation 6.1 .. onns fSAKE of Soundness 6.3.1 .. euiyo SAKE of Security 6.3.2 Protocol the of Description Concepts 6.2.3 Key Nutshell a 6.2.2 In 6.2.1 .. owr erc nteSmerckySetting Symmetric-key the in Secrecy Forward 6.1.2 Context 6.1.1 AE w-at AKE Two-party a SAKE: ...... rSK o short. for SAKE or , ...... nteaymti-e etn r nw opoiestronger provide to known are setting asymmetric-key the in ...... Symmetric-key 6 148 159 158 156 143 140 145 148 143 152 140 140 144

6 140 Chapter 6 SAKE: a Two-party AKE

6.1 Motivation

6.1.1 Context An authenticated key exchange (AKE) protocol executed between two parties aims at providing unilateral or mutual entity authentication, and computing a fresh shared session key. Well- known two-party authenticated key exchange protocols make use of digital signatures to provide authentication, and apply the Die-Hellman (DH) scheme [DH76] to compute a shared session key. However, such protocols can be too heavy for low-resource devices. More suited protocols, solely based on symmetric-key functions, have been proposed (e.g., [BR94; PST+02; PS04; Int08; BM03b; Glo18; Zig14; Sor17] to cite a few), including widely deployed ones (e.g., in 3G/UMTS [3rda] and 4G/LTE [3rdb]). Such symmetric-key protocols are needed in various applications, ranging from Wireless Sensor Networks (WSNs), Radio Frequency Identication (RFID) tags, smart cards, Controller Area Networks (CANs) for vehicular systems, smart home, up to industrial Internet of Things (IoT). Yet, existing symmetric-key based protocols lack a fundamental security property usually provided by the DH scheme: forward secrecy [Gün90; DvW92]. Forward secrecy is a very strong form of long-term security which, informally, guarantees that future disclosures of some long-term secret keys do not compromise past session keys. It is widely accepted that this property can only be provided by asymmetric schemes (at least regarding stateless protocols). Indeed, in protocols based on symmetric-key functions, the two parties must share a long-term symmetric key (which the session keys are computed from). Therefore the disclosure of this static long-term key allows an adversary to compute all the past (and future) session keys (if the adversary has eavesdropped on the communications, as it is assumed in usual security models).

6.1.2 Forward Secrecy in the Symmetric-key Setting In this section, we summarise several works that aim at achieving some form of forward secrecy in the symmetric-key setting. We stress that the goals of the schemes briey described below are not necessarily the same as ours (essentially, performing a key exchange in our case). Nonethe- less, the small number of existing symmetric-key protocols that provide forward secrecy, and the lukewarm security level they achieve illustrate that combining symmetric-key cryptography and (a strong form of) forward secrecy is a non-trivial task.

Dousti and Jalili [DJ14] describe a key exchange protocol where the shared master key is updated based on time. Their protocol requires perfect synchronism between the parties otherwise this leads to two main consequences. Firstly, in order to handle the key exchange messages, the parties may use dierent values of the master key corresponding to consecutive epochs, which causes the session to abort. Secondly, this allows an adversary to trivially break forward secrecy. Once a party deems the protocol run is correct and the session key can be safely used (i.e., once the party “accepts"), the adversary corrupts its partner (which still owns the previous, not updated yet, master key), and computes the current session key. Furthermore, achieving perfect time synchronisation may be quite complex in any context, in particular for low-resource devices. Contrary to Dousti and Jalili, the protocol we propose explicitly deals with the issue of updating the master keys at both parties without requiring any additional functionality (such as a synchronised clock).

In the RFID eld, the protocol proposed by Le, Burmester, and de Medeiros [LBM07] aims at it.Tidy eycrnsto a ml utpeudtso h atrky tonce at keys master the of updates multiple imply may resynchronisation Thirdly, width. of issue the with teshm fBiradPyi n Ae9 isa iiigta muto aclto,but calculation, of amount that limiting at aims [Ame09] and Peyrin and Brier of scheme (the keeps server the tag, the and reader the between desynchronisation possible the with deal To uhniae esgsaemd nrswrh) hi loihsaebsdo key-evolving on based previously are (i.e., algorithms messages Their of untrustworthy). forgeries made antedated are or messages constructions messages, authenticated past Their of algorithm). constructions decryption encryption practical against symmetric and protect MAC, (e.g., denitions primitives formal secure propose They forward of [BY03]. Yee and Bellare by tigated drawbacks. these all avoids scheme Our keys). encryption possible of number limited a to leads it band- (at consumes counter which the resynchronise, to sending parties Secondly, two exhaustion. the any for counter avoid necessary a to is such order periodically) of in least size a the enough build Firstly, to large drawbacks. way be several inecient) yields must (and this simple to But to a order protocol. is not secret counter) in is forward large information [Ame09]) suciently as additional a well sending as (as (such generally Peyrin resynchronise More and Brier authentication. of mutual purpose deal provide the to addition, need In not secrecy. does scheme forward the not Therefore, does client). server the the to and upon messages unidirectional, only encrypted is key send channel encryption to secure The an need only. (the compute client message to the client’s supposed to a is of respect Brier and reception with Moreover, incorruptible, secrecy side. as forward client deemed on the is focus on server parallel [Ame09]) increasing in as implies well stored (as keys limit that Peyrin of that is and number Increasing scheme the this reduced. and the of size is for drawback counter keys message main previous the encryption encrypted The the possible key. the from of corresponding with derived the number counter is compute the the the to (key) in send able leaf involved must be each is client to whose server which The tree counter, counter. a (short) the to a and the use belong one on to keys storage, and The the parallel implies update. solution in keys Their keys low. used several (directly be of key must side, master side client the server compute the to on secrecy, key) calculation forward of encryption to as amount addition the In that [Ame09]. is proposal constraint previous another a improving at aims that setting, party targeted the as soon as party either corrupt to adversary accepts. the the allows few) Yet use (a one). we memory previous model in a does security keeps (including values also these epochs parties dierent all the to of of disclosure corresponding one key tag scheme, master a our a corrupting In of and al. accepts. forbidden, samples et is Le it Yet, corruption once server accepts). only any party allowed where targeted is model the that a once models in partners, (i.e., protocol the models their of security analyse with any strong together corrupt key, in to master insecure adversary the intrinsically the of is allow the value scheme to previous the respect the one, with keeps current key always the Hence, session server previous the value. the since previous compute fact, the can In stores server. tag still the tag the corrupts the up computes who whereas catch server key, adversary to the master an desynchronisation, able updated of is the case update server from in not the key that, does dropped), session implies tag is This the message session. If last next one. the the previous when during the happens and (which current key the master key: its run. the protocol of the values secure throughout consecutive a updated two establish is to key order master in The key describe). session not a do computing they at (which and server, channel a to tag a authenticating Motivation 6.1 h oegnrlqeto ffradscrt nsmerccytgah a enas inves- also been has cryptography symmetric in security forward of question general more The client-server a in scheme derivation key secret forward a propose [BP10] Peyrin and Brier both ate en nsn wt epc otekycmuain,adproviding and computation), key the to respect (with sync in being parties not opoieps eso es utemr,te(strong) the Furthermore, keys. session past compromise 141

6 142 Chapter 6 SAKE: a Two-party AKE schemes [BM99]. Nonetheless, Bellare and Yee consider only algorithms (but not protocols) and they do not deal with the issue of synchronising the evolution of the shared key at both parties. That is, they propose out-of-context (non-interactive) solutions with respect to our purpose.

Abdalla and Bellare [AB00] investigate a related question which is “re-keying”. Their formal analysis shows that appropriate re-keying techniques “increase” the lifetime of a key. They consider re-keying in the context of symmetric encryption (in order to thwart attacks based on the ability to get lots of encrypted messages under the same key), and forward security (in order to protect past keys). Yet, they conne their analysis to algorithms and not protocols. Hence, as Abdalla and Bellare [BY03], they do not treat the synchronisation issues that arise from evolving a shared symmetric key.

The Signal messaging protocol [Sig], devised by Marlinspike and Perrin, uses a key derivation scheme called “double ratchet algorithm” [PM16]. This scheme combines a DH based mechanism with a symmetric key-evolving mechanism (based on a one-way function). The rst mechanism provides an asymmetric ratchet, whereas the second provides a symmetric ratchet. The asymmetric ratchet is applied when a fresh DH share is received (included in an application message) from the peer. The symmetric ratchet is applied when a party wants to send several successive messages without new incoming message from its partner. Thanks to the DH scheme, the asymmetric ratchet is supposed to provide forward secrecy.1 Regarding the symmetric ratchet, each party is compelled to store the decryption keys of the not yet received messages. This is due to the asynchronous nature of the Signal protocol. Therefore, the symmetric ratchet in Signal does not provide forward secrecy, as stated in their security analysis by Cohn-Gordon, Cremers, Dowling, Garratt, and Stebila [CGCD+17]: “old but unused receiving keys are stored at the peer for an implementation dependent length of time, trading o forward security for trans- parent handling of outdated messages. This of course weakens the forward secrecy of the keys”. Consequently, Cohn-Gordon et al. choose not to model this weakened property. In turn, Alwen, Coretti, and Dodis [ACD19] incorporate the latter in the security analysis of their “generalised Signal protocol”. But the crucial dierence in their notion of forward security is that, as soon as the receiver is compromised, no more security can be provided. On the contrary, we tackle the synchronisation issue, and solve it in our protocol. The security model we use captures forward secrecy and allows corrupting a party and its partner as soon as the targeted party “accepts” (i.e., deems the session key can be safely used). With regard to Signal, our protocol can be compared to the asymmetric ratchet (in synchronous mode), and yet does not implement asymmetric functions.

Table 6.1 provides a comparison between the aforementioned schemes with respect to six features:

• “2P” – The scheme is a two-party protocol (in opposition to a cryptographic primitive).

• “Bilateral” – The forward secrecy property is guaranteed at both parties (e.g., in contrast to a client-server context where the server is deemed as incorruptible).

• “Sym.” – The scheme is built on symmetric-key functions only.

• “I/R” – Any party can be initiator or responder in a session.

1In Signal, the DH exchanges can be asynchronous. This impairs the forward secrecy property usually ensured by this scheme. a epoei) n ahpryi lasal octhu ncs fdsnhoiain(fcourse, (of desynchronisation of case in up catch to able always is party each and it), prove we (as to solution shrewd a provide We arises. problem synchronisation a evolve, key (symmetric) erc) n eycrnsto r oei h otniyo h rtclrn nadto,the addition, In run. characteristics. following protocol forward the the (with has of continuity describe exchange we the key protocol in authentication, done Mutual are resynchronisation complete). and and secrecy), bounded correct is is gap session possible the the if Hence parties keys. The master necessary. their if updating parties to tracking the allow prior resynchronising keys other and These each state, keys. authenticate internal master the Our of of chain procedure. evolution (independent) resynchronising the second additional a an on nor based clock, is a solution shared neither a using make require We parties issue. two this as soon form As strong scheme. very key-evolving this a attain We using secrecy. by forward security also long-term guarantees of and agreement, key and tion Our Nutshell a In 6.2.1 Secrecy Forward with Protocol AKE Symmetric-key 6.2 Secrecy Forward with Protocol AKE Symmetric-key 6.2 osiadJll [DJ14] Jalili and Dousti u AESK-Mprotocol SAKE/SAKE-AM Our [Sig] Signal [AB00] Bellare and Abdalla [BY03] Yee and Bellare [BP10] Peyrin and Brier [LBM07] al. et Le al 6.1 Table • • • • • ymti-e uhniae e Exchange Key Authenticated Symmetric-key Ulmtd h ubro esosteshm a xct,o h ubro (encryp- of number unlimited. the (virtually) or is execute, output can can scheme it the keys sessions tion) of number The – “Unlimited” clock). synchronised (e.g., secrecy “No ne(hnrsnhoiaini eesr) n osmn adit t rnmtthe transmit (to at bandwidth computations data). consuming keys, additional of and master necessary), amount the is great of resynchronisation a evolution (when doing the once periodically of drawbacks: track subsequent keeps the that counter and resynchronise, large) to (suciently order bounded. in a strictly information as is additional run such sending of protocol need single the a avoid in we parties particular only). both In once by used done calculation being of each amount keys, The master of list protocols to predened opposite a (as of sessions use of make number that unlimited synchronised. (virtually) and an updated establishing protocol is allows the state It in internal involved their parties and two key, the session session), the new the whatever a (and to share session prior run complete parties and the correct of a state after internal is, That self-synchronising. is It Scheme + uc”–N diinlfntoaiyi eurdi re ogaateforward guarantee to order in required is functionality additional No – func.” oprsnbtensvrlshmsamn tesrn owr secrecy forward ensuring at aiming schemes several between Comparison – Feature 2P Bilateral - - SK)pooo rvdsmta authentica- mutual provides protocol (SAKE) Sym. I/R - - No + - - func. Unlimited - 143

6 144 Chapter 6 SAKE: a Two-party AKE

6.2.2 Key Concepts The protocol allows two parties A (initiator) and B (responder) to mutually authenticate and compute a shared session key. It is based on two types of master keys: a derivation master key K (used to compute the session keys), and an authentication master key K0 (used to authenticate the messages sent during a protocol run). The protocol makes use of symmetric-key functions only. Each pair of parties (A, B) shares distinct master keys. The main lines of the protocol are as follows: the two parties exchange pseudo-random values rA, rB. These two values are used to

• authenticate each other: each party sends back the value it has received in a message 0 that is MAC-ed with the authentication master key K . For instance, if B receives rA it 0 replies with rBkτB where τB = MAC(K ,BkAkrBkrA).

• Compute a session key: a pseudo-random function KDF is keyed with the derivation master key K and uses the pseudo-random values as input. That is, sk ← KDF(K, f(rA, rB)). Function f is deliberately left undened. For instance, f(rA, rB) can be equal to the 2 concatenation or the bitwise addition of rA and rB.

Providing forward secrecy. The shared key K is used to compute the session keys. If this key remains unchanged throughout all sessions, its disclosure allows computing all past (and future) session keys. To solve this issue we apply a key-evolving technique. We update the master key such that a previous version of the latter cannot be computed from an updated one. Each of the two parties involved in a session updates its own copy of the derivation master key K with a non-invertible function update: K ← update(K). Hence this protects past sessions in case the (current value of) master key K is revealed. Each party authenticates its peer prior to updating the derivation master key. If the master key is updated throughout the session, it may happen that one of the two involved parties update its master key whereas the other does not. This leads to a synchronisation problem.

update 0 0 0 0 K0 K1 K2 K3 ··· update K0 K1 K2 K3 ··· KDF

sk0 sk1 sk2 sk3

Figure 6.1 – Master key chains in SAKE. At epoch j, the initiator stores four keys: K = 0 0 0 0 Kj, and Kj−1, Kj, Kj+1. The responder stores two keys: K = Kj and K = 0 Kj. An illustration with j = 2 corresponds to the keys surrounded by the blue dashed box .

The synchronisation problem. If two parties use a dierent key K, they are obviously not able to compute a shared session key. Hence they must resynchronise rst. More fundamentally,

2The function f must be chosen such that the security of KDF is not impaired. We assume here that the cryptographic functions used are ideal (investigating this topic is beyond the scope of this chapter). δ A value current ( message rst the and step one δ parameter The between 6.2. gap Figure the by to depicted is protocol SAKE Our Protocol the of Description 6.2.3 key master derivation the of sample up-to-date. one Only secrecy. of forward copy threatening a maintain safely can parties one the when particular state (in discarded. accepting Otherwise is in used. key ending safely session party be the the can desynchronised), case, key are a session such fresh In the partner keys. that its master deems that messages) own MAC-ed its (nal updated conrmation already a tells received has has consequently it and after issue, only synchronisation “accepts” the party with deal to able for one order in sucient are epochs, previous keys three only key master key course, the Of of as to. sample way belongs same sender the the in epoch nised which learn to tag MAC the update to is of solution evolution The session. a during a changed for order in sent is a data of up. additional catch continuity (heavy) actually to the no has party and in partner desynchronised needed, issues its is both of procedure to key extra master solution no the particular, a if provide know Therefore, We parties secrecy. updated. the forward that been break importance trivially paramount hence compute initiator, of can the is partner to it the respect corrupts who with adversary keys an session then key past epoch, master earlier derivation an some to with corresponding session key a initiates party a if Secrecy Forward with Protocol AKE Symmetric-key 6.2 AB AB ic w needn atrky r sd(uhniainadssinkyderivation), key session and (authentication used are keys master independent two Since key master second the on solution our base We informs • • • {− ∈ {− ∈ hn(pnrcpino message of reception (upon Then n hnprom h eua prtos(eso e optto,mse esupdate). keys master computation, key (session operations regular the performs then and If is parties the between Since gap the update). proceeding, keys master computation, key once Then, time). second a that (i.e., keys operations master regular its the updates with and key, proceed to and time), rst a If of reception upon Then, keys. If A A A ha to ahead 1 1 si dac ( advance in is si ycwith sync in is B slt ( late is , , B K 0 0 K ssnhoie (message synchronised is n bit One . } , 0 K 1 0 orsodn osvrlcneuieeoh.W rv i eto ..)that 6.3.1) Section (in prove We epochs. consecutive several to corresponding ( } olw htof that follows K 0 B of seScin631.Ta is, That 6.3.1). Section (see 0 = K j δ 0 +1 uigasession, a During . AB A B 0 h te at (initiator party other the , , ,adif and ), Therefore . and K m = δ j AB 0 B B seog (message enough is , − K B K etby sent ) ( 1 1 = δ hsi h,weesoepry(responder party one whereas why, is This . j 0 ,i eycrnss(.. tudtsismse esas time), rst a keys master its updates it (i.e., resynchronises it ), ihrsett h vlto ftemse es epoethat prove We keys. master the of evolution the to respect with AB − δ K AB 1 orsodn epcieyt h et h urn,adthe and current, the next, the to respectively corresponding , ), 0 = h at htrcie h rtatetctdmsaeuses message authenticated rst the receives that party The . K A m 1 = 0 B at for waits B m ), orsodn oa ale pc ( epoch earlier an to corresponding A niae h urn ycrnsto tt of state synchronisation current the indicates A A ( τ olearn to m B , 0 sstekeys the uses optstenwssinky n pae t master its updates and key, session new the computes 1 = B ), A A A ), ostesame. the does A ). B B and efrsterglroeain swl (session well as operations regular the performs m a nyb either be only can A A orsnhoie(i.e., resynchronise to δ ple h eua operations. regular the applies A trssvrlsmlso h authentication the of samples several stores ) bounded AB and because ) B K h message The . K orsnhoie h ntao ( initiator The resynchronise. to A B 0 K 0 sdt uhniaetemsae ex- messages the authenticate to used ttesm ieas time same the at at for waits j eaea follows. as behave 0 , a rvdi eto 6.3.1). Section in proved (as K B K j δ 0 − AB n t ate trsamaster a stores partner its and , 1 ae w eaiusol:if only: behaviours two takes , n step one K optdby computed B B j 0 m A +1 K optstenwsession new the computes B orsnhoiebefore resynchronise to B eevsaconrmation a receives 0 B b re flikelihood) of order (by pae t atrkeys master its updates a lob desynchro- be also can scmue ihthe with computed is K eid ri yc or sync, in or behind, o obhv.Each behave. to how j K 0 B − K single 1 trsol one only stores ) skp:temost the kept: is ihu ikof risk without ) hrfr the Therefore . A corresponds eso.In session. A B sthe is ) Then . 145

6 146 Chapter 6 SAKE: a Two-party AKE

Once a correct and complete session ends, three goals are achieved in the same protocol run: (i) the two parties have updated their master keys, (ii) they are synchronised (which stems in particular from the fact that the gap between A and B is bounded, i.e., |δAB| ≤ 1), and (iii) they share a new session key. In other words, the protocol is self-synchronising.

The session can be reduced from ve to four messages in some cases. Indeed, regarding the synchronisation state, in two cases (when δAB ∈ {−1, 0}, that is = 0), A and B are synchronised, and share a session key once B has received message mA and executed the subsequent operations. Therefore, in such a case, the session can end upon reception of message 0 τB by A. More precisely

0 • if δAB = 1 ( = 1), then A accepts upon reception of τB, and B accepts upon reception 0 of τA;

0 • if δAB ∈ {−1, 0} ( = 0), then A accepts upon reception of τB, and B accepts upon reception of mA.

Although this does not appear explicitly in Figure 6.2, a party aborts the session if it receives a message computed with an invalid identity. For the responder B, an invalid identity corresponds to an initiator party A it does not share master keys with. For an initiator A, the particular case B = A, among other possibilities, yields an error (i.e., each party must have a distinct identity). 0 0 0 Note that, since Kj+1 and Kj can be computed from Kj−1, it is also possible to store only 0 Kj−1, and to compute the two other keys when necessary during the session.

Remark. With respect to the security model presented in Chapter 2, Section 2.3.1, the long-term 0 0 key of A and B corresponds respectively to A.ltk = (K,Kj−1) and B.ltk = (K,K ). We could 0 0 have allowed the authentication master key Kj−1/K to be disclosed prior to the start of the session. This would not impair the forward secrecy of the derivation master key K. Nonetheless, knowing the authentication master key an adversary could desynchronise a legitimate party so that the party could not catch up anymore. Hence our choice to include both master keys in the response to a Corrupt-query.

0 0 0 0 A variant. Alternatively, the evolving authentication keys K and Kj−1, Kj, Kj+1 can be 0 replaced by a static authentication master key K , and two local counters cA, cB (respectively stored by A and B) that keep track of the evolution of the derivation master key K.3 On the initiator’s side, the MAC verications are then done with consecutive values of the counter j − 1, j, j + 1. Overall, the sequence of operations and the computations are similar to that of SAKE. This 0 0 means mainly replacing function x 7→ MAC(Kj, x) with x 7→ MAC(K , jkx). This alternative 0 implies the storage of two keys and one counter: K, K and cA/cB, instead of two keys only: K 0 0 and Kj−1/K (and, on the initiator’s side only, one or two additional calls to update in order to 0 0 compute Kj and, possibly, Kj+1).

Notation. For the sake of clarity, we use the following notation in Figure 6.2:

• kdf corresponds to: sk ← KDF(K, f(rA, rB))

• updA corresponds to

3This alternative has been suggested by anonymous reviewers from Crypto 2019. . ymti-e K rtclwt owr Secrecy Forward with Protocol AKE Symmetric-key 6.2 r if leif else leif else τ else m if leif else τ A A A 0 A K δ K δ K δ abort if K K if kdf ( ( ← ← ←− { Vrf $ AB AB AB ← 0 0 0 0 0 0) = MAC MAC abort abort ( ( ; ← ← ← ← ← Vrf Vrf ( 0 ← ← − ← upd k K , ( ( ( ( τ K K K K K Vrf Vrf 1 ,K K, j ( ( 0 A 0 1 } B , 1) = K K ( ( A j j j j j 0 0 0 0 0 λ K K − +1 +1 ; 1 ( ( 0 0 1 kdf K K r , r , k 0 0 ; ; , r , j 0 A j j +1 0 0 upd B B − +1 k ; k A ← k k 1 A K , r B A upd k r r B , B , B r A A A k 1 B k ; B j τ , τ , 0 k k r A K , ) kdf A A A k B B ; 0 0 r τ , k k = ) = ) j A 0 ; r r − ← B k upd B B 1 r = ) ( ) k k iue6.2 Figure B false false 0 r r ) A A A ; true τ , τ , B B ← ) ) = ) = ) ←−−−−−−− −−−−−−−→ ←−−−−−−− −−−−−−−→ ) −−−−−−−→ 0 AEprotocol SAKE – true true A m m τ τ k A B 0 0 A B r r τ m if if τ kdf if A B B B 0 ) ) B upd ( ( ( ← ← ←− { ; abort abort Vrf Vrf $ ← upd 1) = MAC MAC B ( ( r 0 K K B B , 1 k 0 0 } r , , τ ( ( B λ K K k A A 0 0 k B , r , r k B B B ,K K, k τ , k k A r r A 0 A k A = ) r ) k 0 B ) r k B false r τ , A ) A = ) ) false ) 147

6 148 Chapter 6 SAKE: a Two-party AKE

1. K ← update(K) 0 0 2. Kj−1 ← Kj 0 0 3. Kj ← Kj+1 0 0 4. Kj+1 ← update(Kj+1)

• updB corresponds to 1. K ← update(K) 2. K0 ← update(K0)

Moreover, Vrf(k, m, τ) denotes the MAC verication function that takes as input a secret key k, a message m, and a tag τ. It outputs true if τ is a valid tag on message m with respect to k. Otherwise, it returns false. Before the rst session between A and B, the master keys are initialised as follows4:

• K and K0 are uniformly chosen at random.

0 • Kj−1 ←⊥

0 0 • Kj ← K

0 0 • Kj+1 ← update(K )

6.3 Proofs for SAKE

In this section we prove that (i) SAKE is sound, and (ii) it is a secure AKE protocol according to Denition 2.10.

6.3.1 Soundness of SAKE We want to show that SAKE is sound, which essentially means that, once a correct session is complete, both parties have updated their respective internal state, are synchronised, and share the same (new) session key. We call a “benign” adversary an adversary that faithfully forwards all messages between an initiator A and a responder B.

Lemma 6.1. Let A and B be respectively the initiator and the responder of a SAKE session. Let δAB be the gap between A and B with respect to the evolution of the master keys of both parties. The following conditions always hold:

1. δAB ∈ {−1, 0, 1}, and

2. whatever the synchronisation state between A and B at the beginning of a session (i.e., whatever A and B are synchronised or not), when that session completes in presence of a benign adversary, then a) A and B have updated their master keys at least once, and b) A and B are synchronised (with respect to their master keys), and c) A and B share the same session key.

4 0 During the rst protocol run, A needs only Kj to verify message mB . ( h oain“ notation The ausfor values K 6.3a. Table iteratively δ between gap the to sponds keys by master held the keys time master the of evolution the Proof. SAKE. B to between to synchronisation equivalent the is regarding consequence no of is this A But message. rst a missed has by received by received message a index of message is way: natural a in numbered are session a SAKE for Proofs 6.3 c AB A ( j 0 eoetes session, constructing rst by the 1 Before item prove We 6.2. Table in listed are sessions possible dierent The Let with sessions of sequences possible the all represents 6.3 Figure by depicted diagram The and that happen may It during exchanged messages The notation. following the use we 6.1, Lemma prove to order In ed message sends (4 i c , A = = , i , B 5) c K B epoeLma61 es rv tm1. item prove rst We 6.1. Lemma prove We ( = ) B c A Since . A ) 0 (resp. ( -session as A − ( i ,i i, A A a ipyrntepooo nw.Teeoew ontuetevalue the use not do we Therefore anew). protocol the run simply may B c i , B . ( Hence . ) i . A c B i A (with B B ) i , eso hr h atmsaercie by received message last the where session a ed message sends ea(ita)mntnclyicesn one ntaie to initialised counter increasing monotonically (virtual) a be ) j 5 = r slse nTbe6.2. Table in listed as are B i { ∈ A ) B K en ht hntessined,tels ai esg eevdby received message valid last the ends, session the when that, means ” n h atvldmsaercie by received message valid last the and , i A .A ntaiain(.. eoetes u fteprotocol), the of run rst the before (i.e., initialisation At ). al 6.2 Table A smessage is 2 , 0 = edas esg hc sntrcie by received not is which message rst a send K , computes 4 j 0 } A .Therefore, ). +1 A nyuo eeto favldmessage valid a of reception upon only and , and K osbevle for values Possible – i j 0 B , { ∈ i A B K B i δ A ihrsett h vlto ftermse es hence keys, master their of evolution the to respect with AB yconvention By . j 0 r ycrnsd htis That synchronised. are 3 − 4 2 0 , 1 A 5 0 = i (resp. } B A a validate can −−−−→ ←−−−− −−−−→ ←−−−− −−−−→ nyuo eeto favldmessage valid a of reception upon only (resp. and , 5 3 1 4 2 1 K , B K 3 0 = .Ta is, That ). 0 i r pae.Teparameter The updated. are ) ( A i τ 5 osqety foecrisotthe out carries one if Consequently, . A B B 0 = i , i message (in B B ) en htn esg a been has message no that means nSAKE in c smsaeo index of message is A A δ (resp. smessage is AB j B m = − c . B B B 1 c ihtesm key same the with ) sicesdeach increased is ) h nypossible only the , A antko fit if know cannot − i A 0 c ( n h last the and , B i htfollows that A i δ i , i B i 0 = AB B − ecall We . B 0 = ) 1 corre- and , sset is and , 149 (it A

6 150 Chapter 6 SAKE: a Two-party AKE

(4, 3) (0, 1) (4, 5) (2, 3) (0, 1) 0 1 (4, 3) (2, 1) (4, 5) (2, 1)

1) , , 3) (2 (2 , 3) 3) (4 , , 5) (2 (4

−1

(0, 1)

Figure 6.3 – Diagram of SAKE. The circled values correspond to the gap δAB, and each edge to a (iA, iB)-session.

protocol run starting with δAB = 0 and = 0, for each possible value (iA, iB), one eventually gets the following:

• (cA, cB) = (i, i) and δAB = 0 after a (0, 1)-session,

• (cA, cB) = (i + 1, i) and δAB = 1 after a (2, 1)-session,

• (cA, cB) = (i + 1, i + 1) and δAB = 0 after a (2, 3)-session,

• (cA, cB) = (i + 1, i + 1) and δAB = 0 after a (4, 3)-session,

• (cA, cB) = (i + 1, i + 1) and δAB = 0 after a (4, 5)-session. This corresponds to the rst column of Tables 6.3a and 6.3b. As we can see, the only possible values for δAB after any session are 0 and 1. δAB = 0 has already been investigated. Hence, starting with δAB = 1 (i.e., (cA, cB) = (i + 1, i)), we look for all the values δAB may have when the session ends, considering any possible session. (cA, cB) = (i + 1, i) means that A is in advance with respect to B. In such a case, A succeeds 0 in validating τB with Kj−1 (and, indeed, nds δAB = 1). Then A uses δAB = 1 and = 1. If one carries out the protocol run using these two values, one gets:

• (cA, cB) = (i + 1, i) and δAB = 1 after a (0, 1)-session,

• (cA, cB) = (i + 1, i) and δAB = 1 after a (2, 1)-session,

• (cA, cB) = (i + 1, i + 2) and δAB = −1 after a (2, 3)-session,

• (cA, cB) = (i + 2, i + 2) and δAB = 0 after a (4, 3)-session,

• (cA, cB) = (i + 2, i + 2) and δAB = 0 after a (4, 5)-session. This corresponds to the second column of Table 6.3a. This shows that a third value is possible for δAB, which is −1 (i.e., (cA, cB) = (i, i + 1)). Then we restart the protocol with all possible sessions, assuming that (cA, cB) = (i, i + 1) at the beginning of the run. This means that A is one step late with respect to B. In such a eedwt he osbevle for values possible three with end We ausfor values hi nenlsaea es ne(stels ieo h al,crepnigt a to corresponding table, the of line last the (as indicates). once least at state internal their c key. session same key ends, master session derivation complete K the and of correct update a last when the Hence, and precedes correct immediately a computation key after session parameter that of value δ the indicates a 6.3a (i.e., Table session of complete line last the session, possible only the sessions, of sequences the whatever that, proves This explored. been already δ case, SAKE for Proofs 6.3 B AB AB al 6.3 Table nadto,Tbe63 hw ht htvrtesnhoiainsaeof state synchronisation the whatever that, shows 6.3b Table addition, In that 6.1. know Lemma We of 2 item prove we Now ttebgnigo h eso,atracretadcmlt session, complete and correct a after session, the of beginning the at ) ocmuetessinky hrfr,uigtesm values same the using Therefore, key. session the compute to • • • • • 0 = = A ( ( ( ( ( c c c c c − ucesi validating in succeeds A A A A A nsc aewaee h au of value the whatever case a such in ) 1 c , c , c , c , c , δ and AB B B B B B osbevle for values Possible – ( = ) ( = ) ( = ) ( = ) ( = ) session r in are 0 = δ ,i i, i i i i AB 2 + 2 + 2 + 2 + (4 (4 (2 (2 (0 foecrisottepooo u sn hs w aus n gets: one values, two these using run protocol the out carries one If . {− 1) + , , , , , {− ∈ 5) 3) 3) 1) 1) i , i , i , i , (4 ( 1 c , 1) + 2) + 2) + 2) + A , 0 and 5) c , , 1 1 ssin.A ecnsee, can we As -session). , B } session τ 0 and and and and δ ) . B , AB δ 1 (b) ihkey with AB } ( ( ( δ δ δ δ o ahpsil au of value possible each For . (a) = i i i (4 (4 (2 (2 (0 AB AB AB AB osbevle for values Possible ( 1 + 1 + 1 + and δ i , , , , , osbevle for values Possible − AB ( ( 5) 3) 3) 1) 1) 1 + 1 = 0 = 0 = 0 = ,i i, i i, 1 i , i , i , ( fe a after tidclm fTbe6.3a): Table of column (third c ) ) i , δ K 1) + 1) + 1) + A AB fe a after fe a after fe a after fe a after ) c , j 0 +1 δ B AB ) (0 ad ned nds indeed, (and, A 0 0 0 0 0 1 mn l eune fssin nSAKE in sessions of sequences all among ( ( ( , hntessinsat.Frhroe the Furthermore, starts. session the when (2 (2 (4 (4 i i i and ( 1) ( ( ( c 2 + 2 + 1 + , , , , i i i − δ A -session, 1) 3) 3) 5) A 1 1 0 0 1 AB 1 + 1 + 1 + c , 1 B -session, -session, -session, -session. i , i , i , and B ) s h aedrvto atrkey master derivation same the use i , i , i , 2) + 2) + 2) + − − 0 0 0 1 ) ) ) B 1 1 r lassnhoie (i.e., synchronised always are r δ A AB , ( ( ( ( i i i i r δ ( ( B 2 + 2 + 2 + 2 + AB ttebgnigo the of beginning the at ,i i, i i, , A − A i , i , i , i , = 1) + 1) + A 1 and and , 2) + 2) + 2) + 1) + and − 0 and 1 B B .Then ). (4 B aeupdated have opt the compute 1 , (i.e., 5) hthave that , -session, A c A uses and 151 K .

6 152 Chapter 6 SAKE: a Two-party AKE

6.3.2 Security of SAKE In order to prove that the protocol SAKE is a secure AKE protocol, we use the AKE security model described in Chapter 2, Section 2.3.1. We dene the partnering between two instances with the notion of matching conversations (see Denition 2.1). That is, we dene sid to be the transcript, in chronological order, of all the (valid) messages sent and received by an instance during the key exchange, but, possibly, the last one. We prohibit parallel executions of the protocol. Indeed, since the protocol we propose is based on shared evolving symmetric keys, running multiple instances in parallel may cause some executions to abort (we elaborate more on this in Section 6.6). This is the only restriction we demand compared to AKE model. In addition, for each party Pi we dene the long-term 0 0 key Pi.ltk to be Pi.ltk = (K,Kj−1) if ρ = init, and Pi.ltk = (K,K ) if ρ = resp. The same long-term key ltk is shared by a unique pair of parties (Pi,Pj). That is, Pi.ltk = Pj.ltk. Furthermore, we choose the function update to be a PRF, that is update : K 7→ PRFupdate(K, x) for some (constant) value x.

Theorem 6.2. The protocol SAKE is a secure AKE protocol, and for any probabilistic polynomial time adversary A in the AKE security experiment against SAKE

ent-auth −λ prf suf-cma advSAKE (A) ≤ nq (nq − 1)2 + (q + 1)advupdate(B) + 2advTag (C)

key-ind prf prf ent-auth advSAKE(A) ≤ nq (q − 1)advupdate(B) + advKDF(D) + advSAKE (A) where n is the number of parties, q the number of instances (sessions) per party, λ the size of the pseudo-random values (rA, rB), and B is an adversary against the PRF-security of update, C an adversary against the SUF-CMA-security of Tag = (Tag.Gen, Tag.MAC, Tag.Vrf), and D an adversary against the PRF-security of KDF.

We give a proof of Theorem 6.2.

Entity authentication. First we consider the entity authentication experiment described in Chapter 2, Section 2.3.1.

Proof. Let Ei be the event that the adversary succeeds in making an instance accept maliciously in Game i. We use the following hops. s In order for an initiator instance πi at some party Pi to accept, two valid messages (i.e., s 0 with valid MAC tags) must be received by πi (mB and τB). We reduce the security of the Tag function to the (in)ability to forge a valid output. Therefore we use the fact that the key K0 is random. By assumption, the genuine value of K0 (i.e., the value used during the rst session between two same parties) is uniformly chosen at random. Yet K0 (and K) is updated throughout the session with the function update. If K0 is random, we can rely on the pseudo- 0 randomness of update(·) = PRFupdate(·, ·). In turn, since PRFupdate(K , ·) can be replaced with a truly random function, its output (updated K0) is random. Therefore, one can rely upon the pseudo-randomness of the function update keyed with this new value K0, and so forth. Each 0 prf transition (i.e., each update of K ) implies a loss equal to advupdate(B) corresponding to the ability of an adversary B to distinguish update from a random function. If Pi is synchronised with the responder (δAB = 0), Pi updates its master keys once (upon reception of mB). If Pi is in advance (δAB = 1), it updates its keys at most once (if a valid 0 message τB is received). If Pi is late (δAB = −1), it updates its keys twice. Yet, in that case, Pi did not update its keys during the previous session. Therefore, on average, Pi updates its keys ( hr ahcneuiegm isa euigtecalne’ eednyo h functions the on dependency challenger’s the reducing at aims game consecutive each where Tag h hlegraot h xeietif experiment the aborts challenger The ausb qa sa most at is equal be values key adversary an of ability adversary key an dierent of ability the to corresponding K the compute to key used key the session, function current the the during replace, in to tag able MAC be to order In random. most at updated been have functions to message valid a receives ever 3. Game of number The aborted. is game the wrong, is guess most the at If is maliciously. instances accept to rst the be 2. Game in random at drawn uniformly each value random a chooses that 1. Game 0. Game Game in experiment per once most of at reception average upon on and, updated average, are keys the the when that Therefore, means session. This session. previous the during ( once updated are messages two the if only the when Hence, u session. per once most at SAKE for Proofs 6.3 q − 0 − hrfr,w elc ahfunction each replace we Therefore, BR04], [Sho04; games of sequence a through proceed We proof. the with proceed now can We instance responder A responder. the regarding similar is This π iharno au n uttk noacuttescesv losses successive the account into take must one value random a with , K K 1 1) a uptta esg.W euetepoaiiyo hseett h euiyo the of security the to event this of probability the reduce We message. that output has update 0 ie naeae n,uo eeto of reception upon and, average, on times 0 adv hogotte tmost, at the, throughout en adm(n nteped-admesof pseudo-randomness the on (and random being Tag update prf nti ae eada br ue h hlegraot fteeeit n instance any exists there if aborts challenger The rule. abort an add we game, this In nti ae eada br ue h hlegrtist us hc ntnewill instance which guess to tries challenger The rule. abort an add we game, this In hsgm orsod oteett uhniainscrt xeiet Therefore experiment. security authentication entity the to corresponds game This Let m update and K A and π 0 ( (resp. rmarno ucin ic hr sa most at is there Since function. random a from ) B eteisac agtdb h desr.I hsgm,w d naotrule. abort an add we game, this In adversary. the by targeted instance the be KDF ) update hnw euetepoaiiyo h adversary the of probability the reduce we Then . nq htotus(h e au of) value new (the outputs that 0 = i . m Let . Therefore . C B rtie( twice or ) m ofreavldtag valid a forge to iharno au,oems eyuo h suornons of pseudo-randomness the upon rely must one value, random a with ) sepandaoe hnthe when above, explained As . nq u A E ( r − u nq and 2 i A m λ t eso starts, session -th Pr[ eteeetta h desr i h niyauthentication entity the win adversary the that event the be − q 1 or B m − 1) ie led.Tegnievleof value genuine The already. times τ E 1 (resp. Hence . A A r Pr[ 0 Pr[ B 0 h esaeudtda ottotimes. two most at updated are keys the , { ucsiessin salse,pirt htcretsession, current that to prior established, sessions successive r ai.Uo eeto favldmessage valid a of reception Upon valid. are ] 0 1 = hti o nqe hr sa most at is There unique. not is that E ≤ , E update 1 0 2 π m } = ] Pr[ .I h atrcs,teky aentbe updated been not have keys the case, latter the In ). Pr[ = ] λ eaiga niiitr(ep epne)instance, responder) (resp. initiator an as behaving , A hrfr h rbblt hta es w random two least at that probability the Therefore . u B u oisac aigamthn conversation matching a having instance no but ) E t eso starts, session -th τ adv ( B 1 odsigihtefunction the distinguish to K + ] τ P (resp. SAKE ent E B 0 0 = ) j 1 , - nq a pae t esa most at keys its updated has auth ] P K × i ( PRF τ 0 pae h esa ottotimes. two most at keys the updates nq ( ntr,ti eisuo h (previous) the upon relies this turn, In . A nq 2 A 1 update ). λ ) − . update u . t eso trs h atrkeys master the starts, session -th 1) . P .Teeoe nodrt replace to order in Therefore, ). ( i K q a pae t esa most at keys its updated has π esos hsls sa most at is loss this sessions, 0 j t x , K A tsm party some at ) 0 ownti aet the to game this win to kydwt dierent a with (keyed suiomycoe at chosen uniformly is update n × adv q admvalues, random update prf u kydwt a with (keyed m − A P 1 ( h keys the , j B ie on times accepts ) each , 153

6 154 Chapter 6 SAKE: a Two-party AKE

update update by the same party that owns π) with truly random functions F0 , ..., Fq−2 . Moreover, if 0 0 an instance uses the same key K = Ki, 0 ≤ i < q − 1, to key update, then we replace update update 0 0 with the corresponding random function Fi . Since, to that point, the key K = Kq−1 used to compute the authentication tag τB (resp. τA) is random, we reduce the ability of A to win to the security of the Tag function. Hence

prf suf-cma Pr[E2] ≤ Pr[E3] + (q − 1)advupdate(B) + advTag (C).

Game 4. In this game, we add an abort rule. The challenger aborts the experiment if π ever 0 0 receives a valid message τB (resp. τA), but no instance having a matching conversation to π has output that message. Between the message mB (resp. mA) being received by π, and the 0 0 message τB (resp. τA) being received by π, the master keys are updated at most twice. We reduce the probability of the adversary to win this game to the security of the Tag function 0 0 used to compute the message τB (resp. τA). In turn we must rely on the randomness of the MAC key, hence on the security of the function update used to update the MAC key K0 (recall that, due to Game 3, the current key K0 is random). Therefore

prf suf-cma Pr[E3] ≤ Pr[E4] + 2advupdate(B) + advTag (C). To that point, the only way for the adversary to make π accept maliciously is to send a valid 0 0 message τB (resp. τA) dierent from all the messages sent by all the instances. However, in such a case, the challenger aborts. Therefore

Pr[E4] = 0. Collecting all the probabilities from Game 0 to Game 4, we have that

ent-auth advSAKE (A) = Pr[E0] nq(nq − 1) ≤ + Pr[E ] 2λ 1 nq(nq − 1) ≤ + nq × Pr[E ] 2λ 2 nq(nq − 1) ≤ + nq Pr[E ] + (q − 1)advprf (B) + advsuf-cma(C) 2λ 3 update Tag nq(nq − 1) ≤ + nq Pr[E ] + (q + 1)advprf (B) + 2advsuf-cma(C) 2λ 4 update Tag nq(nq − 1) ≤ + nq (q + 1)advprf (B) + 2advsuf-cma(C) 2λ update Tag −λ prf suf-cma ≤ nq (nq − 1)2 + (q + 1)advupdate(B) + 2advTag (C)

Key indistinguishability. Now we prove the key indistinguishability security.

0 Proof. Let Ei be the event that an adversary win the key indistinguishability experiment in 0 1 Game i, and advi = Pr[Ei] − 2 .

Game 0. This game corresponds to the key indistinguishability experiment described in Chapter 2, Section 2.3.1. Therefore 1 1 Pr[E0 ] = + advkey-ind (A) = + adv . 0 2 SAKE 2 0 ( whether replace we key dierent a with the during performed games the in as modications same the make we game this in words, Then ae2. Game h euiyof security the key owns that party G same the by session, current that of pseudo-randomness the to respect with update key the to update due losses successive the account starts, session the of pseudo-randomness the upon key function the rely the we of is, security That the to key. game this win to adversary 3. Game instances of number The aborted. is game the wrong, is most guess at the is If adversary. the by targeted Hence proof. authentication entity b 1. Game SAKE for Proofs 6.3 q 0 q update { ∈ olcigaltepoaiiisfo ae0t ae3 ehv that have we 3, Game to 0 Game from probabilities the all Collecting guessing in advantage no has adversary the therefore random, is key session the point that To − − 2 K adv 1) K 0 oevr fa ntneue h aekey same the uses instance an if Moreover, . ic hr sa most at is there Since . = , adv K 1 key SAKE sudtdwith updated is π. } K nq - update prf srno.Tegnievleof value genuine The random. is b nti ae eada br ue h hlegraot h xeietadchooses and experiment the aborts challenger The rule. abort an add we game, this In nfrl trno fteeeit nisac htacpsmlcosy nother In maliciously. accepts that instance an exists there if random at uniformly ind nti ae eada br ue h hlegrtist us hc ntneis instance which guess to tries challenger The rule. abort an add we game, this In Let update q − Therefore . = ( 1 K A KDF π sdt opt h eso e srno,w eueteaiiyof ability the reduce we random, is key session the compute to used b ( 0 = ) B htis That . eteisac agtdb h desr.W eueteavnaeo the of advantage the reduce We adversary. the by targeted instance the be a enudtda most at updated been has ) ihtecrepnigrno function random corresponding the with ec erpaeec function each replace we Hence . Therefore . ≤ ≤ ≤ ≤ K adv hogotte tmost, at the, throughout adv adv adv adv adv update 2 ≤ SAKE ent 0 SAKE ent SAKE ent SAKE ent adv q - - - - auth auth auth auth esosprpry(.. e rgnlkey original per (i.e., party per sessions adv tms neprssino vrg.Teeoe hnthe when Therefore, average. on session per once most at 3 ( ( ( ( ( + A A A A 0 + ) + ) + ) + ) ≤ adv q adv − 2 adv nq nq nq adv 1) = 1 u K × adv 1 + adv ( adv 3 − q adv suiomycoe trno yassumption. by random at chosen uniformly is 0 = adv q update prf − 1 1 3 − ie led.Teeoew uttk into take must we Therefore already. times × K 2 π 1) ( + SAKE ent . ihtuyrno functions random truly with ) 1 adv nq = - ( 1 auth ucsiessin salse,pirto prior established, sessions successive q B update K . − + ) update prf ( i A 1) , KDF 0 KDF adv ) adv . G ≤ ( ( B K i update KDF prf update prf q < i + ) sdt opt h session the compute to used = ) ucin hsi osbeif possible is This function. ( D adv ic,t htpit the point, that to Since, . ( PRF − ) B . K KDF prf + ) 1 okey to , ,ti osi tmost at is loss this ), update ( adv D ) KDF prf ( ,x K, update A G ( 0 update D ownto win to ) ) (keyed then , , u 155 . . . -th ,

6 156 Chapter 6 SAKE: a Two-party AKE

6.4 SAKE-AM: a Complementary Mode of SAKE

0 0 0 In SAKE the initiator A owns the three keys Kj+1, Kj, Kj−1, and the responder B does the lightest computations. In this section, we present a variant of SAKE such that the smallest amount of calculations is done by the initiator. This variant corresponds also to less messages, and we call this “aggressive mode” of the protocol SAKE-AM. Compared to SAKE, SAKE-AM inverts the role of the initiator and the responder in terms of calculations (in SAKE, the initiator performs – at most – two additional MAC computations compared to the responder). Thus B owns three samples of the authentication master key (corresponding to consecutive epochs), and A does the smallest amount of calculation. SAKE- AM (with one message less with respect to SAKE) allows computing the synchronisation gap δ earlier (with the rst message). Yet the responder must wait for the third message to conrm that value. In a sense, this variant is also more optimistic. The main idea is to skip the rst SAKE message AkrA. Hence the roles between the two parties are swapped. This leads to other minor changes in message format compared to SAKE. Despite these dierences, the messages and the calculations are essentially the same as in SAKE. This variant remains a sound and secure AKE protocol (according to Denition 2.10). Furthermore, in a similar way to SAKE, the session in SAKE-AM can be reduced from four to three messages in some cases. Indeed, regarding the synchronisation state, in two cases (when δAB ∈ {−1, 0}, that is = 0), A and B are synchronised, and share a session key once A has received message mB and executed the subsequent operations. Therefore, in such a case, the 0 session can end upon reception of message τA by B. More precisely

0 • if δAB = 1 ( = 1), then A accepts upon reception of τB, and B accepts upon reception 0 of τA;

• if δAB ∈ {−1, 0} ( = 0), then A accepts upon reception of mB, and B accepts upon 0 reception of τA.

Notation. For the sake of clarity, we use the following notation in Figure 6.4:

• kdf corresponds to: sk ← KDF(K, f(rA, rB))

0 • updA corresponds to 1. K ← update(K) 2. K0 ← update(K0)

0 • updB corresponds to 1. K ← update(K) 0 0 2. Kj−1 ← Kj 0 0 3. Kj ← Kj+1 0 0 4. Kj+1 ← update(Kj+1)

End-device-server setting. Executing either SAKE or SAKE-AM depending on the party’s role results in an implementation (gathering all the properties summarised in Section 6.2.1, starting with the forward secrecy property) that allows any party to be either initiator or responder of a session, and such that the smallest amount of calculation is always done by the . AEA:aCmlmnayMd fSAKE of Mode Complementary a SAKE-AM: 6.4 r τ m if if τ kdf if A A A 0 A upd ( ( ( ← ← ←− { ; abort abort Vrf Vrf $ ← upd 1) = MAC MAC A 0 A ( ( 0 K K A 0 , k 1 r 0 0 ( } , r , A ( ( ,K K, λ K K k k B B A τ B 0 0 k A A , A , r k A 0 A ( ) k k τ , B B k r B 0 k k B = ) r r k A A r ) k A r false τ , B iue6.4 Figure ) B = ) −−−−−−−→ ←−−−−−−− −−−−−−−→ ←−−−−−−− ) false m m τ τ A B 0 A 0 B AEA protocol SAKE-AM – ) if leif else leif else m τ r else if leif else τ B B B 0 B K δ K δ K δ abort K K if kdf if ( ( ← ← ←− { Vrf $ BA BA BA ← 0 0 0 0 0 0) = abort abort ( ( MAC MAC ; ← ← ← ← ← Vrf Vrf ( 0 ← ← − ← upd K k , ( ( ( r K K K K K Vrf Vrf 1 j ( ( 0 B 1 0 } A , 1) = K K ( ( B 0 j j j j j 0 0 0 0 0 k λ K K − +1 +1 ; 1 ,K K, ( ( τ 0 0 1 kdf K K k A , A , B 0 0 ; ; , r , B j j 0 0 upd − +1 k k ; k k B ← 1 j B B 0 r B upd k +1 A , A , A B 0 r k k k 1 τ , A K , r r ; A k k B 0 A A ) kdf A B B k ; k k j = ) 0 r r r k k K , B ; B B r r ← k upd A A τ , τ , j r 0 true τ , τ , − A 0 A A 0 0 1 ) A A B 0 = ) = ) ) = ) = ) ; ) false false ← true true 0 ) ) ) ) 157

6 158 Chapter 6 SAKE: a Two-party AKE same party. Furthermore, SAKE and SAKE-AM are built on the same cryptographic functions, which enables to pool their implementation. This is particularly convenient in the context of a set of (low-resource) end-devices communicating with a central server. In such a case, the end-device supports the lightest computations, whereas either the server or the end-device can initiate a session. Figure 6.5 illustrates such a conguration. When the end-device initiates a session, protocol SAKE-AM is applied. Otherwise (the server is initiator), SAKE is executed.

Remark. In Chapter 7 we introduce a 3-party key exchange protocol dedicated to IoT, and describe how SAKE and SAKE-AM can be appropriately used in such a context.

End-device [B] Back end [A] 0 0 End-device [A] Back end [B] (K,K )(K,Kj+1, 0 0 0 0 (K,K )(K,Kj+1, Kj,Kj−1) 0 0 Kj,Kj−1) Akr ←−−−−−−−−−−−A AkrAkτA −−−−−−−−−−−→ r kτ −−−−−−−−−−−→B B compute δBA kr kτ compute δAB ←−−−−−−−−−−−B B kτA 0 ←−−−−−−−−−−− τA −−−−−−−−−−−→ τ 0 " # −−−−−−−−−−−→B τ 0 B " # ←−−−−−−−−−−− τ 0 ←−−−−−−−−−−−A

(a) End-device is initiator (SAKE-AM) (b) Back end is initiator (SAKE)

Figure 6.5 – SAKE/SAKE-AM executed between a low-resource end-device and a back-end server. Both parties may initiate the session. In some cases, the last message can be skipped.

Soundness and security of SAKE-AM. SAKE-AM is a sound and secure AKE protocol. The proofs for SAKE-AM follow the same reasoning and are similar to that of SAKE. They yield the same bounds (see Section 6.3).

6.5 A Random-free Variant of SAKE

In SAKE (and SAKE-AM), the pseudo-random values rA, rB are used to yield a fresh session key, and participate also in the authentication of the parties. Using new values during each session contributes to achieving these two tasks. Yet, these parameters are not the only ones to evolve throughout the successive protocol runs. The master keys do also. Therefore, one can consider removing the pseudo-random values from the messages. Without the pseudo-random values, several messages become cryptographically valid for each ow (instead of one only in SAKE). 0 For instance, without rA, party A may accept as second message either τB = MAC(Kj,BkA), hra h te eeae rs peea n [HGFS15]). one ephemeral fresh a generates other the whereas lhuhupesn,ti atc”de o ra n lie euiypoet i particular (in property security claimed any break not does “attack” this unpleasant, Although eg,TSRA,btas peea H(nsm ahlgclcss hnsal xdpublic xed small, when cases) pathological some (in DH ephemeral also but TLS-RSA), (e.g., symmetric- apply and keys master shared on based is SAKE-AM) as well (as SAKE protocol The aecnet e opoieiproain(C)alw h desr oiproaeohrparties other impersonate to adversary the allows (KCI) impersonation compromise key a context, same [ABD+15]. protocols used public-key are non-DH parameters regarding true also the is not this is Yet, This DH. keys. ephemeral session with subsequent general in all case compromise passively can adversary an revealed, resynchronise. to possibility no with partner, that honest Therefore, an consecutively. to twice respect keys with master desynchronised its is update party to initiator the brings that SAKE to (updated) (corresponding the key between subsequent dependency the the to (due not keys). is master protocol our whereas [BWJM97], attacks attacks. KCI unlimited (virtually) master an separate allows use scheme executions. party DH parallel each the contrary, that of the is number On restriction this executions. cause relax concurrent may to for parallel way keys in A instances abort. multiple to running sessions keys, some symmetric evolving shared on based executions. Concurrent and public-key between distinction intrinsic diers the DH-like protocol beyond our of ways cryptography. result, kind several symmetric-key this any in Despite of scheme secrecy. forward DH application of a the form from require strong not a provides does it it Yet scheme. particular In only. functions key Paradigm DH the with Comparison 6.6 is attack mismatch this whom adequate. for more is practitioners from protocol the expects SAKE usually for the addition, one unacceptable, Consequently, In what taste. not anyone’s protocol. is of security scenario be aforementioned a not the may pseudo- by key, using provided session not possibility the Nonetheless, the derive devices. to constrained particular for in suitable values, is random Therefore, variant devices. this low-resource us for to advantageous according is This function. generation adversary pseudo-random the (if successfully completes latter the SAKE. session, in new as a passive), two start remains the they of if synchronisation is, the That damage parties. cannot scenario this Moreover, authentication). entity compel to able is is adversary an following: the from identity). index its with message either message third as or Paradigm DH the with Comparison 6.6 unaltered nte osqec ftedpnec ftemse esi AE sta neteky are keys the once that is SAKE, in keys share, master DH the xed of a dependency uses the party of a consequence (when Another scheme DH static the also aect attacks KCI that Note the calling also avoids this and shortened, is messages the of length the variant, this In mean we “attack” By attack”. “mismatch a enables values pseudo-random the of removal The τ 5 B hnaparty a When = MAC yteavrayadepce by expected and adversary the by 5 ( oevri navraysced ngtigtekey the getting in succeeds adversary an if Moreover K h peea Hshm we sn aeprmtr)i eitn gis KCI against resistant is parameters) safe using (when scheme DH ephemeral The P j 0 i − sln-emsce e sdslsd navraycnimpersonate can adversary an disclosed, is key secret long-term ’s 1 B , k 0 A k ) τ or , A u rtclde o lo aalleeuin.Ide,snei is it since Indeed, executions. parallel allow not does protocol Our or 1 τ to B 1 k = 4 τ A btnttes n hc are nyteinitiator’s the only carries which one rst the not (but MAC osqety nti ain,w r ahMAC-ed each prex we variant, this in Consequently, . K j 0 +1 ( K .Hneteavraycnfreamessage a forge can adversary the Hence ). j 0 +1 B A B , n yet and , ocmueamsae(message message a compute to k A ) ieie without Likewise, . A eet hsmsaea invalid. as message this rejects K 0 (or K P i j 0 oohrpris nthe In parties. other to ,secncompute can she ), r B , B a accept may 4 which ) to m P i B . 159 in

6 160 Chapter 6 SAKE: a Two-party AKE

Post-quantum setting. Now a probable benet of our protocol compared to the DH scheme is that, since it is based on symmetric-key functions, it can likely survive in a post-quantum world (with a suitable choice of the primitives [KLLN16a] and key length [Gro96]). On the contrary, the DH scheme is known to be insecure in such a context [Sho94; PZ03; KJ17]. Yet, we observe that there exists a post-quantum variant of the original DH scheme [JD11; CLN16], but it is based on larger parameters and heavier computations than SAKE. Moreover this post-quantum variant does not provide entity authentication.

Computations. The DH scheme implies heavier computations (modular exponentiations, elliptic curve point multiplication) than SAKE which is solely built on symmetric-key functions. In practice, SAKE is likely more suitable to be implemented on constrained devices which have limited computational (and communication) capabilities. 6

Contents without cost, computation) servers. and other one (communication with from reduced switch established a securely sessions at to the forth end-device compromising and (mobile) of a back properties for another security ability to the the server from in results inherits This latter the protocol. that the such instantiation. servers) its and and end-devices protocol numerous the of security the prove formally to used model security cost, computation end-devices. and constrained communication for saving advantageous partic- allows is (in This and security maintained). impairing is without secrecy resumption based forward session ular, symmetric-key enables deployed it widely Furthermore, to contrast protocols. IoT network), in secrecy, back-end the forward and symmetric-key guarantees end-device on protocol the based this between Solely done au- network. computations 3-party a the generic such (regarding a to functions describe dedicated we protocol Consequently, exchange between network. key operations IoT thenticated interleaved an the of consider components and diverse vision security our the stronger widen we with we 6, SAKE chapter, Chapter this protocol In In exchange properties. key attacks. authenticated practical 2-party (likely) the to presented leading have weaknesses several from suer they that servers). powerful end-devices, (low-resource capabilities dierent W h eut fti hpe aebe ulse n[ACF19]. in published been have chapter this of results The involving (i.e., deployment IoT real-case a in applied a be devise can and protocol exchange SAKE, key on 3-party based The protocol our of instantiation concrete a present we addition, In show and devices, constrained to dedicated protocols analysed have we 4, and 3 Chapters In . eso eupinProcedure Resumption Session 7.3 Protocol AKE 3-party the of Description 7.2 Introduction 7.1 tes hyama oncigwt n nte utpecmoet hc have which components multiple another among one NB-IoT with connecting and at Sigfox, aim LoRaWAN, They as others. such promoted, strongly Things or of Internet deployed the of rise the ith .. h uligBlocks Building The 7.2.3 .. oprsnwt te eso eupinSchemes Resumption Session Other with Comparison ED Low-resource for Procedure Resumption 7.3.3 Session Procedure Resumption Session a for 7.3.2 Rationale 7.3.1 Protocol 3-AKE the of Features Main 7.2.4 Distribution and Computation Key Roles Dierent 7.2.2 The 7.2.1 .. u Approach Our 7.1.2 Context 7.1.1 ...... he-at AKE Three-party ...... eea euiypooosaewidely are protocols security several ...... 7 172 165 167 168 169 175 172 172 166 165 171 167

7 164 Chapter 7 Three-party AKE

7.4 Concrete Instantiation ...... 175 7.4.1 Forward Secret 2-AKE Protocol P ...... 176 7.4.2 Protocol P with Session Resumption Scheme for Low-resource ED 177 7.4.3 Protocol P 0 and Function ENC ...... 178 7.5 Security Proofs ...... 181 7.5.1 Generic 3-AKE Protocol ...... 181 7.5.2 SAKE-R ...... 185 7.5.3 Achieving 3-AKE Security ...... 193 ieydpoe rsrnl rmtdoe uha ifx[i1b i1a,LRWN[LoR18a; LoRaWAN Sig17a], [Sig17b; Sigfox as such ones promoted strongly or deployed widely hs w niisnest omnct ihec n-eiefrdrn upss which purposes, dierent for end-device each with communicate to needs entities two These that networks managing at aims it since applications sensitive covers (IIoT) and IoT cases Industrial The use of types dierent to birth gives (IoT) Things of Internet the of arising The aubedt n rvd oesrie,adtecmuiainpoie hs ewr is network whose provider communication the and service), some provide and data valuable eie hc r o bet pl ev opttosipidb smercschemes. asymmetric implement by usually networks implied IoT computations deployed currently heavy on apply used to protocols security able Consequently, not are which devices layers. the of separation Cryptographic IoT no knowledge, our scheme. of resumption best session the a to proposes and, protocol secrecy, (cellular forward these provide of protocols None non-cellular) (EC-GSM-IoT). and IoT Machine-Type GSM enhanced Coverage (NB-IoT), Extended IoT (eMTC), Narrowband Communication as belong such protocols technologies of cellular class and this Sor17], root To end-device) network. (per back-end unique the and and static end-device a the of between use shared make key and functions, symmetric-key on security 7.1 Figure channels. 7.1). secure Figure independent (see two objects implies connected its with communicate to provider some application get the to by objects used connected of, the involvement exploits the (which implies provider This application area. the (e.g., urban players: objects an two connected over least, where all at zone widespread of coverage are management large etc.) domestic a actuators, a require sensors, merely may implies context IIoT and where the perimeter case, network, house home the the smart to the localised to is Contrary network etc.). a water, energy, (e.g., resources valuable provide several to Things According of etc.). IoT, Industrial “ eHealth, reports, cities, smart home, (smart environments Context 7.1.1 Introduction 7.1 Introduction 7.1 utemr,a niae nCatr1 h rtcl o h Idsra)ITbidtheir build IoT (Industrial) the for protocols the 1, Chapter in indicated as Furthermore, is8 n “ and [i-s18] ” h nutilItre fTig stebgetadms motn ato h Internet the of part important most and biggest the is Things of Internet Industrial the – hog omncto evr( server communication a through ( end-devices between Connection End-device h igs rvro rdciiyadgot ntenx decade next the in growth and productivity of driver biggest the Communication Server h Idsra)ITivle o-eoreend- low-resource involves IoT (Industrial) The − ED CS − akednetwork Back-end ← ) n napiainsre ( server application an and ) Application Server [Acc15]. ” → AS 165 )

7 166 Chapter 7 Three-party AKE symmetric-key functions only, and are based on a unique (per end-device) symmetric root key. Using the same root key implies that the communication layer and the application layer are entangled. The communication provider must guarantee that only legitimate parties can send data through its network, but does not need to get the application data. The application provider must keep full control over its connected objects, but must not be able to interfere with the management of the communication network. Therefore, the communication and the application layers must be cryptographically distinct.

Forward secrecy. The (Industrial) IoT protocols based on symmetric-key functions do not provide strong security properties usually ensured by asymmetric schemes, in particular forward secrecy. The disclosure of the root key compromises all the past sessions established with that key, not to mention the consequences of an intrusion into the back-end server that centralises all root keys. The current symmetric-key based IoT protocols lack in providing this fundamental security property.

Session resumption. A session resumption scheme allows establishing a new session at a reduced cost: once two parties has performed a rst key exchange, they can use some shared key material to execute subsequent runs faster. This means less data exchanged during the key agreement, and reduced time and energy, which is particularly convenient and advantageous for low-resource end-devices. Yet, the symmetric-key based IoT protocols always execute the same full key exchange.

7.1.2 Our Approach The basis of our approach is the need for an authenticated key exchange protocol guaranteeing better security properties than that of existing IoT protocols (including widely deployed ones), and being at the same time suitable for low-resource end-devices. Consequently, we consider the symmetric-key setting. In order to cryptographically separate the communication and the application layers, we consider a LoRaWAN-like architecture with a trusted third party behaving as a key server (see Chapter 3, Section 3.5). But we use the latter in a more ecient way. We describe an authenticated key exchange protocol that involves three parties: an end-device, a (communication or application) server, and a trusted third party (the key server). This protocol is solely based on symmetric-key functions (regarding the computations done by the end-device), and yet it provides forward secrecy. Moreover our 3-party protocol allows resuming sessions. A full run implies the involvement of the trusted third party in order to establish a session between an end-device and a (communication or application) server. The resumption procedure allows executing the subsequent runs between the end-device and the same server without the trusted third party being involved. That is, all the messages exchanged with the latter are saved. This means a faster session establishment with reduced time and energy (in particular for the low-resource end-device). Our resumption scheme implies a small and xed size storage in the end-device’s memory independently of the number of sessions that can be resumed. Finally, our protocol allows resuming sessions without impairing security: it combines session resumption and forward secrecy. An IoT network involves many entities and not only a pair of end-device and server. Our 3-party key exchange protocol can be used to deploy an arbitrary number of end-devices and (communication or application) servers within the same network (i.e., aliated to the same trusted third party). This allows in particular a (mobile) end-device to switch from one com- hc nue oefntoaiy(omncto rapiaini u ae.Ti sachieved is This case). our in application our or with (communication functionality some ensures which AS of purpose The channels. secure separate two establishing at aim keys These ED. with Suefse wrd oncin ihec te,adhv eve aaiiis nparticular in capabilities, heavier have and other, each with connections (wired) faster use AS exchange to order In service. that ensure to etc.) actuator, an sensor, a (e.g., ED exploits AS h elcs o elyetw osdrivle four involves consider we deployment IoT real-case The to enables subsequently This keys. session output to is protocol our of purpose main The eto o ipiiyol h w ye fC n Ssres oehls,rcl htthey that recall Nonetheless, will servers. we chapter, AS the and of CS remainder of the types In two the channel. only secure simplicity a for establish mention to XS and ED allows that server a with key session a share KS to to ED respect allow to with is way reach same to the goal behave main The AS ED. and and CS perspective, cryptographic a from However, and CS, of KS, kind that computational. The assume service). we dierent whereas end-device a wireless providing (low-resource) one (each a AS is sake protocol several consider the our by we For with ED used service. possible be its cryptographically) ED provide (i.e., same to technically the order be in that also ED several may use it can genericness, AS of An CS. several or one to interface. connect also radio needs the CS regulate operator. to telecom order a in by e.g., grants ED, managed which with is CS, communicate CS is Typically privately point entry network. The that network. to communication access a ED use The AS and etc.). ED automation, data, condential equipment tracking, asset keys telemetry, session (e.g., distinct service share some to provide CS to and is AS allow to and ED, authenticate to is purpose main its Server name Roles Dierent dened The be it 7.2.1 let and channels, these detail not context. an specic and do We their hand, on one hand. the depending other on the server on communication server a application with channels, secure distinct ( two exchange establish key authenticated 3-party generic our describe we section, this Protocol In AKE 3-party the of Description 7.2 matches which party, third trusted a and server, time a end-device, an between executed without servers application dierent servers. two other by with used established be sessions to compromising or one, another to server munication Protocol AKE 3-party the of Description 7.2 ssi,teacietr ecnie novsfu ye fette:K,E,C,adAS. and CS, ED, KS, entities: of types four involves consider we architecture the said, As to have may hence mobile, or static either be can ED An ED. several manage can KS One ( exchange key authenticated 3-party a present we chapter this in up, sum To • • • • h olwn properties: following the uhniainadKyServer Key and Authentication h rtclpoie owr secrecy. forward provides protocol The resumption. session enables protocol The separated. are layers security communication and Application computations the (regarding end-device). functions the symmetric-key by on done based solely is protocol The C) n the and (CS), 3-AKE rtcl xctdbtenK,E,adX,tepooo upt e material key outputs protocol the XS, and ED, KS, between executed protocol: plcto Server Application K) the (KS), A) Si ncag fteoealscrt ftesystem: the of security overall the of charge in is KS (AS). plcto End-device Application roles h rse hr at htwe that party third trusted the : E) the (ED), 3-AKE 3-AKE Communication XS { ∈ ttesame the at protocol. ) protocol ) CS , AS 167 }

7 168 Chapter 7 Three-party AKE represent in fact the several servers which are actually involved in the IoT architecture we consider.

7.2.2 Key Computation and Distribution

Our 3-AKE protocol is based on a pre-shared symmetric key mk known only to two parties: ED, and KS which ED is aliated to. Each ED owns a distinct master key mk. A 3-AKE run is split in two main phases. Each phase appeals to a 2-party authenticated key exchange (2-AKE) protocol, whose security properties will be made explicit in Section 7.2.3. During the rst phase (Figure 7.2), ED and KS perform a 2-AKE run with the shared master key mk. During the second phase (Figure 7.3), ED and XS ∈ {CS, AS} use the output of the rst key exchange to perform an additional 2-AKE run. This yields a session key used to establish a secure channel between ED and XS. In practice, since our architecture involves two types of XS servers, a 3-AKE run is done rst between KS, ED, and CS, and then between KS, ED, and AS. This yields two distinct session keys. With each session key, a secure channel can be established between ED and CS on the one hand, and ED and AS on the other hand.

ikc/ika ← KDF(mk) mk KS

AKE ED CS AS mk ikc, ika ← KDF(mk) ikc/ika ← KDF(mk)

(a) 2-AKE run executed between ED and KS (relayed by CS) with mk

mk KS

{ {

ik ik

c a } } KS KS -AS - CS

ED CS AS mk ikc, ika ← KDF(mk) ikc, ikaik←c, KDFika (mk)

(b) Transmission by KS of intermediary keys ikc (to CS) and ika (to AS) respectively through the secure channels {·}KS-CS established between KS and CS, and {·}KS-AS established between KS and AS

Figure 7.2 – 2-AKE run executed between ED and KS with mk, and distribution of ikc, ika Protocol we features main the below have. list to we blocks protocol, building 3-party three our these of require properties the clear making Before Our Blocks Building The 7.2.3 4-5). steps to (corresponding XS and ED key session a also of but output unique the the from case, keys either two in yields used AKE. that be 2-party step can original derivation protocol the computed exchange additional be key an keys same in both The lying that dierence run. possible same be the also during may once it at Conversely, dissociated. completely be can keys intermediary Variants. by output key session the with CS) (resp. AS and Let call CS). KS We ENC between (resp. 5). channel AS (step and secure AS KS the and between up ED side and back-end 4), the (step on CS used and ED 1-2), (steps KS and Protocol AKE 3-party the of Description 7.2 utemr,the Furthermore, call We AS. and CS, ED, KS, between executed are steps following the precisely, More 6. 5. 2. 4. 1. 3. • • • 3-AKE sue se )t encrypt to 3) (step used is Fgr 7.3b). (Figure 7.3a). (Figure Fgr .b.Te,uo eeto fteky yC n S Sdltsisoncopies own its deletes KS AS, and CS by keys the of reception upon Then, 7.2b). (Figure channel elaborate (we protocol the 7.2.4). of phases Section in subsequent this the of on more security the enhance to order in sends KS ( step previous The a outputs AKE rst This 7.2a). key ure master shared the on Based h ceegaate owr secrecy. forward guarantees scheme The solely. functions symmetric-key on based is authentication. scheme mutual The provides that protocol AKE 2-party a is scheme The distinct key session application the Using Using Using key intermediary P P rtcldpnscuilyo h -at protocols 2-party the on crucially depends protocol . o h aeo lrt,w aedpce nFgr .atecs hr h two the where case the 7.2a Figure in depicted have we clarity, of sake the For ik h rtclta novsE,adi sdt efr the perform to used is and ED, involves that protocol the ik ieie ihtecmuiainssinkey session communication the with Likewise, . omncto euechannel secure communication c erqieprotocol require We a DadC efr nAEwihotusa outputs which AKE an perform CS and ED , DadA efr nAEwihotusan outputs which AKE an perform AS and ED , ik c ik 2-AKE oC,and CS, to c sk and ik hnK ed both sends KS Then . a 2-AKE . u ewe DadK a uptntol nitreir key intermediary an only not output can KS and ED between run ik a r ucsieycmue.Bttecmuaino ihrkey either of computation the But computed. successively are ik ik P srpae ewe SadE.I upt an outputs It ED. and KS between repeated is ) a a , (resp. oA hog w itntpeeitn euechannels secure pre-existing distinct two through AS to P P 0 ofll h olwn properties. following the fulll to and , sk mk omncto nemdaykey intermediary communication ik a DadA a o sals an establish now can AS and ED , SadE efr nAE eae yC (Fig- CS by relayed AKE, an perform ED and KS , c Fgr 7.3c). (Figure ro obigsn yK oA rs.CS). (resp. AS to KS by sent being to prior ) ENC ik and sk oX.Ti ae nAErnbetween run AKE an saves This XS. to ENC sk omncto eso key session communication P c DadC a sals a establish can CS and ED , plcto eso key session application etefnto sdt set to used function the be and 2-AKE P P 0 0 ik n function and , the c plcto secure application usbtenED between runs . 2-AKE application P 0 protocol htis, That . ENC sk 169 sk ik a c .

7 170 Chapter 7 Three-party AKE

mk KS

AKE ED CS AS mk ikc ika ikc, ika skac ← KDF(ikac) skc ← KDF(ikc) ska ← KDF(ika)

(a) 2-AKE run executed between ED and CS with ikc

mk KS

AKE ED AS ED CS AS mk ikc ika ikc, ika skc skc ska ← KDF(ika) ska ← KDF(ika)

(b) 2-AKE run executed between ED and AS (relayed by CS) with ika

mk KS

{·}ska ED AS {·}skc ED CS AS mk ikc ika ikc, ika skc ska ska ←skcKDF, ska(ika) ska ← KDF(ika)

ED and CS, and application channel {·}ska between ED and AS

Figure 7.3 – 2-AKE run executed between ED and AS (resp. CS) with ika (resp. ikc), and subsequent secure channels eifral ealwa h owr erc rprymasi hssmerckycontext. symmetric-key this in means property secrecy forward the what recall informally We lhuhi sntrltdt h angasw ake eadtefloigrqieetin requirement following the add we tackle, we goals main the to related not is it Although ses12 eto ..)cnb ntae yaybtol hs w niis Each entities. two these only but any by initiated be can 7.2.2) Section 1-2, (steps DadK ilsadrn nemdaykey intermediary key each dierent a First, yields server. KS another and with ED security the impairing without server key server. any to connection Secure parties legitimate from received and to sent CS are respectively, keys and, KS intermediary only. between the done that authentication guarantees mutual AS, The and AS). and ED (between layer and layers. the of separation XS. Cryptographic corrupted or dishonest a against defend can ED and KS Hence, and ED key by intermediary ED shared new and a key KS creates between KS done and exchange ED key between The system. the of security overall the manage to KS security. the of Management our by provided features properties. main these the section this in detail components main three the that prove a a presented demand have we we properties 5.2, Section 5, Chapter In Protocol 3-AKE the of Features Main 7.2.4 messages. of non-replayability include we latter Function used. be Since secrecy. forward and tion, Protocol 6. Chapter in introduced have keys session key intermediary current the of a in Likewise, parties. two revealed. is secret) shared key the compute and parties the authenticate to (used key root symmetric a Once protocol: 3-AKE the of exibility the improve to order Protocol AKE 3-party the of Description 7.2 nScin74w rsn oceeisatainof instantiation concrete a present we 7.4 Section In a in precisely, More • ik mk ik ik n ftetopriscniiit u fprotocol of run a initiate can parties two the of Any et Sdltsiscp of copy its deletes KS Next, . a ihay(omncto rapiain evr oevr Dcncnetaysuch any connect can ED Moreover, server. application) or (communication any with 2-AKE lossprtn h omncto ae btenE n S n h application the and CS) and ED (between layer communication the separating allows ue sro e)ms o opoieps nemdaykeys intermediary past compromise not must key) root as (used P ENC 0 . sk u of run . edemand We optdb DadXS. and ED by computed edemand We P 2-AKE XS scmlt,ps uptscesms eanpiaeee ftecurrent the if even private remain must secrets output past complete, is 3-AKE 2-AKE { ∈ P u oebtenE n S h icoueo h urn master current the of disclosure the KS, and ED between done run 0 ENC CS rtclt nue nScin751w s hsscrt oe to model security this use we 7.5.1 Section In ensure. to protocol ob secure a be to P u oebtenE n some and ED between done run ik , h e irrh (between hierarchy key The AS 0 ik ue sro e nta ae utntcmrms past compromise not must case) that in key root as (used opoiedt oetaiyaddt uhniiy nthe In authenticity. data and condentiality data provide to sapidbtenK n S smercfntosmay functions asymmetric XS, and KS between applied is } sso si a enrcie yX.Finally, XS. by received been has it as soon as P The n dsoncs Dfo Sb resetting by XS from ED “disconnects” and , , P 3-AKE 0 and ik 2-AKE 3-AKE h s ftodsic nemdaykeys intermediary distinct two of use The ec ahprnrdE n Sueadistinct a use XS and ED partnered each Hence . ENC rtclalw Dt hr nintermediary an share to ED allows protocol ik rtclta rvdsmta authentica- mutual provides that protocol il secure a yield hsosltstecretintermediary current the obsoletes This . euiymdlta omlyde the denes formally that model security P 3-AKE ae nteSK rtclta we that protocol SAKE the on based P . mk rtcladifral justify informally and protocol XS , 3-AKE ik { ∈ 2-AKE and , CS ik , rtcl eoe we Before, protocol. optdb these by computed sk AS u oebetween done run ,alw Dand ED allows ), } h disclosure the , 2-AKE P ik provides tED. at done 171 ik c

7 172 Chapter 7 Three-party AKE forward secrecy. The disclosure of the current master key mk (stored at ED and KS) does not compromise a past output key ik. The forward secrecy ensured by P 0 and the security of the channel established with ENC participate also in the condentiality of ik. Likewise, due to the forward secrecy of P , past session keys sk (computed between ED and XS) remain private, even if the current key ik (stored at ED and XS) is exposed

Quick session establishment. Once a rst intermediary key ik is shared between ED and XS, these two parties can perform as many 2-AKE runs (hence set up as many successive secure channels) as wished without soliciting KS anymore (i.e., ED and XS repeat several times step 4 or 5, Section 7.2.2). This avoids overloading KS (which has to manage many ED and XS). An additional consequence is also that the number and the frequency of the connections established between ED and XS are hidden from KS.

7.3 Session Resumption Procedure

In this section, we explain how to shorten the genuine key exchange procedure of the 3-AKE protocol such that ED and CS or AS, after a rst successful protocol run involving KS, can execute subsequent key exchanges without the need for KS to intervene.

7.3.1 Rationale for a Session Resumption Procedure As explained in Section 7.2.4, after a rst 2-AKE run with KS, ED shares an intermediary key ik with XS ∈ {CS, AS}. Then, ED and XS can execute, from ik, subsequent 2-AKE runs without soliciting KS anymore. Consequently, as soon as ED shares (distinct) intermediary keys with several servers, it can quickly switch from one server to another back and forth without the help of KS. This is particularly convenient for a mobile ED which must connect dierent communication providers (hence dierent CS servers). Likewise, this allows ED to connect several AS servers, hence to be securely used by dierent application providers. Moreover, since P guarantees forward secrecy, the disclosure of (the current value of) ik does not compromise past session keys sk. We call this faster mode (without KS) a session resumption procedure. Due to the intrinsic properties of the 2-AKE scheme P (see Section 7.2.3), any peer (ED or XS) can initiate the key exchange. This implies that both peers can initiate the session resumption procedure. The main benet of this procedure is to give the ability to switch between servers without soliciting KS. Avoiding the involvement of KS (that is, avoiding a whole 2-AKE run between ED and KS), allows to save time, computation cost and communication cost for KS but mainly for ED. Indeed, the ED we consider are low-resource, self-powered devices. The energy cost to transmit and to receive data usually exceeds the cost of cryptographic processing [SP05; WGE+05]. Hence it is worth saving as much as possible the amount of data exchanged to compute a new session key. Another limitation of a low-resource ED is its memory space. Being able to resume a session with several servers implies storing simultaneously as many intermediary keys. This is likely possible for a server but becomes prohibitive for such kind of ED. In Section 7.3.2, we present a session resumption scheme that solves this issue.

7.3.2 Session Resumption Procedure for Low-resource ED Overview of the procedure. The session resumption procedure for a low-resource ED with XS ∈ {CS, AS} is made of two phases: hc eoe nsbe vnthough Even unusable. becomes which keys the compute we Ssres n h w osbydrn eaiuso D(e iue74.Nntees fa if Nonetheless, 7.4). Figure (see ED of behaviours dierent possibly two the and servers, AS fracntandE)rgrigmmr,o h muto rnmte aa[e1;AJ9.In AGJ19]. [Res18; data transmitted of amount the or memory, regarding ED) constrained a (for intended yet ST10]), Res18; [SZET08; (e.g., schemes existing of reminiscent is procedure This ieetcnetrqie o nqecano erpinky a lob maintained. be also can keys decryption of chain unique a so, requires the context to dierent corresponding keys we decryption Therefore, AS. of with chains unusable two procedure of resumption use session the the advocate makes This point. some at again compute cannot ED Consequently, updated. is key decryption key current forth the and back CS switches with exchange and AS, CS AS, one at by respectively managed CS is servers other ED two low-resource between mobile A scenario. k keys. of chains Two sessions. many as resume anymore. decrypted be key consume current to wants ED When ticket. key one only memory in k chain key key dierent a with encrypted be must keys session the compromising revealing secrecy: forward breaks obviously key decrypt encryption to same needs the ED Using Only encrypted. is ED by ticket. the Computing below. explained as our issue, contrast, this In to schemes. solution resumption shrewd other a with provides proposal protocol our compare session we combining 7.3.3 in Section succeeds requirements prohibitive latter or the cryptography of asymmetric without none secrecy However forward IoT. and than resumption context dierent a to Procedure Resumption Session 7.3 i i +1 +1 (b) (a) This key random initial an From ik = = . Struhteogigscr hne.Uo eeto ftetce yX,E deletes ED XS, by ticket the of reception Upon channel. secure ongoing the through XS otniyo h u,tetce thssn rvosy et Ddcyt h iktand ticket the key session decrypts new ED a Next, previously. sent key has corresponding it the ticket gets the run, the of continuity The to “ticket” resulting the sends ik ED Next, below). this on elaborate (we itself to only known sk The ihaohr(nrpin key (encryption) another with H unique H hnE a ls h hne n time. any channel the close can ED Then . otu by (output ( ( k k trg phase storage erea phase retrieval i i k ) ) j , ec n previous any Hence . , i nrpinkygvsE h blt ocmuemlil ikt,teeoeto therefore tickets, multiple compute to ability the ED gives key encryption i k ≥ ≥ i a with 0 tretrieves it , j . P : KW k a .Bt hr nitreir key intermediary an share Both ). k i n CS and , k DadX aea non euecanlstu ihassinkey session a with up set channel secure ongoing an have XS and ED . = sdt nrp h nemdayky seeet fa of elements as keys intermediary the encrypt to used j sk When Dsat new a starts ED . +1 sakywa ucin[S6,and [RS06], function key-wrap a is k h nemdaykey intermediary The H j . hskyi h hl ftekyta a erpe h atused last the decrypted has that key the of child the is key This . = i a − k j n CS and H k b ( ticket sk ticket Dkestedcyto key decryption the keeps ED . 0 opoetdrn nemdayky sn odrn servers) dierent to (sent keys intermediary dierent protect to k ( ahtce scmue as computed is ticket each , k ik j ) j optdwt h atr hrfr ahitreir key intermediary each Therefore latter. the with computed ticket Then . ) hn DadX opeeternwith run the complete XS and ED Then, . k hnvrE lentsbtenCS between alternates ED Whenever . ticket b j k i ilstesm eoyiseadi onls.Therefore, pointless. is and issue memory same the yields Dsoe fresh stores ED . ticket oee,rpaigi Dsmmr ahintermediary each memory ED’s in replacing However, . n erpsi with it decrypts and sue,tecretdcyto e srpae with replaced is key decryption current the used, is j k , 2-AKE i ts optstedcyto key decryption the computes rst it , j j k i srpae with replaced is ik ≤ losdecrypting allows a h otrcn ikt twudb obsoleted be would it ticket, recent most the was ik i ic h evrsoe t w oyo h key. the of copy own its stores server the since sosltd e scnie h following the consider us Let obsoleted. is , u ihakonX.Frt Dgt,i the in gets, ED First, XS. known a with run hti trda h evradltrretrieved later and server the at stored is that ticket ik is,E encrypts ED First, . k H i k j , ticket i ticket k = +1 n-a ucin Dkeeps ED function. one-way a past i hnE ae e key new a makes ED When . H = j − i H nemdayky,hence keys, intermediary +1 j i and , ( ( k k k = i i i ) ) n decrypt and w types two a hn Dreplaces ED Then, . and , KW ticket n CS and ik ( ik n compute and , ticket k i n-a key one-way k +1 ne key a under k , b h ticket the , i k < j < i fC and CS of ik , rmthe from i ticket cannot 3-AKE ) with 173 i ,

7 174 Chapter 7 Three-party AKE

If the tickets are used in the same order they are computed, all can be (legitimately) decrypted. In particular, according to us, it is likely, that ED, when alternating between several CS servers (or, equivalently, between several AS servers) uses the corresponding tickets accordingly. Figure 7.4a depicts the case where a CS ticket (ticketi) is used. The corresponding decryption key ki is deleted, and ED keeps only ki+1. This obsoletes all previous CS tickets. Figure 7.4b 0 0 depicts the case where an AS ticket (ticket0) is used. The decryption key k0 is deleted, and ED 0 0 keeps only k1. All AS ticketj, j ≥ 1, are still usable.

0 0 k0 ticket0 k0 ticket0

H H 0 0 k1 ticket1 k1 ticket1 H H . . . . H H 0 0 ki ticketi kj ticketj

H H 0 0 0 ki+1 ticketj+1 kj+1 ticketj+1

(a) CS tickets and keys (b) AS tickets and keys

Figure 7.4 – Chains of keys used to compute a ticket. The tickets already used cannot be decrypted because the corresponding key cannot be computed anymore. The used tickets and their key appear in a dashed box . The current key and the available tickets appear in blue.

Maintaining forward secrecy. When ticketi is used, the current encryption key kj, j ≤ i, stored at ED, is replaced with the next encryption key ki+1 = H(ki). This forbids any old ticket from being decrypted. All the remaining tickets that can be decrypted (from the now current key ki+1) have not been used yet. Moreover, the protocol P provides forward secrecy. Hence, the disclosure of the intermediary key ik protected into a (not used yet) ticket does not compromise past session keys sk. In a way, the session resumption procedure inherits the forward secrecy from P (and also the one-wayness of function H). This property is formally proved in Section 7.5.2. The use of the (forward secret) intermediary key ik highlights also why encrypting the session key sk in the ticket is not a good choice. The more data the same session key protects, the worse its disclosure.

Remark. Another reason to opt for ik is eciency. In fact, sk may be quite large (e.g., two pairs of keys, encryption and MAC, for each direction, and the last value of the uplink and downlink frame counters). The ticket is transmitted twice between ED and XS. As explained above, the amount of data exchanged with the server is a burden for a wireless low-resource ED. From a single intermediary key ik, any kind of security parameters can be computed. Hence the choice ehv ocos a choose to have We hra trmisee n iktntue e rmtepeiu ac,toky tecurrent (the keys two batch, previous the from yet used not ticket one even remains it whereas compromise may secret reused the of disclosure Hence procedures. IKE) (TLS, these with RS uptb h rvoskyecag,adsoe ta h let nIE2[H+4,a [KHN+14], IKEv2 In client. the at it stores and exchange, key previous the by output (RMS) Nonethe- scheme. resumption session a proposes protocol IoT no knowledge, our of best the To nti eto epeetacnrt ntnito four of instantiation concrete a present we section this In Instantiation Concrete 7.4 of amount and cost, computation space, memory to related data. issues transmitted the mitigates it time same the of lifetime battery the As limits which end-device. energy, low-resource costs a bit end-devices. transmitted for self-powered each issue al., an et is Aviram by tickets noticed big retrieving) (and sending memory. server’s However the in concurrently stored be must one) of new batch the new and a if that, observe We server. the by stored and generated the yield to used (say tickets (client). of end-device the number for prohibitive point) is some which to used, (up is grows ticket key a decryption time the functions. each that symmetric-key implies implement despite scheme excluded, only is tree-based can scheme their that based Moreover, end-devices RSA IoT al.’s low-cost et Aviram for the elegance, First, its sucient. not is ticket) the stores the memory servers constrained of with number end-devices schemes. the low-resource these with Hence, apply grows cannot with. store session to a tickets resume of can all number client ticket As the a scheme. Therefore storing two tree-based client. implies a describe proposal the al.’s is They at et Aviram other schemes, the 1.3. resumption [RSA78], TLS session RSA aforementioned in on the based used is is One 0-RTT instantiations. when concrete non-replayability and secrecy forward solutions secrecy. these forward Therefore to sessions. respect past with to compromises satisfactory server disclosure persistent not the its be are may and by STEK memory used a server’s Hence is the clients). (STEK) in dierent Key to (corresponding Encryption values to Ticket RMS added [DH76]. several Session be scheme encrypt same can Die-Hellman the the secret TLS, applying fresh implies in a Moreover, this 1.3, but TLS computation, In derivation secrecy. key forward the breaks this sessions: past several secret” master [ST10]. “resumption used a is encrypts approach similar server the [Res18], 1.3 TLS In client. the at [SZET08] contexts. other in exist schemes such less, Schemes Resumption Session Other with Comparison 7.3.3 of Instantiation Concrete 7.4 h eupinshm edsrb eessterlso let(n-eie n evr At server. and (end-device) client of roles the reverses describe we scheme resumption The size. ticket for size key decryption trades that alternative an also propose al. et Aviram xed a computing allow al. et Aviram by described tree-based) and (RSA- schemes two The server the and computes client the (i.e., server the and client the by taken roles the Reversing guaranteeing at aiming scheme resumption a propose [AGJ19] Jager and Gellert, Aviram, executed be can runs successive key, master symmetric as used value, secret same the From Ticket” “Session that store and secret” “master the encrypt can server the [DR08], 1.2 TLS In ik . n ikt.I re ocmueanwbthof batch new a compute to order In tickets. 2-AKE n .Oeky(smerco ymti eedn nteshm)is scheme) the on depending symmetric or (asymmetric key One ). scr protocol -secure P a , 2-AKE 3-AKE scr protocol -secure rtcldsrbdi eto 7.2. Section in described protocol n ikt,anwkyms be must key new a tickets, n ikt scomputed is tickets P 0 n secure a and , 175

7 176 Chapter 7 Three-party AKE authenticated encryption function ENC. Regarding protocol P , we recall that it must fulll the properties listed in Section 7.2.3, which includes the essential forward secrecy. We describe an instantiation of P with (Section 7.4.2) and without (Section 7.4.1) the session resumption procedure for low-resource ED.

7.4.1 Forward Secret 2-AKE Protocol P

We instantiate the 2-AKE protocol P with the SAKE protocol described in Chapter 6. SAKE fullls all the properties listed in Section 7.2.3.1 We recall that SAKE uses a key-evolving scheme, based on a one-way function, to update the symmetric root key shared by the two peers. Thus, applying SAKE, ED and KS compute an intermediary ik with their shared master key mk (used as SAKE root key). The current master key is then updated with the one-way function update: mki+1 ← update(mki). Likewise, applying SAKE, ED and XS ∈ {CS, AS} compute a session key sk with the key ik they share (used as SAKE root key in that case). Eventually, the SAKE root key used in that case is updated: ikt+1 ← update(ikt).

mk0 update mk1 mk0 mk1 ··· KDF . . ik2 update ik3 mkik00 ik1 ik2 ik3 ··· KDF KDF

sk0 sk1 sk2 sk3

Figure 7.5 – Key chains in SAKE

Figure 7.5 depicts the evolution of the three types of keys over time: the master key mk, the intermediary key ik, and the session key sk. The computation of ik0 and mk1 from mk0 corresponds to the 2-AKE run executed between ED and KS as depicted by Figure 7.2a. The computation of sk2 and ik3 from ik2 corresponds to the 2-AKE run done between ED and CS (resp. AS) with ik = ikc (resp. ik = ika) as depicted by Figure 7.3a (resp. Figure 7.3b). Note that the keys ikc and ika are computed from two dierent values mk (i.e., yielded by two dierent 2-AKE runs between ED and KS). In Figure 7.5, the branch mk0 → mk1 → · · · corresponds to the evolution of mk throughout successive key exchange runs executed between ED and KS. Each of these runs yields a new intermediary key ik = ik0. The branch ik0 → ik1 → · · · corresponds to the evolution of ik throughout successive key exchange runs (each one outputting a session key ski) executed between ED and XS without the involvement of KS.

1Any other 2-AKE protocol can be used, as long as it provides the same properties as SAKE, but we are not aware of other such protocols. ihtecrepnigtce.Teparameter The ticket. corresponding the with fX osntrciemessage receive not does XS If ticket. consumed already an of replay any rejects (see message H rst the in sent is ticket the initiator, session the 7.9). the is Figure and server authentication, the mutual When the computation. in key participate that values pseudo-random embed responds XS retrieve. to ticket the index of (see identier SAKE-R an with carries phase XS retrieval to the sent message initiates rst ED the When 7.8), 7.3.2). Figure Section (see XS with established and ticket, the decrypt key derivation ik key current the between “distance” the H keys. the of evolution the regarding procedure SAKE-R. with procedure variant resumption this Session call We ticket. the of use the include to adapted protocol SAKE the 7.3.2): Section phase a (see phases is resumption two (ii) session of the and made that 7.3.2, is Recall procedure Section secrecy). in forward particular, described This in include, ED. procedure (which low-resource the protocol to secure of features dedicated the scheme resumption fullls session (i) a scheme describe we section, this In Protocol 7.4.2 Instantiation Concrete 7.4 ( n ecnosreta Dudtsisro key root its updates ED that observe can We gets ED Once They protocol. SAKE original the as same the essentially are messages subsequent The channel secure ongoing the through ticket the sends merely ED phase, storage the During parameter The computation The procedure. resumption session the of phase storage the depicts 7.7 Figure k (i.e., ( k i ) j where , = ) i pae().Tertivlpaeo h ceefrlwrsuc Di ain fthe of variant a is ED low-resource for scheme the of phase retrieval The (b)). (phase utb sdt erp h orsodn ticket. corresponding the decrypt to used be must ) n = mk H sk ik ( i 0 0 · · · 0 k − i K iue7.6 Figure j stekyue odcyttertivdtce seScin732.Teeoe ED Therefore, 7.3.2). Section (see ticket retrieved the decrypt to used key the is H ik .SK hneSK-)ue w anky:a uhniainkey authentication an keys: main two uses SAKE-R) (hence SAKE ). Therefore, . P ( id h iktdcyto key decryption ticket the , H ticket ihSsinRsmto ceefrLwrsuc ED Low-resource for Scheme Resumption Session with ( k j id )) server niae htky(.. t ne ntekycan utb sdto used be must chain) key the in index its (i.e., key what indicates · · · euigacano nemdayky (from keys intermediary of chain a Resuming – sk ik ) ik 1 1 orsod to corresponds dnie h evrta trsteticket. the stores that server the identies τ orsod to corresponds A mk tde o paeisonro key root own its update not does it , 1 k j trdb Dadte(e)key (new) the and ED by stored sk id ik ik k n j ticket 2 2 K 2 ie h plcto ffunction of application the times urnl etb Di elcdwith replaced is ED by kept currently ik k K = iue76dpcstetopae fthe of phases two the depicts 7.6 Figure niae hc key which indicates 0 trg phase storage . • eue(hs (b)) (phase resume (a)) (phase pause K k K · · · 0 pnrcpino message of reception upon sk ik 3 3 pae() n the and (a)) (phase ik k k ec Dadthe and ED Hence . i i ik SAKE-R ie,esnilyits essentially (i.e., eddt encrypt to needed 2 ) H · · · where , . K retrieval 2-AKE k 0 i n a and +1 m n 177 = B is - .

7 178 Chapter 7 Three-party AKE

ED XS

n ki ← H (kj) // ik = KkK0 ticket ← KW(ki, ik) store (idticket, idserver) id kticket −−−−−−−−−−−−−−−−−−→ticket

store (idticket, ticket, ik) ack ←−−−−−−−−−−−−−−−−−− delete ik

Figure 7.7 – Storage of a ticket server are “desynchronised” (i.e., they do not share the same value of ik). When ED initiates anew the key exchange, it executes the SAKE protocol (and not SAKE-R) since it has already retrieved ik. SAKE enables ED and XS to resynchronise in the continuity of the protocol run (i.e., SAKE is self-synchronising). Therefore, ED and XS can perform a correct key exchange, and eventually compute a shared session key sk. For the sake of clarity we use the following notation:

• kdf corresponds to: sk ← KDF(K, f(rA, rB))

• upd corresponds to 1. K ← update(K) 2. K0 ← update(K0)

Function f is deliberately left undened. For instance, f(rA, rB) can be equal to the concate- 2 nation or the bitwise addition of rA and rB. KDF is the session key derivation function used in SAKE (and SAKE-R). update is the one-way function used to update the root key (i.e., the intermediary key ik in that case). Vrf(k, m, τ) denotes the MAC verication function. It takes as input a secret key k, a message m, and a tag τ. It outputs true if τ is a valid tag on message m with respect to k. Otherwise, it returns false. We chose to model H and KDF as PRFs, and KW as an AE function.

7.4.3 Protocol P 0 and Function ENC We instantiate the 2-AKE protocol P 0 with TLS 1.3. In order not to impair the security, we enforce (EC)DHE and forbid 0-RTT mode. We dene the ENC function to be the record layer of TLS 1.3.

2The function f must be chosen such that the security of KDF is not impaired. We assume here that the cryptographic functions used are ideal (investigating this topic is beyond the scope of this chapter). . oceeInstantiation Concrete 7.4 m r if τ k // if ik ,K K, sk delete k if A A i i +1 A ik ← ← ← ( ( ( ← ←− { abort abort abort Vrf ik Vrf $ ← ← = 0 H KW kdf MAC k ← = A ( ( n 0 K j H K K ( , , ( k ⊥ k ( upd 1 k k − k r 0 0 k j } K i B , r , D[]X [B] XS [A] ED j 1 ) A ( ) i iue7.8 Figure id , λ ( K ) k then ( 0 k B − id k i 0 k ticket , A , ticket A ( ) r ticket A k k r τ , B B ( ) B 0 k k = ) r ) r A eso eupinwt AERiiitdb ED by initiated SAKE-R with Resumption Session – A k k id r false B ticket ) −−−−−−−→ −−−−−−−→ ←−−−−−−− ←−−−−−−− k ) ikt τ ticket, then m m τ τ A B 0 A B τ r if m ,K K, sk if τ delete B B B B 0 B = ) ← ( ( ← ← ←− { abort abort id Vrf $ ← 0 ticket kdf MAC MAC ticket ← false ( r 0 K B , upd 1 k 0 } A , ticket o found not ( ( λ K K ) k then 0 0 B B , r , k k B id k r τ k A A B r ticket k ) A k r ,K K, then r ) B B τ , ticket , k r A A 0 ) = ) k id ) ticket false k ticket ) then ) 179

7 180 Chapter 7 Three-party AKE

ED [B] XS [A] (−)(K,K0) (kj, idticket)(idticket, ticket)

$ λ rA ←−{0, 1} mA ← AkrAkidticketkticket m ←−−−−−−−A

if (idticket not found) then abort

n ki ← H (kj) −1 ik ← KW (ki, ticket) if (ik = ⊥) then abort

ki+1 ← H(ki) delete kj, ki

// ik = KkK0 $ λ rB ←−{0, 1} 0 τB ← MAC(K ,BkAkrBkrA) mB ← rBkτB

sk ← kdf K,K0 ← upd m −−−−−−−→B 0 if (Vrf(K ,BkAkrBkrA, τB) = false) then abort

sk ← kdf K,K0 ← upd

0 τA ← MAC(K ,AkBkrAkrB) delete ticket τ ←−−−−−−−A 0 if (Vrf(K ,AkBkrAkrB, τA) = false) then abort

Figure 7.9 – Session Resumption with SAKE-R initiated by XS ∈ {CS, AS} hoe 7.1. Theorem hrfr,wt epc otescrt oe,w en h ogtr key long-term the dene we model, security the to respect with Therefore, the (ii) protocol The desr gis h A-euiyof sAE-security the against adversary of 2-AKE-security the against where nScin522 hrfr ehv that have we Therefore 5.2.2. Section in 0. Game Game in Proof. 5.2.2. Section authentication. Entity adversary an and challenger a between adversary time polynomial probabilistic protocol, 2-AKE in in party party any For in party parties. ED any and For XS, KS, of sets the (iii) and key, private be 5.4. Denition of to security according the protocol on 3-AKE Based 2.2.5). Section 2, Chapter the by on output and key session a with the XS and of KS between channel secure a up Protocol 3-AKE Generic 7.5.1 7.4. Section in described instantiation the generic with the follow with and begin We schemes. our of security the use we section this In Proofs Security 7.5 Proofs Security 7.5 nodrt rv hoe .,w rce hog euneo ae So4 BR04] [Sho04; games of sequence a through proceed we 7.1, Theorem prove to order In P ltk adv adv sasmerckybsdpooo,whereas protocol, based symmetric-key a is ( = n 3-AKE Let 2-AKE Π ent K E Π key i , pubk euetefloighops. following the use We . , - E n auth - ltk sAE hsgm orsod oteett uhniainscrt xeietdescribed experiment security authentication entity the to corresponds game This ind E i Π eteeetta h desr ucesi aiga ntneacp maliciously accept instance an making in succeeds adversary the that event the be , protocol ( ( protocol ( = , n A A h protocol The scrt ftefunction the of -security sbsdo:()the (i) on: based is prvk P X = ) = ) X ⊥ 0 r epcieytenme fK,E,adX ate,and parties, XS and ED, KS, of number the respectively are , sascr -K rtcl and protocol, 2-AKE secure a is , , rootk ltk ⊥ rootk Π , P sflydened fully is rootk adv n 0 3-AKE eiso the on relies K xctdbtenK n S n ii h function the (iii) and XS, and KS between executed sasmercro e.W ealthat recall We key. root symmetric a is ) is ecnie h niyatetcto xeietdsrbdin described experiment authentication entity the consider we First Π Π ent hr (i) where · n ) P sascr -K rtcludrteasmto that assumption the under protocol 3-AKE secure a is - . E auth 0 euiymdldsrbdi hpe ,Scin52 opoethe prove to 5.2, Section 5, Chapter in described model security , · B n 2-AKE ( Pr[ 1 A X ENC navrayaantte2AEscrt of 2-AKE-security the against adversary an pubk + ) h E 2-AKE 2 A 2 + A 0 after adv ENC = ] n protocol . . nte3AEscrt xeietagainst experiment security 3-AKE the in sacrie ulcky (ii) key, public certied a is K adv P ent adv · h rst the scrt of -security wt epc otera-rrno ain,see variant, real-or-random the to respect (with - n auth ENC sae E Π ent · P ( P ( - n B auth K ENC B , 3-AKE P X 1 xctdbtenE n S DadXS, and ED KS, and ED between executed 2 P h he opnnsof components three the , + ) 3-AKE ) 0 h ( i 0 and , A a mlmn smercschemes. asymmetric implement can 2 + sascr A ucin n o any for and function, sAE secure a is adv ) adv P . adv protocol and P key ENC u (before, run P ent 0 ENC sae - - ind auth P K eso that show we , ( ( 0 B P B , ( Catr2 eto 2.3.1), Section 2, (Chapter Π X 1 B 2 prvk 0 + ) nomly h security the Informally, . ) 0 and , eitdi eto 7.2, Section in depicted i + ) adv rootk stecorresponding the is ltk adv B E P key 0 ENC fec at to party each of r respectively are 0 P key sa adversary an is ltk - = P 0 ind Π - P ⊥ ind and , Π r dened. are ( sdt set to used sasecure a is B .Frany For ). sasecure a is ( 0 B ) 0 B ) 2 181 an

7 182 Chapter 7 Three-party AKE

Game 1. In this game, the challenger aborts the experiment if it does not guess the party the adversary targets, and its party partners. There are respectively nK , nE, nX parties in the sets K, E, and X . Therefore we have that 1 Pr[E1] = Pr[E0] × . nK · nE · nX

Game 2. Now the parties Pk ∈ K, Pj ∈ X and Pi ∈ E are xed. In this game, the challenger aborts the experiment if the adversary succeeds in impersonating Pj to Pk or conversely. We reduce this event to the 2-AKE-security (with respect to entity authentication) of the protocol 0 P applied between Pk and Pj. Therefore we have that

ent-auth Pr[E1] ≤ Pr[E2] + advP 0 (B0)

0 where B0 is an adversary against the 2-AKE-security of P . s This guarantees that to each instance πk ∈ Pk.Instances there exists a unique instance v s v πj ∈ Pj.Instances such that πk.sid = πj .sid (and conversely).

Game 3. In this game, the challenger aborts the experiment if the adversary succeeds in impersonating Pi to Pk or conversely. We reduce this event to the 2-AKE-security (with respect to entity authentication) of the protocol P applied between Pk and Pi. Therefore we have that

ent-auth Pr[E2] ≤ Pr[E3] + advP (B1) where B1 is an adversary against the 2-AKE-security of P . m This guarantees that to each instance πi ∈ Pi.Instances there exists a unique instance ` m ` πk ∈ Pk.Instances such that πi .sid = πk.sid (and conversely).

Game 4. Another way for the adversary to win the entity authentication security experiment is to get the intermediary key ik used by Pi and Pj to mutually authenticate, or to forge a valid message intended to Pj that carries an intermediary key chosen by the adversary. In this game, the challenger aborts the experiment if the adversary succeeds in either case. The secure channel between Pk and Pj is established with the function ENC keyed with the session key output by P 0. We reduce each of the two events to the sAE-security of ENC. In turn, we must assume that the ENC key is random. The latter is reduced to the 2-AKE-security (with respect to key indistinguishability) of P 0. Therefore we have that

key-ind sae Pr[E3] ≤ Pr[E4] + advP 0 (B0) + 2advENC(B2) where B2 is an adversary against the sAE-security of ENC.

Game 5. In this game, the challenger aborts the experiment if the adversary succeeds in impersonating Pi to Pj or conversely. We reduce this event to the 2-AKE-security (with respect to entity authentication) of P . Therefore we have that

ent-auth Pr[E4] ≤ Pr[E5] + advP (B1).

n Due to Game 4 and Game 5, we have that, to each instance πi ∈ Pi.Instances, there exists a u n u unique instance πj ∈ Pj.Instances such that πi .sid = πj .sid (and conversely). Due to Game 4, m ` v m the intermediary key ck = ik shared by πi and πk is also known to πj (i.e., ik = πi .ck = v n u n u πj .km). Due to Game 5, πi .sid = πj .sid. Hence πi .trscrpt = πj .trscrpt. We dene function oictosa ntegmspromddrn h niyatetcto ro.Therefore proof. same authentication the entity make the we during words, performed other In games the accepts. maliciously in that as instance modications an exists there if random at 1. Game that have we Therefore 5.2.2. Section in 0. Game hops. following the Proof. “directly” to try can below. adversary games the successive Secondly, the key). session their derive protocol the to break Firstly, XS ways. and two ED through by key XS the used and get ED to between try shared can key adversary session the target can adversary protocol 5.2.2. Section in described indistinguishability. Key g key root the g Proofs Security 7.5 adv ( ob h e eiainfnto htotustessinkey session the outputs that function derivation key the be to π nodrt i h e nitnusaiiyeprmn,teavraycns r obreak to try rst can adversary the experiment, indistinguishability key the win to order In that have we 5, Game to 0 Game from probabilities the all Collecting Therefore win. to chance no has adversary the point, that To i Π ent m . - ck auth Let π , P ( E i n A nti ae h hlegraot h xeietadchooses and experiment the aborts challenger the game, this In hsgm orsod otekyidsigihblt euiyeprmn described experiment security indistinguishability key the to corresponds game This ple ewe DadK,o protocol or KS, and ED between applied . i trscrpt Pr[ = ) ik eteeetta h desr isi Game in wins adversary the that event the be P ≤ ≤ ≤ ≤ ≤ = n h esgsecagdbetween exchanged messages the and ple ewe DadX hc ilstessinky hsi eetdby reected is This key. session the yields which XS and ED between applied = ) n n n n n n K K K K K K E π · · · · · · i n n n n n n n 0 Pr[ . ] E E E E E E ck · · · · · · E o ecnie h e nitnusaiiyscrt experiment security indistinguishability key the consider we Now n n n n n n = 0 X X X X X X adv = ] π ik h h h · j u Pr[ Pr[ adv Pr[ Pr[ Pr[ . 0 2 + + + etb St S n rtce ihfunction with protected and XS, to KS by sent ck adv ≤ adv adv E E E E E P key = adv adv 3 2 0 5 4 0 1 + ] + ] - Pr[ + ] + ] ] ind g P ent P ent + ENC sae ( 0 0 1 π ( - - E 2 1 adv adv auth auth adv adv B + j v 5 . ( 0 = km 0 = ] B adv + ) ( ( P ent P ent P key P key B B 2 adv 0 0 0 ) π , - - 0 0 - - i Π ent auth auth ind ind adv ) ) . i i P j Π key u - ( ( . auth 0 ( ( trscrpt B B P ent - B B ple ewe SadX.Te the Then XS. and KS between applied ind 0 0 0 π 1 0 2 + ) 2 + ) - ( i n auth + ) ) ( A A and i ) + ) and , . ) ( adv . B adv adv 0 π 2 + ) 2 1 P ent j u ENC sae ENC sae adv π . 0 hrfr,w aethat have we Therefore, . - i n auth . ( ( ck adv i B B Pr[ = ( 2 2 b B 2 + ) + ) = P ent 0 0 { ∈ ) π - auth adv j E u adv 0 . i ck , ] ( P ent 1 B − P ent } = 1 ENC - auth ) uniformly 2 1 - auth euse We . sk ( B ( ( from ik B 1 183 ) 1 ) is

7 184 Chapter 7 Three-party AKE

Game 2. In this game, the adversary aborts the experiment if it does not guess the party the adversary targets, and its party partners. There are respectively nK , nE, nX parties in the sets K, E and X . Therefore 1 adv2 = adv1 × . nK · nE · nX

Game 3. Now the parties Pk ∈ K, Pj ∈ X and Pi ∈ E are xed. Moreover, the conditions of Denition 5.2 are satised. This means in particular that each instance ending in accepting state is pairwise partnered with a unique instance. In this game, we replace the session key ik output by the 2-AKE run of protocol P between ˜ Pi and Pk with a truly random value ik. The challenger aborts the game if there is an algorithm able to distinguish between both values. We reduce this event to the 2-AKE-security (with respect to key indistinguishability) of P . Therefore, we have that

key-ind adv2 ≤ adv3 + advP (B1) where B1 is an adversary against the 2-AKE-security of P .

Game 4. In this game, we replace the session key output by the 2-AKE run of protocol P 0 between Pk and Pj with a truly random value. The challenger aborts the game if there is an algorithm able to distinguish between both values. We reduce this event to the 2-AKE-security (with respect to key indistinguishability) of P 0. Therefore, we have that

key-ind adv3 ≤ adv4 + advP 0 (B0)

0 where B0 is an adversary against the 2-AKE-security of P .

Game 5. The key (allegedly ik) sent by Pk to Pj is protected with ENC, which is keyed with the session key output by P 0. The adversary can try to get the key ik˜ , and then compute the session key sk shared between Pi and Pj. We reduce this event to the sAE-security of ENC. In turn, this relies implicitly on the fact that the encryption key used to key ENC (and which is output by P 0) be indistinguishable from random. This is the case due to Game 4. Therefore, in this game, the challenger aborts the experiment if the adversary succeeds in getting ik. We have that sae adv4 ≤ adv5 + advENC(B2).

Game 6. Finally, in order to win the experiment, the adversary can try to break the 2-AKE- security (with respect to key indistinguishability) of P executed between Pi and Pj. Therefore we have that key-ind adv5 ≤ adv6 + advP (B1).

To that point, the adversary can do no better than guessing. Therefore

adv6 = 0. hoe 7.2. Theorem update of security of party, where iltm adversary time mial o n XS, any any For For 2.3.1. Section 2, key Chapter master in derivation described [BJS16] key al. long-term et the Brzuska ED, of model same security the the to follows initiator, initiates the ED is where XS here. case the detailed the where not case, consider is We converse and reasoning SAKE-R. The of 7.8). security Figure the (see prove SAKE-R we section, this In SAKE-R 7.5.2 Proofs Security 7.5 adv ihtefloigtermw li htSK- sasecure a is SAKE-R that claim we theorem following the With that have we 6, Game to 0 Game from probabilities the all Collecting H adv adv , Π key B λ n and , SAKE key SAKE ent 1 - h ieo h suorno aus( values pseudo-random the of size the stenme fpris(DadXS), and (ED parties of number the is ind navrayaantteA-euiyof AE-security the against adversary an - - auth ind ( Tag A ltk B - - R R = ) 4 ( ( h rtclSK- sascr -K rtcl n o n rbblsi polyno- probabilistic any for and protocol, 2-AKE secure a is SAKE-R protocol The sde as dened is navrayaanttePFscrt of PRF-security the against adversary an A A ( = ≤ ≤ ≤ ≤ ≤ ≤ ≤ ) ) Tag A ≤ ≤ adv adv adv adv adv adv adv adv nte2AEscrt xeietaantSAKE-R against experiment security 2-AKE the in K ltk . Gen Π ent Π ent 0 Π ent Π ent Π ent Π ent Π ent h uhniainmse key master authentication the , adv nq sde as dened is ------auth auth auth auth auth auth auth h , ltk SAKE ent Tag ( nq +3 - ( ( ( ( ( ( ( auth ( = A A A A A A A . − adv MAC + ) + ) + ) + ) + ) + ) + ) - R ,K K, 1)2 ( Tag suf A n adv n n n n n ltk , + ) − K K K K K K - cma Tag ( 0 ) λ 1 · · · · · · nta ae a case, that In . − ( = n n n n n n nq ( 1) . B E E E E E E Vrf q r 2 ,K K, 2( + h A · · · · · · h aiu ubro ntne ssin)per (sessions) instances of number maximum the + ) 2 n n n n n n , ) +( r , KW X X X X X X B B adv q q q h h h h h · 0 ), 3 k , − adv adv adv adv adv · adv − , +2 +2 + B adv navrayaanttePFscrt of PRF-security the against adversary an KW ae j B 1) adv 0 1) ) KDF ENC sae 6 5 4 3 2 2 hti,a is, That . adv adv navrayaanttePRF-security the against adversary an adv ( K update prf + + + + navrayaantteSUF-CMA- the against adversary an Corrupt B P key adv n h iktecyto key encryption ticket the and , ( 1 P key P key adv adv adv adv . B H prf + ) - ind 2 - - ( ( update prf ind ind + ) B ENC sae ENC sae P key P key B ( adv 0 2-AKE 3 B ( ( 0 qeyreturns -query ) - - B B 2 + ) ind ind 1 i adv ( ( Corrupt ) 1 1 ( B B KDF prf i ) ) ( ( B 2 2 i i B B 3 P key + ) + ) adv 0 1 2 + ) ( 0 rtclwt respect with protocol + ) ) B - i ind 4 adv adv qeyrtrsthe returns -query KW ae ) ( adv adv B ( P key P key 0 B 0 0 ) P key H prf - - 1 K ind ind ) - ( ind B and ( ( B B 0 ( ) 0 0 B i ) ) K 1 ) 185 i 0 . k j .

7 186 Chapter 7 Three-party AKE

The security proof for SAKE-R follows essentially the same steps as the proof for SAKE (see Chapter 6, Section 6.3). We dene functions H and update to be two PRFs. That is H : y 7→ PRFH(y, x) and 0 0 update : y 7→ PRFupdate(y, x ) for some (constant) values x and x .

Entity authentication. We start with the 2-AKE entity authentication experiment.

ent-auth Proof. Let advSAKE-R(A) be the probability that the adversary wins the entity authentication ent-auth game. Let advSAKE-R,client(A) be the probability that an adversary succeeds against a client ent-auth (ED), and advSAKE-R,server(A) the probability that an adversary succeeds against a server (XS). We have that

ent-auth ent-auth ent-auth advSAKE-R(A) ≤ advSAKE-R,client(A) + advSAKE-R,server(A).

Client adversary. We rst consider an adversary that targets a client. Let Ei be the event that the adversary succeeds in making a client instance accept maliciously in Gameclient i.

Gameclient 0. This game corresponds to the 2-AKE entity authentication security experiment when the adversary targets a client instance. Therefore

ent-auth Pr[E0] = advSAKE-R,client(A).

Gameclient 1. In this game, the challenger aborts the experiment if there exists an instance that chooses a random value rA or rB that is not unique. There is at most n × q random values, each uniformly drawn at random in {0, 1}λ. Hence the two games are equivalent up to a collision nq(nq−1) term 2λ . Therefore nq(nq − 1) Pr[E ] ≤ Pr[E ] + . 0 1 2λ

Gameclient 2. In this game, the challenger aborts the experiment if it does not guess which client instance will be the rst to maliciously accept. There is n parties and q instances per party. Therefore we have that 1 Pr[E ] = Pr[E ] × . 2 1 nq

client Game 3. The rst key k0 used to compute a ticket is uniformly drawn at random. The next encryption key k1 is computed as k1 = H(k0) = PRFH(k0, x). Since k0 is random, we PRF (k , ·) FH can replace H 0 with a truly random function k0 . We do the same for any server instance that uses function H with the same key k0 to compute k1. Distinguishing the change implies an algorithm able to distinguish function H from a random function. This corresponds prf to an advantage advH (B0) where B0 is an adversary against the PRF-security of H. Since PRF (k , ·) FH k = FH (x) H 0 is replaced with a random function k0 , 1 k0 is random. In turn, we can PRF (k , ·) FH replace H 1 with a truly random function k1 . Recursively, we replace each function PRF (k , ·) FH q H i with a truly random function ki . There is at most instances per party, hence at most q−1 updates of the original key k0 before computing a ticket (that is, 0 ≤ i < q). Therefore, prf distinguishing the successive changes corresponds to an advantage at most (q − 1)advH (B0). Consequently, in this game, the challenger aborts the experiment if the adversary is able to distinguish any of these changes. Therefore, we have that

prf Pr[E2] ≤ Pr[E3] + (q − 1)advH (B0). where where where hrfr,w eueti vn oteSFCAscrt fteMCfnto kydwith (keyed function MAC the of SUF-CMA-security the to event this reduce we Therefore, Game Game Game hseett h U-M-euiyo h A ucinue ocompute to used function MAC that the have of SUF-CMA-security the to event this Game to message valid a receives ever a such distinguish to able is adversary the if experiment Hence the aborts change. challenger the game, function this the in distinguish to able algorithm an implies the uses that instance server replace we game, this compute to used Game to Due message valid a receives ever that because possible function key the Game Proofs Security 7.5 ota on,teavrayhsn hnet i.Therefore win. to chance no has adversary the point, that To client client client client B B B ik 3 2 1 client KW sa desr gis h R-euiyof PRF-security the against adversary an is of SUF-CMA-security the against adversary an is of AE-security the against adversary an is 6. from 4. 7. 5. client ,tekyue ocmueteMCtag MAC the compute to used key the 6, hc urnesra-rmrno nitnusaiiyfrtepanet ti is (this plaintexts the for indistinguishability real-from-random guarantees which h e sdt opt h A tag MAC the compute to used key The nti ae h hlegraot h xeieti h desr sal oget to able is adversary the if experiment the aborts challenger the game, this In nti ae h hlegraot h xeieti h agtdinstance targeted the if experiment the aborts challenger the game, this In instance targeted the if experiment the aborts challenger the game, this In ticket m k 4, i B sidsigihbefo admdet Game to due random from indistinguishable is ik hrfr,w aethat have we Therefore, . PRF = = K KW update k update τ K Pr[ Pr[ B Pr[ ( 0 m k Pr[ ( 0 u oisac atee with partnered instance no but K B i (hence E E ik , E E u oisac atee with partnered instance no but 6 0 4 , 5 ] ] ucinwt h aekey same the with function ] · 3 ) ≤ ) ≤ ] , ≤ iharno function random a with 0 ≤ Pr[ Pr[ K Pr[ ≤ Pr[ Pr[ 0 E a esfl elcdwt rl admvalue. random truly a with replaced safely be can ) E q < i E E E 7 5 6 + ] + ] 7 + ] 4 0 = ] + ] erdc hseett the to event this reduce We . adv adv adv adv update . KW τ Tag suf Tag suf update update prf B 0 KW ae τ - - is cma cma B 0 . update ( stuyrno.Hne ereduce we Hence, random. truly is B ( ( rmarno ucin Therefore, function. random a from ( Tag B B B 1 . ) 3 2 2 ) F ) π ) . . K K update a uptta esg.Due message. that output has ( 0 K 0 itnusigtechange the Distinguishing . π client 0 = ) a uptta message. that output has ed h aefrany for same the do We . ) hrfr ehave we Therefore 3). PRF τ B 0 update hrfr,we Therefore, . AE scrt of -security ( K 0 x , 0 ) K 187 In . π π 0 )

7 188 Chapter 7 Three-party AKE

Collecting all the probabilities from Gameclient 0 to Gameclient 7, we have that ent-auth advSAKE-R,client(A) = Pr[E0] nq(nq − 1) ≤ + Pr[E ] 2λ 1 nq(nq − 1) ≤ + nq × Pr[E ] 2λ 2 nq(nq − 1) h i ≤ + nq Pr[E ] + (q − 1)advprf (B ) 2λ 3 H 0 nq(nq − 1) h i ≤ + nq Pr[E ] + advae (B ) + (q − 1)advprf (B ) 2λ 4 KW 1 H 0 nq(nq − 1) ≤ + nq Pr[E ] + advsuf-cma(B ) + advae (B ) 2λ 5 Tag 2 KW 1 prf i +(q − 1)advH (B0) nq(nq − 1) h ≤ + nq Pr[E ] + advprf (B ) + advsuf-cma(B ) 2λ 6 update 3 Tag 2 ae prf i +advKW(B1) + (q − 1)advH (B0) nq(nq − 1) h ≤ + nq Pr[E ] + advprf (B ) + 2advsuf-cma(B ) 2λ 7 update 3 Tag 2 ae prf i +advKW(B1) + (q − 1)advH (B0) nq(nq − 1) h ≤ + nq advprf (B ) + 2advsuf-cma(B ) + advae (B ) 2λ update 3 Tag 2 KW 1 prf i +(q − 1)advH (B0)

h −λ prf suf-cma ae ≤ nq (nq − 1)2 + advupdate(B3) + 2advTag (B2) + advKW(B1)

prf i +(q − 1)advH (B0)

Server adversary. Now we consider an adversary that targets a server. Let Ei be the event that the adversary succeeds in making a server instance accept maliciously in Gameserver i.

Gameserver 0. This game corresponds to the 2-AKE entity authentication security experiment when the adversary targets a server instance. Therefore we have that ent-auth Pr[E0] = advSAKE-R,server(A).

Gameserver 1. In this game, the challenger aborts the experiment if there exists an instance that chooses a random value rA or rB that is not unique. There is at most n × q random values, each uniformly drawn at random in {0, 1}λ. Hence the two games are equivalent up to a collision nq(nq−1) term 2λ . Therefore nq(nq − 1) Pr[E ] ≤ Pr[E ] + . 0 1 2λ

Gameserver 2. In this game, the challenger aborts the experiment if it does not guess which server instance will be the rst to maliciously accept. There is n parties and q instances per party. Therefore we have that 1 Pr[E ] = Pr[E ] × . 2 1 nq where ehv that have we hrfr ehv that have we Therefore ai A tag MAC valid Game Game uhafreycnb civdi n ftowy:ete h desr ucesi ogn a compute forging the to in to used succeeds function adversary MAC the the either of ways: SUF-CMA-security two of one in achieved be can forgery a Such message valid a receives ever that have we Therefore, changes. these of any distinguishing in succeeds adversary the most 0 most at hence PRF PRF function random a with advantage function replaced an the to distinguish corresponds to This able function function. algorithm uses random an that implies instance change client the any tinguishing for same the do with replaced is key Since the run, protocol next the During random. function key the Game function k Game Proofs Security 7.5 i +1 ≤ ota on,teavrayhsn hnet i.Hence win. to chance no has adversary the point, that To q < i update update = ( K q server server server server AE B H 0 − 0 ik 1 KW F ( srno,w a replace can we random, is scrt ffunction of -security ( ( .Teeoe itnusigtescesv hne orsod oa datg at advantage an to corresponds changes successive the distinguishing Therefore, ). sa desr gis h Escrt of AE-security the against adversary an is k k H 1) K K from i 5. 4. 6. i 3. ahcag ilsaloss a yields change Each . = ) adv i 1 0 0 , ti spsil because possible is (this , · q · τ ) ) h rtvleof value rst The nti ae h hlegraot h xeieti h desr sal oget to able is adversary the if experiment the aborts challenger the game, this In nti ae h hlegraot h xeieti h agtdinstance targeted the if experiment the aborts challenger the game, this In nti ae eapytesm hne si Game in as changes same the apply we game, this In A update prf − ticket PRF ihatuyrno function random truly a with ihatuyrno function random truly a with ri estekey the gets it or , 1 pae fteoiia key original the of updates H ( B ( = k 3 i ) x , osqety nti ae h hlegraot h xeietif experiment the aborts challenger the game, this in Consequently, . KW Pr[ Pr[ ) , Pr[ E ( i τ KW E k Pr[ 4 A ≥ ] i E K 2 ik , ≤ F ] u oisac atee with partnered instance no but E 5 0 hc sarayasmddet Game to due assumed already is which , 0 K update ≤ ] PRF erpaerecursively replace we , K ( Pr[ 3 ) 0 0 K ≤ ] , Pr[ k 0 0 ≤ 0 i 0 adv Pr[ are in carried E sdt opt A tag MAC a compute to used ) , update sidsigihbefo admdet Game to due random from indistinguishable is ≤ Pr[ E Pr[ 5 K ( + ] H prf E 3 q < i 1 0 ( + ] E E 6 ( = ( + ] 6 B 4 K 0 = ] q F + ] F 0 F q 0 K update ) erdc hseett the to event this reduce We . − 0 K update K K update adv , hrfr,w aethat have we Therefore, . ticket i − 0 1 0 · 0 0 0 adv 0 1) ) . KW eoecmuigaMCtag MAC a computing before 1) Tag suf ihatuyrno function random truly a with adv adv hr sa most at is There . eusvl,w elc ahfunction each replace we Recursively, . ( KW ae adv - x cma erdc h rtpsiiiyt the to possibility rst the reduce We . . 0 update update prf τ ) update prf ( A H prf B ( srno.I un ecnreplace can we turn, In random. is erdc h eodpossibility second the reduce We . B 1 update PRF ( ) 2 B ( ) ( B 0 . B ) ihtesm key same the with 3 H 3 . ) ) π ( . Since . k ( K a uptta message. that output has i τ , A 0 · 0 ) = ) client suiomycoe at chosen uniformly is q ihatuyrandom truly a with ntne e party, per instances PRF PRF server .Ta s since is, That 3. AE update update update .Therefore, 4. scrt of -security F τ K update A ( K 0 K ( 0 ta is, (that K server rma from 0 0 0 0 Dis- . , 0 0 We . x , · 189 ) 3). is 0 π ) .

7 190 Chapter 7 Three-party AKE

Collecting all the probabilities from Gameserver 0 to Gameserver 6, we have that

ent-auth advSAKE-R,server(A) = Pr[E0] nq(nq − 1) ≤ + Pr[E ] 2λ 1 nq(nq − 1) ≤ + nq × Pr[E ] 2λ 2 nq(nq − 1) h i ≤ + nq Pr[E ] + (q − 1)advprf (B ) 2λ 3 H 0 nq(nq − 1) h i ≤ + nq Pr[E ] + advae (B ) + (q − 1)advprf (B ) 2λ 4 KW 1 H 0 nq(nq − 1) h ≤ + nq Pr[E ] + (q − 1)advprf (B ) + advae (B ) 2λ 5 update 3 KW 1 prf i +(q − 1)advH (B0) nq(nq − 1) ≤ + nq Pr[E ] + advsuf-cma(B ) 2λ 6 Tag 2 prf ae +(q − 1)advupdate(B3) + advKW(B1) prf i +(q − 1)advH (B0)

h −λ suf-cma prf ≤ nq (nq − 1)2 + advTag (B2) + (q − 1)advupdate(B3)

ae prf i +advKW(B1) + (q − 1)advH (B0)

Finally, we have that

ent-auth ent-auth ent-auth advSAKE-R(A) ≤ advSAKE-R,client(A) + advSAKE-R,server(A) h −(λ−1) prf ae ≤ nq (nq − 1)2 + 2(q − 1)advH (B0) + 2advKW(B1)

suf-cma prf i +3advTag (B2) + q · advupdate(B3)

Key indistinguishability. Now we consider the 2-AKE key indistinguishability security experiment.

Proof. Let Ei be the event that the adversary succeeds in making an instance accept maliciously 1 in Game i, and advi = Pr[Ei] − 2 .

Game 0. This game corresponds to the 2-AKE key indistinguishability security experiment. Therefore we have 1 1 Pr[E ] = + advkey-ind (A) = + adv . 0 2 SAKE-R 2 0

Game 1. In this game, the challenger aborts the experiment and chooses b ∈ {0, 1} uniformly at random if there exists an instance that accepts maliciously. Therefore we have

ent-auth adv0 ≤ adv1 + advSAKE-R. where with keyed when that have we that have we hrfr ehv that have we Therefore Game etrta usig Hence guessing. than better that have we Therefore, change. the distinguishing in succeeds adversary Game to due random from that fact the use (we function getting in Game PRF since is, That experiment. tication advantage an to respectively corresponding stance, 3. Game that have we Therefore, targets. adversary the 2. Game Proofs Security 7.5 Game olcigtepoaiiisfo Game from probabilities the Collecting point, that To o ecnie h aeweeteavraytresasre instance. server a targets adversary the where case the consider we Now case. rst the with begin We H adv ( client client client B k i 4 SAKE key , · sa desr gis h R-euiyof PRF-security the against adversary an is K ) 5. 3. - 4. nti ae h hlegraot h xeieti tde o us hc instance which guess not does it if experiment the aborts challenger the game, this In edsigihtocss h desr agt ihracin ntneo evrin- server a or instance client a either targets adversary the cases: two distinguish We ind ihatuyrno function random truly a with from - R, nti ae erpaethe replace we game, this In nti ae eapytesm hne si Game in as changes same the apply we game, this In nti ae h hlegraot h xeieti h desr succeeds adversary the if experiment the aborts challenger the game, this In client sk K ticket iharno function random a with , = ( adv adv A F ) K KDF SAKE key 2 = ≤ ≤ ≤ ≤ ≤ - client ind ( k f KW adv i ( - adv adv R, eidsigihbefo admdet Game to due random from indistinguishable be r adv adv adv adv .Cneunl,tecalne brsteeprmn fthe if experiment the aborts challenger the Consequently, 4. A client ( SAKE key r , 4 client 3 client k 5 client KDF prf 4 client 3 client k i - B ik , ind i ( +1 adv )) A ( - ≤ ≤ R, ) B + + ( + ) = sarno au.Teeoeteavraycnd no do can adversary the Therefore value. random a is erdc hseett the to event this reduce We . adv 2 client 4 adv adv ≤ client adv adv F + ) H = q k H adv KDF 5 client ( i − 5 client 4 client F ( k ahcag ilsaloss a yields change Each . adv KDF prf KW ae adv A K KDF oGame to 3 i 1) = ) 3 client + ) ( 1 0 = ( adv + + ucinue ocmuetessinkey session the compute to used function B KW ae adv euetefc that fact the use We . B × 1 PRF 4 adv adv adv ( + ( + ) ( + ) . H prf nq SAKE key KDF B 1 ( 1 KDF prf KW ae key SAKE q - H . B ( + ) ind client adv q ( − 0 - k . ( ind ) − - ( R, i B 1) B x , KW ae - q 1 ,w aethat have we 5, 1) client R, 4 adv ) ) ) − . ( adv server , B i 1) ( H prf 1 ≥ A ( + ) H prf client adv ( ( ) B 0 A ( and erpaerecursively replace we , B 0 AE ) H prf K ) . q 0 fteett authen- entity the of 3 adv . ) ( scrt fthe of -security − adv eindistinguishable be B H prf 0 1) client ) SAKE key ( adv B - ind 0 ) Therefore 3). ) H prf Therefore, . - R, ( B server 0 ) ( KW 191 A sk ) .

7 192 Chapter 7 Three-party AKE

server Game 3. The rst value of K (K0) used to compute the session key is uniformly chosen at 0 random. During the next protocol run, the key is replaced with update(K0) = PRFupdate(K0, x ). K PRF (K , ·) Fupdate Since 0 is random, we can replace update 0 with a truly random function K0 . We do the same for any client instance that uses update function with the same key K0. Dis- tinguishing the change implies an algorithm able to distinguish the function update from a prf random function. This corresponds to an advantage advupdate(B3). Since PRFupdate(K0, ·) is Fupdate K = Fupdate(x0) replaced with a random function K0 , 1 K0 is random. In turn, we can replace PRF (K , ·) Fupdate update 1 with a truly random function K1 . Recursively, we replace each function PRF (K , ·) Fupdate q update i with a truly random function Ki . There is at most instances per party, hence at most q − 1 updates of the original key K0 before computing a session key (that is, 0 ≤ i < q). Therefore, distinguishing the successive changes corresponds to an advantage at prf most (q − 1)advupdate(B3). Consequently, in this game, the challenger aborts the experiment if the adversary succeeds in distinguishing any of these changes. Therefore, we have that

key-ind server prf advSAKE-R,server(A) ≤ adv3 + (q − 1)advupdate(B3).

Gameserver 4. In this game, we apply the same changes as in Gameclient 3 of the entity authentication experiment. That is, since ki+1 = H(ki) = PRFH(ki, x), i ≥ 0, we replace recursively PRF (k , ·) FH advprf (B ) H i with a truly random function ki . Each change yields a loss H 0 . Therefore, we have that server server prf adv3 ≤ adv4 + (q − 1)advH (B0).

Gameserver 5. In this game, the challenger aborts the experiment if the adversary succeeds in getting K from ticket = KW(ki, ik). We reduce this event to the AE-security of the KW server function (we use the fact that ki be indistinguishable from random due to Game 4). Therefore we have that server server ae adv4 ≤ adv5 + advKW(B1).

Gameclient 6. In this game, we replace the KDF function used to compute the session key sk KDF when keyed with K, with a random function FK . We use the fact that K be indistinguishable from random due to Gameserver 3 and Gameserver 5. Consequently, the challenger aborts the experiment if the adversary succeeds in distinguishing the change. Therefore, we have that

server server prf adv5 ≤ adv6 + advKDF(B4). KDF To that point, sk = FK (f(rA, rB)) is a random value. Therefore the adversary can do no better than guessing. Hence server adv6 = 0. Collecting the probabilities from Gameserver 3 to Gameserver 6, we have that

key-ind server prf advSAKE-R,server(A) ≤ adv3 + (q − 1)advupdate(B3) server prf prf ≤ adv4 + (q − 1)advH (B0) + (q − 1)advupdate(B3) server ae prf prf ≤ adv5 + advKW(B1) + (q − 1)advH (B0) + (q − 1)advupdate(B3) server prf ae prf ≤ adv6 + advKDF(B4) + advKW(B1) + (q − 1)advH (B0) prf +(q − 1)advupdate(B3) prf ae prf ≤ advKDF(B4) + advKW(B1) + (q − 1)advH (B0) prf +(q − 1)advupdate(B3) o o-eoreE)i -K-euepooo codn oDiin5.4. Denition to according protocol 3-AKE-secure a is ED) low-resource for we Hence sides). both of at sAE-security independently of the maintained non-replayability assume being guaranteeing number at sequence aims (the a records number 1.3, the sequence TLS a in from addition, derived In nonce per-record indistinguishability). (real-from-random implies [Shr04] which Shrimpton bits) of random sense from (indistinguishability [Rog02] also Rogaway version of nal the that assume reasonably may we protocol, the 2-AKE-security. of guarantees draft earlier an to applies key key encryption ticket the get to rootk component key Moreover long-term the secrecy). forward captures (which 2-AKE model security that [BJS16] proved al. have we 6 Chapter In Security 3-AKE Achieving 7.5.3 Proofs Security 7.5 ec,fo hoe .,orisatain(ihadwtottessinrsmto scheme resumption session the without and (with instantiation our 7.1, Theorem from Hence, ENC P that have we probabilities, the all collecting Finally, adv K 0 ( = = scr rtclfo hoe ..Wt epc othe to respect With 7.2. Theorem from protocol -secure SAKE key n h uhniainmse key master authentication the and enda h eodlyro L . spoe obe to proved is 1.3 TLS of layer record the as dened - L 1.3 TLS ind ,K K, - R ( A 0 k , = ) spoe ob secure a be to proved is j ) ≤ ≤ ≤ ≤ if P adv adv adv adv adv = SAKE-R ENC SAKE ent 0 SAKE ent SAKE ent SAKE ent - - - - auth auth auth auth k rootk j . - - - - hog a through R R R R ( ( ( ( P hti,i h atrcs,w lo the allow we case, latter the in is, That . A A A A fayE obe to ED any of + ) + ) + ) + ) = SAKE K adv nq nq nq 2-AKE Corrupt 0 . h h · 1 adv ( adv +2 q sasecure a is − SAKE key 2 rtcl[FS6.Atog hsresult this Although [DFGS16]. protocol qey nadto otedrvto master derivation the to addition in -query, 1) adv - ind KW ae rootk - adv R, client ( update prf 2-AKE B AE 1 3-AKE + ) ( = ( scr BM1]i h sense the in [BMM+15] -secure A ( + ) B adv ,K K, rtcli h ruk et Brzuska the in protocol 3 2 + ) euiymdl edene we model, security adv KDF prf 0 ) SAKE key ( adv if B P AE - ind 4 P 3-AKE ) H prf i = scrt nthe in -security - R, ( = B server SAKE-R 0 SAKE ) adversary ( A ) and , i sa is 193

hc edrte nutbet eipeetdo eycntanddvcs vrl,most Overall, devices. constrained very on implemented be to unsuitable them render which hti,dvcswt o eore ihrsett optto,cmuiain n nryin energy and communication, computation, to respect with resources low with devices is, That eto u nweg,ti stes ucsflatc gis C0.Gvnta ilossmart billions that Given SCP02. against attack successful rst the is this knowledge, experi- our an of in best attacked, To successfully tunnel. have we secure setting, aw, the mental this in of transmitted exploitability data practical key, the corresponding illustrate the without decrypt, to device). to need constrained allows not the does particular she (in but equipment target), on any her act to with to access interact only physical and needs a data attacker a get on the as eavesdrop scenario, such (to attack interface module the air resistant of the tamper one a in using Furthermore, (e.g., the from parameters Element). secret independent Secure any the is against protect attacks successful to the be used of to means success likely The not are 1.0. and do LoRaWAN bugs, aws, implementing hardware protocol equipment or the implementation to potential due on attacks, lean aforementioned The 1.0. LoRaWAN against ability practical likely to lead highlighted have protocol. we and either (LoRaWAN), weaknesses against networks The LPWAN attacks (SCP02). in industry deployed card widely smart both the are by They 4). (Chapter SCP02 and protocols. of Cryptanalysis of have ones. we terms existing Finally, (in to respect end. properties with the enhanced security) in feature and goal that eciency our protocols were establishment which key constructions necessary several the tools proposed of methodological the security otherwise the security devised assess deployed and to widely collected two have We of we 1). analysis Then, (Chapter the protocols. eciency by for assessment security this trade illustrated (concretely) devices have constrained for protocols schemes current asymmetric the of of strong use providing make in protocols lack Other secrecy. and forward functions, as symmetric-key such on properties security based are deployed or proposed devices. constrained for tunnel particular. secure a establishing of issue the addressed have we thesis this In Results the of Summary 8.1 perspectives. further open and results these summarise we sion, W ehv lopeetdhwt pl adn rceatc gis C0.Ti attack This SCP02. against attack oracle padding a apply to how presented also have We avail- network the and condentiality, data integrity, data break to how described have We either protocols current the of most that observed have we approach, our of beginning the At im ntesmerckystigbtentoadtrepris nti conclu- this In parties. three and two mecha- between establishment setting key symmetric-key in the nally in and nisms models, security in secondly protocols, results new presented have e 10 ieetmdl fsatcr rdcdb i admnfcues othe To manufacturers. card six by produced card smart of models dierent ehv nlsdtosc rtcl:LRWN(hpe 3) (Chapter LoRaWAN protocols: such two analysed have We ntrels rtyi rpaayi fsecurity of cryptanalysis in rstly elds: three in Conclusion 8

8 196 Chapter 8 Conclusion cards are produced every year, the number of aected items, although dicult to estimate, is potentially high. We have proposed practical recommendations aiming at thwarting, when possible, the attacks, and reported our ndings to each consortium in charge of the development and the promotion of LoRaWAN and SCP02 respectively. LoRa Alliance has published a document aiming at strengthening the current version 1.0, and changes have been incorporated in the specication of version 1.1. Regarding SCP02, our results have contributed in the decision by GlobalPlatform to deprecate the protocol.

Security models. Considering the several vulnerabilities that impair these two real-life protocols, and in view of proposing ecient and secure key establishment protocols, we have devised two security models (Chapter 5). They capture the security properties that protocols must guarantee according to us, and incorporate the interleaved operations between the diverse components of an IoT network. We have applied one of these to a slightly modied version of LoRaWAN 1.1, and proved that, with a suitable choice of parameters and deployment, this modied version is secure in our model.

Forward secret symmetric-key protocols. Finally, we have presented two key establishment protocols for constrained devices. This rst one, called SAKE, is solely built on symmetric- key functions (Chapter 6). Based on a shrewd synchronisation mechanism and a key evolving scheme, it guarantees forward secrecy. 3-AKE is a three-party protocol dedicated to IoT (Chapter 7). Also based on symmetric-key functions (regarding the computations done between the end-device and the back-end network), it guarantees forward secrecy, in contrast to widely deployed symmetric-key based IoT protocols. It also enables session resumption without impairing security (in particular, forward secrecy is maintained). This allows saving communication and computation cost which is advantageous for low-resource devices. This 3-party key exchange protocol can be applied in a real-case IoT deployment (i.e., involving numerous end-devices and servers) such that the latter inherits from the security properties of the protocol.

8.2 Perspectives and Open Problems

Further investigations. The SAKE (resp. SAKE-AM) protocol described in Chapter 6 requires ve (resp. four) rounds, which can be reduced to four (resp. three) rounds if the two parties are synchronised with respect to their master keys evolution when a session starts. Each message of the protocol fullls a specic task: party authentication, detecting desynchronisation, and then catching up. This eventually results in the forward secrecy property being ensured. Removing one message yields an attack, as shown by any of the numerous alternative versions we have analysed. Therefore, we do think that the gure of ve rounds is the least achievable. Yet we do not formally prove it. This question of optimality deserves further investigation to conclude regarding the minimum number of rounds. The 3-AKE security model presented in Chapter 5 (in order to analyse the three-party key establishment protocol described in Chapter 7) is based on the paradigm of indistinguishability of the session keys. In a protocol run, the computation of the “nal” session key implies the involvement of “intermediary” session keys in several operations. This contradicts the possibility to prove the security of the protocol based on indistinguishability of the keys. In order to overcome this issue, we chose to limit the moments when the adversary can test a session key. A more suitable model remains to be devised (perhaps based on – variants of – the as n hr r usin eadn h eeac ftesproiinbsdquantum superposition-based the of relevance the regarding questions are there and ways, smerc rtcl icuigtoedsrbdi hstei)i unu etn,and setting, quantum a in thesis) this in described those (including protocols (symmetric) eysotprmtr ( parameters short very rtcli upsdt eaewe ti o sdi da repce conditions. expected or ideal in used not way is the it the to when how regard behave seen with to have question We supposed generic behaviour. is more expected protocol a this a Yet, raises from This lifespan. deviate whole (badly). to its resists device in protocol a LoRaWAN execute compel small to to the supposed possible by is is choice device LoRaWAN it this a justify exchanges designers key protocol of instance, The For number peculiarity. this specicities. leverage their 3 to Chapter rather is in but This used, them. and break deployed trivially are almost they way to the possibility to the due is not protocols IoT existing several in protocol. ments) security a of Survivability attention. analysing deserve models functions, security symmetric suitable devising classic consequently of generally, security More quantum specics. exact technical protocol’s the the study of feasibility to advantage the take continuing investigate to can adversary one quantum protocol, a a for constitutes that functions the targeting Beyond states). of granted superposition only quantum is a computing) in quantum not a to (i.e., propose access queries and also classical issue, has (which this overcoming adversary in the where succeed many trade-o [BHN+19] in results one some Yet, classic the [Gag17]. key from security secret diers a setting as quantum puzzling (such The parameter the primitive. secret through attacked a revealed the discloses of be turn, tweak) can be in or that can This, shift) functions mechanics. hidden primitives quantum a these of (e.g., magic On structure model. inner quantum an a with in built broken be can model adversarial [KLLN16a; primitives some against emerge vulnerable threats less But KLLN16b]. seem CNS17; far. functions so symmetric computing the common quantum most broken, the against all If are up. opens schemes variants era asymmetric new post-quantum a classical described Now have functions. we symmetric-key stronger on Consequently, with built and solely protocols. devices, existing constrained than on ecient properties time security same the at protocols establishment key cryptography. Post-quantum remains and results, mixed to lead work of line continued. to this be corresponding far, to ciphertext So the [CK05]. to key) key the another with specic translates encryption a function under a encryption such notion from primitive, the resulting symmetric-key with or ciphertext a PN18] from [Par15; (built scheme have function” DH “conversion path the of this of on generalisations steps algebraic Some through latter. done been the replace advantageously would scheme setting. Die-Hellman symmetric-key the in secrecy of Forward eciency the show concretely to concept of proof benecial a protocols. be both would SAKE) for tag RFID a indistinguishability issue on to allowed dened still be be adversary protocol the the and or of keys, [BFS+13], of security al. the et that Brzuska such [BFWW11], [Kra16]), Williams Krawczyk and Warinschi Fischlin, Brzuska, of models Problems Open and Perspectives 8.2 htw elwt eei o niserltdto related issue an not is here with deal we What protocols. to extended be can and ongoing is primitives symmetric-key on work of line This classic a in secure are which functions) MAC or encryption (e.g., primitives Symmetric-key passive a (e.g., devices constrained in protocols 3-AKE and SAKE the implementing Finally, 2 and 3 bt og r sdi oaA ..Teatcsw present we attacks The 1.0. LoRaWAN in used are long) -byte n forgaswst vroetecalneo devising of challenge the overcome to was goals our of One htmylo upiig(mns te assess- other (amongst surprising look may What Test qeya n moment. any at -query resilience idn ymti qiaeto the of equivalent symmetric a Finding hc a ede sthe as dened be may which 197

8 198 Chapter 8 Conclusion ability of a system under attack or in the presence of faults to recover all its capabilities from a degraded state to its nominal state [CMH+07]. The notion we are considering is not to be confused either with how much a protocol may withstand and maintain its nominal functionalities in the presence of faults or when facing attacks, which is related to performability [Mey80; Mey92]. Rather, our issue is related to the notion of survivability [KSS03; SKH+02]. Intuitively one would expect that the essential of the security properties be preserved, which leads to the problem of dening what is essential in security. This depends certainly on the intended goals of the protocol. The question of a survivable security protocol deserves further investigation. Regarding an environment where devices become pervasive, with no easy way to update the algorithms they implement, and physically liable to attacks, this issue is of particular concern. Bibliography

[3rda] 3rd Generation Partnership Project. Technical Specications 33. url: http:// www.3gpp.org/DynaReport/33-series.htm (cit. on pp. 20, 25, 140). [3rdb] 3rd Generation Partnership Project. Technical Specications 35. url: http:// www.3gpp.org/DynaReport/35-series.htm (cit. on pp. 20, 25, 140). [AB00] Michel Abdalla and Mihir Bellare. Increasing the Lifetime of a Key: a Comparative Analysis of the Security of Re-keying Techniques. In: ASIACRYPT 2000. Ed. by Tatsuaki Okamoto. Vol. 1976. LNCS. Springer, Heidelberg, Dec. 2000, pp. 546–559 (cit. on pp. 142, 143). [ABD+15] David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella-Béguelin, and Paul Zimmermann. Imperfect Forward Secrecy: How Die-Hellman Fails in Practice. In: ACM CCS 2015. Ed. by Indrajit Ray, Ninghui Li, and Christopher Kruegel. ACM Press, Oct. 2015, pp. 5–17 (cit. on p. 159). [ABF+19] Ghada Arfaoui, Xavier Bultel, Pierre-Alain Fouque, Adina Nedelcu, and Cristina Onete. The privacy of the TLS 1.3 protocol. Cryptology ePrint Archive, Report 2019/749. 2019. url: https://eprint.iacr.org/2019/749 (cit. on p. 25). [Acc15] Accenture. Winning with the Industrial Internet of Things – How to accelerate the journey to productivity and growth. 2015. url: https://www.accenture. com/t00010101T000000Z__w__/it- it/_acnmedia/PDF- 5/Accenture- Industrial-Internet-of-Things-Positioning-Paper-Report-2015. pdf (cit. on p. 165). [ACD19] Joël Alwen, Sandro Coretti, and Yevgeniy Dodis. The Double Ratchet: Security Notions, Proofs, and Modularization for the Signal Protocol. In: EUROCRYPT 2019, Part I. Ed. by Yuval Ishai and Vincent Rijmen. Vol. 11476. LNCS. Springer, Hei- delberg, May 2019, pp. 129–158 (cit. on p. 142). [ACF19] Gildas Avoine, Sébastien Canard, and Loïc Ferreira. IoT-Friendly AKE: Forward Se- crecy and Session Resumption Meet Symmetric-Key Cryptography. In: ESORICS 2019, Part II. Ed. by Kazue Sako, Steve Schneider, and Peter Y. A. Ryan. Vol. 11736. LNCS. Springer, Heidelberg, Sept. 2019, pp. 463–483 (cit. on pp. vii, viii, 27, 28, 99, 163). [ACF20] G. Avoine, S. Canard, and L. Ferreira. Symmetric-key Authenticated Key Exchange (SAKE) with Perfect Forward Secrecy. In: CT-RSA. (To appear). 2020 (cit. on pp. viii, 28, 139). 200 Bibliography

[AF18a] Gildas Avoine and Loïc Ferreira. “Attacking GlobalPlatform SCP02-compliant Smart Cards Using a Padding Oracle Attack”. In: IACR TCHES 2018.2 (2018). https : / / tches . iacr . org / index . php / TCHES / article / view / 878, pp. 149–170. issn: 2569-2925 (cit. on pp. vi, 26, 27, 81). [AF18b] Gildas Avoine and Loïc Ferreira. Rescuing LoRaWAN 1.0. In: FC 2018. Ed. by Sarah Meiklejohn and Kazue Sako. Vol. 10957. LNCS. Springer, Heidelberg, 2018, pp. 253–271 (cit. on pp. vi, 26, 27, 43, 73). [AFM+16] Stéphanie Alt, Pierre-Alain Fouque, Gilles Macario-Rat, Cristina Onete, and Benjamin Richard. A Cryptographic Analysis of UMTS/LTE AKA. In: ACNS 16. Ed. by Mark Manulis, Ahmad-Reza Sadeghi, and Steve Schneider. Vol. 9696. LNCS. Springer, Heidelberg, June 2016, pp. 18–35 (cit. on pp. 22, 23, 25, 100). [AGJ19] Nimrod Aviram, Kai Gellert, and Tibor Jager. Session Resumption Protocols and Ecient Forward Security for TLS 1.3 0-RTT. In: EUROCRYPT 2019, Part II. Ed. by Yuval Ishai and Vincent Rijmen. Vol. 11477. LNCS. Springer, Heidelberg, May 2019, pp. 117–150 (cit. on pp. 173, 175). [AIES15] Gorka Irazoqui Apecechea, Mehmet Sinan Inci, Thomas Eisenbarth, and Berk Sunar. Lucky 13 Strikes Back. In: ASIACCS 15. Ed. by Feng Bao, Steven Miller, Jianying Zhou, and Gail-Joon Ahn. ACM Press, Apr. 2015, pp. 85–96 (cit. on p. 61). [Ant17] Sebastian Anthony. USB Killer now lets you fry most Lightning and USB-C devices for $55. Ars Technica. 2017. url: https://arstechnica.com/gadgets/2017/ 02/usb-killer-fry-lightning-usb-c-devices/ (cit. on p. 53). [AP13] Nadhem J. AlFardan and Kenneth G. Paterson. Lucky Thirteen: Breaking the TLS and DTLS Record Protocols. In: 2013 IEEE Symposium on Security and Privacy. IEEE Computer Society Press, May 2013, pp. 526–540 (cit. on pp. 61, 96). [AP16] Martin R. Albrecht and Kenneth G. Paterson. Lucky Microseconds: A Timing Attack on Amazon’s s2n Implementation of TLS. In: EUROCRYPT 2016, Part I. Ed. by Marc Fischlin and Jean-Sébastien Coron. Vol. 9665. LNCS. Springer, Heidelberg, May 2016, pp. 622–643 (cit. on p. 92). [ASS09] Zahra Ahmadian, Somayeh Salimi, and Ahmad Salahi. New attacks on UMTS network access. In: 2009 Wireless Telecommunications Symposium. 2009, pp. 1–6 (cit. on pp. 23, 25). [Atm11] Atmel. 8-bit Atmel Microcontroller with 128KBytes In-System Programmable Flash. 2011. url: http : / / ww1 . microchip . com / downloads / en / DeviceDoc / doc2467.pdf (cit. on pp. 6, 7). [Atm14] Atmel. Atmel ATmega640/V-1280/V-1281/V-2560/V-2561/V. 2014. url: https:// ww1.microchip.com/downloads/en/devicedoc/atmel- 2549- 8- bit- avr-microcontroller-atmega640-1280-1281-2560-2561_datasheet. pdf (cit. on p. 6). [AVTP+17] Ferran Adelantado, Xavier Vilajosana, Pere Tuset-Peiro, Borja Martinez, Joan Melià-Seguí, and Thomas Watteyne. “Understanding the Limits of LoRaWAN”. In: IEEE Communications Magazine 55.9 (2017), pp. 34–40 (cit. on p. 76). Bibliography 201

[AZM10] Aslan Askarov, Danfeng Zhang, and Andrew C. Myers. Predictive black-box mitigation of timing channels. In: ACM CCS 2010. Ed. by Ehab Al-Shaer, Angelos D. Keromytis, and Vitaly Shmatikov. ACM Press, Oct. 2010, pp. 297–307 (cit. on p. 96). [Ame09] American National Standards Institute. ANSI X9.24-1:2009 Retail Financial Ser- vices Symmetric Key Management Part 1: Using Symmetric Techniques. 2009 (cit. on p. 141). [BBD+18] Karthikeyan Bhargavan, Ioana Boureanu, Antoine Delignat-Lavaud, Pierre-Alain Fouque, and Cristina Onete. A Formal Treatment of Accountable Proxying Over TLS. In: 2018 IEEE Symposium on Security and Privacy. IEEE Computer Society Press, May 2018, pp. 799–816 (cit. on pp. 101, 112). [BBF+17] Karthikeyan Bhargavan, Ioana Boureanu, Pierre-Alain Fouque, Cristina Onete, and Benjamin Richard. Content delivery over TLS: a cryptographic analysis of keyless SSL. In: 2017 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 2017, pp. 1–16 (cit. on pp. 100, 101, 106, 109, 111). [BBK03] Elad Barkan, Eli Biham, and Nathan Keller. Instant Ciphertext-Only Cryptanalysis of GSM Encrypted Communication. In: CRYPTO 2003. Ed. by Dan Boneh. Vol. 2729. LNCS. Springer, Heidelberg, Aug. 2003, pp. 600–616 (cit. on p. 8). [BCJ+06] Michael Backes, Iliano Cervesato, Aaron D. Jaggard, Andre Scedrov, and Joe-Kai Tsay. Cryptographically Sound Security Proofs for Basic and Public-Key Kerberos. In: ESORICS 2006. Ed. by Dieter Gollmann, Jan Meier, and Andrei Sabelfeld. Vol. 4189. LNCS. Springer, Heidelberg, Sept. 2006, pp. 362–383 (cit. on p. 25). [BCK98] Mihir Bellare, Ran Canetti, and Hugo Krawczyk. A Modular Approach to the Design and Analysis of Authentication and Key Exchange Protocols (Extended Ab- stract). In: 30th ACM STOC. ACM Press, May 1998, pp. 419–428 (cit. on p. 11). [BDJR97] Mihir Bellare, Anand Desai, Eric Jokipii, and Phillip Rogaway. A Concrete Security Treatment of Symmetric Encryption. In: 38th FOCS. IEEE Computer Society Press, Oct. 1997, pp. 394–403 (cit. on pp. 32, 34, 50, 129, 136). [BDL+12] Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. “High-speed high-security signatures”. In: Journal of Cryptographic Engineering 2.2 (Sept. 2012), pp. 77–89 (cit. on p. 6). [Bel98] Mihir Bellare. Practice-Oriented Provable-Security (Invited Lecture). In: ISW’97. Ed. by Eiji Okamoto, George I. Davida, and Masahiro Mambo. Vol. 1396. LNCS. Springer, Heidelberg, Sept. 1998, pp. 221–231 (cit. on p. 50). [Ber05] Daniel J. Bernstein. The Poly1305-AES Message-Authentication Code. In: FSE 2005. Ed. by Henri Gilbert and Helena Handschuh. Vol. 3557. LNCS. Springer, Heidel- berg, Feb. 2005, pp. 32–49 (cit. on p. 7). [Ber06] Daniel J. Bernstein. Curve25519: New Die-Hellman Speed Records. In: PKC 2006. Ed. by Moti Yung, Yevgeniy Dodis, Aggelos Kiayias, and Tal Malkin. Vol. 3958. LNCS. Springer, Heidelberg, Apr. 2006, pp. 207–228 (cit. on p. 7). [Ber08] Daniel J. Bernstein. The Salsa20 Family of Stream Ciphers. In: New Stream Cipher Designs: The eSTREAM Finalists. Ed. by Matthew Robshaw and Olivier Billet. Springer, 2008, pp. 84–97. url: https://doi.org/10.1007/978- 3- 540- 68351-3_8 (cit. on p. 6). 202 Bibliography

[Ber19] Daniel J. Bernstein. CAESAR: Competition for Authenticated Encryption: Security, Applicability, and Robustness. 2019. url: https://competitions.cr.yp.to/ caesar.html (cit. on p. 8). [BFS+13] Christina Brzuska, Marc Fischlin, Nigel P. Smart, Bogdan Warinschi, and Stephen C. Williams. “Less is more: relaxed yet composable security notions for key exchange”. In: International Journal of Information Security 12.4 (2013), pp. 267– 297. url: https://doi.org/10.1007/s10207-013-0192-y (cit. on pp. ix, 102, 197). [BFWW11] Christina Brzuska, Marc Fischlin, Bogdan Warinschi, and Stephen C. Williams. Composability of Bellare-Rogaway key exchange protocols. In: ACM CCS 2011. Ed. by Yan Chen, George Danezis, and Vitaly Shmatikov. ACM Press, Oct. 2011, pp. 51–62 (cit. on pp. ix, 197). [BHN+19] Xavier Bonnetain, Akinori Hosoyamada, María Naya-Plasencia, Yu Sasaki, and André Schrottenloher. Quantum Attacks without Superposition Queries: the Of- ine Simon Algorithm. Cryptology ePrint Archive, Report 2019/614. 2019. url: https://eprint.iacr.org/2019/614 (cit. on p. 197). [Biz15] BiztechAfrica. FastNet announces Africa’s rst dedicated M2M network and IoT developer academy. BiztechAfrica. 2015. url: http://www.biztechafrica. com / article / fastnet - announces - africas - first - dedicated - m2m - netw/10718/ (cit. on p. 45). [BJS16] Christina Brzuska, Håkon Jacobsen, and Douglas Stebila. Safely Exporting Keys from Secure Channels: On the Security of EAP-TLS and TLS Key Exporters. In: EU- ROCRYPT 2016, Part I. Ed. by Marc Fischlin and Jean-Sébastien Coron. Vol. 9665. LNCS. Springer, Heidelberg, May 2016, pp. 670–698 (cit. on pp. 36, 101, 185, 193). [BJST08] Buno Blanchet, Aaron D. Jaggard, Andre Scedrov, and Joe-Kai Tsay. Computa- tionally sound mechanized proofs for basic and public-key Kerberos. In: ASIACCS 08. Ed. by Masayuki Abe and Virgil Gligor. ACM Press, Mar. 2008, pp. 87–99 (cit. on p. 25). [BK07] Alexandra Boldyreva and Virendra Kumar. Provable-Security Analysis of Au- thenticated Encryption in Kerberos. Cryptology ePrint Archive, Report 2007/234. http://eprint.iacr.org/2007/234. 2007 (cit. on p. 25). [BKL+07] Andrey Bogdanov, Lars R. Knudsen, Gregor Leander, Christof Paar, Axel Poschmann, Matthew J. B. Robshaw, Yannick Seurin, and C. Vikkelsoe. PRESENT: An Ultra- Lightweight Block Cipher. In: CHES 2007. Ed. by Pascal Paillier and Ingrid Ver- bauwhede. Vol. 4727. LNCS. Springer, Heidelberg, Sept. 2007, pp. 450–466 (cit. on p. 7). [BKN02] Mihir Bellare, Tadayoshi Kohno, and Chanathip Namprempre. Authenticated Encryption in SSH: Provably Fixing The SSH Binary Packet Protocol. In: ACM CCS 2002. Ed. by Vijayalakshmi Atluri. ACM Press, Nov. 2002, pp. 1–11 (cit. on pp. 32, 100). [BKN04] Mihir Bellare, Tadayoshi Kohno, and Chanathip Namprempre. “Breaking and Provably Repairing the SSH Authenticated Encryption Scheme: A Case Study of the Encode-then-Encrypt-and-MAC Paradigm”. In: ACM Trans. Inf. Syst. Secur. 7.2 (2004), pp. 206–241. url: http://doi.acm.org/10.1145/996943.996945 (cit. on p. 96). Bibliography 203

[Blo70] Burton H. Bloom. “Space/Time Trade-os in Hash Coding with Allowable Errors”. In: Communications of the ACM 13.7 (1970), pp. 422–426. url: http://doi.acm. org/10.1145/362686.362692 (cit. on pp. 63, 73). [BM03a] Colin Boyd and Anish Mathuria. Protocols for Authentication and Key Establish- ment. Information Security and Cryptography. Springer, 2003 (cit. on p. 11). [BM03b] Colin Boyd and Anish Mathuria. Protocols for Authentication and Key Establish- ment. ISC. Springer, Heidelberg, 2003. isbn: 978-3-642-07716-6 (cit. on p. 140). [BM99] Mihir Bellare and Sara K. Miner. A Forward-Secure Digital Signature Scheme. In: CRYPTO’99. Ed. by Michael J. Wiener. Vol. 1666. LNCS. Springer, Heidelberg, Aug. 1999, pp. 431–448 (cit. on p. 142). [BMM+15] Christian Badertscher, Christian Matt, Ueli Maurer, Phillip Rogaway, and Björn Tackmann. Augmented Secure Channels and the Goal of the TLS 1.3 Record Layer. In: ProvSec 2015. Ed. by Man Ho Au and Atsuko Miyaji. Vol. 9451. LNCS. Springer, Heidelberg, Nov. 2015, pp. 85–104 (cit. on p. 193). [BN00] Mihir Bellare and Chanathip Namprempre. Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm. In: ASIACRYPT 2000. Ed. by Tatsuaki Okamoto. Vol. 1976. LNCS. Springer, Heidelberg, Dec. 2000, pp. 531–545 (cit. on p. 136). [BN08] Mihir Bellare and Chanathip Namprempre. “Authenticated Encryption: Relations among Notions and Analysis of the Generic Composition Paradigm”. In: Journal of Cryptology 21.4 (Oct. 2008), pp. 469–491 (cit. on pp. 32, 84, 96). [BP10] Eric Brier and Thomas Peyrin. A Forward-Secure Symmetric-Key Derivation Pro- tocol - How to Improve Classical DUKPT. In: ASIACRYPT 2010. Ed. by Masayuki Abe. Vol. 6477. LNCS. Springer, Heidelberg, Dec. 2010, pp. 250–267 (cit. on pp. 141, 143). [BP17] Alex Biryukov and Leo Perrin. State of the Art in Lightweight Symmetric Cryp- tography. Cryptology ePrint Archive, Report 2017/511. http://eprint.iacr. org/2017/511. 2017 (cit. on p. 8). [BPG18] Ismail Butun, Nuno Pereira, and Mikael Gidlund. “Security Risk Analysis of LoRaWAN and Future Directions”. In: Future Internet 11.1 (2018). url: http: //www.mdpi.com/1999-5903/11/1/3 (cit. on p. 75). [BPR00] Mihir Bellare, David Pointcheval, and Phillip Rogaway. Authenticated Key Ex- change Secure against Dictionary Attacks. In: EUROCRYPT 2000. Ed. by Bart Pre- neel. Vol. 1807. LNCS. Springer, Heidelberg, May 2000, pp. 139–155 (cit. on p. 100). [BR04] Mihir Bellare and Phillip Rogaway. Code-Based Game-Playing Proofs and the Security of Triple Encryption. Cryptology ePrint Archive, Report 2004/331. http: //eprint.iacr.org/2004/331. 2004 (cit. on pp. 119, 153, 181). [BR94] Mihir Bellare and Phillip Rogaway. Entity Authentication and Key Distribution. In: CRYPTO’93. Ed. by Douglas R. Stinson. Vol. 773. LNCS. Springer, Heidelberg, Aug. 1994, pp. 232–249 (cit. on pp. 11, 12, 25, 32, 100, 140). [Bri16] Ken Briodagh. Japan Opens New LoRaWAN Network for IoT Testing. IoT Evolution World. 2016. url: http://www.iotevolutionworld.com/iot/articles/ 423324-japan-opens-new-lorawan-network-iot-testing.htm (cit. on p. 45). 204 Bibliography

[BRS+15] Benjamin Buhrow, Paul Riemer, Mike Shea, Barry K. Gilbert, and Erik S. Daniel. Block Cipher Speed and Energy Eciency Records on the MSP430: System Design Trade-Os for 16-Bit Embedded Applications. In: LATINCRYPT 2014. Ed. by Diego F. Aranha and Alfred Menezes. Vol. 8895. LNCS. Springer, Heidelberg, Sept. 2015, pp. 104–123 (cit. on p. 6). [BSNRN14] Alessandro Bruni, Michal Sojka, Flemming Nielson, and Hanne Riis Nielson. Formal Security Analysis of the MaCAN Protocol. In: Integrated Formal Methods. Ed. by Elvira Albert and Emil Sekerinski. Springer International Publishing, 2014, pp. 241–255 (cit. on p. 20). [BSS+13] Ray Beaulieu, Douglas Shors, Jason Smith, Stefan Treatman-Clark, Bryan Weeks, and Louis Wingers. The SIMON and SPECK Families of Lightweight Block Ciphers. Cryptology ePrint Archive, Report 2013/404. http://eprint.iacr.org/ 2013/404. 2013 (cit. on pp. 6, 7). [BSS+15] Ray Beaulieu, Douglas Shors, Jason Smith, Stefan Treatman-Clark, Bryan Weeks, and Louis Wingers. SIMON and SPECK: Block Ciphers for the Internet of Things. Cryptology ePrint Archive, Report 2015/585. http://eprint.iacr.org/ 2015/585. 2015 (cit. on p. 7). [BSW01] Alex Biryukov, Adi Shamir, and David Wagner. Real Time Cryptanalysis of A5/1 on a PC. In: FSE 2000. Ed. by Bruce Schneier. Vol. 1978. LNCS. Springer, Heidelberg, Apr. 2001, pp. 1–18 (cit. on p. 8). [BU02] John Black and Hector Urtubia. Side-Channel Attacks on Symmetric Encryption Schemes: The Case for Authenticated Encryption. In: USENIX Security 2002. Ed. by Dan Boneh. USENIX Association, Aug. 2002, pp. 327–338 (cit. on pp. 85, 95). [BWJM97] Simon Blake-Wilson, Don Johnson, and Alfred Menezes. Key Agreement Protocols and Their Security Analysis. In: 6th IMA International Conference on Cryptogra- phy and Coding. Ed. by Michael Darnell. Vol. 1355. LNCS. Springer, Heidelberg, Dec. 1997, pp. 30–45 (cit. on pp. 11, 38, 100, 117, 159). [BY03] Mihir Bellare and Bennet S. Yee. Forward-Security in Private-Key Cryptography. In: CT-RSA 2003. Ed. by Marc Joye. Vol. 2612. LNCS. Springer, Heidelberg, Apr. 2003, pp. 1–18 (cit. on pp. 141–143). [CBH05] Kim-Kwang Raymond Choo, Colin Boyd, and Yvonne Hitchcock. Examining Indistinguishability-Based Proof Models for Key Establishment Protocols. In: ASI- ACRYPT 2005. Ed. by Bimal K. Roy. Vol. 3788. LNCS. Springer, Heidelberg, Dec. 2005, pp. 585–604 (cit. on p. 100). [CC04] Zhaohui Cheng and Richard Comley. Attacks On An ISO/IEC 11770-2 Key Estab- lishment Protocol. Cryptology ePrint Archive, Report 2004/249. http://eprint. iacr.org/2004/249. 2004 (cit. on p. 25). [CF12] Cas Cremers and Michèle Feltz. Beyond eCK: Perfect Forward Secrecy under Ac- tor Compromise and Ephemeral-Key Reveal. Cryptology ePrint Archive, Report 2012/416. http://eprint.iacr.org/2012/416. 2012 (cit. on p. 11). [CF19] Sébastien Canard and Loïc Ferreira. Extended 3-Party ACCE and Application to LoRaWAN 1.1. In: AFRICACRYPT 19. Ed. by Johannes Buchmann, Abderrahmane Nitaj, and Tajjeeddine Rachidi. Vol. 11627. LNCS. Springer, Heidelberg, July 2019, pp. 21–38 (cit. on pp. vi, vii, 26, 27, 43, 73, 99). Bibliography 205

[CFPR15] Carlos Cid, Loïc Ferreira, Gordon Procter, and Matt J. B. Robshaw. Algebraic Cryptanalysis and RFID Authentication. In: Radio Frequency Identication. Ed. by Stefan Mangard and Patrick Schaumont. Springer International Publishing, 2015, pp. 104–121 (cit. on p. 9). [CFR13] Sébastien Canard, Loïc Ferreira, and Matt Robshaw. Improved (and Practical) Public-Key Authentication for UHF RFID Tags. In: Smart Card Research and Ad- vanced Applications. Ed. by Stefan Mangard. Springer, 2013, pp. 46–61 (cit. on p. 8). [CGCD+17] Katriel Cohn-Gordon, Cas Cremers, Benjamin Dowling, Luke Garratt, and Dou- glas Stebila. A Formal Security Analysis of the Signal Messaging Protocol. In: 2017 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 2017, pp. 451–466 (cit. on p. 142). [CH14] Cas Cremers and Marko Horvat. Improving the ISO/IEC 11770 Standard for Key Management Techniques. In: Security Standardisation Research. Ed. by Liqun Chen and Chris Mitchell. Springer International Publishing, 2014, pp. 215–235 (cit. on p. 25). [CHH+17] Cas Cremers, Marko Horvat, Jonathan Hoyland, Sam Scott, and Thyla van der Merwe. A Comprehensive Symbolic Analysis of TLS 1.3. In: ACM CCS 2017. Ed. by Bhavani M. Thuraisingham, David Evans, Tal Malkin, and Dongyan Xu. ACM Press, 2017, pp. 1773–1788 (cit. on p. 25). [CHVV03] Brice Canvel, Alain P. Hiltgen, Serge Vaudenay, and Martin Vuagnoux. Password Interception in a SSL/TLS Channel. In: CRYPTO 2003. Ed. by Dan Boneh. Vol. 2729. LNCS. Springer, Heidelberg, Aug. 2003, pp. 583–599 (cit. on pp. 61, 88, 89, 92, 96). [CK01] Ran Canetti and Hugo Krawczyk. Analysis of Key-Exchange Protocols and Their Use for Building Secure Channels. In: EUROCRYPT 2001. Ed. by Birgit Ptzmann. Vol. 2045. LNCS. Springer, Heidelberg, May 2001, pp. 453–474 (cit. on pp. 11, 100). [CK02] Ran Canetti and Hugo Krawczyk. Security Analysis of IKE’s Signature-based Key- Exchange Protocol. In: CRYPTO 2002. Ed. by Moti Yung. Vol. 2442. LNCS. http: //eprint.iacr.org/2002/120/. Springer, Heidelberg, Aug. 2002, pp. 143–161 (cit. on p. 100). [CK05] Debra L. Cook and Angelos D. Keromytis. Conversion and Proxy Functions for Symmetric Key Ciphers. In: International Symposium on Information Technology: Coding and Computing – ITCC 2005. Vol. 1. 2005, pp. 662–667. url: https:// doi.org/10.1109/ITCC.2005.115 (cit. on pp. x, 197). [CLN16] Craig Costello, Patrick Longa, and Michael Naehrig. Ecient Algorithms for Supersingular Isogeny Die-Hellman. In: CRYPTO 2016, Part I. Ed. by Matthew Robshaw and Jonathan Katz. Vol. 9814. LNCS. Springer, Heidelberg, Aug. 2016, pp. 572–601 (cit. on p. 160). [CM08] Liqun Chen and Chris J. Mitchell. Parsing ambiguities in authentication and key establishment protocols. Cryptology ePrint Archive, Report 2008/419. http:// eprint.iacr.org/2008/419. 2008 (cit. on p. 25). [CMH+07] Piotr Cholda, Anders Mykkeltveit, Bjarne E. Helvik, Otto J. Wittner, and Andrzej Jajszczyk. “A Survey of Resilience Dierentiation Frameworks in Communication Networks”. In: Commun. Surveys Tuts. 9.4 (2007), pp. 32–55. url: http://dx. doi.org/10.1109/COMST.2007.4444749 (cit. on pp. x, 198). 206 Bibliography

[CNS17] André Chailloux, María Naya-Plasencia, and André Schrottenloher. An Ecient Quantum Collision Search Algorithm and Implications on Symmetric Cryptogra- phy. In: ASIACRYPT 2017, Part II. Ed. by Tsuyoshi Takagi and Thomas Peyrin. Vol. 10625. LNCS. Springer, Heidelberg, Dec. 2017, pp. 211–240 (cit. on pp. x, 8, 197). [Cre09] Cas J. F. Cremers. Session-state Reveal Is Stronger Than Ephemeral Key Reveal: Attacking the NAXOS Authenticated Key Exchange Protocol. In: ACNS 09. Ed. by Michel Abdalla, David Pointcheval, Pierre-Alain Fouque, and Damien Vergnaud. Vol. 5536. LNCS. Springer, Heidelberg, June 2009, pp. 20–33 (cit. on p. 100). [Cre11] Cas J. F. Cremers. Key Exchange in IPsec Revisited: Formal Analysis of IKEv1 and IKEv2. In: ESORICS 2011. Ed. by Vijay Atluri and Claudia Díaz. Vol. 6879. LNCS. Springer, Heidelberg, 2011, pp. 315–334 (cit. on p. 100). [CS15] Iwen Coisel and Ignacio Sanchez. Improved Cryptanalysis of the DECT Standard Cipher. In: CHES 2015. Ed. by Tim Güneysu and Helena Handschuh. Vol. 9293. LNCS. Springer, Heidelberg, Sept. 2015, pp. 269–286 (cit. on p. 9). [DCK+15] Daniel Dinu, Yann Le Corre, Dmitry Khovratovich, Léo Perrin, Johann Großschädl, and Alex Biryukov. Triathlon of Lightweight Block Ciphers for the Internet of Things. Cryptology ePrint Archive, Report 2015/209. http://eprint.iacr. org/2015/209. 2015 (cit. on pp. 6, 7). [DDSW11] Lucas Davi, Alexandra Dmitrienko, Ahmad-Reza Sadeghi, and Marcel Winandy. Privilege Escalation Attacks on Android. In: ISC 2010. Ed. by Mike Burmester, Gene Tsudik, Spyros S. Magliveras, and Ivana Ilic. Vol. 6531. LNCS. Springer, Heidelberg, Oct. 2011, pp. 346–360 (cit. on p. 92). [DFGS15] Benjamin Dowling, Marc Fischlin, Felix Günther, and Douglas Stebila. A Cryp- tographic Analysis of the TLS 1.3 Handshake Protocol Candidates. In: ACM CCS 2015. Ed. by Indrajit Ray, Ninghui Li, and Christopher Kruegel. ACM Press, Oct. 2015, pp. 1197–1210 (cit. on p. 119). [DFGS16] Benjamin Dowling, Marc Fischlin, Felix Günther, and Douglas Stebila. A Cryp- tographic Analysis of the TLS 1.3 draft-10 Full and Pre-shared Key Handshake Protocol. Cryptology ePrint Archive, Report 2016/081. http://eprint.iacr. org/2016/081. 2016 (cit. on p. 193). [DFK+17] Antoine Delignat-Lavaud, Cédric Fournet, Markulf Kohlweiss, Jonathan Protzenko, Aseem Rastogi, Nikhil Swamy, Santiago Zanella-Béguelin, Karthikeyan Bhar- gavan, Jianyang Pan, and Jean Karim Zinzindohoue. Implementing and Proving the TLS 1.3 Record Layer. In: 2017 IEEE Symposium on Security and Privacy. IEEE Computer Society Press, May 2017, pp. 463–482 (cit. on p. 25). [DH76] Whiteld Die and Martin E. Hellman. “New Directions in Cryptography”. In: IEEE Transactions on Information Theory 22.6 (1976), pp. 644–654 (cit. on pp. iv, 4, 140, 175). [DH79] Whiteld Die and Martin E. Hellman. “Privacy and Authentication: An Intro- duction to Cryptography”. In: Proceedings of the IEEE 67.3 (Mar. 1979), pp. 397– 427 (cit. on pp. 46, 50). Bibliography 207

[DJ14] Mohammad Sadeq Dousti and Rasool Jalili. FORSAKES: A Forward-Secure Authen- ticated Key Exchange Protocol Based on Symmetric Key-Evolving Schemes. Cryp- tology ePrint Archive, Report 2014/123. http://eprint.iacr.org/2014/123. 2014 (cit. on pp. 12, 22, 25, 140, 143). [DM04] Peter C. Dillinger and Panagiotis Manolios. Bloom Filters in Probabilistic Veri- cation. In: Formal Methods in Computer-Aided Design. Vol. 3312. Springer, 2004, pp. 367–381 (cit. on pp. 63, 73). [DN18a] Tahsin C. M. Dönmez and Ethiopia Nigussie. Security of Join Procedure and its Delegation in LoRaWAN v1.1. In: FNC/MobiSPC. Vol. 134. 2018, pp. 204–211. url: https://doi.org/10.1016/j.procs.2018.07.202 (cit. on p. 76). [DN18b] Tahsin C. M. Dönmez and Ethiopia Nigussie. Security of LoRaWAN v1.1 in Back- ward Compatibility Scenarios. In: FNC/MobiSPC. Ed. by Elhadi Shakshuki and Ansar Yasar. Vol. 134. 2018, pp. 51–58. url: https://doi.org/10.1016/j. procs.2018.07.143 (cit. on p. 76). [DPW11] Jean Paul Degabriele, Kenneth G. Paterson, and Gaven J. Watson. “Provable Security in the Real World”. In: IEEE Security and Privacy 9.3 (May 2011), pp. 33– 41 (cit. on p. 50). [DR08] Tim Dierks and Eric Rescorla. The Transport Layer Security (TLS) Protocol – Ver- sion 1.2. 2008. url: https://tools.ietf.org/html/rfc5246 (cit. on pp. 4, 11, 13, 38, 82, 84, 100, 107, 111, 119, 175). [DvW92] Whiteld Die, Paul C. van Oorschot, and Michael J. Wiener. “Authentication and Authenticated Key Exchanges”. In: Designs, Codes and Cryptography 2.2 (June 1992), pp. 107–125 (cit. on pp. iv, 9, 140). [Dwo01] Morris Dworkin. NIST Special Publication 800-38A Recommendation for Block Cipher Modes of Operation – Methods and Techniques. Dec. 2001. url: http:// nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800- 38a.pdf (cit. on pp. 46, 50). [Dwo05] Morris Dworkin. NIST Special Publication 800-38B Recommendation for Block Ci- pher Modes of Operation: The CMAC Mode for Authentication. May 2005. url: http://csrc.nist.gov/publications/nistpubs/800- 38B/SP_800- 38B.pdf (cit. on p. 46). [DY81] Danny Dolev and Andrew Chi-Chih Yao. On the Security of Public Key Protocols (Extended Abstract). In: 22nd FOCS. IEEE Computer Society Press, Oct. 1981, pp. 350–357 (cit. on p. 22). [Dön19] Tahsin Dönmez. Personal communication. 2019 (cit. on p. 77). [EBPG18] Mohamed Eldefrawy, Ismail Butun, Nuno Pereira, and Mikael Gidlund. “Formal Security Analysis of LoRaWAN”. In: Computer Networks 148 (2018), pp. 328–339. url: https://doi.org/10.1016/j.comnet.2018.11.017 (cit. on p. 78). [EKP+07] Thomas Eisenbarth, Sandeep Kumar, Christof Paar, Axel Poschmann, and Leif Uhsadel. “A Survey of Lightweight-Cryptography Implementations”. In: IEEE Des. Test 24.6 (2007), pp. 522–533. url: https://doi.org/10.1109/MDT. 2007.178 (cit. on p. 7). [ET05] Pasi Eronen and Hannes Tschofenig. Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). RFC 4279. 2005 (cit. on pp. 13, 25, 112). 208 Bibliography

[ECR08] ECRYPT network. The ECRYPT Stream Cipher Project. 2008. url: https://www. ecrypt.eu.org/stream/ (cit. on p. 8). [ETS17] ETSI. Smart Cards; Secure packet structure for UICC based applications (release 12). TS 102.225, v12.1.0 (2014-10). 2017 (cit. on p. 82). [Fea16] Nicholas Fearn. Orange deploys LoRa network in thousands of French towns. In- ternet of Business. 2016. url: https://internetofbusiness.com/orange- lora-network-france/ (cit. on p. 45). [Fei73] Horst Feistel. “TCryptography and Data Security”. In: Scientic American 228.5 (1973), pp. 15–23 (cit. on p. 4). [FOR16] Pierre-Alain Fouque, Cristina Onete, and Benjamin Richard. Achieving Better Privacy for the 3GPP AKA Protocol. Cryptology ePrint Archive, Report 2016/480. http://eprint.iacr.org/2016/480. 2016 (cit. on p. 100). [FS99] Niels Ferguson and Bruce Schneier. A Cryptographic Evaluation of IPsec. 1999 (cit. on p. 100). [GAB19] Utku Gulen, Abdelrahman Alkhodary, and Selcuk Baktir. “Implementing RSA for Wireless Sensor Nodes”. In: Sensors 19.13 (2019). url: https://doi.org/ 10.3390/s19132864 (cit. on p. 6). [Gag17] Tommaso Gagliardoni. Quantum Security of Cryptographic Primitives. PhD thesis. Technische Universität Darmstadt, 2017. url: http://tuprints.ulb.tu- darmstadt.de/6019/ (cit. on p. 197). [GL04] Marc Girault and David Lefranc. Public Key Authentication with One (Online) Single Addition. In: CHES 2004. Ed. by Marc Joye and Jean-Jacques Quisquater. Vol. 3156. LNCS. Springer, Heidelberg, Aug. 2004, pp. 413–427 (cit. on p. 8). [Glo14] GlobalPlatform. GlobalPlatform Technology – Secure Channel Protocol ‘03’ – Card Specication v2.2 – Amendment D. version 1.1.1, GPC_SPE_014. 2014. url: http: //www.globalplatform.org/specificationscard.asp (cit. on pp. 14, 25, 82). [Glo18] GlobalPlatform. GlobalPlatform Technology – Card Specication – Version 2.3.1. Reference GPC_SPE_034. 2018. url: https://www.globalplatform.org/ specificationscard.asp (cit. on pp. 14, 25, 82, 140). [GMVV12] Bogdan Groza, Pal-Stefan Murvay, Anthony Van Herrewege, and Ingrid Ver- bauwhede. LiBrA-CAN: A Lightweight Broadcast Authentication Protocol for Con- troller Area Networks. In: CANS 12. Ed. by Josef Pieprzyk, Ahmad-Reza Sadeghi, and Mark Manulis. Vol. 7712. LNCS. Springer, Heidelberg, Dec. 2012, pp. 185–200 (cit. on p. 20). [Got] Compact server for private LoRaWAN networks. url: https://github.com/ gotthardp/lorawan-server (cit. on p. 55). [GPS06] Marc Girault, Guillaume Poupard, and Jacques Stern. “On the Fly Authentication and Signature Schemes Based on Groups of Unknown Order”. In: Journal of Cryptology 19.4 (Oct. 2006), pp. 463–487 (cit. on p. 8). [Gro96] Lov K. Grover. A Fast Quantum Mechanical Algorithm for Database Search. In: 28th ACM STOC. ACM Press, May 1996, pp. 212–219 (cit. on p. 160). [GSM16] GSMA. 3GPP Low Power Wide Area Technologies – GSMA White Paper. 2016 (cit. on p. 22). Bibliography 209

[GSM19] GSMA. The Mobile Economy 2019. 2019. url: https://www.gsma.com/r/ mobileeconomy/ (cit. on pp. 82, 95). [Gün90] Christoph G. Günther. An Identity-Based Key-Exchange Protocol. In: EUROCRYPT’89. Ed. by Jean-Jacques Quisquater and Joos Vandewalle. Vol. 434. LNCS. Springer, Heidelberg, Apr. 1990, pp. 29–37 (cit. on pp. iv, 9, 140). [Har14] Thomas Hardjono. Kerberos for Internet-of-Things. 2014. url: https://kit. mit.edu/sites/default/files/documents/Kerberos_Internet_of% 20Things.pdf (cit. on p. 13). [HC14] Chan-Kyu Han and Hyoung-Kee Choi. “Security Analysis of Handover Key Man- agement in 4G LTE/SAE Networks”. In: IEEE Transactions on Mobile Computing 13.2 (2014), pp. 457–468 (cit. on pp. 23, 25). [HFPM18] George Hatzivasilis, Konstantinos Fysarakis, Ioannis Papaefstathiou, and Char- alampos Manifavas. “A review of lightweight block ciphers”. In: Journal of Cryp- tographic Engineering 8.2 (June 2018), pp. 141–184 (cit. on p. 8). [HGFS15] Clemens Hlauschek, Markus Gruber, Florian Fankhauser, and Christian Schanes. Prying Open Pandora’s Box: KCI Attacks Against TLS. In: Proceedings of the 9th USENIX Conference on Oensive Technologies. WOOT’15. USENIX Association, 2015 (cit. on p. 159). [HHR+08] Daniel Halperin, Thomas S. Heydt-Benjamin, Benjamin Ransford, Shane S. Clark, Benessa Defend, Will Morgan, Kevin Fu, Tadayoshi Kohno, and William H. Maisel. Pacemakers and Implantable Cardiac Debrillators: Software Radio At- tacks and Zero-Power Defenses. In: 2008 IEEE Symposium on Security and Privacy. IEEE Computer Society Press, May 2008, pp. 129–142 (cit. on p. 5). [HS13] Michael Hutter and Peter Schwabe. NaCl on 8-Bit AVRMicrocontrollers. In: AFRICACRYPT 13. Ed. by Amr Youssef, Abderrahmane Nitaj, and Aboul Ella Hassanien. Vol. 7918. LNCS. Springer, Heidelberg, June 2013, pp. 156–172 (cit. on pp. 6, 7). [HSD+05] Changhua He, Mukund Sundararajan, Anupam Datta, Ante Derek, and John C. Mitchell. A Modular Correctness Proof of IEEE 802.11i and TLS. In: ACM CCS 2005. Ed. by Vijayalakshmi Atluri, Catherine Meadows, and Ari Juels. ACM Press, Nov. 2005, pp. 2–15 (cit. on p. 25). [Hun17] Derek Hunt. Certication Deep Dive. LoRa Alliance. 2017. url: https://lora- alliance.org/resource-hub/certification-deep-dive (cit. on p. 54). [HW08] Georg Hoerek and Johannes Wolkerstorfer. Coupon Recalculation for the GPS Authentication Scheme. In: Smart Card Research and Advanced Applications. Ed. by Gilles Grimaud and François-Xavier Standaert. Vol. 5189. LNCS. Springer, 2008, pp. 162–175 (cit. on p. 8). [HW18] Jialuo Han and Jidong Wang. An Enhanced Key Management Scheme for Lo- RaWAN. In: Security, Privacy, and Anonymity in Computation, Communication, and Storage. Ed. by Guojun Wang, Jinjun Chen, and Laurence T. Yang. Springer International Publishing, 2018, pp. 407–416 (cit. on p. 78). [IK03a] Tetsu Iwata and Kaoru Kurosawa. OMAC: One-Key CBC MAC. In: FSE 2003. Ed. by Thomas Johansson. Vol. 2887. LNCS. Springer, Heidelberg, Feb. 2003, pp. 129–153 (cit. on p. 50). 210 Bibliography

[IK03b] Tetsu Iwata and Kaoru Kurosawa. OMAC: One-Key CBC MAC – Addendum. 2003. url: http : / / csrc . nist . gov / groups / ST / toolkit / BCM / documents / proposedmodes/omac/omac-ad.pdf (cit. on p. 50). [IK03c] Tetsu Iwata and Kaoru Kurosawa. Stronger Security Bounds for OMAC, TMAC, and XCBC. In: INDOCRYPT 2003. Ed. by Thomas Johansson and Subhamoy Maitra. Vol. 2904. LNCS. Springer, Heidelberg, Dec. 2003, pp. 402–415 (cit. on pp. 50, 136). [i-s18] i-scoop. The Industrial Internet of Things (IIoT): the business guide to Industrial IoT. 2018. url: https://www.i-scoop.eu/internet-of-things-guide/ industrial-internet-things-iiot-saving-costs-innovation/ (cit. on p. 165). [IEE04] IEEE. IEEE Standard for Information technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Spe- cic requirements – Part 11: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specications: Amendment 6: Medium Access Control (MAC) Security Enhancements. 2004 (cit. on pp. 20, 23, 25). [IHS17] IHS Markit. The Internet of Things: a movement, not a market. 2017. url: https: //cdn.ihs.com/www/pdf/IoT_ebook.pdf (cit. on p. 4). [Int08] International Organization for Standardization. ISO/IEC 11770-2 – Information technology – Security techniques – Key Management – Part 2: Mechanisms using Symmetric Techniques. 2008 (cit. on pp. 12, 25, 140). [Int11] International Organization for Standardization. ISO/IEC 9797-1:2011 – Informa- tion technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher. 2011 (cit. on p. 83). [Int17] International Organization for Standardization. ISO/IEC 10116:2017 – Information technology – Security techniques – Modes of operation for an n-bit block cipher. 2017 (cit. on pp. 83, 95). [IoT19] IoT.Business.News. MWC 2019 – LoRa Alliance: interview with CEO, Donna Moore. 2019. url: https : / / iotbusinessnews . com / 2019 / 03 / 13 / 37011 - mwc - 2019-lora-alliance-interview-with-ceo-donna-moore/ (cit. on p. 45). [JD11] David Jao and Luca De Feo. Towards Quantum-Resistant Cryptosystems from Supersingular Elliptic Curve Isogenies. In: Post-Quantum Cryptography - 4th In- ternational Workshop, PQCrypto 2011. Ed. by Bo-Yin Yang. Springer, Heidelberg, 2011, pp. 19–34 (cit. on p. 160). [JKSS11] Tibor Jager, Florian Kohlar, Sven Schäge, and Jörg Schwenk. On the Security of TLS-DHE in the Standard Model. Cryptology ePrint Archive, Report 2011/219. http://eprint.iacr.org/2011/219. 2011 (cit. on pp. 11, 28, 32, 36, 38, 100, 106, 111, 117, 119). [Jon03] Jakob Jonsson. On the Security of CTR + CBC-MAC. In: SAC 2002. Ed. by Kaisa Nyberg and Howard M. Heys. Vol. 2595. LNCS. Springer, Heidelberg, Aug. 2003, pp. 76–93 (cit. on p. 84). [KE10] Hugo Krawczyk and Pasi Eronen. HMAC-based Extract-and-Expand Key Deriva- tion Function (HKDF). RFC 5869. 2010. url: https://tools.ietf.org/html/ rfc5869 (cit. on p. 16). [Ker83a] Auguste Kerckhos. “La cryptographie militaire”. In: Journal des sciences militaires 9 (1883), pp. 5–38 (cit. on p. 4). Bibliography 211

[Ker83b] Auguste Kerckhos. “La cryptographie militaire – Seconde partie”. In: Journal des sciences militaires 9 (1883), pp. 161–191 (cit. on p. 4). [KHN+14] Charlie Kaufman, Paul Homan, Yoav Nir, Pasi Eronen, and Tero Kivinen. Internet Key Exchange Protocol Version 2 (IKEv2). RFC 7296. 2014. url: https://tools. ietf.org/html/rfc7296 (cit. on pp. 4, 175). [Kim16] Gary Kim. Tata to deploy LoRa network for IoT. Spectrum Futures. 2016. url: http://spectrumfutures.org/tata-to-deploy-lora-network-for- iot/ (cit. on p. 45). [Kin16] Sean Kinney. 100 US cities covered by Senet LoRa network for IoT. RCR Wireless News. 2016. url: http://www.rcrwireless.com/20160615/internet-of- things/100- u- s- cities- covered- senet- lora- network- iot- tag17 (cit. on p. 45). [Kiv] Anton Kivva. The banker that can steal anything. 20/09/2016. url: https:// securelist.com/the-banker-that-can-steal-anything/76101/ (cit. on p. 92). [KJ17] Burton S. Kaliski Jr. A Quantum “Magic Box” for the Discrete Logarithm Problem. Cryptology ePrint Archive, Report 2017/745. 2017. url: https://eprint.iacr. org/2017/745 (cit. on p. 160). [KLLN16a] Marc Kaplan, Gaëtan Leurent, Anthony Leverrier, and María Naya-Plasencia. Breaking Symmetric Cryptosystems Using Quantum Period Finding. In: CRYPTO 2016, Part II. Ed. by Matthew Robshaw and Jonathan Katz. Vol. 9815. LNCS. Springer, Heidelberg, Aug. 2016, pp. 207–237 (cit. on pp. x, 8, 160, 197). [KLLN16b] Marc Kaplan, Gaëtan Leurent, Anthony Leverrier, and María Naya-Plasencia. “Quantum Dierential and Linear Cryptanalysis”. In: IACR Trans. Symm. Cryptol. 2016.1 (2016). http://tosc.iacr.org/index.php/ToSC/article/view/ 536, pp. 71–94. issn: 2519-173X (cit. on pp. x, 8, 197). [KMSS15] Dennis Kupser, Christian Mainka, Jörg Schwenk, and Juraj Somorovsky. How to Break XML Encryption – Automatically. In: Proceedings of the 9th USENIX Con- ference on Oensive Technologies. WOOT’15. USENIX Association, 2015, pp. 11– 11. url: http://dl.acm.org/citation.cfm?id=2831211.2831222 (cit. on p. 96). [KOY03] Jonathan Katz, Rafail Ostrovsky, and Moti Yung. Forward Secrecy in Password- Only Key Exchange Protocols. In: SCN 02. Ed. by Stelvio Cimato, Clemente Galdi, and Giuseppe Persiano. Vol. 2576. LNCS. Springer, Heidelberg, Sept. 2003, pp. 29– 44 (cit. on p. 11). [KPW13] Hugo Krawczyk, Kenneth G. Paterson, and Hoeteck Wee. On the Security of the TLS Protocol: A Systematic Analysis. In: CRYPTO 2013, Part I. Ed. by Ran Canetti and Juan A. Garay. Vol. 8042. LNCS. Springer, Heidelberg, Aug. 2013, pp. 429–448 (cit. on pp. 32, 100). [Kra01] Hugo Krawczyk. The Order of Encryption and Authentication for Protecting Com- munications (or: How Secure Is SSL?) In: CRYPTO 2001. Ed. by Joe Kilian. Vol. 2139. LNCS. Springer, Heidelberg, Aug. 2001, pp. 310–331 (cit. on p. 84). [Kra03] Hugo Krawczyk. SIGMA: The “SIGn-and-MAc” Approach to Authenticated Die- Hellman and Its Use in the IKE Protocols. In: CRYPTO 2003. Ed. by Dan Boneh. Vol. 2729. LNCS. Springer, Heidelberg, Aug. 2003, pp. 400–425 (cit. on p. 112). 212 Bibliography

[Kra05] Hugo Krawczyk. HMQV: A High-Performance Secure Die-Hellman Protocol. Cryp- tology ePrint Archive, Report 2005/176. http://eprint.iacr.org/2005/176. 2005 (cit. on p. 11). [Kra16] Hugo Krawczyk. A Unilateral-to-Mutual Authentication Compiler for Key Ex- change (with Applications to Client Authentication in TLS 1.3). In: ACM CCS 2016. Ed. by Edgar R. Weippl, Stefan Katzenbeisser, Christopher Kruegel, Andrew C. Myers, and Shai Halevi. ACM Press, Oct. 2016, pp. 1438–1450 (cit. on pp. ix, 102, 197). [Kru09] John Krumm. Ubiquitous Computing Fundamentals. 1st. Chapman & Hall/CRC, 2009 (cit. on p. 4). [KS17] Jaehyu Kim and JooSeok Song. “A Dual Key-Based Activation Scheme for Secure LoRaWAN”. In: Wireless Communications and Mobile Computing 2017 (2017). url: https://doi.org/10.1155/2017/6590713 (cit. on p. 77). [KSS03] John C. Knight, Elisabeth A. Strunk, and Kevin J. Sullivan. Towards a rigorous def- inition of information system survivability. In: Proceedings of DARPA Information Survivability Conference and Exposition – DISCEX’03. Vol. 1. IEEE, 2003, pp. 78– 89. url: https://doi.org/10.1109/DISCEX.2003.1194874 (cit. on pp. x, 198). [KSS13] Florian Kohlar, Sven Schäge, and Jörg Schwenk. On the Security of TLS-DH and TLS-RSA in the Standard Model. Cryptology ePrint Archive, Report 2013/367. http://eprint.iacr.org/2013/367. 2013 (cit. on pp. 111, 119). [LBM07] Tri Van Le, Mike Burmester, and Breno de Medeiros. Universally composable and forward-secure RFID authentication and authenticated key exchange. In: ASIACCS 07. Ed. by Feng Bao and Steven Miller. ACM Press, Mar. 2007, pp. 242–252 (cit. on pp. 14, 23, 25, 140, 143). [Lif16] Renaud Lifchitz. Security review of LoRaWAN networks. Hardwear.io. 2016. url: https://speakerdeck.com/rlifchitz/security-review-of-lorawan- networks (cit. on p. 74). [LLM07] Brian A. LaMacchia, Kristin Lauter, and Anton Mityagin. Stronger Security of Authenticated Key Exchange. In: ProvSec 2007. Ed. by Willy Susilo, Joseph K. Liu, and Yi Mu. Vol. 4784. LNCS. Springer, Heidelberg, Nov. 2007, pp. 1–16 (cit. on pp. 11, 100). [LOL12] Conrado Porto Lopes Gouvêa, Leonardo B. Oliveira, and Julio Cesar López- Hernández. “Ecient software implementation of public-key cryptography on sensor networks using the MSP430X microcontroller”. In: Journal of Crypto- graphic Engineering 2.1 (May 2012), pp. 19–29 (cit. on p. 7). [LoR] LoRa Alliance. LoRaWAN Certied Products. Last consulted December 8, 2017. url: https://www.lora- alliance.org/certified- products (cit. on p. 54). [LoR17] LoRa Alliance Technical committee. LoRaWAN 1.0.2 Regional Parameters. LoRa Alliance, version 1.0, revision B. 2017. url: https://lora-alliance.org/ resource-hub/lorawantm-regional-parameters-v102rb (cit. on p. 45). [LoR18a] LoRa Alliance Technical committee. LoRaWAN 1.0.3 Specication. LoRa Alliance. 2018. url: https : / / lora - alliance . org / resource - hub / lorawanr - specification-v103 (cit. on pp. 22, 24, 25, 45, 165). Bibliography 213

[LoR18b] LoRa Alliance Technical committee. Technical Recommendations for Preventing State Synchronization Issues around LoRaWAN1.0.x Join Procedure. LoRa Alliance, version 1.0.0. 2018. url: https://lora- alliance.org/resource- hub/ technical - recommendations - preventing - state - synchronization - issues-around-lorawantm-10x (cit. on pp. 27, 63, 70, 73). [LSY+14] Yong Li, Sven Schäge, Zheng Yang, Florian Kohlar, and Jörg Schwenk. On the Security of the Pre-shared Key Ciphersuites of TLS. In: PKC 2014. Ed. by Hugo Krawczyk. Vol. 8383. LNCS. Springer, Heidelberg, Mar. 2014, pp. 669–684 (cit. on pp. 11, 25, 40). [Lun17] Lucas Lundgren. Taking over the world through MQTT – Aftermath. Black Hat USA. 2017 (cit. on pp. 60, 70). [LWG14] Zhe Liu, Erich Wenger, and Johann Großschädl. MoTE-ECC: Energy-Scalable Elliptic Curve Cryptography for Wireless Sensor Networks. In: ACNS 14. Ed. by Ioana Boureanu, Philippe Owesarski, and Serge Vaudenay. Vol. 8479. LNCS. Springer, Heidelberg, June 2014, pp. 361–379 (cit. on pp. 6, 7). [Mar16] Sue Marek. SK Telecom & KPN Deploy Nationwide LoRa IoT Networks. sdx central. 2016. url: https://www.sdxcentral.com/articles/news/sk-telecom- kpn - deploy - nationwide - lorawan - iot - networks / 2016 / 07/ (cit. on p. 45). [McG08] David McGrew. An Interface and Algorithms for Authenticated Encryption. RFC 5116. 2008. url: https://tools.ietf.org/html/rfc5116 (cit. on p. 119). [MEM] MEMSIC. TelosB – TelosB Mote Platform. url: http : / / www . memsic . com / userfiles/files/Datasheets/WSN/telosb_datasheet.pdf (cit. on p. 7). [Mey80] John F. Meyer. “On Evaluating the Performability of Degradable Computing Systems”. In: IEEE Trans. Comput. 29.8 (1980), pp. 720–731. url: https://doi. org/10.1109/TC.1980.1675654 (cit. on pp. x, 198). [Mey92] John F. Meyer. “Performability: a retrospective and some pointers to the future”. In: Performance Evaluation 14.3–4 (1992), pp. 139–156. url: https://doi.org/ 10.1016/0166-5316(92)90002-X (cit. on pp. x, 198). [MGSP08] Giacomo de Meulenaer, François Gosset, François-Xavier Standaert, and Olivier Pereira. On the Energy Cost of Communications and Cryptography in Wireless Sensor Networks. In: IEEE International Workshop on Security and Privacy in Wire- less and Mobile Computing, Networking and Communications (SecPriWiMob’2008). 2008, pp. 580–585 (cit. on pp. 6, 7). [Mil16a] Robert Miller. LoRa Security – Building a Secure LoRa Solution. Whitepaper, MWR Labs. Mar. 2016. url: https : / / labs . mwrinfosecurity . com / assets / BlogFiles / mwri - LoRa - security - guide - 1 . 2 - 2016 - 03 - 22 . pdf (cit. on p. 74). [Mil16b] Robert Miller. LoRa the Explorer – Attacking and Defending LoRa Systems. Infor- mation Security Conference – SyScan360. 2016. url: https://www.syscan360. org/slides/2016_SG_Robert_Miller_LoRa_the_Explorer-Attacking_ and_Defending_LoRa_systems.pdf (cit. on p. 74). 214 Bibliography

[MMDF+12] Andres Molina-Markham, George Danezis, Kevin Fu, Prashant J. Shenoy, and David E. Irwin. Designing Privacy-Preserving Smart Meters with Low-Cost Micro- controllers. In: FC 2012. Ed. by Angelos D. Keromytis. Vol. 7397. LNCS. Springer, Heidelberg, 2012, pp. 239–253 (cit. on p. 8). [MPL+11] Amir Moradi, Axel Poschmann, San Ling, Christof Paar, and Huaxiong Wang. Pushing the Limits: A Very Compact and a Threshold Implementation of AES. In: EUROCRYPT 2011. Ed. by Kenneth G. Paterson. Vol. 6632. LNCS. Springer, Hei- delberg, May 2011, pp. 69–88 (cit. on p. 6). [MS08] Anish Mathuria and G. Sriram. New attacks on ISO key establishment protocols. Cryptology ePrint Archive, Report 2008/336. http://eprint.iacr.org/ 2008/336. 2008 (cit. on p. 25). [MSG+16] Eduard Marin, Dave Singelée, Flavio D. Garcia, Tom Chothia, Rik Willems, and Bart Preneel. On the (in)Security of the Latest Generation Implantable Cardiac Debrillators and How to Secure Them. In: Proceedings of the 32nd Annual Con- ference on Computer Security Applications. ACSAC ’16. ACM, 2016, pp. 226–236. url: http://doi.acm.org/10.1145/2991079.2991094 (cit. on p. 5). [MSW08] Paul Morrissey, Nigel P. Smart, and Bogdan Warinschi. A Modular Security Anal- ysis of the TLS Handshake Protocol. In: ASIACRYPT 2008. Ed. by Josef Pieprzyk. Vol. 5350. LNCS. Springer, Heidelberg, Dec. 2008, pp. 55–73 (cit. on p. 100). [MSY+16] Eduard Marin, Dave Singelée, Bohan Yang, Ingrid Verbauwhede, and Bart Pre- neel. On the Feasibility of Cryptography for a Wireless Insulin Pump System. In: Proceedings of the Sixth ACM Conference on Data and Application Security and Privacy. CODASPY ’16. ACM, 2016, pp. 113–120. url: http://doi.acm.org/ 10.1145/2857705.2857746 (cit. on p. 5). [MV15] Charlie Miller and Chris Valasek. Remote Exploitation of an Unaltered Passenger Vehicle. 2015. url: http://illmatics.com/Remote%20Car%20Hacking.pdf (cit. on p. 5). [MVO96] Alfred J. Menezes, Scott A. Vanstone, and Paul C. Van Oorschot. Handbook of Applied Cryptography. 1st. CRC Press, Inc., 1996 (cit. on p. 11). [MW04] Ulrike Meyer and Susanne Wetzel. A Man-in-the-middle Attack on UMTS. In: Pro- ceedings of the 3rd ACM Workshop on Wireless Security – WiSe ’04. Philadelphia, PA, USA: ACM, 2004, pp. 90–97 (cit. on pp. 23, 25). [MWES06] Joshua Mason, Kathryn Watkins, Jason Eisner, and Adam Stubbleeld. A natural language approach to automated cryptanalysis of two-time pads. In: ACM CCS 2006. Ed. by Ari Juels, Rebecca N. Wright, and Sabrina De Capitani di Vimercati. ACM Press, 2006, pp. 235–244 (cit. on pp. 54, 71). [Nan09] Mridul Nandi. “Improved Security Analysis for OMAC as a Pseudo Random Function”. In: Journal of Mathematical Cryptology 3.2 (Aug. 2009), pp. 133–148 (cit. on p. 50). [Nat01] National Institute Of Standards and Technology. NIST FIPS 197 Specication for the Advanced Encryption Standard (AES). 2001. url: http://csrc.nist.gov/ publications/fips/fips197/fips-197.pdf (cit. on pp. 7, 46). Bibliography 215

[Nat04] National Institute Of Standards and Technology. NIST Special Publication 800- 38C Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Condentiality. May 2004. url: http://csrc.nist.gov/ publications/nistpubs/800-38C/SP800-38C_updated-July20_2007. pdf (cit. on p. 84). [Nat19] National Institute Of Standards and Technology. Lightweight Cryptography. 2019. url: https://csrc.nist.gov/Projects/Lightweight- Cryptography (cit. on p. 8). [Nat99] National Institute Of Standards and Technology. Data Encryption Standard (DES). 1999. url: https://csrc.nist.gov/csrc/media/publications/fips/ 46/3/archive/1999-10-25/documents/fips46-3.pdf (cit. on p. 4). [NCOS16] Erick Nascimento, Lukasz Chmielewski, David Oswald, and Peter Schwabe. Attacking Embedded ECC Implementations Through cmov Side Channels. In: SAC 2016. Ed. by Roberto Avanzi and Howard M. Heys. Vol. 10532. LNCS. Springer, Heidelberg, Aug. 2016, pp. 99–119 (cit. on p. 7). [NH09] Christoph Nagl and Michael Hutter. Coupon Recalculation for the Schnorr and GPS Identication Scheme: A Performance Evaluation. In: Workshop on RFID Security 2009 – RFIDSec 2009. Ed. by Lejla Batina. 2009, pp. 1–10 (cit. on p. 8). [NL15] Yoav Nir and Adam Langley. ChaCha20 and Poly1305 for IETF Protocols. RFC 7539. 2015. url: https://tools.ietf.org/html/rfc7539 (cit. on p. 119). [NLG+17] David Naylor, Richard Li, Christos Gkantsidis, Thomas Karagiannis, and Pe- ter Steenkiste. And Then There Were More: Secure Communication for More Than Two Parties. In: Proceedings of the 13th International Conference on Emerging Net- working EXperiments and Technologies. CoNEXT ’17. ACM, 2017, pp. 88–100. url: http://doi.acm.org/10.1145/3143361.3143383 (cit. on p. 101). [NR16] Stefan Nürnberger and Christian Rossow. - vatiCAN - Vetted, Authenticated CAN Bus. In: CHES 2016. Ed. by Benedikt Gierlichs and Axel Y. Poschmann. Vol. 9813. LNCS. Springer, Heidelberg, Aug. 2016, pp. 106–124 (cit. on p. 20). [NSV+15] David Naylor, Kyle Schomp, Matteo Varvello, Ilias Leontiadis, Jeremy Blackburn, Diego López, Konstantina Papagiannaki, Pablo Rodriguez Rodriguez, and Peter Steenkiste. Multi-Context TLS (mcTLS): Enabling Secure In-Network Functionality in TLS. In: Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication. SIGCOMM ’15. ACM, 2015, pp. 199–212. url: http:// doi.acm.org/10.1145/2785956.2787482 (cit. on pp. 100, 101). [NYHR05] Cliord Neuman, Tom Yu, Sam Hartman, and Ken Raeburn. The Kerberos Network Authentication Service (V5). RFC 4120. 2005. url: https://tools.ietf.org/ html/rfc4120 (cit. on pp. 7, 13, 25). [OA16] Orange and Actility. LoRa Device Developer Guide – Orange Connected Objects & Partnerships. 2016. url: https://developer.orange.com/wp-content/ uploads/LoRa-Device-Developer-Guide-Orange.pdf (cit. on p. 45). [Par15] Juha Partala. Algebraic methods for cryptographic key exhange. PhD thesis. Uni- versity of Oulu, 2015. url: http://urn.fi/urn:isbn:9789526207445 (cit. on pp. x, 197). 216 Bibliography

[PM16] Trevor Perrin and Moxie Marlinspike. The Double Ratchet Algorithm. Revision 1, 20/11/2016. 2016. url: https://signal.org/docs/specifications/ doubleratchet/ (cit. on p. 142). [PN18] Jacques Patarin and Valérie Nachef. Commutativity, Associativity, and Public Key Cryptography. In: Number-Theoretic Methods in Cryptology. Ed. by Jerzy Kac- zorowski, Josef Pieprzyk, and Jacek Pomykała. Springer International Publishing, 2018, pp. 104–117 (cit. on pp. x, 197). [PS04] Taejoon Park and Kang G. Shin. “LiSP: A Lightweight Security Protocol for Wireless Sensor Networks”. In: ACM Trans. Embed. Comput. Syst. 3.3 (2004), pp. 634–660 (cit. on pp. 19, 25, 140). [PS18] Christopher Patton and Thomas Shrimpton. Partially Specied Channels: The TLS 1.3 Record Layer without Elision. In: ACM CCS 2018. Ed. by David Lie, Mohammad Mannan, Michael Backes, and XiaoFeng Wang. ACM Press, Oct. 2018, pp. 1415– 1428 (cit. on p. 25). [PST+02] Adrian Perrig, Robert Szewczyk, J.D. Tygar, Victor Wen, and David E. Culler. “SPINS: Security Protocols for Sensor Networks”. In: Wireless Networks 8.5 (2002), pp. 521–534 (cit. on pp. 18, 25, 140). [PW08] Kenneth G. Paterson and Gaven J. Watson. Immunising CBC Mode Against Padding Oracle Attacks: A Formal Security Treatment. In: SCN 08. Ed. by Rafail Ostrovsky, Roberto De Prisco, and Ivan Visconti. Vol. 5229. LNCS. Springer, Heidelberg, Sept. 2008, pp. 340–357 (cit. on p. 95). [PW12] Kenneth G. Paterson and Gaven J. Watson. Authenticated-Encryption with Padding: A Formal Security Treatment. In: Cryptography and Security: From Theory to Ap- plications. Ed. by David Naccache. Springer, 2012, pp. 83–107. url: https:// doi.org/10.1007/978-3-642-28368-0_9 (cit. on p. 96). [PZ03] John Proos and Christof Zalka. “Shor’s Discrete Logarithm Quantum Algorithm for Elliptic Curves”. In: Quantum Info. Comput. 3.4 (July 2003), pp. 317–344 (cit. on p. 160). [Rad11] Jay Radclie. Hacking Medical Devices for Fun and Insulin: Breaking the Hu- man SCADA System. Black Hat USA. 2011. url: https://media.blackhat. com/bh- us- 11/Radcliffe/BH_US_11_Radcliffe_Hacking_Medical_ Devices_WP.pdf (cit. on p. 5). [Res18] Eric Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3. 2018. url: https://tools.ietf.org/html/rfc8446 (cit. on pp. 4, 13, 25, 101, 119, 173, 175). [RG16] Andreea-Ina Radu and Flavio D. Garcia. LeiA: A Lightweight Authentication Pro- tocol for CAN. In: ESORICS 2016, Part II. Ed. by Ioannis G. Askoxylakis, Sotiris Ioannidis, Sokratis K. Katsikas, and Catherine A. Meadows. Vol. 9879. LNCS. Springer, Heidelberg, Sept. 2016, pp. 283–300 (cit. on pp. 20, 22, 25). [RKHP19] David Rupprecht, Katharina Kohls, Thorsten Holz, and Christina Pöpper. Break- ing LTE on Layer Two. In: 2019 IEEE Symposium on Security and Privacy. IEEE Computer Society Press, May 2019, pp. 1121–1136 (cit. on pp. 23, 25, 70). [Rog02] Phillip Rogaway. Authenticated-Encryption With Associated-Data. In: ACM CCS 2002. Ed. by Vijayalakshmi Atluri. ACM Press, Nov. 2002, pp. 98–107 (cit. on p. 193). Bibliography 217

[RS06] Phillip Rogaway and Thomas Shrimpton. A Provable-Security Treatment of the Key-Wrap Problem. In: EUROCRYPT 2006. Ed. by Serge Vaudenay. Vol. 4004. LNCS. Springer, Heidelberg, 2006, pp. 373–390 (cit. on pp. 136, 173). [RSA78] Ronald L. Rivest, Adi Shamir, and Leonard M. Adleman. “A Method for Obtaining Digital Signatures and Public-Key Cryptosystems”. In: Communications of the Association for Computing Machinery 21.2 (1978), pp. 120–126 (cit. on pp. 4, 175). [RSWO17] Eyal Ronen, Adi Shamir, Achi-Or Weingarten, and Colin O’Flynn. IoT Goes Nuclear: Creating a ZigBee Chain Reaction. In: 2017 IEEE Symposium on Security and Privacy. IEEE Computer Society Press, May 2017, pp. 195–212 (cit. on p. 5). [Sch90] Claus-Peter Schnorr. Ecient Identication and Signatures for Smart Cards. In: CRYPTO’89. Ed. by Gilles Brassard. Vol. 435. LNCS. Springer, Heidelberg, Aug. 1990, pp. 239–252 (cit. on p. 8). [Sho] Victor Shoup. On Formal Models for Secure Key Exchange. RZ 3120 (#93166), 19/04/1999 (cit. on p. 11). [Sho04] Victor Shoup. Sequences of games: a tool for taming complexity in security proofs. Cryptology ePrint Archive, Report 2004/332. http://eprint.iacr.org/ 2004/332. 2004 (cit. on pp. 119, 153, 181). [Sho94] Peter W. Shor. Algorithms for Quantum Computation: Discrete Logarithms and Factoring. In: 35th FOCS. IEEE Computer Society Press, Nov. 1994, pp. 124–134 (cit. on p. 160). [Sho97] Peter W. Shor. “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer”. In: SIAM J. Comput. 26.5 (1997), pp. 1484– 1509. url: http://dx.doi.org/10.1137/S0097539795293172 (cit. on p. 8). [Shr04] Tom Shrimpton. A Characterization of Authenticated-Encryption as a Form of Chosen-Ciphertext Security. Cryptology ePrint Archive, Report 2004/272. http: //eprint.iacr.org/2004/272. 2004 (cit. on p. 193). [Sig] Signal. url: https://signal.org/ (cit. on pp. 142, 143). [Sig17a] Sigfox. Secure SigFox Ready devices – Recommendation guide. 2017 (cit. on pp. 22, 165). [Sig17b] Sigfox. SigFox Technical Overview. 2017 (cit. on pp. 22, 165). [SKH+02] James P. G. Sterbenz, Rajesh Krishnan, Regina Rosales Hain, Alden W. Jackson, David Levin, Ram Ramanathan, and John Zao. Survivable Mobile Wireless Net- works: Issues, Challenges, and Research Directions. In: Proceedings of the 1st ACM Workshop on Wireless Security – WiSE ’02. ACM, 2002, pp. 31–40. url: http: //doi.acm.org/10.1145/570681.570685 (cit. on pp. x, 198). [SLE+15] Nicolas Sornin, Miguel Luis, Thomas Eirich, Thorsten Kramp, and Olivier Hersent. LoRaWAN Specication. LoRa Alliance, version 1.0. 2015 (cit. on p. 74). [SLE+16] Nicolas Sornin, Miguel Luis, Thomas Eirich, Thorsten Kramp, and Olivier Hersent. LoRaWAN Specication. LoRa Alliance, version 1.0.2. 2016. url: https://lora- alliance.org/resource-hub/lorawantm-specification-v102 (cit. on pp. 45, 46, 51, 54–56, 60). [Sma16a] SmartCitiesWorld. IoT connectivity for 100 million homes in China. SmartCi- tiesWorld. 2016. url: https://smartcitiesworld.net/news/news/iot- connectivity-for-100-million-homes-in-china-1139 (cit. on p. 45). 218 Bibliography

[Sma16b] SmartCitiesWorld. Semtech LoRa chosen for new IoT network in New Zealand. SmartCitiesWorld. 2016. url: https://smartcitiesworld.net/news/news/ semtech-lora-chosen-for-new-iot-network-in-new-zealand-949 (cit. on p. 45). [Sor17] Nicolas Sornin. LoRaWAN 1.1 Specication. LoRa Alliance, version 1.1, 11/10/2017. 2017. url: https : / / lora - alliance . org / resource - hub / lorawantm - specification-v11 (cit. on pp. 22, 24, 25, 45, 63, 65, 71, 76, 77, 140, 165). [SP05] Stefaan Seys and Bart Preneel. Power Consumption Evaluation of Ecient Digital Signature Schemes for Low Power Devices. In: IEEE International Conference on Wireless And Mobile Computing, Networking And Communications. Vol. 1. WiMob 2005. IEEE, 2005, pp. 79–86 (cit. on p. 172). [SPLI06] JunHyuk Song, Radha Poovendran, Jicheol Lee, and Tetsua Iwata. The AES-CMAC Algorithm. RFC 4493. 2006. url: https://tools.ietf.org/html/rfc4493 (cit. on p. 46). [ST10] Yaron Sheer and Hannes Tschofenig. Internet Key Exchange Protocol Version 2 (IKEv2) – Session Resumption. RFC 5723. 2010. url: https://tools.ietf. org/html/rfc5723 (cit. on pp. 173, 175). [ST16] Mohamed Sabt and Jacques Traoré. Cryptanalysis of GlobalPlatform Secure Chan- nel Protocols. In: Security Standardisation Research. Ed. by Lidong Chen, David McGrew, and Chris Mitchell. Springer International Publishing, 2016, pp. 62–91 (cit. on pp. 23, 25). [Stö17] Volker Stöhr. Personal communication. 2017 (cit. on p. 76). [SZET08] Joseph Salowey, Hao Zhou, Pasi Eronen, and Hannes Tschofenig. Transport Layer Security (TLS) Session Resumption without Server-Side State. 2008. url: https: //tools.ietf.org/html/rfc5077 (cit. on pp. 173, 175). [SIM18] SIMalliance. SIMalliance Members Report Shipments of 4.9 Billion SIMs in 2017, while Estimated Total Available SIM Market in 2017 Increases 2.75% to 5.6 Billion Units. 2018. url: https://simalliance.org/media/press- releases/ simalliance-members-report-shipments/ (cit. on pp. 82, 95). [SSD] SSD Research Team. OPAL library. XLIM Labs, University of Limoges, France. url: https://bitbucket.org/ssd/opal (cit. on p. 93). [Sig16] Sigma Designs. Security 2 Command Class, version 0.9. 2016 (cit. on pp. 20, 25). [Sil18] Silicon Labs. Z-Wave Application Security Layer (S0). 2018 (cit. on pp. 20, 25). [Tie18] Andrew Tierney. Z-Shave. Exploiting Z-Wave downgrade attacks. Pen Test Part- ners. 2018. url: https://www.pentestpartners.com/security-blog/z- shave-exploiting-z-wave-downgrade-attacks/ (cit. on pp. 5, 20, 25). [TM12] Joe-Kai Tsay and Stig F. Mjølsnes. A Vulnerability in the UMTS and LTE Au- thentication and Key Agreement Protocols. In: Computer Network Security. Ed. by Igor Kotenko and Victor Skormin. Berlin, Heidelberg: Springer, 2012, pp. 65–76 (cit. on pp. 23, 25). [Tom19] Stefano Tomasin. Personal communication. 2019 (cit. on p. 75). Bibliography 219

[TPG15] Hannes Tschofenig and Manuel Pegourie-Gonnard. Performance of State-of- the-Art Cryptography on ARM-based Microprocessors. NIST Lightweight Cryp- tography Workshop 2015 Session VII: Implementations & Performance. 2015. url: https : / / csrc . nist . gov / csrc / media / events / lightweight - cryptography- workshop- 2015/documents/presentations/session7- vincent.pdf (cit. on p. 7). [Ttn] The Things Network Stack V2. url: https://github.com/TheThingsNetwork/ ttn/ (cit. on p. 55). [TZV17] Stefano Tomasin, Simone Zulian, and Lorenzo Vangelista. Security Analysis of LoRaWAN Join Procedure for Internet of Things Networks. In: IEEE Wireless Com- munications and Networking Conference Workshops. WCNCW 2017. IEEE, 2017, pp. 1–6 (cit. on p. 74). [Tex03] Texas instruments. MSP430 Ultra-Low-Power MCUs. 2003. url: http://vega. elo.utfsm.cl/~lsb/elo325/aplicaciones/ApplicatioNotes/slab034f. pdf (cit. on p. 6). [Unu] Roman Unuchek. Dvmap: the rst Android malware with code injection. 08/06/2017. url: https://securelist.com/dvmap- the- first- android- malware- with-code-injection/78648/ (cit. on p. 92). [Uri10] Pascal Urien. Introducing TLS-PSK authentication for EMV devices. In: 2010 In- ternational Symposium on Collaborative Technologies and Systems, CTS 2010. Ed. by Waleed W. Smari and William K. McQuay. IEEE, 2010, pp. 371–377. url: https://doi.org/10.1109/CTS.2010.5478489 (cit. on p. 13). [Vau02] Serge Vaudenay. Security Flaws Induced by CBC Padding - Applications to SSL, IPSEC, WTLS... In: EUROCRYPT 2002. Ed. by Lars R. Knudsen. Vol. 2332. LNCS. Springer, Heidelberg, 2002, pp. 534–546 (cit. on p. 95). [VBMP17] Jo Van Bulck, Jan Tobias Mühlberg, and Frank Piessens. VulCAN: Ecient Com- ponent Authentication and Software Isolation for Automotive Control Networks. In: Proceedings of the 33rd Annual Computer Security Applications Conference. AC- SAC 2017. ACM, 2017, pp. 225–237. url: http://doi.acm.org/10.1145/ 3134600.3134623 (cit. on p. 20). [VHSV11] Anthony Van Herrewege, Dave Singelée, and Ingrid Verbauwhede. CANAuth – A Simple, Backward Compatible Broadcast Authentication Protocol for CAN bus. In: ECRYPT Workshop on Lightweight Cryptography 2011. 2011 (cit. on p. 20). [VP16] Mathy Vanhoef and Frank Piessens. Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys. In: USENIX Security 2016. Ed. by Thorsten Holz and Stefan Savage. USENIX Association, Aug. 2016, pp. 673–688 (cit. on p. 25). [VP17] Mathy Vanhoef and Frank Piessens. Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2. In: ACM CCS 2017. Ed. by Bhavani M. Thuraisingham, David Evans, Tal Malkin, and Dongyan Xu. ACM Press, 2017, pp. 1313–1328 (cit. on pp. 20, 25). [VP18] Mathy Vanhoef and Frank Piessens. Release the Kraken: New KRACKs in the 802.11 Standard. In: ACM CCS 2018. Ed. by David Lie, Mohammad Mannan, Michael Backes, and XiaoFeng Wang. ACM Press, Oct. 2018, pp. 299–314 (cit. on pp. 20, 25). 220 Bibliography

[Wei91] Mark Weiser. “The Computer for the 21st Century”. In: Scientic American 265.3 (1991), pp. 66–75 (cit. on p. 4). [WGE+05] Arvinderpal S. Wander, Nils Gura, Hans Eberle, Vipul Gupta, and Sheueling Chang Shantz. Energy Analysis of Public-Key Cryptography for Wireless Sensor Networks. In: Proceedings of the Third IEEE International Conference on Pervasive Computing and Communications. PERCOM ’05. IEEE Computer Society, 2005, pp. 324–328. url: http://dx.doi.org/10.1109/PERCOM.2005.18 (cit. on p. 172). [Wor] LoRa Alliance Technical Committe Regional Parameters Workgroup (cit. on pp. 45, 53, 68, 69). [Wu00] Thomas Wu. The SRP Authentication and Key Exchange System. RFC 2945. 2000 (cit. on p. 112). [Yan17] Xueying Yang. LoRaWAN: Vulnerability Analysis and Practical Exploitation. 2017. url: https://repository.tudelft.nl/islandora/object/uuid:87730790- 6166 - 4424 - 9d82 - 8fe815733f1e / datastream / OBJ / download (cit. on p. 75). [Yeg17] Alper Yegin. LoRaWAN Backend Interfaces 1.0 Specication. LoRa Alliance, version 1.0, 11/10/2017. 2017. url: https://lora-alliance.org/resource- hub/lorawantm-back-end-interfaces-v10 (cit. on pp. 66, 70, 71, 77). [YKPH11] Huihui Yap, Khoongming Khoo, Axel Poschmann, and Matt Henricksen. EPCBC - A Block Cipher Suitable for Electronic Product Code Encryption. In: CANS 11. Ed. by Dongdai Lin, Gene Tsudik, and Xiaoyun Wang. Vol. 7092. LNCS. Springer, Heidelberg, Dec. 2011, pp. 76–97 (cit. on p. 6). [YL06a] Tatu Ylönen and Chris Lonvick. The Secure Shell (SSH) Authentication Protocol. RFC 4252. 2006. url: https://tools.ietf.org/html/rfc4252 (cit. on pp. 4, 84). [YL06b] Tatu Ylönen and Chris Lonvick. The Secure Shell (SSH) Connection Protocol. RFC 4254. 2006. url: https://tools.ietf.org/html/rfc4254 (cit. on pp. 4, 84). [YL06c] Tatu Ylönen and Chris Lonvick. The Secure Shell (SSH) Protocol Architecture. RFC 4251. 2006. url: https://tools.ietf.org/html/rfc4251 (cit. on pp. 4, 84). [YL06d] Tatu Ylönen and Chris Lonvick. The Secure Shell (SSH) Transport Layer Protocol. RFC 4253. 2006. url: https://tools.ietf.org/html/rfc4253 (cit. on pp. 4, 84). [ZF05] Muxiang Zhang and Yuguang Fang. “Security analysis and enhancements of 3GPP authentication and key agreement protocol”. In: IEEE Transactions on Wireless Communications 4.2 (2005), pp. 734–742 (cit. on pp. 23, 25). [Zig14] ZigBee Alliance. ZigBee specication. 2014. url: http://www.zigbee.org/ download/standards-zigbee-specification/ (cit. on pp. 19, 25, 140). List of Figures

1.1 Protocols for constrained devices: current situation and expectations . . . . .9 1.2 Pre-accept and post-accept phases in a key establishment protocol ...... 10 1.3 The main properties of the AKE and ACCE security models ...... 11 1.4 The AKEP2 protocol ...... 12 1.5 The FORSAKES protocol ...... 13 1.6 The Kerberos v5 protocol ...... 14 1.7 The key establishment in TLS 1.2 protocol in PSK mode ...... 15 1.8 The key establishment in TLS 1.3 protocol in PSK mode ...... 16 1.9 The key establishment in SCP02 protocol ...... 17 1.10 The O-FRAKE protocol ...... 18 1.11 The key establishment in SPINS protocol ...... 19 1.12 The key establishment in WPA2 protocol ...... 21

2.1 The Encrypt and Decrypt oracles in the sAE (RoR) security experiment . . . . 35 2.2 The Encrypt and Decrypt oracles in the sAE (LoR) security experiment . . . . 35 2.3 The Encrypt and Decrypt oracles in the ACCE security experiment ...... 39

3.1 Worlwide map of LoRa networks in May 2017 ...... 46 3.2 LoRaWAN network in version 1.0 ...... 47 3.3 Correct execution of LoRaWAN 1.0 ...... 48 3.4 Generation of an application frame in LoRaWAN 1.0 ...... 49 3.5 “Replay or decrypt” attack against ED ...... 52 3.6 Desynchronisation attack against ED ...... 58 3.7 Attack on data integrity ...... 61 3.8 LoRaWAN network in version 1.1 ...... 64 3.9 Correct execution of LoRaWAN 1.1 ...... 66 3.10 Application session key derivation and keystream computation in LoRaWAN 1.1 72

4.1 Encryption and MAC computation of a command data with SCP02 ...... 83 4.2 Distribution of the number of cases depending on the padding validity . . . . 87 4.3 Distribution of the response times for Card B ...... 88 4.4 Padding oracle attack targeting an UICC ...... 91

5.1 The six instances involved in a correct 3-AKE run ...... 104 5.2 Impersonation of ED to NS based on a weak protocol between NS and JS . . . 106 5.3 The Encrypt and Decrypt oracles in the 3-ACCE security experiment . . . . . 108 5.4 3-ACCE protocol Π ...... 112 5.5 Correct execution of protocol Π ...... 113 6.1 Master key chains in SAKE ...... 144 6.2 SAKE protocol ...... 147 6.3 Diagram of SAKE ...... 150 6.4 SAKE-AM protocol ...... 157 6.5 SAKE/SAKE-AM executed between an end-device and a back-end server . . . 158

7.1 Connection between ED, AS and CS ...... 165 7.2 2-AKE run executed between ED and KS ...... 168 7.3 2-AKE run executed between ED and AS/CS ...... 170 7.4 Chains of keys used to compute a ticket ...... 174 7.5 Key chains in SAKE ...... 176 7.6 Resuming a chain of intermediary keys ...... 177 7.7 Storage of a ticket ...... 178 7.8 Session Resumption with SAKE-R initiated by ED ...... 179 7.9 Session Resumption with SAKE-R initiated by XS ...... 180 List of Tables

1.1 Comparison of symmetric and asymmetric operations on constrained chips . .6 1.2 Comparison of several key exchange protocols ...... 25

3.1 Attacks against LoRaWAN 1.0 ...... 62

4.1 Experimental results for the padding oracle attack ...... 94

6.1 Comparison between several schemes aiming at ensuring forward secrecy . . 143 6.2 Possible values for (iA, iB) in SAKE ...... 149 6.3 Possible values for δAB and (cA, cB) in SAKE ...... 151

List of Algorithms

4.1 Regular padding oracle attack ...... 86 4.2 Padding oracle attack based on the card response time ...... 90

LATEX thesis template: https://github.com/rbost/thesis_template.

Titre : Tunnels sécurisés pour environnements contraints

Mot clés : cryptanalyse, cryptographie à clé symétrique, protocole d’échange de clé authentiﬁé, modèle de sécurité, Internet des Objets.

Resumé : Avec l’extension de l’Internet des Objets et tocoles d’échange de clé entre deux et trois par- l’usage croissant de terminaux à bas coût, de nom- ties et décrivons des modèles de sécurité permettant breux protocoles de sécurité sont déployés à grande de saisir leurs propriétés et de les analyser. Nos échelle. protocoles mettent uniquement en œuvre des fonc- Cette thèse étudie le champ des protocoles tions symétriques. En même temps, ils garantissent d’échange de clé authentiﬁé basés sur des fonctions des propriétés de sécurité plus fortes que les pro- cryptographiques symétriques. Nous montrons que tocoles similaires. En particulier, ils garantissent la les protocoles existants n’atteignent pas un niveau de propriété de conﬁdentialité persistante et permettent sécurité correspondant à l’état de l’art en matière de l’usage de reprises de session. Cela est particulière- protocoles cryptographiques. Nous décrivons des at- ment avantageux pour des terminaux disposant de taques pratiques contre deux tels protocoles actuelle- peu de ressources en termes de calcul, de mémoire ment utilisés. Nous présentons de nouveaux pro- et d’énergie.

Title: Secure Tunnels for Constrained Environments

Keywords: Cryptanalysis, Symmetric-key cryptography, Authenticated key exchange, Security models, Internet of Things.

Abstract: With the rise of the Internet of Things and cases, and describe suitable security models that al- the growing popularity of constrained devices, several low capturing their security goals, and analysing them. security protocols are widely deployed. Our protocols apply only symmetric-key functions. At In this thesis, we investigate the ﬁeld of authenti- the same time, they provide stronger security proper- cated key exchange protocols in the symmetric-key set- ties than comparable ones. In particular, they guaran- ting. We show that existing protocols do not achieve tee forward secrecy, and enable applying a session re- the most established levels of security properties, and sumption procedure. This is particularly advantageous describe practical attacks against two currently de- for low-resources devices with limited capabilities in ployed protocols. We present new authenticated key terms of computation, memory, and energy. exchange protocols for the 2-party and the 3-party