Université de la RéunionUFR Sciences et Technologies

Rapport de stage de Master M2 INFORMATIQUE

Laboratoire d’Informatique et de Mathématiques

Communication stéganographique baséesur la consommation énergétique des

smartphones

Auteur :Kévin Hoarauno étudiant : 32001076

Encadrants :Dr. Pierre Ugo Tournoux

Responsable de stage :

Dr. Pascal Anelli

Période du stageJanvier - Juin 2017

© LATEX style made by David Laï-Yock (2016)

II

Remerciements

Je tiens à remercier Dr. Pierre Ugo Tournoux pour son encadrement, sa disponibilitéet ses bons conseils. Je remercie Pr. Dali Kaafar d’avoir proposé ce sujet de stage ainsique pour son encadrement. J’adresse également mes remerciements à Dr. Dominique Gaypour l’aide qu’il m’a apportée à plusieurs reprises. Je remercie Dr. Pascal Anelli d’avoirrendu ce stage possible. Je remercie Pr Rémy Courdier et Dr. Denis Payet pour m’avoirprésenté leurs travaux de recherche. Je tiens à remercier Taher Issoufaly, Irène Velontrasinaet Maurica Fonenantsoa pour leur accueil, leur bonne humeur et leurs conseils. Je remercieégalement tous les doctorants du LIM et mes collègues stagiaires pour l’ambiance agréablede travail.

III

IV

Résumé

Lorsqu’il est question d’établir une communication cachée, le chiffrement de l’infor-mation n’est pas toujours adapté puisqu’il peut éveiller des soupçons. La stéganographieapporte une solution à ce problème en permettant de dissimuler la présence de la commu-nication plutôt que son contenu. D’abord appliquées aux objets numériques, les techniquesstéganographique ont beaucoup évolué jusqu’à être utilisées pour déjouer les mécanismesde sécurité des smartphones. C’est dans ce contexte que s’inscrit ce stage dont l’objec-tif est d’établir un canal de communication stéganographique basée sur la consommationénergétique. Ce canal de communication doit permettre un échange unidirectionnel de-puis une tierce partie distante vers un smartphone. Notre proposition consiste à exploiterl’empreinte énergétique induite par la réception d’un message (SMS, Facebook Messen-ger, Mail, etc.) pour encoder le message stéganographique. Ainsi, nous avons mesuré laconsommation énergétique de smartphones sous Android pendant qu’ils recevaient diffé-rents types de messages. Plusieurs techniques d’analyse des données de consommation ontmontré que le système proposé pourrait atteindre un débit de 2 bits par minutes avec untaux d’erreurs inférieures 10%. De plus, c’est résultats montrent qu’il est possible d’inférerdes informations d’activités à partir de la consommation énergétique ce qui pose un réelproblème pour le respect de la vie privée des utilisateurs.

Mots-clés : stéganographie, canal caché, consommation énergétique, smartphone

Abstract

When we talk about establishing a hidden communication, information encryption doesnot always fit well as it may be suspicious. Steganography give a solution to this problemby allowing to hide the presence of communication instead of its content. First applied todigital objects, stereographic techniques have evolved considerably as far as being used fordefeat smartphone security mechanisms. It is in this context that this internship is takingplace with the aim of establishing a steganographic communication channel based on po-wer consumption. This channel must allow a unidirectional communication from a remotethird party to a smartphone. Our proposal is to exploit the power fingerprint induce by thereception of a message (SMS, Facebook Messenger, Mail, etc.) to encode the steganogra-phic message. Thus, we measured the power consumption of some Android smartphoneswhen they receiving different type of message. Several technic of power data analysis sho-wed that the proposed system could reach a throughput of 2 bits per minutes with anerror rate lower than 10%. Furthermore, these results show that it is possible to infer ac-tivity information from a device power consumption which is a real threat for user privacy.

Keywords : steganography, covert channel, power consumption, smartphone

V

VI

Table des matières

1 Introduction 1

2 État de l’art 22.1 La stéganographie moderne . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1.1 Origine et définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.2 Métriques de performances . . . . . . . . . . . . . . . . . . . . . . . 32.1.3 Évolution de la stéganographie . . . . . . . . . . . . . . . . . . . . . 4

2.2 Exploitation des ressources physique . . . . . . . . . . . . . . . . . . . . . . 52.2.1 Communication par canal caché . . . . . . . . . . . . . . . . . . . . . 52.2.2 Attaque par canal auxiliaire . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Application aux smartphones . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.1 La collusion entre applications . . . . . . . . . . . . . . . . . . . . . 92.3.2 Canaux cachés distants . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.3 Analyse de la consommation énergétique . . . . . . . . . . . . . . . . 15

3 Contributions 193.1 Notre proposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.2 Système stéganographique proposé . . . . . . . . . . . . . . . . . . . 203.1.3 Possibilités d’encodage . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Acquisition des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.1 Solution retenue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.2 Événement de réception de message . . . . . . . . . . . . . . . . . . 223.2.3 Application développée . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Environnement de mesure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.1 Protocoles de mesure . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.2 Envoi automatique de message . . . . . . . . . . . . . . . . . . . . . 25

3.4 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4.1 Plate-forme d’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4.2 Visualisation des mesures . . . . . . . . . . . . . . . . . . . . . . . . 273.4.3 Moyenne glissante . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5 Détection de message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.5.1 Problème posé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.5.2 Solutions proposées . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

VII

3.5.3 Recherche des meilleures performances . . . . . . . . . . . . . . . . . 323.5.4 Résultats obtenus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Conclusion 36

A Annexes 42A.1 Présentation du LIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42A.2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42A.3 MOOC : Applied Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . 43

A.3.1 Unité 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43A.3.2 Unité 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44A.3.3 Unité 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44A.3.4 Unité 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44A.3.5 Unité 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44A.3.6 Unité 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44A.3.7 Unité 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

A.4 Résultats de détection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.4.1 Un seul fichier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.4.2 Plusieurs fichiers (Approche simple) . . . . . . . . . . . . . . . . . . 46A.4.3 Plusieurs fichiers (Approche par slot) . . . . . . . . . . . . . . . . . . 47

VIII

Table des figures

2.1 Système stéganographique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Interdépendance entre capacité, sécurité et robustesse . . . . . . . . . . . . 42.3 Classification des techniques stéganographique . . . . . . . . . . . . . . . . 62.4 Sécurité sous Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Collusion entre applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Système stéganographique proposé . . . . . . . . . . . . . . . . . . . . . . . 213.3 Application Android pour la mesure . . . . . . . . . . . . . . . . . . . . . . 243.4 Fichiers de log de consommation et de notification . . . . . . . . . . . . . . 243.5 Envoi périodique de message Facebook et Gmail . . . . . . . . . . . . . . . 263.6 Envoi périodique de SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.7 Envoi aléatoire de message (SMS, Facebook, Gmail) . . . . . . . . . . . . . 273.8 SMS (courant échantillonné à 100ms) . . . . . . . . . . . . . . . . . . . . . . 283.9 Message Facebook (courant échantillonné à 100ms) . . . . . . . . . . . . . . 283.10 Mail (courant échantillonné à 100ms) . . . . . . . . . . . . . . . . . . . . . . 283.11 SMS avec moyenne glissante sur 10 valeurs . . . . . . . . . . . . . . . . . . 293.12 Analyse par slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.13 Détection par seuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.14 Détection par seuil adaptatif . . . . . . . . . . . . . . . . . . . . . . . . . . 323.15 Détection par distribution statistique . . . . . . . . . . . . . . . . . . . . . . 33

IX

Liste des tableaux

2.1 Débit des canaux cachés implémenté dans [24] . . . . . . . . . . . . . . . . . 132.2 Débit de quelques canaux cachés réseaux . . . . . . . . . . . . . . . . . . . . 15

3.1 Comparaison des méthodes d’analyse . . . . . . . . . . . . . . . . . . . . . . 31

A.1 Organisation des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

X

Chapitre 1

Introduction

L’analyse de la consommation énergétique d’un système peut permettre d’inférer desinformations sur son état. Cela a déjà été démontré dans la littérature avec les systèmesde chiffrements. La récupération des clés de chiffrement contenue dans les cartes à puceest un exemple célèbre de ce type d’attaques. S’inscrivant dans le domaine des attaquespar canaux auxiliaires, elles partent du principe que la sécurité théorique d’un systèmene garantit pas la sécurité de son implémentation physique. Les smartphones ne font pasentorse à cette règle et leur consommation énergétique peut donc potentiellement laissertransparaître des informations sur leur activité. C’est sur ce constat que s’appuie ce sujetde stage qui vise à exploiter la consommation énergétique des smartphones pour établirune communication stéganographique.

La proposition faite dans ce stage est de détecter la réception d’un message sur unsmartphone par l’analyse de sa consommation énergétique. En effet, lorsqu’un smart-phone reçoit un message il doit effectuer un certain nombre d’actions tel que réveillerla carte réseau ou activer l’application concernée par le message. Ces actions conduisentà une consommation d’énergie que nous souhaitons évaluer. Si cette consommation quenous appellerons empreinte énergétique est suffisamment identifiable, nous pouvons alorsl’utiliser pour détecter la réception des messages. Une application ne disposant pas depermission pour l’accès au réseau pourrait ainsi détecter la réception de messages en ana-lysant la consommation énergique du smartphone sur lequel elle est installée. De même,une tierce partie distante serait capable d’envoyer des informations vers cette applicationen exploitant ce canal auxiliaire énergétique. Un exemple d’encodage de l’information peutêtre qu’ un bit « 1 » correspond à la détection d’un message et un bit « 0 » à son absence.La problématique posée par ce stage est donc de déterminer si la réception d’un messagepar un smartphone possède une empreinte énergétique identifiable et sous quelles mesurescette empreinte peut être utilisée pour sa détection.

Pour répondre à la problématique, nous commencerons au chapitre 2 par dresser unétat de l’art dans lequel nous nous intéresserons aux origines de la stéganographie mo-derne, à l’exploitation des ressources physique d’un système et aux applications de cesdeux thématiques sur les smartphones. Puis, au chapitre 3 nous présenterons notre propo-sition de système stéganographique, les travaux effectués et les résultats obtenus. Enfin,au chapitre 4 nous conclurons sur la réponse apportée à la problématique.

1

Chapitre 2

État de l’art

2.1 La stéganographie moderne

La stéganographie peut être définie comme l’art et la science de dissimulé de l’infor-mation. Ainsi, à l’opposé de la cryptographie dont le but est de cacher le contenu d’unmessage, la stéganographie cherche à dissimuler la présence même de ce message.

2.1.1 Origine et définitions

Avant d’être une science, la stéganographie était un art que l’on présume plus ancienque la cryptographie. L’utilisation de procédés stéganographique peut ainsi être remontéejusqu’à l’antiquité. L’apparition de la stéganographie moderne quant à elle peut être attri-buée à G. Simmons, qui en 1984, énonça le problème des prisonniers [1]. Dans ce problème,Simmons place deux prisonniers qui souhaitent élaborer un plan d’évasion. Cependant,tous leurs échanges sont contrôlés par un gardien qui au moindre soupçon placerait un desdétenus en zone de confinement. Les deux complices doivent donc trouver un moyen decommuniquer sans éveiller les soupçons. C’est ici qu’intervient la stéganographie en leurpermettant de dissimuler un message caché à l’intérieur d’un autre message qui ne semblepas suspect.

La stéganographie moderne telle que définie dans [2, 3] consiste à dissimuler de l’in-formation dans des objets numériques. Cela est rendu possible par la modification d’uncertain nombre de bits dont l’altération n’a pas d’effet visible sur l’objet résultant. Afinque cette modification soit indétectable, l’objet original doit être gardé secret, car unecomparaison entre ce dernier et l’objet résultant révélerait l’altération. De plus, à l’ins-tar de la cryptographie, la stéganographie moderne vise à obéir au principe de Kerckoffsqui dit que la sécurité d’un système de chiffrement doit reposer uniquement sur une clésecrète. Dans [3], les auteurs donnent une définition formelle d’un système stéganogra-phique respectant ce principe. Ce dernier, illustré par la figure 2.1, implique un émetteuret un récepteur qui communique à travers un canal public. Pour dissimuler un messagem ∈ M dans un objet x(0) ∈ X* avec une clé secrète k ∈ K, l’émetteur applique lafonction Embed : M × X* × K → X*. Cette fonction produit en sortie un objet stégano-graphique x(m) ∈ X* qui ne peut être distinguer de x(0). Ici, M est l’ensemble de tous les

2

Embed()

key

cover

secretmessage

k

x(0)

mExtract()

key

k

m secretmessage

Sender

stego object

x(m)

RecipientChannel

Figure 2.1 : Système stéganographique

messages possibles, X* l’ensemble des objets qui peuvent être envoyés sur le canal publicet K l’ensemble des clés utilisables. Le récepteur de son côté récupère le message m àpartir de la clé secrète k et de l’objet stéganographique x(m) en appliquant la fonctionExtract : X* × K → M . Le système stéganographique est lui défini par le quintuplet(X*, M, K, Embed, Extract).

