MoCrySIL – Carry Your Cryptographic Keys in Your Pocket

Florian Reimair, Peter Teuﬂ, Christian Kollmann and Christoph Thaller

Graz University of Technology, Graz, Austria

Keywords:

Cloud Security, Central Cryptographic Solutions, Advanced Cryptographic Protocols, Heterogeneous Appli-

cations, Mobile Devices.

Abstract:

Today’s applications need to share data and workload in heterogeneous device environments. Many of these

handle sensitive data and need to make use of cryptography, which induces keys that have to be provisioned,

stored and shared securely. Our Cryptographic Service Interoperability Layer (CrySIL) architecture addressed

these challenges by storing the key material off-device in a central hardened service that provides crypto-

graphic functions to arbitrary devices via standardised APIs. While CrySIL is typically deployed by a trusted

entity utilising hardware-security-modules (HSMs), the setup of this central trusted instance might be too

complex or not desired in SME/personal deployment scenarios. Therefore, we present MoCrySIL, an exten-

sion to CrySIL that omits the need for a thrusted third party by making use of hardware-backed key-storage

facilities available in today’s smart phones. We describe the MoCrySIL architectures and present a prototype

that performs S/MIME based email encryption/signatures via a PKCS#11 library. We conduct a thorough

security/risk analysis, and reﬂect on functional achievements and shortcomings.

1 INTRODUCTION

In recent years, a highly heterogeneous platform land-

scape has become the standard scenario for the devel-

opment and deployment of applications. Especially,

mobile device platforms introduced an unprecedented

level of architectural heterogeneity that needs to be

considered for all aspects of the application develop-

ment process. In addition to the relatively new mo-

bile operating systems and platforms, rich HTML5-

based cross-platform and browser applications gain

importance while classic desktop operating systems

still stand their ground. Developing applications for

these diverse environments boosts complexity of the

processes signiﬁcantly. Especially, security-related

aspects – the deployment of cryptographic algorithms

and protocols to offer conﬁdentiality, integrity and au-

thenticity for the processed data – suffer in several

ways: First, managing cryptographic keys on multi-

ple platforms is a signiﬁcant challenge either due to

the lack of required key storage facilities, or due to

their strongly deviating levels of security. Second,

low- and high-level cryptographic algorithm and pro-

tocol implementations are not available on every plat-

form. Third, the high level of complexity is the likely

cause for severe implementation mistakes that lead to

signiﬁcant security issues (e.g., (Egele et al., 2013;

Fahl et al., 2012)). With this work, we follow the call

for action issued by (Rocha and Correia, 2011) and

the need for addressing important personal crypto use

cases such as health data protection (Benaloh et al.,

2009) and/or secure cloud storage for the industry as

proposed in (Kamara and Lauter, 2010), among oth-

ers.

Scientiﬁc research and the industry reacted to the

situation and created a plethora of crypto platforms,

communication protocols, and key management so-

lutions. Most of these solutions, however, offer a

very limited set of cryptographic functions, deploy

(implicit) authentication mechanisms tailored to spe-

ciﬁc requirements, or are not ﬂexible enough to be

deployed in constantly changing environments.

We recently presented the Cryptographic Service

Interoperability Layer (CrySIL) (Reimair et al., 2015)

concept as our approach to complement existing ap-

proaches and stand the challenges of key management

and utilising cryptographic functions within hetero-

geneous application deployment scenarios. CrySIL is

all about getting access to the keys, everywhere and

at any time. And it does so by offering a centralized

key storage and crypto engine. In a typical scenario

CrySIL is deployed in private cloud environments and

utilises HSMs for protecting key material. While this

setup is highly relevant for enterprise-based applica-

285

Reimair F., Teuﬂ P., Kollmann C. and Thaller C..

MoCrySIL – Carry Your Cryptographic Keys in Your Pocket.

DOI: 10.5220/0005547902850292

In Proceedings of the 12th International Conference on Security and Cryptography (SECRYPT-2015), pages 285-292

ISBN: 978-989-758-117-5

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

tions, it might not be suitable for personal use cases

or SMEs due to setup complexity and hardware costs

(HSMs).

Thus, we extend the ﬂexible CrySIL architec-

ture to gain a mobile version (MoCrySIL) based on

today’s mobile hardware-backed key storage facil-

ities. While foreclosing the need for yet another

third party, it provides a personal crypto platform for

