Intégration du protocole TLS basé sur la cryptographie à ... · Sigles et Abréviations AC : Autorité de Certiﬁcat6,28–31 AES : Advanced Encryption Standard14,26,30,34 CBC

RÉPUBLIQUE DU BÉNINMINISTÈRE DE L’ENSEIGNEMENT SUPÉRIEUR

ET DE LA RECHERCHE SCIENTIFIQUE

UNIVERSITÉ D’ABOMEY-CALAVI

INSTITUT DE FORMATION ET DERECHERCHE EN INFORMATIQUE

BP 526 Cotonou Tel : +229 21 14 19 88http://www.ifri-uac.net Courriel : [email protected]

MÉMOIREpour l’obtention du

Diplôme de Licence en Informatique

Option : Sécurité Informatique

Présenté par :Abdias DAGBEKPO

Intégration du protocole TLS basé sur lacryptographie à courbes elliptiques dans

un système de prises intelligentes

Sous la supervision :Dr Ing. Vinasétan Ratheil HOUNDJI

Ing. Probus KIKI

Année Académique : 2017-2018

http://www.ifri-uac.net

mailto:[email protected]

Table des matières

Sigles et Abréviations v

Glossaire vii

Dédicace ix

Remerciements x

Résumé/Abstract xi

Introduction 11 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Contexte et Justification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Organisation du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1 Revue de Littérature 31 L’environnement des prises intelligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1 Concept de prise intelligente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Protocoles de communication utilisés dans les systèmes de prises intelligentes 4

2 Présentation du protocole TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1 Architecture du protocole TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Le Record Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Le Change Cipher Spec Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Le Handshake Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 La Cryptographie à Courbes Elliptiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1 Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Echange de clés ECDH (Elliptic Curve Diffie-Hellman) . . . . . . . . . . . . . . 193.3 TLS Handshake avec l’ECDHE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 Signature digitale avec l’ECDSA (Elliptic Curve Digital Signature Algorithm) . 203.5 Avantages de ECC par rapport aux autres cryptosystèmes . . . . . . . . . . . . 20

2 Solution et choix techniques 241 Matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.1 L’esp8266 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.2 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.3 La librairie BearSSL et les librairies esp8266 importantes . . . . . . . . . . . . . 251.4 Ionic Cordova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

i

TABLE DES MATIÈRES TABLE DES MATIÈRES

1.5 L’application android MPlug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.6 Le plugin cordova-plugin-advanced-http . . . . . . . . . . . . . . . . . . . . . . 261.7 Openssl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2 Mise en place du système M-Plug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.1 Fonctionnement du système - Architecture de base . . . . . . . . . . . . . . . . 272.2 Fonctionnement du système - Architecture sécurisée . . . . . . . . . . . . . . . 27

3 Résultats et Discussions 331 Analyse de paquets du système M-Plug non sécurisé . . . . . . . . . . . . . . . . . . . 332 Analyse de paquets du système M-Plug sécurisé . . . . . . . . . . . . . . . . . . . . . . 34

2.1 Observations de l’échange de clés dans le système M-Plug . . . . . . . . . . . . 342.2 Observations des données applicatives dans le système M-Plug . . . . . . . . . 342.3 Observations des réactions du client M-Plug face à une attaque MiTM . . . . . 35

3 Discussions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Conclusion 37

Bibliographie 38

Webographie 40

ii

Table des figures