2.1.2 Métriques de performances

L’objectif d’une communication stéganographique est d’échanger un maximum de don-nées sans que cela soit détectable. Ainsi, la performance d’un système stéganographiquepeut être évaluée sur trois critères : sa capacité, sa sécurité et sa robustesse.

Capacité

La capacité d’un système stéganographique correspond à la quantité d’information quipeut être dissimulée dans l’objet numérique. De cette valeur, il dérive la bande passantede la communication stéganographique. La capacité dépend à la fois de l’objet utilisé et dela fonction de dissimulation qu’on lui applique (respectivement x(0) et Embed). On peutla définir comme le taux d’information secrète que l’on peut transmettre dans un objet.Pour un objet x(0) de taille n bits, la capacité c d’un système stéganographique peut êtrecalculé tel que c = |m|

n . Cependant, cette mesure peut être difficile à obtenir notammentpour les objets compressés. En effet, dans ce cas la capacité va varier en même temps quele taux de compression de l’objet.

Sécurité

Dans le problème des prisonniers (cf. 2.1.1), la sécurité de la solution stéganographiqueréside dans le fait que le gardien est incapable de détecter la communication secrète.Les actions mises en oeuvre par un tiers pour déceler la présence de stéganographie sontappelées la stéganalyse. On retrouve ainsi dans la littérature aussi bien des travaux portantsur des techniques de stéganalyse [4] que sur des façons de s’en protéger [5]. La stéganalysepose un problème de décision qui pour un objet donné cherche à savoir s’il contient uncontenu caché. La sécurité d’un système stéganographique peut donc être évaluée par sacapacité à mettre en erreur une stéganalyse. Cela revient alors à mesurer le taux d’erreur

3

Capacity

RobustnessSecurity

Secure steganographicDigital watermarking

Naïve steganography

techniques

Figure 2.2 : Interdépendance entre capacité, sécurité et robustesse

commise qui peuvent être de deux types : faux positif et faux négatif. Le premier correspondla détection d’un objet alors que ce dernier ne transporte aucun contenu caché alors quele second correspond à l’échec de détection d’un contenu stéganographique.

Robustesse

Lorsqu’un objet numérique est envoyé à travers un canal, il peut subir des altérations.Ces dernières peuvent être intentionnelles dans l’objectif de détruire un éventuel contenusténographique qui peut être caché dans l’objet. Toutefois, l’objet peut également êtrealtéré par le « bruit » du canal (erreur aléatoire, compression, etc.). Il est donc importantpour un système stéganographique de limiter les conséquences des modifications subiespar l’objet numérique. Ainsi, la robustesse correspond à la difficulté de détruire le contenucaché dans un objet stéganographique. Cette dernière peut être mesurée par la quantitéde distorsion appliquée à l’objet.

Un système stéganographique parfait optimiserait ces trois propriétés, cependant ellessont interdépendantes. En effet, si l’on prend le cas d’une image comme support stégano-graphique, le fait d’accorder plus d’espace à la robustesse va diminuer la capacité. De lamême manière, augmenter la capacité introduit plus de distorsion dans l’image et diminuedonc la sécurité. C’est donc en fonction de l’application qui sera faite du système qu’unéquilibre en capacité, sécurité et robustesse doit être trouvé. Dans [6] les auteurs ont illus-tré cette interdépendance sous la forme d’un triangle (figure 2.2). On y voit par exempleque pour le tatouage numérique (ou « Digital watermarking ») la capacité et la sécuriténe sont pas très importantes à l’inverse de la robustesse. Cela s’explique par le fait quecette discipline vise à protéger du contenu sous licence et donc que le tatouage doit êtreimpossible (ou très difficile) à enlever sans détruire le contenu.

2.1.3 Évolution de la stéganographie

Nous avons défini la stéganographie moderne (section 2.1.1) comme l’ensemble des tech-niques permettant de dissimuler de l’information dans des objets numériques. Cependant,l’évolution de la stéganographie jusqu’à aujourd’hui nécessite de compléter cette défini-tion. Ainsi, pour une meilleure organisation de ma recherche bibliographique nous avonsétabli une classification des techniques stéganographique (figure 2.3). Cette classificationn’est pas exhaustive et des domaines tels que tatouage numérique ont volontairement étéomis, car il n’entre pas dans le champ de notre travail. Par ailleurs, une classification plus

4

générale des techniques de dissimulation d’information a déjà été présentée dans [7]. Denotre côté, nous avons réparti ses techniques dans deux catégories. La première correspondà la définition que nous avons faite de la stéganographie moderne et agit sur des objetsnumériques (image, audio, vidéo, etc.). La seconde, que nous allons détailler ci-dessous,vise à créer un canal de communication caché.

Canal caché

Les canaux cachés consistent à créer un canal de communication entre deux entitéssans que cela soit visible et connu. Ils posent donc des problèmes de sécurité importants enpermettant par exemple une communication non autorisée. Les canaux cachés s’appuientsur des techniques stéganographique pour dissimuler la communication. Dans notre clas-sification (figure 2.3) nous les avons réparties de deux groupes :

— Locaux : les canaux cachés locaux ont pour objectif établir une communication entredeux entités se trouvant sur le même système physique. Ces entités pouvant être parexemple deux processus s’exécutant sur le même système d’exploitation [8, 9], maisaussi deux machines virtuelles [10, 11]. La communication cachée peut aussi êtreétabli au niveau logiciel en exploitant des caractéristiques du système d’exploitationou de l’API qu’il offre, que au niveau matériel en se basant par exemple sur la chargeCPU ou la température de certains composants.

— Réseaux : les canaux cachés réseau permettent une communication entre deux enti-tés distantes (i.e situés sur des systèmes physiques différents). Pour cela, différentescouches de la pile OSI peuvent être exploitées, par exemple les bits de bourrage pourla couche physique [12], l’en-tête IP pour la couche réseau [13] et le protocole HTTPpour la couche applicative [14]. Dans [15] les auteurs ont classé quelques travaux decanal caché réseau en fonction de la couche OSI qu’ils utilisent pour dissimuler lacommunication.

2.2 Exploitation des ressources physique

L’objectif de ce stage est d’utiliser la consommation énergétique pour établir une com-munication cachée. Nous avons vu dans la partie précédente (section 2.1) l’état actuel de larecherche dans le domaine stéganographique. Nous allons donc maintenant nous intéresseraux possibilités d’exploitation des ressources physiques (telle que l’énergie) présente dansla littérature.

2.2.1 Communication par canal caché

Nous avons vu à la section 2.1.3 que les canaux cachés peuvent compromettre la sécuritéd’un système en permettant une communication non autorisée entre deux entités. Nousallons voir maintenant quelques exemples de canaux cachés qui peuvent être créés enexploitant les ressources physiques d’un système. Pour cela, nous nous plaçons dans le

5

Steganography

Covert channel Digital object

Local Network

Sofware Hardware Physical Network Application

Image Audio Video

API OS Load Temp. Padding IP Header HTTP Protocol

Figure 2.3 : Classification des techniques stéganographique

contexte où deux processus souhaitent établir un canal caché unidirectionnel. On notePS le processus source et PR le processus récepteur. PS envoie des informations à PR

en utilisant un codage binaire. Nous allons voir ci-dessous que de tels canaux cachés sontcapables de déjouer les mécanismes de sécurité mis en oeuvre dans des systèmes largementutilisés de nos jours.

Plate-forme Multicoeur

Dans l’objectif de se protéger de problèmes de sécurités tel que les canaux cachés,certaines plates-formes multicoeurs utilisent des mécanismes d’isolation. Ces derniers ontpour objectif d’empêcher une communication entre deux processus non autorisés. Ainsi,une technique répandue d’isolation est le partitionnement des ressources qui permet decréer des conteneurs dans lequel s’exécutent des processus sensibles. Le partitionnementdes ressources est généralement effectué de deux manières :

— Spatial : le partitionnement spatial permet d’isoler des processus en leur affectantdifférentes ressources physiques. Par exemple, deux processus n’utiliseront pas lemême coeur du processeur. Cela permet donc d’isoler les processus tout en permet-tant une exécution simultanée.

— Temporel : avec le partitionnement temporel, les processus s’exécutent dans desportions de temps différentes. Ainsi, contrairement au partitionnement spatial, lesprocessus partagent les mêmes ressources physiques.

Ces techniques sont déjà implémentées dans les processeurs actuels avec par exempleIntel Trusted Execution Technology [16] qui utilise un partitionnement temporel des res-sources (CPU, mémoire). Les technologies Intel Software Guard Extensions [17] et ARMTrustZone [18] quant à elle s’appuient à la fois sur un partitionnement temporel pour le

6

CPU et sur un partitionnement spatial pour la mémoire.

Malgré l’efficacité que peuvent avoir ces techniques pour contrer les canaux cachésbasés sur les ressources partagés entre les applications, d’autres approches sont toujourspossibles. Nous souhaitons démontrer ici qu’il est possible de créer un canal caché en ex-ploitant des ressources physiques du système. Nous avons donc retenu deux techniquesprésentent dans la littérature qui s’appuient sur des composants matériels différents :

— Température des coeurs : dans leur papier [8] les auteurs présentent deux tech-niques d’exploitation de la température des coeurs d’un processeur. La premières’appuie sur la propagation de la chaleur au coeur voisin pour contourner le parti-tionnement spatial. La seconde profite de la chaleur rémanente d’un calcul précédantpour dépasser le partitionnement temporel. Pour envoyer un bit « 1 », le processussource PS va alors effectuer un calcul lourd pour augmenter la température du coeursur lequel il s’exécute. À l’inverse pour un bit « 0 » il ne fera aucun calcul pour lais-ser la température redescendre. Le processus PR examinant la température de soncoeur va alors lire ce codage binaire.

— Générateur de nombres aléatoires : les générateurs de nombres aléatoires, enanglais « random number generator » (RNG), sont des dispositifs permettant de pro-duire des suites de nombre pseudo aléatoires. Ces dispositifs sont utilisés entre autrespour les procédés cryptographiques. Ainsi, certains processeurs actuels implémententdes RNG au niveau matériel (Intel [19], IBM [20]). Cependant, le module RNG estpartagé entre tous les coeurs du processeur et deux processus séparés spatialementpeuvent y accéder en même temps. Les auteurs de [9] ont montré qu’il était possibled’exploiter cette propriété pour contourner l’isolation spatiale. Pour envoyer un bit« 1 », le processus PS va saturé le RNG pour que les demandes de nombre aléatoirede PR échouent. Pour un bit « 0 », PS ne fait rien pour que les demandes de PR

réussissent. De son côté, PR effectue des demandes régulières de nombre aléatoireset décode le message en fonction des échecs et réussites.

Environnements mutualisés

Les environnements mutualisés permettent de partager la puissance de calcul et l’es-pace de stockage entre plusieurs entités. Cela permet de mieux exploiter les ressources etoffre de nombreux avantage donc une réduction des coûts. Dans ces environnements, unebonne isolation est très importante puisqu’on ne sait pas avec qui on partage le supportphysique. On peut avoir le sentiment que cette isolation est bien garantie, car dans ce typed’environnement on dispose d’une instance d’un système d’exploitation qui s’exécute surdes ressources physiques virtuelles. Cependant, à l’instar des systèmes multicoeurs, les en-vironnements mutualisés peuvent également être victime d’attaque basée sur les ressourcesphysiques. Nous allons donc voir deux exemples d’exploitation matérielle qui peuvent êtreeffectués sur deux types d’environnements largement utilisés de nos jours :

7

— Machines virtuelles : pour pouvoir exécuter plusieurs systèmes d’exploitation surune même machine physique, on s’appuie sur un hyperviseur. Il en existe plusieurssur le marché dont le projet open source Xen. Dans [10] les auteurs montrent qu’ilest possible de créer un canal caché entre deux machines virtuelles s’exécutant surXen. Ils utilisent pour cela la charge processeur en partant du postulat que les deuxmachines virtuelles (que nous noterons V M1 et V M2) sont rattachées au mêmecoeur. Sous Xen, lorsque que VM1 exécute quelque chose, V M2 est en attente. SurV M1, PS effectue du calcul pour envoyer un bit « 1 » et ne fait rien pour envoyerun bit « 0 ». V M2 sait qu’un calcul C prend un temps t pour être effectué lorsqu’au-cune machine n’utilise le processeur. De façon régulière, V M2 effectue C et mesurele temps t′ pris pour le faire. Si t′ > t alors un bit « 1 » est reçu, sinon c’est un « 0 ».

— Environnement de « cloud computing » : dans [11] les auteurs présentent uneméthode pour établir un canal caché basé sur la contention des disques durs dansles infrastructures de « cloud computing ». Dans leur proposition, PS et PR sontdans des environnements séparé mais sur le même disque dur physique. Ainsi, si PS

lit des fichiers frénétiquement, PR vas voir son temps accès disque augmenter. Pourenvoyer un bit « 1 », PS lis des fichiers aléatoirement et ne fais rien pour un bit « 0 ».PR lit des fichiers régulièrement en mesurant son temps accès disque pour décoderle message binaire.

2.2.2 Attaque par canal auxiliaire

