A Fine-grained General Purpose Secure Storage Facility for Trusted

Execution Environment

Luigi Catuogno and Clemente Galdi

Universit

a Degli Studi di Salerno, Italy

Keywords:

Trusted Execution Environments, BYOD, Secure Storage, Enterprise Rights Management.

Abstract:

In this paper we address the problem of enforcing data access control over the storage area of a mobile device

running different and independent third party applications. To this end, we present the design of a general pur-

pose secure ﬁle system that allows to guarantee ﬁle-grained data conﬁdentiality at OS level. Data encryption,

key management and policy enforcement are based on Trusted Execution Environment (TEE) facilities. We

describe a prototype implementation and discuss preliminary performance results.

1 INTRODUCTION

Modern ICT infrastructures and business models en-

tail the possibility that personal mobile devices ex-

ecute software and handle data owned by multiple

providers, e.g., front-end applications for subscrip-

tion services along with the user access credentials

and possible locally stored/cached contents.

Consider, in particular, the increasingly spreading

“Bring Your Own Device” (BYOD) paradigm, where

employers may leverage employees’ devices (having

installed the required applications and data) for the

sake of any corporate process. The fact that both em-

ployees’ and corporate applications and private data

coexist on the same platform, raises the need of pro-

tecting each from the others’ interferences. Locally

stored information pertaining to each service is gener-

ally considered private to its interface application and

is assumed not to be available to other applications.

Thus, for every service, related security policies

and agreements are locally enforced by the respec-

tive front-end application on the basis of both sub-

scriber’s and device’s credentials. However, access

to user’s personal data, e.g., photos and videos, that

are intended to be used with different legacy appli-

cations (e.g., camera, photo gallery, ﬁle manager), is

managed through the native OS-level mechanisms.

Nowadays several scenarios require advanced ﬁle

access control mechanisms that: (a) enable any appli-

cation to keep the data it owns isolated from the others

(b) enable any application to share such data accord-

ing to ad hoc access policies, possibly depending on

the context in which the device is used; (c) ensure that

the policy established for a ﬁle is enforced even if the

ﬁle is transferred to another device through the net-

work or with an SD card. Off-the-shelf OSes, rarely

support this kind of mechanisms.

Enterprise Right Management (ERM) systems

feature ﬁne-grained access control on protected doc-

uments at fruition time. However, such systems rely

on centralized security authorities whereas data pro-

tection is mainly implemented at application level as

protected data fall in a limited number of types and

formats. Moreover, ERM systems are rather closed

solutions and rarely offer advanced interoperability

features.

GlobalPlatfom’s (GlobalPlatform, 2011) Trusted

Execution Environment (TEE) is forthcoming stan-

dard architecture for Trusted Computing on mobile

and embedded devices. Its speciﬁcations deﬁne a

double sided environment composed of a Rich Exe-

cution Environment which runs legacy Rich applica-

tions, and a Trusted Execution Environment in which

a Trusted OS takes place.

The TEE architecture feature strong resources iso-

lation for applications running in the Trusted OS

(Trusted Applications - TA). Through their TAs de-

ployed on the device, remote service providers are en-

abled to locally enforce access control over their data.

However, the TEE architecture provides a quite strict

model of ﬁle system.

In facts, the TEE’s Secure Storage facility is

mainly devoted to store generic “data objects” (keys,

certiﬁcates, etc.) rather than offering a full featured

ﬁle system-like interface to the ﬁle store. In addition,

every data object can be accessed exclusively by the

588

Catuogno, L. and Galdi, C.

A Fine-grained General Purpose Secure Storage Facility for Trusted Execution Environment.

DOI: 10.5220/0007578605880595

In Proceedings of the 5th International Conference on Information Systems Security and Privacy (ICISSP 2019), pages 588-595

ISBN: 978-989-758-359-9

TA that owns it, while other TAs can not.

Finally, TEEs lets multiple TAs handling and shar-

ing secure objects lying on secure removable storage

devices through the TEE Secure Elements API. How-

ever, this interface is conceived for the sake of provid-

ing an APDU-based transport layer to ISO IEC 7816-

4 modelled ﬁle systems (like smart cards). Both these

features are too strict to fulﬁl our requirements.

In this paper we present the design and the imple-

mentation of a full featured secure ﬁle system imple-

mented as an additional feature of the Trusted OS.

Our ﬁle system builds on top of standard TEE In-

