DBStore: A TrustZone-backed Database Management System for

Mobile Applications

Pedro S. Ribeiro

, Nuno Santos

and Nuno O. Duarte

INESC-ID / Instituto Superior T

ecnico, University of Lisbon, Lisbon, Portugal

Max-Planck Institute for Software Systems, Saarbruecken, Germany

Keywords:

Trusted Execution Environments, ARM TrustZone, Security, Android Applications, Mobile Ticketing.

Abstract:

ARM TrustZone technology has been widely use to enhance the security of mobile devices by allowing for

the creation of Trusted Execution Environments (TEE). However, existing TEE solutions tend to struggle with

a trade-off between security and functionality: they either expose a larger attack surface to favor dynamic

code loading inside the TEE, or depend on the static deployment of trusted services inside the TEE which is

more cumbersome and error-prone to maintain. This paper proposes the deployment of a trusted service which

aims to serve a broad range of applications by offering secure database storage capability inside the TEE. We

present DBStore, a TrustZone-backed database management system for mobile applications. Applications can

create and operate DBStore databases inside a TEE that provides conﬁdentiality and integrity protection of

databases and respective SQL queries without depending on the integrity of the mobile OS. We present a case

study where DBStore is used in order to thwart existing attacks in HCE-based mobile ticketing applications.

1 INTRODUCTION

Trusted Execution Environments (TEE) have played

an increasing role within the mobile security land-

scape. A TEE is an isolated execution environment

which can provide conﬁdentiality and integrity pro-

tection of code and data. Its appeal comes from the

fact that these properties can be enforced against a

strong attacker with the ability to compromise the

OS (e.g., a rootkit). For this reason, a TEE can be

a very important resource for protection of sensitive

code and assets. In the mobile world, a TEE tends

to be created by special hardware available in ARM

processor-based devices: ARM TrustZone. Examples

of commercially deployed systems that use TrustZone

for protection of data and code inside a TEE include

Hardware-backed Android Keystore (Android, 2018)

and Samsung Knox (Samsung, 2013).

Both academia and industry have pushed the de-

velopment of TEE solutions that can be both func-

tionally rich and secure. Achieving both goals, how-

ever, is challenging. In one line of work, the idea

is to develop speciﬁc security services that reside in-

side the TEE (Liu and Cox, 2014; Sun et al., 2015b).

Hardware-backed Android Keystore is such an exam-

ple for storing cryptographic keys. Since the TEE

runtime system can be customized to offer a single

service, the resulting trusted computing base can be

very small, which favors security. Furthermore, since

it provides a narrow API to OS and mobile apps, the

attack surface is also reduced. A downside of this

approach is that it requires ﬁrmware changes for ev-

ery newly deployed service, which discourages their

wider adoption by device manufacturers.

At the other end, we ﬁnd TEE runtime systems

which aim to allow application code to be loaded and

executed inside the TEE itself. Examples of such sys-

tems include Samsung Knox, the Trusted Language

Runtime (TLR) (Santos et al., 2014), and systems that

implement GlobalPlatform’s TEE speciﬁcations (opt,

). Because these systems allow dynamic code loading

at runtime, it means that new security services can

be deployed without the need to change the device

ﬁrmware. However, although the application code is

deployed inside independent TEE-hosted sandboxes,

the system’s attack surface increases. Furthermore,

in some cases, such as Samsung Knox’s, the trusted

computing base is very large. Both these factors may

weaken the overall security of the system.

Our goal is to devise an intermediate solution that

allows mobile applications to take advantage of the

beneﬁts of TEEs without (i) allowing for dynamic

loading and execution of third-party application code

inside the TEE, and (ii) requiring frequent ﬁrmware

396

Ribeiro, P., Santos, N. and Duarte, N.

DBStore: A TrustZone-backed Database Management System for Mobile Applications.

DOI: 10.5220/0006883603960403

In Proceedings of the 15th International Joint Conference on e-Business and Telecommunications (ICETE 2018) - Volume 2: SECRYPT, pages 396-403

ISBN: 978-989-758-319-3

upgrades to mobile devices. To this end, we pro-

pose a single trusted service aimed to provide general-

purpose database hosting inside the TEE. Such a ser-

vice would provide a narrow interface through which

mobile applications can preserve their databases se-

curely and issue database queries to be executed in-

side the TEE while preserving the conﬁdentiality and

integrity of their execution state. With our solu-

tion, although mobile applications cannot run arbi-

trary code inside the TEE, they enjoy a great degree

of ﬂexibility in managing their data securely through

the possibility to issue sophisticated database queries.