Lorsqu’on parle d’exploitation des ressources physiques d’un système, les attaques parcanal auxiliaire sont un exemple en la matière. Principalement utilisé en cryptographie,leur objectif est d’obtenir des informations sensibles en exploitant les failles dans l’implé-mentation physique d’un système. Différents effets physique due aux opérations effectuéespar un système de chiffrement peuvent être exploité, par exemple :

— le temps pris pour effectuer un calcul

— les radiations électromagnétiques émises

— le son produit par le système

— la variation de la consommation énergétique

Les attaques basées sur la consommation énergétique sont particulièrement intéressantespour nous et les cartes à puce sont un cas bien étudié dans ce domaine. Ainsi, l’analysedifférentielle de la consommation [21, 22] (DPA pour « Differential Power Analysis ») estune méthode statistique qui s’attaque aux cartes à puce exécutant le système de chiffrementDES. En analysant la variation de la consommation énergétique de la carte, la DPA permetde retrouver la clé secrète utilisée.

Étant donné que les canaux auxiliaires permettent de déduire des informations surun système, ils peuvent être utilisés pour créer des canaux cachés. En effet, si on saitqu’une opération peut être repérée à travers un canal auxiliaire, alors on peut l’utilisé

8

pour encoder une information sous forme binaire. Le papier exploitant la températuredes coeurs du processeur [8] présenté à la section 2.2.1 est un exemple de canal auxiliaireutilisé pour créer un canal caché. La littérature sur les canaux auxiliaires est donc un pointd’entrée intéressant pour la création d’un canal caché puisqu’elle peut contenir des pistesà explorer.

2.3 Application aux smartphones

2.3.1 La collusion entre applications

Nous avons vu dans les parties précédentes (2.1.3 et 2.2.1) comment les canaux cachéssont capables de déjouer les mécanismes de sécurité mis en oeuvre dans les environnementsutilisés de nos jours. Dans cette section, nous allons voir que les protections existantes surle système Android peuvent également être mises à mal par l’utilisation de canaux cachéslocaux. Ces derniers sont utilisés pour effectuer de la collusion entre applications afind’unir leur force pour servir un objectif malveillant.

La sécurité sur Android

Les smartphones font partie intégrante de notre vie de tous les jours et sont doncune mine d’or donnée personnelle pour des attaquants. La sécurité de ces données estdonc un point central des environnements. Sous Android, de par le nombre grandissantd’applications disponibles et la diversité de leur provenance, on ne peut pas toujoursaccorder pleine confiance aux applications que l’on installe. Il est donc important que lesapplications évoluent dans un environnement contrôlé afin qu’elles ne puissent pas accéderà des ressources et fonctionnalités pour lesquelles elles n’ont pas d’autorisations. Pourassurer cela, Android s’appuie principalement sur deux mécanismes :

1. L’isolation des applications dans des « sandbox »

2. Un contrôle d’accès basé sur des permissions

Ces mécanismes de sécurité sont représentés sur la figure 2.4 et détaillés ci-dessous :1. Le système Android est construit au-dessus du noyau Linux et tire profit des mé-

canismes de sécurité qu’il offre [23]. Plus précisément, c’est le système de protection basésur les utilisateurs qui est exploité pour isoler les applications. Ainsi, pour chaque appli-cation, Android crée un utilisateur Linux unique avec un accès restreint aux ressources dusystème. C’est dans cet environnement utilisateur, appelé « sandbox » (i.e bac à sable),qu’une instance de la machine virtuelle Dalvik (ou ART depuis Android 5.0) s’exécute.Cette machine virtuelle va par la suite interpréter le code Java de l’application. On notetoutefois que la machine virtuelle Dalvik/ART n’a pas pour objectif d’assurer l’isolationde l’application. En effet, sous Android, les développeurs ont la possibilité d’écrire du codenatif qui sera exécuté en dehors de la machine virtuelle. Cependant, cela ne comprometpas la sécurité du système étant donné que le « sandbox » de l’application se situe dansle noyau Linux. Le code natif est donc aussi sécurisé que celui qui est interprété.

2. En plus du système de « sandbox » dans lequel les applications sont exécutées, An-droid utilise un mécanisme de permission. Chaque application déclare ainsi explicitement

9

Permissions check

Contacts App

Contacts data Network

Weather App

Dalvik / ART Dalvik / ART

Linux User ID : 12345 Linux User ID : 54321

Figure 2.4 : Sécurité sous Android

les permissions dont elle a besoin pour son fonctionnement. Lors de l’exécution de l’appli-cation, Android vérifie que l’application dispose de la permission pour la fonctionnalité oula ressource demandée avant de lui offrir l’accès.

Utilisation des canaux cachés

Le mécanisme de sécurité que nous venons de voir est très efficace pour empêcher uneapplication d’avoir accès à des ressources sensibles. Cependant, il ne prend pas en consi-dération le fait que plusieurs applications (généralement deux) puissent être complices.Ce comportement est appelé la collusion entre applications et consiste à établir un canalcaché (c.f section 2.1.3) entre deux applications afin de combiner leurs permissions. Ainsi,deux applications provenant d’un même développeur malintentionné et paraissant inno-cente prises toutes seules peuvent poser d’importants risques de sécurité si un canal cachéest établi entre elles. La figure 2.5 illustre un exemple de collusion entre une application degestion de contact et une autre qui fournit des informations météorologiques. La premièredispose des permissions nécessaires pour lire les contacts alors que la seconde à accès ainternet pour mettre à jour les informations météorologiques. Une fuite des données decontact vers internet est donc possible par établissement d’un canal caché entre ces deuxapplications.

Comme nous l’avons à la section 2.2.1, les mécanismes d’isolation ne permettent pasde contrer toutes les possibilités de canaux cachés. Android ne déroge pas à cette règle etmalgré son système de « sandbox » l’établissement de certains canaux cachés reste possible.Ces derniers ouvrent alors la voie à la collusion entre applications. Dans [24], les auteursont classé les canaux cachés pouvant être utilisés pour de la collusion entre applicationsen trois catégories :

— Niveau application : ce type de canal caché est considéré de haut niveau puisqu’ilexploite les fonctions disponibles dans l’API mise à la disposition des développeurs.

— Niveau système d’exploitation : ces canaux cachés agissent au niveau du sys-tème d’exploitation s’exécutant sur le smartphone au travers d’appel natif. Dans le

10

Permissions check

Contacts App

Contacts data Network

Weather App

Dalvik / ART Dalvik / ART

Linux User ID : 12345 Linux User ID : 54321

Source Sink

Covert channel

Figure 2.5 : Collusion entre applications

cas d’Android, cela peut consister à utiliser des propriétés du noyau Linux.

— Niveau matériel : à l’image des techniques d’exploitation des ressources physiqueprésentée à la section 2.2.1, ce type de canal caché s’appuie sur les propriétés dumatériel constituant le smartphone. Il est donc considéré de bas niveau.

Techniques implémentées

Nous venons de voir que la collusion entre applications peut poser d’importants pro-blèmes de sécurité et qu’elle est réalisable grâce à des canaux cachés pouvant être établis àdifférents niveaux. La faisabilité de tels canaux cachés n’est pas du domaine du théoriquepuisque dans [24] plusieurs canaux cachés ont été implémentés sous Android. De plus, lesauteurs ont mesuré le débit de chacun de ces canaux cachés dont la table 2.1 présente lesrésultats. Les auteurs ont utilisé différentes techniques réparties dans les trois catégoriesprésentées plus haut. Dans la suite, on note AS l’application source et AR l’applicationréceptrice du message caché. Ainsi, ils ont implémenté les techniques suivantes au niveauapplication :

— Paramètres généraux : AS modifie des paramètres généraux tels que le volumedu smartphone. Ce canal est rendu possible par le fait que la majorité des ces pa-ramètres peuvent être modifiés par AS et lues par AR sans permission. Plusieursparamètres peuvent être modifiés simultanément pour augmenter le débit.

— Type d’Intents : Android dispose d’un mécanisme appelé « Intent » qui permetd’envoyer un message à d’autre application pour leur demander d’effectuer une ac-tion (envoyer un mail, sélectionner un fichier, etc.). Ces Intents disposent d’un typeque AS exploite pour encoder un message caché. AR à juste à s’enregistrer auprèsdu système pour recevoir ces Intents.

11

— Intents automatique : la modification de certains paramètres (e.g le paramètrede vibration) conduit à l’envoi d’un Intent automatique sous Android. AS encode lemessage dans la valeur du paramètre qui est transmis par l’Intent automatique. Iciaussi, AR à juste à s’enregistrer auprès du système pour recevoir les Intents auto-matiques.

Au niveau système d’exploitation, ce sont les techniques suivantes qui ont été implémen-tées :

— Énumération des threads : en héritage de Linux, Android dispose du systèmede fichier virtuel « /proc ». qui donne accès à des informations sur le système. Lalecture de ses informations ne requiert pas de permission. Ainsi, AS lance un certainnombre de thread en fonction de la donnée à encoder. Il suffit ensuite à AR de lirele nombre de thread lancé par AS dans « /proc ».

— Découverte de socket Unix : AS ouvre ou ferme un socket pour encoder un bit.AR vérifie l’état du socket pour recevoir le bit.

— Espace libre sur le système de fichier : AS encode le message en écrivant ouen supprimant des fichiers. En regardant l’espace libre sur le système de fichier, AR

est capable de décoder le message.

— Lecture de /proc/stat : cette technique est similaire à celle basée sur l’énuméra-tion des threads à la différence que ce sont les statistiques d’utilisation du processeurqui sont exploité pour encode le message.

Enfin, au niveau matériel les techniques implémentées sont :

— Canal temporel : le principe est le même que dans [10] décrit à la section 2.2.1pour les machines virtuelles. AS effectue des calculs ou ne fait rien pour encoder unbit « 1 » ou « 0 ». AR sait que AS effectue un calcul en mesurant le temps pris pourses propres calculs. Il en déduit alors le bit encodé.

— Fréquence du processeur : afin d’augmenter leur autonomie en énergie, la plu-part des processeurs de smartphone procèdent à un ajustement dynamique de leursfréquences en fonction de leur utilisation. Le message est ici encoder par AS de lamême façon que pour le canal temporel. C’est donc AR qui procède différemmenten déterminant si AS fait un calcul en observant la fréquence du processeur.

2.3.2 Canaux cachés distants

Nous venons de voir dans la section précédente que les canaux cachés locaux pouvaientposer des risques de sécurité sur les smartphones en permettant de déjouer les systèmes de

12

Technique Débit (bps) NiveauParamètres généraux (Multiple / Simple) 262.33 / 56.38 ApplicationType d’Intents 3837.49 ApplicationIntents automatique 71.025 ApplicationÉnumération des threads 148.56 Système d’exploitationDécouverte de socket Unix 2129.35 Système d’exploitationEspace libre sur le système de fichier 11.43 Système d’exploitationLecture de /proc/stat 5.54 Système d’exploitationCanal temporel 3.69 MatérielFréquence du processeur 2.675 Matériel

Table 2.1 : Débit des canaux cachés implémenté dans [24]

protection basés sur des permissions. Nous allons maintenant nous intéresser aux canauxcachés distants qui peuvent être établis entre deux smartphones.

Exploitation des fonctionnalités téléphoniques

Même si les smartphones offrent une grande diversité de services de par les différentscapteurs qu’ils embarquent et leur puissance de calcul grandissante, ils gardent pour fonc-tion principale d’offrir des services téléphoniques. Nous allons voir ici quelques techniquesd’exploitation de ces services pour la création de canaux cachés distants. Pour cela, nousavons regroupé ces techniques dans trois catégories en fonction du service exploité :

— Téléphonie : par service de téléphonie, nous entendons ici ceux offerts par le ré-seau cellulaire. Des services tels que la VoIP (Voix sur IP) n’entrent donc pas dansce champ. Ainsi, parmi les canaux cachés construits sur les systèmes téléphoniquesmobiles, deux approches existent. La première, utilise la voix comme canal de com-munication dans le lequel le message caché est encodé. Par exemple, dans [25] lesauteurs transforment le message en code morse dont chaque motif (point ou tiret) estassocié à un son. Le signal sonore ainsi construit est ensuite au smartphone récep-teur via un appel téléphonique. La seconde approche, consiste à exploiter certainespropriétés des protocoles de communication téléphonique. Ainsi, les auteurs de [26]proposent une technique s’appuyant sur le codec AMR-WB utilisé sur les réseaux 3Gpour la voix HD (i.e bande passante plus grande). Pour cela, ils modifient quelquesbits de la communication compressée pour y dissimuler un message caché. Même sicontrairement à la première, cette technique est spécifique à un protocole, le prin-cipe stéganographique est bien plus respecté. En effet, alors que dans la premièreapproche le message sonore n’aura plus rien à voir avec de la voix, ici les donnéessont dissimulées dans la voix avec uniquement une augmentation du rapport signalsur bruit.

— SMS : en raison de leur petite taille (140 octets de charge utile) les SMS n’offrentpas beaucoup de possibilités en termes de stéganographie. Par conséquent, la plu-