ternal Core API speciﬁcation and it is implemented

by means of a pool of Trusted Applications intended

to provide it as a service to other TAs, by means of the

so called Internal Client APIs. Our design approach

makes possible to deploy both the ﬁle system compo-

nents and forthcoming “client” Trusted Application

onboard of devices featuring legacy Trusted OSes.

Our prototype features a cryptographic ﬁlesystem

providing data encryption and access control at ﬁle-

level and serves multiple Trusted Applications (TA)

by means of a ﬁlesystem-like interface wrapped into

the TEE Internal API. The ﬁlesystem is implemented

in the Trusted OS. Data I/O and access control are per-

formed by means of a TA acting as stand-alone server

(the ﬁlesystem back-end). Access Control Policies

can be based on roles as well as “environmental” fac-

tors such as time, events and location. In addition, we

have developed an interface which enables legacy ap-

plications (a.k.a. Rich Applications or RA) to access

the secure storage transparently.

2 RELATED WORKS

Cryptographic ﬁle systems (Blaze, 1993; Cattaneo

et al., 2001; Kallahalla et al., 2003) enjoyed a cer-

tain success mainly in the ﬁrst decade of the century.

In model “trusted client” versus “untrusted server”,

these projects pushed data encryption functionalities

beneath the virtual ﬁle system abstraction layer so

that data conﬁdentiality could be ensured indepen-

dently from the type of data and the legacy applica-

tion which handled it. Their evolution (Yun et al.,

2009; Castiglione et al., 2014) leverages cloud-based

outsourced storage facilities or passive mobile storage

devices.

Mobile computing poses at least two main prob-

lems: sensitive data are stored on devices that might

be stolen or tampered with; mobile devices require

enriched speciﬁcations for access policies as they

store data belonging to multiple stakeholders.

The Proof-Carrying File System (PCFS) (Garg

and Pfenning, 2010; Geambasu et al., 2011; Peters

et al., 2015; Catuogno et al., 2014) leverages formal

proofs to enforce ﬁle access control policies. How-

ever, the PCFS features a quite complicated and error-

prone policy-making process and a rather invasive in-

terface.

A full featured cryptographic ﬁle system for An-

droid is presented and analysed in (Wang et al., 2012).

It essentially aims at protecting data stored on micro

SD cards exchanged amongst different devices and

does not natively support any trusted computing fa-

cility to protect encryption keys.

The synergy between Trusted Computing and vir-

tualisation technologies have boosted the develop-

ment of OS-level solutions which ensure data security

to multiple parties by means of workloads isolation.

The architecture in (Catuogno et al., 2016; Catuogno

et al., 2018) use biometric identiﬁcation and key bind-

ing, in conjunction with workload isolation in order

to enforce the security of documents over a system

comprising multiple devices owned by different ac-

tors. The architecture of VPFS (Weinhold and H

artig,

2008) feature an insecure compartment, that executes

untrusted applications, and a trusted one, providing

trusted data management.

Our solution provides a full featured crypto-

graphic ﬁle system for applications running in both

trusted and untrusted compartments and is intended

to be fully compliant with the GlobalPlaftorm TEE

standard (GlobalPlatform, 2011).

2.1 Trusted Execution Environments

GlobalPlatform, a non-proﬁt organization, issued a

set of standard speciﬁcations documents deﬁning the

concept of Trusted Execution Environment (Glob-

alPlatform, 2011).

GlobalPlaform’s platform features a secure vir-

tualization infrastructure which puts side by side a

Trusted Execution Environment (TEE) and a Rich Ex-

ecution Environment (REE). The latter executes un-

trusted Rich Applications (RA), i.e., user applica-

tions, whereas the former executes Trusted Applica-

tions (TA) that provides on-demand access to privi-

leged resources and sensitive data to RAs, by means

of a client-server interface.

The Operating System running in the REE, the

Rich OS, can be considered as a legacy operating sys-

tem provided of a TEE Client API (GlobalPlatform,

2010) library which enables RAs to interact with

TAs. TEE Client APIs implement a session-oriented

communication protocol with the TEE Kernel, the

heart of the operating system running in the TEE,

which is in charge of handling the communication be-

A Fine-grained General Purpose Secure Storage Facility for Trusted Execution Environment

589

tween the two worlds. In particular, through the TEE

Client API, the RAs can use possibly available cryp-