one’s pocket. The platform features direct key man-

agement and a crypto engine that can be used for

VPN, email signature/encryption, and data encryp-

tion, among others. Finally, transferring the CrySIL

architecture from the typical server/HSM based envi-

ronment to the mobile scenario allowed us to evaluate

and improve the ﬂexibility and security of the original

CrySIL architecture.

To evaluate the security of the MoCrySIL system,

we present a prototypical Android-based MoCrySIL

system that is used for S/MIME-based email sig-

natures/encryption (via a CrySIL-enabled PKCS#11

API). The cryptographic keys are stored in the

hardware-backed Android KeyStore. The communi-

cation between the PKCS#11 API on the client and

the MoCrySIL app on the Android device is estab-

lished via an external WebVPN component, which

utilises push notiﬁcation facilities and long lived

WebSocket connections. The communication path is

protected by an end-2-end TLS tunnel. We present

a functional analysis as well as performance state-

ments. Although standard protocols and components

form the basis of the MoCrySIL architecture, their

new combination, the mobile nature of the system and

the requirements for protecting key material and cryp-

tographic functions mandate a thorough security/risk

analysis.

The results of our evaluation indicate a success in

providing low-footprint access to cryptographic prim-

itives from different devices, and, given internet ac-

cess, anywhere and at any time. With MoCrySIL, we

created a central key storage solution with most ad-

vantages of centralised key storage services while not

introducing yet another trusted third party. The key

material never leaves the central crypto engine and

therefore does not have to be guarded at every client

device. Access to the primitives is guarded by build-in

strong authentication procedures. While MoCrySIL

introduces latencies that renders it not suitable for

bulk encryption, it succeeds in getting cryptography

to places where crypto could not securely be used be-

fore (e. g. in browsers).

The subsequent work is structured as follows.

Section 2 presents solutions which already try to stand

the challenges but fall short in multiple aspects. The

general CrySIL architecture is described in Section 3.

The requirements, adaptations and the detailed work-

ﬂow for MoCrySIL are introduced in Section 4. The

system is then subject to a detailed risk/security anal-

ysis in Section 5. We conclude the work with a

glimpse to the future.

2 RELATED WORK

A number of server-based cryptographic services

have been implemented by the industry. This sec-

tion gives an overview and functional evaluation of

selected cryptographic services that can be integrated

into cloud-based environments.

Dictao

and Cryptomathic

support digital sig-

natures for transaction security and user authentica-

tion. Both services facilitate key access by authenti-

cating clients using simple credentials, such as user-

name/password schemes, or credentials that feature

higher strength (eID cards, OTPs, mobile devices etc).

While SigningHub and Cryptomathic are deployed

as cloud services, Dictao requires integration into an

enterprise IT infrastructure. Basically, the provided

functionality is limited to user authentication and sig-

nature creation.

The so-called Austrian Mobile Phone Signature

one implementation of the Austrian citizen card con-

cept (Leitold et al., 2002), is a cloud-based service

and uses a hardware security module (HSM) to store

the private signature keys of all Austrian citizens. Ac-

cess to these keys is protected by a strong two-factor

authentication mechanism, involving a password as

well as an OTP being sent to the citizen’s mobile

phone. Applications can access the Austrian Mobile

Phone Signature and its signature creation functional-

ity through a well-deﬁned XML interface. Although

the Austrian Mobile Phone Signature meets the de-

mands of the law, the currently deployed implemen-

tation fails to support use cases other than signature

creation and user identiﬁcation.

Scientists adopted the new environment and re-

quirements as well. A very intuitive approach is to

host the cryptographic keys centrally and hand copies

to clients on request. The OASIS Key Management

Interoperability Protocol (KMIP) (KMIP-v1.1, 2013)

and the Cloud KMIP (CKMIP) (Lei et al., 2010) en-

able this kind of key distribution. While this kind of

key distribution may be effective and spot-on for pri-

vate cloud environments, the approach does not suf-

ﬁce for personal use cases and public cloud appli-

ances.

https://www.dictao.com

http://www.cryptomathic.com

https://www.handy-signatur.at

SECRYPT2015-InternationalConferenceonSecurityandCryptography

286

Trusted Computing, as proposed by the Trusted

Computing Group (TCG), introduces a hardware se-

curity module (HSM), the trusted platform module

(TPM) (Trusted Computing Group, 2011), into com-

