Bridging the gap between Privacy by Design and mobile systems by patterns

176 Pages·2016·10.89 MB·English

by  Karina Perez

Thèse
de doctorat

de l’UTT
Karina SOKOLOVA PEREZ
Bridging the Gap between
Privacy by Design
and Mobile Systems by Patterns

Spécialité :
Ingénierie Sociotechnique des Connaissances, des Réseaux
et du Développement Durable

2016TROY0008 Année 2016
THESE

pour l’obtention du grade de

D de l’U
OCTEUR NIVERSITE

T T
DE ECHNOLOGIE DE ROYES
Spécialité : INGENIERIE SOCIOTECHNIQUE DES CONNAISSANCES ET

DES RESEAUX

présentée et soutenue par

Karina SOKOLOVA PEREZ

le 27 avril 2016

Bridging the Gap between Privacy by Design
and Mobile Systems by Patterns

JURY

M. B. NGUYEN PROFESSEUR DES UNIVERSITES Président (Rapporteur)
M. M. CONTI PROFESSORE ASSOCIATO CONFERMATO Examinateur
M. D. LE METAYER DIRECTEUR DE RECHERCHE INRIA Rapporteur
M. M. LEMERCIER MAITRE DE CONFERENCES Directeur de thèse

Personnalités invitées

M. J.-B. BOISSEAU INGENIEUR
M. A. VERNIER INGENIEUR
Acknowledgments
I would like to express my special appreciation and thanks to my advisor Dr. Marc
Lemercier, who has been an exceptional mentor for me. I would like to thank you for
encouraging my research and for allowing me to develop as a research scientist. Your
advice on my research, as well as on my career, and your trust in me have been beyond
price.
IwouldliketothankalltheteamofEutechSSIIandAlpix,whowerealwaysavailableto
share their knowledge and professional experience with me and always willing to discuss
and exchange opinions. I would especially like to thank my advisor : Jean-Baptiste
Boisseau, one of the co-founders of Eutech SSII, who was enthusiastic about my work and
research from the first day we met. During the most difficult times during the writing of
this thesis, my advisors gave me moral support and freedom I needed to move on.
I would especially like to thank everyone from University of Technology of Troyes who
hadtrustinmemeandwhohelpedmetointegrateaFrenchuniversityandFrenchsociety.
Iamalsoverygratefultoalltheprofessorswhogavemethepossibilityofexpressingmyself
as a lecturer and lecturer assistant.
A special thanks to my family: words cannot express how grateful I am to my mother,
and father for all the sacrifices they have made on my behalf. I would also like to thank
all of my friends, in particular my dear friend Natalia Sirina who was always there when
no one would answer my queries. Finally, I would like to express my appreciation to
my beloved husband Charles Perez sustained me through sleepless nights and pushed me
towardsmygoal. Icannotfindthewordstothankyouforyourencouragementallthrough
this adventure.
i