tographic devices. Sessions are always started by RAs

that act as TEE Clients.

On the TEE side, the Trusted OS executes each TA

independently from the others, guarantees their isola-

tion and allows each TA to access only its own data.

GlobalPlatform provides speciﬁcation for every as-

pects of TA development, in particular: the TEE Inter-

nal APIs to deﬁne interaction between a TA and other

applications; the TEE Trusted User Interface APIs

to enable applications to interact with users through

a trusted path amongst the platform’s I/O devices;

and Secure Elements APIs to communicate with hard-

ware secured resources and devices, called Secure El-

ements such as smart card readers, NFC controllers,

crypto accelerators or hardware keys.

2.2 Commercial Mobile OSes

Mobile devices, such as tablets and smartphones,

have been considered for a long time “inherently”

single-user. With the continuous performance im-

provement for such devices, some currently available

operating systems have switched from the single-user

approach to a multi-user one.

Currently available Android and Windows Mobile

devices provide actual multi-user support at the op-

erating system level. Conversely, iOS virtually pro-

vides multi-user support via the cloud-based feature,

Shared Ipad (Apple Inc., 2016), that reconﬁgures the

device at login time.

A similar evolution has occurred regarding the ﬁle

encryption functionalities. Windows Mobile provides

a device encryption functionality (Microsoft Corp.,

2017). Current OS version allows to uniquely pair

SD cards to speciﬁc devices and to store personal or

corporate apps and data securely either in the internal

memory or on secured SDs. The Windows Informa-

tion Protection (WIP), by means of englighted apps,

transparently keeps corporate data protected and per-

sonal data private.

iOS. Apple devices include the Secure En-

clave (Apple Inc., 2018), a security dedicated copro-

cessor that provides full support for data protection

and key management. Each such device is equipped

with keys that are fused or compiled in the device at

manufacturing time and that are not directly acces-

sible. In this way, data stored in memory chips are

bound to a speciﬁc device. In addition to hardware

security support, iOS provides File Data Protection,

with each ﬁle encrypted with a random key that is it-

self encrypted using the ﬁle system key.

Android provides Full Disk Encryption (FDE)

and File Based Encryption (FBE). FDE encrypts the

whole user-data partition in a disk with a password

protected encryption key. The user needs to unlock

the whole disk partition before any data on it can be

accessed. FBE protects each ﬁle independently and

allows the FBE-aware apps to unlock each ﬁle inde-

pendently. Key management is executed by means of

a TEE. In all cases, data stored on external devices,

such as SD cards, cannot be encrypted and should be

stored in clear.

3 PRELIMINARIES

3.1 Entities and Roles

Our system features extended Role Based Access

Control to protected resources by entities living on

the device. An entity is an instance of an application

which runs on the device on behalf of a subscriber.

Entities are identiﬁed through the composition of a

Domain ID and at least one amongst:(a) the UUID of

the application; (b) the unique device identiﬁer (e.g. a

hardware-bound serial number, the mac-address) the

application is running on; and (c) the subscriber cre-

dentials of the user is running the application.

Each entity can activate multiple roles. Our sys-

tem features a set of default roles including owner,

administrator, and guest, though it makes possible

the deﬁnition of new per-domain, per-device, per-ﬁle

roles.

Policy rules assign a set of permissions (read,

write, execute) to every role. Role enforcement lever-

ages public key encryption. To this end, every role is

associated to a public-secret keypair (role keypair in

short). Each ﬁle is associated to at least one propri-

etary roles and, possibly, additional roles. A propri-

etary role can both access the ﬁle content and mod-

ify its access policy while additional ones are only

allowed to access ﬁle contents.

At glance, we deﬁne a Domain as the scope within

unambiguous namespaces for entities and roles are es-

tablished. Every Domain member (such as any de-

vice, application, subscriber), registered by the Do-

main authority, is provided of appropriate unique

identiﬁers along with the related cryptographic cre-

dentials including digital certiﬁcates and possibly a

required set of domain-wide role key pairs.

Any device owner or operator (user in short)

is registered as subscriber and receives her sub-

sID along with her authentication credentials (e.g.

PIN/password, crypto-tokens, etc.). Devices can be

registered by placing identiﬁers and credentials on

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

590

board through different procedures that depend on the

platform technological characteristics. For example,

credentials could be saved on a SIM, or “burnt” as