modity off-the-shelf hardware for personal comput-

ers. This HSM allows for rather secure personal

key storage. Together with virtualisation solutions,

scientiﬁc research was successful in securely storing

and using keys without distributing them to the client

(Bleikertz et al., 2013; Butt et al., 2012; Toegl et al.,

2013). However, these approaches introduce a trusted

third party for key management which is not ideal for

public cloud environments.

All in all, there are plenty of attempts to stand the

challenges. Most of them fall short for the use case of

easy-to-use, ﬂexible, and portable personal key man-

agement for a multi-device user.

3 CrySIL ARCHITECTURE

The Crypto Service Interoperability Layer (CrySIL)

concept (Reimair et al., 2015) has been created to

meet today’s heterogeneous device landscape and al-

lows the user to use her keys within cryptographic op-

erations regardless where the key resides and where

it is needed. In a nutshell, the user takes one of her

devices and launches an application to perform some

cryptographic task. The application interfaces with

the interoperability layer, CrySIL, which connects to

another device. This other device has access to the

actual cryptographic primitive, creates and validates

authentication challenges if required and performs the

Figure 1: CrySIL’s basic architecture.

requested operation. The result is returned to the in-

teroperability layer and back to the application run-

ning on the device of the user. A graphical illustration

of the workﬂow is given in Figure 1.

CrySIL introduces great ﬂexbility by breaking

the classic cryptographic provider apart. The re-

sulting parts – modules – have different jobs and

work together to form the actual cryptographic ser-

vice provider. Receivers, actors, a router, and other

modules handle inter-node communication, protocol

mappings, crypto, advanced crypto and authentica-

tion. A receiver for example acts as a protocol bridge

to the interoperability layer with pre-build implemen-

tations for the Windows CNG, the W3C Web Cryp-

tography API as well as a SOAP-based web interface.

An actor makes the services of a crypto provider, e.g.

a smart card or an HSM, available to the layer and col-

lects authentication information as they are required.

Authentication modules do handle the authentication

challenges issued by actors. The router connects the

modules together. Anyhow, all modules are consid-

ered as building blocks and are not restricted to any

technology, platform, or programming language. Ev-

ery conﬁguration of a router and other modules is re-

ferred to as a CrySIL node and forms the heart of the

concept. An illustration of modules and their inter-

connections is given in Figure 2.

Figure 2: CrySIL node architecture overview.

Communication modules forward requests to

other nodes and therefore renders off-device crypto

completely transparent to the user, the developer, and

to the application while maintaining a simple archi-

tecture. A user beneﬁts from her ability to use a vari-

ety of keys within different cryptographic operations

provided by different crypto providers from a variety

of applications on different devices.

4 MoCrySIL – A CrySIL

EXTENSION

Although today’s mobile devices may not compete

with the security levels of dedicated cryptographic

smart cards or similar hardware, they do offer hard-

ened operating systems and hardware-backed key

storage solutions. Furthermore, since the mobile de-

vice is at the owner’s ﬁngertip, direct user interaction

is available. For example, when the mobile device

receives some request to perform a cryptographic op-

eration with sensitive key data, the mobile device can

ask the user (the key owner) for allowance.

Together with the rather novel deployment options

provided by CrySIL, this allows for moving the cen-

tral cloud-based key service to a user’s mobile de-

vice. MoCrySIL extends the standard CrySIL archi-

tecture by nodes that can be deployed on mobile de-

MoCrySIL-CarryYourCryptographicKeysinYourPocket

287

vices and an external WebVPN component that en-

sures that these nodes are reachable from the internet.

The WebVPN approach solves the reachability

challenge for mobile devices (NAT, changing IP ad-

dresses etc.) by acting as relay service that uses stan-

dard push notiﬁcation systems and long lived Web-

Socket connections. The communication paths via

WebVPN are protected with end-2-end TLS tunnels,

which eliminates the possibility for a possibly mali-

cious WebVPN node to read or manipulate CrySIL

messages. An additional communications module

communicates with the WebVPN component, a ca-

pable actor connects the mobile phone key store to

CrySIL.

For explaining the detailed application workﬂow,

the following assumptions were taken: An Android

device is used for the MoCrySIL application. The

WebVPN component is hosted by a public cloud

provider. The complete workﬂow can be categorised

in two main steps – (A) the WebVPN enrolment pro-

cess and (B) using the system. In this case “using the