Contents
Contents iii
List of Figures vii
List of Tables ix
1 Introduction 1
1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Document organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
I State-of-the-art 7
2 Privacy, Privacy by Design and European regulation 9
2.1 Privacy in European Union . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Privacy by Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Architectural design patterns and mobile development 15
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Architectural design patterns . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Model-View-Controller (MVC) . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Presentation-Abstraction-Control (PAC) . . . . . . . . . . . . . . . 18
3.2.3 Model-View-Presenter (MVP) . . . . . . . . . . . . . . . . . . . . . 18
3.2.4 Hierarchical-Model-View-Controller (HMVC) . . . . . . . . . . . . . 19
3.3 iOS system and architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Android system and architecture . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Mobile architecture related works . . . . . . . . . . . . . . . . . . . . . . . 22
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Mobile permission systems 25
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Limits of modern mobile permission systems . . . . . . . . . . . . . . . . . 29
4.3 Mobile permission analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.1 Permission request analysis . . . . . . . . . . . . . . . . . . . . . . 32
4.3.1.1 Benign applications . . . . . . . . . . . . . . . . . . . . . . 32
iii
CONTENTS
4.3.1.2 Malicious applications . . . . . . . . . . . . . . . . . . . . 33
4.3.2 Permission use analysis tools . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Permission-based decision support systems . . . . . . . . . . . . . . . . . . 34
4.5 Improvement of modern mobile permission systems . . . . . . . . . . . . . 35
4.5.1 Revoke permissions and mock data tools . . . . . . . . . . . . . . . 35
4.5.2 Conditional granting . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5.3 Usage model and Digital rights management (DRM) technologies . 36
4.5.4 Finer-grained mobile permissions . . . . . . . . . . . . . . . . . . . 36
4.6 Code analysis and data flow control . . . . . . . . . . . . . . . . . . . . . . 37
4.6.1 Static analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6.2 Dynamic analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7 Other works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.7.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.7.2 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.7.3 Permissions as an attack vector . . . . . . . . . . . . . . . . . . . . 40
4.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
II Quality and Security 41
5 Development of mobile applications of quality: Android Passive MVC archi-
tectural pattern 43
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Research methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Developers’ experience and difficulties . . . . . . . . . . . . . . . . . . . . . 46
5.4 Android Passive MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.4.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4.2.1 Fragments usage . . . . . . . . . . . . . . . . . . . . . . . 52
5.4.2.2 Java classes . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.5 ’Tweetle’ Android application and Android Passive MVC . . . . . . . . . . 56
5.5.1 Fragment mediate Activities . . . . . . . . . . . . . . . . . . . . . . 57
5.5.2 Fragment/Activity mediate Fragments . . . . . . . . . . . . . . . . 58
5.5.3 Advantages and disadvantages . . . . . . . . . . . . . . . . . . . . . 58
5.6 Android Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.7 Architecture evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.7.1 Code quality requirements . . . . . . . . . . . . . . . . . . . . . . . 61
5.7.2 Scenario-based evaluation . . . . . . . . . . . . . . . . . . . . . . . 61
5.7.2.1 Scenario 1: adapt the phone version to the tablet . . . . . 62
5.7.2.2 Scenario 2: add new tab to the main menu . . . . . . . . . 63
5.7.2.3 Scenario 3: move the main menu to the separate screen . . 63
5.7.2.4 Scenario 4: modify the appearance of the list . . . . . . . 63
5.7.2.5 Scenario 5: add new interface element . . . . . . . . . . . 64
5.7.3 Evaluation by developers . . . . . . . . . . . . . . . . . . . . . . . . 64
5.8 Discussion and future work . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.8.1 Android and MVP . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.8.2 Android and AM-MVC . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
iv
CONTENTS
III Security and Privacy 69
6 Detecting abusive applications: permission usage patterns for applications’
classification and anomaly detection 71
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2 Related works and limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3 Research methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3.1 Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3.2 Permission usage pattern construction . . . . . . . . . . . . . . . . 76
6.3.3 Classification of applications into categories . . . . . . . . . . . . . 79
6.3.3.1 The application classification problem . . . . . . . . . . . 79
6.3.3.2 Features selection . . . . . . . . . . . . . . . . . . . . . . . 80
6.3.4 Privacy score and risk metrics . . . . . . . . . . . . . . . . . . . . . 81
6.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.4.1 The category patterns obtained . . . . . . . . . . . . . . . . . . . . 83
6.4.2 Graph centrality features vs. occurrence . . . . . . . . . . . . . . . 85
6.4.3 Classification and features accuracy . . . . . . . . . . . . . . . . . . 87
6.4.4 Risk warning for suspicious applications . . . . . . . . . . . . . . . 90
6.4.5 Category similarity . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.5 Discussion and future work . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7 Respecting user’s privacy by default: a PbD permission system for mobile
applications 99
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.2 Related works and limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.3 Privacy-respecting permission system overview and vocabulary . . . . . . . 101
7.3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.3.2 Object: private data . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.3.3 Permission use restrictions . . . . . . . . . . . . . . . . . . . . . . . 105
7.3.4 Permission state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.3.5 User control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.3.6 Permissions interconnection . . . . . . . . . . . . . . . . . . . . . . 107
7.4 The permission system in action . . . . . . . . . . . . . . . . . . . . . . . . 108
7.5 Application Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.6 Discussion and future work . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8 Conclusion 117
8.1 Problematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
9 Publications 121
10 Appendix 123
v
CONTENTS
11 Résumé 139
11.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
11.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
11.3 Questions de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
11.4 Vue sur le respect de la vie privée et « Privacy by Design » . . . . . . . . . 141
11.5 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
11.5.1 Android Passive MVC . . . . . . . . . . . . . . . . . . . . . . . . . 143
11.5.2 Indicateur du respect de la vie privée . . . . . . . . . . . . . . . . . 146
11.5.3 Système de permissions « Privacy by Design » . . . . . . . . . . . . 149
11.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Bibliography 153
vi
List of Figures
3.2.1 a) Classic MVC, b) Application Model MVC . . . . . . . . . . . . . . . . 17
3.2.2 Passive Model MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3 PAC architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.4 Supervising controller and Passive view . . . . . . . . . . . . . . . . . . . 19
3.2.5 Hierarchical-Model-View-Controller . . . . . . . . . . . . . . . . . . . . . 19
4.1.1 Java ME MIDlet asks for a permission. . . . . . . . . . . . . . . . . . . . 27
4.1.2 iOS (left) and Android (right) systems ask for permissions. . . . . . . . . 28
5.2.1 Research methodology for Android passive MVC . . . . . . . . . . . . . . 46
5.3.1 Activity as ’View-Presenter’ of MVP or a ’Controller’ of MVC . . . . . . 46
5.3.2 Activity as ’View’ of MVP with additional Presenter component . . . . . 47
5.3.3 Activity as ’View’ of MVC with additional Controller component. . . . . . 48
5.3.4 Activity as ’Presenter’ of MVP with additional View component. . . . . . 48
5.4.1 Activity as an intermediate component between Views and Controllers. . 50
5.4.2 Android Passive MVC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4.3 Communication between Controllers. . . . . . . . . . . . . . . . . . . . . 51
5.4.4 AP-MVC impose the creation of Fragment event if the only one is cur-
rently used within Activity . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4.5 Mediate Fragment corresponding to the possible menu that exchange 2
Fragments depending on intercepted action . . . . . . . . . . . . . . . . . 53
5.4.6 A chain of dependent Fragments or Activities. a) Direct calls make de-
pendent Fragments b) Mediate Controller makes components independent 54
5.4.7 Communication between Fragments and Activity. . . . . . . . . . . . . . 54
5.4.8 Circular dependency between Fragments a) Direct calls, dependent Frag-
ments b) Mediator Controller makes Fragments independent . . . . . . . 55
5.4.9 Android Passive MVC implementation . . . . . . . . . . . . . . . . . . . . 55
5.4.10Login implementation example . . . . . . . . . . . . . . . . . . . . . . . . 56
5.5.1 ’Tweetle’ application user interface . . . . . . . . . . . . . . . . . . . . . . 57
5.5.2 Activity by screen initialisation calls . . . . . . . . . . . . . . . . . . . . . 58
5.5.3 Activity as Main Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.6.1 Domain Model Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3.1 The summary of 3-step methodology . . . . . . . . . . . . . . . . . . . . 75
6.3.2 Five steps of pattern construction methodology. . . . . . . . . . . . . . . 76
6.3.3 Exampleoffeatureconstructionforoneapplication,onemetricandpatterns. 81
6.3.4 Risk threshold representation for different settings of α; applications col-
ored in red would raise the warning for α > 1 . . . . . . . . . . . . . . . 82
vii
LIST OF FIGURES
6.4.1 Examplesofobtainedpermissionpatternsforfourscategories. Colorsrep-
resent the modularity classes, node size represents betweenness centrality
score and edge thickness represents the weight. . . . . . . . . . . . . . . . 84
6.4.2 Performance gain brought while adding all metrics one by one to between-
ness centrality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.4.3 Binaryvectorandpattern-relatedfeaturescomparisonregardingF-measure
and all categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.4.4 Performance for risky application detection in ’Photography’ category.
ROCcurvesforfordifferentβ (denotedBetaonthegraph)andthresholds
for the equation 6.3.7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.4.5 Graph representing how the minimal likeness and beta affects risky appli-
cation detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.4.6 Optimal threshold for detecting risky applications β = 3, threshold =
0.108, LN = 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
0
6.4.7 Category similarity graph . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.3.1 Different actions can be made on the data and included into the proposed
permission system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.3.2 Summary of the the proposed permission system definition . . . . . . . . 104
7.3.3 Example of state modification diagram for a given permission . . . . . . 106
7.3.4 Activity diagram for the rule definition . . . . . . . . . . . . . . . . . . . 107
7.3.5 Activity diagram: permission management. . . . . . . . . . . . . . . . . 109
7.4.1 Example of a permission request . . . . . . . . . . . . . . . . . . . . . . . 109
7.4.2 Sequence diagram: first use of one permission or a use or permission in
’user check’ mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.4.3 Sequence diagram: use of one permission without user confirmation. . . . 110
7.4.4 Example of usage modification diagram for a given permission . . . . . . 111
viii