a ﬁrmware update. Applications IDs and credentials

are assigned according to their registration “scope”:

either device-wide or domain-wide.

Role keypairs, IDs and credentials are stored lo-

cally on each device at registration time. For cer-

tain entities, this choice is inherently static. For ex-

ample device identiﬁers and credentials are deployed

by the equipment manufacturer in the factory; trusted

applications may be installed in the device ﬁrmware,

along with their private data, once and for all. On

the other hand, the choice of subscriber identities and

domain-wide roles to be active on any device is likely

to change over times. To this end, our architecture

provides a mechanism to securely import/export keys

and credentials from/to other devices.

3.2 File System Encryption

Policy enforcement leverages ﬁle system level en-

cryption in which every single ﬁle is encrypted with

a randomly generated ﬁle key. Only entities enjoy-

ing the required roles can “unlock” such key (through

a mechanism we describe later) and access the ﬁle

content. Per-ﬁle policy rules are included into ﬁle

metadata. The ﬁle system ensures data conﬁdential-

ity, integrity and authenticity. Integrity is guaranteed

by means of message authentication codes (MAC). In

particular, the ﬁle key is used both to encrypt the ﬁle

content (along with its metadata) and to compute its

MAC ﬁngerprint. Data authentication is provided by

means of digital signatures. Each entity is provided

of a set of private keys that can be used to sign the

content of each ﬁle it creates or modiﬁes.

The cryptographic ﬁle system as a whole is im-

plemented as a local stand-alone ﬁle server. The ﬁle

server stores protected data (in encrypted form) on a

dedicated storage area lying on the device’s ﬁle sys-

tem or on an external storage device (e.g., SD cards,

USB sticks). Entities willing to access protected ﬁles

ﬁrstly authenticate themselves with the ﬁle server and

then issue their requests through a ﬁle-system-API

shaped IPC protocol. This component is introduced,

in details, in Section 4.4.3.

4 SYSTEM ARCHITECTURE

The system we propose can be seen as an Enter-

prise Right Management (ERM) system, i.e., a set

of tools, techniques and practices which concern

Figure 1: System architecture of maintainers’ devices.

of ensuring the conﬁdentiality of sensitive informa-

tion regardless to where it is stored or is transferred

through (Catuogno et al., 2016). Figure 1 describes

the overall architecture. Since our architecture is

modelled on top of the TEEs speciﬁcations, the “ERM

interface” is split into two components: the front-end