This paper develops this idea and presents the de-

sign and implementation of DBStore, a TrustZone-

backed database management system for mobile ap-

plications. DBStore provides an SQL interface to

application-custom databases. A simple-to-use API

masks the security protocols designed to defend

against rollback and replay attacks, and provide con-

ﬁdentiality and integrity protection of both databases

and SQL commands, including inputs and outputs. In

our current prototype, we adopted SQLite as our SQL

engine running inside the TEE. By providing an SQL

interface, we aim to offer a programming model fa-

miliar to application developers. DBStore was care-

fully designed in order to provide secure remote ac-

cess to the databases. By leveraging TrustZone for

isolation purposes, DBStore can protect applications’

databases in the presence of a powerful attacker which

can control the local operating system.

To demonstrate our system, we present a case

study in which we apply DBStore in secure mobile

ticketing applications. We present the design of an

existing HCE-based mobile ticketing app based on

Android keystore, and analyze its vulnerabilities. We

then show how DBStore allows to mitigate such at-

tacks with simple DBStore SQL transactions. Al-

though we have focused on a single use case, we en-

vision DBStore to be used for a wide range of appli-

cations, e.g., e-health, mobile payments, etc.

2 BACKGROUND

First, we present some necessary background infor-

mation for both our threat model and system design.

2.1 ARM TrustZone Technology

ARM TrustZone is a security extension for ARM pro-

cessors that provides a hardware-level isolation be-

tween two execution domains: normal world (NW)

and secure world (SW). Compared to the NW, the SW

has higher privileges, as it can access the memory,

CPU registers and peripherals of the normal world,

but not the other way around. Isolation is enforced by

checking and controlling the state of the CPU through

a NS bit, and partitioning the memory address space

into secure and non-secure regions.

Interaction between worlds requires a world

switch operation triggered by the SMC instruction.

TrustZone devices equipped with a secure boot mech-

anism provide integrity and authenticity protection of

the SW software. The binary of the SW software must

be part of the device ﬁrmware and signed by the de-

vice manufacturer. When the device is powered, the

processor enters SW, jumps to the initialization proce-

dure of the SW software, which then switches to NW

and hands over control to the OS bootloader.

2.2 TrustZone-based TEE Systems

TrustZone is used in millions of ARM-based mobile

devices for the creation of Trusted Execution Envi-

ronments (TEE). A TEE consists of an isolation en-

vironment in which trusted applications can execute

without the interference of the local (untrusted) oper-

ating system. When based upon TrustZone technol-

ogy, the TEE typically resides in the secure world and

the rich operating system lives in parallel in the nor-

mal world. This strict separation between both envi-

ronments ensures that a potentially compromised OS

cannot access the TEE’s internal state.

We distinguish two types of TEE architectures:

TEE kernel (opt, ; Fitzek et al., 2015) or TEE ser-

vice (Sun et al., 2015a). In the ﬁrst case, the TEE

provides an interface to the normal world that allows

for trusted applications to be installed and executed

inside the TEE. On the other hand, TEE services ex-

pose only a function call interface to the normal world

and implement a speciﬁc application. They do not al-

low for dynamic loading of third-party trusted appli-

cations inside the TEE, which reduce exposure of po-

tential vulnerabilities to an attacker when compared

to the TEE kernel architecture.

2.3 A Case for TrustZone-backed DBs

In spite of the security beneﬁts of the TEE service ar-

chitecture, an important downside lies in its inﬂexibil-

ity: in order to deploy a new trusted application inside

the TEE, end-users’ devices need to be upgraded with

new ﬁrmware containing the application binary and

be rebooted so that the new application can be prop-

erly instantiated inside the secure world upon boot.

However, ﬁrmware upgrades tend to be error-prone

and quite cumbersome for the end-users. To alleviate

this problem, the question we raise is whether there

DBStore: A TrustZone-backed Database Management System for Mobile Applications

397

exists a class of applications that could beneﬁt from

a common general trusted service so that the applica-

tions could be executed inside the normal world by

relying only on this single trusted service for protect-

ing this sensitive state.

To answer this question, we propose a new trusted

service – DBStore – aimed at maintaining and secur-

ing application databases inside a TrustZone-backed

TEE. With DBStore, we decouple the persistent state

of the application from the logic of the application,

and provide a way to secure its persistent state only.

As a result, the logic of the application can reside

in the normal world thereby precluding the need to

upgrade the devices’ ﬁrmware. On the other hand,

since databases are widely used, many different appli-

cations can beneﬁt from DBStore. More speciﬁcally,

our goal is to serve a particular class of applications in