1.1 Modèle de demande/réponse du protocole HTTP (HyperText Transfert Protocol) / 1.1[12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Pile du protocole TLS (Transport Layer Security) [14] . . . . . . . . . . . . . . . . . . . 71.3 Fonctionnement du "Record Protocol" [14] . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Le TLS Record Format [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.5 Payload du "Record Protocol" [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.6 Le Handshake Protocol en action [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.7 Une courbe elliptique avec des points [10] . . . . . . . . . . . . . . . . . . . . . . . . . . 161.8 Addition de points sur une courbe elliptique [6] . . . . . . . . . . . . . . . . . . . . . . 171.9 Doublage d’un point sur une courbe elliptique [6] . . . . . . . . . . . . . . . . . . . . . 181.10 Fonctionnement du ECDH (Elliptic Curve Diffie-Hellman) [6] . . . . . . . . . . . . . . 201.11 TLS Handshake avec ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)[7] . . . . . . 21

2.1 L’esp8266-esp12E [23] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2 Interface de l’application MPlug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3 Architecture de base du système M-Plug . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.4 Architecture sécurisée du système M-Plug . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.1 Analyse des paquets du système M-Plug non sécurisé . . . . . . . . . . . . . . . . . . . 343.2 Analyse des paquets (Handshake) du système M-Plug sécurisé . . . . . . . . . . . . . 353.3 Analyse de paquets (Application Data) du système M-Plug sécurisé . . . . . . . . . . . 353.4 Analyse de paquets (Attaque MiTM (Man In The Middle)) du système M-Plug sécurisé 36

iii

Liste des tableaux

1.1 Algorithmes permis dans le chiffrement du message compressé + le MAC [14] . . . . . 81.2 Types de messages du "TLS Handshake Protocol" [14] . . . . . . . . . . . . . . . . . . . 151.3 Cryptosystèmes à clé publique connus [7] . . . . . . . . . . . . . . . . . . . . . . . . . . 221.4 Comparaison ECC vs RSA/DSA/DH [7] . . . . . . . . . . . . . . . . . . . . . . . . . . 22

iv

Sigles et Abréviations

AC : Autorité de Certificat 6, 28–31AES : Advanced Encryption Standard 14, 26, 30, 34

CBC : Cipher Block Chaining 8, 14, 29, 30COAP : Constrained Application Protocol 5CSR : Certificate Signing Request 30

DES : Data Encryption Standard 14, 26DH : Diffie-Hellman xi, xii, 14DSA : Digital Signature Algorithm 26, 34DTLS : Datagram Transport Layer Security 15

ECC : Elliptic Curve Cryptography 15–18, 21, 22, 26, 29, 30ECDH : Elliptic Curve Diffie-Hellman iii, 13, 14, 16, 19, 20, 29ECDHE : Elliptic Curve Diffie-Hellman Ephemeral iii, 16, 19, 21, 34ECDSA : Elliptic Curve Digital Signature Algorithm 16, 26, 29, 34

GCM : Galois Counter Mode 34

HTTP : HyperText Transfert Protocol iii, 4, 5, 9, 27, 31, 33, 36HTTPS : HyperText Transfert Protocol Secure 31

IDEA : International Data Encryption Algorithm 14, 26IOT : Internet Of Things xi, xii, 1, 4–6, 22

MAC : Message Authentication Code 7, 8, 10, 11, 13MD5 : Message Digest 5 14, 26MiTM : Man In The Middle iii, 6, 26, 30, 31, 33–36MQTT : Message Queue Telemetry Transport 5, 9

v

Sigles et Abréviations Sigles et Abréviations

PKC : Public Key Cryptography 6PSK : Pre Shared Key 6

RC : Rivest Cipher 26RSA : Rivest Shamir Adleman xi, xii, 13, 14, 26

S/MIME : Secure/Multipurpose Internet Mail Extensions 26SHA : Secure Hash Algorithm 14, 26, 34SSL : Secure Socket Layer 5

TLS : Transport Layer Security iii, iv, xi, xii, 2, 3, 5–12, 15, 19, 23, 25–27,30, 31, 33, 34, 36

vi

Glossaire

Autorité de certificat :

Une autorité de certificat est une autorité dans un réseau qui délivre et gère les informationsd’identification sécurisée et les clés publiques pour le chiffrement des messages. 10, 27–29, 31,37

Certificat numérique :

Un certificat numérique fournit le moyen de prouver l’identité d’une personne dans le cadre detransactions électroniques. 6, 7, 10, 11, 14, 26, 28–31, 37

Chiffrement :

Le chiffrement est le processus de codage des messages (ou informations) de manière à ceque les espions ou les pirates informatiques ne puissent les lire, mais les parties autoriséesle peuvent. 7, 8, 10, 11, 13–15, 25, 26, 34

Chiffrement par bloc :

Un chiffrement par bloc est une méthode de chiffrement de texte dans lequel une clé cryptogra-phique et un algorithme sont appliqués à un bloc de données (par exemple, 64 bits contigus) àla fois en tant que groupe. 8, 14

Chiffrement par flux :

Un chiffrement par flux est une méthode de chiffrement de texte dans lequel une clé cryptogra-phique et un algorithme sont appliqués à chaque bit d’un flux de données, un bit à la fois. 8,14

Chiffrement symétrique :

Le chiffrement à clé symétrique est une classe d’algorithmes qui utilisent la même clé crypto-graphique pour le chiffrement du texte clair et le déchiffrement du texte chiffré. 8

Clé cryptographique :

Une clé est un paramètre qui détermine la sortie fonctionnelle d’un algorithme cryptogra-phique. 6–8, 11–16, 19, 20, 26, 28–30, 37

Cryptographie :

La cryptographie est une science qui se sert de la logique mathématique pour permettre à n’im-porte qui de stocker de façon sécurisée des informations sensibles ou de transmettre des infor-

vii

Glossaire Glossaire

mations en toute sécurité à travers des canaux non sécurisés pour empêcher qu’elles soientpiratées ou modifiées. 2, 15, 16, 23, 37

Cryptographie symétrique :

La cryptographie symétrique (ou chiffrement à clé symétrique) est une classe d’algorithmes quiutilisent la même clé cryptographique pour le chiffrement du texte clair et le déchiffrement dutexte chiffré. 6

Cryptosystème :

Un cryptosystème est une paire d’algorithmes qui prennent une clé et convertissent un messageclair en un message chiffré et inversement. 18, 20–23, 37

Déchiffrement :

Il s’agit du processus de décodage du texte chiffré et pour le récupérer sous le format du texteclair. 26

Signatures numériques :

Une signature numérique (ou digitale) est une technique qui est utilisée pour authentifierl’identité de l’expéditeur d’un message ou d’un document, et éventuellement pour assurer quele contenu original du message envoyé reste inchangé. 11, 14, 16, 20, 21, 26, 29, 31, 34

viii

Dédicace

A ma mère Affousatou OLOUDEA mon père Ambroise DAGBEKPO

A mon frère Aquilas DAGBEKPOA ma famille, mes frères qui ne m’ont pas laissé tomber

A ma seconde famille, celle de Calavi, des personnes formidablesA tous ceux qui œuvrent activement pour le développement des sciences informatiques en Afrique et

particulièrement au Bénin.

ix

Remerciements

Mes remerciements s’adressent en premier lieu à Dieu le Tout Puissant, de m’avoir donné son soufflede vie, la force et le courage d’aller jusqu’au bout sans douter de mes compétences.

Je tiens particulièrement à remercier :

• l’administration de l’IFRI.

• ma famille et mes frères, pour tout le soutien et l’encouragement dont elle a fait preuve à monégard durant ces trois années de formation à l’IFRI et durant toute la rédaction du mémoire ;

• mes proches et amis à Calavi, tous ceux qui se sont inquiétés pour moi et m’ont donné ducourage quand les situations étaient difficiles ;

• monsieur Ratheil HOUNDJI, notre maître de mémoire pour sa disponibilité, son accompagne-ment et son soutien dans la réalisation de ce mémoire ;

• monsieur Probus KIKI, mon maître de stage et madame Marianne BALOGOUN DirectriceTechnique chez MiFY-Sarl ;

• toute l’administration de MiFY et les stagiaires avec qui j’ai fait mon parcours ;

• monsieur Lionel METONGNON, pour ses conseils sur certains aspects techniques de mon tra-vail ;

• Wallis KASSIWIN, Gary DJOGBENOU, Parmely ZANTOU, Iffanice HOUNDAYI, Isdine BOU-RAIMA qui m’ont été d’un grand soutien technique durant tout ce travail ;

• Ben-Sirac DJOSSOU, Dorcas ADJIBI, Seth HOUANSOU, Biblis ABATTI, Sunday ADEMON-SOU, Hillary LAMISSI, Romaric DOSSOU-YOVO, Oulfath ADJAO, Lauryne JOSIAS-DADY, Is-mène DEGUENONVO, Théophile HOUESSOU, Bégis-Pascal DAGBEHOU qui m’ont été d’ungrand soutien moral durant toute la rédaction ;

x

RésuméL’IOT (Internet Of Things) est la nouvelle tendance technologique qui vise à simplifier la vie aumoyen de capteurs et d’appareils intelligents. Le développement rapide de la domotique, a favoriséle déploiement des prises intelligentes dans des millions de foyers à travers le monde entier. Cesprises intelligentes offrent des fonctionnalités intéressantes à leurs utilisateurs. Il est possible de lescontrôler et de les configurer pour répondre à nos préférences, à nos besoins. Les données manipu-lées par les prises intelligentes sont d’une haute sensibilité et peuvent être source d’informations ausujet de la vie privée des utilisateurs . Il est donc important d’implémenter les mécanismes de sécu-rité adéquats en vue de s’assurer que ces données sont manipulées et transmises en toute sécurité ; etque seules les personnes autorisées puissent y accéder. Le protocole TLS a été conçu, pour permettrede sécuriser des données n transit dans un canal non securisé. Ce travail vise à intégrer le proto-cole TLS dans une architecture existante d’un système de prises intelligentes. Les modules utilisés,étant de faible capacité, il est important de déployer TLS en minimisant son impact sur les perfor-mances du système. Dans ce but, la cryptographie à courbes elliptiques est préférée, contrairementaux algorithmes populaires tels que RSA (Rivest Shamir Adleman), DH (Diffie-Hellman), pour lesopérations d’échange de clés et de signature digitale effectuées par TLS. Les différents résultats obte-nus montrent que le protocole TLS combiné aux avantages de la cryptographie à courbes elliptiquesreprésentent le futur en matière de sécurité et de performance, des environnements à ressources li-mitées.

Mots clés : Internet des objets, prises intelligentes, Sécurité des données, TLS, Cryptographie àcourbes elliptiques, environnement à ressources limitées

xi

AbstractIOT is the new technology trend that aims to simplify life with smart sensors and devices. The rapiddevelopment of home automation has fostered the deployment of smart plugs in millions of homesaround the world. These smart plugs offer interesting features to their users. It is possible to controland configure them to suit our preferences, our needs. The data handled by smart plugs is of highsensitivity and can be a source of information about the privacy of users. It is therefore importantto implement the appropriate security mechanisms to ensure that these data are handled and trans-mitted securely; and only authorized people can access it. The TLS protocol has been designed tohelp secure data n transit in an unsecured channel. This work aims to integrate the TLS protocolinto an existing architecture of a smart plug system. Since the modules used are of low capacity, itis important to deploy TLS while minimizing its impact on system performance. For this purpose,elliptic curves cryptography is preferred, unlike popular algorithms such as RSA, DH, for key ex-change and digital signature operations performed by TLS. The various results obtained show thatthe TLS protocol combined with the advantages of elliptic curves cryptography represent the futurein terms of security and performance, resource-limited environments.

Key words: Internet of Things, Smarts plugs, Data security, TLS, Elliptic curves cryptography,limited ressources environments

Introduction

Les progrès enregistrés dans le domaine des semi-conducteurs ont permis une meilleure inté-gration de supports de réseau sans fil dans les processeurs et capteurs intégrés, ce qui a donné ungrand coup de pouce à l’industrie de l’IOT (appelé l’industrie 4.0) [5]. L’IOT est défini commel’interconnexion en réseau, de plusieurs objets du quotidien. Le succès de l’IOT auprès du grandpublic, nous a mené à divers concepts plus innovants, plus simples et plus adaptés aux besoins desutilisateurs dont les systèmes de prises intelligentes. Ces systèmes permettent aujourd’hui, à leursutilisateurs, de la souplesse dans la façon de gérer leurs appareils ménagers et de contrôler leur con-sommation en énergie. Ils ne peuvent malheureusement, pas toujours garantir aux utilisateurs leurvie privée et la sécurité dans l’utilisation du système.

1 Problématique

Dans un système de prises intelligentes, l’utilisateur a le loisir de contrôler l’état(allumé/éteint)de tous les appareils qui sont branchés à un smart plug. Ce contrôle peut être éffectué depuis unsmartphone via une application android ou depuis son ordinateur via un navigateur web. Toutesles communications peuvent être lues, modifiées et même détournées si le système ne présente pasune sécurité adéquate. Comment empêcher une personne malveillante de lire et de modifier lescommandes envoyées par l’utilisateur à un smart plug ? Comment s’assurer que tous les acteurs dusystème sont bien ceux qu’ils prétendent être et qu’on est pas victime d’une usurpation? Commentêtre sûr que seuls les acteurs autorisés profitent des ressources du système ? Et surtout, commentgarantir la sécurité à moindre coût ? Toutes ces préoccupations sus-citées serviront à orienter notretravail, qui sera de garantir la sécurité dans l’utilisation de notre système de prises intelligentes.

2 Contexte et Justification

Au Bénin, la domotique et le concept d’objets connectés ne sont pas encore grand public. Ceci estdû en partie à la faible capacité financière des habitants pour s’octroyer des équipements qu’il fautafin d’apporter un peu de commodité à leur maison; et aussi au coût de l’électricité et aux difficultésd’accès à l’internet. Tenant compte de tous ces facteurs, l’entreprise MIFY(Machine Intelligence ForYou) a mis en place le projet M-Plug. M-Plug est un système de prises intelligentes contrôlé depuisl’interface d’une application android, offrant aux populations plus de commodité dans leur quoti-

1

dien, sans aucun besoin d’accès à l’internet. Néanmoins, l’introduction des systèmes M-Plug au seindes foyers peut présenter divers risques quant à la sécurité des utilisateurs, comme l’utilisation nonautorisée de leurs équipements, l’accès au données concernant leur vie privée (habitudes d’utilisationdes équipements). Il est donc vital de réfléchir aux mécanismes de sécurité à mettre en place sur lesystème M-Plug afin d’assurer aux populations une utilisation sûre et exempt de risques de sécuritédes systèmes M-Plug.

3 Objectifs

L’objectif principal de notre travail est de garantir un niveau de sécurité au niveau des échanges àl’intérieur du système. Pour cela, nous nous fixons les objectifs spécifiques suivants:

• la confidentialité des données échangées dans le système;

• l’intégrité des données échangées;

• l’établissement d’un dispositif de confiance entre les appareils du système;

• l’authentification de chaque appareils clients dans le système;

• l’utilisation minimale de ressources afin de maintenir la fluidité sur le réseau.

4 Organisation du mémoire

Le présent travail sera structuré en trois chapitres. Dans un premier chapitre, nous parlerons deprises intelligentes et des protocoles de communication qu’ils utilisent, du fonctionnement généraldu protocole TLS et de présenter le principe de la Cryptographie à courbes elliptiques, des algo-rithmes basés sur cette dernière. Un deuxième chapitre sera l’occasion de faire le point sur le matérielque nous utilisons dans notre système, la présentation du système M-Plug et des différentes opéra-tions techniques faites en vue de sa sécurité. Dans le dernier chapitre, nous présentons et analysonsles résultats obtenus après implémentation de nos solutions.

Chapitre 1Revue de Littérature

Introduction

Pour mener à bien notre projet, il est important de faire le tour des concepts clés qui y apparaissent etde présenter l’état actuel des recherches sur le sujet. Nous parlons dans ce chapitre, de systèmes deprise intelligentes et leurs protocoles de communication. Nous présentons le protocole TLS qui est leprotocole majeur utilisé dans la sécurité de ces systèmes.

1 L’environnement des prises intelligentes

Dans cette section, nous nous intéressons à l’environnement d’un système de prise intelligentesainsi qu’aux protocoles de communication qu’il utilise.

1.1 Concept de prise intelligente

Les objets connectés n’ont pas besoin d’être complexes pour être utiles. Nous avons en exemplela prise intelligente qui est un gadget qui permet simplement d’alimenter ou non en énergie élec-trique d’autres appareils qui lui sont reliés. Cette simple fonctionnalité, quand elle est intégrée à unearchitecture de maison intelligente peut vite faire de la prise intelligente, un objet très polyvalent[20].

1.1.1 Fonction d’une prise intelligente

La prise intelligente est reliée à une prise murale et directement contrôlée par une application mobileou une application web. Il permet alors le contrôle à distance de tout appareil qui lui est relié mêmelorsque vous n’êtes pas dans la pièce ou même dans la maison. Les prises M-Plug, vous permettentaussi d’activer votre prise intelligente pour qu’elle fonctionne à des heures spécifiques et même pourqu’elle imite votre modèle d’utilisation quand vous n’êtes pas là. Vous pouvez l’utiliser avec unelampe, une télévision, un décodeur, une machine à café, à votre guise [21].

1.1.2 Rôle d’une prise intelligente dans une maison

La prise intelligente présente de nombreuses utilités.

3

Chapitre 1. Revue de Littérature 1. L’environnement des prises intelligentes

• Sécurité : Lorsqu’on relie une lampe à une une prise intelligente, celle-ci devient une lampeintelligente offrant des avantages en matière de sécurité domestique. Vous pouvez programmervotre lampe pour s’allumer à certaines heures ou lorsque vous êtes en route pour chez vous, ouencore elle peut même être déclenché par un autre appareil, tel qu’un détecteur de mouvementou une alarme qui retentit pour dissuader un intrus [20].

• Commodité : Les prises intelligentes sont idéales pour automatiser vos appareils.Avec des ho-raires déjà programmés, vos appareils s’exécutent sans aucune intervention [21].

• Économie d’énergie : Une prise intelligente peut réduire votre facture d’énergie en éteignantautomatiquement les appareils tels que votre téléviseur et votre décodeur, qui consomment del’énergie en mode veille lorsque vous n’êtes pas à la maison [20].

1.2 Protocoles de communication utilisés dans les systèmes de prises intelligentes

Les systèmes de prise intelligentes utilisent toujours des protocoles bien définis pour gérer lescommunications entre les différents modules du système. Nous présentons dans la suite, les diffé-rents protocoles de communication qui existent et que l’on peut utiliser dans un système de priseintelligente.

1.2.1 HTTP

HTTP est sans doute le protocole le plus important pour Internet tel que nous le connaissons au-jourd’hui [12].HTTP utilise un modèle classique de communication requête/réponse (figure 1.1), qui permet auclient d’envoyer des données au serveur et de recevoir une réponse une fois le traitement terminécôté serveur. Alors que ce modèle est un ajustement parfait pour le web (un client peut demanderune page Web et le serveur fournit la page), les communications IOT événementielles avec HTTP nesont pas optimales pour les messages lancés par le serveur, car il n’existe pas de moyen standardd’envoyer des messages en tant que serveur. Des solutions de contournement telles que les longuesinterrogations et les nouveaux protocoles tels que les websockets ont été inventés au fil des ans pourrésoudre certains de ces problèmes.HTTP est un protocole flexible protocole. Ceci est dû à la possibilité d’ajouter des en-têtes arbitraires

FIGURE 1.1 – Modèle de demande/réponse du protocole HTTP / 1.1 [12]

4

Chapitre 1. Revue de Littérature 2. Présentation du protocole TLS

à toute demande et à toute réponse. Il existe de nombreux en-têtes normalisés universellement ac-ceptés tels que l’authentification, le contrôle du cache, et préférences du client pour l’encodage et lalangue de la réponse Les en-têtes HTTP sont largement utilisés pour le web par les navigateurs Webet les serveurs Web (par exemple, pour les cookies et les indications d’agents utilisateur). Chaqueréponse HTTP contient des codes de réponse universellement acceptés et normalisés qui indiquentsi la demande a abouti ou si une erreur s’est produite. Ces codes d’erreur indiquent la cause premièredu problème et le client peut prendre les mesures appropriées après avoir interprété la réponse. Lescodes de réponse sont classés et le premier chiffre du code de réponse représente une catégorie [14].

Les méthodes HTTPChaque requête HTTP contient une méthode HTTP qui oblige le serveur à prendre une mesure spé-cifique. Les méthodes HTTP les plus courantes utilisées pour le web et pour les API HTTP sont sansdoute GET et POST. Les méthodes HTTP restantes sont plus couramment utilisées dans les API RES-Tful. Il est important de noter que tous les serveurs Web n’autorisent pas toutes les méthodes HTTPpour une ressource spécifique [14].

1.2.2 MQTT - Message Queue Telemetry Protocol

Le protocole MQTT (Message Queue Telemetry Transport) est un protocole de communication uti-lisant un modèle de "publication/abonnement" avec la version 3.1.1 définie comme norme ISO/IEC20922 :2016. Le protocole est conçu pour une efficacité maximale et une communication sans pertesur des réseaux à perte, un cas d’utilisation courant de l’IOT.MQTT est un protocole très simple et flexible. Il est adapté pour les appareils limités et est égalementpopulaire pour les applications mobiles. La seule exigence pour MQTT est TCP en tant que protocolede transport.[14] TLS peut éventuellement être utilisé pour chiffrer le canal de communication. Leriche ensemble de fonctionnalités, les caractéristiques d’évolutivité, l’écosystème actif et le supportétendu des plateformes IOT propriétaires ont positionné MQTT en tant que protocole IOT importantpour une variété de cas d’utilisation.

1.2.3 CoAP - Constrained Application Protocol

Le protocole COAP (Constrained Application Protocol) est un protocole de transfert Web conçupour les périphériques et les réseaux soumis à des contraintes. Il s’agit d’un standard ouvert de l’IETF(RFC 7252) qui prend en charge différentes extensions de protocole, également reconnues par l’IETF.COAP est basé sur un modèle de communication demande/réponse similaire à HTTP et prend encharge des fonctionnalités supplémentaires de protocoles utiles dans les scénarios IOT.[14] Le casd’utilisation le plus répandu de COAP concerne les réseaux de capteurs câblés et sans fil. Il est basésur UDP, mais supporte des mécanismes de transport alternatifs via des extensions. En raison de sonutilisation fréquente dans les réseaux restreints et locaux, COAP est souvent mandaté via HTTP afinde convenir au transfert de données sur Internet.

2 Présentation du protocole TLS

Le protocole TLS (Transport Layer Security) a vu le jour en 1995 lorsque Netscape, développeurdu navigateur Netscape, a mis au point son ancêtre, le protocole SSL (Secure Socket Layer).

5


TLS protège les connexions entre les serveurs et les applications clientes en établissant un canal sécu-risé entre eux afin de garantir que les données transférées soient confidentielles, authentifiées et nonmodifiées [13].TLS est agnostique par application ; ceci veut dire qu’il ne se soucie pas du type de contenu crypté[13].L’un des objectifs de sécurité de TLS est de prévenir les attaques MiTM, dans lequel un attaquantintercepte le traffic chiffré provenant de l’émetteur, déchiffre le traffic pour capturer le contenu enclair et le rechiffre avant de l’envoyer à la partie destinataire. TLS combat les attaques de l’homme dumilieu en authentifiant les serveurs (et éventuellement les clients) à l’aide de certificats numériquesdélivrés par des AC (Autorité de Certificat) de confiance [13].Pour garantir une large adoption, TLS devait satisfaire à quatre exigences supplémentaires : être effi-cace, interopérable, extensible et polyvalent [13].TLS prend en charge trois approches principales.

• La première approche, la plus courante, est que le serveur possède un Certificat numérique etle client non. Dans ce modèle, le client s’authentifiera une fois le flux chiffré lancé, en utilisantun autre mécanisme d’authentification tel qu’un nom d’utilisateur/mot de passe ou un jeton.

• La deuxième approche est que le client et le serveur ont tous deux des certificats, on parlede "Mutual TLS". Cela pose un défi car la distribution et la gestion des certificats numériquesclients sont coûteux et complexes. Dans les scénarios IOT, cela signifie que le client doit mettreà jour ses certificats numériques à l’expiration de ceux-ci.

• La troisième approche consiste à utiliser une Clé cryptographique pré-partagée (TLS PSK (PreShared Key)) qui signifie qu’au lieu d’utiliser une PKC (Public Key Cryptography), le systèmerevient à la Cryptographie symétrique. Cela présente un gros avantage pour l’IOT en termesde performances. Comme évoqué précédemment, mais la PKC est chère. Le PSK évite cela.Cependant, distribuer des clés cryptographiques uniques et sécurisées sur les périphériques etveiller à ce qu’elles ne soient pas volées est encore plus complexe et coûteux que l’émission decertificats numériques clients.

2.1 Architecture du protocole TLS

TLS est conçu pour utiliser TCP afin de fournir un service fiable, sécurisé de bout en bout. TLS n’estpas un protocole unique, mais plutôt deux couches de protocoles, comme illustré dans la figure 1.2.Le Record Protocol fournit des services de sécurité de base à divers protocoles de couche supérieure.Trois protocoles de couche supérieure sont définis dans le cadre de TLS : le Handshake Protocol,le Change Cipher Spec Protocol, et le Alert Protocol. Ces protocoles sont spécifiques à TLS et sontutilisés dans la gestion des échanges TLS.Une session TLS et une connexion TLS sont deux concepts importants, définis dans la spécificationcomme suit :

• Connexion : Une connexion est un transport (dans la définition du modèle de stratification OSI)qui fournit un type de service approprié. Pour TLS, ces connexions sont des relations d’égal àégal. Les connexions sont transitoires. Chaque connexion est associée à une session.

• Session : Une session TLS est une association entre un client et un serveur. Les sessions sontcréées lors du Handshake Protocol. Les sessions définissent un ensemble de paramètres de

6


FIGURE 1.2 – Pile du protocole TLS [14]

sécurité, qui peuvent être partagés entre plusieurs connexions. Les sessions sont utilisées pouréviter la négociation coûteuse de nouveaux paramètres de sécurité pour chaque connexion.

Un certain nombre d’états sont associés à chaque session. Une fois la session établie, il existe unétat de fonctionnement courant pour la lecture et l’écriture (c’est-à-dire réception et envoi). De plus,pendant le Handshake Protocol, des états de lecture et d’écriture sont créés en attente. Une fois ceprotocole conclu avec succès, les états en attente deviennent les états courants. Un état de session estdéfini par les paramètres suivants :

• Session identifier : Séquence d’octets arbitraires choisie par le serveur pour identifier un étatde session actif ou pouvant être repris.

• Peer certificate : Un Certificat numérique X509.v3 de l’homologue. Cet élément peut être nul.

• Compression method : L’algorithme utilisé pour compresser les données avant le chiffrement.

• Cipher specifications : Spécifie l’algorithme de Chiffrement de données en bloc (tel que 3DES,AES, etc..) et un algorithme de hachage (tel que MD5,SHA2 etc..) utilisé pour le calcul MAC(Message Authentication Code).Il définit également des attributs cryptographiques tels que lataille du hash.

• Master secret : Un secret de 48 octets partagé entre le client et le serveur.

• Is resumable : Un indicateur indiquant si la session peut être utilisée pour initier de nouvellesconnexions.

Un état de connexion est défini par les paramètres suivants :

• Server and client random : Séquences d’octets choisies par le serveur et le client pour chaqueconnexion.

• Server write MAC secret : La Clé cryptographique secrète utilisée dans les opérations MACsur les données envoyées par le serveur.

• Client write MAC secret : La Clé cryptographique symétrique utilisée dans les opérationsMAC sur les données envoyées par le client.

7


• Server write key : Clé cryptographique de Chiffrement symétrique pour les données chiffréespar le serveur et déchiffrées par le client.

• Client write key : Clé de Chiffrement symétrique pour les données chiffrées par le client etdéchiffrées par le serveur.

• Initialization vectors : Lorsqu’un Chiffrement par bloc en mode CBC (Cipher Block Chaining)est utilisé, un vecteur d’initialisation (VI) est maintenu pour chaque clé. Ce champ est d’abordinitialisé par le Handshake Protocol. Ensuite, le dernier bloc de texte chiffré de chaque enregis-trement est conservé pour une utilisation en tant que VI avec l’enregistrement suivant.

• Sequence numbers : Chaque partie conserve des numéros de séquence distincts pour les mes-sages transmis et reçus pour chaque connexion. Lorsqu’une partie envoie ou reçoit un changecipher spec message, le numéro de séquence approprié est mis à zéro. Les numéros de séquencene doivent pas dépasser 264 − 1.

2.2 Le Record Protocol

Le Record Protocol fournit deux services pour les connexions TLS :

• Confidentiality : Le Handshake Protocol permet de définir une Clé cryptographique secrètepartagée utilisée pour le Chiffrement conventionnel des payloads TLS.

• Message Integrity : Le Handshake Protocol définit également une Clé cryptographique secrètepartagée utilisée pour former un MAC.

La figure 1.3 indique le fonctionnement général du Record Protocol. Il prend un message applicatifà transmettre, fragmente les données en blocs gérables, compresse éventuellement les données, ap-plique un MAC, chiffre, ajoute un en-tête et transmet l’unité résultante dans un segment TCP. Lesdonnées reçues sont déchiffrées, vérifiées, décompressées et réassemblées avant d’être transmisesaux applications de couche supérieur.La première étape est la fragmentation. Chaque message de couche supérieure est fragmenté en blocsde 214 octets (16 384 octets) ou moins. Ensuite, la compression est éventuellement appliquée. La com-pression doit être sans perte et ne peut pas augmenter la longueur du contenu de plus de 1024 oc-tets. Dans TLSv2, aucun algorithme de compression n’est spécifié. L’algorithme de compression pardéfaut est donc "null". L’étape suivante du traitement consiste à calculer MAC des données compres-sées. TLS utilise l’algorithme HMAC défini dans le document RFC 2104. Ensuite, le message com-pressé et le MAC sont chiffrés en utilisant un Chiffrement symétrique symétrique. Les algorithmesde Chiffrement autorisés sont présentés dans le tableau 1.1. Pour le Chiffrement par flux de flux, le

TABLE 1.1 – Algorithmes permis dans le chiffrement du message compressé + le MAC [14]

Chiffrement par bloc Chiffrement par fluxAlgorithme Taille de clé Algorithme Taille de clé

AES 128,256 RC4-128 1283DES 168

message compressé, en plus du MAC sont chiffrés. Notez que le MAC est calculé avant le Chiffre-ment et qu’il est ensuite chiffré avec le texte clair ou le texte clair compressé.La dernière étape du déroulement du Record Protocol consiste à ajouter un en-tête composé deschamps suivants :

8


FIGURE 1.3 – Fonctionnement du "Record Protocol" [14]

• Content Type (8 bits) : Le protocole de couche supérieure utilisé pour traiter le fragment inclus.

• Major Version (8 bits) : Indique la version majeure de TLS utilisée. Pour TLSv2, la valeur est 3.

• Minor Version (8 bits) : Indique la version mineure utilisée. Pour TLSv2, la valeur est 1.

• Compressed Length (16 bits) : La longueur en octets du fragment de texte clair (ou fragmentcompressé si la compression est utilisée). La valeur maximale est de 214 + 2048.

Les types de contenu définis sont le change_cipher_spec, le alert, le handshake et application_data.Les trois premiers sont des protocoles spécifiques à TLS, abordés dans la suite. Notons qu’aucunedistinction n’est faite entre les diverses applications (par exemple, HTTP, MQTT) pouvant utiliserTLS ; le contenu des données créées par ces applications est opaque pour TLS.La figure 1.4 illustre le TLS_record_format.

FIGURE 1.4 – Le TLS Record Format [14]

9


2.3 Le Change Cipher Spec Protocol

Le Change Cipher Spec Protocol est l’un des quatre protocoles spécifiques à TLS qui utilise le RecordProtocol. Il s’agit du plus simple. Ce protocole consiste en un seul message (Figure 1.5a), qui consisteen un seul octet avec la valeur 1 [14]. Ce message a pour seul objectif de faire en sorte que l’étaten attente soit copié dans l’état actuel, ce qui met à jour la suite de Chiffrement à utiliser sur cetteconnexion.

2.4 Alert Protocol

Le Alert Protocol est utilisé pour transmettre des alertes liées à TLS à l’entité homologue. Commeavec d’autres applications qui utilisent TLS, les messages d’alerte sont compressés et cryptés, commespécifié par l’état courant.Chaque message de ce protocole consiste en deux octets (Figure 1.5b). Le premier octet prend lavaleur warning (1) ou fatal (2) pour indiquer la gravité du message. Si le niveau est fatal, TLS metimmédiatement fin à la connexion. D’autres connexions sur la même session peuvent continuer, maisaucune nouvelle connexion sur cette session ne peut être établie. Le deuxième octet contient un codequi indique l’alerte spécifique. Les alertes suivantes sont toujours fatales :

• unexpected_message : Un message inapproprié a été reçu.

• bad_record_mac : Un MAC incorrect a été reçu.

• decompression_failure : La fonction de décompression a reçu une entrée incorrecte (par exemple,décompression impossible ou incapable de décompresser à une longueur supérieure à la lon-gueur maximale autorisée).

• handshake_failure : L’expéditeur n’a pas été en mesure de négocier un ensemble de paramètresde sécurité acceptables en raison des options disponibles.

• illegal_parameter : Un champ dans un message de prise de contact était hors de portée ouincompatible avec les autres champs.

• decryption_failed : Un message chiffré, déchiffré de manière non valide ; soit il n’était pas unmultiple pair de la longueur du bloc ou ses valeurs de rembourrage, si cochées, étaient incor-rectes.

• record_overflow : Un enregistrement TLS a été reçu avec une charge utile (texte chiffré) dont lalongueur dépasse 214 + 2048 octets ou le texte chiffré a été décrypté à une longueur supérieureà 214 + 1024 octets.

• unknown_ca : Une chaîne de certificats numériques valide ou une chaîne partielle a été reçue,mais le Certificat numérique n’a pas été accepté, car le Certificat numérique de l’autorité decertification était introuvable ou ne pouvait pas être mis en correspondance avec une Autoritéde certificat de certification connue et approuvée.

• access_denied : Un Certificat numérique valide a été reçu, mais lorsque le contrôle d’accès aété appliqué, l’expéditeur a décidé de ne pas poursuivre la négociation.

• decode_error : Un message n’a pas pu être décodé, car un champ était en dehors de la plagespécifiée ou la longueur du message était incorrecte.

10


• export_restriction : Une négociation non conforme aux restrictions d’exportation sur la lon-gueur de la Clé cryptographique a été détectée.

• protocol_version : La version du protocole que le client a tenté de négocier est reconnue maisnon prise en charge.

• insufficient_security : Renvoyé au lieu du handshake_failure lorsqu’une négociation a échoué,car le serveur requiert des chiffrements plus sécurisés que ceux pris en charge par le client.

• internal_error : Une erreur interne non liée à l’homologue ou à l’exactitude du protocole em-pêche de continuer.

Les alertes restantes sont les suivantes.

• close_notify : Notifie le destinataire que l’expéditeur n’enverra plus de messages sur cetteconnexion. Chaque partie doit envoyer une alerte close_notify avant de fermer le côté écritured’une connexion.

• bad_certificate : Un Certificat numérique reçu était corrompu (par exemple, il contenait uneSignatures numériques qui ne vérifiait pas).

• unsupported_certificate : Le type du Certificat numérique reçu n’est pas pris en charge.

• certificate_revoked : Un Certificat numérique a été révoqué par son signataire.

• certificate_expired : Un Certificat numérique a expiré.

• certificate_unknown : Un autre problème non spécifié est survenu lors du traitement du certi-ficat, le rendant inacceptable.

• decrypt_error : Une opération cryptographique de handshake a échoué, notamment en raisonde l’impossibilité de vérifier une signature, de déchiffrer un échange de Clé cryptographiqueou de valider un message terminé.

• user_canceled : Cette prise de contact est annulée pour une raison quelconque, non liée à unedéfaillance de protocole.

• no_renegotiation : Envoyé par un client en réponse à une "hello request" ou par le serveur enréponse à un "client hello" après un handshake initial. L’un ou l’autre de ces messages entraî-nerait normalement une renégociation, mais cette alerte indique que l’expéditeur n’est pas enmesure de renégocier. Ce message est toujours un avertissement.

2.5 Le Handshake Protocol

La partie la plus complexe de TLS est le Handshake Protocol. Ce protocole permet au serveur etau client de s’authentifier et de négocier un chiffrement, un algorithme MAC et des clés cryptogra-phiques à utiliser pour protéger les données envoyées dans le TLS record. Le Handshake Protocolest utilisé avant toute transmission de données applicatives.Le Handshake Protocol consiste en une série de messages échangés par le client et le serveur. Tousont le format indiqué à la figure 1.5c. Chaque message a trois champs :

11


FIGURE 1.5 – Payload du "Record Protocol" [14]

• Type (1 byte) : Indique l’un des 10 messages. Le tableau 1.2 répertorie les types de messagedéfinis.

• Length (3 bytes) : La longueur du message en octets.

• Content ( ≥ 0 bytes) : Les paramètres associés à ce message ; ceux-ci sont énumérés dans letableau 1.2.

La Figure 1.6 montre l’échange initial nécessaire pour établir une connexion logique entre le client etle serveur. L’échange peut être considéré comme ayant quatre phases.

2.5.1 Phase 1. Etablir les capacités de sécurité

La phase 1 établit une connexion logique et établit les fonctionnalités de sécurité qui lui seront as-sociées. L’échange est initié par le client qui envoie un message client_hello avec les paramètressuivants :

• Version : La version TLS la plus élevée comprise par le client.

• Random : Une structure aléatoire générée par le client et composée d’un horodatage de 32 bitset de 28 octets générés par un générateur de nombres aléatoires sécurisés. Ces valeurs serventd’accessoires et sont utilisées lors de l’échange de clés cryptographiques pour empêcher lesattaques de type "replay".

• Session ID : Un identifiant de session de longueur variable. Une valeur différente de zéroindique que le client souhaite mettre à jour les paramètres d’une connexion existante ou créerune nouvelle connexion sur cette session. Une valeur nulle indique que le client souhaite établirune nouvelle connexion sur une nouvelle session.

• CipherSuite : Il s’agit d’une liste contenant les combinaisons d’algorithmes cryptographiquespris en charge par le client, par ordre décroissant de préférence. Chaque élément de la liste(chaque suite de chiffrement) définit à la fois un algorithme d’échange de clé et une spécification"CipherSpec".

• Compression Method : Voici une liste des méthodes de compression prises en charge par leclient.

Après avoir envoyé le message client_hello, le client attend le message server_ hello, qui contientles même paramètres que le message client_hello. Pour le message server_hello, les conventions sui-vantes s’appliquent. Le champ Version contient la version la plus basse de la version suggérée par

12


FIGURE 1.6 – Le Handshake Protocol en action [14]

le client et la plus haute prise en charge par le serveur. Le champ Random est généré par le serveuret est indépendant du champ tRandom du client. Si le champ SessionID du client était différent dezéro, la même valeur est utilisée par le serveur sinon, le champ SessionID du serveur contient lavaleur pour une nouvelle session. Le champ CipherSuite contient la suite de Chiffrement uniquesélectionnée par le serveur parmi celles proposées par le client. Le champ Compression contient laméthode de compression sélectionnée par le serveur parmi celles proposées par le client.Le premier élément du paramètre Ciphersuite est la méthode d’échange de clés cryptographiques(c’est-à-dire le moyen par lequel les clés cryptographiques pour le Chiffrement conventionnel et lecode MAC sont échangées).Plusieurs méthodes d’échange de clés cryptographiques sont prises encharge (RSA, Diffie-Hellman, ECDH, ...).Après la définition d’une méthode d’échange de clé, la spécification CipherSpec comprend les champssuivants :

13


• CipherAlgorithm : N’importe lequel des algorithmes mentionnés précédemment : AES (Ad-vanced Encryption Standard), RC4, RC2, DES (Data Encryption Standard), 3DES, DES40 ouIDEA (International Data Encryption Algorithm) ...

• MACAlgorithm : MD5 (Message Digest 5), SHA (Secure Hash Algorithm)-1, SHA256 ...

• CipherType : Chiffrement par flux ou Chiffrement par bloc

• IsExportable : Vrai ou Faux

• HashSize : 0, 16 (pour MD5), 20 (pour SHA-1), 32 (pour SHA256) octets

• Key Material : Une séquence d’octets contenant des données utilisées pour générer les cléscryptographiques d’écriture

• IV Size : La taille de la valeur d’initialisation pour le Chiffrement AES en mode CBC.

2.5.2 Phase 2. Authentification du serveur et échange de clés

Le serveur commence cette phase en envoyant son Certificat numérique s’il doit être authentifié ; lemessage contient un Certificat numérique ou une chaîne de certificats numériques au format X.509.Le message contenant le Certificat numérique est requis pour les méthodes d’échange de clés cryp-tographiques.Un message server_key_exchange peut être envoyé s’il est requis. Il n’est pas nécessaire si le ser-veur a envoyé un Certificat numérique avec des paramètres fixes selon la méthode d’échange de cléscryptographiques utilisée (RSA, DH, ECDH). Le message server_key_ exchange est nécessaire si lesparamètres sont temporaires et négociés pendant la connexion. Dans ce cas, le contenu du messagecomprend les paramètres temporaires du serveur, ainsi qu’une Signatures numériques de ces para-mètres.Quelques détails supplémentaires sur les signatures numériques sont garantis. Comme d’habitude,une Signatures numériques est créée en prenant le hash d’un message et en le chiffrant avec la Clécryptographique privée de l’expéditeur. Ainsi, le hash couvre non seulement les paramètres, maiségalement les deux nonces des messages hello initiaux. Cela garantit contre les attaques de type re-play et les fausses déclarations.Les cas de demande de Certificat numérique au client sont ignorés ici, et sont donc surcolorés dansla figure 1.6.Le dernier message obligatoire de la phase 2, est le message server_done, qui est envoyé par le ser-veur pour indiquer la fin du server_hello du serveur et les messages associés. Après l’envoi de cemessage, le serveur attend une réponse du client. Ce message n’a pas de paramètres.

2.5.3 Phase 3. Authentification du client et échange de clés

Il n’est pas nécéssaire de décrire l’authentification du client puisqu’il n’est pas utilisé ici.À la réception du message server_done, le client doit vérifier que le serveur a fourni un Certificatnumérique valide (le cas échéant) et que les paramètres server_hello sont acceptables. Si tout estsatisfaisant, le client renvoie un ou plusieurs messages au serveur. Le message client_key_exchange,doit être envoyé dans cette phase. Il contient les paramètres de Clé cryptographique publique généréspar le client. Ceci est valable aussi pour des paramètres temporaires.

14

Chapitre 1. Revue de Littérature 3. La Cryptographie à Courbes Elliptiques

2.5.4 Phase 4. Finish

La phase 4 termine l’établissement d’une connexion sécurisée. Le client envoie un message change_cipher_specet copie la spécification CipherSpec en attente dans la spécification CipherSpec actuelle. Notez quece message n’est pas considéré comme faisant partie du Handshake Protocol, mais est envoyé àl’aide du Change Cipher Spec Protocol. Le client envoie ensuite immédiatement le message Fini-shed utilisant les nouveaux algorithmes, clés cryptographiques et secrets.Le message Finished vérifie que les processus d’échange de clés cryptographiques et d’authentifica-tion ont abouti.En réponse à ces deux messages, le serveur envoie son propre message change_cipher_ spec, trans-fère l’état en attente vers la spécification CipherSpec actuelle et envoie le message Finished. À cestade, le handshake est terminé et le client et le serveur peuvent commencer à échanger des donnéesprovenant de la couche application. Le tableau 1.2 présente un resumé des paramètres contenus dansles différents messages échangés.

TABLE 1.2 – Types de messages du "TLS Handshake Protocol" [14]

Message Type Parametershello_request nullclient_hello version, random, session id, cipher suite, compression methodserver_hello version, random, session id, cipher suite, compression method

certificate chain of X.509v3 certificatesserver_key_exchange parameters, signature

certificate_request type, authoritiesserver_done null

certificate_verify signatureclient_key_exchange parameters, signature

finished hash value

DTLSLe protocole DTLS (Datagram Transport Layer Security) (Datagram Transport Layer Security) estune variante de TLS modifiée afin de prendre en charge le protocole UDP. TCP prend en charge à lafois la re-livraison de messages et la mise en ordre de message, fonctionnalités qui ne sont pas prisen charge par UDP [14].Une préoccupation concernant DTLS est la nouveauté relative du protocole et son adoption précoce.Le DTLS a été introduit en 2012 (comparé à 1999 pour TLS). En 2013, des chercheurs ont trouvé uneattaque sur DTLS avec certaines suites de Chiffrement susceptibles de récupérer le texte en clair.TLS a connu de nombreuses attaques graves, ce qui en fait est un bon signe car nous savons qu’ila été testé et amélioré, et il existe une mine de connaissances sur la manière de le mettre en œuvreefficacement. La même chose n’est pas encore vraie pour DTLS.

3 La Cryptographie à Courbes Elliptiques

La Cryptographie à les courbes elliptiques (ECC (Elliptic Curve Cryptography)) regroupe un en-semble de techniques cryptographiques qui utilisent une ou plusieurs propriétés des courbes ellip-tiques. L’usage des courbes elliptiques en Cryptographie a été suggéré, de manière indépendante,

15


par Neal Koblitz et Victor Miller en 1985 [3],[9]. L’utilisation de ces propriétés permet d’améliorer lesprimitives cryptographiques existantes, par exemple en réduisant la taille des clés cryptographiques,ou de construire de nouvelles primitives cryptographiques qui n’étaient pas connues auparavant.ECC propose des applications sous forme de schéma de partage de Clé cryptographique publique(ECDH/ECDHE) et de schéma d’authentification de Signatures numériques numérique (ECDSA (El-liptic Curve Digital Signature Algorithm)).

3.1 Principe de fonctionnement

3.1.1 Définition d’un corps premier

Un corps premier est une variante du corps fini ou du corps de Galois GF(p) où p est un nombrepremier. Un champ premier noté Fp comprend des entiers modulo p avec les résultats de toutes lesopérations telles que l’addition et la multiplication appartenant également au même champ [6]. C’estun corps d’ordre fini p. Tous les éléments appartenant à ce champ sont 0, 1, 2, ......., p− 1.

3.1.2 Définition d’une courbe elliptique

Soit p un nombre premier et Fp un corps premier. Une courbe elliptique E est définie sur Fp. Tous lespoints de cette courbe appartiennent au corps principal défini. Ces points satisfont à l’équation don-née ci-dessous. Ici, la paire (x,y) représente les coordonnées cartésiennes d’un point de la courbe [6].

y2 = x3 + ax+ b

a, b sont aussi les éléments du corps premier Fp.Ils doivent satisfaire à la condition 4a3 + 27b2 6= 0(modp).Nous avons plusieurs types de courbes elliptiques. L’ECC implique des courbes elliptiques (figure1.7) définies sur un corps fini [10]. Il y a deux types de corps qui soient d’intérêt dans l’ECC :

• Un corps premier GF (p)

• Un corps binaire fini GF (2m)

Nous parlerons dans ce mémoire de Cryptographie utilisant des courbes elliptiques définies sur uncorps premier.

FIGURE 1.7 – Une courbe elliptique avec des points [10]

16


3.1.3 Paramètres de domaine

Outre les paramètres de la courbe, les parties impliquées doivent convenir de certains autres para-mètres pour une communication sécurisée utilisant l’ECC. Ces paramètres sont appelés paramètresde domaine. Une courbe elliptique appropriée sur un corps premier est choisie [6]. Ces paramètressont résumés comme suit :

1. p est le nombre premier choisi pour définir le corps premier ;

2. a, b sont les deux paramètres de l’équation de la courbe dont dépend la forme de la courbe ;

3. G est le point de base ou le point générateur qui est un point de la courbe sur Fp sélectionnépour effectuer les opérations sur la courbe ;

4. n est l’ordre d’un point D sur la courbe elliptique. C’est le plus petit entier tel que nD = 0.L’opération effectuée pour calculer nD s’appelle une opération ponctuelle et est décrite dansles dernières parties de cet article ;

5. h est le cofacteur de la courbe.

3.1.4 Arithmétique des corps finis

1. Inversion : Inverse d’un élément non nul x auquel appartient le corps fini Fp, noté x−1modp

est un autre élément unique m qui appartient également au même corps fini Fp tel que mx =

1modp. Il est éfficacement calculé en utilisant un algorithme euclidien étendu [18].

2. Ajout de points et doublage de points : L’addition de points (figure 1.8) est la méthode danslaquelle deux points M et N sur une courbe elliptique sont combinés pour obtenir un autrepoint qui se trouve également sur la même courbe elliptique sur un corps premier Fp [19]. Le

FIGURE 1.8 – Addition de points sur une courbe elliptique [6]

doublage de points (figure 1.9) est une méthode consistant à ajouter un point M au même pointpour obtenir un point S sur la courbe elliptique sur un corps premier Fp.[19]

3. Multiplication de points : Ceci est également connu sous le nom de multiplication scalaire.Cela implique le calcul de bM , ici b appartient au corps premier et M est un point de la courbeelliptique définie sur le même corps premier Fp [6]. Cette opération est effectuée en doublant

17


FIGURE 1.9 – Doublage d’un point sur une courbe elliptique [6]

plusieurs fois et en ajoutant le point de la courbe jusqu’à ce que le point soit multiplié le nombrede fois requis.

3.1.5 Génération de clés à l’aide d’une courbe elliptique

Notons E une courbe elliptique définie. Elle est définie sur un corps premier Fp. Soit T un point dela courbe elliptique E (Fp), et T doit avoir un ordre premier n [6].Un nombre est sélectionné aléatoirement de sorte qu’il appartienne au corps principal. Ce nombredevient la clé privée. Il est multiplié par le point de base ou le point générateur. Le résultat de cettemultiplication de points est la clé publique.

3.1.6 Elliptic Curve Discrete Logarithmic Problem (ECDLP)

Contrairement aux cryptosystèmes classiques qui fonctionnent sur des champs entiers, ECC fonc-tionne sur un groupe de points sur une courbe elliptique. Son opération cryptographique principaleest la multiplication de points scalaires. La sécurité de l’ECC repose sur la difficulté de résoudrele problème du logarithme discret à courbe elliptique (ECDLP), qui stipule que, étant donné P etQ = kP , il est difficile de trouver k. Outre l’équation de la courbe, un paramètre important de lacourbe elliptique est le point de base, G, qui est fixé pour chaque courbe.[7] En ECC, un grand entieraléatoire k agit comme une clé privée, alors que le résultat de la multiplication de la clé privée k avecle point de base de la courbe G sert de clé publique correspondante.

3.1.7 Standards du NIST

Toutes les courbes elliptiques n’offrent pas de fortes propriétés de sécurité et, pour certaines courbes,l’ECDLP peut être résolu efficacement. Etant donné qu’un mauvais choix de courbe peut compro-mettre la sécurité, les organisations de normalisation telles que NIST et SECG ont publié un ensemblede courbes [2] possédant les propriétés de sécurité nécessaires. L’utilisation de ces courbes est égale-ment recommandée pour faciliter l’interopérabilité entre différentes implémentations d’un protocolede sécurité [7].Toutes les courbes proposées sur un corps premier ont un cofacteur à l’unité et l’équation de la courbe

18


est donnée par [6]E : y2 = x3 − 3x+ b(modp) .

Des courbes ont été proposées pour 192, 224, 256, 384 et 521 bits.

3.2 Echange de clés ECDH (Elliptic Curve Diffie-Hellman)

Elliptic Curve Diffie-Hellman est un protocole utilisé pour l’accord de clé qui permet à deux entitésde générer une clé secrète qui sera utilisée pour les opérations impliquant la clé privée. La clé pu-blique générée par un individu est partagée avec l’autre. Les opérations sur les courbes elliptiquessont utilisées pour générer la clé secrète. Nous considérons qu’Alice et Bob sont d’accord sur un pro-tocole commun d’échange de clés cryptographiques pour l’échange de données. On suppose qu’ilsn’avaient aucun contact et que le mode de communication disponible entre eux par le canal n’est quepublic. Les deux échangent des données publiques ou des clés cryptographiques publiques. Cha-cune d’entre elles possède une clé privée utilisée pour générer la clé partagée appelée clé publique.Les deux individus s’accordent sur les mêmes paramètres de domaine. Les étapes suivantes sontsuivies dans ce protocole [6].

1. Alice et Bob choisissent une courbe elliptique commune E sur un corps premier Fp. Ils ont éga-lement un point de base GεE(Fp) de sorte que le sous-groupe généré par G ait une cardinalitéde groupe plus grande. Cela détermine la force de la méthode impliquée [1].

2. Alice choisit un entier a. C’est une clé secrète qui n’est partagée avec personne. C’est la cléprivée d’Alice. Elle utilise ensuite la multiplication de points et calcule la clé publique Ta = aG

et envoie Ta à Bob.

3. Bob sélectionne également un entier b qui devient sa clé privée, calcule Tb = bG par la multi-plication de points et envoie Tb à Alice.

4. Alice calcule aTb = abG. Cela se fait par la multiplication de points de la clé secrète d’Aliceavec la clé partagée de Bob.

5. Bob effectue la multiplication de points entre sa clé privée et la clé publique d’Alice et calculebTa = abG.

Les seules données qu’un espion puisse obtenir concernent la courbe elliptique E, le corps fini Fp etles points G, aG, bG. Il est difficile de calculer le secret partagé avec seulement cette information [6].Un resumé du fonctionnement de l’ECDH est présenté à la figure 1.10.

ECDHE (ECDH Ephemeral)L’ECDHE n’est autre que l’algorithme ECDH dont les clés cryptographiques générés ont une duréede vie temporaire équivalente à la durée de la session en cours. L’ECDHE fournit le Perfect ForwardSecrecy [28] qui assure juste que les informations échangées pendant une session TLS ne puissentêtre découvertes en utilisant des clés cryptographiques recouvertes lors d’une autre session [28].

3.3 TLS Handshake avec l’ECDHE

Notre solution implémente le TLS en utilisant l’ECDHE comme mécanisme d’échange de clés cryp-tographiques de session. La figure 1.11 nous montre les étapes du processus d’échange de clés cryp-tographiques TLS avec l’ECDHE

19


FIGURE 1.10 – Fonctionnement du ECDH [6]

3.4 Signature digitale avec l’ECDSA (Elliptic Curve Digital Signature Algorithm)

Un algorithme asymétrique peut être utilisé pour signer numériquement un message afin que le des-tinataire puisse prouver qui l’a envoyé [11]. En d’autres termes, l’authenticité d’un message peutégalement être vérifiée en utilisant un algorithme asymétrique. Dans le cas d’une Signatures numé-riques, le message est chiffré à l’aide de la clé privée et déchiffré à l’aide de la clé publique corres-pondante. Étant donné que seul un expéditeur valide peut avoir sa clé privée, un destinataire peutsupposer que le message est envoyé par l’expéditeur valide [11].En pratique, les algorithmes à clé publique sont trop inéfficaces pour signer de longs messages. Pourgagner du temps, les protocoles de Signatures numériques sont souvent implémentés avec des fonc-tions de hachage unidirectionnelles [8]. Au lieu de signer un message, on signe le hash du message.Avant la signature, la fonction de hachage et l’algorithme de Signatures numériques sont convenusau préalable. La Signatures numériques se fait comme suit [15] :

• L’expéditeur produit un hash du message ;

• Il chiffre le hash produit avec sa clé privée, signant ainsi le hash ;

• Alice envoie le message et le hash signé au destinataire ;

• Le destinataire produit un hash du document reçu. Il utilise ensuite l’algorithme de Signaturesnumériques pour déchiffrer le hash signé avec la clé publique de l’expéditeur. Si le hash signécorrespond au hash qu’il a généré, la Signatures numériques est valide.

ECDSA est l’analogue à courbe elliptique de l’algorithme (DSA). La paire de clés cryptographiquesdans ECDSA est générée de la même manière que dans ECDH [10]. ECDSA utilise le hash du messageet les opérations sur les points pour générer des signatures.

3.5 Avantages de ECC par rapport aux autres cryptosystèmes

À la base d’un Cryptosystème à clé publique se trouve un problème mathématique difficile, pres-qu’impossible à résoudre, même avec un ordinateur. La difficulté relative à la résolution de ce pro-

20


FIGURE 1.11 – TLS Handshake avec ECDHE[7]

blème détermine la force du Cryptosystème qui l’utilise. Le tableau 1.3 [7] résume trois types decryptosystèmes à clé publique bien connus. Comme indiqué dans la dernière colonne, RSA, Diffie-Hellman et DSA peuvent tous être attaqués à l’aide d’algorithmes sous-exponentiels, mais la meilleureattaque connue sur ECC nécessite un temps exponentiel. Pour cette raison, ECC peut offrir une sé-curité équivalente avec des tailles de clé considérablement plus petites. Contrairement aux autrescryptosystèmes à clé publique connus, ECC offre les avantages suivants :

1. La complexité : En dépit de la multiplication ou de l’exponentiation dans un corps fini, ECCutilise la multiplication scalaire. Résoudre Q = k.P (utilisé par ECC) est plus difficile que derésoudre la factorisation (utilisée par RSA) et le logarithme discret (utilisé par Diffie-Hellman(DH), EIGamal, DSA). ECC est donc beaucoup plus puissant que les autres méthodes de Signa-tures numériques digitale et d’échange de clé symétrique [10].

2. L’implication de moins de bits : ECC nécessite un moins grand nombre (et donc moins de bits)pour son fonctionnement grâce à ECDLP. Le niveau de sécurité d’une clé ECC de 160 bits estsimilaire à celle d’une clé RSA/DSA de 1024 bits [10]. Le tableau 1.4 [7] montre la comparaisonentre ECC et les autres cryptosystèmes à clé publique.

21


TABLE 1.3 – Cryptosystèmes à clé publique connus [7]

Système à Exemples Problème Méthode connueclé publique mathématique pour la résolution

du problème(complexité en temps)

Factorisation RSA, Trouver les Le nombred’un nombre Rabin-Williams facteurs premiers Field Sieve :

entier d’un nombre exp[1.923(logn)1/3(loglogn)2/3]entier donné (sous-exponentiel)

Logarithme discret Diffie-Hellman(DH), Étant donné un Le nombreDSA, ElGamal nombre premier n Field Sieve :

et les nombres g et h exp[1.923(logn)1/3(loglogn)2/3]trouver x tel que (sous-exponentiel)h = gx modn

Logarithme discret ECDH/ECDHE, Étant donné une L’algorithme Pollard-rho :à courbe elliptique ECDSA courbe elliptique E

√n

et les points P (Pleinement exponentiel)et Q sur E,

trouvez x telque Q = xP

TABLE 1.4 – Comparaison ECC vs RSA/DSA/DH [7]

Symetrique(AES) ECC RSA/DSA/DH Durée de protection80 160 1024 jusqu’en 2010112 224 2048 jusqu’en 2030128 256 3072 au-delà de 2031192 384 7680256 512 15360

3. Consommation d’énergie : Le fonctionnement de l’ECC nécessite moins d’énergie, il est doncmieux adapté aux applications à faible consommation d’énergie telles que les appareils porta-tifs, mobiles, lesIOT [10].

4. Efficacité dans l’execution : L’implémentation de la multiplication scalaire dans le logiciel ou lematériel est beaucoup plus faisable que d’effectuer des multiplications ou des exponentiations.Comme ECC utilise des multiplications scalaires, il est donc bien plus efficace en calcul que lessystèmes publics RSA et Diffie-Hellman (DH) [10].

Le coût de calcul et la durée d’exécution des opérations cryptographiques jouent un rôle majeur dansl’efficacité des cryptosystèmes. La taille en bits de la clé détermine les demandes d’espace ou de mé-moire. Une taille de clé plus petite est plus efficace car elle nécessite moins de ressources matérielles,un temps de transmission de clé faible, une mémoire moins grande pour le stockage, un faible coûtde calcul arithmétique et une faible bande passante.Nous pouvons donc affirmer sans aucun doute que l’ECC est le Cryptosystème le plus fort et le plusrapide (le plus éfficace) parmi les cryptosystèmes à clé publique actuels.

22


Conclusion

Les prises intelligentes peuvent apporter de la commodité dans une maison. Elles ont un large choixentre plusieurs protocoles de communication à utiliser pour fonctionner. La sécurité des donnéesmanipulées par ces prises peut être gérée par le protocole TLS, un protocole phare dans la sécuritéde données en transit dans un canal non sécurisé. Pour le présent projet, nous intégrons le protocoleTLS à un système de prises intelligentes en utilisant la Cryptographie à courbes elliptiques commeCryptosystème à clé publique.

23

Chapitre 2Solution et choix techniques

Introduction

La réalisation d’un système demande une hiérarchisation des idées et outils liés à sa conception.Dans ce présent chapitre, nous faisons un inventaire des outils liés à la mise en place de l’architecturesécurisée de notre système et nous abordons la mise en place proprement dite du système.

1 Matériel

Dans cette section, nous présentons les différents outils utilisés pour mettre en place notre solution.

1.1 L’esp8266

L’esp8266 est un circuit, du fabricant chinois Espressif, avec microcontrôleur et une carte WiFiintégrés. Il est utilisé dans plusieurs modules pour contrôler des périphériques par réseau. Mais toutela souplesse et la puissance de ce module résident dans le fait qu’il peut être entièrement programméde façon personnalisée, et rendu autonome. L’esp8266 est programmable en Arduino [23].La version l’esp8266-esp12E (figure 2.1) est utilisée dans ce projet. L’esp8266 :

• supporte les protocoles 802.11 b/g/n ;

• se connecte à votre routeur et fonctionne comme client ou comme point d’accès ou même lesdeux en même temps ;

• fonctionne aussi comme serveur web avec son propre point d’accès ;

• fonctionne aussi en communiquant avec une carte Arduino ou peut être programmé pour fonc-tionner en toute autonomie.

Quelques caractéristiques de l’esp8266 sont présentées ci-dessous :[23]

• 32-bit RISC CPU : Tensilica Xtensa LX106, 80 MHz;

• 64 KiB de RAM d’instruction, 96 KiB de RAM de données ;

24

Chapitre 2. Solution et choix techniques 1. Matériel

• IEEE 802.11 b/g/n Wi-Fi ;

• Authentification WEP ou WPA / WPA2, ou réseaux ouverts ;

• 16 broches GPIO.

FIGURE 2.1 – L’esp8266-esp12E [23]

1.2 Arduino

Le langage de programmation Arduino est un langage très inspiré des langages de programmationC et C++, et qui est adapté à la programmation de microcontrôleurs. Il permet de programmer desmicrocontrôleurs [23]. Il est accompagné de son propre IDE.

1.3 La librairie BearSSL et les librairies esp8266 importantes

BearSSL est une implémentation du protocole TLS (RFC 5246) écrit en C. Il est portable, richeen fonctionnalités et extensible. Il implémente plusieurs suites de Chiffrementet extensions utilisésdans TLS.[22] La librairie BearSSL est reconnue par la communauté Arduino et Espressif et a étéintégrée aux librairies standards de l’esp8266, afin de rajouter le support de connexions TLS client/-serveur. Elle sous-tend principalement les librairies ESP8266WebServerSecure,WiFiServerSecure,WiFiClientSecure etc.

1.4 Ionic Cordova

Ionic est un framework open-source crée en 2013 par Max Lynch, Ben Sperry, et Adam Bradley. Deuxversions distinctes sont disponibles, incompatibles entre elles : la première version, 1.3.3 se base surAngularJS 1.5.3 tandis que la version 3.5.0 se base sur Angular 4.1.3 et TypeScript [16]. Basé initiale-ment sur AngularJS et Apache Cordova2 [17], Ionic permet de créer un code multisupport en utili-sant des outils Web comme HTML, CSS, JavaScript, afin de générer des applications iOS, Android,Chrome, Windows Phone et bien d’autres.

1.5 L’application android MPlug

Dans le cadre du monitoring du système M-Plug, l’application multiplateforme MPlug a été dé-veloppée en Ionic Cordova. Elle joue le rôle de client web dans le système M-Plug. Elle offre lesfonctionnalités suivantes :

• permettre à l’utilisateur d’allumer et d’éteindre à distance tout appareil branché à un plug dansle système ;

25

Chapitre 2. Solution et choix techniques 1. Matériel

• permettre à l’utilisateur de programmer à l’avance des appareils voulus pour fonctionner à desheures définies ;

• permettre à l’utilisateur d’activer un contrôle intelligent des appareils par la reproduction deses habitudes de contrôle.

Un aperçu de l’interface de l’application MPlug est montré à la figure 2.2

FIGURE 2.2 – Interface de l’application MPlug

1.6 Le plugin cordova-plugin-advanced-http

Le plugin cordova-plugin-advanced-http a été développé pour les applications Ionic. Il permet nonseulement de supporter les connexions TLS avec des serveurs distants tout en déjouant l’attaqueMiTM [26]. Il embarque des fonctionnalités telles que :

• le threading en arrière-plan - toutes les requêtes sont effectuées dans un thread en arrière-plan ;

• le SSL Pinning.

Le plugin supporte les plateformes IOS et Android.

1.7 Openssl

OpenSSL est une boîte à outils cryptographiques implémentant le protocol TLS qui offre :

• une bibliothèque de programmation en C permettant de réaliser des applications client/serveursécurisées s’appuyant sur TLS [27] ;

• une ligne de commande(openssl sous linux) permettant :

– la création de clés cryptographiques ECC, RSA, DSA (Digital Signature Algorithm), ECDSA(signature) ;

– la création de certificats numériques X509 ;

– le calcul d’empreintes (MD5, SHA256, SHA1, ...) ;

– le Chiffrementet Déchiffrement(AES, DES, IDEA, RC (Rivest Cipher)4, ...) ;

– la Signatures numériques et le Chiffrementde courriers (S/MIME (Secure/MultipurposeInternet Mail Extensions)).

26

Chapitre 2. Solution et choix techniques 2. Mise en place du système M-Plug

2 Mise en place du système M-Plug

L’interopérabilité, l’acceptation par le public et les spécifications techniques sont des questions connexesliées à la mise en œuvre des systèmes cryptographiques.

2.1 Fonctionnement du système - Architecture de base

Ici nous décrivons le fonctionnement du système M-Plug tout en attirant l’attention sur les différentsblocs sur lequel il repose.Le système M-Plug est basé sur une architecture client/serveur et utilise le protocole HTTP commeprotocole de communication.Le serveur web est représenté par l’esp8266. En fait, ce périphérique joue plusieurs rôles dans lesystème, à savoir :

• Serveur web : Il est directement relié aux appareils à contrôler en se servant des broches dontil dispose. Il est l’entité qui reçoit les commandes des clients et les traite. Les commandes sontenvoyés (par les clients web) et reçues (par l’esp8266) sous forme de requêtes web contenantdes paramètres définis ; la méthode GET est la méthode utilisée pour les requêtes.

• Point d’accès : L’esp8266 fonctionne comme un point d’accès dans le système M-Plug (celapeut changer dans les versions futures du système M-Plug, où l’esp8266 sera connecté au réseauexistant de son propriétaire). Il diffuse son propre hotspot (intégrant donc une passerelle réseau,un serveur DHCP...) auquel se connectent tous les appareils pour le contrôle à distance.

• Serveur DNS : Dans le hotspot diffusé, l’esp8266 jouera aussi le rôle de serveur DNS. Dansle réseau, il sera désigné par son nom de domaine (pour des questions de sécurité que nousévoquerons plutard).

Le client web est représenté par l’application android MPlug. Il se connecte au point d’accès del’esp8266 et peut ainsi lui envoyer ses requêtes web (et reçevoir les réponses appropriées à celles ci).

2.2 Fonctionnement du système - Architecture sécurisée

Cette sous-section nous permet de ressortir les aspects critiques du système de base et définir lesfonctions de sécurité ajoutés.

2.2.1 Présentation générale

Le système M-Plug, dans son architecture de base présente plusieurs failles de sécurité. Dans lecas d’une interception de paquets, les données en transit peuvent être lues et modifiées, les acteursdu systèmes peuvent être imités. Il était donc important de rajouter une couche de sécurité, afin depréserver la vie privée des utilisateurs. Les objectifs fixés en matière de sécurité sont la confiden-tialité, l’intégrité des données, l’authentification (côté client et côté serveur). En plus des objectifsprécédemment cités, il est important de rajouter l’utilisation légère des ressources dans l’atteintedes objectifs de sécurité, ce qui passe par l’utilisation de méthodes non gourmandes en calculs.Le protocole TLS répond aux objectifs de sécurité fixés plus haut, notamment la confidentialité etl’intégrité des données. Avec l’aide d’une Autorité de certificat reconnue entre les acteurs(appareils)

27


FIGURE 2.3 – Architecture de base du système M-Plug

du système M-Plug, il permet aussi de réaliser l’authentification du serveur à travers des certificatsémis par l’Autorité de certificat à l’endroit de chaque serveur (esp8266). Nous présentons dans lasuite, les différentes entités et les différents mécanismes qui participent à notre solution.

2.2.2 Autorité de Certificat (AC) MiAC

L’Autorité de certificat représente l’entité de confiance du système M-Plug. Le système M-Plug fonc-tionne sur une chaîne de confiance dont l’AC est le socle. L’AC est représenté par une paire de cléscryptographiques et son certificat, chacun ayant un rôle important.

• La clé publique : Il est embarqué dans le Certificat numérique de l’AC qui sera embarqué à sontour dans les programmes clients afin d’effectuer les vérifications nécéssaires à l’authentifica-tion du serveur distant.

• La clé privée : Il est tenu secret par l’AC et lui sert à signer les certificats numériques émis àl’endroit des serveurs(esp8266).

• Le certificat : Il contient des informations relatives à l’AC.

Les informations requises pour le Certificat numérique (en dehors de la clé publique) de l’AC sontles suivantes :

• country Name : Le code (BJ, US, ...) du pays où se trouve l’AC. Dans notre cas, le BJ(pour Bénin).

• state Or Province Name : Le nom de la ville ou de la province où se trouve l’AC (ou le serveur).Dans notre cas, Abomey-Calavi.

28


• locality Name : Le nom de la localité où se trouve l’AC. Dans notre cas, Aconville.

• organization Name : Le nom de l’AC (ou de l’organisation que représente l’AC). Dans notrecas, MiFY.

• organizational Unit Name : Le nom du département qui gère l’AC. Dans notre cas, MiAC.

• common Name : Le nom de domaine (ou l’adresse IP) de l’AC. Dans notre cas, https ://www.mify-ai.com

• email Address : L’adresse email de l’AC. Dans notre cas, [email protected].

Pour allier sécurité et rapidité dans le système, les algorithmes ECC, ECDH(pour l’échange de clésymétrique) et ECDSA(pour la Signatures numériques digitale) sont utilisés.En pratique, il existe une hiérarchie entre différentes autorités de certificats de certification. Un ACracine ne signe pas directement les certificats numériques des serveurs. Il signe plutôt les certificatsnumériques d’AC intermédiaires, leur transmettant ainsi sa confiance. Cela crée donc une chaîne deconfiance de l’AC racine au serveur en fin de chaîne. Les AC intermédiaires à leur tour peuvent si-gner les certificats numériques d’autres AC intermédiaires (allongeant ainsi la chaîne) ou directementles certificats numériques des serveurs. Ceci est considérée comme une mesure de sécurité, car dansle cas où un AC intermédiaire se fait pirater, il suffira que son Certificat numérique soit révoqué parl’AC racine pour que les programmes clients rejettent les certificats numériques des serveurs affectés.On assume que les clés cryptographiques de l’AC racine sont tenues en haute sécurité et ne peuventêtre divulguées. Les certificats numériques des serveurs embarquent donc souvent les informationsdécrivant la chaîne de confiance qui relie l’AC intermédiaire qui les a signé à l’AC racine connu duprogramme client.Le principe décrit plus haut rallonge les certificats numériques émis aux serveurs ; ce qui produitplus d’informations à signer, et beaucoup de travail pour les programmes clients dans la vérificationde l’authenticité de chaque entité dans la chaîne. Cela produit plus d’opérations pour les serveurset clients du système. Cette mesure est pratique quand on a affaire à des serveurs ayant des res-sources suffisantes mais elle crée de la latence dans le système M-Plug vu les faibles ressources dontil dispose. Cette perspective en vue, le système M-Plug ne dispose que d’un seul AC pour signer lescertificats numériques des différents serveurs(esp8266).C’est l’outil openssl que nous utilisons pour générer des paire de clés, créer des certificats numé-riques et les signer. Les opérations suivantes sont éffectuées pour mettre en place l’AC que nousnommons "MiAC".

• Creation de la paire de clés : Nous fixons la taille des clés cryptographiques ECC de l’AC à384 bits. Nous utilisons donc la courbe secp384r1 disponible dans les standards SEC/NIST [2]et définie sur un corps premier de 384 bits. L’accès à la paire de clé créée est restreinte en lachiffrant à l’aide de l’algorithme aes en mode CBC avec une clé de 256 bits protégée par unmot de passe et en rajoutant des droits d’accès. Le système Ubuntu(Linux) est utilisé.Les commandes openssl suivantes permettent de créer notre paire de clés cryptographiques etde restreindre les accès.

1. openssl ecparam -name secp384r1 -genkey | openssl ec -aes-256-cbc -out rootKey.pem

2. chmod 400 root.key

29


• Création du certificat : Le Certificat numérique créé pour l’AC est un Certificat numérique au-tosigné par sa propre clé privée, générée plus haut. Ce Certificat numérique sera embarquédans chaque application mobile MPlug pour vérifier l’authenticité des serveurs distants.Les commandes openssl suivantes permettent de créer le Certificat numérique et d’y restreindrel’accès.

1. openssl req -x509 -sha256 -key rootKey.pem -new -out rootCert.pem -subj ’/C=BJ/ST=Abomey-Calavi/L=Aconville/O=MiFY/OU=MiAC/CN=www.mify-ai.com’ -days 7300

2. chmod 400 rootCert.pem

2.2.3 Certificats des serveurs

Pour obtenir un Certificat numérique pour les connexions TLS, un serveur doit posséder sa proprepaire de clés cryptographiques et produire un CSR (Certificate Signing Request) qui sera utilisé parl’AC pour lui délivrer ledit certificat. Chaque serveur du système M-Plug doit posséder sa proprepaire de clés. Les opérations suivantes sont éffectuées pour créer le Certificat numérique d’un serveurdu système.

• Creation de la paire de clés : Nous fixons la taille des clés cryptographiques ECC des ser-veurs(esp8266) à 256 bits. Nous utilisons donc la courbe prime256v1 disponible dans les stan-dards SECG [2] et définie sur un corps premier de 256 bits. L’accès à la paire de clé créée estrestreinte en la chiffrant à l’aide de l’algorithme AES en mode CBC avec une clé de 256 bitsprotégée par un mot de passe et en rajoutant des droits d’accès. Le système Ubuntu(Linux) estutilisé.Les commandes openssl suivantes permettent de créer notre paire de clés cryptographiques etde restreindre les accès.

1. openssl ecparam -name prime256v1 -genkey | openssl ec -aes-256-cbc -out serveurNKey.pem

2. chmod 400 serveurNKey.pem

• Création du certificat : Le CSR créé pour le serveur(esp8266) sera utilisé par l’AC pour lui pro-duire le certificat. Pour empêcher que le Certificat numérique d’un serveur(esp8266) ne soitréutilisé dans une attaque MiTM, le champs "Common Name" est différent pour chaque CSRcréé et pour chaque Certificat numérique qui sera émis par l’AC. Chaque serveur sera doncaccessible sur un nom de domaine différent.Les commandes openssl suivantes permettent de créer le CSR du serveur, le Certificat numé-rique du serveur (par l’AC en utilisant sa clé privée) et d’y restreindre l’accès.

1. openssl req -new -sha256 -key serveurNKey.pem -out serveurNCsr.pem -subj ’/C=Pays/ST=Province/L=localite/O=Entreprise/OU=Entreprise+MPlug/CN=NomDeDomaineAleatoire.local’

2. openssl x509 -req -sha256 -days 365 -CA rootCert.pem -CAkey rootKey.pem -CAcreateserial -inserveurNCsr.pem -out serveurNCert.pem

3. chmod 400 serveurNCert.pem

30


2.2.4 Configuration du Client (Application MPlug)

Le client doit négocier des paramètres de connexion TLS avec le serveur distant. Il doit aussi fournirles paramètres qui l’authentifie auprès du serveur distant.Le plugin cordova-plugin-advanced-http permet de confirmer l’identité du serveur en vérifiant laSignatures numériques que contient le Certificat numérique fourni par le serveur. Pour se faire, il sesert du Certificat numérique de l’AC fourni avec l’application. Il vérifie aussi que le nom de domaineauquel il accède est le même que le nom de domaine contenu dans le Certificat numérique du serveur(ceci empêche les attaques MiTM avec des certificats numériques inappropriés signés par la mêmeAutorité de certificat de certification ; c’est pour cela qu’on s’assure que les noms de domaines utiliséspar nos différents modules soient différents). Il fournit les méthodes nécessaires.L’application doit fournir avec chaque requête HTTP, les informations qui l’authentifie auprès duserveur (vu que seul le serveur s’authentifie lors de l’établissement de la connexion sécurisée TLS).Pour rendre cela possible, l’utilisateur dispose d’un formulaire dans l’application qui lui permet derenseigner les informations importantes au fonctionnement de l’application à savoir :

• un nom de domaine

• un identifiant

• un mot de passe

2.2.5 Configuration du serveur

Certaines configurations ont besoin d’être faites sur le serveur afin qu’il puisse établir des connexionsTLS avec les clients web. Le serveur par défaut fonctionne en HTTP. Il s’agit ici de configurer leserveur pour qu’il fonctionne en HTTPS (HyperText Transfert Protocol Secure) et aussi pour qu’ilpuisse authentifier les clients dont il reçoit les requêtes. Les librairies ESP8266WebServerSecure.h,ESP8266WiFi.h, ESP8266mDNS.h sont utilisés pour atteindre nos objectifs. Elles sont toutes pré-sentes dans les librairies standards du pack Arduino/esp8266. Nous présentons dans la suite l’utili-sation qui est faite de chacune de ces librairies.

• ESP8266WiFi.h : Elle permet soit de se connecter à un réseau existant soit de créer un pointd’accès. Dans notre cas, elle est utilisé pour créer le point d’accès auquel se connecte le clientweb (l’application mobile). Les paramètres du point d’accès sont intégrés directement dans lecode du module esp8266 et on s’assure qu’ils soient différents (ssid/password) pour chaquemodule. L’idée est de rajouter une couche de sécurité au système M-Plug.

• ESP8266mDNS.h : Elle permet d’activer et de configurer un serveur DNS sur le réseau. Celui-ci permettra au module d’être accessible directement grâce à un nom de domaine et non uneadresse ip. Le nom de domaine doit être le même que celui que contient le Certificat numériquedu serveur.

• ESP8266WebServerSecure.h : Elle est basée sur les librairies BearSSL (permettant les connexionsTLS et adaptée aux conditions du module esp8266) et ESP8266WebServer (permettant les connexionsHTTP). Elle fournit des méthodes permettant de négocier des connexions TLS, d’enregistrer leCertificat numérique et la clé privée du serveur.

31


En dehors des librairies citées, l’esp8266 stocke les identifiants et mots de passe utilisés pour authen-tifier chaque client qui lui envoie des commandes. Ces identifiants et mots de passe, sont différentspour chaque serveur (module esp8266).

Architecture du système M-PlugLa figure 2.4 nous présente un aperçu complet du fonctionnement de la version sécurisée du systèmeM-Plug.

FIGURE 2.4 – Architecture sécurisée du système M-Plug

Conclusion

Ce chapitre a présenté le fonctionnement de notre système ainsi que les outils et les étapes dans saréalisation. La suite sera l’occasion de vérifier que les résultats obtenus sont conformes aux résultatsattendus.

32

Chapitre 3Résultats et Discussions

Introduction

Dans ce dernier chapitre, nous présentons les résultats obtenus après la mise en place des mécanismesde sécurité pour le système M-Plug. Nous utilisons l’outil de captures de paquets réseau Wiresharkpour observer le contenu des paquets transitant dans le système M-Plug. Dans un premier temps,nous observons les informations que nous sommes capables d’obtenir en interceptant les paquetsen transit dans le système M-Plug sous sa version non sécurisée. Dans un deuxième temps, nousreprenons la même expérience sur le système dans sa version sécurisée. Nous observons par la mêmeoccasion, les réactions du client web lorsqu’il subit à une attaque MiTM. Nou terminons en discutantde quelques insuffisances de notre solution.

1 Analyse de paquets du système M-Plug non sécurisé

Dans cette section, nous mettons en évidence les failles du système système M-Plug avant le déploie-ment du protocole TLS. Le système M-Plug utilise le protocole HTTP comme protocole de commu-nication. Les résultats, de l’interception des paquets en transit dans le système, sont présentés à lafigure 3.1. On peut constater que :

1. le protocole HTTP est utilisé dans les communications, comme le montre le champs Protocol ;

2. toutes les requêtes échangées entre le client et le serveur ne sont ni chiffrées, ni encodées. Toutesles données en transit sont donc lisibles comme le montre le champs Info ;

3. tous les paquets peuvent être interceptés, et modifiés en transit en utilisant un proxy, (commel’outil BurpSuite). Le système est donc vulnérable aux vols de sessions (Session Hijacking), àl’attaque MiTM.

33

Chapitre 3. Résultats et Discussions 2. Analyse de paquets du système M-Plug sécurisé

FIGURE 3.1 – Analyse des paquets du système M-Plug non sécurisé

2 Analyse de paquets du système M-Plug sécurisé

L’architecture de base du système M-Plug présente des failles importantes. Il est vulnérable aux at-taques MiTM, les données peuvent être lues et modifiées. Le protocole TLS permet de remédier à cesfailles. Les figures 3.2 et 3.3 nous permettent d’analyser les résultats de l’interception des paquets entransit dans la version sécurisée du M-Plug system.

2.1 Observations de l’échange de clés dans le système M-Plug

La figure 3.2 nous montre les échanges entre notre client M-Plug et notre serveur M-Plug (les tests ontété éffectués avec le navigateur web Firefox) pour établir la connexion sécurisée TLS. Cette figure meten évidence la suite de Chiffrement utilisée dans notre système, le TLS_ECDHE_ECDSA_AES_128_GCM_SHA256. Nous pouvons en déduire ce qui suit :

• l’algorithme utilisé pour l’échange de clés est l’ECDHE. Il permet de générer des paires de clésasymétriques temporaires pour l’échange de clé de session. Il assure aussi le Perfect ForwardSecrecy ;

• l’algorithme utilisé pour la Signatures numériques digitale est l’ECDSA. L’ECDSA utilise desclés de taille très réduites comparativement à l’algorithme DSA dont il est une variante, ce quipermet d’accélérer la production et la vérification des signatures ;

• l’algorithme à clé symétrique AES en mode GCM (Galois Counter Mode) est utilisé pour géné-rer des clés de session de 128 bits ;

• l’algorithme utilisé pour le hash des messages est le SHA.

2.2 Observations des données applicatives dans le système M-Plug

La figure 3.3 nous permet d’observer les données applicatives échangées entre le client et le serveur.On peut remarquer que les données sont entièrement chiffrées et ne sont donc pas lisibles.

34

Chapitre 3. Résultats et Discussions 2. Analyse de paquets du système M-Plug sécurisé

FIGURE 3.2 – Analyse des paquets (Handshake) du système M-Plug sécurisé

FIGURE 3.3 – Analyse de paquets (Application Data) du système M-Plug sécurisé

2.3 Observations des réactions du client M-Plug face à une attaque MiTM

Pour nous rassurer que le système M-Plug fonctionne et réagit dans le sens voulu, il est important dele soumettre à un cas d’attaque. L’outil Ettercap a été utilisé (sur une distributiom Kali-Linux) pourperpétrer une attaque MiTM contre le système. La figure 3.4 nous permet d’observer les réactionsengendrées par le client web dans les communications lors de cette attaque.Nous observons dans la liste des paquets présentés par Wireshark, à la ligne 474 que le client webrenvoie un message de type Alert avec pour information Level : Fatal, Description :Bad Certificate (dansle champs info de la fenêtre Wireshark). En suite il met fin à la connexion en cours. Nous pouvonsalors conclure que le système (le client web spécialement) est capable de contrecarrer des attaquesMiTM.

35

Chapitre 3. Résultats et Discussions 3. Discussions

FIGURE 3.4 – Analyse de paquets (Attaque MiTM) du système M-Plug sécurisé

3 Discussions

Le système M-Plug dans sa phase initiale, a été conçu sans aucun mécanisme de sécurité. Il pouvaitêtre manipulé à des fins de vols de données (habitudes utilisateurs) et compromettre ainsi la vie pri-vée des utilisateurs. Face à ces menaces, nous devions proposer un protocole de sécurité qui répon-drait à des objectifs de sécurité tels que la confidentialité, l’intégrité des données, l’authentification.Le protocole TLS permettait d’atteindre les objectifs de sécurité fixés pour le système. En plus d’êtreéfficace et en raison des ressources disponibles, l’implémentation du protocole TLS se devait légèrece qui a été rendu possible grâce à la cryptographie à courbes elliptiques qui permet de procurer uneforte sécurité tout en utilisant des tailles de clés très réduite. La cryptographie à courbes elliptiquesprésente donc un avantage majeur par rapport à d’autres algorithmes tels que RSA, Diffie-Hellmanetc.Les résultats issus de l’implémentation du protocole TLS montre que les données échangées dans lesystème M-Plug sont à l’abri des tentatives indiscrètes de lecture et des modifications de donnéesen transit. Loin d’être parfait, certains aspects de la sécurité du système pourrait être améliorés. Onpourrait entre autres, travailler à réduire le temps de latence qu’impose le protocole TLS au systèmepour l’établissement de connexions sécurisées. Ceci passe par la gestion des mécanismes de reprisede sessions TLS, et de persistence de connexions HTTP.

Conclusion

Ce chapitre a fait l’objet d’une présentation des résultats obtenus après l’implémentation de notresystème. Il a été question de comparer l’état du système initial et celui du système finalement obtenu.Les insuffisances liées à la solution ont été soulevées et seront utilisées comme base pour formulerles perspectives.

36

Conclusion et Perspectives

Les systèmes de smart plugs occupent une place dans la vie privée et les habitudes quotidiennesdes utilisateurs. Ces derniers ont la capacité de transformer une maison banale en une maison tota-lement intelligente.En dépit du confort et de la commodité qu’ils peuvent procurer, ils représentent des vecteurs d’at-taques, qui exploités correctement, peuvent porter atteinte à la sécurité et à la vie privée de l’utilisa-teur. Il est primordiale de mettre en place les mécanismes de sécurité nécéssaires pour protéger lessystèmes de smart plugs contre les attaques courantes dans un cyber-environnement. Ces systèmesétant sévèrement limités en ressources, tous les mécanismes de sécurité ne sont pas bon à utiliser,autrement ils ralentissent et provoquent un déni de service dans le système.Dans ce mémoire, nous avons mis en place le protocole TLS. Il garantit la confidentialité et l’intégritédes données échangées à l’intérieur du système. La Cryptographie à courbes elliptiques a été utiliséecomme Cryptosystème de base du protocole TLS parce qu’elle produit des clés cryptographiquesrelativement courtes pour le niveau de sécurité qu’elles offrent, garantissant ainsi un minimum delatence. D’autres mécanismes ont été mis en place notamment un procédé d’authentification des sys-tèmes clients, les valeurs aléatoires différentes pour les noms de domaine des serveurs afin de déjouerles attaques de l’homme du milieu.

Le travail éffectué dans ce mémoire peut être amélioré et corrigé. Nous envisageons les améliora-tions suivantes :

• le développement d’un programme qui permettra de façon abstraite, la création et la gestion del’Autorité de certificat, l’automatisation de la production des certificats numériques serveurs,des noms de domaines associés, et même la personnalisation et le téléversement du code dechaque module ;

• la mise en place d’un mécanisme de mise à jour des certificats numériques embarqués dans lesmodules déployés ;

• l’utilisation des méthodes d’authentification natives du protocole HTTP pour l’authentificationdu client ;

• l’amélioration de l’application mobile pour assurer des ouvertures de session au préalable afinde masquer la latence du système à l’utilisateur.

Ces perspectives permettront de rendre le système MPlug plus robuste et plus éfficace pour la desti-nation à laquelle il est destiné. Ils permettront aussi d’améliorer l’expérience des utilisateurs.

37

Bibliographie

[1] Baier, Harald and Buchmann, Johannes, The advantages of elliptic curve cryptography for wirelesssecurity, 2002.

[2] Mehuron W, Digital Signature Standard (DSS). US Department of Commerce, National Institute ofStandards and Technology (NIST), 1994.

[3] Koblitz, Neal, Elliptic curve cryptosystems, 2006.

[4] Brown D, Standards for efficient cryptography, SEC 1 : elliptic curve cryptography, 2009.

[5] Santoso, Freddy K and Vun, Nicholas CH, Securing IoT for smart home system, IEEE, 2015.

[6] Kodali, Ravi Kishore and Naikoti, Ashwitha, ECDH based security model for IoT using ESP8266,IEEE, 2016.

[7] Gupta, Vipul and Stebila, Douglas and Fung, Stephen and Shantz, Sheueling Chang and Gura,Nils and Eberle, Hans, Speeding up Secure Web Transactions Using Elliptic Curve Cryptography.,NDSS, 2004.

[8] Davies, Donald W and Wyn, L, Price. 1980. The application of digital signatures based on public-keycryptosystems.

[9] Miller, Victor S, Use of elliptic curves in cryptography, Springer, 1985.

[10] Malik, Muhammad Yasir, Efficient implementation of elliptic curve cryptography using low-powerdigital signal processor, IEEE, 2010.

[11] Azad ; Saiful, Practical Cryptography : Algorithms and Implementations using C++, CRC Press, 978-1-4822-2889-2,978-1-4822-2890-8, 2014.

[12] Boris Adryan ; Dominik Obermaier ; Paul Fremantle, The Technical Foundations of Iot, ArtechHouse Publishers, 978-1-63081-251-5,163081251X, 2017.

[13] Jean-Philippe Aumasson, Serious Cryptography : A Practical Introduction to Modern Encryption, NoStarch Press, 1593278268,9781593278267, 2017.

[14] Stallings, William, Cryptography and network security principles and practice, Pearson,1292158581,978-1-292-15858-7, 2017.

[15] Bruce Schneier, Applied Cryptography : Protocols, Algorithms, and Source Code in C, Wiley,0471128457,9780471128458, 1995.

38

[16] Ravulavaru, A.7, Learning Ionic, Packt Publishing, 9781786464576, 2017.

[17] Griffith, C., Mobile App Development with Ionic, Revised Edition : Cross-Platform Apps with Ionic,Angular, and Cordova, O’Reilly Media, 9781491998090, 1995.

[18] Katz, Jonathan and Menezes, Alfred J and Van Oorschot, Paul C and Vanstone, Scott A, Handbookof applied cryptography, CRC press, 1996.

[19] Paar, Christof and Pelzl, Jan, Understanding cryptography : a textbook for students and practitioners,Springer Science & Business Media, 2009.

39

Webographie

[20] Alarm.com, What Is a Smart Plug?, http://www.alarm.com/blog/what-is-smart-plug,consulté le 1er Août 2018.

[21] Gia Lu, What is a smart plug? Here’s all you need to know, https://www.digitaltrends.com/home/what-is-a-smart-plug/, consulté le 02 Août 2018.

[22] Thomas Pornin,BearSSl - Overview, https://bearssl.org/, consulté le 06 Août 2018.

[23] Wikipedia, ESP8266, https://fr.wikipedia.org/wiki/ESP8266, consulté le 13 Août2018.

[24] Wikipedia, Échange de clés Diffie-Hellman, https://fr.wikipedia.org/wiki/échange_de_clés_Diffie-Hellman, consulté le 22 Août 2018.

[25] Wikipedia, Cryptographie sur les courbes elliptiques, https://fr.wikipedia.org/wiki/Cryptographie_sur_les_courbes_elliptiques, consulté le 23 Août 2018.

[26] Ionic, cordova-plugin-advanced-http, https://ionicframework.com/docs/native/http/,consulté le 30 Septembre 2018.

[27] OpenSSL, OpenSSL, https://www.openssl.org/, consulté le 27 Juillet 2018.

[28] Arduino, Arduino, https://www.arduino.cc/, consulté le 14 Juin 2018

40

http://www.alarm.com/blog/what-is-smart-plug

https://www.digitaltrends.com/home/what-is-a-smart-plug/

https://www.digitaltrends.com/home/what-is-a-smart-plug/

https://bearssl.org/

https://fr.wikipedia.org/wiki/ESP8266

https://fr.wikipedia.org/wiki/�change_de_cl�s_Diffie-Hellman

https://fr.wikipedia.org/wiki/�change_de_cl�s_Diffie-Hellman

https://fr.wikipedia.org/wiki/Cryptographie_sur_les_courbes_elliptiques

https://fr.wikipedia.org/wiki/Cryptographie_sur_les_courbes_elliptiques

https://ionicframework.com/docs/native/http/

https://www.openssl.org/

https://www.arduino.cc/

41

Documents

Intégration du protocole TLS basé sur la cryptographie à ... · Sigles et Abréviations AC : Autorité de Certiﬁcat6,28–31 AES : Advanced Encryption Standard14,26,30,34 CBC