application, which runs as Rich Application (RA and

its back-end counterpart, which is a Trusted Applica-

tions (TA) which lives in the Trusted OS along with

all its private data. With ERM workload, we denote

the ERM application “as a whole”, i.e., meaning both

its front-end and back-end.

Components of our architecture are also im-

plemented with Trusted Applications and protocols

which are compliant to the TEE speciﬁcations.

In the following sections we introduce each com-

ponent, its design highlights and the services it pro-

vides.

4.1 Front-end Applications

Operators access protected resources by means of

dedicated front-end applications running in the Rich

Environment. Such application may be of two differ-

ent kinds: TEE-aware and legacy ones.

TEE-aware applications are aware of the security

architecture and mechanisms deployed on the mobile

device. According to the TEE standard, each such

application consists of two parts, a ﬁrst one running

in the Rich OS and its corresponding back-end coun-

terpart running in the Trust OS. The communication

between these two components occurs via the TEE

APIs. The back-end application interacts with the

trusted applications implementing our security archi-

tecture by means of TEE internal APIs. It is clear that,

such applications have to be speciﬁcally designed and

implemented using the TEE architecture as a refer-

ence.

Legacy applications, such as standard web

browsers and multimedia players, are developed by

A Fine-grained General Purpose Secure Storage Facility for Trusted Execution Environment

591

third parties. Such applications are completely un-

aware of the security mechanisms deployed on the de-

vice. Nevertheless, the proposed architecture makes

available protected data through a ﬁle system front-

end where legacy application can access them, once

the user/subscriber has been successfully authenti-

cated and authorized.

4.2 ERM User Services

4.2.1 The AA Interface

Users authentication is performed through trusted

channels such as PIN/password insertion dialogs

through TEE Trusted UIs or leveraging cryptographic

hardware based authentication systems. Once the user

is successfully authenticated, she starts her session

that lasts until she logs out. Throughout the session,

protected data available to the user are made available

through the ﬁle system front-end, and legacy appli-

cation access such ﬁles enjoying the privileges of the

user’s active roles.

4.2.2 File System Front-end

The ﬁle system front-end allows legacy application

to handle protected data through ﬁle system-shaped

APIs. To this end, we use a virtual ﬁle system layer

that wraps the TEE Client APIs to properly interact

with the ﬁle system back-end in the Trusted OS.

Speciﬁcally, whenever an untrusted application

requires a ﬁle system operation on a secured ﬁle, the

ﬁle system front-end in the Rich OS forwards such re-

quest to an underlying translation module. Such mod-

ule will contain no relevant application logic but it

will just encode the requests in a proper way and send

it to a ﬁle system back-end running on the TEE side.

In our prototype, this component is implemented with

a FUSE ﬁle system layer (FUS, ).

4.3 ERM Workloads Layer

ERM back-end applications along with their private

data take place in the ERM Workloads layer. Such ap-

plications are designed to trustworthily interact with

their owners’ premises in order to carry out their

tasks. As TAs, ERM back-ends communicate with

the user and remote facilities through the TEE APIs

and the secure network protocols and are provided of

a private local storage for e.g. temporary data and

keying materials. Moreover, such applications handle

secured ﬁles lying in the File System Backend related

services by means the APIs they expose. Through

such interfaces, different ERM back-ends are enabled

to access and share their secure ﬁles with other TAs,

according to arbitrary policy rules. Legacy TAs may

co-exist with ERM workloads.

4.4 ERM Service layer

4.4.1 The Policy Manager

Our architecture features access control policies

which are based on a extended Role Based Access

Control (RBAC) approach which is thought to include

temporal, spatial (GPS based) and event-driven poli-

cies (Bonatti et al., 2015; Aich et al., 2009). Fine-

grained policy rules are attached to the ﬁle metadata.

The Policy Manager (PolicyMGR) maintains the

role-entity database. For each entity “living” on

the device, the role-entity database contains an

entry which relates its identiﬁer with the list of

the roles it is enrolled into. The PolicyMGR

API provides the functions to query such database:

check

role(entity-id, role-id) which returns

true whether (a) the entity has activated role-id or (b)

the entity is allowed to play that role due to some oc-

curring events or environmental conditions.

The function check policy(policy,role-id)

returns a bit-string denoting the granted access mode

(like the unix-like octal digit representing read, write

and execute permission) that the policy rules allow to

the role role-id.

Entries related to domain-wide identities and roles

are added to the role-entity database at registration

time and can not be modiﬁed by the device owner.

However, the device owner can create new “local”

roles and entities, concerning the deﬁnition of policy

rules for local ﬁles.

Each ﬁle is associated to the following meta-

data. A list of proprietary and additional roles,

, . . . , r

; the actual plaintext size; the speciﬁca-

tion of cryptographic algorithms, including their op-

erational parameters; the encryptions of the ﬁle

key under the public keys of authorized roles, i.e.,

Enc

(k) . . . Enc

(k); the encryption of the ﬁle ac-

cess policy under the ﬁle key k, Enc

(Policy);

FILEMAC = MAC

(File Content); LastRoleID of the

last role that modiﬁed the ﬁle along with her signature

on FILEMAC. The integrity of above data is guaran-

teed by MAC

(Metadata) computed by LastRoleID.

4.4.2 The Key Manager

The Key Manager (KeyMGR) handles the crypto-

graphic keys on behalf of every entity and role present

in the system.

For the sake of access control enforcement, our

architecture holds a public-secret key pair for each

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

592

role deﬁned by the domain authority. Access con-

trol leverages data symmetric encryption. Each ﬁle

is encrypted with a random key (the ﬁle key) Hence,

for each enabled role, the system attaches to the ﬁle a

copy of its ﬁle key, encrypted with the corresponding

public key.

When any entity accesses to a protected ﬁle, the

ﬁle system back-end requires the KeyMGR to decrypt

the ﬁle key, by using a private key associated to one

of the roles the requesting entity has activated. In ad-

dition, role keypairs are used to sign/verify ﬁle data

and metadata.

In order to fulﬁll such tasks, the KeyMGR API

provides the following functionalities: ﬁlekey en-

crypt/decrypt and data sign/verify.

Role keys are physically stored (indexed by role-

id) in the Key Repository, which is a private storage

area cryptographically bound to the KeyMGR, and

never leave this component during normal operations.

KeyMGR’s API includes the functions needed to han-

dle keys and keypairs generation, import/export and

disposal. The role/role keys lifecycle within domains,

KeyMGR’s API includes the functions to handle key-

pair generation, import/export and disposal.

The device user generates new “local” roles (and

their respective role key pairs) in order to setup any

ad-hoc policy rule to govern the access to a locally

created ﬁle. To this end, the KeyMGR enables the

user to engage in a secure protocol for the generation

of a local role key-pair and triggers the PolicyMGR

to add the new role-id to role-entity database (along

with its enrolled entities).

The import functionality can occur at different

times and has the effect of adding new role/role key

pairs to the Key Repository. At device registration

time, domain and device authorities can populate the

Key Repository with the key pairs related to every

pre-deﬁned roles according to every installed appli-

cation and pre-loaded ﬁles and data. In addition, at

any time, the user can import a newly generated key

pair from an external source. External sources include

mainly Secure Elements as deﬁned by the GlobalPlat-

form standard, such as a smart-card, or nearby trusted

devices, connected through NFC.

Key pairs generation can be accomplished accord-

ing different strategies. In the simplest one, the ap-

plication vendor provides at least the keypair for the

domain-wide reserved role of a given application.

This guarantees the highest possible portability of en-

crypted contexts. On the other hand it also allows, in

principle, the vendor to access the data generated by

every single installation of its application.

Frequently protected ﬁles are transferred between

device (e.g., through the network or by means of SD

cards). Whenever none of the roles enabled to access

the ﬁles are present on the receiving device, it is nec-

essary to transfer the related key pairs between the

devices. In this case, the endpoints have to establish a

trusted channel through which the key are exported.

Local role key pair disposal occurs whenever ev-

ery entity operating on the device should no longer

enabled to play the corresponding role.

4.4.3 The File System Back-end

The ﬁle system back-end (FSB) is the TA which acts

as a stand-alone ﬁle-server and Policy Enforcement

Point (PEP). To this end, the FSB exhibits a num-

ber of interfaces implemented by means of the entry

points deﬁned in the TEE internal API. Trusted ap-

plications (including ERM backends) access the en-

crypted storage by using a library which resembles

usual ﬁle system calls (open, read, write, etc.), along

with the functions devoted to entity authentication and

authorization. Such a library wraps the TA client API

and is intended to provide a high level interface to the

FSB for third party TA application developers.

Access requests for encrypted ﬁles make the

ERM system services components interact each oth-

ers through the APIs introduced above.

The FSB features a ﬁle system-like interface to en-

crypted data stored on its private storage. Through

this layer, data are organized and made available as

logical ﬁles. The way in which any logical ﬁle, along

with its metadata and status information is structured,

handled and made available underneath of such an in-

terface, depends on the nature of the underlying OS

(the Trusted OS).

5 PROTOTYPE

IMPLEMENTATION

Our PEP/FS works on top of a ext4 ﬁlesystem, which

is the last representative in a family of ﬁlesystems of

widespread use on Linux systems.

In our architecture, we assume that information

related to any logical ﬁle is split amongst at least two

different low level ﬁles, one for its contents and one

(or more) for its metadata.

For the purpose of managing open ﬁles, the FSB

maintains two different data structure: the open ﬁles

table (OFT) and the Virtual File Descriptor table

(VFD).

The OFT contains an entry for each logical ﬁle

currently in use by at least one entity. When an entity

opens a ﬁle, the FSB creates a new entry in the OFT.

Each entry features: (a) the logical ﬁle descriptor; (b)

A Fine-grained General Purpose Secure Storage Facility for Trusted Execution Environment

593

the data structure that references the ﬁle’s low level

counterparts; and (c) ﬁle’s metadata and status infor-

mation (including e.g. the reference counter which

reports the number of entity which opened the ﬁle).

The VFD features an entry for each entity that

has opened a ﬁle and maintains it until such an en-

tity closes the ﬁle. Each entry (whose reference is

the virtual ﬁle descriptor the open returns) links the

entity with the logical ﬁle in use and contains: (a) a

reference to the entry of the OFT that represents the

logical ﬁle; (b) ﬁle key k; (c) entity’s current role-id

and credentials; and (d) access mode information.

In order to change its current role, an entity in-

vokes the FSB claim function, providing the subject

virtual ﬁle descriptor and the new role. The FSB, in

turn, issues a check role call to the PolicyMGR for the

new role and, if successful, updates the current role of

the VFD.

The FSB provide some ad hoc APIs to allow pro-

prietary roles to modify the ﬁle’s access policy rules.

To this end, the entity opens the ﬁle and pushes

the policy changes into the policy metadata then re-

encrypts it with the ﬁle key and signs it. Our system is

intended to be neutral with respect to the policy repre-

sentation format. We envision the employment of any

standard format such as extensions of XACML.

We build our prototype system using the Open-

TEE which is a software emulator of a GlobalPlat-

form compliant TEE environment for the Linux oper-

ating system. Open-TEE provides a framework that

can be used to develop and test prototypes of TEE-

enabled applications, keeping apart the problems and

challenges raised by the real hardware target plat-

form. However, Open-TEE ensures a high level of

source-compatibility with real-world TEE develop-

ment frameworks.

The Open-TEE environment is composed of two

stand-alone servers and a set of dynamic libraries

which implements the GlobalPlatform APIs. Rich

Applications are native Linux Applications written in

C/C++, whereas Trusted Applications are dynamic

shared objects registered with the launcher and exe-

cuted in separated threads. It is clear that Open-TEE

only reproduces the development environment but

does not fulﬁlls any security requirement addressed

by GlobalPlatform speciﬁcations.

6 PERFORMANCE EVALUATION

We have run preliminary performance measurements

of our prototype implementation. There are a number

of variables that come into play when evaluating the

performance of our solution. Some examples are the

Figure 2: Comparison proposed ﬁle system vs Plain ext4

for random read operations.

complexity of the access policy, the presence of the

(optional) en/decryption operations, the block size,

the complexity related to the translation of metadata

into metadata storage interfaces of the underlying ﬁle

system.

We highlight that the purposes of these exper-

iments are validating the approach and verifying

whether the TEE framework APIs are suitable for the

implementation of our architecture. In the following,

we brieﬂy summarize some performance results we

achieved in our early experiments.

Currently, such results are clearly far even from

the ones of the ext4 ﬁle system for a number of rea-

sons. The ﬁrst one is that we build on top of such

a ﬁle system and, thus, our measurements consist of

the time needed by our software structure and by the

time needed by the ext4 ﬁle system to actually exe-

cute the operations. Secondly, we highlight that the

Open-TEE environment has not been written by fo-

cusing on efﬁciency but as a proof of concept of the

architecture.

Due to space constraints, we only report some of

the experiments with have done. As stated above, we

have implemented our system on an ext4 ﬁle ﬁlesys-

tem by its extended attributes for storing ﬁle meta-

data. The complexity of the access policies is an-

other variable that strongly depends on the speciﬁc

policy. Since we needed to evaluate the usability of

our system, we have run the ﬁrst experiments using

’ﬂat’ spatio-temporal policies, i.e., allow everytime-

everywhere. We note that complex access policies

veriﬁcation may have a huge impact on the open op-

eration. On the other hand, once the ﬁle is opened, the

status of the policy condition can be asynchronously

monitored by the PDP in order to reduce the response

time for each subsequent request.

We have run the following tests:

• Read/Randomized Read: This test measures the

performance of reading an existing ﬁle (at ran-

domly selected locations).

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

594

• Write/Randomized Write: This test measures the

performance of writing a new ﬁle (at randomly se-

lected locations).

Each test only considers the time needed to exe-

cute read/write operations in ﬁles and does not con-

sider the time needed to open or close the ﬁle. In

Figures 2 we report the performance of our ﬁlesys-

tem (compared with a plain ext4 ﬁle system) in the

random read operations into ﬁles with size ranging

from 64KB to 512MB. The performance of the read

and write operations are similar to the corresponding

randomized versions and are omitted.

7 CONCLUSIONS

In this paper propose the design of a full fea-

tured cryptographic ﬁle system, intended as general

purpose facility for Trusted Execution Environment

(TEE)-compliant platforms.

Data may either lie on a device internal stor-

age (and bound to that device) or can be transferred

amongst different devices (e.g., by means of micro SD

cards rather than trusted communication channel). In

this case, a protocol to transfer access privileges to the

receiving device is provided.

The ﬁle system is fully compliant to the TEE stan-

dard speciﬁcations. As far as we know, this is the

ﬁrst project of this kind which offers this feature. We

present a prototype based on OpenTEE and the FUSE

ﬁlesystem. Although preliminary experiments are

likely to signiﬁcant improvements and optimizations,

they look quite promising and make the approach

worthy of further investigation.

REFERENCES

FUSE: Filesystem in Userspace. http://fuse.sourceforge.

net.

Aich, S., Mondal, S., Sural, S., and Majumdar, A. (2009).

Role based access control with spatiotemporal context

for mobile applications. In Trans. on Computational

Science IV, volume 5430 of LNCS, pages 177–199.

Apple Inc. (2016). Apple Shared Ipad. https://developer.

apple.com/education/shared-ipad/.

Apple Inc. (2018). iOS Security Guide - White

Paper. https://www.apple.com/business/docs/iOS

Security Guide.pdf.

Blaze, M. (1993). A cryptographic ﬁle system for unix. In

Proceedings of the 1st ACM conference on Computer

and communications security, pages 9–16. ACM.

Bonatti, P., Galdi, C., and Torres, D. (2015). Event-driven

RBAC. Journal of Computer Security, 23(6):709–757.

Castiglione, A., Catuogno, L., Del Sorbo, A., Fiore, U., and

Palmieri, F. (2014). A secure ﬁle sharing service for

distributed computing environments. The Journal of

Supercomputing, 67(3):691–710.

Cattaneo, G., Catuogno, L., Sorbo, A. D., and Persiano, P.

(2001). The design and implementation of a trans-

parent cryptographic ﬁle system for unix. In USENIX

Annual Technical Conference, pages 199–212.

Catuogno, L., Galdi, C., and Riccio, D. (2016). Flexible and

robust enterprise right management. In IEEE Sympo-

sium on Computers and Communication, ISCC 2016,

Messina, Italy, June 27-30, 2016, pages 1257–1262.

Catuogno, L., Galdi, C., and Riccio, D. (2018). Off-line en-

terprise rights management leveraging biometric key

binding and secure hardware. Journal of Ambient In-

telligence and Humanized Computing.

Catuogno, L., L

ohr, H., Winandy, M., and Sadeghi, A.-R.

(2014). A trusted versioning ﬁle system for passive

mobile storage devices. Journal of Network and Com-

puter Applications, 38:65–75.

Garg, D. and Pfenning, F. (2010). A proof-carrying ﬁle sys-

tem. In Security and Privacy (SP), 2010 IEEE Sym-

posium on, pages 349–364. IEEE.

Geambasu, R., John, J. P., Gribble, S. D., Kohno, T., and

Levy, H. M. (2011). Keypad: an auditing ﬁle system

for theft-prone devices. In Proceedings of the sixth

conference on Computer systems, pages 1–16. ACM.

GlobalPlatform (2010). TEE Client API Speciﬁcation v1.0.

http://globalplatform.org.

GlobalPlatform (2011). TEE System Architecture v1.0.

http://globalplatform.org.

Kallahalla, M., Riedel, E., Swaminathan, R., Wang, Q., and

Fu, K. (2003). Plutus: Scalable secure ﬁle sharing on

untrusted storage. In Prof. of the USENIX Conference

on File and Storage Technologies, pages 29–42.

Microsoft Corp. (2017). Windows 10 mo-

bile deployment and management guide.

https://docs.microsoft.com/en-us/windows/

client-management/windows-10-mobile-and-mdm.

Peters, T., Gondree, M., and Peterson, Z. N. J. (2015).

DEFY: A deniable, encrypted ﬁle system for log-

structured storage. In 22nd Network and Distributed

System Security Symposium, NDSS. The Internet Soc.

Wang, Z., Murmuria, R., and Stavrou, A. (2012). Imple-

menting and optimizing an encryption ﬁlesystem on

android. In Proc. of IEEE Mobile Data Management,

pages 52–62.

Weinhold, C. and H

artig, H. (2008). Vpfs: Building a vir-

tual private ﬁle system with a small trusted comput-

ing base. ACM SIGOPS Operating Systems Review,

42(4):81–93.

Yun, A., Shi, C., and Kim, Y. (2009). On protecting in-

tegrity and conﬁdentiality of cryptographic ﬁle system

for outsourced storage. In Proc. of the ACM workshop

on Cloud computing security, pages 67–76.

A Fine-grained General Purpose Secure Storage Facility for Trusted Execution Environment

595