13

part des travaux s’appuyant sur les SMS pour établir un canal caché utilisent destechniques de manipulation de texte. Certaines d’entre elles sont discutées dans [27],parmi lesquelles on trouve des techniques sémantiques avec par exemple l’utilisationde synonyme, des techniques basés sur les abréviations ou encore les espaces entreles mots. Une approche intéressante est également proposée dans [28] où les auteursutilisent deux polices de caractère différentes dans un même SMS. Un bit est doncencodé dans chaque caractère par rapport à la police utilisée. Leur idée étant d’utili-ser deux polices très ressemblantes afin que la présence du message stéganographiquesoit difficilement détectable.

— MMS : il vient étendre la capacité du SMS en permettant d’envoyer des fichiersmultimédias (image, audio, vidéo, etc.) à travers le réseau téléphonique mobile. LeMMS entre donc pleinement dans le cadre de la stéganographie moderne (section2.1) et des techniques stéganographique pour les objets numériques. Dans [29], lesauteurs présentent l’application de certaines de ces techniques au MMS avec parexemple pour les images l’utilisation des bits de poids faible des pixels. Pour l’audio,de nombreuses techniques existent également avec notamment la création d’un échoou l’exploitation de la compression du format MP3. Enfin, les vidéos étant composéd’un grand nombre d’images (environs 30 par secondes), elles offrent une grandecapacité stéganographie. De plus, les auteurs proposent également d’exploiter leslangages de balisage utilisé dans les MMS (e.g SMIL) en réordonnant les balises ouen modifiant les espaces qui les séparent.

Potentiel des canaux cachés réseau

La stéganographie réseau est un domaine qui a déjà reçu de l’attention de la part dela communauté scientifique. Cependant, l’application de ces travaux aux smartphones estpeu étudiée dans la littérature. Pourtant, les smartphones sont conçus pour être en perma-nence connectés et partagent de nombreuses technologies avec les systèmes informatiquesclassiques. Nous allons voir ici quelques exemples de canaux cachés réseau qui s’appuientsur des technologies déjà présentes dans les smartphones. Comme nous l’avons dit à lasection 2.1.3 les canaux cachés réseau peuvent exploiter différentes couches de la pile OSI.Ainsi, nous avons retenu des techniques de différent niveau OSI et dont les auteurs onteffectué une évaluation de débit (table 2.2) :

— Préfixe cyclique dans 802.11n : cette technique proposée dans [30] agit au ni-veau physique de la norme 802.11.n mise en oeuvre dans la technologie Wi-Fi. Lanorme 802.12.n utilise la modulation OFDM (Orthogonal Frequency-Division Multi-plexing) afin de permettre des transmissions simultanées dans différentes bandes defréquences. Afin d’éviter les interférences dues à la réfection, OFDM ajoute un préfixecyclique avant l’envoi d’un symbole. Dans la pratique, ce préfixe permet d’améliorerla qualité de la transmission, mais son contenu n’est pas interprété. Dans ce pa-pier, les auteurs proposent d’utiliser cet espace pour encoder un message caché. Le

14

Technique Débit Couche OSI RéférencePréfixe cyclique dans 802.11n 3.25 Mbps to 19.5 Mbps Physique [30]

Bourrage dans LTE 1.162 Mbps Physique [12]Corruption de paquet 1.27 Mbps Liaison de donnés [31]Transcodage sur VoIP 32 kbps Application [32]

Table 2.2 : Débit de quelques canaux cachés réseaux

système proposé peut atteindre un débit maximum de 19.5 Mb/s en utilisant unemodulation 64-QAM (Quadrature Amplitude Modulation).

— Bourrage dans LTE : le LTE (Long Term Evolution) équipe désormais la plupartdes smartphones sortant sur le marché et permet l’accès à des services auparavantimpossible sur les réseaux 3G. Dans [12] une technique agissant au niveau physiquede cette norme est proposée. De façon similaire à la proposition vue pour 802.11.n,les auteurs exploitent ici les champs de bourrage qui séparent chaque trame. Ceschamps de bourrage consistent en une suite de zéro et ne sont pas interprétés. Enremplaçant ces champs de bourrage par un message caché, les auteurs parviennentà atteindre un débit stéganographique de 1.162 Mb/s.

— Corruption de paquet : dans [31], les auteurs effectuent une analyse de per-formance de HICCUPS (HIdden Communication system for CorrUPted networkS)dans un réseau local sans fil. HICCUPS exploite la couche liaison de donnée encréant volontairement des paquets dont la somme de contrôle est mauvaise. Ces pa-quets vont alors contenir dans leur charge utile le message stéganographique et vontêtre ignorés des autres stations à cause de leur somme de contrôle erroné. Ainsi,seules les stations complices de l’échange sténographique vont lire le contenue caché.Les auteurs ont évalué que HICCUPS est capable d’atteindre un débit de 1.27 Mb/s.

— Transcodage sur VoIP : la VoIP (Voix sur IP) est un ensemble de technologiespermettant d’effectuer des appels vocaux sur un réseau IP. Dans [32], les auteursproposent une technique de niveau applicatif permettant de créer un canal cachédans une communication VoIP. Pour cela, ils transcodent le signal audio afin dediminuer sa taille sans modifier l’espace qui lui ait attribué. L’espace libre restantest ensuite utilisé pour encoder le message caché. Le canal caché ainsi établi offre undébit pouvant aller jusqu’à 32 kb/s

2.3.3 Analyse de la consommation énergétique

À l’issue de ce stage, nous souhaitons savoir si l’analyse de la consommation énergé-tique d’un smartphone peut révéler des informations sur son activité et être utilisée à desfins stéganographique. Dans cette section, nous allons voir les travaux présents dans lalittérature qui se rapproche cette problématique.

15

Mesure de la consommation énergétique

Avant de se pencher sur les possibilités d’interprétations des informations de consom-mation énergétique, il faut savoir quels types de données nous allons manipuler. Pour cela,nous avons exploré plusieurs techniques d’acquisition de ces informations sous Android.Afin de nous assurer de la faisabilité de ces techniques une application implémentantchacune d’entre elles a été développée et détaillée dans [33] (document disponible sur de-mande). Nous allons voir ici le principe de ces techniques et les données auxquelles ellesdonnent accès :

— Intent sur le BatteryManager : cette approche est mise en avant dans la do-cumentation d’Android [34] et utilise le mécanisme d’Intent sur la classe Battery-Manager fourni par l’API. On peut considérer cette méthode comme disponible surtous les terminaux Android puisqu’elle est implémentée depuis l’API 5 (Android2.0). Cette approche est pleinement supportée par Android, mais nous donne ac-cès à des informations peu précises sur l’état de la batterie tel que le pourcentaged’énergie restante. Cette technique peut donc être adaptée aux applications qui n’ontpas besoin d’informations précises sur la consommation énergétique, mais n’est passuffisante pour une exploitation comme la nôtre.

— Le service BatteryManager : cette technique est elle aussi basée sur le Battery-Manager, mais au lieu d’utiliser le mécanisme d’Intent comme précédemment pourobtenir des informations, nous récupérons l’instance du BatteryManager. Sur cetobjet nous avons alors accès aux méthodes publiques « getIntProperty » et « get-LongProperty ». Cependant, ces méthodes sont disponibles uniquement à partir del’API 21. Ainsi, sur un terminal exécutant au moins Android 5.0 nous avons de-vrions avoir accès à des données telles que le courant en microampères et l’énergierestante en nanowatt-heure. Cependant, ces mesures sont disponibles uniquementsur les terminaux compatibles qui disposent d’une « jauge de batterie« [35]. LesNexus 6,9 et 10 seraient pleinement compatibles. Cette approche pourrait être unepiste intéressante à l’avenir lorsque plus de terminaux disposeront de cette jauge.

— Approche par réflexion : cette approche ne nous fournit pas beaucoup informa-tions (une seule) pour le moment, mais elle est suffisamment intéressante pour enparler. Android utilise le langage Java et dispose donc comme ce dernier de la ré-flexion. Cela étant défini par Oracle comme une fonctionnalité de Java qui permetà un programme de s’examiner ou de s’introspecter lui-même et de manipuler sespropriétés internes. Ainsi, en utilisant cette fonctionnalité, il est possible d’instancierla classe interne « com.android.internal.os.PowerProfile » et d’exécuter des méthodessur cette dernière. De cette façon, nous parvenons à obtenir capacité de la batterieen milliampères-heure. Cette donnée n’est pas exploitable dans notre cas, mais l’ap-proche en elle-même en étant appliquée à d’autres classes internes d’Android peutse révéler intéressante.

16

— Le système de fichier virtuel sysfs : en héritage de Linux, Android utilise le sys-tème de fichier virtuel sysfs pour exporter des informations du noyau vers l’espaceutilisateur. Ainsi dans le dossier « /sys/class/power_supply/battery/ » on retrouvedes fichiers qui contiennent des informations sur la batterie. Parmi ces fichiers, nousavons « voltage_now » et « current_now » qui fournissent respectivement le voltagede la batterie en microvolt et le courant parcourant la batterie en microampère.Ces fichiers, ne nécessite pas d’autorisation particulière pour être lue et fournissentdes informations précisent sur la consommation énergétique d’un smartphone. Ainsi,bien qu’ils soient utiles pour un suivi précis de la batterie, ils peuvent potentielle-ment être exploités pour une attaque par canal auxiliaire.

— La commande dumpsys battery : Android dispose d’un outil en ligne de com-mande pour obtenir des informations sur les services système : dumpsys [36]. Ainsi,la commande « dumpsys battery » nous renvoie des informations sur la batterie.Malheureusement, la commande dumpsys requiert une permission qui ne peut êtreobtenue que par des applications système. Ainsi, pour pouvoir l’exécuter dans notreapplication il était nécessaire, soit de l’installer comme une application système, soitde l’exécuter avec les droits root. On obtient par cette approche des informationséquivalentes à celles obtenues avec l’Intent sur le BatteryManager. Cela la rend doncpeu intéressante étant donné qu’elle nécessite les droits root.

— La commande dumpsys batterystats : la commande dumpsys dispose égalementdu service batterystats [37] qui nous donne accès à un grand nombre de données sta-tistiques sur l’utilisation de la batterie. Cela, nous offre notamment un historique desévénements liés à la batterie et des statistiques de consommation agrégées par ap-plication. Cependant, l’exploitation de ces données peut être complexe, une solutionest de se baser sur le fichier « power_profile.xml ». Ce fichier fournit par fabri-cants du smartphone décrit la consommation des différents composants du terminalen fonction de leurs utilisations. L’objectif de ce fichier étant de pouvoir calculerla consommation énergétique du terminal en multipliant le courant par le tempsdurant lequel le composant est actif. C’est de cette façon que l’outil « Utilisationde la batterie » présent dans les paramètres d’Android fonctionne. Ainsi, si nousavons accès au fichier « power_profile.xml » du terminal nous pouvons nous aussiestimer la consommation énergétique de ce dernier grâce aux traces obtenues avec« dumpsys batterystats ». Ce fichier peut être récupéré en décompilation le fichier« /system/framework/framework-res.apk », mais cela nécessite d’avoir les droits root.Cette approche est donc envisageable pour estimer avec un certain niveau de finessela consommation énergétique d’un smartphone, mais requiert un smartphone rootéet est relativement complexe à mettre en oeuvre.

17

Canaux auxiliaires énergétiques

Nous avons vu à la section 2.2.2 que les canaux auxiliaires permettent d’inférer desinformations sensibles à partir de l’observation des comportements physiques d’un sys-tème. Afin de nous guider vers notre objectif qui est l’exploitation de la consommationénergétique, nous souhaitons faire un tour d’horizon des travaux portant sur des canauxauxiliaires énergétiques sur les smartphones. Cependant, à notre connaissance, ce sujetreste pour le moment peu étudié. Ainsi, nous allons voir ici trois propositions d’exploita-tion de la consommation énergétique des smartphones :

— Suivi de déplacement : la communication radio téléphonique est une importantesource de consommation énergétique sur les smartphones. De plus, cette consomma-tion peut varier de manière significative en fonction de la puissance du signal. C’esten partant de ce constat, que les auteurs de [38] proposent d’utiliser la consomma-tion énergétique des smartphones pour suivre de déplacement de leurs utilisateurs.Cependant, il ont remarqué que la puissance du signal radio n’est pas uniquementliée à la distance avec la station de base la plus proche, mais aussi à environne-ment. Ils proposent alors de mesurer par avance la consommation énergétique d’unsmartphone pendant qu’il se déplace sur un ensemble de routes prédéfini. Par lasuite, l’observation de la consommation énergétique d’un smartphone conduit à unproblème de décision qui consiste à déterminer la route suivie parmi l’ensemble pré-défini.

— Identification d’application : dans [39], les auteurs donnent quelques pistes surla possibilité d’utiliser la consommation énergétique des smartphones comme canalauxiliaire. Ils ont ainsi mesuré la consommation énergétique des smartphones avectrois objectifs différents : détecter le démarrage d’une application, détecter l’affichaged’un écran spécifique et retrouver la longueur d’un mot de passe lors de sa saisie. Desgraphiques illustrant la variation de la consommation dans ces contextes semblentmontrer que de telles attaques sont possibles. Cependant, aucune évaluation de per-formance n’est fournie par les auteurs.