which a remote client may need to access and manip-

ulate application data stored locally while requiring

high level protection, such as secure mobile ticketing,

mobile payment, and e-health applications.

2.4 Security Goals and Threat Model

In the scenarios we envision, distributed applications

consist of two parts: a client side which is kept under

the control of an application provider, and a counter-

part mobile side which runs on users’ devices. De-

pending on the speciﬁc application, the remote client

can be implemented, e.g., by a remote cloud server, a

nearby embedded device, etc. The mobile application

can solicit storage space at the DBStore for storing

dabatases and should interact with its databases using

standard SQL statements.

DBStore must give application providers strong

assurances about the integrity and conﬁdentiality of

the guest databases. It must prevent an adversary from

reading or altering not only the contents of database

records, but also the inputs / outputs of SQL trans-

actions issued by the clients. It must defend against

replay attacks allowing for the re-execution of past

legitimate SQL, and against rollback attacks, which

attempt to revert the database state to an old version.

The adversary can intercept and modify messages

exchanged between client and DBStore, either while

in transit over the network, or by controlling the mo-

bile application or the mobile OS. Such control can

be gained, e.g., through malware exploits, or device

routing. We assume, however, that the adversary can-

not perform physical attacks to the TrustZone-enabled

mobile platform. Hardware and cryptographic primi-

tives are considered to be correct and DBStore com-

ponents residing in the SW belong to the trusted com-

puting base. Side-channel attacks are not in scope.

Normal World

DBStore Manager

SQL

Engine

Secure World

DBStore

Mobile Device

Client Application

DBStore Lib

Remote Client

Mobile Application

DBStore Lib

ARM TrustZone Hardware

Rich OS

DBStore Driver

Internet

Figure 1: DBStore architecture: arrows represent invoca-

tion ﬂow of an SRPC.

3 DESIGN

Figure 1 presents a high-level architecture of DB-

Store. The SW is used to implement a TEE where

the DBStore resides; OS and mobile applications run

in the NW. Thus, mobile applications and OS have no

direct access to the DBStore state. The client applica-

tion interacts with the mobile application by submit-

ting SQL commands to the remote databases hosted

inside the DBStore. The databases are securely main-

tained by the DBStore, which has exclusive access to

the databases’ state and is responsible for the execu-

tion of the SQL statements submitted by clients. The

DBStore ensures that the SQL commands issued by

the clients are securely forwarded to and executed on

the intended database and the results routed back to

the respective client.

SQL commands are issued to a database residing

on a remote DBStore by invoking SQL Remote Pro-

cedure Calls (SRPC). To this end, an API is provided

by the DBStore library. An SRPC comprises one or

more SQL statements, such as “create table”, “insert

into”, and ”select” commands, and are performed as a

single transaction. An SRPC can be parameterized by

inputs provided by the client application, and can op-

tionally return an output to the client application. The

DBStore library and DBStore manager implement se-

curity protocols which involve the exchange of infor-

mation in the form of speciﬁc Protocol Data Units

(PDUs). An SRPC is translated into PDUs that are

sent over the network to the mobile application. The

mobile application must then issue a request to a DB-

Store driver in order to forward the PDUs to DBStore.

This driver is required because the context switch to

SW needs kernel privileges. DBStore, then, handles

the PDUs, assigns the SRPC commands to the inter-

nal SQL engine, and returns the results all the way

back to the client. In our system, the SMC instruction

is invoked by the DBStore driver to enter the secure

world and by the DBStore to exit and return to the OS.

SECRYPT 2018 - International Conference on Security and Cryptography

398

Next, we provide additional details of our system.

3.1 Initialization Protocol

Before deploying databases on a remote DBStore, a

client must ﬁrst verify that the remote peer runs a le-

gitimate DBStore inside a TrustZone-enabled device.

Conversely, the DBStore must be able to authenticate

the client and implement an authorization policy that

prevents other applications from accessing the remote

client’s databases. To obtain these guarantees, the

client and the remote DBStore must ﬁrst perform an

initialization protocol by exchanging two PDUs: M

and M

(see Table 1).

To prove that the DBStore service is authentic

and resides inside a valid TrustZone-enabled environ-

ment, the ﬁrst message (M

) contains a challenge, a

nonce n

, that the DBStore must sign with a valid

attestation key (T K). The attestation key is a key-

pair that the device manufacturer must embed into the

device ﬁrmware. The private part T K

−

is accessible

within the SW (if the secure boot passes). If DBStore

is able to sign n

with such a key, then it means that

the DBStore software has not been tampered with and

