on the effectiveness of trust leases in securing mobile ... · the goal of this work is then to...
TRANSCRIPT
On the Effectiveness of Trust Leasesin Securing Mobile Applications
Nuno Miguel de Oliveira Duarte
Thesis to obtain the Master of Science Degree in
Information Systems and Computer Engineering
Supervisors: Prof. Dr. Paulo Jorge Pires FerreiraProf. Dr. Nuno Miguel Carvalho dos Santos
Examination Committee
Chairperson: Prof. Dr. José Carlos Alves Pereira MonteiroSupervisor: Prof. Dr. Paulo Jorge Pires Ferreira
Member of the Committee: Prof. Dr. Henrique João Lopes Domingos
November 2015
ii
Acknowledgments
First of all, I would like to thank my supervisors, Professor Paulo Ferreira and Professor Nuno Santos,
for the continuous support, motivation, and guidance throughout this thesis.
Second, I would like to thank my parents, for their love, and endless support during my spell at
Instituto Superior Tecnico (IST).
Third, I would like to thank everyone who accepted to participate in the user tests. In particular, for
the mExam user tests, I would like to thank Jose Cavalheiro, Alberto Carvalho, Sancha Pereira, Rodrigo
Lourenco, Rita Levy, Telma Pereira, Pedro Curto, Tiago Brito, Bruno Candeias and Rodrigo Bruno. For
the mMeeting user tests, I would like to thank Marta Baptista, Tiago Neves, Tiago Fidalgo, Emanuel
Andrade and Zaida Freire. For the mTicket user tests, I would like to thank Sebastiao Freire, Miguel
Baptista, Monica Baptista, Maria Pina, Fernando Ramos, Joao Ramos, Miguel Ramos, Alda Rodrigues,
Angelo Silva, Laima Frichenbruders, Carolina Cordeiro, Aristea Sapera and Ioannis Papoutsis.
I would also like to thank everyone who accepted to participate in the adoption questionnaires. Re-
garding the mExam questionnaires, I would like to give a special thanks to all the professors from the De-
partment of Computer Science and Engineering of IST, who accepted to participate. For the mMeeting
questionnaires, I would like to thank Ana Correia from Thing Pink, Ines La Feria from Banco Santander,
Joana Pereira from Glintt, and again to Tiago Fidalgo from InnoWave Technologies, Marta Baptista from
Beta-i and Emanuel Andrade from Caixa Geral de Depositos, as well as all their colleagues who partic-
ipated. For the mTicket questionnaires, I would like to thank the managers from the movie theaters of
the Saldanha Residence, Dolce Vita Monumental, Alegro Alfragide, and Campo Pequeno malls, as well
as the Cinema City movie theater in Alvalade.
Finally, I would also like to give a big acknowledgement to all my friends and colleagues, who made
this journey that much easier.
To everyone of you, thank you!
iii
iv
Resumo
Nos ultimos anos assistimos a uma enorme evolucao nas capacidades dos dispositivos moveis. Ainda
assim, ha muitas tarefas que nao realizamos atraves desses dispositivos, pois os sistemas operativos
moveis (MOSes), nao oferecem os mecanismos necessarios para garantir a seguranca dessas tarefas.
Por exemplo, hoje e impossıvel permitir que alunos respondam a exames atraves dos seus dispositivos.
Como os MOSes nao oferecem mecanismos para restringir o acesso a Internet e prevenir a execucao
de aplicacoes, os alunos podiam cometer fraudes, que a vigilancia humana dificilmente detectaria.
Por outro lado, as extensoes a seguranca dos MOSes, nao resolvem o problema, ora por oferecerem
restricoes aos recursos dos dispositivos com abrangencia ou granularidade inapropriadas, ora por nao
oferecerem restricoes ao ciclo de vida de aplicacoes.
Para visar o problema, propusemos recentemente uma nova primitiva denominada trust lease. Um
mecanismo que permite a utilizadores e outras entidades a negociacao de restricoes quer a recursos
quer ao ciclo de vida de aplicacoes (ex. prevenir o acesso a Internet e a execucao de aplicacoes). Estas
restricoes sao entao aplicadas sob condicoes especıficas, nos dispositivos moveis dos utilizadores.
O objectivo deste trabalho passa pelo desenvolvimento de aplicacoes nao suportadas pelos MOSes
de hoje em dia, e testar a eficacia desta primitiva em garantir a seguranca destas aplicacoes. Testamos
tambem os efeitos da primitiva em aplicacoes e spywares reais, e conduzimos um estudo de adopcao
para perceber qual a abertura dos potenciais utilizadores em adoptar esta solucao. Os resultados
recolhidos sao favoraveis a utilizacao da primitiva.
Palavras-chave: Controlo de Acesso a Recursos Moveis, Controlo de Execucao de Applicacoes,
Trust Lease, Exames Electronicos Moveis, Prevencao de Fugas de Informacao Sensıvel, Controlo de
Acesso Baseado em Contextos
v
vi
Abstract
In recent years we have witnessed a tremendous evolution in mobile devices’ capabilities. However,
there are still activities that we do not do resorting to these devices, because mobile OSes (MOSes)
do not offer the necessary mechanisms to secure these activities. For instance, today is impossible to
allow students to answer exams using their devices. Because MOSes offer no mechanisms capable
of restricting Internet access and the execution of applications, students would be free to cheat, and
human invigilation is a fallible solution. On the other hand, the few security extensions created for these
OSes, come short in providing solutions to this problem, either by offering inappropriate OS resource
restriction scope and granularity, or by offering no application lifetime restrictions.
In order to address this problem, we recently proposed a new OS primitive called trust lease. A
mechanism that allows for users and third parties to negotiate OS resource and application lifetime re-
strictions (e.g., prevent Internet access and the execution of apps). These restrictions are then enforced
under very specific geographical and / or temporal conditions on users’ devices.
The goal of this work is then to develop new applications, currently unsupported by MOSes, and test
the effectiveness of this new primitive in securing these applications’ scenarios. Additionally, we test
the effects of trust leases on real-world applications and spyware, and we conduct an adoption study to
understand how open would users feel to adopt this solution. The results we collected encourage the
use of the primitive.
Keywords: Device Resource Access Control, Application Lifetime Control, Trust Lease, Mobile
Electronic Exams, Sensitive Information Leak Prevention, Context Aware Device Resource Control
vii
viii
Contents
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
1 Introduction 1
1.1 Goals & Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Current Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Related Work 5
2.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Electronic Exams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Other Related Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Mobile Security Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Digital Rights Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Access Control Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.3 Permission Refinement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4 Application Communication Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.5 Privacy Enhancement Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.6 Access Control Hook APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.7 Memory Instrumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Architecture 25
3.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Operation Mode Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.2 Restricted Mode Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.3 The TrUbi System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
ix
3.1.4 Strapp workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Strapp Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 Trust Lease Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Use Case Strapps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.1 mExam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.2 mMeeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.3 mTicket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 Implementation 41
4.1 Strapp Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1 Secure Channel Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.2 Mode Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.3 Strapp Middleware API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.4 Network and NFC Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Use Case Strapps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.1 Trust Leases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.2 Differences between Design and Implementation . . . . . . . . . . . . . . . . . . . 52
4.2.3 Central Servers Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.4 Demo Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5 Evaluation 55
5.1 Trust Lease Effects on Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.1 Real World Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.2 Real-World Malware / Spyware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Trust Lease Protocol Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3 Use Case Strapp User Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.2 mExam Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3.3 mMeeting Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3.4 mTicket Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3.5 Summary of User Test Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.4 Strapp Adoption Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.4.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.4.2 mExam – Students Questionnaire Findings . . . . . . . . . . . . . . . . . . . . . . 72
5.4.3 mMeeting – Meeting Attendants Questionnaire Findings . . . . . . . . . . . . . . . 74
5.4.4 mTicket – Movie Spectators Questionnaire Findings . . . . . . . . . . . . . . . . . 75
5.4.5 Summary of Adoption Study Findings . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
x
6 Conclusion 79
Bibliography 81
A Android SSL Development 87
B Strapp Middleware API Example 89
C NFC Background 91
D Use Case Strapp Wireframes 93
E Restriction Development Comparison 97
F Lessee Adoption Study 101
F.1 mExam – Professors Study Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
F.2 mMeeting – Meeting Organizers Study Findings . . . . . . . . . . . . . . . . . . . . . . . 103
F.3 mTicket – Movie Theater Managers Study Findings . . . . . . . . . . . . . . . . . . . . . . 104
F.4 Summary of Adoption Study Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
xi
xii
List of Tables
2.1 Matching between the related systems and restriction support. . . . . . . . . . . . . . . . 23
3.1 Restrictions supported by TrUbi’s trust lease implementation. . . . . . . . . . . . . . . . . 28
5.1 Effects of trust leases on real mobile applications. . . . . . . . . . . . . . . . . . . . . . . 57
5.2 Observed behavior when testing trust leases on real mobile applications. . . . . . . . . . 57
5.3 Performance of trust lease protocol (50 test average). . . . . . . . . . . . . . . . . . . . . 59
xiii
xiv
List of Figures
2.1 DRM ecosystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Android DRM framework’s architecture (adapted from [2]). . . . . . . . . . . . . . . . . . . 10
2.3 MOSES architecture (adapted from [79]). . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Android application communication attacks (confused deputy attack (a), collusion attack
(b)). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 TaintDroid architecture (adapted from [46]). . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 General access hook API architecture (adapted from [57]). . . . . . . . . . . . . . . . . . 20
3.1 TrUbi architecture (strapps represented in light grey). . . . . . . . . . . . . . . . . . . . . . 27
3.2 Strapp workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Strapp middleware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Trust lease protocol workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5 SSL version comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 Simplified SSL detailed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.7 Mode transition phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8 mExam workflow (with the student being the lessor, and the professor the lessee). . . . . 34
3.9 mMeeting workflow (with the attendant being the lessor, and the host the lessee). . . . . . 36
3.10 mTicket workflow (with the user being the lessor, and the cinema terminal the lessee). . . 38
4.1 Strapp Middleware implementation and corresponding workflow (lessor’s perspective). . . 42
4.2 UML representation of TLP’s implementation. . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 mExam identity confirmation dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4 UML representation of TLP’s network implementation (new components in grey). . . . . . 47
4.5 UML representation of TLP’s NFC implementation (new components in grey). . . . . . . . 48
4.6 Android TLP APDU message structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.7 Standard TLP APDU message structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.8 Use case strapps’ screenshots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1 SSL performance comparison (50 test average). . . . . . . . . . . . . . . . . . . . . . . . 60
5.2 mExam ease of use, intuitiveness and responsiveness user evaluation (10 test average). 64
5.3 mMeeting ease of use, intuitiveness and responsiveness user evaluation (10 test average). 66
5.4 mMeeting restriction popup usefulness (5 test average). . . . . . . . . . . . . . . . . . . . 67
xv
5.5 mTicket ease of use, intuitiveness and responsiveness user evaluation (10 test average). 68
5.6 mTicket restriction popup usefulness (10 test average). . . . . . . . . . . . . . . . . . . . 69
5.7 Students’ comfort with OS restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.8 Students’ comfort and worries about trust leases. . . . . . . . . . . . . . . . . . . . . . . . 73
5.9 Attendants’ comfort with OS restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.10 Meeting habits, and attendants openness to adopt mMeeting. . . . . . . . . . . . . . . . . 75
5.11 Attendants’ comfort and worries about trust leases. . . . . . . . . . . . . . . . . . . . . . . 76
5.12 Spectators’ comfort with OS restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.13 Movie theater habits, and spectator openness to adopt mTicket. . . . . . . . . . . . . . . 77
5.14 Spectators’ comfort and worries about trust leases. . . . . . . . . . . . . . . . . . . . . . . 78
C.1 Card emulation solutions (adapted from [16]) . . . . . . . . . . . . . . . . . . . . . . . . . 92
D.1 Wireframe of the mExam strapp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
D.2 Wireframe of the mExam professor strapp. . . . . . . . . . . . . . . . . . . . . . . . . . . 94
D.3 Wireframe of the mMeeting strapp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
D.4 Wireframe of the mTicket strapp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
F.1 Movie disturbance occurrence and report frequency. . . . . . . . . . . . . . . . . . . . . . 104
F.2 Movie disturbance seriousness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
xvi
Glossary
APDU Application Protocol Data Unit
API Application Programming Interface
BYOD Bring Your Own Device
DAC Discretionary Access Control
DRM Digital Rights Management
HCE Host Card Emulation
HTTPS Hypertext Transfer Protocol Secure
HTTP Hypertext Transfer Protocol
IMEI International Mobile Station Equipment Identity
IPC Inter Process Communication
IP Internet Protocol Address
IRM Inline Reference Monitor
LOC Lines Of Code
MAC Mandatory Access Control
MMS Multimedia Messaging Service
MOS Mobile Operating System
MT Mode Transition Phase
NFC Near Field Communication
OMA Open Mobile Alliance
OS Operating System
P2P Peer To Peer
QR Quick Response Code
RFID Radio Frequency Identification
SEC Secure Channel Establishment Phase
SMS Short Message Service
SSL Secure Sockets Layer
TLP Trust Lease Protocol
UID User Id
UML Unified Modeling Language
XML Extensible Markup Language
xvii
xviii
Chapter 1
Introduction
Over the past years, we have witnessed incredible advances in mobile technology. Smartphones and
tablets emerged, equipped with powerful sensors and with network interfaces that allow for everywhere
connection with online services and nearby devices. Because mobile devices are fully programmable,
users can enhance their functionality in various ways. There are thousands of applications (apps for
short) in app stores like Google Play [15] that can be installed on devices. In addition, users have the
freedom to further develop their own. Because mobile devices are lightweight, users can easily carry
them everywhere. Naturally, these factors have sparked a widespread adoption of mobile technology for
personal and professional purposes, changing society deeply.
Despite these advances, however, there are still plenty of activities that we simply do not do resort-
ing to these devices. These particular activities would require strict assurances from mobile operating
systems (MOSes), about the behaviour (functionality) of mobile devices, in order for them to be exe-
cuted correctly. For instance, the lack of behaviour guarantees of mobile devices could be the source of
security breaches, in business meetings, where the topics discussed are often privacy sensitive. While
mobile devices can provide excellent tools to assist the participants in the meeting by providing calendar
apps, notebook apps, collaborative frameworks, e-mail clients, etc., users cannot assess whether their
devices are secure. Without knowing, a device could run malware that secretly taps the device, records
phone calls, or captures audio signal and stealthily uploads recorded conversations to a remote site.
Mobile devices’ inability to provide behavior guarantees is relevant also in other contexts. In par-
ticular, many public services impose constraints on how mobile devices can be used. For example,
in airplanes, mobile devices must be shut down or turned into flight mode; in airports’ customs areas,
mobile devices cannot be used to take photos or make phone calls; in museums, devices cannot be
used to take pictures; in movie theaters, devices should be put in silent mode to avoid disturbing the
audience, etc. However, users commonly forget to abide by these rules. Therefore, service providers
lack guarantees that peoples’ mobile devices have been properly configured.
Another good example of the need to provide mobile device behaviour guarantees, is student exam-
ination. In examination centers and universities, the evaluation of students could be a lot more efficient
and time saving for professors by allowing examinees to fill out exams through a trusted m-exam app
1
running on their devices. However, with today’s technology, examinees could easily cheat. They could
launch additional apps to obtain answers, connect to the Internet and look up Wikipedia, etc. Although
current mobile technology can support the execution of such activities, the reality is that today’s MOSes
simply do not offer the mechanisms to do so, securely. This means that currently, there is no way to
prevent students from cheating, unless resorting to human vigilance, which is still a fallible mechanism
to prevent exam cheating.
So, there is a clear need for a system capable of solving these limitations. In order to overcome
these issues, we recently proposed a new operating system primitive called trust lease [80]. This prim-
itive introduces the concept of secure operation modes for mobile devices, allowing security sensitive
applications to rely on the OS to prevent the execution of potentially dangerous operations by other
applications or system services. A good example of such a secure application scenario is the mobile
exam app which blocks the access to the Internet and prevents any pdf reader app from running during
the exam, effectively preventing students from cheating. Recently we have developed a novel platform,
called TrUbi, that uses trust leases to allow for the development of secure applications for Android de-
vices. Essentially, the use of trust leases enable application developers to leverage TrUbi’s services to
enforce these secure applications’ restrictions on users’ devices. With this approach, the specification
of the constraints an app must enforce is reduced to the lightweight task of using the trust lease model.
The idea is for application developers to define a general-use trust lease to be used in their apps, but
also to allow even non-technical users to define their own (e.g., a professor may define his own trust
lease to enforce during his exams).
1.1 Goals & Requirements
The goal of this work is to validate the effectiveness of the trust lease primitive in securing mobile
applications, by designing and implementing three use-case applications whose security guarantees are
not supported by today’s MOSes. We use them to perform a thorough evaluation of the effectiveness of
trust leases in enforcing each of these apps’ corresponding runtime constraints, through usability tests.
Additionally, and because all these apps require the negotiation of trust leases between users and
third parties (e.g., students and professors), we aim at designing a middleware layer (Strapp Middle-
ware) on top of TrUbi’s trust lease API. This middleware helps application developers in using trust leases
(i.e., negotiation and corresponding installation) transparently over network communication (sockets),
and over Near Field Communication (NFC). Note that we are interested in designing a solution with
globally applicable concepts; however, it is not a requirement to develop a system that is portable to
all mobile devices. As a matter of fact, because TrUbi is built for Android devices we intend to develop
the above mentioned apps for Android based smartphones; thus, we focus on the security mechanisms
that are available in Android. In this work we also seek to test the effects of trust leases in real-world
applications, i.e., existing applications available in today’s application markets (e.g., Google Play [15]).
Furthermore, we also plan to test the effects of trust leases on real-world spyware. Finally, we plan to
conduct an adoption study, in order to assess how open would potential users feel about the adoption
2
of these apps, as well as the underlying system.
In this work we aim at developing three secure applications:
• an e-exam application (called mExam) that allows students to answer exam questions while pre-
venting them from cheating;
• an enterprise meeting assistant application (called mMeeting) that blocks certain sensitive re-
sources (e.g., microphone or camera), in order to prevent meeting information leakage;
• a movie theatre context aware application (called mTicket) that restricts some mobile device’s
settings (e.g., volume, screen brightness), as well as the camera.
The apps mentioned above must fulfil the following requirements:
• ensure a secure behaviour even in the presence of other apps that may try to circumvent the
restrictions imposed (e.g., trusted parties that may have been compromised with malware trying to
leak meeting information);
• provide a user friendly experience to the users by avoiding the need of extra-effort when com-
pared to what happens with current apps (e.g., changing the status to vibrate, etc.);
• allow trust lease creators to enforce the execution of trusted apps only (e.g., resorting to app
package name), on the target device;
• guarantee our secure apps comply with the desired set of privileges only for the intended period
of time, after which the full control of the device returns to its owner.
1.2 Current Solutions
Nowadays, systems and applications addressing this special type of activities have low security require-
ments, as they do not enforce restrictions on devices’ resources. As we have said, present day MOSes
do not provide the necessary mechanisms to enforce the kind of restrictions needed to secure this type
of activities. Additionally, today’s MOS security extensions (e.g., ASM [57], ASF [31]), come short in
mitigating these limitations. In summary these extensions’ main limitations are:
• limited restrictions - they restrict very few little OS resources, or offer no restrictions at all, focus-
ing on other issues such as digital rights management, or app communication monitoring;
• course-grained restrictions - for instance, they block access to the whole Internet, and do not
allow for an app to access a sub-group of domains;
• system-wide restrictions - for example, they block Internet access to all applications, and are not
able to support a white-list / black-list Internet access approach;
• weak application lifecycle restrictions - while most extensions simply cannot prevent untrusted
apps from being launched, the ones that can, are incapable of stopping already running apps;
3
• low deployability - these solutions require the modification of the Android OS source code and
corresponding generation of custom system images for different devices, which makes the adop-
tion for real users very difficult.
1.3 Contributions
This work makes the following contributions:
• architectural design of the m-exam, meeting assistant and movie theatre context-aware apps as
well as their individual communication protocols and behaviour procedures;
• architectural design of the Strapp Middleware, as well as its communication protocols;
• implementation of the Strapp Middleware and corresponding protocol over network communication
(sockets), and over NFC, leveraging TrUbi’s trust lease API;
• implementation of all three apps and corresponding logic, supported on the trust lease primitive,
made available through the middleware layer;
• implementation of a webserver application, capable of providing mockup functionality (e.g. authen-
tication) for each of the three proposed apps;
• evaluation of the effects of trust leases on real-world applications / spyware;
• evaluation of the effectiveness of the developed apps in performing their desired tasks, through
user testing;
• publication of part of this work in a workshop [80], and submission to a conference.
1.4 Document Structure
The rest of this document is organized as follows. Chapter 2 describes the current application and An-
droid security extension related solutions. Chapter 3 starts by providing some background over TrUbi,
and then proceeds to the specification of the Strapp Middleware and its corresponding phases; the
chapter terminates with the description of the main architectural decisions of the three apps. Chapter 4
addresses the implementation details of the Strapp Middleware, as well as the three apps and web-
server. Chapter 5 covers the evaluation of the effects of trust leases over real-world apps and spyware,
and then presents the user test results over the effectiveness of the developed apps in performing their
desired tasks; the chapter concludes with adoption study results. Finally, Chapter 6 concludes this work,
while also presenting future work.
4
Chapter 2
Related Work
We organize this chapter in three main parts: (i) secure sensitive applications, (ii) security mechanisms,
and (iii) summary.
The first part addresses applications which are similar to those we intend to develop; for each one,
we perform an analysis of their requirements to show why existing solutions fail in providing secure ways
to achieve the tasks we are interested in (Section 2.1). The second part, security mechanisms, ad-
dresses solutions that extend Android in order to increase users’ capabilities of controlling their devices’
resources and data (Section 2.2). Finally, in the third part we summarize the more relevant aspects and
provide a critical analysis of the current solutions (Section 2.3).
2.1 Applications
As we have described, this work comprises the development of an mExam, mMeeting and mTicket
applications. In this section we provide an overview of existing applications that provide either similar
or closely related functionality. Section 2.1.1 focuses specifically on electronic exam applications, and
Section 2.1.2 covers other related applications.
2.1.1 Electronic Exams
The field of research focused on electronic exams has been around for quite a while now and yet we
have not seen a consensual system being widely adopted in schools. One of the main reasons is the
generalized idea that electronic exams will provide yet another difficulty for the professors invigilating the
exams in the already hard task of preventing students from cheating.
We now give an overview of the existing systems for electronic exams. We distinguish them based
on their nature, starting with systems developed in studies as proofs of concept, and then we move on
to commercial systems.
Academic Research Systems The first electronic exam system proposals [40] were developed for
desktop computers which targeted specific non-mobile OSes. Those exams would generally take place
5
in special purpose rooms, where the environment was controlled either by video cameras and micro-
phones, or in a more traditional fashion by invigilating professors. To support distance learning, some
systems [62] started resorting to e-monitoring schemes, to guarantee students would not cheat.
With recent improvements in mobile devices’ capabilities and resources, investigators started target-
ing these devices as platforms to execute exams. Some systems [67, 85] developed for the Android plat-
form, leverage the NFC technology to create rich scholar ecosystems, which support electronic exams.
Even so, these systems pay no attention to the enforcement of resource restrictions. Other systems
migrate the special purpose room approach from the old days by relying on institutional resources, i.e.
school provided tablets, instead of the students’ own personal devices. One of these special purpose
room systems [68] is composed by three main components: server, client and daemon. This daemon
handles the communication between the server and the exam stations (i.e., tablets), while also being
responsible for dealing with the client’s lifetime. This system appears to satisfy our resource access
restriction requirement thanks to the enforcement provided by this daemon, but considering it is a Bring-
Your-Own-Device (BYOD) incompatible system, it fails to meet our full set of requirements. Still on the
mobile based systems, some solutions target Symbian [53] and others are cross platform [69, 88] either
by using frameworks intended to produce applications whose code allow portability for various mobile
operating systems or by focusing on achieving web-browser multi-device compatibility. Other types of
systems target learning rather than examination [77] while still providing quizzes in which students are
encouraged to learn by exercising and viewing their progress and their classes’ progress as well.
Commercial Systems With the widespread of the Internet, electronic exams caught the attention of
many companies that sensed this field as an unexplored business opportunity which led to the creation
of multiple web-based systems such as TCExam [25] and VirtualX [27] that allow authoring, scheduling,
delivering and reporting exams. These systems target not only schools and universities but anyone
who is seeking a way for administering exams ranging from governmental agencies to leading corporate
entities. These systems offer basic exam mechanisms such as student enrollment, login and IP white-list
for answering exams.
With the evolution of mobile devices, commercial systems followed these new technological tenden-
cies and shifted their focus towards mobile devices as platforms to execute exams. Many companies
added value to their exam services by building mobile device platform specific apps. Custom Exam [7]
and Think Exam [26] mainly target Android and iOS on top of their web-based systems to provide users
better flexibility and user experience. On the other hand, there are cases, like Speed Exam [23], where
companies target mobile device owners by improving their web system’s graphical interface by adapting
it to the several mobile operating systems, through the browser.
A security assessment of these solutions is always difficult to achieve mostly because commercial
systems are closed and all their information on this topic mostly relies on buzzwords or abstract mech-
anisms, to describe their ways of keeping their systems and corresponding services safe. Even so, it
appears these systems rely on external mechanisms such as student behaviour monitoring to prevent
them from cheating, a type of solution that hardly solves the problem, as students may still cheat, for
6
example, by accessing the Internet.
Analysis All the academic systems we found failed to meet our requirements. Some systems fall short
by targeting non-mobile operating systems and relying on e-monitoring mechanisms incompatible with
today’s mobile devices. Some other systems fall short either by being BYOD incompatible, or by not
paying attention to device resource restrictions, or even by not providing useful descriptions regarding
security, which makes a correct security assessment impossible to achieve. As for the commercial
systems, since most of them are closed, few security information is disclosed. One would have to
assume web-based systems fail to meet our requirements, by having to rely on invigilation to prevent
student cheating, an unreliable method considering students may, for example, browse the Internet to
get exam answers. The main reason behind these systems’ inability to meet our requirements is that
browsers cannot control the underlying system on top of which they run. On the other hand, since current
mobile operating systems do not provide ways for applications to enforce system wide restrictions (e.g.,
a user can use Android’s system settings to restrict Internet access, but no app can perform those same
restrictions), mobile-based systems also fail to provide the security requirements we are after.
2.1.2 Other Related Applications
We now describe some other systems with similar security requirements to our mExam, mMeeting
and mTicket apps. A sensitive task with similar security requirements to electronic exams is the elec-
tronic vote. Although some of these systems have strong protocol security requisites, many target the
web [33, 61], which means they do not have the ability to handle malicious users’ intent or malware.
Other systems were created before the smartphone era [39], and so they were not really designed to
account for malicious applications; at that time, malware mostly targeted PCs. Some systems [33, 64]
resort to SMS to support e-voting, while others [87] develop solutions to modern day devices, but fail
to address our security concerns by offering no resource restrictions. Therefore, none of these sys-
tems offer solutions capable of enforcing resource restrictions on voters’ devices, violating our BYOD
compatibility requirement.
Throughout the years, some researchers developed context-aware systems for collaborative working.
For example, some systems provide meeting participants with a wide range of services to facilitate com-
munication and information sharing in a non-intrusive way. Some systems [44] rely on scene analysis,
while others [29, 41, 52] rely on devices to track meeting participants arrivals and departures. This last
group of systems generally uses Bluetooth to perform device tracking and offers users access control
mechanisms, so they can disclose to whom they are willing to share information with, during a meeting.
These systems have a clear focus on context-awareness. Therefore, it is comprehensible for them not
to have the same security concerns that we do (e.g. restricting participants devices’ camera and micro-
phone during meetings). However, by failing to do so, these systems fail to meet our mMeeting app’s
privacy requirements, concretely by failing to address sensitive information leakage during meetings.
Conceptually, our mTicket app shares transactional properties with electronic ticketing systems. The
difference is that instead of just buying a ticket, we want our mTicket app to not only save a digital ticket
7
but also a set of restrictions to be imposed on his phone during the movie. There are new trends in
technology that are supporting the development of new e-ticket systems. Some of them [65, 89] use
NFC, while others [50] combine this technology with QR codes and RFID tags. Nevertheless, none of
them support the restrictions (e.g., silent mode, low brightness) we want our mTicket app to enforce, in
order to prevent users’ devices from causing disturbances in a movie room. To the best of our knowledge,
there are no solutions that do so.
2.2 Mobile Security Mechanisms
In this section we describe security mechanisms developed for Android with the intention of increasing
users’ control over their smartphones’ resources as well as their personal data stored on their devices.
We address the most relevant security related systems and divide them in seven groups: (i) digital rights
management, (ii) access control mechanisms, (iii) permission refinement, (iv) application API security,
(v) privacy enhancement systems, (vi) access control hook APIs, and (vii) memory instrumentation. For
each group, we first present the motivation that led researchers to create that group’s systems. Then,
we describe the sub-problem that each system focuses on, as well as the way it handles that same
sub-problem. Finally, we summarize the group’s systems, explaining which of our requirements do they
address, as well as the reasons why they may or may not be a solution to our problem.
2.2.1 Digital Rights Management
A great concern among data owners is Digital Rights Management (DRM). These data owners want
not only to control if and how their data is copied, but also to control how that data once transferred to
another device is handled. A classic example of DRM, is the case of music distributors, who use this
kind of mechanism to prevent unauthorized copies of music files from customers’ devices.
DRM Overview In Figure 2.1, we can see the functional entities one can find in a regular DRM envi-
ronment. We now describe the most important ones:
• User - human user of DRM content, represented in the diagram by his device;
• DRM Agent - trusted entity responsible for enforcing permissions and constraints associated with
DRM Content;
• Content Issuer - entity that delivers DRM Content;
• Rights Issuer - entity that assigns permissions and constraints to DRM Content, and generates
Rights Objects;
• Rights Object - XML document expressing the permissions and constraints associated with a
piece of DRM Content.
8
Other
User’s
Device
User’s
Device
Rights
IssuerContent
Issuer
DRMAgent N
DRMAgent 1
DRMContent
DRMContent
RightsObject
RightsObject
Figure 2.1: DRM ecosystem.
In the music scenario, the music distributor would be the content issuer, and it would use a rights
issuer, so that music files (DRM content) could be accompanied by a set of usage restrictions (rights
object) when this kind of files are downloaded to customers’ devices.
In these ecosystems, users can only access content through a DRM agent. These agents are re-
sponsible for controlling access to DRM Content, and it is assumed mobile devices have several of these
agents, where each of which is responsible for handling certain types of content. Which agents are in-
stalled on a device is decided by the device’s manufacturer. The Open Mobile Alliance (OMA) DRM
standard [73] defines the format of the DRM Content delivered to the DRM Agents, and the way the
DRM Content can be transported from a Content Issuer to a DRM Agent using different transport mech-
anisms. Right objects express permissions (e.g., music files must only be played in a particular device)
and constraints (e.g., music files have a fixed lifetime, after which they become unusable) associated
with a piece of DRM Content.
Most mobile operators, mobile device manufacturers, and Android comply with the OMA DRM stan-
dard. This standard defines an API and infrastructure for authorizing devices to process content. How-
ever, the enforcement of DRM policies faces many difficulties, mostly stemming from the fact that DRM
as-is relies on device manufacturers choices over which DRM Agents are present in each device. This
dependency makes the dissemination of DRM difficult to accomplish.
Android DRM Framework Nowadays, the Android platform provides an extensible DRM framework
called Android DRM Framework [2]. It allows application developers to enable their apps to manage
rights-protected content, according to the license constraints that are associated with the type of con-
tent they wish to protect. The DRM framework supports many DRM schemes (specific mechanisms,
enforced by DRM Agents, to handle particular types of files), but as we have said, which DRM schemes
a device supports depends on the device manufacturer’s decisions.
Figure 2.2 shows Android DRM framework’s two layer architecture. The DRM Framework API ex-
poses DRM handling functionality to applications through the Android application framework and runs
9
DRM Framework API
DRM Manager
Applications
DRM Plugins
Binder
Figure 2.2: Android DRM framework’s architecture (adapted from [2]).
through the Dalvik VM for standard applications. The DRM Manager is a set of native code libraries,
which implement the DRM framework and exposes an interface for DRM plug-ins (DRM Agents) to
handle rights management and decryption for various DRM schemes.
DRM Extensions Although Android supports this standard, it does not offer users a custom mecha-
nism to protect personal data using it. That’s why MP3-based, MMS or photo content placed on Android
smartphones can be extracted and shared with impunity.
Porscha [74] is a framework created to give regular users more flexible personal data management
mechanisms. This system allows content owners to define policies specifying to whom their data is
forwarded to, which applications are allowed to handle it, and how their data is used. Additionally, the
system guarantees secure content delivery using identity-based encryption and mediates on-platform
content handling to ensure conformance with content policy through reference monitors 1 and content
proxies. It enforces access control policies and provides three guarantees: (i) complete mediation, (ii)
tamper-proofness, and (iii) verifiability within the Android middleware. By not assigning default security
policies to data, one of Porscha’s main limitations is that it cannot prevent leakage of data not tagged
with a security policy.
Analysis DRM solutions provide interesting hints to deal with the way users handle our secure ap-
plications’ logic. A particular example of this is the mExam application. DRM can constrain the way
students handle the exam statement and answers by preventing them from sharing that exam with other
colleagues. It can also limit the file’s lifetime to the duration of the exam, after which no modifications
could be done by the student. However, these systems provide no OS resource restrictions, which
makes them incapable of securing our apps.
2.2.2 Access Control Mechanisms
Access control mechanisms define the way subjects (i.e., processes, threads, etc.) access or operate
over a certain object or resource (e.g., files, system services such as IMEI or location). Since Android’s
kernel is Linux based, it follows traditional Discretionary Access Control (DAC). In Linux, DAC is based
on user ids (UIDs) and on read-write-execute permissions associated to system resources (e.g., files,
1A reference monitor is a mechanism that specifies the way the access to a certain resource is done.
10
sockets, processes). In other words, this access control mechanism allows users to make policy deci-
sions which include modifying security parameters (e.g., access grants to system resources). A good
example of DAC in Android is the way applications handle files. Applications are allowed to create and
store files in the filesystem and because these apps are owners of such files, they are free to grant file
access to whatever applications they wish.
On the other hand, most other resources in Android2 follow Mandatory Access Control (MAC) poli-
cies. MAC is better characterized by the assignment of security rules between subjects and objects.
Once a subject attempts to access an object, it triggers a policy evaluation by the kernel, which as-
sesses whether the access may be granted. One of the main ideas behind MAC, is to prohibit users
from changing access permissions. In Android, applications must specify in their manifests the permis-
sions they require at runtime. After the installation, neither applications nor users have any control over
the access policies and, therefore, the kernel will rely solely on the app’s initial specifications to decide
whether to grant or deny access to a certain resource.
Mandatory Access Control extensions Over the years several systems were created to extend An-
droid’s access control model. SEAndroid’s [84] policy specification prevents several root exploits, and
its install-time MAC allows for apps to be checked against the system’s policies to allow or deny their
installation. SEAndroid’s authors consider both Android’s application sandboxing3 and permission mod-
els suffer from severe limitations because they comply with a DAC mechanism. The authors argue this
compliance has several problems: (i) the ability of malicious or flawed apps to leak access to data,
(ii) DAC permissions are too much course-grained, and (iii) the inability to confine system daemons or
setuid programs that run with root access. In order to address these issues, the authors first ported
SELinux [66] to provide MAC at the system’s kernel layer, and then developed a simple and efficient pol-
icy specification tailored to Android’s userspace software stack and to the desired security goals. Then,
the authors modified the kernel layer to support the new MAC policy (e.g., filesystem, IPC) and created
a new middleware layer (MMAC) to extend MAC to Android’s Binder IPC.
TrustDroid [35] focuses on providing safe inter-domain (e.g., private and corporate) isolation between
applications and data. The authors extended the MAC mechanism to all the platform’s resources (e.g.,
filesystem which complied with DAC) in order to isolate different domains’ sensitive information. They
then ported TOMOYO Linux [56] to the system’s kernel to provide MAC in that layer. The system also
comprises several middleware modifications (e.g., content providers, system services, Binder IPC) to
help this access control mechanism in supporting this domain isolation.
The authors of FlaskDroid [38] created a framework to provide a flexible and effective ecosystem
on top of which, multiple security models can be instantiated, with a clear focus on fine-grained policy
specification. Since most Android security extensions addressing access control mechanisms, specifi-
cally MAC, only ensure it at the kernel or middleware layers independently, the authors built FlaskDroid2 On a related note Android’s filesystem access control currently consists of the traditional Linux DAC, which is complemented
(since Android v4.3) by SELinux based MAC.3 Application sandboxing is achieved by Android’s kernel enforcement of process isolation and DAC over resources by user
ownership. To sandbox applications, every application instance in Android is assigned a unique user identifier (UID), while systemresources are owned by either the system or root user. Applications can only access their own files, or files that are explicitlydefined as world-wide readable.
11
on top of SEAndroid, with the intention of synchronizing both layers’ access control. A good example
of the usefulness of this approach is the Internet access which can effectively be restricted at the mid-
dleware layer, but in reality since all network traffic is mediated by the kernel, it makes sense for this
layer to be the one effectively responsible for this resource’s restrictions. On the other hand, it does not
make sense for a layer to restrict access to a resource while the other is unaware those restrictions are
in place. To provide fine-grained access control to Android’s resources, FlaskDroid distributes hooks
through the middleware (e.g., content providers, system services), and through the kernel (e.g., filesys-
tem and network). FlaskDroid provides an API for those hooks to allow security model developers to
specify resource access policies. This system supports multiple stakeholders to define their own poli-
cies on a target device. It resorts to contexts, an approach similar to Saint’s [75], which we cover in
Section 2.2.4. FlaskDroid allows users to act as any other external stakeholder and define their own
security policies through a special purpose app. On the other hand, the system also supports policy
conflict resolution through a consensus approach.
Analysis Both TrustDroid and SEAndroid enforce MAC policies but fail to so with a fine granular-
ity, compromising their agility in enforcing our secure apps’ resource restrictions. On the other hand,
FlaskDroid provides a granularity better suited for our needs, but unfortunately, it does not offer applica-
tion lifecycle restrictions, (e.g., we cannot prevent a helper application from running during an exam).
2.2.3 Permission Refinement
One of the biggest limitations associated with the Android permission mechanism is its course-granularity.
This problem translates in users’ inability to constrain applications’ access to resources at runtime. At
install time, users are presented with a list of permissions an application specifies in its manifest file,
and are forced into an all-or-nothing decision, either granting all permissions forever or quitting the in-
stallation. This inflexibility allows for apps to explore the device’s resources whenever they wish without
users’ knowledge, possibly with malicious intent.
Manual Permission Revocation Some extensions were created to allow users to manually revoke
application access permits over certain resources. APEX [72] refines Android’s permission model by
allowing users to specify which permissions should be assigned to each app both at install and runtime.
It also allows the definition of additional constraints over those permissions, e.g., limit the number of
text messages to be sent per day by an app. Permission Tracker [63] allows users to be informed on
how the permissions they grant to applications at install time are used at runtime. It offers users the
possibility to revoke permissions at runtime, and to be notified of every permission-of-interest access
so they can decide whether to grant or deny that access based on their preferences. Compac [91] also
tries to restrain application access to certain permissions, but does so at a different granularity, i.e., it
considers applications as groups of components and tries to prevent component privilege escalation.
A classic example is a game that requests access to the camera and to the Internet and profits from
displaying in-game adds. Considering that all components of the application have access to the same
12
permissions, the ad component has access to the camera as well, which doesn’t make sense and can
even lead this component to escalate its privileges by leaking video.
With the release of Android 4.3 Jelly Bean came an unofficial permission manager called App Ops [6].
App Ops allows users to check which permissions a certain app had access to, and enabled them
to revoke these permissions. However, because most apps were not prepared to handle permission
revocation, Google dropped this functionality after the release of Android 4.4 KitKat.
Although this approach was dropped by Google, a smaller operating system company understood the
usefulness of such a service [9]. CyanogenMod [8] provides a third-party Android remix that includes
the App Ops functionality. CyanogenMod circumvented the problem of having a disabled permission
breaking an app with two decisions. First, they only allow users to control a subset of permissions
which have a more limited impact on apps’ functionality, such as contact list access and location service
access. Second, after changing a certain app’s permission, the system embeds a persistent notification
in the app remembering the user that a feature has been blocked.
Context-Aware Permission Handling Extensions Instead of manually changing permissions, a more
interesting mechanism would be for these permissions to change based on contextual information.
CRePE’s [42] goal is to enable trusted third parties to enforce security policies on another user’s de-
vice. In order to do so, the system relies on a context-aware approach to ensure, for example, that a
company can control its employees’ mobile devices when they are inside the company’s building, but
have no enforcement privileges once employees leave the premises. CRePE extends Android’s permis-
sion mechanism to enforce their security model, mainly by creating their own permission checker which
complies with their finer-grained permissions (e.g., restricting Internet access to a particular group of
apps). CRePE detects contexts primarily focusing on time and location, which allows the definition of
context-aware security policies by the stakeholders. There is a one-to-one relationship between policies
and contexts and each of these relationships has a single owner. Users have a special purpose app
for handling their own policies while external entities can do it via Bluetooth, WiFi or SMS. Entity au-
thentication is done through phone numbers as the authors assume the network provider to be trusted.
CRePE handles policy conflicts according to a priority system, in which external entities have prece-
dence over user policies. MOSES [79] is a system that enforces domain isolation through the concept
of security profiles. Figure 2.3 shows this system’s architecture. As we can see, the system provides a
clear domain isolation. In this case, the system separates personal from professional domains, but can
support several other scenarios. Using a context-aware approach similar to CRePe’s, MOSES switches
security profiles based on pre-established conditions, namely GPS coordinates and time. These aware-
ness is the responsibility of the Context Monitoring Module. When switching profiles, MOSES terminates
and prevents the execution of applications not allowed to run in this now enforced profile. Additionally,
MOSES leverages TaintDroid (covered in Section 2.2.5) in order to clearly determine the profile that
owns a certain piece of data. Through this mechanism, MOSES prevents apps from one profile to ac-
cess data belonging to another, e.g., prevents a work supervisor to access social media contacts on a
user’s device. This prevention is the responsibility of the Policy Enforcement Module.
13
App1
Data
Applications
Android Middleware
Linux Kernel
MOSESConfiguration
Manager
MOSES Hypervisor
Policy EnforcementModule
Context MonitoringModule
App2
SecurityProfiles
App3
DataApp5
SecurityProfiles
App4 App3
DataApp5
SecurityProfiles
App4
Security Profile:
WorkSecurity Profile:
PrivateSecurity Profile:
Default
MOSES
Figure 2.3: MOSES architecture (adapted from [79]).
Analysis None of these platform extensions, offers an application developer all the security guarantees
required for our desired applications. As the name implies, the manual permission revocation extensions
either offer no mechanisms for the definition of complex policies, or forces users to go through too much
work to do so. Context-aware permission handling extensions are the type of solutions closer to provide
a solution to our problem. However, by offering a priority based restriction system, CRePE potentially
allows for third parties to define policies that cannot be revoked by the user, which means users might
have no control over their devices if needed. In addition, with CRePE, a user has no way to deny the
enforcement of a third party policy, and these entities may even control the device remotely, meaning
that a company may send policies to a user’s mobile device while he’s at home. On the other hand,
MOSES suffers from having a very static approach as its security policies are made to be systematic,
(e.g. policies can respect normal work routines, but may fail to adapt to a meeting where a host, which
as no enterprise infrastructure, may define his own policies). Additionally, MOSES may suffer from the
same device control issues that affects CRePe, i.e, a user may lose control of his device to a third party.
2.2.4 Application Communication Monitoring
We now move to another important group of security extensions, namely the ones which monitor the
way applications interact on Android, focusing on vulnerabilities explored by malicious developers. We
start by addressing a particular sub-problem of privilege escalation called the confused deputy attack,
which can be seen in Figure 2.4 (a). This attack basically consists of unprivileged applications taking
advantage of other applications’ publicly accessible APIs to perform malicious actions. In this case,
app1 did not had permission to access the network, but leveraged a publicly accessible API from app2,
to do so. Then, we move to another type of problem called collusion attack, which can be seen in
Figure 2.4 (b). Essentially, even though an app might not have permission to perform an operation,
because Android’s permission system is based on UIDs, this app might still be able to perform the
14
Network
App1
App2
No Permission
(a)
Network
App1
App2
(b)
No Permission
Same DeveloperSandbox
Figure 2.4: Android application communication attacks (confused deputy attack (a), collusion attack (b)).
operation, if there exists another app belonging to the same developer, installed on the user’s device,
with the permission to perform said operation. In the case of Figure 2.4 (b), even though app1 could not
directly access the network, it still did so, because app2, which belonged to the same developer, was
also installed on the user’s device, and had the Internet permission.
Confused Deputy Attacks Confused deputy attacks usually happen because of application develop-
ment negligence. A classic example is an app that exposes a service on its API that allows another
app to receive photos directly from the device’s camera. This second app does not need to specify a
camera permission to have access to that sensor. If this application happens to be malicious and holds
an Internet permission, sensitive data leakage could take place without the user’s knowledge or consent,
and all because an app’s API was not properly protected.
Saint’s [75] policy enforcement happens both at install and runtime, and is based on application
inter-communication. Saint’s creators tried to address three main questions: (i) applications have limited
ability to control to whom permissions for accessing their interfaces are granted; (ii) Android provides
only rudimentary facilities for applications to control how their interfaces are used by other applications;
and (iii) applications have limited means of selecting, at runtime, which applications’ interfaces they use.
To mitigate confused deputy attacks, Saint allows developers to assign appropriate security policies
on their APIs which basically specify which apps can access them. The identity of the caller apps is
authenticated by the modified IPC mechanism. To support new apps and to revoke current restrictions
on apps, the developer must modify the app’s manifest and re-install it.
Other systems control apps’ communication by extending Android’s Binder IPC mechanism, which
is the main form of application inter-communication in Android. QUIRE’s [45] extensions made every
message exchanged between apps contain the full call chain context so that the source of each request
and corresponding data can be assessed. When source applications have not been assigned the corre-
sponding permission to a request, their access is denied. This system provides these guarantees locally,
but also remotely. QUIRE accomplishes this with a modified RPC mechanism which adds a symmetric
key provided by the kernel to each message, so that the source application can be validated by remote
parties. IPC Inspection [49] uses the messages exchanged between apps to assess their permissions
and to automatically reduce the target application’s privileges. The target app’s privileges are reduced to
the intersection of its original permissions with the message source app’s permissions, balancing each
15
others privileges and preventing possible abuses.
Collusion Attacks Another important privilege escalation problem worth mentioning is collusion at-
tacks. As the name suggests it usually stems from groups of colluding malicious apps. For instance, if
a malware developer creates a game which specifies a microphone grant permission, he can persuade
a victim user to install both the game and a malicious add-on app. If this second app holds an Internet
permission, both apps can collude to leak sensitive audio data.
The authors of XManDroid [34] extended the Android’s permission model in order to support policies
that could constrain the way apps interact with each other. The system’s main contribution, however,
is its graph mechanism that is filled at runtime with a representation of the apps’ interactions. This
graph is then used to regulate app inter-communication, based on the system’s policies and also on
the possible communication links established previously between apps. This mechanism is then used
to prevent data leakage or other types of collusion attacks. An extension to XManDroid [36] aimed at
supporting a wider range of communication channels (e.g., files and Internet sockets) through which
privilege escalation attacks could occur. They also created a library allowing the enhanced kernel layer
to access the middleware layer in order to fetch access control decisions in case local information did
not provide enough context to perform a correct access control evaluation.
Analysis While all these works provide a greater insight to application inter-communication issues
focusing on verifying the existence and mitigating some of those vulnerabilities, they provide no support
for the development of secure apps. This is why these systems do not help an application developer to
follow the security requirements we seek.
2.2.5 Privacy Enhancement Systems
Another major concern among the Android research community is the way applications handle users’
data, particularly in situations where malicious parties can leak information from mobile devices.
Data Access Control Extensions To prevent untrusted applications’ from accessing high level data
(see Section 2.2.3), some extensions [32, 95] allow users to manually specify application access rights
over the system services providing access to such data. These systems offer data shadowing4 to unau-
thorized apps accessing it. myTunes [37] protects the OS services providing that data, as well as Android
data structures (e.g., contact list, file lists), by defining semantic links. These links establish relationships
between different Content Providers and OS services which govern access over that same information,
and are essential in guaranteeing that user access control decisions over certain information providers
are also reflected in other linked providers. For instance, in Android, an app with no permissions to
access the contact list, may still access some contacts if it has permissions to access the device’s text
messages. Considering nowadays a user is many times forced to use a group of applications to perform
4Data shadow is the return of empty or incorrect information instead of the intended data.
16
Trusted Application
Binder Kernel Module
Virtual Taint MapDalvik VMInterpreter
Taint Source
Binder IPC Library Binder Hook
Untrusted Application
Virtual Taint Map Dalvik VMInterpreter
Binder IPC LibraryBinder Hook
Taint SourceTrusted Library
(1)
(2) (3)
(4)
(5)
(6)
(7) (9)
(8)
Inte
rpre
ted
Co
de
Use
rsp
ace
Ker
nel
Figure 2.5: TaintDroid architecture (adapted from [46]).
a high level task instead of resorting to a single app, some systems [71] allow developers to protect data
which is used throughout the stages of strictly fixed workflow chains.
MobileIFC [83] provides contextual policies, based on location and time, that offer users’ and high
level data protection. The system’s creators follow an idea similar to Compac’s (Section 2.2.3), where
an app is also seen as a group of chunks, but in this case they do so, in order to create a one-to-one
relationship between those chunks and corresponding data they have access to, and the third parties
to which they may disclose that same data. However, the system was implemented for PhoneGap [21]
so it targets primarily web technologies, which means its Android support is not as strong as the rest
of the systems covered in this section. IdentiDroid [82] focuses on privacy protection, by addressing
the lack of mechanisms to prevent applications from identifying the user and his respective device, and
then leak that information to a third party. The system offers users an anonymous mobile device state
that provides data shadowing (e.g., return a default location instead of actual device’s location) and
permission revocation techniques that disable apps’ abilities to use system services (e.g. IMEI, location)
to identify the user and corresponding device. IdentiDroid allows users to defend themselves either by
specifying the set of resources an app has access to (similar approach to the other systems we described
so far), or by restricting which applications have access to a certain resource. Additionally the system
offers two other mechanisms (under the anonymous state): (i) application access restrictions to their
custom directories, preventing them from using their previously collected data to identify the device and
potentially leak that data, and (ii) application message filtering, preventing them from passing information
capable of identifying the user to other apps.
Dynamic Taint Analysis Another approach to prevent data leakage is dynamic taint analysis. Taint-
Droid [46] is a sophisticated framework which detects unauthorized leakage of sensitive data. Figure 2.5
shows the system’s architecture. TaintDroid exploits dynamic taint analysis in order to label privately de-
clared data with a taint mark (steps 1, 2 and 3 from the figure), audit on track tainted data as it propagates
17
through the system (steps 4, 5, 6, and 7), and alerting the user (step 9) if tainted data aims to leave the
system (step 8) through a taint sink (e.g., network interface). In order to control data flows, the authors
modified Android’s Dalvik VM environment, and Binder IPC library to track information when within a
process, and when traveling from different applications’ processes. The system suffers, however, from
some limitations: (i) the low number of information sources it can track (32 sources covering mainly sen-
sors such as camera or microphone or high level info5), (ii) the existence of false negatives, which may
lead to access control circumvention, (iii) more performance overheads than may be tolerable for some
environments, and (iv) incapability of detecting attacks that exploit covert channels to leak sensitive
information.
TaintDroid’s limitations from a security system’s standpoint did not stop many researchers to look at
the system as a potential tool on top of which other security models could be built. Kynoid [81] extends
TaintDroid to provide a finer-grained access control to data, extending its mechanism to support a bigger
number of information sources. The system also provides users a way to establish data access rights
on data items and allows them to specify a list of acceptable IP destinations for each item. Pebbles [86]
focus on the definition of Logical Data Objects (LDOs). These objects represent abstractions of user’s
valuable information (e.g., email is composed of body and attachments), and are used to ensure data
integrity (e.g., when a user deletes an email, no traces of the body or attachments should be left behind).
The system uses TaintDroid to identify and control these LDOs’ flows in the system. AppFence [58]
extends TaintDroid to provide a leakage blocking mechanism that prevents data the user made available
to the application for on-device use only, to be transmitted over the network, and allows high level info to
be substituted by shadowed data.
Analysis All these systems aim at protecting users’ privacy, either by protecting system services,
content providers, or other sources of private information. These systems’ main concern is to detect
and, in most cases, avoid data leakage. While some of them do present the novelty of having a single
app controlling resources’ accesses system wide, those apps are nothing but their security model’s UI,
and not the product of a framework providing developers resource restriction functionality. Hence, we
can conclude these systems do not accomplish our goals.
2.2.6 Access Control Hook APIs
With the emergence of Android, its open source nature and popularity, motivated several security studies
that identified multiple limitations in the operating system and prompted the development of solutions to
such shortcomings resulting in many of the systems described so far. While some systems do not
require modifications to Android’s middleware and Linux-based kernel (e.g., inline reference monitors,
covered in Section 2.2.7), most security extensions require modifying and adding components to those
layers in order to implement specialized security models.
With this in mind recent work [31, 57] has been developed to facilitate security model developers’
work. These contributions comprise frameworks allowing these developers to create their security mod-5By high level info we mean private data such as the device’s IMEI or location.
18
els as ordinary apps and benefit from a rich callback system that can notify those security enforcement
apps of accesses or requests to some of the apps’ resources of interest. Figure 2.6 shows a general
access control hook API architecture. As we can see, these APIs comprise a set of hooks distributed to
the kernel, as well as the middleware layer. In this last layer, these hooks mainly target the Activity Man-
ager Service, to control the lifecycle of applications, OS content providers, to control access to users’
and apps’ data, and OS system services, to control access to device resources (e.g., camera, location).
Whenever a secure app registers for a hook, and that hook gets activated, a callback is triggered from
that hook to the Hook API Module, which is then forwarded to these apps, so that they can decide
whether the operation that triggered the activation of the hook may or may not proceed. By giving de-
velopers freedom to choose the resources they want to manage, these programmable APIs allow those
apps and corresponding security models to be as diverse as the number and combinations of Android
components’ can allow one to be. Considering that Android’s kernel is Linux-based, these solutions
take advantage of the already existing Linux Security Module [92] framework, which is conceptually very
similar to these approaches in handling kernel level hooks, such as network and filesystem hooks.
Android Security Modules (ASM) [57] and Android Security Framework (ASF) [31] are the two most
renown frameworks currently available. While ASF provides a way for security developers to create
reference monitors to be embedded on applications as part of the programmable API, it suffers from
limitations ASM does not. ASM seeks to ensure existing security guarantees such as preserving sand-
boxing integrity. This is accomplished by following restrictive enforcement, i.e. ASM’s reference monitor
interface hooks only provide more restrictions than Android platform currently enforces, e.g., fewer per-
missions or less file system access. On the other hand, ASF assumes the module writer is completely
trusted, e.g., can load kernel modules, which violates ASM’s principle. Both ASM and ASF have proven
to be effective in enforcing different sets of MAC models, which is a key requirement in securing our
apps. Examples of this effectiveness is their sucessfull instantiation of MAC supporting systems such
as MockDroid, XManDroid and FlaskDroid.
Analysis Although these frameworks do provide building blocks to solve our problem, particularly by
allowing flexible resource restrictions (e.g., system-wide and at the same time app-specific restrictions),
they do not control all the resources we need. On the other hand, they still lack mechanisms that can
safely handle application lifecycle restrictions, i.e., they prevent apps from being launched but they do
not provide mechanisms to kill or freeze already running applications.
2.2.7 Memory Instrumentation
The majority of the Android security extensions covered so far, rely on modification of the Android OS
source code. This modification is then followed by the creation of flashable modified operating system
images, which are then installed in mobile devices but for testing purposes only. The deployability of
these solutions to real users’ devices is far from being a reality, because generally these systems are
developed and tested on very few little different models (usually just one). This means that their de-
ployment to real users would always face compatibility issues with different Android and mobile device
19
Hook API LSM Module
Hook API Module
Android Framework
Linux Kernel
Applications
Android Framework
Access hooks
Access control callback
Hook1
OS
Content Providers
… HookN Hook1
OS
System Services
… HookNHook1
Activity
Manager Service
… HookN
SApp1 SAppN
Secure Apps
… App1 AppN
Regular Apps
…
Figure 2.6: General access hook API architecture (adapted from [57]).
versions. Additionally, the adoption of these systems is also hindered by the requirement of having to in-
stall flashable OS images in users devices. We now cover different memory instrumentation techniques.
Static Memory Instrumentation Instead of modifying Android’s core to provide enhanced application
desired resource access through the use of the platform’s reference monitors (see Section 2.2.2), a
good alternative is to rely on inline reference monitors (IRM) instead, which are a form of static memory
instrumentation. The basic idea is to rewrite an app in order to embed a reference monitor in its structure,
yielding a “self-monitoring” app. By having full access to the internal state of the app, a richer contextual
information is available and other kinds of security enforcements are possible (e.g., to enforce the use of
HTTPS over HTTP). These systems usually support high level info protection through data shadowing
(see Section 2.2.5), and the possibility of users to change policy decisions.
Among the most representative IRM-based systems, we find Aurasium [93]. This system supports
these rewriting services through the cloud, and it also makes sure that user decisions regarding appli-
cation’s access to a resource is kept in memory, so that the user is not frequently asked for the same
decision again. It also provides IP white/black-listing so it can restrict the domains an app can access,
and also detects runtime privilege escalation (e.g., execution of the su command to gain root access).
AppGuard [30], allows the repackaging process to execute on the phone and also allow for already in-
stalled apps to be rewritten and reinstalled. SIF [55] focuses on providing expressive abstractions that
can ease the process of expressing the applications parts to be instrumented in a compact and precise
way. This system also addresses instrumentation efficiency, and provides a novel path inspection mech-
anism that provides feedback on users instrumentation specification overhead. Dr. Android and Mr.
Hide [60] is a two component system where Dr Android is responsible for the rewriting of apps, providing
them with a finer-grained permission model (e.g., InternetURL(d) instead of Internet permission, where
d specifies a domain). During the app rewriting process, Dr. Android re-engineers apps so that instead
20
of accessing resources through Android’s API, they do so through Mr. Hide. This component runs on
a separate process, and mediates apps’ resource accesses with the underlying system, ensuring apps’
compliance with the system’s fine-grained permission model. APClib and Redexer [78] is a system very
similar to Dr. Android and Mr. Hide with the only difference that instead of using a single resource access
process monitor (Mr. Hide), this system uses a groups of processes responsible for different resources,
which together compose APClib. Complementing these IRM-based systems, recent work [54] has tar-
geted the evaluation of the effectiveness of Android bytecode rewriting mechanisms, focusing on Java
class reloading, OS Service native code, and the use of alternative RPC stubs to access those services.
IRMs are an interesting group of systems that rely on application re-engineering with the intent of
adapting apps to certain security models. This re-engineering process can be seen as static memory
instrumentation, in the sense that apps are modified, at install time, to conform with those models, before
running for the first time. Another kind of mechanism that can be seen as static memory instrumentation
is the Android update. Android is an open-source OS that grew throughout times thanks to its developer
and user community. It is this community that frequently finds and reports bugs, which are then fixed
by the Android development team. For this reason, Google frequently publishes these bugfixes as well
as additional enhancements for Android. Instead of forcing users to attach a computer to their mobile
devices in order to update them, Android provides an over-the-air (OTA) update mechanism, that allows
for the quick distribution of updates through the network. An interesting idea for the adoption of these
systems would be for Google to allow users to install them, through this OTA mechanism, in a non
automatic way, i.e., users would be allowed to install and test these systems at their own risk. However,
this approach would be cumbersome and even dangerous for Google. Cumbersome because it would
force them to allocate manpower to at least understand what these systems did, in order to assess
whether they violated users’ rights. And dangerous because even if they did, compatibility issues could
end up breaking users’ devices, which would then lead to users blaming Google for it. Overall, on one
hand, Google has enough reasons not to help distributing these systems, and on the other hand, system
developers have absolutely no say in the matter, which means that they will continue to provide access
to their systems code and flashable OS images through their project specific webpages.
Dynamic Memory Instrumentation Another interesting mechanism to enforce a security model is to
use dynamic rather than static memory instrumentation. While static instrumentation, changes already-
compiled bytecode, dynamic instrumentation patches running processes. PatchDroid [70], is a system
that uses dynamic instrumentation to provide poorly-supported devices the bugfixes and enhancements
that Google publishes. Because of Android’s open-sourceness, device manufactures are free to use
whatever Android version they wish on their devices’ models. Additionally, because Android’s OTA
mechanism solely targets devices sold directed by Google, the application of the bugfixes published
for Android for other devices relies on the decisions from their corresponding manufacturers. The speed
of the application of these bugfixes varies from manufacturer to manufacturer. Still, this speed is also
influenced by mobile operators decisions as well, because they too personalize the OS, so they too
need to test these bugfixes for the different device models before providing these updates to users.
21
Considering that the average model support from device manufacturers is generally limited to one to two
years, some devices never actually get the bugfixes, which leads to a lot of devices running in the wild
with out-of-date, and vulnerable OSes. To solve this issue, PatchDroid offers the possibility for security
analysts to write vulnerability patches, which are then sent to users’ devices and used, by PatchDroid, to
patch bugs in both native processes, and Dalvik VM-based processes. PatchDroid features an in-device
patch-monitor, and a cloud-based patch repository, which detect patch compatibility issues, and study
alternative patches for devices’ vulnerabilities respectively. Deepdroid [90], is a system that relies on
dynamic memory instrumentation to enforce enterprise security policies. By patching several system
services, and tracing system calls, Deepdroid is capable of enforcing fine-grained context-aware poli-
cies, which are ideal for enterprice security. On the other hand, since these system services have stable
process structures, PatchDroid provides high portability for several Android versions.
Analysis On one hand, IRM systems are easy-to-deploy solutions that still cannot offer system-wide
resource and application lifecycle restrictions. On the other hand, the adoption of more robust systems
that enforce new security models is difficult in Android, because these systems usually target specific
devices, and so they provide no compatibility assurances to other models. Google could help in the
adoption of these systems if it allowed users to use its OTA mechanism to install and test these systems.
However, by doing so, Google would expose itself to new problems, so it opts not to. System developers
are then forced to publicise their systems through their projects’ webpages, which obviously have low
visibility for real users. The adoption of dynamic memory instrumentation, to enforce security models
(DeepDroid), or to fix OS vulnerabilities (PatchDroid), can be a good solution. Still, in order for these
systems to patch running processes they need to aquire root access, which means they only work
on already rooted phones, something we do not want. Overall these systems do not help application
developers in building the kind of applications we propose, since all their work resides in the middleware
layer, not in the application layer. DeepDroid, the closest case to ours, offers fine-grained but static
restrictions, determined by an enterprise administrator. We, on the other hand, are more interested in
providing dynamic restrictions, without having to rely on predefined trusted administrators.
2.3 Summary
Next we briefly review the systems we described in Chapter 2. Table 2.1 provides a matching between
these systems and the restrictions they are capable of enforcing on mobile devices, as well as these
systems’ ease-of-deployment. This matching helps us in realizing why some systems are ineffective in
securing our applications, and why other systems are better equipped to serve as base for our work.
In Section 2.1 we have described systems covering the e-exam, e-meeting, and e-cinema functionali-
ties. We saw that both academic and commercial e-exam systems fail in providing fundamental security
guarantees such as anti-cheating mechanisms, and that they continue to rely heavily on classic tech-
niques, e.g., invigilating professors. We described some e-voting systems, mainly due to the similarity
of their security requirements to e-exams, and we found that despite offering safe communication, they
22
Systems / RestrictionsDevice
ResourceRestrictions
Device ResourceRestrictions’Granularity
Device ResourceRestrictions’
Scope
AppLifecycle
RestrictionsDeployability
Applications
e-exam Unsupported – – Unsupported Easy
e-voting Unsupported – – Unsupported Easy
e-meeting Unsupported – – Unsupported Easy
e-ticket Unsupported – – Unsupported Easy
OS Extensions
DRM Mechanisms Unsupported – – Unsupported Difficult
Access Control Mechanisms Limited Coarse-Grained App-Specific Unsupported Difficult
Permission Refinement Supported Fine-Grained App-Specific Unsupported Difficult
App Communication Monitoring Unsupported – – Unsupported Difficult
Privacy Enhancement Limited Coarse-Grained System-Wide Unsupported Difficult
Access Control Hook APIs Supportable Fine-Grained Flexible Limited Difficult
Memory Instrumentation Supportable Fine-Grained Flexible Supportable Manageable
Table 2.1: Matching between the related systems and restriction support.
do not offer the possibility to apply the restrictions we need. We addressed some e-meeting systems,
and concluded they mostly focus on context-aware solutions and have more lenient concerns about se-
curity than what we have. Since we did not find any systems capable of covering our e-cinema app’s
purposes, we researched e-ticketing systems in order to study their transactional nature, which relates
to our app’s underlying essence, and found they do not enforce the restrictions we need.
In short, and as we can easily see in Table 2.1, none of the systems on the application domain
could enforce the restrictions we want. Still, because these solutions run in the application domain, they
are easily deployable to users’ devices. Considering we are targeting the Android platform, and that
the OS as-is does not offer users or developers the ability to enforce these restrictions, we analysed
in Section 2.2, current Android security extensions. This analysis’ intention was to assess whether we
could leverage these extensions in order to enforce the constraints we need for our scenarios.
As we can see from Table 2.1, DRM mechanisms and application communication monitoring
systems simply do not support the enforcement of restrictions on device resources (e.g., restrict Internet
access), which renders them ineffective in helping us in securing our applications. Most access control
mechanisms we described have limited resource restriction support (i.e., support very little resources),
and on the other hand, the granularity of those restrictions is very coarse (e.g., prevent complete Internet
access, and not a sub group of domains). Yet, some of these systems (FlaskDroid) offer fine-grained
restrictions. Still, they fall short by failing to offer application lifecycle restrictions (e.g., cannot prevent
untrusted applications from running). Privacy enhancement systems also fail to secure our scenarios
because they also suffer from offering limited and course-grained device resource support. The main
reason for this lack of support is these systems’ main focus on data privacy issues. Most permission
refinement systems, do provide fine-grained access control, but they rely on very static approaches.
In these systems, users either manually revoke permissions, or edit static system default policies, which
does not conform with the dynamic resource enforcement our apps request. There are also systems
allowing fine-grained and context based policy enforcement. However, these systems either allow for
23
third parties to either completely override users’ preferences (i.e., users may not have control over the
restrictions enforced on their devices), or they rely on static system wide security profiles (i.e, if a user is
at work, the work profile applies, if the user is at home, the home profile applies). We on the other hand,
require support for dynamic policies, which are not only limited to geographical / temporal restrictions,
but also to interactions between users and third party entities, which can happen anytime and anywhere.
Additionally, we described the two most prominent access control hook API frameworks, available
today for the Android platform. They do provide developers with building blocks for what we want,
particularly by allowing flexible resource restrictions (e.g., system-wide and at the same time app-specific
restrictions), which can be then used in creating the dynamic scenarios we are interested in. However,
not only do these frameworks force application developers to put in some more extra work for their apps
to enforce the restrictions they want, they also fail by offering limited application lifecycle restrictions.
While these frameworks prevent an untrusted app from being launched, they do not allow for one of our
three apps to stop an already running untrusted application. On the other hand, these systems, like the
rest of the OS extension systems, are difficult to deploy to users’ devices.
We concluded the section by presenting memory instrumentations systems. We first introduced
IRMs, and showed that they have limited capabilities in enforcing system-wide resource and application
lifecycle restrictions. We explained how most of these other OS extensions are developed and deployed,
and explained how Google could help these systems’ creators in reaching bigger audiences. Addition-
ally, we presented dynamic memory instrumentation systems, which as we can see from Table 2.1, have
the ability to support flexible and fine-grained restrictions similarly to hook APIs systems. However, these
systems are also able to enforce complete application lifecycle restrictions (i.e., they can stop the execu-
tion of already running untrusted apps). From an application developer’s perspective, the only problem
of these systems is that the work surrounding these solutions involves modifying OS-level processes,
which may not be trivial for the average developer. Another limitation of these solutions is the need to
root users devices, something we simply do not want to do.
In conclusion, despite offering solutions for some of our work’s sub-problems, none of the described
related work, whether on the application domain, or the extensions to Android security, provide a direct
solution for the development of apps secure and flexible enough to address our requirements.
24
Chapter 3
Architecture
In this chapter, we present an overview on this work’s architectural landscape. We start by giving some
background on the trust lease primitive, as well as on the new mobile operation mode paradigm we use
in developing our proposed applications. Then, we describe the Android-based system that provides
the trust lease mechanism, on top of which we develop those applications. Next, we present the Strapp
Middleware, to help the transparent negotiation and consequent enforcement of trust leases. We then
describe the architecture and workflows of mExam, mMeeting and mTicket applications separately;
given that employing a one-size-fits-all solution to each of these apps is infeasible, we conclude by
presenting for each one, a basic and advanced use case scenario.
As we have said in Chapter 1, the applications proposed are: (i) mExam, an exam application that
allows students to answer exam questions while preventing them from cheating, (ii) mMeeting, an enter-
prise meeting assistant application that blocks certain sensitive resources (e.g., microphone, camera),
in order to prevent meeting information leakage, and (iii) mTicket, a movie theatre context aware appli-
cation that restricts mobile devices’ resources (e.g., volume, screen brightness) to prevent disturbances.
3.1 Background
The trust lease primitive is an OS mechanism we recently proposed [80], that enables to restrict the
access to several device resources, as well as the restriction of several other device functionalities (e.g.,
preventing untrusted apps from running). This primitive enforces a new mobile computing paradigm that
enables two entities, a mobile device user and a third party (e.g., a server), to negotiate restrictions
over the user’s device, and the conditions under which those restrictions hold. In the remainder of this
section, we first present the new operation mode paradigm, and then present TrUbi, that implements the
new paradigm, capable of providing the trust lease primitive to Android applications. We conclude by
showing the overall workflow of our use case apps, called strapps, for short.
25
3.1.1 Operation Mode Paradigm
The concept of trust leases spawned a new mobile device paradigm that introduced the concept of
mobile operation mode, more specifically the unrestricted and restricted modes. This paradigm enforces
the negotiation of trust leases, which ultimately lead to the transition of users devices from unrestricted
to restricted mode, effectively constraining some of the users’ device resources and / or functionalities.
The restricted mode is a novel operation mode for mobile devices that enables a multi-purpose
commodity mobile device to be turned into a special-purpose device, restricting its functionality to a
well-defined set of tasks for a limited amount of time. This operation model provides a remote party the
guarantees that those restrictions are in place.
In order for remote party sides to control users’ device states, there needs to be a way to negotiate
which and for how long certain restrictions (e.g., Internet access restriction on students’ phones) have
to be applied on users’ devices. This negotiation is essential in guaranteeing the correct behaviour of
certain application-specific activities. This is supported by trust leases. A trust lease is an abstraction
that captures the process of specializing a device, by transitioning it from unrestricted to restricted mode,
and granting a remote party behaviour guarantees from that device. Basically the user (known as lessor)
issues a trust lease on behalf of the remote party (known as lessee) in order to define a contract where
both parties agree on:
• a set of restrictions to apply to the lessor’s device (e.g., limit the access to the Internet, and the
execution of other applications, during an exam);
• a set of conditions that regulate the extent of the specialization (e.g., limit the lease to the maximum
duration of the exam, or up until the completion of the exam by the student).
3.1.2 Restricted Mode Threat Model
The restricted mode is essential to the correct execution of the security sensitive scenarios we propose.
On one hand, this mobile operation mode paradigm assumes that all lessors (users) are untrusted,
as they can try to change device configurations or execute applications that can corrupt the secure
execution of these applications’ tasks. It is also assumed that lessors (users) may install malicious
applications that try to circumvent the restricted mode’s restrictions, in order to benefit lessors in these
scenarios. So, all lessor-side third party apps are considered untrusted except the ones specifically
specified by lessees in leases’ whitelists. Additionally, the lessor-side’s kernel and middleware services
are part of the trusted computing base (TCB), and lessees’ devices are also considered to be trusted.
Note, that this paradigm does not address the side-channels associated to the use of a second device.
3.1.3 The TrUbi System
TrUbi is a system that supports the recently proposed trust lease primitive [80], for Android devices.
Figure 3.1 shows TrUbi’s architecture. This system extends both Android’s kernel and middleware level
resource access control mechanisms (e.g., access to Internet, IMEI, location). These extensions are
26
arestrapp 1Regular
Apps
Application Layer
OS Middleware
TrUbi Middleware
strapp N…
OS Kernel
TrUbi Kernel
Mobile Device Hardware
Figure 3.1: TrUbi architecture (strapps represented in light grey).
represented in the figure by the TrUbi Middleware and TrUbi Kernel components. TrUbi also provides
features that can better accommodate the application lifecycle requirements that both the mExam and
mMeeting strapps require (e.g., prevent unauthorized apps from running). In order to control device
resources, system services, and application lifecycles, TrUbi essentially monitors these components’
access / execution decisions, and each time the OS performs some operation of interest to TrUbi, a
callback is triggered in TrUbi, which it then uses to decide whether that operation may or may not proceed
accordingly with the lease currently active. As we can see in the figure, strapps, represented in light grey
in the application layer, run on top of the TrUbi Middleware component. The interactions between these
strapps and TrUbi are performed through the API provided by the TrUbi middleware. This API essentially
offers four trust lease handling primitives:
• startlease - used on lessors’ side to signal TrUbi to start the enforcement of a lease;
• stoplease - used on lessors’ side to signal TrUbi to stop the enforcement of a lease;
• quote - used on lessors’ side to request TrUbi to compute the hash of the lease being enforced;
• verifylease - used on lessees’ side to compare the hash calculated on lessors’ side with the one
expected, generated locally.
Table 3.1 shows the restrictions that TrUbi and its trust lease primitive provides to strapp developers.
These restrictions are divided in (1) application, (2) resource, and (3) setting constraints. Application
restrictions prevent the execution of certain applications. Resource restrictions prevent access to the
network and camera, as well as to the ability to place phone calls, send / receive text messages, and take
screenshots. Setting restrictions prevent toggling the state of the microphone, airplane mode, camera’s
led and Bluetooth. These restrictions also prevent changes to the sound and brightness values, as well
as changing the mobile device’s time.
27
T Restrictions Description
A Process Prevents the execution of applications. TrUbi terminates applications not allowed to run by atrust lease, when it is activated.
R Network Prevents access to the Internet. TrUbi terminates applications with open networkconnections, when a trust lease is activated.
Camera Denies access to the camera. TrUbi terminates running applications that have gained prioraccess to the camera, when a trust lease is activated.
Phone Call Prevents applications from making or receiving phone calls. TrUbi terminates ongoing calls,when a trust lease is activated.
SMS Prevents sending or receiving SMS / MMS messages.
Screenshot Blocks screenshots issued by the user (e.g., by pressing the power and volume downbuttons) or through the Android Debug Bridge.
S Microphone Mutes the microphone until the trust lease terminates. Apps will at most collect a silence lineby reading the microphone.
Sound Sets the volume to a certain value, and prevents changes.
Brightness Sets the brightness to a certain value, and prevents changes.
Airplane Mode Disables all wireless transmission functions of the device, namely: cellular radio, WiFi, andBluetooth interfaces. Prevents toggling the airplane mode on the system settings.
LED Forces the camera built-in LED to be disabled.
Bluetooth Disables Bluetooth, thereby preventing communication using the Bluetooth network stack.
Time Prevents changes to system time through the system settings.
Legend: T: type of restriction, A: application, R: resource, S: setting
Table 3.1: Restrictions supported by TrUbi’s trust lease implementation.
3.1.4 Strapp workflow
We now take a look at how the operation mode paradigm applies to our secure applications, more
specifically by providing a generic overview of strapps’ workflow. We assume, for the sake of simplicity,
that users download these applications either from an ordinary app market, e.g., Google Play, or from a
safe source controlled by the institution associated to the secure task (e.g., university, enterprise). The
uninstallation of one of these apps is analogous to the uninstallation process of any other Android app.
From a purely functional perspective, Figure 3.2 gives an abstract overview of strapps’ workflows.
As we can see in the figure, we not only assume the presence of the lessor and lessee, but we also
assume the existence of a central server. This entity supports useful logic behind these apps (e.g., au-
thentication). For instance, in our mExam strapp a school central server is responsible for authenticating
students and keeping record of room availability and room access control lists. The logic behind who
can behave as lessors is the full responsibility of the server and should be transparent to strapps.
Lessor’s
Mobile
Device
Lessee’s
Mobile
Device
Central
Server1
2
35
Wifi Communication
NFC Communication
Trust Lease Activation
4
Figure 3.2: Strapp workflow.
28
Lessee DeviceLessor Device
…strapp 1 strapp N
Strapp Middleware
…strapp 1 strapp N
Strapp Middleware
Trust Lease Protocol
TrUbi
Middleware & Kernel
TrUbi
Middleware & Kernel
Figure 3.3: Strapp middleware.
In step 1, the lessee first optionally contacts the central server to retrieve a list of lessor identities
as well as the lease to be enforced in lessors’ devices during the secure task’s scenario. If the lessee’s
device and / or strapp have enough context to identify lessors, and if the lease to be enforced is the
sole responsibility of the lessee, step 1 may be avoided altogether. In step 2, the lessor notifies the
lessee of his interest in starting a secure task. Then, in step 3 the lessee sends the set of restrictions
(i.e., the lease) to the lessor. In possession of the lease, the lessor must decide whether he agrees
with the terms the lessee proposes, or refuses them and no longer performs the secure task. Assuming
the lessor agrees with the lease’s terms, the device transitions to restricted mode (step 4). After this
point, and until the lease terminates, the way the three parties behave differs based on the nature of
the application. Once the application’s lifetime is over, (i.e., when the strapp ends), the application must
cease its privileges with the lessor’s device transitioning back to unrestricted mode (step 5).
3.2 Strapp Middleware
The application scenarios proposed for the mExam, mMeeting, and mTicket strapps require that users’
devices make a transition from unrestricted to restricted mode. This transition is transversal to these
new application scenarios now supported by TrUbi, effectively establishing a new pattern. The profuse-
ness of this pattern proves that the development of a middleware layer on top of the TrUbi API, capable
of providing a protocol that can transparently perform this mode transition can bring tremendous ben-
efits for strapp developers. For this reason, we present the Strapp Middleware which provides a new
protocol called Trust Lease Protocol (TLP for short). A representation of this middleware can be found in
Figure 3.3. Basically strapps on the lessor and lessee side leverage the Strapp Middleware to negotiate
leases, over TLP, which are then enforced by TrUbi on the lessor’s device. We now present TLP’s design.
3.2.1 Trust Lease Protocol
The Trust Lease Protocol is a developer-friendly mechanism that transparently mediates the Trust Lease
negotiation between lessors and lessees. The goal of this protocol is thus to negotiate a lease and
29
OS unrestricted
strapp middleware
strapp logic
strapp middleware
1
strapp logic
strapp middleware
strapp logic
t
1
effective mode transition
2
strapp middleware
OS unrestricted
3 4 7
5 7
8
strapp logic8
protocol setup
protocol setup
trust lease active
t
Lessor Device
Lessee Device
strapp middleware
OS restricted
6
mode
transition
secure
channel
establishment
Figure 3.4: Trust lease protocol workflow.
make the transition of the lessor’s device from unrestricted to restricted mode accordingly. This protocol
comprises two main phases: (1) secure channel establishment, and (2) mode transition. Figure 3.4
gives a high-level representation of TLP’s workflow. In this figure both the secure channel establishment
and mode transition phases are shown as “black-boxes”, but we detail their design next.
The protocol starts with both the lessee-side and lessor-side strapps setting up the necessary pro-
tocol configurations (step 1), using an API (see Section 4.1.3), that allows strapps to manage when
they wish to negotiate the protocol (i.e., in a simple start-stop state machine). In step 2 the lessor’s
protocol side initiates the secure channel establishment, which yields a session key when that phase
is completed (step 3). This key is then used from there on in the encryption of every communication
message of the protocol. Step 4 represents the bi-directional communication where lease conditions
are presented and accepted by the lessor. In step 5 the control goes from the Strapp Middleware to the
OS so that the lease can be activated, and in step 6 the control returns from the OS back to the Strapp
Middleware. Step 7 shows the attestation step where the lessee is effectively notified of the lessor’s
device mode transition success. Finally in step 8, the Strapp Middleware returns the control to strapps.
Secure Communication Establishment TLP was envisioned to be as transparent as possible, mean-
ing that it should work irrespective of the communication technology on top of which it is negotiated.
Unlike for network communication (i.e., sockets), it seems that, to the best of our knowledge, there is no
SSL-like protocol available to use on top of NFC. For this reason we propose a simplified SSL version,
that is by no means an improved version of the original SSL version in terms of security, but is nonethe-
less a reasonable replacement given the proof-of-concept nature of this work. From Figure 3.5 we can
see the major differences between the two versions’ designs. Note that although we use SSL’s original
30
Secure Communication
…
Client Hello
Lessor(Client)
Lessee(Server)
Server Hello
Server Certificate
Client Certificate Request (optional)
Server Hello Done
Client Certificate (optional)
Client Key Exchange
Certificate Verify
Change Cipher Spec
Client Finished
Change Cipher Spec
Server Finished
Secure Communication
…
Client Certificate
Lessor(Client)
Lessee(Server)
Server Certificate
Nonce
Nonce + Session Key
“ACK” encrypted using Session Key
Original SSL Simplified SSL
tt
tt
Figure 3.5: SSL version comparison.
Client-Server notation for this comparison, in our scenarios, lessors are clients, and lessees are servers.
The first difference we can identify is right at the beginning of the protocol. While the original SSL
offers a set of Hello messages used in negotiating the technology and exchanging random values used
in generating the session key, the NFC version offers an inflexible solution, where no negotiation occurs.
The second difference is at the certificate exchange phase. While the original SSL version makes it
optional for the lessor to send his certificate for the lessee to validate, our version enforces a two-way-
authentication, where both parties are forced to send their certificates, and to validate their counterparts’.
We decided to enforce this authentication, as we believe it provides an extra security measure when
establishing our secure channel.
The third difference, and the one more critical in terms of security is the session key generation
phase. In the original SSL, the lessor uses the Client Key Exchange message to send a premaster secret
derived from random values, previously exchanged, which are then used by both sides to compute the
master secret and derive the session key from it. In the NFC version, on the other hand, we use a
one-sided session key generation approach, where it is up to the lessor to generate that key. We are
fully aware that this design decision may bring security vulnerabilities, but given the proof-of-concept
nature of this work, we find this solution to be reasonable. Still, a simple solution to mitigate these
vulnerabilities could be the adoption of a stronger protocol for the session key generation phase such as
Diffie-Hellman [11].
31
Secure Communication
…
Client Certificate
Lessor
(Client)Lessee
(Server)
Server Certificate
Nonce
{{KS + Nonce}K+Lessee} + {{Hash(KS + Nonce)}K-
Lessor}
{“ACK”}KS
Verify Certificate
Generate KS
Verify Certificate
Verify Hash
tt
Figure 3.6: Simplified SSL detailed.
The forth difference is the generation of a nonce by the lessor, which is then sent to the lessee along
with the session key. This nonce is sent to guarantee freshness and prevent replay attacks.
Figure 3.6 shows a more detailed representation of the SSL design for NFC. As we have said, the
protocol starts with an exchange of certificates, with each exchange being followed by their counterpart’s
certificate validation. At that point the lessee generates a nonce and sends it to the lessor. The lessor
then generates a session key (KS), and sends it, as well as the nonce, to the lessee, on a composed
message. On one side, both nonce and session key are encrypted with the lessee’s public key (K+B )
for privacy. On the other side, both nonce and session key are hashed for integrity, and signed with
the lessor’s private key (K−A ) for authenticity. After verifying the hash and authenticity, the lessee sends
a string “ACK”, symmetrically encrypted using the session key, to the lessor, and the secure channel
establishment is thus complete.
Mode Transition After the establishment of a secure channel between lessor and lessee, TLP pro-
ceeds to the mode transition phase. This is where the lessee sends the lease conditions to the lessor,
which it must accept in order to make the transition from unrestricted to restricted mode. Figure 3.7
shows a detailed perspective of the steps involved in this phase.
As we can see, after the secure establishment phase, both parties hold the session key which is
used for further secure communication through symmetric encryption of the messages exchanged. The
lessee starts by signalling its availability to the lessor by sending the string ”AVAILABLE”. This step
represents the beginning of step 4 in Figure 3.4. The lessor then responds with its identification, which
must be sent in a particular form to ensure compatibility with the lessee side. The lessee then validates
that identification before sending the lease conditions, which are then presented to the lessor. Even
before they are accepted, the protocol proceeds with the lessor side acknowledging the reception of the
conditions by sending the string ”LEASE RECEIVED”.
After receiving the lease conditions reception acknowledgement, the lessee immediately starts the
32
Lessor Device in Restricted Mode
…
{“AVAILABLE”}KS
Lessee Lessor
{Id}KS
{Lease}KS
Secure Channel Establishment
KS KS
Show Lease Conditions
{“LEASE RECEIVED”}KS
{“TRUBI CERTIFICATE”}KS
{TrUbi Certificate}KS
Verify TrUbi Certificate
Generate Random Token
Calculate Lease Hash{Random Token}KS
quote
{Lease Hash}KSverify
{“HANDSHAKE COMPLETE”}KS
{ACK}KS
tt
Validate Id
startlease
Figure 3.7: Mode transition phase.
attestation step, where it requests proof of the correct transition of the lessor’s device from unrestricted
to restricted mode. This step represents the beginning of step 7 in Figure 3.4. The lessee starts by
requesting the lessor’s TrUbi certificate by sending him the ”TRUBI CERTIFICATE” string. The lessor
then responds by sending that same certificate. After receiving it, the lessee validates the lessor’s TrUbi
certificate, generates a random token to calculate a local hash of the lease sent to the lessor, and sends
that hash to the lessor. The lessor then requests a lease hash from TrUbi through its API’s quote call,
using the just received token. This hash request is a blocking mechanism that waits until a timeout in
order to return the lease hash. If, after the timeout, the lessor has failed to accept the lease conditions,
the hash request returns a default erroneous value. Otherwise, it returns the hash of the lease currently
being enforced.
As we can see in the figure, we assume the lessor accepts the lease conditions before the quote
call. The acceptance of the terms triggers the startlease method. Even so, whatever the hash result
may be, the lessor then sends it to the lessee. The lessee then verifies the lease hash, through TrUbi’s
API verify method, and in case both match, it signals the completion of the protocol by sending the string
”HANDSHAKE COMPLETE”. If they do not match, the protocol is aborted. After receiving the protocol
completion message from the lessor, the lessee sends the string ”ACK”, acknowledging the termination
33
Student’s
Mobile
Device
Professor’s
Mobile
Device
School
Server1
2
4
3
5
Wifi Communication
NFC Communication
Trust Lease Activation
6b
6a
7
Figure 3.8: mExam workflow (with the student being the lessor, and the professor the lessee).
of the protocol.
3.3 Use Case Strapps
In this section, we describe the architecture and workflows of the mExam, mMeeting and mTicket strapps
separately. Then, given that employing a one-size-fits-all solution to each of these strapps is infeasible,
we present, for each one, a basic and advanced use case scenario. In each of these scenarios, we
present its threat model, the trust lease used to enforce the scenario’s security requirements, as well as
the lease termination conditions.
3.3.1 mExam
The mExam strapp is intended to allow students to use their devices to answer exams, while preventing
them from cheating.
The mExam usage scenario considers a professor app, running in professors’ devices, where the
professor plays the part of lessee, and a student app, running in students’ devices, where students play
the part of lessors. We assume, for the sake of simplicity that, in this mExam scenario, the educational
institution has some kind of academic portal, like Fenix [14] or Moodle [18], providing academic and
management functionalities (e.g., handle students’ enrolment in exams, distinguish between students
and professors, to ensure only professors can book exams). Professors are able to build their exam
statements, and choose the group of professors they want to invigilate the exam rooms, information
that they must then upload to the central server. On the other hand, professors are also able to specify
exam trust leases, which may or may not be controlled by the school through the central server. The
restrictions that an exam trust lease may impose on students’ devices can vary, and we discuss them
next, when we present our basic and advanced scenarios. Students are free to enroll / unenroll in exams
as long as their corresponding registration windows are opened.
We now explain this scenario’s workflow, which can be seen in Figure 3.8. In the day of the exam,
already in the class room, the invigilating professor starts by retrieving the list of all enrolled students
from the server (step 1). This list contains not only the ids and photos of each enrolled student but also
34
a token customized for each student. Then, as students enter the room, they communicate with the
professor, for example using NFC (represented in the figure with a dashed line), to identify themselves
(step 2). After confirming the identity of a student, the professor sends him the exam trust lease (still
step 2), which the student must accept in order to proceed with the exam. With the student’s device
already in restricted mode (step 3), the professor then sends the token to the student (step 4). This
last communication is already performed using WiFi, instead of NFC, which is only used in the student’s
mode transition phase. The student then uses the token to prove to the school’s server he’s in fact in
the room (step 5). After the school server validates the identifier, it then sends the exam statement back
to the student (still step 5). At that point, the student signals the professor he’s ready to start the exam.
Once the professor identifies all students in the room, he broadcasts a message signalling the start of
the exam to the students.
When the student’s exam time runs out, he can no longer perform any changes, as neither the strapp
or the school server will allow him to do so. Once the student finishes his exam, he makes his complete
exam submission to the server (step 6a). If the invigilating professor detects, during the exam, that the
student is cheating he may also force the abortion of that student’s exam (step 6b). Independently of the
way the exam ends, the scenario terminates with the transition from restricted mode, back to unrestricted
mode (step 7).
Basic Scenario
• Threat Model - In this scenario we consider an adversary (i.e., a student) that tries to cheat in
his exam. This adversary may use all available communication channels to get answers either
from colleagues or from the Internet. Even so, in this scenario we allow students to use a pdf
application to access personal notes. Note however, that this is a scenario adapted threat model,
which means it extends the threat model presented in Section 3.1.2 as well;
• Trust Lease - Given this scenario, the exam trust lease specifies the duration of the exam and
corresponding restrictions, and guarantee that only the mExam strapp and a specific pdf reader
application are allowed to run during the exam. Note that the exam statement still remains on the
mExam strapp, not on the pdf reader. Even though only these two applications can run, our trust
lease must also grant access to the Internet and NFC to our mExam strapp only. The lease must
additionally restrict any usage of Bluetooth as well as the reception and emission of text messages.
The specification of the lease is done in XML format;
• Lease Termination - For this scenario we consider four different ways for the trust lease to termi-
nate: (i) the student reaches the exam time limit, (ii) the student submits the exam, (iii) the student
aborts the exam, or (iv) the invigilating professor terminates the student’s exam for some reason.
Advanced Scenario This advanced scenario for mExam is closest to real-world usage scenarios, in
which professors just want to prevent students from cheating. On the other hand, this scenario’s threat
model assumes that an attacker may not only use the communication channels mentioned in the basic
35
Attendant’s
Mobile
Device
Host’s
Mobile
Device
Company
Server 1
5
8
6
4
Wifi Communication
NFC Communication
Trust Lease Activation
109
2
3
7
Figure 3.9: mMeeting workflow (with the attendant being the lessor, and the host the lessee).
scenario, but he may also try to access private files to access exam answers. To prevent exam cheating
and access to private files, this scenario’s trust lease only allows the mExam strapp to run during the
exam, and also applies all the restrictions over communication channels mentioned in the basic scenario.
3.3.2 mMeeting
The mMeeting strapp is intended to prevent meeting attendants from using their devices to leak sensitive
meeting information.
In this mMeeting scenario the meeting host plays the role of lessee, while attendants play the role of
lessors. Again, in this case, the enterprise’s or institution’s server must be responsible for being able to
distinguish between employees who can book meetings, from employees who cannot. The mMeeting
strapp allows for meeting hosts to create their own meeting trust leases. A visual representation of this
scenario’s workflow can be seen in Figure 3.9.
In preparation of the meeting, the host submits the list of people allowed to attend the meeting, and
his local network IP to the company server (step 1). Before starting, the host signals the beginning of
the meeting to the company server (step 2), and restricts his own device with the meeting’s trust lease
(step 3). Once attendants arrive, in order to communicate with the host, they must first retrieve the host’s
IP from the company server (step 4). Then, they must identify themselves to the host (step 5). After
identifying an attendant, the host then sends the meeting trust lease in return (still step 5). Attendants
may accept the trust lease’s terms and be granted access to the meeting, or reject them and withdraw
from the meeting. Step 6 represents the transition from the attendant’s device from unrestricted to
restricted mode, assuming he accepted the lease’s terms. During the meeting, attendants and host are
able to attest each others devices, in order to check if the devices are or not at risk of being leaking
meeting data (step 7), for example by using an open phone line. This attestation is done in a process
similar to the negotiation of TLP (Figure 3.4), but without the lease activation steps, i.e., without steps
4, 5 and 6 from that figure. Once the meeting is over, the host signals the end of the meeting to every
meeting attendant (step 8), which triggers their devices’ transitions from restricted back to unrestricted
mode (step 9). After every attendant’s device makes that transition, the host makes that same transition
himself, concluding the scenario (step 10). Note however, that if an attendant wishes to leave earlier
he’s free to terminate the restrictions on his phone with a click of a button (step 9).
36
Unlike in the other scenarios, in this case, in terms of security, we want the host to behave as an
ordinary attendant as well. Meaning we want hosts to be able to use their devices just like any other
attendant, while at the same time guaranteeing that compromised hosts’ devices do not leak sensitive
meeting information (e.g, by using the microphone in combination with an Internet connection).
Basic Scenario
• Threat Model - In this scenario, we consider a lenient level of security threat in which an adversary
forgets to mute his device, or uses apps that are not meeting-related during the meeting (e.g.,
social media apps). Again note that this is a scenario adapted threat model, which means it
extends the threat model presented in Section 3.1.2 as well;
• Trust Lease - Given this scenario’s threat model, the meeting trust lease specifies the duration of
the meeting and corresponding restrictions. These restrictions then either prevent certain know so-
cial media apps from running (e.g., Facebook, Instagram), or allow only for our mMeeting strapp to
run. This lease also mutes users’ devices and prevents users to unmuting them. The specification
of the lease is done in XML format;
• Lease Termination - For this scenario we consider three different ways for a trust lease to termi-
nate: (i) the host explicitly terminates an attendant’s lease, (ii) an attendant explicitly terminates
the lease before exiting the room, or (iii) the lease’s duration limit is reached.
Advanced Scenario In this advanced scenario, we consider a more malicious type of adversary, when
compared to our mMeeting basic scenario. This adversary tries to capture or even live leak sensitive
meeting information. For these reasons, this scenario’s trust lease blocks every communication channel
available (e.g., phone call, SMS, Internet, Bluetooth) to prevent sensitive meeting information leakage.
This lease also blocks access to both camera and microphone, as they could be leveraged, for example,
to photograph confidential slides, or record meeting conversations respectively, yielding another form of
meeting information unauthorized capture and leakage.
3.3.3 mTicket
The mTicket strapp intends to prevent audience disturbances in movie theaters due to wrong mobile
device usage, such as using a mobile device with high screen brightness during a movie.
In the mTicket scenario, movie spectators play the part of lessors, while movie theater staff play the
role of lessees. The mTicket strapp allows for movie spectators to use their smartphones as movie ticket
wallets. These devices are then used to validate these same tickets when entering a movie theater
room. Figure 3.10 shows this scenario’s workflow.
After acquiring the ticket, and before entering the movie room area, the user communicates with an
NFC terminal using his smartphone. Here the NFC terminal provides a variation to the original strapp
worflow (Figure 3.2), where the lessor’s device is a mobile device as well. This communication validates
37
User’s
Mobile
Device
Cinema’s
Terminal
1 2
3
Cinema’s
Wifi AP
5
4
Figure 3.10: mTicket workflow (with the user being the lessor, and the cinema terminal the lessee).
the user’s ticket (step 1), and after doing so, it immediately sends the lease conditions to be enforced on
the user’s device during the movie (step 2). As we have said, both these steps are performed through
NFC, which is represented in the figure by a dashed line. After accepting the lease’s terms, the user’s
device transitions to restricted mode (step 3). Considering the nature of a movie theater, forcing movie
spectators to communicate with a terminal once again after the movie is over would be seen as too
troublesome, as it would basically be the same thing as forcing them to show their tickets again, before
leaving. To address this problem, the mTicket strapp continuously checks if the device is in reach of the
movie theater’s WiFi signal. If after a certain timeout the device is still outside the signal’s reach, the
restrictions are revoked. This means that if a user decides to leave in the middle of the movie, he would
automatically regain control of his device (optional step 4). At the end, either because the movie ended
or because the user left the movie earlier, the user’s device transitions back to unrestricted mode (step
5), terminating the scenario.
Basic Scenario
• Threat Model - In this scenario, we consider negligent adversaries that use their devices in ways
that disturb other spectators during a movie (e.g., forget to mute their devices or use their devices
with high screen brightness). Again note that this is a scenario adapted threat model, which means
it extends the threat model presented in Section 3.1.2 as well;
• Trust Lease - Given this scenario, our movie trust lease specifies the duration of the movie and
corresponding restrictions, mute users’ devices and guarantee users cannot unmute them, and
turn screens’ brightness to the minimum, while preventing them from increasing it, during a movie.
The specification of the lease is done in XML format;
• Lease Termination - For this scenario we considered two different ways for a trust lease to termi-
nate: (i) a user leaves the movie room, stepping outside the movie theater’s WiFi range, or (ii) the
lease’s duration limit is reached.
Advanced Scenario In this advanced scenario we consider an adversary that not only disturbs other
spectators by unmuting his device, increasing screen brightness and even activating the back led, but
38
also an adversary that uses his camera to actually record the movie. This scenario obviously requires
the movie trust lease to not only prevent users from unmuting their devices, and increasing their screens’
brightness, but also to access the camera. The denial of access to the camera eliminates both the movie
recording, and led related issues.
3.4 Summary
In this chapter we present an overview of the trust lease primitive, the new mobile operation mode
paradigm, and TrUbi, the Android-based system we leverage to develop our applications. We also
present, the design of the Strapp Middleware, a new abstraction layer to be built on top of TrUbi, to help
the transparent negotiation and consequent enforcement of this primitive. Additionally, this layer provides
a novel programming model (covered in Section 4.1.3) that eases the work of strapp developers. We
detail the Trust Lease Protocol, a two phase mechanism that runs on top of the Strapp Middleware
layer, and allows users and third parties to negotiate the restrictions and corresponding conditions to be
enforced on users’ devices. Finally we describe the architecture and workflows of the mExam, mMeeting
and mTicket strapps separately. For each strapp, we present and discuss a basic and advanced use
case scenario, with the corresponding threat model, as well as the trust lease and lease termination
conditions. Given the different needs from each scenario, these strapps become essential in covering
most of trust leases’ restrictions, contributing to thorough tests on the effectiveness of trust leases.
39
40
Chapter 4
Implementation
In this chapter, we present the most important implementation decisions of this work. First we cover
the implementation of the Strapp Middleware, focusing on the two phases of the Trust Lease Proto-
col (i.e., secure channel establishment, and mode transition). Then, we present the API provided by
the Strapp Middleware to strapp developers, and discuss the implementation of this protocol on the
two communication technologies we addressed, i.e., network and NFC. We conclude by describing the
implementation of the mExam, mMeeting and mTicket strapps, referring also the differences between
the initially idealized architecture and the actual implementation, and terminate by covering the servers
involved in these strapps’ scenarios.
The development of the previously described middleware and strapps is done under the Android
environment. This decision was based on the fact that TrUbi is built on top of the Android Open Source
Project (AOSP) [5].
4.1 Strapp Middleware
In Section 3.2 we present the Strapp Middleware, a new layer built on top of the TrUbi API to ease
the transition from users’ devices from unrestricted to restricted mode. In this section we present its
implementation; Figure 4.1 shows its major components. This figure presents the various high level
components / libraries used in the implementation of TLP provided by the Strapp Middleware. Note
that this figure shows the negotiation of TLP from the lessor’s perspective. The implementation of TLP
from the lessee’s perspective is identical, but without the trust lease activation step, following the design
presented in Section 3.2.1.
For developers, TLP introduces a new, yet simple development paradigm. In order to use TLP,
developers must use protocol adapters, whose root class is the TLProtocolAdapter. We provide more
information on the API provided by the Strapp Middleware in Section 4.1.3.
From Figure 4.1 we can see that the negotiation of TLP starts with the lessor strapp setting up
the protocol, which in practice, translates in calling an adapter’s constructor. This constructor receives
the keystore ids of both the CA and client certificates, as well as their corresponding passwords, and
41
strapp strapp
t
strapp middleware
TrUbi Middleware
protocol
setup
TrUbi Kernel
TrUbi Middleware
(restricted)
java.security java.security
javax.crypto
TrUbi API
java.security
java.net / android.nfc
secure channel
establishment
trust lease
activation
mode
transition
TrUbi Kernel (restricted)
java.net / android.nfc
Figure 4.1: Strapp Middleware implementation and corresponding workflow (lessor’s perspective).
transparently loads such certificates into memory, so that later they can be easily accessed in the secure
channel establishment phase (more on this in Section 4.1.1). The secure channel establishment then
starts with either the setup of web sockets, for the network implementation, or with the activation of the
NFC sensor, for NFC. During this phase, the secure channel establishment follows the design presented
in Section 3.2.1, (detailed implementation explanation in Section 4.1.1). Overall, this phase consists on
an exchange of certificates, and corresponding validation as well as a session key generation step.
The Strapp Middleware leverages the java.security package from Android’s API to handle certificates,
and the javax.crypto package for the key generation step. The communication on top of which TLP is
negotiated relies on Android’s java.net package for the network communication (i.e., sockets), and on
the android.nfc package for NFC communication. The protocol then proceeds with the mode transition
phase, where lease conditions are presented to lessors, whose acceptance triggers the activation of
the trust lease. The phase ends with an attestation step that provides lessees assurances regarding
the mode transition’s phase success. The Strapp Middleware relies on the TrUbi API to activate the
lease, and to ask for that lease’s hash so that it can be used as proof of the transition phase’s success to
lessees. This Middleware also relies on the java.security package to validate the lessor’s TrUbi certificate
in the attestation step, and on either the java.net or android.nfc packages for communication purposes,
depending on the adopted solution.
In the following sections we detail the implementation of TLP’s secure channel establishment and
mode transition phases. Then, we present the API provided by the Strapp Middleware, and conclude by
specifying the major decisions on our network and NFC implementations.
4.1.1 Secure Channel Establishment
The implementation of the TLP’s secure channel establishment phase first started on top of the network
communication technology, (i.e., sockets). Instead of reinventing the wheel, we sought to use Android
APIs, more specifically the Java Secure Socket Extension (JSSE), which provides SSL socket mecha-
nisms, a prominent and extensively used technology in network communication security. However, we
had some difficulties using these APIs. On one hand, Android’s documentation on SSL sockets and re-
42
lated components is very weak, as they provide no useful examples upon which a developer can easily
adopt this protocol. In fact, most examples provided by Android on SSL, relate exclusively to HTTPS [3].
On the other hand, the lack of information linking the creation and handling of certificates, needed to
establish a secure connection in this protocol, with the usage of SSL socket related components, (e.g.,
TrustManager, KeyManager), is another alarming problem that caused us setbacks. In Appendix A we
provide useful information on studies that cover the details of the difficulties surrounding the usage of
SSL for Android.
Instead of using self-signed certificates which would lead to scalability issues, and because they have
been shown to be a source of vulnerabilities [48, 76], (e.g., apps accepting all self-signed certificates),
we opted to follow best practices [51, 76], and used a custom Certificate Authority (CA) based approach.
Essentially, every entity in our scenarios has a certificate (i.e., client certificate saved in a KeyManager)
signed by the CA certificate, as well as a TrustManager that trusts that same CA, and uses the CA
certificate to validate other client certificates when establishing secure channels.
Both our certificates (X509) and private keys had an initial size of 4096 bits, and were created using
OpenSSL [20], an open-source SSL library available in Android. In order for these certificates and private
keys to be used by Android, we created Bouncy Castle keystores (i.e., BKS keystores), containing the
necessary certificates and private keys, using a tool called Portecle [22]. This tool is a handy GUI
application that eases the handling of keystores, keys, and certificates.
The implementation of the secure channel establishment phase using JSSE was initially tested to
evaluate the effectiveness of the mechanism in an operation similar to the one provided by TLP. We
created a demo app with two objectives: (1) test whether the communication between lessee and lessor
could effectively transition the lessor’s device from unrestricted to restricted mode, and (2) test whether
the communication between the two parties was done over secure SSL channels. The test relied on
a computer used as a hotspot and a network protocol analyzer [28] to monitor all the communication
between lessor and lessee.
The test results showed that the lessor’s device transitioned to restricted mode, and the communi-
cation analysis showed no perceptible or clear text information. However, the performance fell below
our expectations, with SLL related operations accounting for roughly 2 seconds, a huge delay even for
mobile devices.
Performance Workaround After finding no compelling reasons that could justify this low performance,
and with very little control over Android’s SSL implementation, we decided to adapt the simplified SSL
version initially designed for NFC communication, for our network implementation as well. We knew that
it would be overkill to create a protocol to replace Android’s SSL not only because of the work that it
would require, but mostly because of the difference in maturity of the two implementations. However,
like for NFC, given the proof-of-concept nature of this work, and considering that the adoption of the
same secure channel protocol for both communication technologies would at least bring consistency
including for evaluation purposes, we decided that it would be a well-adjusted solution to proceed with
our own implementation of SSL.
43
TLProtocolNetworkAdapter
TLProtocolLesseeNetworkAdapter
TLProtocolLessorNetworkAdapter
TLProtocolNFCAdapter
TLProtocolLessorNFCAdapter
TLProtocolLesseeNFCAdapter
TLProtocolAdapter
<<interface>>TLProtocolLessorHandshakeListener
<<interface>>TLProtocolLesseeHandshakeListener
Figure 4.2: UML representation of TLP’s implementation.
The simplified SSL version, previously explained in Section 3.2.1, relies on AES-256 for symmetric
cryptography, and on RSA and SHA-2 for digital signatures. All these cryptographic operations are
provided by Android’s java.security and javax.crypto packages.
The simplified SSL implementation was tested with the same demo app used for JSSE, only this time
with our new SSL implementation. In terms of effectiveness, the results were similar, the operation was
successful and the network analysis showed no perceptible or clear text information. On the other hand,
in terms of efficiency, we recorded a 50% speedup when compared with Android’s SSL implementation.
We considered the results far from being perfect, but considering that the communication between
lessee and lessor requires the lessee to interact with the UI to confirm the lessor’s identity, we thought
that this delay could effectively be attenuated by that same interaction. However, by coincidence, the
developers of the TrUbi prototype detected elevated performance slowdowns in some cryptographic
operations. These slowdowns were caused by the sizes of the keys used in their protocols, which were
similar in size to the ones used in this work (i.e., 4096 bytes). Changing the size of the keys from 4096
to 1024 bits led to speedups of about one order of magnitude in some TrUbi cryptographic operations
which led us to change all our apps’ certificate and private keys accordingly as well.
Because RSA uses a block-cipher approach, and because the keys involved were now smaller, the
protocol suffered modifications in order to partition the data to blocks with the size of the now used
RSA-1024 (i.e., 128 bytes). This issue was obviously more problematic in the interactions that involved
certificate exchanges, due to the length of the data involved. We ended testing the demo app again,
focusing solely on efficiency this time, and ended up recording a reasonable result (i.e., bellow 320ms).
In Section 5.2, we present additional performance evaluation information on both the Simplified and
Android’s SSL implementations.
44
1 public abstract class TLProtocolAdapter {2
3 ...4
5 public abstract void start();6 public abstract void restart ();7 public abstract void stop();8
9 }
Listing 4.1: TLP adapter API.
4.1.2 Mode Transition
The mode transition phase leverages the secure communication’s phase resulting session key to encrypt
every message from there on. This encryption relies, as we have said, on APIs provided by Android’s
javax.crypto package. The protocol then proceeds with an exchange of simple messages, that fully
respect the design we presented in Section 3.2.1 (Figure 3.7).
In the attestation step, the lessee validates the lessor’s TrUbi certificate leveraging the APIs from the
java.security package. The generation of the random token and the computation of the hash of the trust
lease, relies on the same java.security package’s API. In order to request the hash of the lease currently
being enforced on TrUbi, the lessor uses TrUbi’s API quote call. The lessee then compares the hashes
of the leases, using the TrUbi API’s verify call. Once the lessor agrees with the lease’s terms, it triggers
the TrUbi API’s startlease call, which then makes TrUbi begin the enforcement of the lease.
4.1.3 Strapp Middleware API
The Strapp Middleware provides TLP under a developer-friendly programming paradigm. In order to
use TLP, developers must use protocol adapters, whose root class is the TLProtocolAdapter. Figure
4.2 shows the UML representation of the available adapters for developers. Essentially the protocol
adapter family is divided into network and NFC adapters, where each of these branches have their cor-
responding lessee and lessor adapters, which must be used complementarily in order to successfully
negotiate TLP. These leaf adapters, the ones developers must use, depend on their side’s correspond-
ing interfaces, (i.e., TLProtocolLesseeHandshakeListener or TLProtocolLessorHandshakeListener)
which developers must implement in their application components, in order for their strapps to commu-
nicate with the Strapp Middleware. These adapters use a very simple API that can be seen in Listing
4.1. As the method names imply, both start() and stop() methods are used to enable and disable the
device from being able to negotiate TLP respectively, while the restart() method is used to reset this
negotiating ability in certain situations (e.g., stop() must be called if an activity responsible for handling
an adapter must be sent to the background, but in order to reload it back to the foreground, restart()
must be called instead of start()).
In Listings 4.2 and 4.3 we can see the methods called by the TLP adapters, through their sides’ APIs.
It’s through these methods that these adapters can notify applications of several different events. As can
be seen in those listings, both interfaces provide a handshakeCompleted() method, which as the name
45
1 public interface TLProtocolLessorHandshakeListener {2 void lessorHandshakeCompleted(boolean success , String message);3 void leaseTimeNotification(int timeToFinish);4 }
Listing 4.2: Lessor side interface of TLP.
1 public interface TLProtocolLesseeHandshakeListener {2 boolean validateLessorId(String lessorId);3 void lesseeHandshakeCompleted(boolean success , String message);4 void attestationCompleted(boolean success , String message);5 }
Listing 4.3: Lessee side interface of TLP.
Figure 4.3: mExam identity confirmation dialog.
implies, is used to notify applications of the result of the TLP negotiation. The lessor interface provides a
leaseTimeNotification() method, that is used to notify the application about the time left on a lease.
This mechanism must be explicitly specified when setting up the adapter. On the other hand, the lessee
interface provides an attestationCompleted() method, which similarly to the handshakeCompleted()
method, is used to notify applications of an attestation request result. For instance, in a mExam app,
the result of this method could determine if the student could or could not continue to answer his exam.
The validateLessorId() method is used, as the name implies, for developers to design the way they
wish their lessee applications to validate the identity of a lessor. For instance, in the same mExam app,
this method could be used to present a dialog like the one shown in Figure 4.3, so that a professor could
validate the identity of a student based on his name and photo.
In Appendix B we provide a concrete example on how to use the Strapp Middleware’s API.
46
TLProtocolNetworkAdapter
TLProtocolLessorNetworkAdapter
TLProtocolLesseeNetworkAdapter
<<interface>>TLProtocolLessorHandshakeListener
<<interface>>TLProtocolLesseeHandshakeListener
SimplifiedSSL
java.lang.Thread
SimplifiedSSLDataInputStream
SimplifiedSSLDataInputStream
Figure 4.4: UML representation of TLP’s network implementation (new components in grey).
4.1.4 Network and NFC Implementations
The use of sockets in order to perform network communication is a mechanism used extensively,
with plenty of documentation and examples, available on the java.net package. The same applies
for cryptographic operations, with a lot of useful information available on both the javax.crypto and
java.security packages. For these reasons, if we exclude the problems we had with the Android SSL
APIs, the implementation of TLP on top of network communication was straightforward. Essentially, we
leveraged these packages and the API provided by TrUbi to implement the secure channel establish-
ment and mode transition phases accordingly to the diagrams we presented. Figure 4.4 shows the UML
representation of the network implementation of TLP. As explained before, lessor and lessee adapters
use their respective side’s interfaces to communicate with application components. Because Android
prevents network communication from happening inside the application’s main thread [4], which is ded-
icated to UI related logic, our network adapters implement all their logic inside a java.lang.Thread.
These adapters’ communication leverage the SimplifiedSSL component to establish the secure chan-
nel, and then both the SimplifiedSSLDataInputStream and SimplifiedSSLDataOutputStream to ex-
change messages encrypted with the session key.
When compared to the network implementation of TLP, the NFC’s implementation complexity is much
superior. For that reason, the rest of this section is dedicated to NFC in its entirety. We begin by giving
some background on Android NFC support to justify our adopted solution and conclude by presenting
implementation details specific to NFC. In Appendix C we present a more in-depth explanation over the
different operation modes offered by NFC and Android’s corresponding support.
47
TLProtocolNFCAdapter
TLProtocolLessorNFCAdapter
TLProtocolLesseeNFCAdapter
<<interface>>TLProtocolLessorHandshakeListener
<<interface>>TLProtocolLesseeHandshakeListener
TLProtocolLessorService
TLProtocolLesseeThread
HostApduService java.lang.Thread
Figure 4.5: UML representation of TLP’s NFC implementation (new components in grey).
Adopted NFC Solution Android supports the three different NFC operating modes: (1) reader/write
mode, (2) peer-to-peer mode, and (3) card emulation mode. However, all of them were designed with
the intention of performing very short communications, that would generally involve small amounts of
data. Given the complexity of the Trust Lease Protocol, it is clear that an NFC solution can only work, if
it can reliably support a considerable amount of communication messages.
The combination of reader and writer mode solutions is incompatible with our bi-directional commu-
nication requirements, because devices cannot toggle between modes during a connection.
Android’s Beam mechanism offers peer-to-peer communication, but the obligation of making the
user confirm each message before sending it, renders this solution impractical. Even the example apps
(e.g., NFC chat, guessing number game, question based hot potato game) provided by textbooks on the
development of NFC applications [43], show how limited this mechanism is, because of this message
confirmation obligation step.
Our option is then to implement the NFC Trust Lease Protocol using a combination of Host Card
Emulation (HCE) and reader modes. By defining a custom application id (AID) to the strapps that use
this NFC mechanism, we can then make the other counterpart device to communicate specifically to
these applications. Note however, that using HCE combined with reader mode to enforce peer-to-peer
communication is sort of a workaround, and one can only hope that Android APIs will allow access to
the stack responsible for managing the exchange of NFC messages, in one of the coming releases.
NFC TLP Implementation Similarly to what happened with the network implementation, the work
surrounding cryptographic operations in NFC was also straightforward. The work on the communi-
cation part of NFC, on the other hand, was much more complex. Figure 4.5 shows the UML repre-
sentation of the NFC implementation of TLP. In this NFC implementation, the protocol adapters use
different components depending on their TLP sides, unlike in the network implementation, where the
adapters rely on threads to implement their logic. In NFC, the lessee adapter adopts the reader
mode, whose implementation is contained entirely inside a background thread (i.e., a component called
TLProtocolLesseeThread that extends java.lang.Thread). The lessor adapter, on the other hand,
adopts the HCE mode, whose implementation lies on a custom service (i.e., TLProtocolLessorSer-
48
tlp msg
header
tlp msg
id
msg block
id
total msg
blocks
size of
first block
(optional)
message payload
bytes 7 1 1 1 1 250
Figure 4.6: Android TLP APDU message structure.
vice), that extends the HostApduService, necessary to process and send Application Protocol Data Unit
(APDU) commands in Android. Like in the network implementation, each side uses its corresponding
interfaces to communicate with application components.
While the network communication relies on a fixed set of messages, exchanged in a certain order,
the NFC implementation is based on commands, meaning that the state and corresponding data at
each step of the protocol must be handled differently (i.e., it must be kept in memory and reset when the
protocol finishes or aborts). Note that because of this command-based approach, the implementation of
the secure channel establishment and mode transition phases is performed in the same block of code,
i.e., the implementation is not as modular as the one for network communication. This command-based
approach also forced us to create a TLP APDU message structure for Android, represented in Figure
4.6. Another issue that we can already see from the figure is the message payload max size. Although
some new chips already support extended length APDUs, which are expected to be well-supported in
the future, the reality is that most devices nowadays still use standard length APDUs. While an extended
APDU command allows for 65535 payload bytes, standard APDUs allow for a maximum of 261 bytes
only [13].
Our 261-byte APDU message structure is composed of a 7-byte message header, similar to Android
AID message sizes, a 1-byte protocol message id, two 1-byte fields used for marking high-level mes-
sages that require their content to be broken into multiple APDU messages, and a number of 1-byte
optional fields used to mark APDU messages that contain composed data, so that the receiver knows
where to partition the information. The rest of the message is reserved for the payload. So in the best
case scenario, in a high-level message that fits into a single APDU command, the message payload can
have a length of 251 bytes, while in our most common worse case scenario, with an APDU message
containing three different pieces of information, the payload is reduced to a 249-byte length.
Therefore, it is needless to say that the creation of these messages, partition of high-level messages
into chunks that can fit into our APDU commands, message processing, high level-message recreation
and handling, not to mention all the work involving handling byte arrays, contributes to the high complex-
ity of this implementation.
NFC-Reader TLP Implementation In Section 3.3.3 we present the design of our mTicket scenario,
which features an NFC interaction between a user (i.e., lessor), and a cinema NFC terminal (i.e., lessee),
where both parties negotiate TLP. While it would be straightforward to use two mobile devices, in an
approach similar to the one used in the mExam scenario, where both professor and student use their
own devices, we wanted to get as close as possible to the real-world scenario. To that end, we decided
to implement the cinema NFC terminal with a real NFC reader device, specifically the ACR122U USB
49
tlp msg
header
tlp msg
id
msg block
id
total msg
blocks
size of
first block
(optional)
message payload
bytes 7 1 1 1 1 230
unused
payload
20
Figure 4.7: Standard TLP APDU message structure.
NFC Reader [1]. In order to do so, we used NFCTools [19], a collection of libraries and tools for NFC
in Java, and adapted the TLProtocolNFCAdapter and TLProtocolLesseeThread, so that they could be
used by NFCTools, in implementing TLP for the NFC reader side. Overall this adaptation consisted
in bringing the lessee side logic of NFC TLP from Android to a Java application, and the only major
difference between the two implementations was the size of the messages. While in Android APDU
messages had a 250 byte payload, the Java version message had to be shrunk to 230 bytes, because
the reader could not handle bigger messages. Because these difference of message sizes generated
some message ordering problems, we ended up standardizing our TLP APDU message to a 230 byte
payload for both Android and Java versions. Figure 4.7 shows this new message structure, that differs
from the original message (Figure 4.7) because of the new 20 bytes worth of unused payload.
4.2 Use Case Strapps
The implementation of the three scenarios involved the creation of four applications: (1a) mExam strapp
for students, (1b) mExam strapp for professors, (2) mMeeting strapp usable by both meeting hots and
meeting participants, and (3) mTicket strapp for movie spectators. Their implementation is entirely in
Java following the Android API level 19. Their structure is solely based on Activities. While Content
Providers may be a good solution for saving private files (e.g., a professor that saves the trust lease
wishes to impose in all his exams), we save such files directly in the apps private directory, and leverage
Android’s application sandboxing mechanism to prevent other apps from accessing them. Broadcast
Receivers could have also been used by our applications, for instance to receive intents signaling a WiFi
signal’s reach. However because the trust lease primitive already provides this mechanism, we had no
need to do so. In Appendix D we present these strapps’ wireframes.
In terms of user interface, all these apps use Android custom resource files and their theme is
Android’s own Theme.AppCompat. The mExam app for professors is the only one that uses a third
party library, DragSortListView [12] that provides drag-and-drop functionalities, ideal in the reordering of
questions when professors are specifying their exam statements. Figure 4.8 shows some screenshots
of our strapps. Figure 4.8 a) shows a screenshot of an exam question screen of our mExam strapp.
Figure 4.8 b) shows the attendants options when clicking the meeting which they are attending. In this
case, the attendant may enter the meeting, (i.e., negotiate TLP to transition his device to restricted
mode), or leave the meeting, which triggers the termination of the lease enforcement. Figure 4.8 c)
shows a movie spectator’s options after acquiring a movie ticket. In this case he can either use the ticket
(i.e., prepare his device to communicate with the movie theater’s NFC terminal, to validate the ticket and
receive the lease restrictions), or discard the ticket.
50
a) mExam b) mMeeting c) mTicket
Figure 4.8: Use case strapps’ screenshots.
Given that lessees may use the very same trust lease in different instances of the same scenario
(e.g., a professor only needs to change the exam’s start time when administering multiple exams), with
the need for very short to no trust lease specification changes, we made it so that the creation of trust
leases in both mExam and mMeeting strapps to be saved locally. In practice this mechanism allows
for the definition of policy profiles providing a simpler and smoother handling of trust leases, reducing
lessees’ efforts when specifying their needs. By offering this mechanism we also help enforcing our user-
friendliness requirement. To support this mechanism we created a set of UI elements (i.e., Activities)
that are used in the mExam professor and mMeeting strapps, to populate an instance of TrUbi’s own
Lease object. Additionally, we also created a XML writer and parser to save leases in XML format,
and to load them back into a Lease object, so they can be edited using these UI elements, or used
for TLP negotiation. In Section 4.2.1 we present a concrete example of a trust lease in XML format,
and explain its specification. In order to communicate with the central servers, these strapps use JSSE
to specify their SSLSocketFactories, as well as their KeyManagers and TrustManagers. Given that our
webserver communicates through HTTPS, our apps also use Apache’s HttpClient to establish those
secure connections. For scenario-related secure communication between strapps we use the simplified
SSL version, presented in Section 3.2.1. We use this mechanism for secure communication instead
of JSSE to avoid configuring extra key and trust managers, something we are already forced to do, in
order for the strapps to communicate with the webserver. The transition of lessors’ devices to restricted
mode is done using the two TLP implementations. mExam lessors and lessees negotiate TLP through
NFC using their devices. mMeeting participants rely on the network implementation of TLP for the trust
lease negotiation on their mobile devices. mTickets lessors use the NFC implementation between their
devices and the NFC reader presented in Section 4.1.4.
51
1 <?xml version='1.0' encoding='UTF -8' standalone='yes' ?>2 <lease>3 <duration >02 :00:00 </duration >4 <wifi_networks >trubi -wifi</wifi_networks >5 <all_wifi_networks >true</all_wifi_networks >6 <resource -restrictions >7 <resource id="Sound">8 <initial -state>Min</initial -state>9 <accesslist type="White List"/>
10 </resource >11 <resource id="Brightness">12 <initial -state>Min</initial -state>13 <accesslist type="White List"/>14 </resource >15 <resource id="Camera">16 <accesslist type="White List"/>17 </resource >18 </resource -restrictions >19 </lease>
Listing 4.4: mTicket trust lease.
4.2.1 Trust Leases
As we previously mentioned, trust leases can be specified in XML format. Listing 4.4 shows the XML
representation of a trust lease used in our mTicket strapp. As we can see, this lease has a duration of
two hours, but requires the device to be in range of a WiFi network called “trubi-wifi”. If the device steps
outside the range of this WiFi access point, the lease terminates automatically. In terms of resources, this
lease specifies restrictions on the sound, brightness, and camera. Regarding the sound and brightness,
the lease requires for the device to lower these settings to their lowest values when the lease is first
installed. Additionally, the empty “White List” access list, prevents every app from modifying these
settings during the lease enforcement. This whitelist approach is also used for the camera, this time to
ensure that no app can use the camera during the enforcement of the lease.
4.2.2 Differences between Design and Implementation
Taking into account the designs of our mExam, mMeeting and mTicket strapps presented in Chapter 3,
we made some changes on the applications in this implementation stage. These changes however do
not compromise this work’s goals. The features that differ from the design, and the features that were
not even implemented, were either not relevant or deemed out of scope of this work. We now give some
examples of such differences:
• the mExam scenario does not handle room availability, nor the rooms in which exams take place,
i.e., we assume that a single professor conducts an exam in a single room;
• the mExam professor strapp offers a static option to pick which professor invigilates the exam, i.e.,
a pre-defined professor name is sent to the school server;
• the mExam professor strapp allows professors to specify exam trust leases, but those leases are
not controlled by the school server;
• the mExam scenario features no synchronicity between professors and students when it comes to
52
the beginning of the exam, i.e., after the student negotiates TLP with the professor and receives
the token from the professor, he immediately fetches the exam statement, and begins his exam;
• the mMeeting scenario allows for a host-side attestation process only, i.e., only the host can attest
whether attendants’ devices are in restricted mode, so attendants have no attestation powers.
• the mTicket strapp simulates the payment of a ticket, in order to store it on the device.
4.2.3 Central Servers Implementation
Our central servers for each scenario are implemented, in practice, in one single webserver, more specif-
ically on a set of three Java WebServlets, each with a different endpoint. This webserver runs on top of
Apache Tomcat 7.0.63. As we have said, the communication between mobile devices and webserver is
done over HTTPS, enforced with a two-way-authentication process. We choose to enforce this authen-
tication as we believe it can be an additional security mechanism to establish a secure channel. This
means that in order to establish a secure connection, not only does the server sends its certificate to
mobile clients, similar to what happens in most webpages, but the clients themselves must also send
their certificates as well. Unlike what happened for Android, both the truststore and keystores, which are
handled transparently by Tomcat, were created in the Java keystore format (i.e., JKS keystores), instead
of BKS, for compatability with Tomcat. The certificates and keys were inserted in these keystores, using
the same GUI application we used when creating the Android-compatible keystores for our strapps. On
top of this HTTPS-based security, the requests performed by our strapps on the webserver rely on the
additional use of username-password combination for the mExam and mMeeting strapps. Because of
the “mockup” nature of these central servers, they were created with pre-defined data, i.e., students,
professors, exam events, company employees, company meetings, and movies available are added
statically when launching the server. This implementation decision, made so that dynamic information
is only kept in memory, and is later lost after we kill the server. For example, the mExam app allows for
professors to create exam events, but since they are kept in non-persistent memory only, they end up
getting lost after a webserver relaunch.
4.2.4 Demo Applications
During this work, we created several demo applications that eased our tests. Lease Creator, is an
app that as the name implies, provides an easy-to-use GUI that enables the creation and editing of trust
leases. This app was fundamental as it not only allowed the specification of trust leases, but also enabled
the start and termination of leases’ enforcement locally, without needing to rely on the two-party side TLP
negotiation. We also created several other demo applications that were used to test whether trust lease
restrictions could be broken (e.g., changing screen brightness, toggling camera led, enabling Bluetooth,
starting other apps), through Android API methods, i.e., no native code coverage. In this work we also
developed demo applications leveraging Android’s Native Development Kit (NDK) to use native code
through the Java Native Interface (JNI) or even through native executables. These apps were used
53
in network tests, to check whether trust leases, could prevent these low-level network accesses, and
in application lifecycle tests, to check whether secondary processes would remain running. This last
problem although not common, could bring tremendous security issues to the correct behaviour of our
strapps (e.g., a low-level process could provide a student with helpful information either from the Internet
or from files saved on the device). Although in Android, applications run all their components within a
single process thanks to its sandboxing mechanism, they are still able to start other processes, (e.g.,
launch a java.lang.Process to run a native executable). Because the Android middleware only keeps
track of the main process of an app, and not of those extra processes, when a user terminates an app,
Android does not terminate those processes as well. Even when the app is uninstalled, those processes
still remain active until the device is turned off. This means that, for instance, a student could leverage
this mechanism, to somehow provide him answers to his exam. So this app was fundamental in testing
whether trust leases could effectively avoid these situations.
4.3 Summary
In this chapter we start by presenting the implementation of the Strapp Middleware, focusing on the
secure channel establishment, and mode transition phases of TLP. We also present the API provided
by the Strapp Middleware to strapp developers, and discuss the implementation of this protocol on
the two communication technologies we addressed, i.e., network and NFC. Finally we describe the
implementation of the mExam, mMeeting and mTicket strapps, while referring the differences between
the initially idealized architecture and the actual implementation, and terminate by covering the servers
involved in these strapps’ scenarios, as well as the demo applications created to test trust leases.
54
Chapter 5
Evaluation
In this chapter, we present the evaluation methods conducted throughout this work, and corresponding
results. We start by presenting the effects of trust leases on real world applications (Section 5.1.1), and
on a real world spyware (Section 5.1.2). Afterwards, we evaluate the performance of TLP (Section 5.2),
focusing on the times of its two phases (i.e., secure channel establishment, and mode transition), both
on the network and NFC implementations. We also compare the performance differences between
Android’s SSL, and our Simplified SSL’s implementations. Additionally, and because we want to assess
whether our strapps are easy to use and useful, we first present the setup and results of our strapps’
usability tests (Section 5.3), and then, we conclude by presenting the results of our strapps’ adoption
study (Section 5.4). In Appendix E we provide a development complexity comparison, between the use
of trust leases, and the use of other available solutions to enforce restrictions, that clearly shows that
trust leases do ease strapp developers’ work.
For these tests, our hardware testbed consisted of two Nexus 4 smartphones, featuring a quad-core
1.5 GHz CPU, 2 GB of RAM, 16 GB of memory, 802.11 WiFi interface, 768 x 1280 display, a camera
with 8 MP, 3264 x 2448 pix, and a LED flash. Both devices were flashed with a build of Android 4.4.1
AOSP patched with TrUbi code. For communications, we used WiFi. The webserver used in conducting
the user tests featured a desktop computer housed in the author’s house.
5.1 Trust Lease Effects on Applications
To evaluate the effects of trust leases on real applications, we performed two studies: one using third
party applications downloaded from Google Play, and another using a real world piece of spyware [10],
already identified by a major anti-virus company. We now cover these studies’ methodology and results.
5.1.1 Real World Applications
Our application study aims to: (1) evaluate the effectiveness of the enforcement of trust leases on real
applications, and (2) study how such applications react when subjected to constraints while accessing
devices’ resources.
55
Methodology. To achieve our goals, we collected a test suite of unmodified real world applications and
observed the effects of restricting such applications using trust leases. In our experiments, we have to
contemplate three possible access patterns to resources that an application can perform:
• Access before lease (ABL) – an application starts accessing a resource, and a trust lease is
activated. Once the trust lease starts, access to the resource must be blocked.
• Access during lease (ADL) – the trust lease is active, and an app accesses a restricted resource.
Access must be denied.
• Access after lease (AAL) – an application has been previously restricted, and the trust lease
terminates. The application must be able to regain access to the resource.
For our test suite, we selected applications that perform operations that can be constrained by dif-
ferent trust lease restrictions: execution of applications (CPU), network, camera, phone call, SMS, mi-
crophone, sound, brightness, LED, and Bluetooth. To test each type of restriction, we use a mix of:
system apps from the vanilla Android distribution (e.g., System Camera), and third-party apps from the
Google Play app market [15]. We chose third-party apps that were popular and highly rated by March
2015. Each type of restriction was tested with 10 apps, except for the restrictions on: airplane mode,
time, and screenshot. The reason for not testing these restrictions with multiple apps is that they can
be triggered only through a limited set of entrypoints, such as the system settings app, a combination
of the power and volume down buttons, or through the Android Debug Bridge. In total, we collected 96
different third-party apps. Most of these apps were used to test a single type of restriction. However,
since Android has no specific permissions for constraining the execution of applications, we reused 9 of
these apps to test the CPU restriction. We executed our test suite for each of the patterns, ABL, ADL,
and AAL.
Findings. For all tested applications, trust leases were effective at enforcing the intended restrictions,
i.e., whenever a trust lease is active, applications have no access to the resources that are constrained
by the trust lease. Table 5.1 presents detailed information of our findings for: ABL, ADL, and AAL.
Table 5.2 provides some observations on those findings.
• Under ABL applications follow 3 policies: they either stop having access to the resource (policy
1), are killed (policy 2), or are frozen (policy 3). Policy 1 applies when TrUbi can intercept all
operations on a given resource performed by applications. Examples include the microphone or
the LED flash. In such cases every access is preceded by an access control decision that TrUbi
can control. In contrast, for resources where an access decision is made when the application
uses the resource for the first time only, TrUbi must kill the apps registered as being using those
resources, as it as no way of knowing whether these apps are still using them or not (policy 2).
This policy is implemented for 10 camera apps and 10 networking apps (see Table 5.1). For trust
leases that restrict app execution, freezing unauthorized apps is expected (policy 3).
56
Resource Test SuiteSize ABL ADL AAL
S 3 T B K F C I D L F R
CPUTed (2.3.6), SpeedTest (3.2.8), Spotify (2.6.0.813), Instagram(6.20.2), Color Flashlight (3.6.8), VC Roys (1.6.0), Textra SMS(2.32), ExDialer (191), VR Iovekara (1.2.28), System Camera
1 9 10 – – 10 – 10 – 10 – –
Network
Chrome (34.0.1847.114), Facebook Messenger (27.0.0.48.14),Facebook (32.0.0.23.15), Youtube (10.18.55), Instagram (6.20.2),
Skype (5.3.0.65524), Spotify (2.6.0.813), TeamViewer(10.0.2484), Ted (2.3.6), SpeedTest (3.2.8)
– 10 10 – 10 – 9 1 – 4 6 –
Camera
Google Camera (2.4.025), Camera HDR Studio (1.2.2), GeakCamera (0.29 beta), Open Camera (1.25), Camera for Android
(2.2), HD Camera Ultra (2.2.2), Retrica (2.4.2), HD Camera(4.4.2.3), High-Speed Camera (3.1.1), System Camera
1 9 10 – 10 – 10 – – – – 10
Phone Call
VR Splend (1.3.6), ZERO Dialer (1.01), Simpler Dialer (4.0),Truedialer (2.12), PP (3.9), True Phone Dialer (1.3.7), ExDialer
(191), Android L UI (4.0), RocketDial (3.8.6.1), Dialer One (2.2.0),System Caller
1 9 10 10 – – 10 – – 10 – –
SMS & MMSHandcent SMS (6.5.5), GO SMS Pro (6.24), ZERO SMS (1.2),
EvolveSMS (3.2.1), Easy SMS (3.6.0), hello sms (2.2.8), SMS KK(1.91), chomp SMS (6.46), Textra SMS (2.32), System Messaging
1 9 10 10 – – 10 – – 9 – 1
Microphone
Smart Voice Recorder (1.7.1), Voice changer (3.1.10), VRIovekara (1.2.28), ASR (36), Audio Recorder (1.00.28), VR Rabbit(1.6.0), Easy Voice Recorder (1.8.1), VR Korrisoft (1.9), QuickRec
(2.5.1b2), VR Splend (1.3.6)
– 10 10 10 – – 10 – – 9 – 1
Sound
Volume Controller (1.0), Volume Control + (1.44), Volume Butler(1.8.4), Volume Control Plus (3.3), Master Control Volume (1.2),
VC Clever (2.9), VC Simple (1.21), VC Firestorm (3.0.4), VC Roys(1.6.0), VC Widget (2.2.1)
– 10 10 10 – – 5 4 1 10 – –
Brightness
Screen Brightness Tool (1.3), Well Brightness (1.0), BrightnessLevel (2.2.0), Display brightness (4.7), Brightness Level Disc(1.8.2), ABC Brightness (3.8), Yet Another Auto Brightness
(1.10.1), LED Flashlight - Brightness Toggle Widget (1.0.4), StatusBrightness Free (2.8), Brightness Easy (2.0c)
– 10 10 10 – – 2 8 – 9 – 1
LED
Flashlight HD LED (1.79), DU Flashlight (1.08), Brightest LEDFlashlight (1.2.5), Flashlight - Torch LED Light (1.8.6),
Super-Bright LED Flashlight (1.0.6), Tiny Flashlight (5.2.4),Flashlight LED Genius (1.10.4), LED Flashlight - Torch (1.5), Color
Flashlight (3.6.8), Super-Bright LED Flashlight (1.0.6)
– 10 10 10 – – – 10 – – 10 –
Bluetooth
Bluetooth OnOff Toggle Widget (2.1), Bluetooth Switch and Mute(1.0.3), Quick Bluetooth Change (1.1.0), Bluetooth On/Off Widget
(1.5), One Tap Bluetooth Manager (1.0), Bluetooth Flick (1.4),Bluetooth Toggle Widget (1.0), Bluetooth Widget (2.0), Bluetooth
On/Off (1.0.1), Bluetooth Status Bar Switch (1.3)
– 10 10 10 – – 5 5 – 5 5 –
Total: 4 96 100 70 20 10 61 38 1 66 21 13
Legend: Size = test suite size (S = number of system apps, 3 = number of third-party apps, T = total number of apps); ABL = access before lease(B = access to resource blocked, K = app killed, F = app frozen); ADL = access during lease (C = app state and GUI consistent, I = app state andGUI inconsistent, D = app dies); AAL = access after lease (L = seamless access, F = requires refresh operation, R = requires app restart).
Table 5.1: Effects of trust leases on real mobile applications.
Observations
Access Before Lease(ABL)
(cpu) apps frozen; (network) apps killed; (camera) apps killed; (phone call) call terminated; (sms & mms) apps cannot send orreceive SMSs and MMSs; (microphone) apps get no input; (sound) apps cannot change sound stream settings; (brightness) appscannot change screen brightness; (led) apps cannot change LED state; (bluetooth) apps cannot enable bluetooth.
Access During Lease(ADL)
(cpu) apps cannot be launched, a toast is popped up: “App isn’t installed”; (network) 9 apps inform user that network is unavailable,1 app (Ted) allows users to select a video but the video is never buffered; (camera) 1 app (System Camera) shows black screen andtakes no photos, 9 apps terminate gracefully; (phone call) apps cannot make or receive calls; (sms & mms) apps cannot send orreceive SMSs and MMSs; (microphone) 1 app (VR Splend) notifies user about lack of input and terminates gracefully, 9 don’t notifythe user and tape silence; (sound) 1 app (Volume Control +) terminated abruptly, 4 apps changed their volume sliders incorrectly, 4apps allow the user to drag the volume slider but it returns to its original position, 1 app (VC Widget) prevents GUI updates;(brightness) 8 apps change their GUI widgets without reflecting the correct brightness level, 1 app (Screen Brightness Tool) preventsGUI changes, 1 app (Status Brightness Free) reports a problem that prevented the brightness level change, and terminates gracefully;(led) apps change their GUI widgets without reflecting the correct LED state; (bluetooth) 5 apps change their GUI widgets withoutreflecting the correct bluetooth state, 5 apps report a problem that prevented them from changing the bluetooth state.
Access After Lease(AAL)
(cpu) apps can execute again normally; (network) 6 apps require explicit refresh action by user, 4 apps automatically detect Internetconnection after a short period of time; (camera) apps can reuse the camera after requesting new access; (phone call) apps canmake and receive calls again; (sms & mms) 1 app (Textra SMS) cannot send SMS / MMS afterwards, 9 apps can again send orreceive SMSs and MMSs; (microphone) 9 apps can use the microphone again, 1 app must be restarted; (sound) apps can changesound stream settings again; (brightness) 9 apps can change the brightness level again, 1 app must be restarted; (led) apps canchange the LED state again, but the GUI button needs to be pressed in order to restore the consistency; (bluetooth) apps canchange the bluetooth state again, but 5 apps require GUI button presses in order to restore the consistency.
Others
(network) apps that automatically detect Internet connection take different times to restart the connection; (camera) blocking accessto the camera results in blocking access to the LED as well; (sms & mms) the single app that can’t send is the only that resends themessages when restarted; (led) when access to the LED is blocked, some apps try to use the device screen instead; (airplanemode) since Jelly Bean, airplane mode is configurable through the system settings app only; (set time) only configurable throughtsystem settings app.
Table 5.2: Observed behavior when testing trust leases on real mobile applications.
• Under ADL different apps react differently to the revocation of their resource / functionalities they
need. For example, for the camera, 9 out of 10 apps terminate gracefully (see Table 5.2); a single
57
app remains executing, but shows a black screen to the user, and no photos can be taken. In other
cases, applications provide different outputs to the user. For example, regarding the microphone,
9 apps tape silence, while a single app notifies the user about the lack of input.
Note that when applications are denied access to a particular resource, side-effects can occur
affecting the consistency between the app’s internal state and its visual interface (GUI). In 38
apps, we observed such inconsistencies. For example, if the user turns on the Bluetooth and a
lease restricting the Bluetooth is active, an application will misleadingly show the Bluetooth status
as enabled. In contrast, 61 apps update their visual interfaces consistently. For instance, all phone
dialer apps refresh their GUI properly by disabling calls. Apps not allowed to run are considered
inconsistent, because their state is frozen. Under ADL, one application crashed because of a null
pointer exception.
• Under AAL, in most cases, applications seamlessly regain access to a resource (in 66 out of 100
tests, as we can see on Table 5.1). In other cases, however, the user must perform some manual
operation to “refresh” the GUI, e.g., by pressing the back button and restarting an application
activity. A refresh operation is required by 21 apps. For instance, 6 apps require an explicit refresh
action by user, in order to detect Internet connection availability. In more extreme cases, apps must
be entirely restarted. This occurs in 13 cases: 10 camera apps, and 3 apps handling microphone,
brightness, and SMS.
In terms of the overhead introduced by these restrictions, although we did not measure it, we can say
it is negligible to the user, and base our statement on the results gathered by the creators of ASM [57],
the system on top of which TrUbi was created. These results show, that in terms of time overhead,
the heavier ASM hooks introduce in the worst case a 14ms overhead. In our opinion, this penalty is
reasonable, and hence we consider the overall performance overhead introduced by these restrictions
as acceptable. In conclusion, current Android APIs lead to the development of applications that suffer
from state inconsistencies, when certain restrictions are applied to their resources / functionalities of
need. This issue could be mitigated by modifying some of Android’s APIs to better support the trust
lease model.
5.1.2 Real-World Malware / Spyware
Inspired by the mMeeting use case, we wanted to test if trust leases’ capability to restrict access to
resources can effectively mitigate real-world spyware. With this in mind, we tested the effectiveness
of trust leases with the Dendroid trojan horse [10], which exhibits bot-like capabilities, a very common
type of spyware running in the wild [94]. It consists of a seemingly inoffensive Android application that
periodically connects to a remote web server listening for specific commands, which enable an attacker
to stealthily execute operations on the victim’s phone: record audio, take pictures, make phone calls,
control sound volume, open web pages, launch apps, and access private information, such as contacts,
text messages, and personal files. We created leases and observed that they prevented Dendroid’s
58
Trust Lease Protocol Times
SEC phase MT phase Total
NetworkTime 0.32s ± 0.04 0.78s ± 0.07 1.10s ± 0.09
Percentage 29.09% 70.91% 100%
Round Trips 2 4 6
NFCTime 0.70s ± 0.05 0.89s ± 0.05 1.59s ± 0.06
Percentage 44.03% 55.97% 100%
Round Trips 8 11 19
Table 5.3: Performance of trust lease protocol (50 test average).
malicious activities by blocking access to sensitive resources, preventing communication with the server,
or suspending Dendroid’s processes.
5.2 Trust Lease Protocol Performance
Given the importance and potential impact of the trust lease protocol to strapp’s performance, we mea-
sured its execution time. The measurements were conducted for both network (i.e., WiFi) and NFC
communication. For benchmarking purposes, the lease terms were accepted instantaneously, i.e., the
validateLessorId() method on the lessee side returns true automatically.
Table 5.3 shows the total execution time for each setup: 1.1 and 1.59 seconds for network and NFC,
respectively. To better understand these numbers, we break them down into two constituent parcels:
secure channel establishment (SEC) and mode transition (MT) phases. As described in Section 3.2.1,
SEC is the first phase of TLP, which takes 2 round trips to execute over network communication, and
8 round trips over NFC. This difference relates to the need of breaking the high-level messages into
the shorter TLP APDU messages. The results show that this need leads to a performance penalty,
where NFC takes over two times longer to complete the SEC phase, when compared with network. The
difference between the number of round-trips and performance is not linear, because NFC’s latency is
lower than the network’s.
MT ensues the SEC phase and comprises 4 round trips to execute over network, and 11 round trips
over NFC. In this case, the results from the table show that the time difference between network and
NFC are shorter, when compared to the ones from SEC, due to the smaller difference of the round trips
involved. Additionally, Table 5.3 shows that while SEC takes about 29% of the total time of the network
implementation, it takes 44% of the NFC’s total time. The reason behind this difference is the connection
setup time, which is higher for NFC, but also because of the difference in the number of round trips, i.e.,
2 - 4 for network, and 8 - 11 for NFC.
SSL Comparison Following the issues we described in Section 4.1.1, we also measured the hand-
shake execution times of both the Simplified and Android’s SSL implementations. Figure 5.1 shows the
execution times with different certificate and private key sizes. As we can see, even with a 1024 bit key,
Android’s SSL implementation takes over 1.5 seconds to complete the SSL handshake, an amount of
59
0
500
1000
1500
2000
2500
Android SSL Implementation Simplified SSL
1024 bit keys
2048 bit keys
4096 bit keysTim
e (
ms)
Figure 5.1: SSL performance comparison (50 test average).
time that is beyond acceptable in our opinion. In fact, Android’s SSL handshake takes 0.4 seconds more
than our TLP implementation over network communication, which comprises not only the secure chan-
nel establishment phase but also the transition to restricted mode, which features multiple OS system
calls. On the other hand, the Simplified SSL implementation takes 850 milliseconds in the worst case,
i.e., using 4096 bit keys. Note however, that the level of security between the two implementations is
incomparable, as we previously explained in Section 3.2.
5.3 Use Case Strapp User Tests
In order to evaluate whether our strapps are effective in supporting their corresponding scenarios, and
also to assess how trust leases would be received and handled by real users, we conducted usability
tests with potential strapp users. In this section we first explain our overall usability test methodology,
and then, for each scenario, present the test structure, and corresponding result analysis.
5.3.1 Methodology
In order to perform usability testing, we need to follow an adequate methodology. In conducting these
kinds of tests, two types of methods are normally adopted: formative and / or summative [59]. Formative
usability testing is usually done during the initial steps of a product’s design, and it contributes to a more
solid iterative design process, because of the rich and continuous potential users’ feedback. These tests
are executed repeatedly from the start, normally even with paper-prototypes, and they are essential
in providing insights about the difficulties users have in reaching their goals with the technology or
service. Summative usability testing, on the other hand, is usually performed during the latter half of
the development phase, where there are already working prototypes. This test is more of a Quality
Assurance (QA) type of test, which produces numerical results, such as task times, completion rates
and satisfaction scores. Overall, this method is used to perform formal user acceptance testing before
the product is released to the markets.
Formative usability testing has been shown to find 33% of usability problems with one user, 85% of
problems with five users, and 99% of problems with three sets of five user tests [59]. Given the relatively
simple tasks and UI interactions our strapps involve, and considering the lack of time we had, and the
difficulty of finding users for iterative usability testing, we opted to rely on summative testing to evaluate
our strapps’ usability. Another strong reason for this choice is that summative usability testing has been
60
shown to be able to provide strong results with ten users only.
After choosing our user usability testing approach, we need to specify an additional set of character-
istics: (1) goal of the test, (2), location of the test, (3) duration of the test, (4) necessary equipment
to run the test, (5) who are the users, (6) initial test support, (7) initial testing state, (8) which are
the tasks, (9) what are the measures we are interested in collecting, (10) success criteria for each
task, and (11) correct ending criteria for each task. We now present the test characteristics that are
common to the three strapp scenarios, and then, we present, for each strapp, specific scenario test
characteristics. In the following sections we present, for each scenario, the findings gathered from each
test set, following the methodology previously described.
Strapp User Test Characteristics There are some similarities between each of the three scenarios’
test characteristics. On one hand, these tests had a maximum duration of 20 minutes. In terms of
data collection, we essentially wanted to understand whether users had trouble using the apps (e.g.,
whether they went back and forth through the menus to complete a task), and if they could correctly ex-
ecute the proposed tasks. On the other hand, we also wanted to check whether the trust lease primitive
was effective in securing the different scenarios, i.e., prevent access to exam answers, prevent sensitive
information leaks, and prevent movie audience disturbances. In order to do so, we asked users to per-
form certain scenario specific tasks, and at the end of each task, users were then asked between three
to five task-related questions orally. These questions usually feature Likert scale [17] questions, i.e., a
ranking between 1 and 5. We considered the test successful, if the trust lease was effective in secur-
ing the scenario, and if users could correctly execute the tasks that did not involve accessing resources
during the enforcement of the lease. In these tests, we were not particularly interested in measuring the
performance of the apps’ UI. Still we focused in detecting interactions that could introduce perceivable
UI delays, capable of negatively impacting the user’s experience. Finally we considered users’ device
transitions back to unrestricted mode as the correct ending criteria for the different scenarios. After the
tasks were completed, users where then presented with a nine question overall interview on the app.
In terms of result analysis, we start each scenarios’ findings section by analysing the first tasks
in terms of their easiness, intuitiveness and responsiveness. Then we analyse the tasks that involve
accessing device resources, to assess whether users associate the restrictions to trust leases, and to
understand how important would restriction notifications be for users. We then analyse each scenario’s
last task, which usually involves the termination of the lease, to see if users notice that same termination.
Additionally, we analyse the sub-task of accepting the lease terms, to see how perceptible do users feel
these conditions are. To conclude, we analyse the overall interview questions we asked on matters such
as privacy and comfort of the trust lease model.
mExam Specific User Test Characteristics The goal of mExam’s usability tests is to check whether
students can start an exam (i.e., by identifying themselves, and accepting lease terms), receive an
exam statement, and during the exam cannot use their devices to access the Internet or use other
communication channels, or applications, to reach information that could help them in answering exam
61
questions. These tests took place at INESC-ID, and required the use of two smartphones.
The user test population features volunteer computer science and biomedical engineering students
from IST and UNL. More specifically, the population featured 10 users between the ages of 21 to 25 years
old, where 7 were male and 3 female. Out of the 10 users, 2 had completed a master’s degree, and 8
had completed a bachelor’s degree. In terms of mobile proficiency, users have basic skills, in particular
4 know how to can send / receive texts and phone calls, install applications, and manage smartphone
disk space. Because 6 users had a computer science degree, they can additionally program mobile
applications. Initially, we planned to conduct these tests also in a secondary school, but bureaucracy
got in the way of our plans, and we ran out of time to do so. While our test population could have been
more diverse, the fact that it features different level of mobile proficient users, leads to a reasonable
representation of students in general.
While this scenario features a professor side and a student side, we focused these tests solely on
the student side, and the author played the part of the professor in the tasks’ interactions. Before the
beginning of the tests, students were presented with the mobile device, and had a period of 2 minutes
to familiarize themselves with it. The initial state of the test environment featured two mobile devices
flashed with TrUbi, with both in unrestricted mode. Additionally, the student’s device had the mExam
strapp installed, and the professor’s device had the professor mExam strapp installed as well. During
the test, students were asked to complete four simple tasks: (1) enroll in an exam, (2) begin an exam,
(3) try to access answers inadvertently, and (4) submit their exam.
mMeeting Specific User Test Characteristics The goal of mMeeting’s usability tests is to check
whether meeting attendants can start a meeting where attendants cannot use their devices to leak
meeting sensitive data. These tests took place at INESC-ID, Beta-i (an organization that promotes
entrepreneurship), and at Caixa Geral de Depositos (CGD), and required the use of two smartphones.
The user test population for this scenario features former colleagues already employed and also
some of their work colleagues. Initially, we planned to conduct these tests in a local technological
center. Unfortunately, when contacting the companies of this center by telephone, to explain the trust
lease primitive, and to ask for their availability for these tests, they shown no interest. On one hand,
they said they feared no meeting information leaks. On the other hand, even though we clearly stated
the proof-of-concept nature of this work, we were frequently mistaken for someone who was trying to
sell a product, which also difficulted the task of convincing these companies to accept to conduct these
tests. These difficulties, and the lack of time were the base for our decision to conduct these tests
on former colleagues and their work colleagues. Still, because of the difficulties in finding enough
users for these tests, the population for the mMeeting test features 5 users, instead of the 10 users of
the mExam and mTicket tests. More specifically, the population features 5 users between the ages of
24 and 53 years old, where 3 were male and 2 were female. Out of the 5 users, 3 had completed a
master’s degree, and 2 had completed a bachelor’s degree. All these degrees were in engineering. In
terms of mobile proficiency, 4 can send / receive texts and phone calls, install applications, and manage
smartphone disk space. The other user can additionally program mobile applications.
62
Before the beginning of the tests, meeting attendants were presented with the mobile device, and
had a period of 5 minutes to understand how to record audio, open a webpage, place a phone call, and
send a text message. The initial state of the test environment featured two mobile devices flashed with
TrUbi; both in unrestricted mode; the attendant’s device had the microphone, system browser, system
dialer, system text message apps, and the mMeeting strapp installed. The meeting host’s device had
the mMeeting strapp installed. At the end of each task, attendants were asked three to five task-related
questions orally. Similarly to mExam, this scenario also features two sides (i.e, host and attendant), but
these tests were solely focused on attendants’ side, and the author played the part of the host in the
tasks’ interactions. During the test, meeting attendants were asked to complete six simple tasks: (1) join
a meeting, (2) record audio, (3) open a web page, (4) place a phone call, (5) send a text message, and
(6) leave the meeting. Additionally, attendants were also presented with the remote attestation process.
mTicket Specific User Test Characteristics The goal of mTicket’s usability tests is to check whether
users can acquire a ticket, enter a movie theater with said ticket, and confirm that inside the theater
they cannot use the camera, or change the device’s volume and brightness. Because this scenario
mimics a movie theatre interaction, the test had to be conducted in a controlled environment. For this
reason, these mTicket tests were conducted in two residential buildings, and required the use of a
mobile device, an NFC reader connected to a computer with an Internet connection, and an additional
smartphone to be used as a wireless access point.
For the user test population, we targeted neighbour family elements and friends of friends, with
good mobile proficiency. More specifically, the population consisted of 10 users between the ages of 14
and 45 years old, where 5 were male and the other five, female. Out of the 10 users, 3 had completed a
master’s degree, 4 had completed a bachelor’s degree, 2 were in high school, and 1 was a middle school
senior. The college educated users graduated in diverse areas such as engineering, law, humanities,
business management and geology. In terms of mobile proficiency, 9 can send / receive texts and phone
calls, install applications, and manage smartphone disk space. The other user can additionally program
mobile applications.
Before the beginning of the tests, users were presented with the mobile device, and had a period
of 2 minutes to understand how to change the device’s volume and brightness, and to take a photo.
The initial state of the test environment featured a mobile device flashed with TrUbi, in unrestricted
mode. The device’s brightness and volume were set to their maximum values; the camera was in an
operational state; the system camera app and mTicket strapp were installed; and there were no tickets
previously stored on the device. Additionally, the initial test state also included an NFC reader attached
to a laptop computer with an Internet connection, as well as an additional mobile device that was used
as WiFi hotspot, to mimic the movie theater’s WiFi access point. During the test, users were asked to
perform six small tasks: (1) buy a movie ticket, (2) enter the movie room, i.e., by connecting the mobile
device to the NFC reader in order to receive and accept the lease’s terms, (3) take a photo, (4) change
device’s brightness (5) change device’s volume, and (6) leave movie room, which was mimicked by the
disconnection of the access point.
63
012345
Enroll in exam Begin exam
Easiness
Intuitiveness
ResponsivenessLike
rtSc
ale
Figure 5.2: mExam ease of use, intuitiveness and responsiveness user evaluation (10 test average).
5.3.2 mExam Findings
In this section we start by analysing the results of the first and more complex tasks. Then, we analyse the
resource access and lease termination task results. Afterwards we cover the lease terms’ perceptability
results, as well as the feedback given by users in the overall interview. As we have said, the first two tasks
were to enroll in an exam, and to begin that exam. Figure 5.2 shows us the users’ perceptions, (average
on a Likert scale), on the easiness of concluding these tasks, the intuitiveness of executing each task
with the strapp, and on the responsiveness of the strapp in performing each task. The 10 users ranked
the responsiveness of the strapp in executing the enrollment task with the option 5, i.e., very responsive.
In term of easiness, and intuitiveness, two users ranked the task with a 4, in each category respectively.
These ranks stemmed from a UI problem, as some users struggled with hiding the keyboard to press
the ok button, when they were logging in the strapp, but most of them did so, because they were used
to other MOSes or different Android versions. Moreover, 2 users expected the enter button to act as the
ok button. Additionally, one user felt the exam start button should only appear after the enrollment on
the exam had been completed. In the begin exam task, 7 users ranked the easiness of the task with 5,
2 users ranked it with a 4, and another user ranked it with 3. These lower ranks had to do with the need
to connect the devices through NFC, which according to some users could have been replaced by other
methods (e.g., WiFi). In terms of intuitiveness, two users ranked it with a 4, as they felt the appearance
of the exam statement and the “exam retrieved from the server” message were not enough for them to
understand that the enforcement of the lease had begun. Regarding responsiveness, all users ranked
the strapp with a 5.
In the third task, we asked users to try to access answers inadvertently. After confirming they could
not, we asked them some questions. No user was bothered by the fact that they could not change most
settings. In fact, all of them said the only setting they would consider changing during an exam would be
the brightness, which we allow. Still, there was one user who felt that it should not be possible to change
the brightness, as it could be used by students as a side-channel to cheat (e.g., by changing brightness
to the maximum value, meaning yes to an answer). In terms of the usefulness of a popup reminding
users they could not change settings because they were in an exam, the opinions were very different.
While 3 users felt the popup would be unnecessary, has they felt it was implicit the settings could not
change because of the exam, 3 felt it could help, and 4 felt it was necessary. Additionally, we asked
users whether the impossibility of exiting the strapp to the main menu during the exam was a problem,
and all users agreed it was not. Four users said it was better this way, because they could accidentally
press the home button during the test. One user said that if we wanted to abort the exam, this would be
64
a problem, because he might want to browse the web or access social media apps or even games. In
fact, although we did not had the abort button, it would be basically the same as submitting the exam,
which would return the full control of the device back to the user.
In the submit exam task, 4 users felt the “exam terminated” popup was not enough to understand
that the restrictions’ enforcement had finished. They suggested a message with an acknowledgment
button or a more explicit message. The other 6 users felt it was enough, but 2 were confused with the
fact that after the exam submission, the app returns to the exam list screen. One user said that after the
exam submission the app should close, while the other user said the start exam button should disappear
when returning to this screen.
In terms of perceptiveness of the lease conditions, displayed when beginning the exam, 5 users
felt they were easily perceptible (4 on a Likert scale), while the other 5 users felt they were reason-
ably perceptible (3 on a Likert scale). Overall, users were confused with the lease conditions. The
“required” field, which is used to indicate that no app can break these restrictions, caused some confu-
sion. Additionally the “there are no geographical restrictions” message, which means there are no GPS
coordinate-based termination conditions on the lease, increased users confusion. Users generally felt
that there should be less text, the non-vital information (e.g., no geographical restrictions) should be re-
moved, and the images should perhaps be smaller. One user did not associated the keyword “Runtime”
with the execution of apps, and two other users said that instead of the apps’ package names, the names
of the apps should be presented instead. On the other hand, some users felt the language should be
simpler, and better adapted to the scenario, and not so general. This problem stems from the fact that
the information displayed when presenting lease conditions is the responsibility of a system app. We
leave a better integration between the scenarios and said system app for future work.
In the overall interview, users gave feedback on many subjects. On the one hand, users felt the app
was easy to use and responsive. In terms of intuitiveness, the biggest problems were on the lease
conditions’ information, where there was non-important information displayed, that ended up confusing
users. In general, users were fully aware of when the restrictions were being enforced, but one user
felt a menu notification could be helpful. All users would adopt the app, but one admitted she saw no
big advantage for students. In terms of privacy, the restrictions did not seem to bother users (average
of 1.8 on a Likert scale, meaning a little worried), as they generally felt the restrictions were for their
own benefit. Regarding the possibility of a professor trying to restrict more than he should, users were
equally very little worried (average of 1.6). In general, users did not believe it would be distracting to
answer an exam in their smartphones, with only 2 users saying it would be strange the first time. In
terms of comfort, 4 users said it would not be possible to answer a 90 minute test in their smartphones.
One user said it depended on the design of the app, another on the size of the screen, and the remaining
users said it would not be a problem. Generally, users agreed the app would be better for small text and
multiple-choice questions, and difficult for long texts and answer involving math. Still some users said
that with a tablet and pen, the math questions could be easily answered, and the long text questions
could be equally easily answered, as users would even be able to type with both hands.
65
012345
Join meeting
Easiness
Intuitiveness
Responsiveness
Like
rtSc
ale
Figure 5.3: mMeeting ease of use, intuitiveness and responsiveness user evaluation (10 test average).
5.3.3 mMeeting Findings
The first task that users had to do was to join a meeting. Figure 5.3 shows us the users’ perceptions,
(average on a Likert scale), on the easiness, intuitiveness, and responsiveness of the strapp in per-
forming the task. The 10 users ranked the intuitiveness of the strapp in executing the first task with the
option 5, i.e., very intuitive. In terms of easiness, two users ranked the task with a 4, as they thought
that there was too much information for them to read, before accepting the lease conditions. Regarding
responsiveness, and because we suffered a minor network problem, 1 user ranked our app with a 4.
In terms of UI, similar to the mExam test, some users struggled with the keyboard. After accepting the
lease terms, the strapp shows a “have a nice meeting” popup. From the 5 users, 3 felt it was enough for
them to understand the restrictions were now active, 1 felt the message should be clearer, and 1 did not
even see the popup. Still, all 5 users agreed, that after accepting the conditions it was implicit that the
enforcement of the restrictions would begin.
In terms of the resource access related tasks (e.g., record audio, send text message), users con-
firmed that they could not access the resources during the meeting. In the second task, users were
asked to record audio. From the 5 users, 4 admitted they did not realized the microphone app was not
recording, which they could have noticed if they had looked at the static sound spectrogram, displayed
by the app. In the second task, users had to open a webpage. All 5 users associated the lack of network
availability with the lease restrictions. Still, because the browser displays a default network connectivity
problem, 4 users admitted that if they were in a meeting for a long time, they may not remember the
restrictions and they might associate the message with a normal connectivity issue, rather than with the
lease restrictions. In the third task, users had to place a phone call. Because the system dialer app
simply does not react when the user presses the call button, 4 out of the 5 users said they would not
associate the inability of placing phone calls with the lease restrictions. In fact because of this behaviour,
these 4 users might be inclined to assume there was something wrong with the dialer app. In the forth
task, users had to send a text message. Similar to the dialer app, the system message app, also con-
fused users, because when the user sends a text, the app displays it with the state “sending”, and it
does not change while the lease is being enforced. None of the users associated the “sending” infor-
mation with the lease restrictions. Actually, users associated that information with a network problem,
or even with a problem with the message app. Figure 5.4 gives us users’ opinions on the usefulness
of restriction popups. As we can see, users felt that popups informing the users of the restrictions to
be very important. In the record audio task, users felt that a popup should appear when they pressed
the record button. In the open webpage task, users felt that a popup could be much more important
66
012345
Record audio Open webpage Place phone call Send text
Popup NotificationUsefullness
Like
rtSc
ale
Figure 5.4: mMeeting restriction popup usefulness (5 test average).
than the browser’s no connectivity message. In the place phone call and send text apps, because of
the misleading behaviours, users felt it was even more important for popups to appear signaling why
the operations could not be completed. In the send text task, the popups were described by 2 users as
crucial, because they admitted they do not look at the message state information. This means that in a
real situation, they would just assume that the text was sent, while in reality the lease prevented it.
In the last task, users were asked to exit the meeting, and terminating the lease. From the 5 users, 2
felt the “lease terminated” message was not enough for them to understand that the lease had ceased
its effect. In fact, one user preferred a more detailed message, while the other preferred a confirmation
popup, where the user had to press an acknowledge button.
Regarding the lease conditions’ perceptibility, 3 users felt they were easily perceptible (4 on Likert
scale), 1 felt they were easily perceptible (3 on Likert scale), and the other user felt they were hard
to perceive (2 on Likert scale). Again, in this test, users felt confused with the conditions presented.
Similarly to the mExam test, they were confused with the “required” field, and with the “there are no
geographical restrictions” message. The user that ranked the conditions’ perceptibility as hard to per-
ceive (experienced app developer), justified his rank with the use of package names instead of the apps’
names, which according to him could be extremely confusing for users. Additionally, users felt there was
too much text, and two admitted they would not read the terms before accepting them.
Overall, users felt the strapp was easy to use and intuitive. In terms of the lease conditions, users
generally agreed that less text would make the conditions clearer to users. Regarding the lifetime of the
restrictions, all 5 users clearly understood when they begun and when they ended. When asked if they
would adopt such a strapp, all 5 users said they would. Still, one user stated that in a normal colleague
meeting the strapp would be too “paranoid”, and for client meetings it would probably not make sense
to make clients use the mechanism. On the other hand, this user concluded the strapp would be good
for more sensible areas of work. Regarding the restrictions, users generally had no concerns (1 on a
Likert scale), or had very little concerns (2 on a Likert scale) regarding a host imposing restrictions on
their devices. In terms of privacy, and more specifically to the possibility of a host to restrict more that
he should, 3 users shown big concerns (4 and 5 on a Likert scale), while the remaining shown little to
no concerns (2 and 1 on a Likert scale, respectively).
Before the last task, where users were asked to leave the meeting, users were presented with the at-
testation mechanism, in which the host attests the attendant’s device. After the task, users saw that now
that their devices were in unrestricted mode, the host could detect that their devices were unrestricted.
Regarding this mechanism, we first asked users if they found it intrusive. From the 5 users, 3 did not
find it intrusive at all. The other two on the other hand, found the mechanism extremely intrusive, but
67
012345
Buy ticket Enter movie room
Easiness
Intuitiveness
ResponsivenessLike
rtSc
ale
Figure 5.5: mTicket ease of use, intuitiveness and responsiveness user evaluation (10 test average).
understood that it was for the greater good of the meeting’s security. Additionally, from the 5 users, only
1 felt uncomfortable about using the strapp because of this attestation mechanism.
5.3.4 mTicket Findings
The first two tasks that users had to do were the acquisition of the ticket, and then the entrance in the
movie room. Figure 5.5 shows us the users’ perceptions, (average on a Likert scale), on the easiness of
concluding each task, the intuitiveness of executing each task with the strapp, and on the responsiveness
of the strapp in performing each task. The 10 users ranked the easiness and responsiveness of the
strapp in executing the first task with the option 5, i.e., very easy and very responsive, respectively. In
terms of intuitiveness, two users ranked the task with a 4, as they thought that additional information on
the movie (e.g., session, room) should be provided, when acquiring the ticket. In terms of UI, similar to
the mExam test, some users struggled with the keyboard. Moreover, 3 users expected the enter button
to act as the ok button. In the enter movie room task, 9 users ranked it as very easy, while 1 ranked
as easy. Additionally, 4 users ranked it very intuitive, 1 ranked it intuitive, and 5 ranked it reasonably
intuitive.
The biggest reason behind these numbers is the lack of information on the interaction a user must
have with his device and the NFC reader, i.e., when they clicked the “use ticket” button, they expected
a popup to tell them to put their devices in range of the reader. Additionally, they did not know that
the device should stay in range of the reader, while they scrolled down through the lease conditions
to accept them, before removing the device. Furthermore, 3 users felt the “enjoy your movie” popup
was not enough for them to understand that the ticked had been validated, and that the restrictions had
started being enforced. In one of the tests we experienced network connectivity issues on the computer,
which lead to a “ticket validation failed” popup in the mobile device’s screen. In this case, the user felt
that a popup should additionally say that in order to proceed, the device should be removed and again
placed in range of the reader, which for him was not implicit. Moreover, while 8 users ranked the strapp
very responsive in executing the task, 2 users ranked it with a 4, as they believed the time spent on the
interaction between the device and the NFC reader, could be smaller. In terms of UI, 1 user felt the “use
ticket” button should be visible in the ticket.
In terms of the resource access related tasks (e.g., take photo, change brightness), users confirmed
that they could not access the resources, while inside the movie theater. An interesting detail of these
tasks was the fact that out of the 10 users, only 5 users changed the volume from the settings menu,
while the others did not bother, and did it solely though the physical buttons. Out of the 10 users, 3
68
012345
Take photo Change brightness Change Volume
Popup NotificationUsefullness
Like
rtSc
ale
Figure 5.6: mTicket restriction popup usefulness (10 test average).
did not automatically associated the black screen of the camera (first resource access task), with the
restrictions they had previously accepted. On the other hand, even though we prevent the volume and
brightness to change, users can still use a slider that in practice as no effect on these two settings. Out
of the 10 users, 6 found the ability to move the slider confusing, and out of those 6, 3 felt that it would be
better if the sliders could not move during a lease, while the other three thought that by preventing the
sliders from moving, users may feel that their devices are broken. Figure 5.6 gives us additional insights
on the usefulness of restriction popups. As we can see, users fairly ranked the usefulness of popups to
the three operations they were asked to perform, i.e., they felt that popus such as “you cannot access
the camera because you are in a movie room” to be in between 3 (needed) to 4 (important). Still they
felt that this type of popups for the camera and volume were more important than for the brightness,
because the camera app showed a black screen, and because the physical volume buttons produced
no UI effects.
Regarding the last task, in which users simply had to leave the access point’s range (mimicked by
turning off the other smartphone’s WiFi hotspot), 1 user ranked the time it took for the device to return
to unrestricted mode with a 5 (extremely satisfactory), 7 ranked it with a 4 (very satisfactory), while 1
user ranked with a 3 (satisfactory), and another with a 2 (unsatisfactory). These two last users claimed
that when they leave a movie room, they immediately check the time, or go to Instagram or other social
media apps, and that the low brightness affects the visibility when doing those tasks.
In terms of lease conditions’ perceptibility, 1 user felt they were very perceptible, 2 felt they were easily
perceptible, while 7 users felt they were reasonably perceptible. Again in this test, users felt confused
with the conditions presented. Similarly to the mExam test, they were confused with the “required” field,
and with the “there are no geographical restrictions” message. Additionally, users felt there should be
less text and it should be more user-friendly, the non-vital information (e.g., no geographical restrictions)
should be removed, and the images should perhaps have the prohibited sign over the resources. One
user argued that the display of the resources’ images would be enough information to present to users.
In the overall interview, users again gave feedback on many subjects. On one hand, users felt the
strapp was easy to use and intuitive. Besides the intuitiveness ranks given in the two first tasks, users
said that the confusion of not knowing exactly what to do also stemmed from the fact that they had
never used the strapp. In terms of the lease conditions, users generally concluded that simpler menus
with less text and clearer information could improve users’ experience. While some users understood
the restrictions’ lifetime, 2 users felt there should be some kind of notification system like a lockscreen
notification or even a menu notification, so that users could remember that their devices were locked.
One of those users, even said that there should be a notification that showed a timer to the end of the
69
restrictions. All 10 users said they would adopt the strapp, and while 1 said the ease of payment
(which in reality would be harder) was an additional incentive, another user said that he would adopt the
strapp more for the ease of buying / using movie tickets, rather than by the restrictions it provided. That
same user also felt that after accepting a lease for the first time, leases should be automatically accepted
whenever the user entered a movie theater, and that users should have a way do terminate leases
whenever they pleased. In terms of privacy, all 10 users said they had no privacy issues about allowing
a movie theater company restrict these resources during a movie. Additionally, and after explaining
that in order for one of these companies to restrict additional resources, those restrictions should be
accepted by the user when validating a ticket, users showed no fear in having one of these companies
restrict more than what they should.
5.3.5 Summary of User Test Findings
Due to the relatively simple menus and interactions required by users to complete the tasks we defined
for the tests, users generally found the strapps intuitive and easy to use. The trust lease primitive proved
to be effective in keeping the scenarios safe, i.e., they prevented users from accessing unauthorized
resources, and from running unauthorized apps. In general, the biggest criticisms had to do with the
lease conditions, which according to the users, had to much or not clear enough information, which
caused confusion. Additionally, the lack of system notifications capable of informing the user about the
reasons behind the inability to perform certain actions, was also called to our attention. In general,
users understood the benefits of these strapps, and although some shown privacy concerns about the
restrictions imposed, they generally would adopt these strapps.
5.4 Strapp Adoption Study
Despite studying the effects of trust leases, and showing their benefits and effectiveness in supporting
scenarios currently unsupported by MOSes, we are also interested in getting a clearer perspective on
the openness of real users in adopting a system and applications that could offer the functionalities we
propose in this work. With that goal in mind, we developed a set of six adoption questionnaires, for the
six different types of entities involved in our three scenarios: students, professors, meeting organizers,
meeting attendants, movie spectators, and movie theater managers.
Because this study is focused in gathering users’ adoption opinions, we present, for each of the
lessors (i.e., students, meeting attendants, and movie spectators), the structure and conclusions we
took from these questionnaires. We start by presenting the methodologies for these tests, and then
present the results for each scenario. In Appendix D we present the questionnaires for lessees.
5.4.1 Methodology
The three scenarios’ questionnaires are divided into five groups: (1) Demographics, (2) Device Popula-
tion, (3) Mobile Security, (4) Institution’s Trust, and (5) Trust Lease Intrusiveness.
70
In the Demographics group, we seek to characterize the respondent. To do so, we ask general ques-
tions such as age, gender, and mobile proficiency (e.g., ask if the respondent can install apps, or create
apps). In the Device Population group, we try to characterize respondents’ devices. We ask respondents
how many smartphones do they have, and under which MOSes do they operate. Additionally, we also
ask where did they bought their smartphones from, if they are under costumer retention periods, and
if they are protected from deficiencies and accidents by warranty or insurance. In the Mobile Security
group, we try to understand how respondents interact with apps and their MOS, but also their privacy
fears, and their thoughts on the possibility of replacing their MOS. In this group we ask respondents
questions such as, how they deal with permissions when installing an app; how worried are they about
possible personal information and location leaks from their apps; if they consider changing their MOS;
what they would look for in a MOS replacement; if they changed MOSes if it meant breaking the device’s
warranty; if they would adopt a MOS that would offer perks in return of restrictions; and how comfortable
would they feel about that MOS being capable of restricting several device resources. The remaining
groups differ from scenario to scenario.
mExam – Students Questionnaire Methodology In the mExam Institution’s Trust group, we try to
understand whether students would adopt an app like mExam. We start by asking whether they would
adopt an app with which they could perform school related tasks (e.g., enroll in tests), and then we ask
if they would adopt an app that allowed them to answer exams using their devices. We then move on
to more practicality kind of questions, such as, if they think there is much difference between answering
an exam in pen and paper than there is in answering an exam in a smartphone; if they would feel
more comfortable in answering an exam in a smartphone; and if they feared a device malfunction could
compromise their exams. To conclude the group, we ask students whether an app such as mExam would
bring new ways for students to cheat. In the last group, we seek to understand students’ perceptions on
the intrusiveness of the trust lease primitive. We start by asking how comfortable would they feel about
allowing a professor to restrict some of their smartphones’ functionalities during a test; if it seemed fair,
for professors to hold that power; if there were big differences between trust leases and what happens
today (e.g., professor tells students he only wants a pen on top of the table and phones turned off); how
worried would they be about a professor trying to circumvent the system to access their private data;
and how compelled would students feel about trying to break the app to cheat.
These questionnaires were conducted online, and respondents were recruited in INESC-ID and RNL.
mMeeting – Meeting Attendants Questionnaire Methodology In the mMeeting Institution’s Trust
group, we try to understand how meeting attendants perceive the relationship between meetings and
mobile devices, as well as their thoughts about adopting an app like mMeeting. We start by asking if
they have regular meetings at work (i.e., one or more meetings a week); if they turn off their devices
before a meeting; if its normal for a mobile device to disturb a meeting; and if it is normal for atten-
dants to use their smartphones inappropriately during meetings (e.g., play games, access social media
content). Additionally, we also ask if attendants would adopt an app like mMeeting, if they believe the
71
02468
10
1 - VeryUnconfortable
2 - Unconfortable 3 - OK 4 - Confortable 5 - VeryConfortable
Internet AccessApp ExecutionTexts and Calls
Nu
mb
er
of
Use
rs
Figure 5.7: Students’ comfort with OS restrictions.
app would help to reduce the number of mobile device related meeting disturbances, and if they fear
for meeting information leakage. In the last group, we seek to understand attendants’ perceptions on
the intrusiveness of the trust lease primitive. We start by asking how comfortable would they feel about
allowing a meeting host, or their company itself, to restrict some of their smartphone’s functionalities
during a meeting, if it seemed fair for hosts or the company to hold that power, and how worried would
they be about a host or the company to try to circumvent the system to access their private data.
Because of the difficulties we had in convincing companies in answering these questionnaires (sim-
ilar to what happened for the mMeeting user tests), we ended up distributing them amongst former
colleagues who are now employed, which then distributed them to their work colleagues.
mTicket – Movie spectators Questionnaire Methodology In the mTicket Institution’s Trust group,
we try to understand how movie spectators perceive the use of mobile devices in movie theaters, as
well as their thoughts about adopting an app like mTicket. We start by asking where do they usually buy
movie tickets from; if they ever used a mobile app to buy those tickets; if they turn off their devices before
a movie; and if they ever got distracted by other peoples’ phone ringing or high screen brightness during
a movie. Additionally, we ask if they would adopt an app like mTicket; if ticket discounts would be a good
incentive, as trade-off for the restrictions imposed; and how effective do they believe the app would be
in preventing movie disturbances due to wrong device usage. In the last group, we seek to understand
spectators’ perceptions on the intrusiveness of the trust lease primitive, in an approach similar to the
mMeeting – Meeting attendants questionnaire. We ask how comfortable would they feel about allowing
a movie company to restrict some of their smartphone’s functionalities during a movie; if it seemed fair
for those companies to hold that power; and how worried would they be about those companies trying
to circumvent the system to access their private data.
These questionnaires were distributed online, through Facebook, targeting potential mTicket users.
5.4.2 mExam – Students Questionnaire Findings
In total we collected 20 responses, from students between the ages of 18 and 28 years old, with a
distribution of 35% women, and 65% men. Amongst the students, 45% could send texts, place phone
calls, install applications, and manage disk space, while 55% could additionally program mobile apps.
From the students, 90% had one smartphone, while 10% had two. From these devices, Android
was the predominant OS (65%), followed by iOS (30%), and Windows Phone (5%). In terms of device
acquisition, 45% of devices were bought from other stores (e.g., Fnac), 20% were bought online, 20%
72
a) Trust lease confort
b) Trust lease worries
02468
1 - VeryUncomfortable
2 - Uncomfortable 3 - OK 4 - Comfortable 5 - Very Comfortable
0
2
4
6
1 - Not worried 2 - Minimally worried 3 - Worried 4 - Very worried 5 - Very muchworried
Nu
mb
er
of
Use
rsN
um
be
ro
fU
sers
Figure 5.8: Students’ comfort and worries about trust leases.
from provider stores with points, and the remaining 15% were acquired in several other ways. From
these devices, only 15% were under customer retention periods, and 40% were under warranty.
In terms of permissions, 40% of students said they read app permissions before installing an app, and
if they find them abusive, they cancel the installation, 50% said they sometimes read the permissions,
but install the app anyway, and 10% admitted they do not read permissions at all. Regarding privacy,
80% of students said they were worried or very worried (ranks 4 and 5 on a Likert scale) about the
possibility of some of their apps being leaking personal information, while 70% had the same concerns
for personal location leaks. Additionally, 45% of students said they would consider changing OSes.
Even so, in terms of OS replacement, 55% of students said that an OS that could protect their private
information and location from leaks, would be a priority when looking for an OS replacement. Moreover,
60% and 75% of students said that a better energy management and increased performance would be
priorities when looking for an OS replacement, respectively. When asked whether they would replace
OSes if it gave them perks (e.g., movie ticket discounts), 40% of students said they would, and when
asked if they would replace it while losing device warranty, the number of students who would dropped
to 35%. Figure 5.7 shows us just how comfortable students felt about the possibility of an OS to allow for
an app to inflict restrictions on the access to the Internet, the execution of apps, and restrictions on texts
and phone calls. Overall, students were uncomfortable with these restrictions, as there we only 16.7%
of comfortable or very comfortable answers.
Regarding more scenario-specific questions, 90% of students said they would use a mobile app to
perform school related tasks (e.g., enroll in exams), and 80% said they would adopt mExam to answer
exams. Moreover, 80% of students said there is a big difference between answering an exam in a
piece of paper or in a smartphone, and 50% admitted they would not feel comfortable about answering
exams through their smartphones. Additionally, 85% of students feared that a device malfunction could
compromise their exams, 70% said the savings in test sheets would be an incentive to adopt mExam,
and 85% said that an app of this nature would bring yet another form for students to cheat.
Regarding trust leases, Figure 5.8 a) shows us that most students feel comfortable about allowing
a professor to control some of their devices’ capabilities during an exam, while Figure 5.8 b) shows us
73
02468
101214
1 - VeryUnconfortable
2 - Unconfortable 3 - OK 4 - Confortable 5 - VeryConfortable
Internet Access
App Execution
Texts and CallsN
um
be
ro
fU
sers
Figure 5.9: Attendants’ comfort with OS restrictions.
that students are worried regarding the possibility of a professor to circumvent the system in order to
access personal information, but those worries are fairly balanced. Moreover, 35% of students admitted
they would feel compelled to analyse app source code to try to circumvent it. Additionally, only 30% of
students believe it to be unfair for professors to have the power to impose those restrictions in students’
devices during exams, and 65% say there is a difference between these restrictions and the orders
professors give at the beginning of exams (e.g., only pen and paper on top of the table during the exam).
5.4.3 mMeeting – Meeting Attendants Questionnaire Findings
In total we collected 20 responses, from people between the ages of 20 and 39, with a distribution of 6
women, and 14 men. From the responders in question, 12 had completed a master’s degree, while 8
had completed a bachelor’s degree. The biggest area of graduation was engineering (80%), but there
were also respondents that graduated in arts, design, among others. Amongst the respondents, 40%
could send texts, place phone calls, and install applications, while 60% could additionally program mobile
applications. Note that the high percentage of respondents who can develop applications has to do with
the technological nature of the companies involved. Even so, this fact has no additional impact to the
overall results of the questionnaires.
From the attendants, 65% had one smartphone, 25% had two, and 10% had three or more. From
these devices, Android was the predominant OS (55%), followed by iOS (30%), and Windows Phone
(25%). In terms of device acquisition, 60% of devices were bought online, 20% were bought from
provider stores, and the remaining 20% were acquired in several other ways. From these devices, only
15% were under customer retention periods, and only 30% were under warranty.
In terms of permissions, 60% of attendants said they read app permissions before installing an app,
and if they find them abusive, they cancel the installation, 35% said they sometimes read the permis-
sions, but install the app anyway, and 5% said they do not read permissions at all. Regarding privacy,
65% of attendants said they were worried or very worried (ranks 4 and 5 on a Likert scale) about the pos-
sibility of some of their apps being leaking personal information, while 60% had the same concerns for
personal location leaks. Additionally, only 20% of attendants said they would consider changing OSes.
Even so, in terms of OS replacement, 65% of attendants said that it would be interesting if the OS
replacing their own could protect their private information and location from leaks. Moreover, 65% and
60% of attendants said that a better energy management and increased performance would be priorities
when looking for an OS replacement, respectively. When asked whether they would replace OSes if it
74
Yes 55%
No 45%
Yes 30%
No 70%
Worried 40%
Not worried
60%
a) Meeting interruptions
b) Non-related apps
c) Information leaks
d) mMeeting adoption
Yes 60%
No 40%
Figure 5.10: Meeting habits, and attendants openness to adopt mMeeting.
gave them perks (e.g., movie ticket discounts), only 40% of attendants said they would, and when asked
if they would replace it while losing device warranty, the number of attendants who would dropped to
25%. Figure 5.9 shows us just how comfortable attendants felt about the possibility of an OS to allow for
an app to inflict restrictions on the access to the Internet, the execution of apps, and restrictions on texts
and phone calls. Overall, attendants felt quite uncomfortable about these restrictions, with only nearly
17% of answers being comfortable or very comfortable, with a fairly balanced distribution amongst the
resources restricted.
Regarding more scenario-specific questions, 95% of attendants said they had at least one meeting
per week. In terms of meeting habits, only 5% of attendants said they turn off their devices before a
meeting, 90% said they do not turn them off, but put them in silence, and 5% said they leave them turned
on and unchanged. Moreover, 55% of attendants said (Figure 5.10 a) ) it is common for their meetings
to have mobile device related disturbances, and 30% said (Figure 5.10 b) ) it is normal for meeting
attendants to use non meeting related apps. Additionally, 40% of attendants said (Figure 5.10 c) ) they
fear for meeting information leaks, and 60% said (Figure 5.10 d) ) they would adopt the mMeeting app.
On the other hand, 70% of attendants believe that an app like mMeeting would help in reducing the
number of meeting disturbances caused by wrong smartphone usage.
Regarding trust leases, Figure 5.11 a) shows us that most attendants feel uncomfortable about al-
lowing someone to control some of their devices’ capabilities during a meeting , while Figure 5.11 b)
shows us that the majority of attendants would feel worried about the possibility of a host to circumvent
the system in order to access personal information. Additionally, 80% of attendants believe it to be unfair
for hosts to have the power to impose those restrictions in attendants’ devices during meetings.
5.4.4 mTicket – Movie Spectators Questionnaire Findings
In total we collected 20 responses, from people between the ages of 18 and 52, with a distribution
of 9 women, and 11 men. From the responders in question, 35% had completed a master’s degree,
50% had completed a bachelor’s degree, and 15% had not finished high school. The biggest area of
graduation featured engineering (35%), but there were also respondents that graduated in medicine,
law, arts, among others. From the respondents, 80% could send texts, place phone calls, and install
applications, 65% could manage device disk space, and 15% could program mobile apps.
From the possible spectators, 80% had one smartphone, and 20% had two. From these devices,
75
a) Trust lease confort
b) Trust lease worries
02468
1 - VeryUncomfortable
2 - Uncomfortable 3 - OK 4 - Comfortable 5 - Very Comfortable
02468
10
1 - Not worried 2 - Minimally worried 3 - Worried 4 - Very worried 5 - Very muchworried
Nu
mb
er
of
Use
rsN
um
be
ro
fU
sers
Figure 5.11: Attendants’ comfort and worries about trust leases.
Android was the predominant OS (70%), followed by iOS (25%), and Windows Phone (5%). In terms
of device acquisition, 35% of devices were bought online, 25% were bought from provider stores with
points, and the remaining 40% were acquired in several other ways. From these devices, only 10% were
under customer retention periods, and only 20% were under warranty.
In terms of permissions, only 15% of spectators said they read app permissions before installing
an app, and if they find them abusive, they cancel the installation, 45% said they sometimes read the
permissions, but install the app anyway, and 40% admit they do not read permissions at all. Regarding
privacy, 30% of spectators said they were worried or very worried (ranks 4 and 5 on a Likert scale)
about the possibility of some of their apps being leaking personal information, while 45% had the same
concerns for personal location leaks. Additionally, 55% of spectators said they would consider changing
OSes. Even so, in terms of OS replacement, 55% of spectators said that it would be interesting if the
OS replacing their own could protect their location from leaks. On the other hand, 65% considered the
protection of their data as a priority. Moreover, 50% and 75% of spectators said that a better energy
management and increased performance would also be priorities when looking for an OS replacement.
When asked whether they would replace OSes if it gave them perks (e.g., movie ticket discounts), 70%
of spectators said they would, and when asked if they would replace it while losing device warranty,
the number of spectators who would dropped, but still reached 45%. Figure 5.12 shows us just how
comfortable spectators felt about the possibility of an OS to allow for an app to inflict restrictions on
the access to the Internet, the execution of apps, and restrictions on texts and phone calls. Overall,
spectators felt uncomfortable about these restrictions, but still, there were over 28% comfortable or very
comfortable answers regarding these restrictions.
Regarding more scenario-specific questions, 95% of spectators said they usually buy movie tickets
in physical ticket booths, and only 5% buy them through mobile apps. Moreover, 80% of spectators said
they had never bought a ticket through a mobile app, and 10% said they did not because they do not
trust mobile apps to make payments. In terms of movie theater habits, only 10% of spectators said they
turn off their devices before a movie, 50% do not turn them off, but put them in silence, and the remaining
76
02468
1012
1 - VeryUnconfortable
2 - Unconfortable 3 - OK 4 - Confortable 5 - VeryConfortable
Internet AccessApp ExecutionTexts and Calls
Nu
mb
er
of
Use
rs
Figure 5.12: Spectators’ comfort with OS restrictions.
a) Phone ringingdisturbances
b) Screen brightnessdisturbances
c) Movierecording
d) mTicketadoption
Yes90%
No10%
Yes85%
No15%
Yes65%
No35%
Yes10%
No90%
Figure 5.13: Movie theater habits, and spectator openness to adopt mTicket.
40% put them in silence and lower its brightness. Moreover, 90% of spectators said (Figure 5.13 a) ) they
occasionally get distracted by devices ringing during a movie, and 85% (Figure 5.13 b) ) get distracted
by devices’ screen brightness. Additionally, 10% of spectators said (Figure 5.13 c) ) they have seen
people record a movie using his/hers smartphone, and 65% said (Figure 5.13 d) ) they would adopt the
mTicket app. Furthermore, 80% of spectators believe that an app like mTicket would help in reducing the
number of movie disturbances caused by wrong smartphone usage, and 90% think that ticket discounts
would be a good incentive to spread the adoption of mTicket.
Regarding trust leases, Figure 5.14 a) shows us that most spectators feel comfortable about allowing
movie theater managers to control some of their devices’ capabilities during a movie, while in Figure 5.14
b) we can see that the majority of spectators would feel worried about the possibility of one of these man-
agers to circumvent the system in order to access personal information. Additionally, 40% of spectators
believe it to be unfair for managers to have the power to impose those restrictions in spectators’ devices
during movies.
5.4.5 Summary of Adoption Study Findings
From this study we can trace the average potential strapp user profile. Generally, users have 1 smart-
phone; Android is the predominant OS; the devices are bought either online, or in other stores (e.g.,
Fnac); and the devices are under no retention periods, and have no protection against deficiencies or
accidents. In terms of permissions, although sometimes users read them, they end up granting them
anyway. Additionally, users feel worried about the possibility of their apps being leaking personal infor-
mation or their location to external parties. In terms of OSes, users feel divided when asked about the
possibility of changing their OS. In fact, the majority of users would not change their OS even if the new
OS offered them perks (e.g., movie ticket discounts). They also become more skeptical about changing
OSes when they learn it would lead to the loss of the device’s warranty. Regarding the capability of an
77
a) Trust lease confort
b) Trust lease worries
0
2
4
6
8
1 - VeryUncomfortable
2 - Uncomfortable 3 - OK 4 - Comfortable 5 - Very Comfortable
02468
10
1 - Not worried 2 - Minimally worried 3 - Worried 4 - Very worried 5 - Very muchworried
Nu
mb
ero
fU
sers
Nu
mb
er
of
Use
rs
Figure 5.14: Spectators’ comfort and worries about trust leases.
OS to allow an app to enforce restrictions on the access to the Internet, send / receive texts, and on the
execution of other apps, users generally feel uncomfortable.
Regarding the mExam, mMeeting, and mTicket strapps, users generally identify themselves with the
issues these apps address, and the majority see the benefits of these apps, and admit they would adopt
them. When presented with the need for the restrictions for each scenario in particular, users from the
mExam, and mTicket scenarios, seem to better understand them. They admit that in those contexts, they
feel more comfortable about the restrictions, as they understand their benefits. The mMeeting users, on
the other hand, tend to feel these restrictions can be too strict, and are therefore not comfortable with
them. In terms of the possibility of a lessee restricting more than he should, or access personal data,
users generally feel worried.
5.5 Summary
In this chapter we covered the effects of trust leases on real world applications and spyware. We have
seen that existing apps do not exhibit erratic behaviours because of trust leases, and we have even seen,
that trust leases can be a good mechanism to stop spyware. Additionally, we saw the performance of the
Trust Lease Protocol over network and NFC communication, and compared their differences. Moreover,
we conducted user tests that shown that our strapps are easy to use and intuitive. The major problems,
stemmed from over-general language with which lease conditions are displayed, and with the lack of
notifications, informing users why certain operations do not execute (useful for more distracted users).
We concluded the chapter with an adoption study on potential mExam, mMeeting, and mTicket strapp
users. From this study we learned that users generally do not feel compelled to change their OS, and
are even more skeptical when they learn it means losing their device’s warranty. In general, users do not
feel comfortable with the restrictions imposed by trust leases, but when applied to specific scenarios,
users tend to see their benefits, and admit adopting these strapps. However, note that adopting the
strapps without adopting the underlying system is unfeasible.
78
Chapter 6
Conclusion
In retrospect, despite the evolution of mobile technology, there are still plenty of tasks we do not do
resorting to mobile devices, not because of technological limitations, but because MOSes do not offer
the necessary mechanisms to secure these tasks. As an example, nowadays’ systems supporting
electronic exams, information leak prevention and context-aware scenarios such as mTicket, all have
very lenient security concerns. With these systems, students can easily cheat, meeting participants
can just as easily leak sensitive data, and movie spectators can carelessly distract audiences. The
Android OS does not offer application developers tools capable of enforcing these security guarantees.
In addition, and after analysing the most representative Android security extensions, we found that none
of them directly solves our problem, although some could serve as building blocks to help developers in
creating secure applications.
In this work, we leverage a new OS primitive we recently proposed [80] called trust lease, that is
capable of enforcing resource and app execution restrictions, to prove the benefits and show its ef-
fectiveness in securing these tasks, currently unsupported by today’s MOSes. In order to do so, we
use TrUbi, a system that offers the trust lease primitive for Android devices. Additionally, we present
the Strapp Middleware, an abstraction layer built on top of TrUbi’s API, that offers a transparent lease
negotiation protocol (TLP) for users and third parties, and simultaneously eases the work of strapp de-
velopers, because of its easy to use API. We present two implementations of TLP that run on top of
network (sockets) and NFC communication channels. Moreover, we present the design and implemen-
tation of the mExam, mMeeting, and mTicket strapps, as well as all the logic supporting these scenarios
(e.g., central server).
In terms of evaluation, we show that trust leases do not trigger erratic behaviours in real-world apps,
and that they can even be a good mechanism to stop spyware. We analysed the performance of the
two TLP implementations, and compared their differences. Regarding our strapps, we conducted user
tests that shown that our strapps are easy to use and intuitive. The major problems, stemmed from over-
general language with which lease conditions are displayed, and with the lack of notifications, informing
the reason why certain operations do not execute (useful for more distracted users). Additionally, we
conducted an adoption study on potential mExam, mMeeting, and mTicket strapp users. From this study
79
we learned that users generally do not feel compelled to change their OS, and are even more skeptical
when they learn it means losing their device’s warranty. In general, users do not feel comfortable with
the restrictions imposed by trust leases, but when applied to specific scenarios, users tend to see their
benefits, and admit adopting these strapps.
It is also important to stress that part of this work as already been accepted in a workshop [80], and
as also been submitted to a conference.
Future Work In terms of future work, there are several new avenues for future research. Regarding
the three strapps, there are several improvements that could be made. For instance, for the mExam
strapp, we could implement an exam submission system, so that students’ exams are periodically sub-
mitted to the school server, to prevent information loss because of device malfunctions. Additionally, we
could also implement a logging system that allows professors to check students’ exam modifications,
and compare them with other colleagues, in order to detect cheating. For the mMeeting strapp we could
spread the attestation mechanism to attendants as well, and implement it following a peer-to-peer ap-
proach (perhaps with WiFi Direct), where the transition of a participant’s device to unrestricted mode
is broadcasted to every meeting participant. For the mTicket strapp, we could implement an easier
lease start mechanism, i.e., allow for users to accept a lease once, and only be presented with lease
conditions, in other movie theater visits, if those conditions change.
On the other hand, we could also focus in covering some side channels, that can somehow endanger
the security of our scenarios. For instance, in the mExam strapp, we could implement a light sensitivity
sensor based solution to detect the use of a second device to access information inadvertently, without
professors’ notice.
Additionally, we could implement a restriction notification system, capable of reminding users they
cannot execute certain tasks, because their devices are in restricted mode, in a response to users’
feedback, given in the strapp user tests. We could also work on open sourcing these strapps, as well as
TrUbi, in a way similar to other Android security extensions.
80
Bibliography
[1] ACR122U USB NFC Reader. http://www.acs.com.hk/en/products/3/acr122u-usb-nfc-
reader. Accessed October 2015.
[2] Android DRM Framework, . http://developer.android.com/reference/android/drm/package-
summary.html. Accessed October 2015.
[3] Security with HTTPS and SSL, . https://developer.android.com/training/articles/
security-ssl.html. Accessed October 2015.
[4] Android Processes and Threads, . http://developer.android.com/guide/components/
processes-and-threads.html. Accessed October 2015.
[5] Android Open Source Project. https://source.android.com. Accessed October 2015.
[6] App Ops. http://www.androidpolice.com/2013/07/25/app-ops-android-4-3s-hidden-app-
permission-manager-control-permissions-for-individual-apps. Accessed October 2015.
[7] Custom Exam. http://www.customexam.com. Accessed October 2015.
[8] CyanogenMod, . http://www.cyanogenmod.org. Accessed October 2015.
[9] Why Android Won’t be Getting App Ops Anytime Soon, . http://www.cnet.com/news/why-
android-wont-be-getting-app-ops-anytime-soon. Accessed October 2015.
[10] Dendroid. http://www.symantec.com/security_response/writeup.jsp?docid=2014-030418-
2633-99. Accessed October 2015.
[11] Diffie-Hellman Key Exchange. https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_
exchange. Accessed October 2015.
[12] DragSortListView. https://github.com/bauerca/drag-sort-listview. Accessed October 2015.
[13] Extended Length APDU. http://developer.android.com/reference/android/nfc/tech/
IsoDep.html#isExtendedLengthApduSupported(). Accessed October 2015.
[14] Fenix. https://fenix.tecnico.ulisboa.pt. Accessed October 2015.
[15] Google Play. https://play.google.com/store. Accessed October 2015.
81
[16] Host-based Card Emulation. https://developer.android.com/guide/topics/connectivity/
nfc/hce.html. Accessed October 2015.
[17] Likert Scale. https://en.wikipedia.org/wiki/Likert_scale. Accessed October 2015.
[18] Moodle. https://moodle.org. Accessed October 2015.
[19] NFCTools. https://github.com/grundid/nfctools. Accessed October 2015.
[20] OpenSSL. http://www.openssl.org/index.php/Android. Accessed October 2015.
[21] PhoneGap. http://phonegap.com. Accessed October 2015.
[22] Portecle. http://portecle.sourceforge.net. Accessed October 2015.
[23] Speed Exam. http://speedexam.net/index.html. Accessed October 2015.
[24] Stack Overflow. http://stackoverflow.com. Accessed October 2015.
[25] TCExam. http://www.tcexam.org/index.php. Accessed October 2015.
[26] Think Exam. http://www.thinkexam.com/index.html. Accessed October 2015.
[27] VirtualX. http://virtualx.sourceforge.net/index.html. Accessed October 2015.
[28] Wireshark. https://www.wireshark.org. Accessed October 2015.
[29] Shameem Ahmed, Moushumi Sharmin, and Sheikh Iqbal Ahamed. A Smart Meeting Room with
Pervasive Computing Technologies. In Proc. of SNPD, 2005.
[30] Michael Backes, Sebastian Gerling, Christian Hammer, Matteo Maffei, and Philipp von Styp-
Rekowsky. AppGuard: Enforcing User Requirements on Android Apps. In Proc. of TACAS, 2013.
[31] Michael Backes, Sven Bugiel, Sebastian Gerling, and Philipp von Styp-Rekowsky. Android Security
Framework: Enabling Generic and Extensible Access Control on Android. In Proc. of ACSAC, 2014.
[32] Alastair R Beresford, Andrew Rice, Nicholas Skehin, and Ripduman Sohan. MockDroid: Trading
Privacy for Application Functionality on Smartphones. In Proc. of HotMobile, 2011.
[33] Giampiero EG Beroggi. Secure and Easy Internet Voting. IEEE Computer, 41(2):52–56, 2008.
[34] Sven Bugiel, Lucas Davi, Alexandra Dmitrienko, Thomas Fischer, and Ahmad-Reza Sadeghi.
Xmandroid: A New Android Evolution to Mitigate Privilege Escalation Attacks. Technical report,
Technische Universitat Darmstadt, Technical Report TR-2011-04, 2011.
[35] Sven Bugiel, Lucas Davi, Alexandra Dmitrienko, Stephan Heuser, Ahmad-Reza Sadeghi, and Bhar-
gava Shastry. Practical and Lightweight Domain Isolation on Android. In Proc. of SPSM, 2011.
[36] Sven Bugiel, Lucas Davi, Alexandra Dmitrienko, Thomas Fischer, Ahmad-Reza Sadeghi, and Bhar-
gava Shastry. Towards Taming Privilege-Escalation Attacks on Android. In Proc. of NDSS, 2012.
82
[37] Sven Bugiel, Stephan Heuser, and Ahmad-Reza Sadeghi. myTunes: Semantically Linked and
User-Centric Fine-Grained Privacy Control on Android. Technical report, Technical Report TUD-
CS-2012-0226, Center for Advanced Security Research Darmstadt (CASED), 2012.
[38] Sven Bugiel, Stephan Heuser, and Ahmad-Reza Sadeghi. Flexible and Fine-grained Mandatory
Access Control on Android for Diverse Security and Privacy Policies. In Proc. of USENIX Security,
2013.
[39] Stefano Campanelli, Alessandro Falleni, Fabio Martinelli, Marinella Petrocchi, and Anna Vaccarelli.
Mobile Implementation and Formal Verification of an e-Voting System. In Proc. of ICIW, 2008.
[40] Jordi Castella-Roca, Jordi Herrera-Joancomarti, and Aleix Dorca-Josa. A Secure e-Exam Manage-
ment System. In Proc. of ARES, 2006.
[41] Harry Chen, Filip Perich, Dipanjan Chakraborty, Tim Finin, and Anupam Joshi. Intelligent Agents
Meet Semantic Web in a Smart Meeting Room. In Proc. of IFAAMAS, 2004.
[42] Mauro Conti, Vu Thien Nga Nguyen, and Bruno Crispo. CRePE: Context-Related Policy Enforce-
ment for Android. Information Security, 6531:331–345, 2011.
[43] Vedat Coskun, Kerem Ok, and Busra Ozdenizci. Professional NFC Application Development for
Android. John Wiley & Sons, 2013.
[44] Peng Dai and Guangyou Xu. Context-aware Computing for Assistive Meeting System. In Proc. of
PETRA, 2008.
[45] Michael Dietz, Shashi Shekhar, Yuliy Pisetsky, Anhei Shu, and Dan S Wallach. QUIRE: Lightweight
Provenance for Smart Phone Operating Systems. In Proc. of USENIX Security, 2011.
[46] William Enck, Peter Gilbert, Byung-Gon Chun, Landon P. Cox, Jaeyeon Jung, Patrick McDaniel, and
Anmol N. Sheth. TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring
on Smartphones. In Proc. of OSDI, 2010.
[47] Sascha Fahl, Marian Harbach, Thomas Muders, Lars Baumgartner, Bernd Freisleben, and Matthew
Smith. Why eve and mallory love android: An analysis of android ssl (in)security. In Proc. of CCS,
2012.
[48] Sascha Fahl, Marian Harbach, Henning Perl, Markus Koetter, and Matthew Smith. Rethinking ssl
development in an appified world. In Proc. of SIGSAC, 2013.
[49] Adrienne Porter Felt, Helen J Wang, Alexander Moshchuk, Steve Hanna, and Erika Chin. Permis-
sion Re-Delegation: Attacks and Defenses. In Proc. of USENIX Security, 2011.
[50] Luka Finzgar and Mira Trebar. Use of NFC and QR Code Identification in an Electronic Ticket
System for Public Transport. In Proc. of SoftCOM, 2011.
83
[51] Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh, and Vitaly Shmatikov.
The most dangerous code in the world: Validating ssl certificates in non-browser software. In Proc.
of CCS, 2012.
[52] Tor-Morten Gronli, Jarle Hansen, and Gheorghita Ghinea. A Context-Aware Meeting Room: Mobile
Interaction and Collaboration Using Android, Java ME and Windows Mobile. In Proc. of COMPSAC,
2010.
[53] Prashant K Gupta and New Delhi. Mobile Examination System. In Proc. of PDGC, 2012.
[54] Hao Hao, Vicky Singh, and Wenliang Du. On the effectiveness of api-level access control using
bytecode rewriting in android. In Proc. of SIGSAC, 2013.
[55] Shuai Hao, Ding Li, William GJ Halfond, and Ramesh Govindan. Sif: A selective instrumentation
framework for mobile applications. In Proc. of MobiSys, 2013.
[56] Toshiharu Harada, Takashi Horie, and Kazuo Tanaka. In Proc. of Linux Conference, 2004.
[57] Stephan Heuser, Adwait Nadkarni, William Enck, and Ahmad-Reza Sadeghi. ASM: A Pro-
grammable Interface for Extending Android Security. In Proc. of USENIX Security, 2014.
[58] Peter Hornyack, Seungyeop Han, Jaeyeon Jung, Stuart Schechter, and David Wetherall. These
Aren’t the Droids You’re Looking For: Retrofitting Android to Protect Data from Imperious Applica-
tions. In Proc. of CCS, 2011.
[59] Manuel J. Fonseca, Pedro Campos, and Daniel Goncalves. Introducao ao Design de Interfaces.
FCA, 2012.
[60] Jinseong Jeon, Kristopher K Micinski, Jeffrey A Vaughan, Ari Fogel, Nikhilesh Reddy, Jeffrey S Fos-
ter, and Todd Millstein. Dr. android and mr. hide: Fine-grained permissions in android applications.
In Proc. of SPSM, 2012.
[61] Rui Joaquim, Paulo Ferreira, and Carlos Ribeiro. EVIV: An End-to-end Verifiable Internet Voting
System. Computers & Security, 32:170–191, February 2013.
[62] Im Y Jung and Heon Young Yeom. Enhanced Security for Online Exams Using Group Cryptography.
IEEE Transactions on Education, 52(3):340–349, 2009.
[63] Michael Kern and Johannes Sametinger. Permission Tracking in Android. In Proc. of UBICOMM,
2012.
[64] Lazaros Kyrillidis, Sheila Cobourne, Keith Mayes, Song Dong, and Konstantinos Markantonakis.
Distributed e-Voting Using the Smart Card Web Server. In Proc. of CRiSIS, 2012.
[65] Hu Linli, Wang Yuhao, and Li Dong. Uniticket: A Third Party Universal e-Ticket System Based on
Mobile Phone. Wireless Engineering and Technology, 2(3):157–164, 2011.
84
[66] Peter Loscocco. Integrating Flexible Support for Security Policies Into the Linux Operating System.
In Proc. of FREENIX Track, 2001.
[67] Yu-Chun Lu, Yu-Sheng Yang, Ping-Chun Chang, and Chu-Sing Yang. The Design and Implemen-
tation of Intelligent Assessment Management System. In Proc. of EDUCON, 2013.
[68] George Meletiou, Ioannis Voyiatzis, Vera Stavroulaki, and Cleo Sgouropoulou. Design and Imple-
mentation of an E-exam System Based on the Android Platform. In Proc. of PCI, 2012.
[69] Zhaozong Meng and Joan Lu. Implementing the Emerging Mobile Technologies in Facilitating
Mobile Exam System. IPCSIT, 17:80–88, 2011.
[70] Collin Mulliner, Jon Oberheide, William Robertson, and Engin Kirda. Patchdroid: Scalable third-
party security patches for android devices. In Proc. of ACSAC, 2013.
[71] Adwait Nadkarni and William Enck. Preventing accidental data disclosure in modern operating
systems. In Proc. of SIGSAC, 2013.
[72] Mohammad Nauman, Sohail Khan, and Xinwen Zhang. Apex: Extending Android Permission Model
and Enforcement with User-defined Runtime Constraints. In Proc. of ASIACCS, 2010.
[73] OMA. Enabler Release Definition for DRM V2.0.1, 2008.
[74] Machigar Ongtang, Kevin Butler, and Patrick Mcdaniel. Porscha: Policy Oriented Secure Content
Handling in Android. In Proc. of ACSAC, 2010.
[75] Machigar Ongtang, Stephen McLaughlin, William Enck, and Patrick McDaniel. Semantically Rich
Application-Centric Security in Android. Security and Communication Networks, 5(6):658–673,
June 2012.
[76] Lucky Onwuzurike and Emiliano De Cristofaro. Danger is my middle name: Experimenting with ssl
vulnerabilities in android apps. arXiv preprint arXiv:1505.00589, 2015.
[77] Josh Potts, Nick Moore, and Somsak Sukittanon. Developing Mobile Learning Applications for
Electrical Engineering Courses. In Proc. of SoutheastCON, 2011.
[78] Nikhilesh Reddy, Jinseong Jeon, J Vaughan, Todd Millstein, and J Foster. Application-centric se-
curity policies on unmodified android. Technical report, Technical Report 110017, UCLA Computer
Science Department, 2011.
[79] Giovanni Russello, Mauro Conti, Bruno Crispo, and Earlence Fernandes. Moses: Supporting op-
eration modes on smartphones. In Proc. of SACMAT, 2012.
[80] Nuno Santos, Nuno O. Duarte, Miguel B. Costa, and Paulo Ferreira. A case for enforcing app-
specific constraints to mobile devices by using trust leases. In Proc. of HotOS, 2015.
[81] Daniel Schreckling, Johannes Kostler, and Matthias Schaff. Kynoid: Real-Time Enforcement of
Fine-Grained, User-Defined, and Data-Centric Security Policies for Android. Information Security
Technical Report, 17(3):71–80, February 2013.
85
[82] Bilal Shebaro, Oyindamola Oluwatimi, Daniele Midi, and Elisa Bertino. IdentiDroid: Android can
finally Wear its Anonymous Suit. Transactions on Data Privacy, 7(1):27–50, 2014.
[83] Kapil Singh. Practical context-aware permission control for hybrid mobile applications. In Proc. of
RAID, 2013.
[84] Stephen Smalley and Robert Craig. Security Enhanced (SE) Android: Bringing Flexible MAC to
Android. In Proc. of NDSS, 2013.
[85] B Sodor, G Fordos, T Doktor, and B Benyo. Building a Contactless University Examination System
Using NFC. In Proc. of INES, 2011.
[86] Riley Spahn, Jonathan Bell, Michael Lee, Sravan Bhamidipati, Roxana Geambasu, and Gail Kaiser.
Pebbles: Fine-Grained Data Management Abstractions for Modern Operating Systems. In Proc. of
OSDI, 2014.
[87] Cesar RK Stradiotto, Angela I Zotti, Claudia O Bueno, Sonali PM Bedin, Hugo C Hoeschl, Tania CD
Bueno, TPS Oliveira, and Vinicus O Mirapalheta. Web 2.0 e-Voting System Using Android Platform.
In Proc. of PIC, 2010.
[88] Aslihan Tufekci, Hasan Ekinci, and Utku Kose. Development of an Internet-Based Exam System for
Mobile Environments and Evaluation of its Usability. Mevlana International Journal of Education, 3
(4):57–74, 2013.
[89] Arnau Vives-Guasch, Maria-Magdalena Payeras-Capella, Mut-Puigserver Macia, Jordi Castella-
Roca, and Josep-Lluıs Ferrer-Gomila. A Secure E-ticketing Scheme for Mobile Devices with Near
Field Communication (NFC) that Includes Exculpability and Reusability. IEICE Transactions on
Information and Systems, 95(1):78–93, 2012.
[90] Xueqiang Wang, Kun Sun, Yuewu Wang, and Jiwu Jing. Deepdroid: Dynamically enforcing enter-
prise policy on android devices. In Proc. of NDSS, 2015.
[91] Yifei Wang, Srinivas Hariharan, Chenxi Zhao, Jiaming Liu, and Wenliang Du. Compac: Enforce
Component-Level Access Control in Android. In Proc. of CODASPY, 2011.
[92] Chris Wright, Crispin Cowan, Stephen Smalley, James Morris, and Greg Kroah-Hartman. Linux
Security Modules: General Security Support for the Linux Kernel. In Proc. of USENIX Security,
2003.
[93] Rubin Xu, Hassen Saıdi, and Ross Anderson. Aurasium: Practical Policy Enforcement for Android
Applications. In Proc. of USENIX Security, 2012.
[94] Yajin Zhou and Xuxian Jiang. Dissecting android malware: Characterization and evolution. In Proc.
of S&P, 2012.
[95] Yajin Zhou, Xinwen Zhang, Xuxian Jiang, and Vincent W Freeh. Taming Information-Stealing
Smartphone Applications (on Android). In Proc. of TRUST, 2011.
86
Appendix A
Android SSL Development
The Android SSL development paradigm suffers from tremendous issues, that hamper the adoption of
this secure channel protocol. The problem however, is not new. Several studies [47, 48, 51, 76] address
the SSL/HTTPS related vulnerabilities present in real-world apps, concluding that these vulnerabilities
stem not only from negligent application development, but mostly due to poor API documentation, or
overly complex APIs.
This development paradigm introduces the need for developers to create their own mechanisms for
validating certificates and entities, which involves creating custom TrustManagers, and HostNameVeri-
fiers, which is not such a trivial task. Most of these studies reveal that the need of such customization
leads to major vulnerabilities such as: (1) applications trusting all certificates, (2) applications allowing
all hostnames (more common in mobile-to-server communication, rather than mobile-to-mobile), and (3)
applications mixing safe communication (i.e., using SSL) with normal communication (i.e., no SSL).
Fahl et al. [47] introduces a tool for detecting SSL related MITM attacks, while also showing that
Android could benefit from a notification system from which users could be informed of the level of
security of the communication channels used by the device. They also conduct a study that reveals that
even tech-savvy users have trouble identifying the level of communication security in a mobile browser.
Georgiev et al. [51] shows that even SSL libraries introduce vulnerabilities because of confusing con-
figuration parameters that end up breaking or disabling certificate validation. They show the presence
of these vulnerabilities in critical libraries such as Amazon Flexible Payments Service, PayPal Payments
Standard and PayPal Invoicing. Onwuzurike and De Cristofaro [76] sets up several MITM attacks while
performing static and dynamic android app analysis to detect those vulnerabilities, while at the same
time focusing on sensitive information leakage through unsafe channels, i.e., through HTTP.
Fahl et al. [48] conducted a study with developers of applications which suffered from SSL vulner-
abilities. They concluded that developers usually get frustrated with the complexity of the SSL devel-
opment paradigm, frequently following online forum [24] posts that make “problems go away” without
understanding the consequences of those suggestions. Suggestions that we ourselves followed, before
understanding their security repercussions. The study also shows that in some cases, even when pre-
sented with the vulnerabilities, developers think that issues such as failing to verify if a certificate is still
87
valid, or allowing information such as the device’s IMEI to go through a channel secured by a broken
certificate are not security concerns.
88
Appendix B
Strapp Middleware API Example
Listing B.1 gives us a concrete example on how to use the Strapp Middleware API. This particular exam-
ple concerns a user that negotiates TLP as a lessee, and over NFC. As we can see from the code, in or-
der for a developer to build an application that can negotiate TLP in these conditions, he must create his
own activity, and make it implement the TLProtocolLesseeHandshakeListener interface. This means he
must override the validateLessorId(), lesseeHandshakeCompleted(), and attestationCompleted()
methods. We will discuss the overriding of these methods next.
In this example, we made our app setup the TLP protocol right at the point of creation of the activity,
i.e., in the onCreate() method. This setup comprises, the passage of a reference of the activity to the
protocol adapter, so that it can later use it to notify the activity of the lessor identity validation, as well
as the success of the handshake and attestation operations. In this setup, the developer must also
pass a reference of the trust lease he wishes to enforce on lessors’ devices, as well as the reference
of the keystores containing his and the CA’s certificates, and also their passwords. As we have said in
Section 4.1.1 every entity holds a personal and the CA’s certificate, which are essential for the secure
channel establishment phase of TLP.
In our example, we added two simple buttons to our activity. One to start a handshake, and another to
start an attestation process. When the user presses the startHandshakeButton, the adapter is started,
and the device becomes ready to negotiate TLP. When the user presses the startAttestationButton,
the adapter is started, and the device becomes ready to attest lessors’ device operation modes.
As we have said, in these conditions, a developer must override the three methods previously men-
tioned. In this case we overrode the validateLessorId() method, so that our lessee only accepts to
negotiate TLP with the lessor with id “Nuno Duarte”. Additionally, our lesseeHandshakeCompleted(),
and attestationCompleted() methods, simply log the success or insuccess of the handshake and at-
testation processes respectively. Moreover, we also overrode the onResume() and onPause() methods,
to better manage the power consumption overheads of having NFC turned on, when not needed.
89
1 ...2
3 public class MainActivity extends Activity implements TLProtocolLesseeHandshakeListener {4
5 private Lease mLease;6 private TLProtocolLesseeNFCAdapter protocolAdapter;7
8 @Override9 protected void onCreate(Bundle savedInstanceState) {
10 super.onCreate(savedInstanceState);11 setContentView(R.layout.activity_main);12
13 mLease = loadLeaseFromResources("myLease");14 protocolAdapter = new TLProtocolLesseeNFCAdapter(MainActivity.this , MainActivity.this ,
mLease , R.raw.cert , "pass", R.raw.caCert , "pass");15
16 Button startHandshakeButton = (Button) findViewById(R.id.startHandshakeButton);17 startHandshakeButton.setOnClickListener(new View.OnClickListener () {18 @Override19 public void onClick(View v) {20 protocolAdapter.start();21 }22 });23
24 Button startAttestationButton = (Button) findViewById(R.id.startAttestationButton);25 startAttestationButton.setOnClickListener(new View.OnClickListener () {26 @Override27 public void onClick(View v) {28 protocolAdapter.attest ();29 }30 });31 }32
33 @Override34 protected void onResume () {35 super.onResume ();36 if(protocolAdapter != null)37 protocolAdapter.restart ();38 }39
40 @Override41 protected void onPause () {42 super.onPause ();43 if(protocolAdapter != null)44 protocolAdapter.stop();45 }46
47
48 @Override49 public boolean validateLessorId(String lessorId) {50 if(lessorId.equals("Nuno Duarte"))51 return true;52 else53 return false;54 }55
56 @Override57 public void lesseeHandshakeCompleted(boolean success , String reason) {58 if(success) {59 Log.i(TAG , "Lease Negotiation Successful");60 protocolAdapter.stop();61 }62 else63 Log.i(TAG , "Lease Negotiation Failed: " + reason);64 }65
66 @Override67 public void attestationCompleted(boolean success , String reason) {68 if(success) {69 Log.i(TAG , "Attestation Successful");70 protocolAdapter.stop();71 }72 else73 Log.i(TAG , "Attestation Failed: " + reason , false);74 }75 }
Listing B.1: NFC lessor-side usage example of the Strapp Middleware API
90
Appendix C
NFC Background
The NFC technology, standardized by ECMA (ECMA-340, ECMA-352) and by ISO/IEC (ISO/IEC-18092,
ISO/IEC-21481), offers three different operating modes: (1) reader/write mode, (2) peer-to-peer mode
(P2P), and (3) card emulation mode. We now discuss each mode and discuss how Android supports
them.
The reader/writer mode allows devices to access contactless smartcards, RFID transponders and
NFC tags. Despite their names, two mobile devices cannot use these mechanisms to communicate
bi-directionally, because NFC communication is based on proximity, and once there is a connection
between two endpoints, the operating mode cannot change in neither of them. In Android, applications
cannot directly set the device into this operating mode, but can instead ask for preference over a set
of NFC tags which they must register in their manifest files. Once Android’s NFC Service detects such
tags, it determines the low-level protocol and technology used, and then fills a Tag object with the data
received and creates and emits an Intent to the registered application with higher preference. From
there on, the application can use that Tag reference to communicate with the other endpoint.
The P2P mode allows for two devices to communicate directly with each other. This mode was
thought of as a good mechanism to perform simple interactions, e.g., exchange business cards, ex-
change credentials for a Bluetooth or WiFi link. In Android, the P2P mode is restricted to the use of the
Beam mechanism, a Simple NDEF Exchange Protocol (SNEP) that as the name implies, handles the
exchange of NFC Data Exchange Format (NDEF) messages. When enabled, Beam allows for users to
transfer various types of simple content among devices, e.g., web pages, photos, map directions, con-
tact information. On the other hand, Android APIs allow for app developers to use Beam to implement
P2P mode solutions. However, Beam suffers from a serious limitation, as it forces app developers to
clearly specify NDEF messages, which must then be confirmed individually by the user for them to be
transmitted to the other device. All things considered, Beam cannot provide continuous bi-directional
communication between devices.
The card emulation mode allows devices to emulate contactless smartcards enabling them to com-
municate with existing RFID/NFC readers. This technology enables the implementation of a wide range
of applications, e.g., Mobile Wallet, Ticketing, Loyalty Cards, Coupons. Card emulation solutions either
91
(a) (b)
Host CPU
NFC Controller Secure Element
NFC Reader
Android Device
Host CPU
NFC Controller
NFC Reader
Android Device
Figure C.1: Card emulation solutions (adapted from [16])
rely on a secure element (SE), or on a host device (HCE). In Figure C.1 we can see the fundamental
differences between SE card emulation and HCE. Basically in the first solution the card is emulated by
a separate chip (e.g., SIM cards provided by wireless carriers) in the device, called a secure element.
The communication between the external NFC Reader and the NFC Controller is forwarded to the SE,
which may then communicate with applications. On the other hand, with HCE, the card is emulated by
applications themselves, and external NFC Readers communicate directly with these applications. In
Android 4.4, Google introduced the support for HCE implementations [16]. In contrast to reader/writer
and P2P modes, the technical complexity of HCE applications is much superior, and even according to
the literature [43] there exist no well-established standards for this mode to enable developers to produce
compatible applications. Even so, in order to use HCE, applications must implement a service extend-
ing HostApduService, so that they can process Application Protocol Data Unit (APDU) commands and
compute replies. More specifically they must implement their own processCommandApdu method, which
will then be executed whenever an NFC reader sends an APDU message to the registered service. App
developers must also specify their app id (AID) in their manifests, which will then used by external NFC
readers upon their first message. This message, called SELECT APDU, enables these readers to specify
the app with which they plan to communicate with. The NFC Controller is then responsible to forward
messages from external readers to the intended apps based on these AIDs.
92
Appendix D
Use Case Strapp Wireframes
In this appendix we present our strapps’ wireframes, and give a brief explanation on the components
and interactions a user can have with each strapp.
MainActivity
exam
list
button
ok
button LoginDialog
start exam
button in exam
listview element
ListExamsActivity
enroll or unenroll exam buttons
in exam listview element
QuestionActivity SubmissionDialog submit
button
confirm
button
Figure D.1: Wireframe of the mExam strapp.
Figure D.2, shows us the wireframe of the mExam strapp. As we can see, the strapp is composed of
a MainActivity, a ListExamsActivity, and a variable set of QuestionActivity elements, which in our
case can be TextQuestionActivity, for simple text answers, and MultipleChoiceQuestionActivity,
for multiple choice answers. When a user opens the mExam strapp, he clicks on the exam list button,
which opens a login dialog. After introducing his credentials, the user clicks the okay button, and is
redirected to the exam list activity, that presents every exam available to the user. In this activity, the
user can enroll or unenroll in exams, and can also start the exam, which basically prepares his device
to communicate with the professor’s device. During the exam, the user can go back and forth through
the questions, and when he is ready to submit the exam, a new dialog appears, this time to confirm
the exam submission. After the user confirms the submission, the exam terminates, and the exam list
activity appears once again. The user is then free to close the app.
93
MainActivity
exam
list
button
ok
button LoginDialog
exam
listview
element
ListExamsActivity
ExamPrepActivity ExamOptionsDialog start
exam
button submit invigilator list listen to students
ConfirmedStudentsActivity terminate
students’
exam
button
Figure D.2: Wireframe of the mExam professor strapp.
Figure D.2, shows us the wireframe of the mExam professor strapp. For a matter of simplicity, we
omit the components that allow for professors to create and edit exam statements. As we can see,
this strapp is composed of four activities: MainActivity, ListExamsActivity, ExamPrepActivity, and
ConfirmedStudentActivity. Once a professor opens the strapp, in order for him to go to the list exams
activity, he must login, similarly to what students do for their strapp. Then, after clicking on an exam, the
professor is then presented with a dialog that allows him to either submit a list of invigilating professors,
or to start the exam, which leads to the download of the student list information from the school server,
and the appearance of the exam preparation activity. At this point, the professor either prepares his
device NFC sensor to listen for student devices, or goes to the list of students currently answering the
exam, in order to terminate one of those student’s exam, because of cheating.
MainActivity
meeting
list
button
MeetingOptionsDialog
ok
button
enter or leave meeting buttons for attendants
begin or terminate meeting and attest attendant buttons for hosts
ListMeetingsActivity LoginDialog
meeting
listview
element
Figure D.3: Wireframe of the mMeeting strapp.
Figure D.3, shows us the wireframe of the mMeeting strapp. This strapp is simply composed of the
MainActivity and ListMeetingsActivity activities. Once the user opens the strapp, he clicks on the
meeting list button, which opens a login dialog, similar to the mExam strapp. After introducing his cre-
dentials, and clicking the ok button, the list meeting activity appears. This activity shows every meeting
available to the user. In this activity, the user can click on a meeting, which will open a meeting option
dialog. If the user happens to be an attendant, the user may enter the meeting, which will automatically
trigger a communication with the host’s device (in order to negotiate TLP), or the user may leave the
meeting, which transitions the device back tounrestricted mode. If the user is a host, he can begin a
meeting, which will setup the necessary information, for attendants (e.g., host’s IP); he can terminate
94
the meeting, which effectively transitions every attendant’s device back to unrestricted mode; or he can
attest an attendant’s device operation mode.
MainActivity
movie list
button
MovieListActivity
movie
listview
element MovieOptionsDialog
buy ticket button or
use/discard ticket bought
LoginDialog
ok
button
Figure D.4: Wireframe of the mTicket strapp.
Figure D.4, shows us the wireframe of the mTicket strapp. Similarly to the mMeeting strapp, mTicket
is also comprised of two activities: MainActivity, and MovieListActivity. When a user opens the
strapp, and clicks on the movie list button, he is immediately presented with a login dialog, just like what
happens for the other two strapps. After introducing the credentials and clicking the ok button, the movie
list activity appears, and displays every movie available. The user can then click on a movie, and a movie
option dialog appears. In this dialog, the user can buy a ticket (mocked), discard the ticket, or use the
ticket. This last option, effectively prepares the device to communicate with the cinema’s NFC terminal,
in order o validate the movie ticket and restrict the user’s device.
95
96
Appendix E
Restriction Development Comparison
The use of trust leases, introduces a new development paradigm for application developers. We now
present an example that clearly shows the differences in the development complexity of enforcing re-
strictions using ASM [57], a renown access control hook API, and using trust leases. In this example, we
show how to setup an application, in order to enforce a one hour restriction, where only the Facebook
app may access the camera, using both solutions.
Listing E.1 shows us how to enforce the restriction previously described, using ASM. Recall that
ASM is a framework that allows application developers to define their own security modules, within their
apps’ code. In order for the OS to retrieve access control decisions from these apps, developers must
create a dedicated service, whose sole purpose is to return these decisions to the OS. In Listing E.1
we can see the definition of such a service, that effectively enforces the restriction we want. To start,
the service must define a stub, that registers the application in the OS once the service is launched,
through the onStartCommand method. This stub is then responsible for the communication between
OS and app, regarding access control decisions. When defining the stub, the developer must define
an initial hook list, which in our case comprises only the camera hook. Then, and because this stub
follows an ASM specific interface that can be used in responding to every hook available in ASM, an
app developer must implement 65 hooks similar to the file permission hook (lines 12 through 15),
even though none of them will actually be used. The developer must then implement the camera hook,
which in our case simply requires us to check if the camera is currently being restricted, and comparing
the package name of the app accessing the camera, to the package name of the Facebook app. Note,
that in this example we follow a simplistic approach, where we rely on a simple boolean flag to check
if there are restrictions. A more robust solution should be used for more complex restrictions. On the
other hand, and because the security models enforced by these apps have a static nature, they do not
take into account restrictions only enforced during an hour. For this reason, and because the access
control decisions are made in the service, we need to create a mechanism capable of enforcing these
more dynamic restrictions, inside the service. With this in mind, in order for the camera restriction to
start, the application’s activities, must call the startLease method from this service. Note that in this
implementation, this method receives the duration of the restriction as parameter, which is then used to
97
1 public class ASMCallbackService extends Service {2
3 private static boolean restricted = false;4
5 private final IASMAPP.Stub mBinder = new IASMAPP.Stub() {6
7 @Override8 public String [] initialHookList () throws RemoteException {9 return new String [] { Hook.HOOK_CAMERA };
10 }11
12 @Override13 public int file_permission(int uid , int pid , String path , int mask) {14 return 0;15 }16
17 ...18 /* Implement 64 other methods similar to file_permission */19 ...20
21 @Override22 public int camera(int uid , String packageName) {23 if(restricted && packageName.equals("com.android.facebook"))24 return 0;25 else26 return -1;27 }28 }29
30 public void startLease(long duration) {31 Thread restrictionTimmerThread = new Thread(new Runnable () {32 @Override33 public void run() {34 try {35 Thread.sleep(duration);36 restricted = false;37 } catch(Exception e) {38 e.printStackTrace ();39 }40 }41 });42 restrictionTimmerThread.start();43 restricted = true;44 }45
46 public int onStartCommand(Intent intent , int flags , int startId) {47 IASMService asm = IASMService.Stub.asInterface(ServiceManager.getService("ASM"));48 try {49 asm.registerASM ();50 } catch (Exception e) {51 e.printStackTrace ();52 }53 return START_STICKY;54 }55 }
Listing E.1: Internet Restriction using ASM.
launch a thread, that simply sleeps during that time, and once it wakes up, terminates the restriction by
reseting the restriction variable.
Regarding the use of trust leases, Listing E.2 shows how to implement the restriction previously
described. The first difference we can identify is that unlike with ASM, with trust leases, an application
developer is free to define his restrictions in the code of his activities, without needing to rely on a
dedicated service. The second difference is the restrictions’ definition. While ASM requires an app
developer to define specific methods for each resource, the use of trust leases simply requires the
app developer to create and populate a Lease object, with the restrictions’ termination conditions, the
resources to be restricted, and the applications to be restricted. In this case, we defined a duration of
one hour, restricted the access to the camera, and defined a white list, where only the Facebook app can
access this resource. The initiation of the enforcement of the lease is then done through the startLease
98
1 public class MainActivity extends Activity {2
3 @Override4 protected void onCreate(Bundle savedInstanceState) {5 super.onCreate(savedInstanceState);6 setContentView(R.layout.activity_main);7
8 IASMAPP trubi = IASMAPP.Stub.asInterface(ServiceManager.getService("TRUBI"));9
10 Lease lease = new Lease();11 Date duration = new Date();12 duration.setHours (1);13 duration.setMinutes (0);14 duration.setSeconds (0);15 lease.setDuration(duration);16
17 Resource resource = new Resource(Lease.CAMERA);18 AccessList whiteList = new AccessList("White List");19 whiteList.addPackage("com.android.facebook");20 resource.addAccessList(whiteList);21 lease.addResource(resource);22
23 try {24 int leaseStartResult = trubi.startLease(lease);25 } catch (RemoteException e) {26 e.printStackTrace ();27 }28 }29 }
Listing E.2: Internet Restriction using trust leases.
method, with our lease object as parameter.
Overall, because of the dynamic restriction support, and the easiness of defining restrictions, we can
conclude that the use of trust leases to enforce the restrictions we are interested in, is easier to use,
when compared to the solutions provided by ASM. Additionally, just by looking at this example, ASM
would require an app developer to use the 55 LOC present in Listing E.1, plus the 256 LOC of the other
unused hooks, as well as 6 additional lines of code to link the apps’ activities to the service, totaling 317
LOC. On the other hand, the use of trust leases, requires only the 29 LOC present in Listing E.2. So, in
terms of development effort, in this case, the number of LOC required by ASM is superior by one order
of magnitude, when compared to the use of trust leases. On a side note, ASF [31], the other access
control hook API we described in Section 2.2, follows an approach very similar to the one described in
Listing E.1, so the development complexity would be similar as well.
Dynamic restriction negotiation One of the goals we established in Section 1, was that the Strapp
Middleware should provide an easy-to-use API that could help app developers in using trust leases. In
Appendix B we shown a code snippet (Listing B.1), that shows how to use the Strapp Middleware API,
from the lessor-side. To gain a better perspective on how easy it is to use this API, when compared to
other solutions, we present in Listing E.3, an example on how to use this API, in order for a lessor to
negotiate, and activate a trust lease, through network communication.
This example starts with the setup of the network adapter through its constructor, where we define
the IP and port of the lessee with which we plan to communicate with, as well as our username, and
certificates for the secure channel establishment phase of TLP. Similarly to the example given in Ap-
pendix B, we again make use of a button to start the negotiation of the protocol (line 20). We then
99
1 public class MainActivity extends Activity implements TLProtocolLessorHandshakeListener {2
3 private TLProtocolLesseeNFCAdapter protocolAdapter;4 private String lesseeIp = "192.168.0.100";5 private int lesseePort = 16000;6 private String username = "Nuno Duarte";7
8 @Override9 protected void onCreate(Bundle savedInstanceState) {
10 super.onCreate(savedInstanceState);11 setContentView(R.layout.activity_main);12
13
14 protocolAdapter = new TLProtocolLessorNetworkAdapter(lesseeIp , lesseePort , username ,MainActivity.this , MainActivity.this , R.raw.cert , "pass", R.raw.caCert , "pass", newint []{0});
15
16 Button startHandshakeButton = (Button) findViewById(R.id.startHandshakeButton);17 startHandshakeButton.setOnClickListener(new View.OnClickListener () {18 @Override19 public void onClick(View v) {20 protocolAdapter.start();21 }22 });23 }24
25 @Override26 public void lessorHandshakeCompleted(boolean success , String reason) {27 if(success) {28 Log.i(TAG , "In the next hour , only Facebook will be able to access the camera");29 protocolAdapter.stop();30 }31 else32 Log.i(TAG , "Lease Negotiation Failed: " + reason);33 }34
35 @Override36 public void leaseTimeNotification(int timeToFinish) {37 if(timeToFinish == 0)38 Log.i(TAG , "The camera restriction is over");39 }40 }
Listing E.3: Network lessor-side usage example of the Strapp Middleware API
implement the TLProtocolLessorHandshakeListener interface’s methods, one to notify the lessor of
the start of the restrictions, in case of a successful negotiation, and another to notify him about the
termination of the restrictions. For space reasons, we hide the onPause and onRestart methods, which
handle the protocol adapter in a way similar to the one used in Appendix B.
The 40 LOC used in Listing E.3 would be enough to transparently negotiate the restriction we de-
scribed in the beginning of this Appendix. In this example, we do not build the trust lease containing
the restriction, because, in TLP, the building of the Lease object takes place on the lessee side. If we
compare the development complexity of enforcing the previously described restriction, we can conclude,
that the Strapp Middleware API requires less work (40 LOC) when compared with the enforcement of
the same restriction, using ASM (317 LOC). Note, that if we wanted to negotiate restrictions, like we
did in this example, using ASM, we would not only need to adapt the code from Listing E.1, but we
would also need to implement a secure channel approach to receive the restrictions from the external
party. Additionally, ASM does not provide any attestation guarantees, regarding the restrictions currently
enforced, unlike what happens with TLP and TrUbi. For instance, because ASM supports multiple apps,
and adopts a consensus approach, even if the app enforced the restriction we want, if another app
denied access to the camera, an over restrictive restriction would be enforced instead.
100
Appendix F
Lessee Adoption Study
In this appendix, we present the results gathered from our lessee adoption study. Essentially we ask
professors, meeting organizers, and movie theater managers, to give some insights on the effects of
wrong mobile device usage in exams, meetings and movies, respectively. Then, we present our strapps,
and ask lessees to give their opinion on the adoption and the effectiveness of these strapps in mitigating
these issues. We now present the methodology followed in each lessee adoption study.
mExam – Professors Study Methodology This questionnaire was conducted on 10 professors of
the Department of Computer Science and Engineering of IST. In this questionnaire, we first asked the
frequency of student cheating cases, and presented our mExam app as a solution for students to answer
exams in their devices, while preventing them from cheating. Afterwards, we asked for professors’
overall perception of the app, if they thought it could bring new forms of student cheating, and if the use
of a mobile application to answer exams could affect the evaluation process’s credibility. Additionally,
we asked if professors thought the execution of an exam in a mobile device would disperse students’
focus, if the long exposure to a stressful situation associated to the relatively small screen size could
be uncomfortable for students, and how practical did they thought the app would be (e.g., long text
questions, calculus-related questions). We concluded by asking if it were up to professors, would they
adopt the app for their exams, how hard did they believe it would be to disseminate the app to a whole
school, and if the savings in test sheets and exam statement printing would be an additional incentive
for students and school to adopt the app.
mMeeting – Meeting Organizers Study Methodology The conduction of these questionnaires faced
the same difficulties we had in the mMeeting user tests and the mMeeting - meeting attendants adoption
study, i.e, we had trouble convincing companies in answering these questionnaires. For this reason we
followed the approach of the attendant adoption study, and distributed these questionnaires amongst
former colleagues who are now employed, which then distributed them to work colleagues who usually
organize meetings. Still because of the difficulties in finding people available to respond, the number
of responses was five, all from different companies. In this questionnaire, we first asked whether these
companies had employee mobile device management systems, in order to understand if they enforced
101
some kind of internal enterprise policies on employee’s devices. Then, we asked what kind of mobile
device-related instructions did meeting organizers / hosts gave meeting attendants at the beginning of
those meetings, i.e., whether hosts instructed attendants to mute or turn off their devices. We also
sought to find out if it was common for attendants’ devices to interrupt meetings (e.g., an attendant
who forgets to mute his device, and then receives loud notifications), and if attendants usually used
their devices inappropriately (e.g., an attendant that uses social media or game apps). Additionally,
we presented meeting hosts our mMeeting app, and asked them if they would use / impose it in their
meetings to prevent these disturbances. We also asked what their thoughts were on the impact of
such an app in preventing such disturbances, and concluded by asking them about how opened would
they think meeting attendants would feel in adopting our app, if they would fear for their privacy, and if
the prevention of using non-meeting-related apps could be seen as an attack on users privacy and well-
being. On the other hand, we also used this questionnaire to address information leaks. We asked hosts
whether they feared meeting information leaks, if the companies dictated rules of conduct regarding
meeting information, and if hosts perceived mobile devices as weapons for meeting information leaks,
because of their sensors and communication technology (e.g., microfone, camera, wifi). Finally, we
asked what hosts felt was the risk of such leaks happening in their companies, if they adopted mMeeting
if it could prevent those leaks, and how opened do they believe meeting attendants would feel in adopting
mMeeting to address this issue.
mTicket – Movie Theater Managers Study Methodology This questionnaire was conducted on 5
different movie theater managers from the area of Lisbon. While 2 were small movie theaters, the
other 3 belonged to a national movie theater chain (Cinema City). With this questionnaire, we first
tried to understand whether these movie theaters had remote ticket purchase systems, and how did
managers thought the future would be, i.e., if these remote systems would replace physical ticket booths.
Then, we tried to know more about the frequency of disturbances caused by wrong phone usage (i.e.,
phone ringing and high brightness screens), as well as the frequency of complaints resulting from those
situations. We also tried to know about the frequency of spectators that use their devices to record
movies. For each of these three situations we asked managers to classify the seriousness of these
problems as well. Additionally, we presented managers with our mTicket app, and asked them if they
thought their movie theater companies would adopt it. We also asked what their thoughts were on
the impact of such an app in preventing such disturbances, and concluded by asking them about how
opened would they think users would feel in adopting our app, if they would fear for their privacy, and if
they believed ticket discounts could ease the adoption of such a solution.
F.1 mExam – Professors Study Findings
In terms of student cheating, 10% of professors say they never had a case of a student cheating, 30%
say these situations are rare, 40% of professors claim these situations happen only once a year, 10%
say it happens every semester, and the remaining 10% say it happens in every test and more than once.
102
Regarding mExam, 60% of professors enjoy the idea of an app that allows students to use their devices
to answer exams (given the trust lease guarantees), 10% feel neutral, and 30% believe it would only
bring more problems to the evaluation process. Even so, 80% of professors believe that an app such
as mExam would bring yet more forms of students to cheat. Additionally, 70% believe that the adoption
of a mobile app to answer exams would affect the evaluation’s process credibility. In terms of student
comfort, 20% of professors believe it would be hard for students to focus on the exam given other
personal matters usually associated to smartphones, and 70% believe that the long exposure to the
small size screen together with the high stress situation would bring discomfort to students. Regarding
the practicality of answering exams in a smartphone, 90% of professors said it would not be practical
for long answer questions, 60% said it would not be practical for calculation questions, and 80% said it
would not be practical for questions that depended on textual context not present in the current screen.
All things considered, 50% of professors would adopt mExam, and the remaining 50% of professors
would not adopt mExam for exams, but they would adopt it for simple class surveys. In terms of app
dissemination, 50% of professors said it would be hard to spread the use of the app to the whole school,
30% believe it could be done, and 20% think it would be easy to do so. Moreover, 70% of professors
believe the savings in test sheets for students and the savings in printing exam statements for the school
would be an incentive for both parties to adopt mExam. One of the professors said the biggest incentive
for professors would be the reduction of logistic needs, as they would not have to print exam statements,
and could even grade parts of exams (multiple choice questions), automatically. On the other hand 3
professors said the system would only work if everyone had a smartphone, which difficults the adoption
of the system in this case.
F.2 mMeeting – Meeting Organizers Study Findings
Because most respondents’ companies were small to medium sized, with the exception of CGD, none
of the companies involved had mobile device management systems to control employees’ devices. In
terms of meeting habits, none of the meeting organizers usually tell attendants to turn off their devices at
the beginning of meetings, as they rely on attendants’ common sense. Still, 4 out of the 5 respondents
admitted that smartphone related disturbances are common in their meetings. Moreover, 3 admitted that
some attendants usually use their devices inappropriately during meetings (e.g., use social media apps).
From the 5 respondents, only 2 said they would impose the use of an app like mMeeting, to mitigate
these disturbances in their meetings. The other respondents eithet claimed that an app of this nature
does not make sense in non sensitive colleague meetings, or that its hard to enforce the use of the
app in meetings with clients. From the 5 attendants, 3 believed the use of an app like mMeeting would
reduce the number of smartphone related disturbances in meetings. These 3 respondents also believed
that the app would provide minor productivity increases in meetings. In terms of attendants’ openness
to adopt this app, all 5 respondents agreed that attendants would not be very opened to adopt it. On the
one hand, respondents claimed that attendants would fear for their privacy, as they would not be willing
to lend the control of their devices to other people. On the other hand, while the sound restrictions were
103
012345
Device ringingoccurences
Device ringingreports
Device brightnessoccurences
Device brightnessreports
Camera useoccurences
Rare
Happens
Frequent
Like
rtSc
ale
Figure F.1: Movie disturbance occurrence and report frequency.
interesting in the point of view of respondents, restricting the use of certain apps in attendants devices
would simply be too intrusive for attendants, which would make them less open to adopt the app.
Regarding sensitive meeting information, only one respondent claim he had real concerns regard-
ing possible leaks. Curiously, the respondent in question was not the one from the bigger company.
From the 5 respondents, none mentioned any rules of conduct dictated by their companies regarding
meeting information. Additionally, although 3 out of the 5 attendants considered the possibility of the
occurrence of meeting information leaks as highly unlikely (1 on a Likert scale), one said it would be
difficult to happen (2 on a Likert scale), and one admitted it could happen (3 on a Likert scale). From the
5 attendants, 4 considered mobile devices as potential weapons for attendants with meeting information
leakage intents. Regarding the adoption of an app like mMeeting to mitigate sensitive information leak-
age, only one respondent, the one who has concerns regarding the issue, admitted he would impose
the use of the app in his meetings. In terms of adoption, although 3 respondents said attendants would
not or would be very little opened to adopt the app (1 and 2 on a Likert scale respectively), 2 admitted
attendants might be opened (3 on a Likert scale) considering the importance of the issue at stake.
F.3 mTicket – Movie Theater Managers Study Findings
As it was expected, while the two smaller movie theaters have no remote ticket purchase systems, the
national movie theater chain has such a system but provides no mobile application to purchase tickets.
Still, between the 3 chain theaters, while 2 managers claim that the distribution between people who buy
tickets online and people who do it in physical ticket booths is of 20% and 80% respectively, the other
manager says that more than 90% of the people who buy movie tickets, do it from physical booths. In
terms of the future of ticket booths, while 3 managers said they would disappear in the future, 2 said that
machines can fail, and that physical booths could not disappear for that reason.
Figure F.2 shows the frequency with which movie spectators disturb audiences by either having their
devices ring, using their devices with high brightness or using the camera during a movie. This figure
confirms that although the device ringing and high brightness disturbances have a tendency to occur,
spectators rarely report mobile device related disturbances. On the other hand, we also concluded that
these disturbances have a tendency to occur more in chain theaters, as the smaller theaters have an
older audience. Additionally, the use of the camera during a movie is much more rare. Still, one of the
managers said the mTicket app would be a good solution particularly for teenagers between 12 and 16
years old, because it is common for them to take selfies at the beginning of the movie.
104
Not an issue 20%
Serious issue 80%
(a) device ringing
occurrences
(b) device brightness
occurrences
Not an issue 20%
Serious issue 80%
Serious issue 20%
Very serious issue 80%
(c) camera use
occurrences
Figure F.2: Movie disturbance seriousness.
While there are currently no laws that punish device ringing and high brightness disturbances, in
Portugal, using a camera inside a movie theater is considered a felony. This fact helps us explain why
80% of managers believe the use of the camera to be a very serious issue. On the other hand, while
most managers considered the phone ringing and high brightness disturbances to be a serious issue,
one of the managers did not consider it a problem at all. It is important to note however, that the manager
in question ran a small movie theater, where the audience is older and the number of disturbance cases
extremely rare.
Overall, all 5 managers said they believed that their movie theater administration would adopt an
app like mTicket. Still, out of the 5 managers, 3 said they could live without the app (as they do now),
but 2 said the app would improve users’ experience. In terms of user adoption, all managers showed
scepticism by saying that users would not be very opened to adopt the app. In fact from the 5 managers,
3 said users would not be opened at all, as they would fear for privacy issues. On the other hand, all 5
managers agreed that ticket discounts could be a good incentive for users to adopt the app.
F.4 Summary of Adoption Study Findings
Overall, lessees confirmed that most of the situations we address in the mExam, mMeeting and mTicket
scenarios are common, i.e., it is recurrent for students to cheat, meeting attendants to disturb meetings
with their devices, and movie spectators do disturb movie audiences through wrong mobile device us-
age. Regarding meeting information leaks, only one meeting organizer said his company had concerns
regarding this issue.
In terms of adoption, half of the professors said they would adopt the mExam app, even though
most of them believe the app could introduce new forms for students to cheat, and could even affect
the evaluation’s process credibility. Regarding mMeeting, most meeting organizers said they were not
inclined to adopt the app, as they thought the app would be to strict for colleague meetings, and simply
hard to use in client meetings, as they believe it to be hard for a meeting host to give orders to clients. In
relation to mTicket, all the movie theater managers’ inquired believed their administrations would adopt
the app, but admitted that without proper incentives (e.g. ticket discounts), users would simply not adopt
the app.
105
106