— Détection de canaux cachés : les auteurs de [40] présentent une méthode dedétection de canaux cachés utilisant la consommation énergétique des smartphones.Leur objectif est donc d’apporter une solution pour la détection de la collusion entreapplications (section 2.3.1). Sept canaux cachés différents ont été implémentés par lesauteurs dans le but de mesurer la consommation énergétique pendant leur exécution.Enfin, un réseau de neurones et un arbre de décision sont utilisés pour identifier cescanaux cachés au travers de la consommation. Les résultats obtenus indiquent untaux de détection correcte pouvant atteindre 97.6%.

18

Chapitre 3

Contributions

3.1 Notre proposition

Dans le chapitre précédent, nous sommes parties des origines de la stéganographiemoderne jusqu’à arriver à son application aux smartphones. Nous avons également vucomment les ressources physiques d’un système tel que la consommation énergétique pou-vaient être exploitées pour inférer des informations sur l’état d’un système. Maintenantque nous avons une connaissance de la littérature dans laquelle nous nous inscrivons, nouspouvons aborder nos contributions.

3.1.1 Scénario

Afin d’introduire notre proposition de système stéganographique, nous allons décrireun scénario dans lequel celui-ci pourrait être utilisé. Même si nous en présentons qu’unseul, dans la réalité plusieurs scénarios peuvent correspondre à l’application du systèmeproposé. La figure 3.1 illustre notre scénario dans lequel nous avons deux parties distantes :un attaquant et un smartphone. On admet qu’une application contenant une portion decode malveillante est installée sur le smartphone. Cette application, créée par l’attaquant,a été installée depuis un marché officiel. Elle ne paraît pas malveillante puisqu’elle rendbien le service demandé et ne requière aucune permission particulière. Nous positionnonsalors du côté de l’attaquant. Ce dernier souhaite envoyer des messages vers le smartphoneafin de lui donner des ordres. Cependant, étant donné que son application ne disposed’aucune permission pour la connexion réseau, le code malicieux qu’elle contient doit êtrecapable en lisant dans un canal caché de :

— détecter le message caché

— décoder l’information qu’il contient

Si l’établissement d’un tel canal caché est possible, cela peut poser des risques importantsen termes de sécurité. En effet, il serait alors possible pour un attaquant d’envoyer desordres vers un smartphone sans que l’application cible ait besoin de permissions réseau.

19

Figure 3.1 : Scénario

3.1.2 Système stéganographique proposé

Maintenant que nous avons vu le scénario dans le lequel nous nous inscrivons, nousallons présenté notre proposition. Le système stéganographique (c.f figure 2.1) que nousproposons est représenté sur la figure 3.2 et consiste à encoder le message secret m ∈ M

dans la consommation énergétique du smartphone. Cependant, l’attaquant se situe à dis-tance de ce dernier et ne peut donc pas agir physiquement. Nous proposons alors d’envoyerune séquence Sm de messages (SMS, Facebook Messenger, Mail) vers le smartphone afinque leur réception produise une consommation d’énergie Cm sur le smartphone. On noteque nous avons choisi de nous restreindre à trois types de messages, mais que cette ap-proche peut être étendue à d’autres services de messagerie. Pour que notre système soitréalisable, nous devons apporter une solution aux deux fonctions suivantes :

— Embed : cette fonction prend en entrée le message secret m à envoyer et doit pro-duire en sortie une séquence de messages Sm qui seront envoyés vers le smartphone.Une séquence Sm doit respecter deux propriétés : elle doit correspondre à un seulmessage m et doit conduire à la consommation C ′

m ≈ Cm sur le smartphone. Dansla réalité, il est impossible que C = Cm, cependant C devra être assez proche de Cm

pour qu’il corresponde toujours à m.

— Extract : cette fonction prend en entrée la consommation C ≈ Cm est doit produireen sortie le message m. Pour cela, Extract doit d’abord être capable de reconstruirela séquence Sm à partir de C. Cela suppose donc que l’impact de la réception d’unmessage (SMS, Facebook Messenger, Mail) est suffisamment visible dans C pour êtredétecté.

Pour être en mesure de construire ces deux fonctions, nous devons valider les pointssuivants :

20

Figure 3.2 : Système stéganographique proposé

— la réception d’un ou de plusieurs messages à une empreinte visible sur la consomma-tion énergétique d’un smartphone

— cette empreinte est suffisamment unique pour être détectée

3.1.3 Possibilités d’encodage

La fonction Embed décrite à la section précédente doit encoder un message secret m

dans une séquence de message Sm. Différentes possibilités d’encodage sont possibles etle choix de l’une entre elles va dépendre des performances de la détection de messages àpartir de l’observation de la consommation énergétique. Pour le moment, nous considéronsuniquement trois possibilités d’encodage :

— Type de message : pour que cet encodage soit applicable, il faut qu’en plus dedétecter la réception d’un message, il soit possible de déterminer son type (SMS,Facebook Messenger, Mail). Ainsi, chacun des types de messages est vu comme unsymbole. Le message secret m est alors encodé avec l’alphabet composé de l’ensemblede ces symboles.

— Réception d’un message : on se place ici dans le cas où nous sommes capables dedétecter la réception d’un message sans parvenir à discriminer son type. Nous pou-vons alors utiliser un encodage basé sur le temps entre les messages. Par exemple,on peut choisir de coder un bit « 0 » en laissant un temps t entre deux messages etde coder le bit « 1 » avec un temps 2t.

— Réception de plusieurs messages : ce dernier cas est le plus défavorable et sup-pose que la détection d’un message à travers la consommation énergétique est im-possible (ou trop peu précise). Dans cette situation, nous pouvons essayer d’envoyerdes blocs composés de plusieurs messages. Si la réception de ces blocs est détectablealors nous pouvons appliquer le même encodage que pour la réception d’un message.

21

3.2 Acquisition des données

Le système stéganographique que nous proposons dans la section précédente exploite lavariation de la consommation énergétique due à la réception d’un message. Afin d’étudier lafaisabilité réelle d’un tel système, la première étape est d’avoir une méthode pour mesurerles données de consommation énergétique.

3.2.1 Solution retenue

Différentes techniques d’acquisition des informations de consommation énergétiquessous Android ont été présentées à la section 2.3.3. Certaines offre une grande quantité dedonnées, mais sont complexes à mettre en oeuvre et requières un smartphone rooté. Cedernier point va à l’encontre de notre scénario puisque l’application malveillante ne doitnécessiter aucune permission suspecte. D’autres techniques n’ont pas besoin de permis-sion particulière et sont offertes par l’API Android, mais fournissent des données avec unefaible précision. Notre compromis a été de retenir la solution s’appuyant sur le système defichier virtuel sysfs. Les raisons qui ont motivé ce choix sont les suivantes :

— Compatibilité : cette technique est supportée par tous les smartphones même lesplus anciens. En effet, le système de fichier sysfs est un héritage de linux et est doncprésente dans toutes les versions d’Android.

— Accessibilité : l’accès au fichier de sysfs contenant les informations énergétiques nenécessite pas de permission particulière.

— Précision : avec cette approche il est possible d’obtenir le courant et le voltage dela batterie en microampère et en microvolts. Ces valeurs sont donc d’une précisionsuffisante pour nous besoin.

— Granularité temporelle : bien que ces données soit précises elles ne sont pas ex-ploitables si leur période d’actualisation en trop élevée. Nous donc avons mener desexpérimentations pour déterminer cette période. Ainsi, durant nos tests nous avonsété capables atteindre une granularité temporelle de l’ordre de 100ms.

— Simplicité : cette technique est simple à mettre en oeuvre puisqu’elle consiste àaller lire les valeurs souhaitées dans les fichiers correspondants.

3.2.2 Événement de réception de message

Afin de déterminer si la réception d’un message sur un smartphone à une empreinteénergétique identifiable, nous devons savoir à quel moment précis le message a été reçu.Une solution pour cela est de noter le moment où le message a été envoyé. Cependant, latransmission d’un message sur le réseau n’est pas instantanée. De plus, certains messages(les mails par exemple) ne seront reçus qu’après une demande d’actualisation de la part

22

du smartphone. Ainsi, c’est au niveau du smartphone que le moment où le message estreçu doit être noté. Pour faire cela, notre solution est de capturer la notification affichée àl’écran lorsqu’un nouveau message est reçu. De cette façon, nous récupérons les informa-tions suivantes sur chaque notification :

— Timestamp : le timestamp en milliseconde ou la notification s’affiche à l’écran. Onpeut donc considérer ce temps comme le moment ou le message est reçu avec unecertaine marge d’erreur. Cette marge d’erreur vient du fait qu’il faut que le messagesoit reçu est traité par le système avec que la notification soit déclenchée.

— Type : le « package name » de l’application concerné par la notification est récu-péré. Il s’agit d’une chaîne de caractère qui identifie une application installée sur letéléphone. Nous utiliserons cette valeur en tant que type du message. Par exempleun message Gmail aura pour type « com.google.android.gm ».

— Contenue : nous avons également accès au texte contenu dans le message reçu. Celapeut être utile pour inclure des informations lors de l’envoi du message.

3.2.3 Application développée

Nous avons implémenté les deux solutions présentées dans les sections précédentes(mesure de la consommation et capture des notifications) dans une application Android.Cette dernière nous permet de mesurer la consommation énergétique d’un smartphonependant qu’il reçoit des messages. Son rôle est de produire des fichiers de log contenantl’évolution de la consommation durant la mesure et les notifications capturées. Ainsi, elleproduit les deux fichiers (figure 3.4) suivants :

— Consommation : ce fichier au format CSV contient les valeurs de la consomma-tion énergétique prises à intervalle régulières. Ainsi, chaque ligne correspond à unéchantillon de cette consommation et comprend les champs suivants :

1. le timestamp où l’échantillon a été pris

2. la valeur du courant traversant la batterie en microampères

3. le voltage aux bornes de la batterie en microvolts

4. (optionnel) le temps cumulé d’utilisation du processeur

5. (optionnel) l’utilisation de la mémoire

— Notification : les notifications issues de la réception d’un message sont enregis-trées dans ce fichier au format CSV. Chaque ligne correspond à la capture d’unenotification et contient les champs suivants :

1. le timestamp où la notification a été créé

2. le type (i.e le « package name ») du message reçu

23

Nom du fichier de log

Intervalle d’échantillonnage

Garder le processeur éveillé

Démarrer/Arrêter la mesure

Figure 3.3 : Application Android pour la mesure

Mesures énergétique Notifications de réception

Figure 3.4 : Fichiers de log de consommation et de notification

3. le texte contenu dans le message

La figure 3.3 décrit l’interface de cette application. Cette dernière permet de fixer lesparamètres suivants avant de commencer une mesure :

— « FileName » : un préfixe du nom sous lequel les fichiers de log de consommationet de notification seront enregistrés. L’application ajoutera un suffixe différent pourchacun de ces fichiers pour éviter un conflit de nom.

— « Interval » : l’intervalle pour l’échantillonnage de la consommation énergétique

— « CPU Lock » : l’activation ou la désactivation d’un verrou sur le processeur pours’assurer qu’il ne se mette pas en veille. En effet, si le processeur se met en veillel’intervalle d’échantillonnage ne sera plus respecté.

3.3 Environnement de mesure

Nous venons de voir l’application Android qui a été développée afin de permettre lacréation de fichiers de log de consommation énergétique et de notification. Nous avonsdonc en main les outils nécessaires afin de mettre en place un protocole de mesure.

24

3.3.1 Protocoles de mesure

Pour rappel, l’objectif de nos mesures est de déterminer si la réception d’un message(SMS, Facebook Messenger, Mail) à une empreinte identifiable sur la consommation éner-gétique d’un smartphone. Pour cela, nous avons défini un protocole de mesure qui consisteà envoyer plusieurs messages vers un smartphone sur lequel l’application de log s’exécute.Deux smartphones Android différents vont être utilisés : un Sony Xperia SP (Android 4.3)et un Sony Xperia Z2 (Android 6.0.1). Sur chacun, de ses smartphones plusieurs mesuresseront faites en faisant varier les paramètres suivants :

— Cas d’utilisation : nous avons déterminé deux d’utilisation du smartphone pen-dant la mesure. Dans le premier, le smartphone n’est pas manipulé par l’utilisateuret l’écran est éteint. Il s’agit donc du cas idéal. Dans le second, l’utilisateur est actifsur le smartphone et provoque donc des variations de la consommation énergétique.Cette consommation énergétique due à l’activité de l’utilisateur est alors vue commedu bruit.

— Temps inter message : nous allons envoyer plusieurs messages vers le smartphonedurant la mesure. Cependant, pour que les résultats soit exploitables il faille quechacun de ses messages soit suffisamment espacé afin qu’il n’arrive pas en mêmetemps. Il faudra donc faire varier le temps inter message afin d’identifier le mini-mum atteignable.