runs inside the SW. The DBStore must then sign n

with T K

−

and send the signature along with a certiﬁ-

cate (C

T K

) that contains the public key TK

required

to check the signature. This certiﬁcate is issued by the

device manufacturer in order to authenticate the attes-

tation key. Thus, by checking the signature against

a legitimately certiﬁed attestation key, the client can

verify the authenticity of the remote DBStore.

To authenticate the remote client and restrict ac-

cess to the local databases by alien applications, M

contains nonce n

, an application ID and both are

signed with the private part AK

−

of application key-

pair (AK). This keypair must be generated by the ap-

plication provider and the private part must be kept se-

cret by the client. The public part AK

is included in

the mobile application package. Upon receiving M

DBStore can validate the signature by obtaining AK

from the mobile application thus authenticating the

client. To ensure that future interactions remain mu-

tually authenticated, a session key (SK) is exchanged

as a token of successful client authentication and ser-

vice remote attestation. This is reﬂected in message

which includes a session key SK created by the

DBStore and encrypted with AK

. This result is also

included in the signature by T K

−

This way, the DBStore can ensure the authentic-

ity of the client endpoint, because only the legitimate

client application holds the private key AK

−

which

will enable the session key to be decrypted. On the

other hand, by checking the signature of M

, the

Table 1: DBStore protocols: C: remote client, S: DBStore.

Initialization Protocol

) C → S: hAppId, n

−

) S → C: hn

, {SK}

T K

−

, C

T K

SRPC Invocation Protocol

) C → S: n

, {SrpcReq}

, hmac(K

)

) S → C: (M

4.a

) S → C: n

, Ok, {SrpcRes}

, hmac(K

)

4.b

) S → C: n

, Fail

Resync Protocol

) C → S: n

, Resync, hmac(SK)

) S → C: n

, {i, salt}

, hmac(SK)

client can be assured about the authenticity of that

session key (i.e., that it was issued within a legiti-

mate DBStore-enabled device) and of the freshness

of the session key (because the tuple includes nonce

which has been chosen by the client itself). The

session key is then crucial in securing SRPCs.

3.2 SQL Remote Procedure Calls

After the initialization, the client can invoke SQL

Remote Procedure Calls (SRPC) on DBStore. Each