system” refers to handle signed and encrypted emails

via a client that is S/MIME enabled and capable of

using the CrySIL infrastructure via standardised APIs

(e.g., PCKS#11). An illustration of the overall work-

ﬂow is given in Figure 3.

Figure 3: MoCrySIL architecture overview.

(A1) WebVPN Setup. The user starts the

MoCrySIL app for the ﬁrst time and initiates the en-

rolment process over a TLS tunnel. For setting up

the WebVPN account the user needs to authenticate

herself via a pre-deﬁned method (depending on se-

curity requirements). The application then requests a

unique Comm ID

used to setup the URL which acts

as CrySIL interface for the clients. The MoCrySIL

app then generates a TLS certiﬁcate that stores the

Comm ID within the common name (CN). The cor-

responding cryptographic key is directly generated

within the Android KeyChain and thus will never be

stored/used in insecure environments. The generated

certiﬁcate is sent to WebVPN, which veriﬁes the cor-

rectness of the Comm ID (via the CN) and signs the

certiﬁcate with its own private key. The signed certiﬁ-

cate is then returned to the MoCrySIL app and stored

in the WebVPN database. MoCrySIL now drops the

initial TLS-based communication channel and estab-

lishes a client-TLS WebSocket based communication

channel by using the just generated certiﬁcate. The

MoCrySIL app initialises the push notiﬁcation sys-

tem (in this case Google Cloud Messaging). The re-

quired tokens are associated with the Comm ID and

are stored in the WebVPN database.

(A2) Storing/Generating S/MIME Key Mate-

rial. In this step certiﬁcates for processing S/MIME

signed/encrypted emails are setup in the Android

KeyChain of the MoCrySIL device. Certiﬁcates can

be self signed or issued by a certiﬁcation authoriy

(CA). However, as there are no special requirements

to the certiﬁcate issuing process it is considered out

of scope for this work.

(A3) Setting up Client Communication. To al-

low for secure communication between the client and

the MoCrySIL app the required trust for the TLS cer-

tiﬁcate needs to be established on the client. The

MoCrySIL app displays the WebVPN endpoint URL

(including the Comm ID) – further denoted as Comm

URL, which is then conﬁgured on the client. Then the

ﬁrst connection is established between the client and

the MoCrySIL app (more details in B1). To establish a

trust relationship, the ﬁngerprint of the TLS certiﬁcate

is displayed on the client device

and the MoCrySIL

app. When both ﬁngerprints match, a possible MITM

attack can be ruled out. The TLS certiﬁcate is stored

on the client and used for protecting CrySIL protocol

data.

(B1) Signing an Email. The plain email is handed

over to the S/MIME signature component of the email

client, which calculates the hash value and hands it

over to the (examplary) PKCS#11 CrySIL API. The

API then prepares a CrySIL signing request.

Before issuing the request to the MoCrySIL app, a

secure TLS end-2-end channel (denoted as E2E TLS

in Figure 3) is to be established. The TLS handshake

Requirements for the communication ID in terms of

length and randomness are similar to those of session iden-

tiﬁers.

(e.g., by the CrySIL enabled PKCS#11 API)

SECRYPT2015-InternationalConferenceonSecurityandCryptography

288

data is encoded in CrySIL protocol packets and sent

to the Comm URL. WebVPN uses the Comm ID to

retrieve information about the respective MoCrySIL

app and push-notiﬁcation tokens from the database.

In case no long lived WebSocket connection exists al-

ready, a “wake-up-call” is sent to the MoCrySIL app

via the push notiﬁcation system. The MoCrySIL app

establishes a long lived TLS protected WebSocket

connection to WebVPN by authenticating via the TLS

certiﬁcate. The TLS handshake between the client

and the MoCrySIL app can now be completed. The

client veriﬁes the validity of the TLS certiﬁcate by us-

ing the hash values that were accepted by the user dur-

ing the registration process.

Now, the actual CrySIL request is sent to the

MoCrySIL app. The MoCrySIL actor receives the

incoming signing request and initiates the (current

)

authentication process: (a) The MoCrySIL app gen-

erates a PIN code that is sent via the CrySIL authen-

tication challenge to the client. (b) The client dis-

plays the PIN code to the user, who then (c) needs

to provide the code to the MoCrySIL app. After a

successful authentication process, the hash is signed

and returned to the client. The client extracts the

signature response and hands it over to the email

client, which then ﬁnalises the S/MIME email and

hands it over to the respective mail transfer agent.

The communication channels between the different

entities remain open for a pre-deﬁned session time,

which allows the efﬁcient transmission of further re-

quests/responses without the need to build up the TLS

channel and send the required push notiﬁcations.

5 EVALUATION

With the MoCrySIL approach, we successfully trans-

formed a mobile device into a portable cryptographic

platform with a direct key management system. There

is no need for a trusted third party, yet MoCrySIL

implements a centralised solution. On top of that,

the third parties that are required for waking the

MoCrySIL application cannot read/manipulate data

due to the end-to-end encryption done by CrySIL. Es-

tablishing trust relationships between consuming and

serving CrySIL nodes does not require trusted third

parties either. The underlying CrySIL technology de-

pends on state-of-the-art technology and is designed

to meet upcoming requirements. For evaluating the

MoCrySIL approach we did a prototypical implemen-

The current authentication method just represents a

simple example and could be replaced by a wide variety

of authentication methods tailored to the speciﬁc environ-

ments.

tation. To understand consequences in relation to

security in these system we present a detailed secu-

rity/risk analysis of the system.

5.1 Security/Risk Analysis

For the conducted risk analysis we assume an ap-

plication scenario that deploys the S/MIME stan-

dard for signing and encrypting emails. Thereby the

MoCrySIL application is installed on a current An-

droid 5.0 devicethat offers a hardware-based Key-

Chain for storing the asymmetric key data. As client

a desktop based mail client is used that supports

S/MIME and is capable of using cryptographic func-

tions via the standardised PKCS#11 API.

5.1.1 Entities and Assumptions

The client

is the device running the application,

which utilises the cryptographic functions offered by

the CrySIL infrastructure. For the most part it is

considered to be out of scope for the conducted se-

curity/risk analysis. The mobile device hosts the

CrySIL instance and stores and handles the asymmet-

ric cryptographic key data used for S/MIME based

encryption/signature processes. The user operates the

mail application on the respective client, handles the

MoCrySIL app on the Android device, registers the

MoCrySIL app with WebVPN and the client, and uses

the MoCrySIL infrastructure by signing/decrypting

mails on the client. WebVPN is hosted on a pub-

lic cloud provider

that is assumed (1) to be honest-

but-curious. (2) The possibility of a successful attack

by a third party needs to be considered. This party

has the interest to manipulate WebVPN or listens to

communication. The CrySIL provider develops and

maintains the CrySIL components. These include the

MoCrySIL app, the client PKCS#11 CrySIL library

and WebVPN. The CrySIL provider is considered as

trustworthy. However, similar to the cloud provider

the components might be successfully attacked by a

third party. Finally, the push notiﬁcation provider is

hosted by the respective mobile platform – in this case

Google. Here, the same assumptions as for the cloud

provider are taken.

5.1.2 Assets

The plain email data handled on the client is consid-

ered as the primary asset. The client’s crypto APIs

are capable of handling bulk cryptographic operations

(e.g. hashing and symmetric algorithms) as well as

Entities and assets are formatted in italic/bold.

such as Amazon EC2, or Jelastic

MoCrySIL-CarryYourCryptographicKeysinYourPocket

289

key wrapping and signature veriﬁcation. Thus, the

MoCrySIL app and the key material is only used for

(1) signing the hash values and (2) for decrypting

the symmetric content encryption keys. The crypto-

graphic material (symmetric keys and hash values)

needs to be transferred to the MoCrySIL app. Know-

ing the symmetric keys would allow an attacker to de-

crypt an encrypted email, whereas being able to ma-

nipulate the transferred hash values would allow an

attacker to sign arbitrary documents in the name of the

legitimate user. Another core security asset is repre-

sented by the asymmetric cryptographic keys stored

in the Android KeyChain. An attacker who can ex-

tract or use these keys is capable of signing arbitrary

content in the name of the legitimate user or decrypt-

ing her emails.

5.1.3 Threats, Countermeasures and Risks

By considering the assumptions, the assets, and the

different players the proposed system can be analysed

in respect to attacks (A), threats (T), countermeasures

Cloud Provider. (A1) The honest-but-curios cloud

provider might listen to the ongoing communication

but does not attack the deployed applications. (A2)

The cloud service provider is successfully attacked

by a third party, who deliberately intends to gain ac-

cess to or manipulate data transferred over WebVPN.

In a similar way, a possibly malicious cloud provider

needs to be considered.

(T1) Denial-Of-Service (relevant for A1, A2).

The communication between the clients and the

MoCrySIL device might be subject to a DOS attack,

which prohibits the utilisation of the provided crypto-

graphic services. The current system is not capable of

addressing this threat due to the reliance on the Web-

VPN component. As a consequence the residual risk

of a DOS-attack remains (R1 – DOS CrySIL com-

munication).

(T2) Snifﬁng Communication Meta Data (rele-

vant for A1, A2). The attacker is capable of snifﬁng

communication meta data of the connections between

clients and MoCrySIL devices. This meta-data in-

cludes IP addresses, information that can be extracted

from the TLS handshake (certiﬁcates, cipher-suites)

for the end-2-end security tunnel or usage data (time,

amount of trafﬁc). Capturing this data cannot be mit-

igated by the current system (no countermeasures)

and thus needs to be considered as residual risk (R2 –

Gaining communication meta data)

Deploying the WebVPN components within a private

cloud can address this residual risk. However, this scenario

(T3) Snifﬁng/Manipulating Cryptographic

Material (relevant for A2, partly A1)). A successful

attacker might try to sniff (A1, A2) or manipulate

transferred cryptographic material (cryptographic

hashes or symmetric keys) (A2). Manipulating this

data would allow an attacker to sign arbitrary docu-

ments (by exchanging the transferred hash values) or

decrypt arbitrary symmetric keys (see T5 for details).

(T4): Re-routing Packets (relevant for A2). The

attacker re-routes (1) CrySIL protocol packets from

a legitimate client to other MoCrySIL devices, or (2)

from a malicious client to a speciﬁc MoCrySIL de-

vice: The latter has a high impact on security, be-

cause it could enable an attacker to sign arbitrary doc-

uments in the name of the attacked MoCrySIL user.

Also, documents belonging to that user could be de-

crypted by sending malicious decryption requests to

the CrySIL infrastructure (see T5 for details).

(T5): Man-In-The-Middle Attack. T3 and T4

are mitigated by the end-2-end encryption TLS tunnel

(C1 – TLS tunnel). However, the system is some-

what susceptible to MITM attacks. During the initial

communication handshake the user currently needs

to verify the validity of the certiﬁcate by compar-

ing certiﬁcate hash values that are displayed on the

MoCrySIL app and the client. Failing to do so would

allow an attacker (A2) to carry out an MITM attack

and read and manipulate the CrySIL protocol packets.

Therefore, the residual risk of a MITM attack – with

the consequences described in T3 and T4 – needs to

be considered (R3 – MITM attack).

Push Notiﬁcation Provider. Attack vectors on the

push notiﬁcation provider are highly similar to those

on the cloud service provider: (A3) Honest-but-

curious Push Notiﬁcation Provider (similar to A1)

and (A4) External attack on Push Notiﬁcation Ser-

vice (similar to A2). However due to “wake-up” only

nature of the push notiﬁcations the consequences dif-

fer from those of A1 and A2.

(T6) Denial of Service (relevant for A4). The

push notiﬁcation service of WebVPN could be sub-

ject to a DOS attack. In this case, the “wake-up-call”

to initiate the WebSocket channel would be lost. This

can simply be mitigated by allowing the user to man-

ually start the MoCrySIL app (C2 – Manual estab-

lishment of communication channel). Therefore,

the residual risk of this DOS attack has a very low

impact (R4 – DOS Push Notiﬁcation System).

(T7) Snifﬁng/Manipulation of the Push Notiﬁ-

cation Messages (relevant for A4, partly A3). In this

case the attacker listens to push notiﬁcation commu-

nication (A3, A4), or manipulates (A4) push notiﬁ-

is not considered in the assumptions.

SECRYPT2015-InternationalConferenceonSecurityandCryptography

290

cation tokens or sends arbitrary tokens (A4) to the

MoCrySIL app. Due to the “wake-up-call” nature

of the push notiﬁcations, there is no residual risk in

learning their content.

Mobile Device and User. The attacks are mainly

related to attacking the mobile device either by gain-

ing physical access or by injecting malicious soft-

ware. (A5) refers to stealing the device with the in-

tention to extract/or use the key material stored on the

mobile device. (A6) refers to an attack carried out by

a malicious application that does not/cannot gain root

access. (A7) refers to malware that is capable of gain-

ing root access. (A8) refers to external attacks orig-

inating from an outside location by exploiting weak-

nesses of the system or the user.

(T8) Extracting Cryptographic Keys (relevant

for A5, A7). By extracting the asymmetric keys, the

attacker can arbitrarily use them to create signatures

or to decrypt symmetric key material. The impact is

different when (1) the user is aware of attack (e.g., due

to stealing the device) and (2) the user is not aware of

the key extraction process (e.g. due to malware). The

latter allows an attacker to use the keys for a long time

before countermeasures are taken. The most effec-

tive countermeasure against the extraction of private

key material is the utilisation of the hardware-backed

key storage (C3 – Hardware-backed key storage).

There remains a very low risk that the key material

could be extracted via a side-channel attack. How-

ever, an application scenario in which an attacker is

willing carry out this complex attack must never be

considered for a mobile use case.

(T9) Using Cryptographic Keys (relevant for

A5, A7). This threat needs to be considered in de-

tail, since it can only be partly mitigated by the em-

ployed hardware element. An attacker who gains ac-

cess to the CrySIL interface offered by the MoCrySIL

app and either knows the authentication credentials or

circumvents the authentication system can arbitrarily

sign and decrypt data. Similar to T8 the impact is

considered to be higher when the user is not aware

of the ongoing misuse. All in all, the residual risk

and countermeasures are strongly tied to mobile de-

vice security (R5/C5 – Security of mobile device).

(T10) Stealing Credentials (relevant for A7 and

especially for A6). Due to the nature of the

MoCrySIL authentication process, this threat does not

apply to this type of credentials. However, creden-

tials, that are used to protect the Android KeyChain

and the mobile device could be subject of an attack.

Such an attack could rely on malware that either di-

rectly captures the entered credentials (A7), lures the

user into entering them (phishing) (A6). Phished cre-

dentials could then be used when the device is stolen

at a later time. Especially, the malware problem

can be mitigated by the same countermeasures as de-

scribed in T9. The risk of gaining access to the cre-

dentials by shoulder surﬁng needs to be considered as

residual risk (R6 – Stealing credentials).

(T11) Accepting a Malicious Request (relevant

for A8). An attacker who gets to know the Comm

ID could send a CrySIL request to the CrySIL URL.

However, the authentication process requires the user

to enter a PIN code that is only shown by the client’s

CrySIL library. Thus, the user is not able to enter the

correct PIN code, even if she would interpret the ma-

licious request as valid (C6 – CrySIL authentication

system). However, an attacker could easily mount a

denial of service attack by sending arbitrary requests

to the communication end point. This threat cannot be

addressed by the current CrySIL authentication fea-

tures and thus manifests in a residual risk (R7 – DOS

by an external attacker).

(T12) Impersonating Another Device (relevant

for A8). An attacker might try to impersonate a target

device when connecting to the WebVPN communica-

tion end point. Even if the attacker learns the comm

ID, he still has no access to the TLS certiﬁcate used

by the device for WebVPN authentication (C7 – We-

bVPN authentication).

5.1.4 Discussion on Risks

The residuals risks are mainly associated with DOS

attacks (R1, R4, R7), gaining meta-information (R2),

deploying malware on the device (R5, R6) and attack-

ing the user (R6, R3). The attacks related to DOS

and extracting meta-information do not have a sig-

niﬁcant security-related impact on the MoCrySIL ar-

chitecture. However, the remaining risks have severe

consequences and need to be mitigated by managing

the device and implementing tight security policies

(device encryption, password locks etc.).

With having these policies in place, MoCrySIL’s

security services offer a solid level of security.

5.2 Performance

As for performance, relying on a third party for com-

munication takes time. Yet, our use of long-lived

Websocket connections reduces the amount of time

lost in creating a connection signiﬁcantly.

As for the integration efforts, whenever an appli-

cation utilises well-known crypto APIs, CrySIL can

be integrated with a minimal effort. As of today, we

work on receivers for PKCS11, JCE, MS CNG and

W3C Crypto API. One can easily implement such a

MoCrySIL-CarryYourCryptographicKeysinYourPocket

291

module if needed. For Java, our JCE receiver mod-

ule for example is implemented using only 1000 lines

of prototypical code, router and sending communica-

tions modules do have 80 loc each with a common

protocol deﬁnition of 1500 loc. The code of imported

libraries is not included in the numbers given.

6 FUTURE WORK AND

CONCLUSIONS

With MoCrySIL, we present our solution of a secure,

ﬂexible and portable personal key store service one

can carry around in his pocket. MoCrySIL removes

the need for a trusted third party and therefore com-

plements our CrySIL solution well.

Our prototype implementation highlights the ﬂex-

ibility of the CrySIL architecture, shows its potential

and afﬁrms the ease of use for developers and end

users. The security analysis of MoCrySIL indicates

that using hardware-backed key storage facilities on

mobile devices allows to reach a signiﬁcant level of

security. Due to the uncontrolled environment a mo-

bile device is used in, however, the residual risks for

certain threats is higher than in classic deployment

scenarios. Therefore, MoCrySIL focuses on standard

applications where the hardware-backed key storage

facilities on mobile devices already provide a signif-

icant improvement of the security when compared to

standard software-based key storage solutions.

Future work will extend CrySIL’s feature set and

client APIs and heavily focus on extending the ﬂexi-

bility of the authentication system to allow for an even

wider range of use cases.

REFERENCES

Benaloh, J., Chase, M., Horvitz, E., and Lauter, K. (2009).

Patient controlled encryption: Ensuring privacy of

electronic medical records. In Proceedings of the 2009

ACM Workshop on Cloud Computing Security, CCSW

’09, pages 103–114, New York, NY, USA. ACM.

Bleikertz, S., Bugiel, S., Ideler, H., N

urnberger, S.,

and Sadeghi, A.-R. (2013). Client-controlled

cryptography-as-a-service in the cloud. In Applied

Cryptography and Network Security, volume 7954

of Lecture Notes in Computer Science, pages 19–36.

Springer Berlin Heidelberg.

Butt, S., Lagar-Cavilla, H. A., Srivastava, A., and Gana-

pathy, V. (2012). Self-service cloud computing. In

Proceedings of the 2012 ACM Conference on Com-

puter and Communications Security, CCS ’12, pages

253–264, New York, NY, USA. ACM.

Egele, M., Brumley, D., Fratantonio, Y., and Kruegel, C.

(2013). An empirical study of cryptographic misuse

in android applications. In Proceedings of the 2013

ACM SIGSAC conference on Computer & communi-

cations security - CCS ’13, pages 73–84, New York,

New York, USA. ACM Press.

Fahl, S., Harbach, M., Muders, T., Smith, M., Baumg

artner,

L., and Freisleben, B. (2012). Why eve and mallory

love android. In Proceedings of the 2012 ACM con-

ference on Computer and communications security -

CCS ’12, page 50, New York, New York, USA. ACM

Press.

Kamara, S. and Lauter, K. (2010). Cryptographic cloud

storage. In Lecture Notes in Computer Science, vol-

ume 6054, pages 136–149.

KMIP-v1.1 (2013). Key Management Interoperability Pro-

tocol Speciﬁcation Version 1.1. OASIS Standard.

Lei, S., Zsihan, D., and Jindi, G. (2010). Research on Key

Management Infrastructure in Cloud Computing En-

vironments. In 9th International Conference on Grid

and Cooperative Computing (GCC), pages 404 – 407,

Nanjing. IEEE.

Leitold, H., Hollosi, A., and Posch, R. (2002). Security

architecture of the Austrian citizen card concept. 18th

Annual Computer Security Applications Conference,

2002. Proceedings.

Reimair, F., Teuﬂ, P., and Zefferer, T. (2015). WebCrySIL -

Web Cryptographic Service Interoperability Layer. In

Web Information Systems and Technologies.

Rocha, F. and Correia, M. P. (2011). Lucy in the sky without

diamonds: Stealing conﬁdential data in the cloud. In

41st International Conference on Dependable Systems

and Networks Workshops (DSN-W), pages 129 – 134,

Hong Kong. IEEE.

Toegl, R., , Reimair, F., and Pirker, M. (2013). Waltzing the

Bear, or: A trusted virtual security module. volume

7868 of Lecture Notes in Computer Science, pages

145–160. Springer Berlin Heidelberg.

Trusted Computing Group (2011). TCG TPM

speciﬁcation version 1.2 revision 116.

http://www.trustedcomputinggroup.org/resources/

tpm main speciﬁcation. last visited on January 29,

2013.

SECRYPT2015-InternationalConferenceonSecurityandCryptography

292