— Fréquence d’échantillonnage : échantillonner la consommation énergétique né-cessite d’exécuter du code à intervalle régulier pour lire dans les fichiers sysfs etécrire dans le fichier de log. Cela a donc un impact sur la consommation énergétique.Il faut alors déterminer quelle fréquence d’échantillonnage limite cet impact tout enassurant une granularité temporelle suffisante pour l’interprétation des données.

3.3.2 Envoi automatique de message

Pour mettre en pratique le protocole de mesure que nous venons de présenter, nousavons besoin d’une méthode pour l’envoi des messages. Dans nos fichiers de log (c.f 3.2.3),nous souhaitons avoir plusieurs messages qui sont reçus de manière périodique par le smart-phone. Cela permettra lors de l’analyse de regarder pour chacun de ces messages si leurréception est détectable à travers la consommation. Nous avons alors développé différentsoutils pour automatisé l’envoi de trois types de messages : SMS, Facebook et Mail. Nousavons choisi d’avoir deux approches pour ces envois automatiques :

— Type fixe : cette approche permet d’effectuer des mesures pour un seul type demessage. Pour cela, on envoie périodiquement le type de message souhaité. Pourl’envoi automatisé de message Facebook et de mail nous avons développé un scriptpython qui est capable de se connecter et d’envoyer des messages sur Facebook et sur

25

Envoie toutes les30 secondes

Figure 3.5 : Envoi périodique de message Facebook et Gmail

Numéro de téléphone

Intervalle d’envois

Démarrer/Arrêter l’envoie

Figure 3.6 : Envoi périodique de SMS

Gmail. Ce script est utilisable à travers une interface web (figure 3.5) afin de fixerl’intervalle d’envoi et de le démarrer. Pour l’envoi de SMS, nous avons développéune application Android dont l’interface est décrite sur la figure 3.6.

— Type aléatoire : nous souhaitons ici avoir des mesures dans lesquelles différentstypes de messages sont reçus. Pour cela, nous utilisons un envoi périodique de mes-sage dont le type est choisi aléatoirement avant chaque envoi. Afin d’assurer la pé-riodicité, il est nécessaire que l’envoi des différents types de messages soit géré à unseul endroit. Nous avons alors développé une application Android (figure 3.7) capabled’envoyer des SMS, mais aussi des messages Facebook et Gmail en se connectant àl’interface web présentée plus haut. Pour effectuer cette connexion, une API a étédéveloppé au niveau de l’interface web afin de l’application Android puisse l’exploi-tée.

3.4 Analyse des résultats

Nous disposons désormais de différents fichiers de log qui décrivent la consommationénergétique d’un smartphone sur une période donnée et les différents types de messagesreçus. Nous entrons alors dans la phase d’analyse où nous allons chercher à déterminer lacorrélation entre la réception d’un message et une variation significative de la consomma-tion.

26

Numéro de téléphone

Type de message

Démarrer/Arrêter l’envoie

Intervalle d’envois

Figure 3.7 : Envoi aléatoire de message (SMS, Facebook, Gmail)

3.4.1 Plate-forme d’analyse

Afin de faciliter la gestion et l’analyse des différents fichiers de log, j’ai développé uneplate-forme web dédiée. Les différents fichiers de log sont placés sur cette plate-forme etpeuvent ainsi être manipulés facilement. Pour chaque fichier, on a accès aux informationssuivantes : le téléphone sur lequel la mesure a été prise, le temps échantillonnage uti-lisé, la durée totale de la mesure, le nombre d’échantillons et des statiques sur le respectréel d’échantillonnage souhaité. De plus, elle nous offre une interface de visualisation desdifférentes mesures (courant, voltage). Sur cette visualisation il apparaît également lesmoments ou des messages ont été reçus sur le smartphone et leur type.

3.4.2 Visualisation des mesures

Nous commençons notre analyse par une visualisation graphique de données de consom-mation énergétique afin d’avoir une intuition sur les traitements à appliquer. Nous allonsvoir ici les mesures de courant échantillonné à 100 millisecondes sur trois types de mes-sages. Les figures 3.8, 3.9 et 3.10 représentent ces mesures respectivement pour les SMS,message Facebook et mail. Les messages sont envoyés toutes les 30 secondes et leurs récep-tions sur le smartphone sont représentées par des traits verticaux. On note que le courantest négatif, car la batterie est en décharge.

On remarque que l’on a une augmentation du courant lorsqu’un SMS est reçu etque celle-ci dure plusieurs secondes. Pour les messages Facebook, cela est plus discutablepuisqu’entre le début et la fin de la trace l’impact de la réception d’un message n’est pasle même. La réception d’un mail semble également difficilement perceptible. De plus, alorsque les mails sont envoyés toutes les 30 secondes, ce n’est pas le cas de leur réception. Celavient du fait que l’application chargée de leur réception se synchronise sur un intervalleplus grand.

27

Figure 3.8 : SMS (courant échantillonné à 100ms)

Figure 3.9 : Message Facebook (courant échantillonné à 100ms)

Figure 3.10 : Mail (courant échantillonné à 100ms)

28

Figure 3.11 : SMS avec moyenne glissante sur 10 valeurs

3.4.3 Moyenne glissante

On peut voir sur les mesures présentées à la section précédente que le courant est assezinstable. Pour lisser ces valeurs, nous avons la possibilité d’appliquer une moyenne glissantesur les données. Ainsi, la figure 3.11 représente les mêmes mesures qu’à la figure 3.8 surlequel on a appliqué une moyenne glissante. L’utilisation de cette technique permet delisser les données et pourrait donc améliorer les performances d’un algorithme d’analyse.

3.5 Détection de message

Nous avons venons de voir des exemples de mesures de la consommation énergétiquedans un smartphone pendant qu’il reçoit différent type de message. Notre objectif danscette partie est de déterminer une approche permettant de détecter l’arrivée d’un message.Pour le moment, nous ne cherchons donc pas à discriminer le type de message.

3.5.1 Problème posé

Comme nous l’avons vue à la section 3.2.3, pour une mesure nous avons à notre dis-position deux fichiers qui contiennent respectivement la consommation énergétique d’unsmartphone et les notifications de réception de message. Pour la détection, nous allonsanalyser une des variables de consommation énergétique (courant, voltage) et tenter desdétecter les moments où des messages sont reçus. Nous comparerons ensuite ces détectionsavec les informations du fichier de notification pour déterminer les vrais et faux positifs.

Notre objectif dans cette partie est d’identifier la meilleure méthode de détection demessage pour :

1. un fichier de consommation

2. un ensemble de fichiers de consommation

29

Mesures de performances

Afin de pouvoir comparer les résultats de détections, nous avons besoin de définirdes métriques. Pour cela, nous évaluons les performances d’une détection en mesure lenombre de bonne et mauvaise détections. Plus formellement, nous utilisons une matricede confusion qui rapporte les informations suivantes :

— Positive (P) : le nombre de fois où il y a eu un message

— Negative (N) : le nombre de fois où il n’y a pas eu de message

— True Positive (TP) : le nombre de fois où un message à correctement été détecté

— False Positive (FP) : le nombre de fois où un message à été détecté alors qu’il n’yavait rien

— True Negative (TN) : le nombre de fois où rien n’a été détecté et qu’il n’y avait rien

— False Negative (FN) : le nombre de fois où rien n’a été détecté alors qu’il y avait unmessage

À partir de ces valeurs, on calcule les métriques suivantes :

— True Positive rate (TPR) : T PT P +F N

— Positive Predictive Value (PPV) : T PT P +F P

— Accuracy : T P +T NP +N

— F1score : 2 ∗ P P V ∗T P RP P V +T P R

3.5.2 Solutions proposées

Dans cette section, nous allons présenter les solutions que nous proposons pour ré-pondre au problème posé plus haut.

Méthodes d’analyse

Avant d’appliquer des techniques de détection, nous devons d’abord définir commentnous allons analyser les données de consommation. Ces données sont des séries tempo-relles qui correspondent à l’évolution d’une variable énergétique (courant ou voltage).Pour l’analyse, nous choisirons une de ces séries temporelles dans laquelle nous allons ten-ter de détecter les réceptions de message. Nous avons défini deux approches pour appliquerles techniques de détection sur une série temporelle :

— Approche simple : on applique la technique de détection sur l’intégralité des don-nées

— Approche par slot : on suppose que l’on dispose un système de synchronisationqui nous permet de savoir le début de l’envoi stéganographique. De plus, on saitqu’un bit est envoyé toute les t périodes de temps où le bit « 1 » est la réceptiond’un message et le bit « 0 » son absence. À partir de ces hypothèses, nous pouvons

30

Approche Avantages Inconvénients

Simple - Pas besoin d’avoir des connais-sances sur le moment où l’envoicommence

- Le taux de faux positif peut êtreimportant (nous allons détecter desmessages qui ne sont pas lié à lacommunication stéganographique)

- La variation du temps inter mes-sage n’est pas un problème

- Un message peut être détecté plu-sieurs fois

Slot - On limite les conséquences dubruit (et les faux positifs)

- on a besoin d’une synchronisation

- on peut réduire l’impact sur laconsommation énergétique en rele-vant les données pendant les slotsuniquement

- la période inter message doit êtrefixe

Table 3.1 : Comparaison des méthodes d’analyse

Figure 3.12 : Analyse par slot

déterminer les slots de temps où les bits sont envoyés. On applique alors la techniquede détection uniquement durant ces slots. La figure 3.12 illustre cette approche.

Ces deux méthodes d’analyse sont comparées dans le tableau 3.1.

Techniques de détection

Nous avons implémenté différentes techniques pour la détection des messages qui sontprésentées ci-dessous :

— Threshold (figure 3.13) : chaque fois que la valeur dépasse un seuil fixé est consi-dérée comme la réception d’un message

— Adaptive threshold (figure 3.14) : cette technique suit le même principe que laprécédente à la différence qu’on essaye d’adapter de seuil si la valeur moyenne change

31

Figure 3.13 : Détection par seuil

Figure 3.14 : Détection par seuil adaptatif

— Statistical distribution (figure 3.15) : on prend pour hypothèse que l’on connaîtla distribution statistique dref des données sur une période t lorsqu’un message estreçu. On parcourt les données avec une fenêtre t en mesurant la distribution statis-tique d et en calculant la distance dist(dref , d). On considère qu’un message est reçulorsque dist(dref , d) est inférieur à seuil fixé.

— Multiple detection avoidance : pour chacune des techniques ci-dessus nous avonsun équivalent qui dispose d’un mécanisme permettant d’éviter de détecter plusieursfois un message. Ces techniques seront appelées dans la suite : Threshold once,Adaptive threshold once et Statistical distribution once.

3.5.3 Recherche des meilleures performances

Nous avons vu dans la section précédente plusieurs techniques de détections qui peuventêtre utilisés selon deux méthodes d’analyse. Nous souhaitons maintenant savoir quelle

32

Figure 3.15 : Détection par distribution statistique

approche nous donne les meilleurs résultats.

Procédure d’application

La meilleure technique de détection n’est forcément celle qui a les meilleures perfor-mances pour un fichier de log. En effet, il également important d’évaluer les performancesd’une technique en moyenne sur plusieurs fichiers. Pour cela, nous avons défini une pro-cédure d’application des techniques. Ainsi, pour chacun des fichiers on suit la procéduresuivante :

1. Pre-traitement : avant de lancer nos techniques de détection, nous pouvons appliquerun traitement aux données (e.g moyenne glissante)

2. Détection : en fonction de la technique de détection à appliquer

— Threshold : Premièrement, on calcule la valeur moyenne des données. Puis, àpartir d’une valeur de seuil générique comprise entre 0 et 1 on calcule le seuiltel que : threshold = mean + mean ∗ genericThreshold.

— Adaptive threshold : on calcule le seuil comme ci-dessus et ensuite durant l’ana-lyse du fichier on calcule la moyenne des données sur une fenêtre de temps.De cette, valeur on calcule le seuil adaptatif tel que thresholdAdaptative =threshold ∗ (currentMean/mean).

— Statistical distribution : Premièrement, pour chaque fois ou on a une notifi-cation, on calcule la distribution sur une fenêtre de temps. Puis, on prend lamoyenne de ces distributions comme distribution de référence.

3. Évaluation : On compare les détections avec les vrais messages contenus dans lefichier de notification. On déduit les métriques de performance définie à la section3.5.1

Enfin, avec les mesures de performance de chaque fichier on calcule la performanceglobale de la détection.

33

Tests exhaustifs

Nous disposons de plusieurs techniques de détection qui peuvent prendre différentesvaleurs en paramètre. Si nous voulons savoir quelle technique nous donne les meilleuresperformances pour un fichier de log (ou un ensemble de fichiers de log), l’idéal est detester toutes les combinaisons possibles de techniques et de paramètres. Dans ce but, j’aidéveloppé un outil qui exécute plusieurs détections avec différentes techniques et valeurs deparamètre. Dans la pratique, on contraint les valeurs que les paramètres peuvent prendre etl’outil va exécuter toutes les techniques de détection avec toutes les valeurs de paramètrespossibles. À la fin, on ordonne les résultats en fonction des métriques de performance.Ainsi, on sait quelles techniques de détection avec quelle valeur de paramètre donnent lesmeilleures performances pour le fichier de log (ou l’ensemble de fichiers de log).