SRPC generates a message to the DBStore (M

which will then return one of two possible messages:

4.a

if the request message was well formed, or M

4.b

otherwise (see Table 1). The SRPC request message

includes ﬁeld SrpcReq which contains the SQL

commands and inputs to be executed on the remote

DBStore. The SrpcRes ﬁeld is included in message

4.a

and contains the execution output to be sent to

the client. For conﬁdentiality protection, SrpcReq and

SrpcRes are encrypted with a symmetric key shared

between the client and the DBStore. For message in-

tegrity protection, the same key is used to generate

HMAC codes for the whole message. Nonce n

helps

the client detect replay attacks of old M

messages.

Although the symmetric key shared between both

endpoints is the session key SN, this key is not used

in messages M

and M

4.a

. Instead, the client creates

a new symmetric key K

for each invoked SRPC. K

generated by calculating a hash of SK concatenated

with a counter value i, which is initialized to zero

and incremented for every SRPC request issued by

the client. To determine K

, the DBStore must also

keep a local counter for the i value. To calculate the

key of an incoming SRPC message, all the DBStore

has to do is to append i to SK, and compute the hash

of the result, yielding K

, which is then used to de-

crypt SRPC #i and encrypt the corresponding SRPC

response. After submitting the response to the client,

the DBStore increments its local i counter.

This mechanism serves two purposes. First, it pre-

DBStore: A TrustZone-backed Database Management System for Mobile Applications

399

vents replay attacks of old SRPC requests. Since the

DBStore uses a single key K

for each request, then

old messages (i.e., corresponding to request numbers

less than i) cannot be decrypted. Furthermore, the i

counter of the DBStore is implemented using a Trust-

Zone monotonic counter, thereby preventing an ad-

versary from decrementing i. This mechanism also

avoids overuse of the session key SN. By generating

a new symmetric key K

, we reduce the exposure of

SN thereby enhancing the overall system security.

If for some reason the client gets out of sync with

the DBStore about the current counter value, and the

legitimate client sends a request encrypted with K

different than K

expected by the DBStore (i.e., j 6= i),

the DBStore will not be able to properly decrypt the

SRPC request ﬁeld of message M

and then returns a

failure message (M

4.b

). To overcome this issue, the

client triggers a resync protocol by which the DB-

Store will return the current i value encrypted with

the session key (see M

and M

in Table 1).

3.3 Protection of DBStore Databases

To secure the DBStore databases at rest, we leverage

the secure storage allocated to the SW. We use addi-

tional TrustZone mechanisms to prevent rollback at-

tacks and protect data conﬁdentiality. In particular,

we use secure monotonic counters to keep track of

the most updated version of DBStore databases. Ev-

ery time a database is updated, its version number is

incremented and written into the database, and the se-

cure monotonic counter is also incremented. If the

device is rebooted and the database is replaced with

an older version, the version number of the recovered

database and the current value of the counter will be

inconsistent, forcing DBStore to raise an exception.

To preserve conﬁdentiality, the DBStore databases

(and associated version numbers) are encrypted with

a symmetric key which is then sealed, i.e., encrypted

with a key which is released only if the secure boot is

successful. This prevents an adversary from retriev-

ing the encryption key and decrypt the database.

3.4 Prototype Implementation

We implemented an initial DBStore prototype for the

Freescale NXP i.MX53 Quick Start Board. The DB-

Store runs inside the SW and consists of several com-

ponents. First, it comprises a small kernel responsi-

ble for memory management, thread execution, and

world switch operations. To this end, we adopted

the base-hw custom kernel from the Genode Frame-

work (gen, ), which comprises a 20 KLOC codebase.

The logic responsible for DBStore management is im-

plemented in C. It is also responsible for the manage-

ment of symmetric cryptographic keys, and provide

cryptographic functions. To maintain a reduced code

base, we used the AES-128 implementation from the

mbed TLS library as the symmetric key encryption al-

gorithms. We also adapted SHA-256 from mbed TLS

to calculate cryptographic hashes.

As for the SQL engine implementation, we ported

SQLite. For database persistence, we implemented

a secure storage service that mediates access to a

ﬁlesystem residing in the SW, through an API similar

to that used by user level programs and libraries such

as SQLite. More speciﬁcally, we conﬁgured a dedi-

cated partition as secure in Genode’s partition man-

ager (part blk). In order to manage ﬁles in this parti-

tion, we used Genode’s dde rump port of a rump ker-

nel, specially crafted with a ﬁlesystem driver.

For the NW, we took advantage of Genode’s Vir-

tual Machine Monitor (VMM) to run a paravirtualized

Android OS, which leverages a custom-made Linux

kernel for Genode. With respect to the interface be-

tween NW and SW, we created a Linux kernel mod-

ule offering an API that triggers the necessary world

switches through SMC invocations.

4 CASE STUDY

In this section, we study a proprietary HCE-based mo-

bile ticketing application for public transports with

the purpose of illustrating how DBStore can thwart

some of its fundamental security limitations. HCE,

which stands for Host Card Emulation, was intro-

duced in the Android OS and it allows mobile applica-

tions to maintain software emulated contactless cards

and communicate with NFC readers.

4.1 HCE-based Mobile Ticketing

HCE-based mobile ticketing is penetrating the realm

of public transports, such as trains and buses. In a

typical workﬂow, a passenger installs the application,

signs up with a username and password, logs in, and

purchases a virtual card with credits for an amount of

trips. This information is then downloaded and main-

tained inside an HCE-emulated card by the mobile

app. To perform a trip, the passenger must validate

the card by swiping the mobile device in front of the

NFC-enabled reader. The reader communicates via

NFC with the app, which checks if enough credits ex-

ist in the virtual card. If so, it decrements the credits

available and tells the reader to authorize the trip.

From a security point of the view, the main con-

cern is to prevent fraudulent passengers from travel-

SECRYPT 2018 - International Conference on Security and Cryptography

400

ing without credit. Thus, it is necessary to prevent

forging new virtual cards, stealing virtual cards from

other passengers, incrementing credits of legitimately

purchased virtual cards, and double spending credits

of valid virtual cards. Since the passengers’ mobile

device may be disconnected from the network, ticket

validation must be able to operate ofﬂine securely,

by relying only on NFC communication with nearby

readers and on the mobile devices’ local resources.

Card Purchase: When a ticket is purchased, the

server generates a secret serial number for the new

virtual card. This secret is cryptographically signed

and sent to the mobile application along with the num-

ber of associated trip credits over an authenticated

HTTP connection. The signature is checked against

the public key of the ticketing server, and the virtual

card’s data (serial number and credits) are written on

a private ﬁle owned by the application. This ﬁle is en-

crypted with a key K protected in Android keystore.

Card Validations: By means of a handshake between

card reader and mobile application, the card reader

is authenticated and a session key is exchanged. The

card reader sends a validation request message to the

mobile application via the Android’s HCE service.

The app decrypts the virtual card ﬁle with key K

(released by the Android keystore), and checks that

enough credits exist. If so, it sends to the reader the

serial number of the virtual card encrypted with the

session key and updates the local ﬁle with a decre-

mented credit. For every update, the ﬁle is encrypted

with a new key K that replaces the previous one.

Card Recharge: The mobile application connects to

the ticketing server over HTTPS. When the payment

is ended, the mobile application learns the amount

of credits just acquired and updates the local ﬁle se-

curely like in a card validation.

4.2 Existing Security Vulnerabilities

Despite the security mechanisms described above,

several attacks can be performed by an adversary with

the ability to control the operating system of a passen-

ger’s mobile device. This can be achieved by acciden-

tal rootkit infection or by intentional device rooting.

Next, we describe some critical attacks and their im-

pact to the overall application security. We consider

hardware-backed Android keystore implementations.

Attack 1 – Rollback keystore ﬁles and card data: The

encrypted key K is encrypted with the public part of

a keypair and persisted inside an Android keystore

ﬁle located in /data/misc/keystore/user 0. The key-

pair ﬁles are encrypted with a master key that is main-

tained inside the TEE and that cannot be retrieved by

typical means. Both encrypted items, ticket data and

key K are stored on the application data folder. Thus,

an adversary with root privileges can backup all these

ﬁles, and replace them with older copies. This attack

enables an attacker to travel using a single card for as

long as its serial number is not blocked.

Attack 2 – Steal keypair with rogue app: This attack

leverages the fact that Android keystore preserves the

keypairs of a given application in two ﬁles: “(App’s

User ID) USRPKEY (Key Entry Alias)” and “(App’s User

ID) USRCERT (Key Entry Alias)”. The owner of the

keypair is identiﬁed by the (App’s User ID) bit. To

launch the attack, the adversary starts by creating a

KeyStealer application aimed to retrieve the keypair

of the mobile ticket app from the keystore ﬁle and

write it elsewhere unencrypted; with that keypair, K

can be obtained and hence the raw card data. Then,

it is only necessary to change the User ID of ﬁles

generated for the HCE mobile ticketing app to match

KeyStealer’s. Android keystore will be tricked into

believing that the KeyStealer app owns that keypair

and will decrypt it using the master key.

Attack 3 – Reverse engineer the mobile app: By using

reverse engineering tools, an attacker can modify the

mobile app so as to prevent credit decrementation at

each validation. Since the card reader devices have

currently no means to authenticate the mobile end-

point, they would not be able to distinguish between

a correct and a modiﬁed application.

4.3 Overcoming Existing Limitations

The attacks described above are possible because the

security depends on the integrity of the OS. This sec-

tion describes how to thwart these attacks using DB-

Store. In our solution, rather than preserving the vir-

tual card data inside an encrypted ﬁle (and the respec-

tive encryption key secured in Android keystore), this

data will be secured inside a DBStore database. The

DBStore clients will be two: the ticketing server and

the validation reader devices. An application keypair

(see Section 3.1) must be generated: the public part

is included in the mobile app package and the private

part is secretly maintained by both ticket server and

reader devices. Then, the revised mobile ticketing app

works as follows.

First, upon user signing up, the ticketing server

runs the initialization protocol with the mobile end-

point. Next, the ticketing server issues a ﬁrst SRPC

aimed at initializing the virtual card database inside

the DBStore (see Listing 1). The DB contains a table

of card records. Each record has a card type, a serial

number, and current credits.

DBStore: A TrustZone-backed Database Management System for Mobile Applications

401

-- SQL code to intialize a mobile ticketing DB

DROP TABLE IF EXISTS T i c k e ts ;

CREATE TABLE T i c k e t s ( SN INT, Typ e TE XT , Cr e di t s

INT) ;

-- SQL instructions for card purchasing

INSERT INTO T i c k e t s VALUES( @sn , @ca r d t y p e ,

@cre d i t s ) ;

-- SQL instructions for card validation

UPDATE Ti c k e t s

SET Cr e d i t s = CASE

WHEN Cr e d i t s > 0 THEN ( C r e d i t s - 1) ELSE

-1 END

WHERE T y p e = @ c a rd t y p e ;

SELECT SN , Cr e d i t s FROM T i c k e t s WHERE Ty pe =

@ca r d t y p e ;

--SQL instructions for card recharging

UPDATE Ti c k e t s SET C r e d i t s = ( Cr e d i t s + @a m o u n t )

WHERE T y p e = @ c a rd t y p e ;

Listing 1: SQL instructions for mobile ticketing app.

For card purchase and card recharge, the ticketing

server only needs to issue SRPC calls for inserting

and updating the DB, respectively. This is shown in

Listing 1. For the validation operation, the reader is-

sues a transaction that decrements the current credit of

the virtual card if the current credit value is positive.

Otherwise it sets its value to -1, indicating that credit

has been exhausted. The second SQL command reads

the current credit value along with the card’s serial

number so that the client—i.e., the reader—can deter-

mine if passage can be granted or not: -1 means it is

not. Since DBStore protects against rollback attacks,

Attack 1 is no longer possible. Attack 2 fails because

DBStore keeps all relevant key material secured in-

side the TrustZone-enabled TEE. Lastly, Attack 3 is

not possible because, through the initialization proto-

col, all SRPCs run inside the DBStore, hence outside

the adversary’s reach.

4.4 Performance Evaluation

To study the performance overhead of DBStore in

the HCE-based mobile ticketing application, we mea-

sure the execution time of three main card opera-

tions tested on our DBStore prototype. We performed

comparative measurements both in NW and SW. The

reported numbers exclude network communication

costs. We use an i.MX53 Quick Start Board, 1 GHz

ARM Cortex-A8 Processor, and 1 GB of DDR3 RAM

memory. For each experiment, we do 50 runs and we

report the mean and standard deviation.

Figure 2 presents the execution time in both NW

and SW of the tested card operations: purchase,

recharge, and validation. The standard deviations are

found atop each bar. The execution time is broken up

into two phases: “operation” refers to the core logic

of all three cases, which is common in NW and SW;

NW SW NW SW NW SW

Execution time (ms)

Context-Switch

Operation

0.64ms

0.57ms

0.51ms

0.4ms

0.51ms

0.35ms

ValidationRechargePurchase

Figure 2: Card operation execution times.

“context-switch” refers to the logic associated with

world context switch and exists in the SW alone.

The results show that purchase queries are faster

since they consist of a simple insertion in the ticket

table. The card recharge query is slower since it in-

volves a write operation on the table to update the

card balance. The card validation query is the slowest

since it must ﬁrst read the table to get the balance and

validate the operation, and only then write the new

updated card balance to the table. The SW setting in-

curs a constant performance penalty of roughly 3ms

associated with the context switches. Considering the

brought about security beneﬁts, this overhead causes

little usability impact in mobile ticketing.

5 RELATED WORK

There is signiﬁcant work on the protection of user

data on mobile devices. Aquifer (Nadkarni and

Enck, 2013) employs application workﬂow control

to prevent accidental information disclosures. Taint-

Droid (Enck et al., 2010) leverage information ﬂow

control to trace user data movements within the op-

erating system. MOSES (Russello et al., 2012) en-

forces contextual security proﬁles, e.g. Work, Pri-

vate, etc. Another group of systems that protect data

within an OS aim to enforce Digital Rights Manage-

ment (DRM) (Ongtang et al., 2010). While these sys-

tems provide effective mechanisms to protect data in

a mobile device, their main downfall is their depen-

dence on the integrity of the OS.

Some existing work has focused on the secu-

rity of the Android keystore. Sabt et al. (Sabt and

Traor

e, 2016) formally prove the failure of the key-

store’s encryption scheme in providing integrity guar-

antees, and exploit this ﬂaw to deﬁne a forgery attack

to breach its security. Cooijmans et al. (Cooijmans

et al., 2014) assess the keystore’s security, particularly

in mobile devices where keystores are protected by

SECRYPT 2018 - International Conference on Security and Cryptography

402

ARM TrustZone. Given the importance of Android

keystore for mobile security, we propose an analo-

gous TrustZone-backed service for the protection of

sensitive user-level databases.

The research on ARM TrustZone for mobile se-

curity has been proliﬁc. Some systems provide pro-

vide speciﬁc secure services, such as secure authenti-

cation (Liu and Cox, 2014), one-time-password (Sun

et al., 2015b), and trusted I/O channels (Li et al.,

2014). Others allow for the execution of application

code instantiated inside SW-hosted sandboxes (San-

tos et al., 2014). In contrast, DBStore does not al-

low for the execution or arbitrary code inside the SW,

therefore reducing a potential attack surface, and yet

provides a rich SQL interface that allows for secure

database hosting.

The idea of using a TrustZone-based TEE for pro-

tection of ticket data has appeared in prior work.

In one case, this idea was sketched at a very high-

level in a position paper (Hussin et al., 2005) with-

out any actual implementation. In other cases, a soft-

ware component of the mobile ticketing application

must run inside a TEE sandbox, which is either sup-

ported by some small trusted kernel (Tamrakar and

Ekberg, 2013) or by a TEE-emulated HCE environ-

ment (Merlo et al., 2016). We demonstrate an alter-

native and yet more general way for securing mobile

ticketing based on TEE-backed SQL commands.

6 CONCLUSIONS

This paper presented DBStore, a system that allows

mobile applications to create and operate databases

inside a TrustZone-backed TEE. It preserves the con-

ﬁdentiality and integrity of the data against a powerful

adversary that can control the OS. To foster portabil-

ity, applications interact with DBStore through a stan-

dard SQL interface. We show that DBStore can be

easily adopted in order to secure an HCE-based mo-

bile ticketing application for public transports.

ACKNOWLEDGEMENTS

We thank the anonymous reviewers for their com-

ments and suggestions. This work was partially

supported by Fundac¸

ao para a Ci

encia e Tecnolo-

gia (FCT) via projects UID/CEC/50021/2013 and

SFRH/BSAB/135236/2017, and by COMPETE 2020

/ Portugal 2020 / Uni

ao Europeia via project Mobile

Security Ticketing (#11388), which is presented by

Link Consulting Tecnologias de Informac¸

ao SA.

REFERENCES

OP-TEE. https://www.op-tee.org.

The Genode OS Framework. http://genode.org.

Android (2018). Android Key Store. https://developer.

android.com/training/articles/keystore.html.

Cooijmans, T., de Ruiter, J., and Poll, E. (2014). Analysis

of Secure Key Storage Solutions on Android. In Proc.

of SPSM.

Enck, W., Gilbert, P., Chun, B.-G., Cox, L. P., Jung, J., Mc-

Daniel, P., and Sheth, A. N. (2010). TaintDroid: An

Information-Flow Tracking System for Realtime Pri-

vacy Monitoring on Smartphones. In Proc. of OSDI.

Fitzek, A., Achleitner, F., Winter, J., and Hein, D. (2015).

The ANDIX Research OS – ARM TrustZone Meets

Industrial Control Systems Security. In Proc. of IN-

DIN.

Hussin, W. H. W., Coulton, P., and Edwards, R. (2005). Mo-

bile ticketing system employing trustzone technology.

In Proc. of ICMB.

Li, W., Ma, M., Han, J., Xia, Y., Zang, B., Chu, C.-K.,

and Li, T. (2014). Building Trusted Path on Untrusted

Device Drivers for Mobile Devices. In Proc. of APSys.

Liu, D. and Cox, L. P. (2014). VeriUI: Attested Login for

Mobile Devices. In Proc. of HotMobile.

Merlo, A., Lorrai, L., and Verderame, L. (2016). Efﬁcient

Trusted Host-based Card Emulation on TEE-enabled

Android Devices. In Proc. of HPCS.

Nadkarni, A. and Enck, W. (2013). Preventing accidental

data disclosure in modern operating systems. In Proc.

of SIGSAC.

Ongtang, M., Butler, K., and Mcdaniel, P. (2010). Porscha:

Policy Oriented Secure Content Handling in Android.

In Proc. of ACSAC.

Russello, G., Conti, M., Crispo, B., and Fernandes, E.

(2012). Moses: Supporting operation modes on smart-

phones. In Proc. of SACMAT.

Sabt, M. and Traor

e, J. (2016). Breaking Into the Key-

Store: A Practical Forgery Attack Against Android

KeyStore. In Proc. of ESORICS.

Samsung (2013). White Paper: An Overview of

Samsung KNOX. http://www.samsung.com/es/

business-images/resource/white-paper/2014/02/

Samsung KNOX whitepaper-0.pdf.

Santos, N., Raj, H., Saroiu, S., and Wolman, A. (2014).

Using ARM Trustzone to Build a Trusted Language

Runtime for Mobile Applications. In Proc. of ASP-

LOS.

Sun, H., Sun, K., Wang, Y., and Jing, J. (2015a). Reli-

able and Trustworthy Memory Acquisition on Smart-

phones. Transactions on Information Forensics and

Security, 10(12):2547–2561.

Sun, H., Sun, K., Wang, Y., and Jing, J. (2015b). TrustOTP:

Transforming Smartphones into Secure One-Time

Password Tokens. In Proc. of CCS.

Tamrakar, S. and Ekberg, J.-E. (2013). Tapping and Trip-

ping with NFC. In Proc. of TRUST.

DBStore: A TrustZone-backed Database Management System for Mobile Applications

403