En plus de tester tous les paramètres de détection possible, l’outil de test exhaustifva également tester les performances avec et sans prétraitement. Pour le moment, ceprétraitement est une moyenne glissante pour laquelle on va tester différentes valeurs defenêtre.

Entant donnée l’aspect combinatoire de ces tests et le volume important des donnéesà traiter (données de consommation sur plusieurs heures), l’exécution de cet outil peutprendre plusieurs heures. J’ai donc implémenté cet outils dans la plate-forme d’analyse(section 3.4.1). Les exécutions sont donc faites sur un serveur et on peut voir leurs pro-gressions et résultats via une interface web.

3.5.4 Résultats obtenus

L’annexe A.4 présente les approches qui ont données les meilleurs résultats dans diffé-rents contextes et sur différents fichiers de log. Pour évaluer les performances de détections,nous nous sommes pour le moment limités au message Facebook. Ainsi, les mesures ontété prises sur deux smartphones différents recevant des messages Facebook toutes les 30ou 60 secondes et dans le cas d’utilisation idéal (écran éteint).

Nous avons d’abord cherché les meilleurs performances pour un seul fichier en utilisantl’analyse simple et par slot. Sans surprise c’est l’approche par slot qui donne les meilleursrésultats avec un taux d’erreur inférieur à 5%. Pour l’analyse simple, les résultats sontvariables avec un taux d’erreur entre 20 et 43%. Pour les performances sur plusieursfichiers, on obtient en moyenne un taux d’erreurs inférieur à 10% pour l’approche par slotet inférieur à 41% pour l’approche simple.

Application stéganographique

Malheureusement, j’ai pris du retard sur le planning décrit dans l’annexe A.2 et nousn’avons donc pas pour le moment d’implémentation de notre système stéganographique.Cependant, les résultats que nous venons de présenter dans la partie précédente nousdonnent une première idée des performances que pourrait atteindre le système stégano-graphique proposé. Ainsi, si on prend les performances de l’approche sur plusieurs fichiersqui est la plus représentative d’un cas réel. L’approche par slot nous offre un canal avecun débit pouvant être fixé à 2 bit par minutes avec un taux d’erreurs inférieur à 10%.

34

Cette approche nécessite une étape de synchronisation qu’il serait possible d’effectueravec l’approche simple dont le taux d’erreur est inférieur à 41%.

Travail en cours

À l’heure où j’écris ces lignes, il nous reste un peu plus de trois semaines de stage. Nouspourrions utiliser ce temps pour valider le modèle stéganographique proposé en partantdes résultats obtenus. Cependant, l’expérience que nous avons acquise sur les données quenous manipulons nous amène vers de nouvelles approches pour rendre plus efficace nostechniques de détection.

L’analyse simple génère beaucoup de faux positif, mais est peu gourmande puissance decalcule. Nous proposons donc de l’utiliser pour une première phase détection afin de générerun ensemble détection potentielle. Puis, nous appliquerons une technique plus lourde encalcule, mais générant beaucoup moins de faux positif sur les détections potentielles. Ainsi,l’utilisation de techniques de reconnaissance de motif dans les séries temporelles pourraitaméliorer nos résultats. Nous travaillons donc actuellement à déterminer si des motifsexistes dans nos données et comment les détecter.

35

Chapitre 4

Conclusion

Avec ce stage, nous proposons une nouvelle approche pour la mise en oeuvre d’uncanal stéganographique entre une tierce partie distance et un smartphone. Ce canal doitpermettre à une application installée sur un smartphone de recevoir une information se-crète sans permission réseau et en exploitant les données de consommations énergétiques.Pour cela, la problématique posée était de déterminer si la réception d’un message par unsmartphone possède une empreinte énergétique identifiable et sous quelles mesures cetteempreinte peut être utilisée pour sa détection.

Nous avons commencé notre exploration de cette problématique en effectuant un étatde l’art durant lequel nous avons vu l’évolution de la stéganographie et ses applicationspermettant de déjouer les mécanismes de sécurité utilisés de nos jours. Nous avons éga-lement vu comment des propriétés physiques d’un système peuvent être exploitées pourinférer des informations et établir des canaux cachés. Nous nous sommes ensuite concen-tré sur les applications de ces techniques stéganographique aux smartphones ainsi qu’àanalyse et l’exploitation de leurs consommations énergétiques. Dans un deuxième temps,nous avons présenté notre proposition de système stéganographique et un scénario danslequel il serait applicable. Enfin, nous avons décrit les différentes étapes de notre réflexionet les solutions techniques que nous avons apportées.

Bien que l’objectif final de développement d’un système stéganographique n’a pasencore été atteint à l’heure où j’écris ces lignes, les résultats que nous avons obtenusnous encouragent à poursuivre nos efforts dans ce sens. En effet, nous sommes arrivés àla conclusion que le système proposé est valide et pourrait atteindre un débit de 2 bitspar minutes avec un taux d’erreur inférieur à 10% (en supposant une synchronisationpréalable). De plus, nous avons bon espoir que ces performances pourront être amélioréesavec le travail que nous effectuons actuellement. En outre, en laissant de côté l’applicationstéganographique, les résultats obtenus montrent également que l’analyse des données deconsommation énergétiques des smartphones peut révéler des informations son activité.Des protections sur l’accès à ces données doivent donc être mise en oeuvre afin de protégerla vie privée des utilisateurs et de rendre impossible des systèmes stéganographique telsque celui que nous proposons.

36

Bibliographie

[1] GustavusJ Simmons. The prisoners’ problem and the subliminal channel. In DavidChaum, éditeur, Advances in Cryptology, pages 51–67. Springer US, 1984.

[2] N. Provos et P. Honeyman. Hide and seek : an introduction to steganography.IEEE Security & Privacy Magazine, 1(3) :32–44, mai 2003.

[3] Rainer Böhme. Advanced Statistical Steganalysis. Springer Berlin Heidelberg, Berlin,Heidelberg, 2010. Partie 2.

[4] A. D. Ker. Steganalysis of LSB matching in grayscale images. IEEE Signal Proces-sing Letters, 12(6) :441–444, juin 2005.

[5] Niels Provos. Defending against statistical steganalysis. In Proceedings of the 10thConference on USENIX Security Symposium - Volume 10, SSYM’01, Washington,D.C. USENIX Association, 2001.

[6] J. Fridrich. Applications of data hiding in digital images. In ISSPA ’99. Proceedingsof the Fifth International Symposium on Signal Processing and its Applications(IEEE Cat. No.99EX359), pages 9+, Brisbane, Qld., Australia. Queensland Univ.Technol, 1999.

[7] F. A. P. Petitcolas, R. J. Anderson et M. G. Kuhn. Information hiding-a survey.Proceedings of the IEEE, 87(7) :1062–1078, juillet 1999.

[8] Ramya J. Masti, Devendra Rai, Aanjhan Ranganathan, Christian Müller, Lo-thar Thiele et Srdjan Capkun. Thermal covert channels on multi-core platforms,mars 2015. arXiv : 1503.07000.

[9] Dmitry Evtyushkin et Dmitry Ponomarev. Covert channels through randomnumber generator : mechanisms, capacity estimation and mitigations. In Proceedingsof the 2016 ACM SIGSAC Conference on Computer and Communications Security,CCS ’16, pages 843–857, Vienna, Austria. ACM, 2016.

[10] Keisuke Okamura et Yoshihiro Oyama. Load-based covert channels between xenvirtual machines. In Proceedings of the 2010 ACM Symposium on Applied Computing,SAC ’10, pages 173–180, Sierre, Switzerland. ACM, 2010.

[11] Bartosz Lipinski, Wojciech Mazurczyk et Krzysztof Szczypiorski. Improvinghard disk contention-based covert channel in cloud computing environment, février2014. arXiv : 1402.0239.

37

[12] Iwona Grabska et Krzysztof Szczypiorski. Steganography in long term evolutionsystems. In 2014 IEEE Security and Privacy Workshops, pages 92–99, San Jose, CA.IEEE, mai 2014.

[13] Bo Xu, Jia-zhen Wang et De-yun Peng. Practical protocol steganography : hidingdata in IP header. In First Asia International Conference on Modelling & Simulation(AMS’07), pages 584–588, Phyket, Thailand. IEEE, mars 2007.

[14] Matthias Bauer. New covert channels in HTTP : adding unwitting web browsersto anonymity sets. In Proceedings of the 2003 ACM Workshop on Privacy in theElectronic Society, WPES ’03, pages 72–78, Washington, DC. ACM, 2003.

[15] Jozef Lubacz, Wojciech Mazurczyk et Krzysztof Szczypiorski. Principles andoverview of network steganography. IEEE Communications Magazine, 52(5) :225–229, mai 2014.

[16] Intel Corporation. Intel trusted execution technology : white paper. url : http://www.intel.com/content/www/us/en/architecture-and-technology/trusted-execution - technology / trusted - execution - technology - security - paper .html (visité le 10/05/2017).

[17] Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Carlos V. Rozas, HishamShafi, Vedvyas Shanbhogue et Uday R. Savagaonkar. Innovative instructionsand software model for isolated execution. In Proceedings of the 2Nd InternationalWorkshop on Hardware and Architectural Support for Security and Privacy, HASP’13, Tel-Aviv, Israel. ACM, 2013.

[18] ARM. Building a secure system using trustzone technology. 2009. url : http ://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf (visité le 10/05/2017).

[19] Intel Corporation. Intel digital random number generator (drng), software im-plementation guide. 2012. url : https://software.intel.com/sites/default/files/m/d/4/1/d/8/441_Intel_R__DRNG_Software_Implementation_Guide_final_Aug7.pdf (visité le 10/05/2017).

[20] J. S. Liberty, A. Barrera, D. W. Boerstler, T. B. Chadwick, S. R. Cot-tier, H. P. Hofstee, J. A. Rosser et M. L. Tsai. True hardware random numbergeneration implemented in the 32-nm SOI POWER7+ processor. IBM Journal ofResearch and Development, 57(6) :4 :1–4 :7, novembre 2013.

[21] Paul Kocher, Joshua Jaffe et Benjamin Jun. Differential power analysis. In Mi-chael Wiener, éditeur, Advances in Cryptology — CRYPTO’ 99. Tome 1666, Lec-ture Notes in Computer Science, partie 25, pages 388–397. Springer Berlin Heidel-berg, Berlin, Heidelberg, décembre 1999.

[22] Thomas S. Messerges, Ezzy A. Dabbish et Robert H. Sloan. Investigations ofpower analysis attacks on smartcards. In Proceedings of the USENIX Workshop onSmartcard Technology on USENIX Workshop on Smartcard Technology, WOST’99,page 17, Chicago, Illinois. USENIX Association, 1999.

38

[23] Android. System and kernel security. 2017. url : https://source.android.com/security/overview/kernel-security (visité le 16/05/2017).

[24] Claudio Marforio, Hubert Ritzdorf, Aurélien Francillon et Srdjan Capkun.Analysis of the communication between colluding applications on modern smart-phones. In Proceedings of the 28th Annual Computer Security Applications Confe-rence, ACSAC ’12, pages 51–60, Orlando, Florida, USA. ACM, 2012.

[25] Bushra Aloraini, Daryl Johnson, Bill Stackpole et Sumita Mishra. A newcovert channel over cellular voice channel in smartphones, juin 2015. arXiv : 1504.05647.

[26] Haibo Miao, Liusheng Huang, Zhili Chen, Wei Yang et Ammar A. Hawbani. Anew scheme for covert communication via 3G encoded speech. Comput. Electr. Eng.,38(6) :1490–1501, novembre 2012.

[27] Mohammad Shirali-Shahreza et M. Hassan Shirali-Shahreza. Text stegano-graphy in SMS. In 2007 International Conference on Convergence Information Tech-nology (ICCIT 2007), pages 2260–2265, Gyeongju-si, Gyeongbuk, Korea. IEEE, no-vembre 2007.

[28] Wesam S. Bhaya. Text hiding in mobile phone simple message service using fonts.

[29] Konstantinos Papapanagiotou, Emmanouel Kellinis, GiannisF Marias et Pa-nagiotis Georgiadis. Alternatives for multimedia messaging system steganography.In Yue Hao, Jiming Liu, Yu-Ping Wang, Yiu-ming Cheung, Hujun Yin, LichengJiao, Jianfeng Ma et Yong-Chang Jiao, éditeurs, Computational Intelligence andSecurity. Tome 3802, Lecture Notes in Computer Science, pages 589–596. SpringerBerlin Heidelberg, 2005.

[30] Szymon Grabski et Krzysztof Szczypiorski. Steganography in OFDM symbolsof fast IEEE 802.11n networks. In 2013 IEEE Security and Privacy Workshops,pages 158–164, San Francisco, CA. IEEE, mai 2013.

[31] Krzysztof Szczypiorski. A performance analysis of HICCUPS - a steganographicsystem for WLAN, juin 2009. arXiv : 0906.4217.

[32] Wojciech Mazurczyk, Pawel Szaga et Krzysztof Szczypiorski. Using transcodingfor hidden communication in IP telephony, novembre 2011. arXiv : 1111.1250.

[33] J. A. Hoarau Kevin. Travail préliminaire sur la consommation énergétique d’unsmartphone android. Janvier 2017.

[34] Android. Monitoring the battery level and charging state. url : https://developer.android.com/training/monitoring-device-state/battery-monitoring.html(visité le 21/05/2017).

[35] Android. Measuring device power. 2017. url : https://source.android.com/devices/tech/power/device (visité le 21/05/2017).

[36] Android. Dumpsys system diagnostics. 2017. url : https://source.android.com/devices/tech/debug/dumpsys (visité le 21/05/2017).

39

[37] Android. Viewing battery use data. 2017. url : https://source.android.com/devices/tech/power/batterystats (visité le 21/05/2017).

[38] Yan Michalevsky, Gabi Nakibly, Aaron Schulman, Gunaa A. Veerapandianet Dan Boneh. PowerSpy : location tracking using mobile device power analysis,août 2015. arXiv : 1502.03182.

[39] Lin Yan, Yao Guo, Xiangqun Chen et Hong Mei. A study on power side channelson mobile devices. In Proceedings of the 7th Asia-Pacific Symposium on Internetware,Internetware ’15, pages 30–38, Wuhan, China. ACM, 2015.

[40] Luca Caviglione, Mauro Gaggero, Jean-Francois Lalande, Wojciech Mazurc-zyk et Marcin Urbanski. Seeing the unseen : revealing mobile malware hiddencommunications via energy consumption and artificial intelligence. IEEE Transac-tions on Information Forensics and Security, 11(4) :799–810, avril 2016.

[41] Dave Evans. Mooc : applied cryptography. url : https://www.udacity.com/course/applied-cryptography--cs387.

40

41

Annexe A

Annexes

A.1 Présentation du LIM

J’effectue mon stage de Master 2 au sein du Laboratoire d’Informatique et de Mathé-matiques (LIM) de l’Université de la Réunion. Le LIM est dirigé par Pr. Jean Diatta etest structuré en trois axes :

— L’axe Epistémologie et Didactique de l’Informatique et des Mathématiques (EDIM)mené par Pr. Dominique Tournès

— L’axe InformaTique et Applications (ITA) avec à sa tête Pr. Etienne Payet

— L’axe Mathématiques (MATHS) gérer par Pr. Marianne Morillon

L’axe ITA comporte notamment le groupe de travail Informatique Mobile et Communi-cante (IMC) au sein duquel j’effectue mon stage. En plus de ses activités de recherche leLIM participe à la formation en adossant notamment la filière Informatique et Mathéma-tiques de l’UFR Sciences et Technologies. Il est également membre de l’École doctoraleSciences Technologies Santé (STS) et de la fédération de recherche Observatoire des Mi-lieux Naturels et des Changements Globaux (OMNCG) de l’Université de la Réunion.

A.2 Planning

Afin d’atteindre l’objectif du stage, j’ai déterminé un ensemble de tâches qui sont àeffectuer. Le tableau A.1 dresse l’ensemble de ces tâches ordonnées chronologiquement.Ces dernières sont regroupées en trois étapes d’avancement :

1. La récolte : il faut durant cette période déterminer quels types de données il estpossible de récolter et de quelle manière. L’impact de la récolte des données doitégalement être évalué.

2. L’analyse : une fois les données recueillies, l’étape d’analyse consiste définir la façonde les exploiter et leur niveau interprétabilité.

3. La mise en œuvre : cette dernière étape vise à la construction d’un prototype fonc-tionnel de communication stéganographique à travers la consommation énergétiqued’un smartphone. Ce prototype sera alors évalué en termes de bande passante, derobustesse et de détectabilité.

42

Récolte

1.1 Exploration des possibilités de récolte de donnéesde consommation énergétique sous Android

1.2 Donnée récupérable : précision et granularité temporelle1.3 Évaluation de l’impact des mesures1.4 Récolte des événements de réception des messages

Analyse

2.1 Visualisation des données brutes2.2 Post traitement sur les données2.3 Étude de l’empreinte énergétique des messages2.4 Détection des messages reçus via la consommation énergétique

Mise en ouvre

3.1 Exploration des possibilités d’encodage3.2 Étude de la robustesse face au bruit3.3 Développement d’un prototype3.4 Évaluation de performance : débit et taux d’erreur

Table A.1 : Organisation des tâches

Il est prévu que chacune de ces étapes a une durée de mise en œuvre équivalente. Ainsi,pour une réalisation en six mois, chaque étape doit être effectuée en deux mois maximum.J’ai donc fixé le planning suivant :

— Fin février : étape de récolte terminée

— Fin avril : fin de l’étape d’analyse

— Fin juin : mise en œuvre effectuée

A.3 MOOC : Applied Cryptography

Nous avons reçu la consigne de suivre au moins un MOOC durant ce stage sur lethème et la plate-forme de notre choix. Ainsi, j’ai suivis le MOOC intitulé « AppliedCryptography » [41] sur la plate-forme Udacity. J’ai choisis ce MOOC car la cryptographieest un domaine voisin de stéganographie et qui attire mon attention.

Le MOOC est divisé en 7 unités d’enseignements durant lequel on commence par poserles fondations mathématiques sur lesquelles la cryptographie est construite jusqu’à arrivéà l’utilisation de la cryptographie dans les technologies actuelles.

A.3.1 Unité 1

Durant cette unité, on introduit la notion de système de chiffrement symétrique danslequel deux participants partagent une clé sécrète k ∈ K préalablement convenue et l’utilisepour chiffrer et déchiffrer un message m ∈ M (avec K l’espace des clés possibles et M

l’espace des messages possibles). On définie également, la fonction de chiffrement Ek(m) =c et la fonction de déchiffrement Dk(c) = m avec c ∈ C l’ensemble des messages chiffréspossibles. Puis on aborde les notions de système cryptographique correcte et sécurisé. Parcorrect on entend que quelque soit le message m et la clé k on a Dk(Ek(m)) = m etpar sécurisé que le message chiffré c ne révèle rien sur k et m. On voit également que unchiffrement parfait tel que le « One-Time Pad » n’est pas utilisable en pratique puisqu’il

43

nécessite que |K| >= |M |. Enfin, les système de chiffrement moderne tel que AES sontintroduits.

A.3.2 Unité 2

Cette unité ce concentre sur l’utilisation pratique du chiffrement symétrique, leurcontexte d’application et les pièges à éviter. On commence par poser le problème de lagénération de la clé de chiffrement et sur la difficulté de généré des clés véritablementaléatoires. On présente alors le concept des générateurs de nombre aléatoire qui permettede produire une grande quantité de données pseudo aléatoire à partir d’une petite quantitéde données aléatoire. On introduit également les fonctions de hachage cryptographique etleur utilisation pour le stockage de mot de passe. Enfin, on présente le concept des « hashchain » et leur utilisations pour l’authentification sans mot de passe côté serveur.

A.3.3 Unité 3

L’unité 3 aborde le problème de l’établissement de la clé entre les deux participants.Le protocole de Diffie-Hellman apporte une solution à ce problème en permettant l’éta-blissement d’un clé sécrète sur un canal non sécurisé. Pour cela, ce protocole s’appuie surle fait qu’on ne connaît pas d’algorithme efficace pour le calcul du logarithme discret.Cependant, il n’est pas résistant face à un attaquant actif qui peut effectuer une attaquede l’homme du milieu.

A.3.4 Unité 4

Dans cette unité on introduit le concept de chiffrement asymétrique qui utilise uneclé différentes pour le chiffrement est le déchiffrement. Ainsi, la fonction de chiffrementEku(m) = c utilise une clé publique ku alors que ces la clé privé kr qui est utilisé parla fonction de déchiffrement Dkr (c) = m. Des exemples d’applications de ses système dechiffrement sont alors détaillés avec l’échange de message privé et les signatures numérique.Enfin, le système chiffrement RSA est introduit et on démontre qu’il est correct et sécurisé.

A.3.5 Unité 5

Cette unité nous présentent le fonctionnement de protocole utilisant des systèmes dechiffrements. Ainsi, trois protocole sont décrits : EKE (Encrypted Key Exchange), SSH(Secure SHell) et TLS (Transport Layer Security). Ces trois protocoles au en communqu’il doivent établir une authentification réciproque entre un client et un serveur.

A.3.6 Unité 6

Durant cette unité on nous présente l’utilisation de la cryptographie pour résoudredifférents problèmes. On commence alors par voir comment l’anonymisation d’un com-munication peut être effectué grâce à la cryptographie. Pour cela, le routage en oignonqui utilise des chaînes de chiffrement à clé publique est présenté. Puis, des systèmes de

44

votes et de monnaie électronique sont présentées. Enfin, on apprend le fonctionnement desmonnaie électronique décentralisé tel que Bitcoin qui utilise un « bloc chain ».

A.3.7 Unité 7

L’unité 7 conclue le MOOC en présentant le concept de « secure computation » dontl’objectif est d’effectuer des calcule entre deux partie qui ne se font pas confiance. Cesdeux partie A et B possèdent des données privé, respectivement a et b et souhaite obtenirle résultat d’une fonction f(a, b) sans que une des partie est accès au données de l’autre.Pour cela, il s’appuie sur le fait que n’importe quelle fonction discrète à taille fixe peut êtrereprésenté par des portes logique. Ainsi, il utilise des portes logique sécurisées s’appuyantsur des système de chiffrement.

A.4 Résultats de détection

A.4.1 Un seul fichier

Approche simple :

Smar. Inter. Pre-traitement Technique F1. Acc. TP FP TN FNSonyZ2

60s movingAverage(window=6)

distributionOnce(threshold=0.2,size=7)

0.72 0.57 29 4 0 18

SonyZ2

30s movingAverage(window=10)

threshold- Adap-tiveOnce (thre-shold=0.7)

0.84 0.75 112 31 0 8

SonySP

30s movingAverage(window=20)

thresholdOnce(threshold=0.5)

0.88 0.8 110 19 0 9

45

Approche par slot :

Smart. Inter. Pre-traitement Technique F1. Acc. TP FP TN FNSonyZ2

60s movingAverage(window=2)

distribution(threshold=0.3,size=3)

0.98 0.98 46 1 46 1

SonySP

60s None distribution(threshold=0.5,size=4)

1 1 47 0 47 0

SonyZ2

30s movingAverage(window=20)

distribution(threshold=0.7,size=6)

0.96 0.96 113 7 110 2

SonySP

30s None distribution(threshold=0.4,size=7)

0.96 0.96 113 6 112 3

SonyZ2

30s movingAverage(window=4)

threshold (thre-shold=0.8)

0.96 0.96 118 8 111 1

SonySP

30s movingAverage(window=20)

distribution(threshold=0.6,size=3)

0.96 0.95 116 8 112 2

A.4.2 Plusieurs fichiers (Approche simple)

Résultats d’ensemble :

# Pre-traitement Technique F1. Acc. TP FP TN FN1 movingAverage

(window=20)threshold- Adap-tiveOnce (thre-shold=0.4)

0.76 0.6 289 150 0 44

2 movingAverage(window=10)

threshold- Adap-tiveOnce (thre-shold=0.7)

0.74 0.59 283 148 0 51

46

Résultats détaillés :

# Smart. Inter. F1. Acc. TP FP TN FN1 Sony

SP60s 0.7 0.53 39 26 0 8

1 SonySP

30s 0.82 0.69 111 41 0 8

1 SonyZ2

30s 0.74 0.59 101 52 0 19

1 SonyZ2

60s 0.66 0.49 38 31 0 9

# Smart. Inter. F1. Acc. TP FP TN FN2 Sony

SP60s 0.46 0.3 17 10 0 30

2 SonySP

30s 0.74 0.58 111 72 0 8

2 SonyZ2

30s 0.84 0.75 112 31 0 8

2 SonyZ2

60s 0.68 0.52 43 35 0 5

A.4.3 Plusieurs fichiers (Approche par slot)

Résultats d’ensemble :

# Pre-traitement Technique F1. Acc. TP FP TN FN1 movingAverage

(window=6)distribution(threshold=0.6,size=5)

0.94 0.94 320 35 294 5

2 movingAverage(window=4)

threshold (thre-shold=0.6)

0.92 0.91 323 54 279 8

47

Résultats détaillés :

# Smart. Inter. F1. Acc. TP FP TN FN1 Sony

SP60s 0.94 0.94 47 6 41 0

1 SonySP

30s 0.94 0.94 115 12 106 1

1 SonyZ2

30s 0.94 0.94 111 9 108 4

1 SonyZ2

60s 0.92 0.91 47 8 39 0

# Smart. Inter. F1. Acc. TP FP TN FN2 Sony

SP60s 0.94 0.94 42 1 46 5

2 SonySP

30s 0.88 0.86 116 31 89 2

2 SonyZ2

30s 0.94 0.93 118 15 104 1

2 SonyZ2

60s 0.94 0.93 47 7 40 0

48