WebCrySIL

Web Cryptographic Service Interoperability Layer

Florian Reimair, Peter Teuﬂ and Thomas Zefferer

Institute for Applied Information Processing and Communications, Graz University of Technology, Inffeldgasse 16a,

Graz, Austria

Keywords:

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

cations, Mobile Devices.

Abstract:

Today’s applications need to work with a heterogeneous collection of platforms. Servers, desktops, mobile

devices, and web browsers share data and workload. Many of these applications handle sensitive data or even

have security as their core feature. Secure messaging, password storage, encrypted cloud storage applications

or alike make use of cryptographic algorithms and protocols. These algorithms and protocols require keys.

The keys in turn have to be provisioned, securely stored, and shared between various devices. Unfortunately,

handling the keys and the availability of cryptographic APIs evokes non-trivial challenges in current hetero-

geneous platform environments. Also, the implementation of APIs supporting cryptographic protocols on

arbitrary platforms require signiﬁcant effort, which is a major challenge when new cryptographic protocols

become available. Our approach, the Crypto Service Interoperability Layer (CrySIL), enables applications to

securely store/use/share key material and supports a wide range of cryptographic protocols and algorithms on

heterogeneous platforms. CrySIL complements existing solutions that mitigate the aforementioned problems

through central services by allowing for more ﬂexible deployment scenarios. In this work, we explain the mo-

tivation of CrySIL, describe its architecture, highlight its deployment in a typical heterogeneous application

use case and reﬂect on achievements and shortcomings.

1 INTRODUCTION

In recent years, a highly heterogeneous platform land-

scape has become the standard scenario for the de-

velopment and deployment of applications. Espe-

cially mobile device platforms introduced an unprece-

dented level of architectural heterogeneity. Modern

web browsers support rich HTML5-based applica-

tions, well known mobile devices are here to stay,

new wearable computing systems claim their place in

the world and classic desktop operating systems still

stand their ground.

Applications present the user with use cases that

became available only recently. Developing appli-

cations for today’s and tomorrow’s diverse environ-

ments boosts complexity of the development pro-

cesses signiﬁcantly. Especially security-related as-

pects – the deployment of cryptographic algorithms

and protocols to offer conﬁdentiality, integrity and

authenticity for the processed data – suffer from this

complexity in several ways: First, cryptographic algo-

rithm and protocol implementations are not available

on every platform. Second, the capabilities of differ-

ent platforms to handle the required key material in a

secure way strongly deviates. Third, the high level of

complexity causes implementation mistakes that lead

to signiﬁcant security issues (Egele et al., 2013; Fahl

et al., 2012).

While existing and well-established solutions,

such as smart cards and cryptographic tokens offer a

way to solve the challenge of key storage, distribu-

tion, and handling, they are only available on limited

platforms and cause additional cost and usability is-

sues when being integrated in heterogeneous applica-

tions. Platform-based systems, i. e. TPMs (Trusted

Computing Group, 2011), mobile TPMs, or propri-

etary solutions offer reasonable security, given that

the security features are activated and conﬁgured ac-

cordingly. These system seldom share common con-

ﬁguration and features and therefore have to be con-

ﬁgured and used one by one. The challenge is to get it

right, every time. The challenge becomes even greater

when multiple platforms with different hardware or

software-based encryption systems are to protect sen-

sitive data. These examples represent only a small ex-

cerpt of the entire problem space and are augmented

Reimair F., Teuﬂ P. and Zefferer T..

WebCrySIL - Web Cryptographic Service Interoperability Layer.

DOI: 10.5220/0005488400350044

In Proceedings of the 11th International Conference on Web Information Systems and Technologies (WEBIST-2015), pages 35-44

ISBN: 978-989-758-106-9

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

by the fact that the availability of cryptographic APIs

is strongly platform-dependent. E.g. when consider-

ing the web browser within an application scenario,

one has to keep in mind that hardly any cryptographic

API nor a secure key storage component is available.

While it might seem reasonable to hold conﬁden-

tial and secret cryptographic material directly at the

user’s device and refrain from storing these data on a

central server, a severe drawback emerges: If stored

locally, cryptographic material is not available every-

where and at any time. For instance, access to e-

government services is infeasible in case the solicited

smart card-based user authentication is impossible be-

cause the end-user device does not provide appropri-

ate card-reading capabilities. In times, in which mo-

bile and wearable devices are of growing importance,

this is becoming a signiﬁcant issue.

The industry created central cryptographic service

to meet the anywhere and at-any-time requirements.

We reviewed some solutions and found that their lim-

ited scope make them only suitable for speciﬁc use

cases and deployment scenarios. For example, the

Austrian Mobile Phone Signature solution is limited

to the creation of electronic signatures, but does not

feature cipher operations. The CloudHSM solution

provided by Amazon is limited in terms of possible

deployment scenarios. In particular, this solution is

tied to a Public Cloud solution and to one speciﬁc

Cloud provider. Similar limitations apply to com-

parable server-based solutions that offer storage of

cryptographic material and central provision of cryp-

tographic services. Furthermore, these solutions do

not use or include locally available key material and

cryptographic functions, which still might play an im-

portant role in many use cases.

To overcome limitations of existing solutions and

to further improve the availability of cryptographic

services everywhere and at any time, we propose

the Crypto Service Interoperability Layer (CrySIL).

CrySIL provides a ﬂexible architecture to use crypto-

graphic protocols and algorithms in a heterogeneous

environment and provides secure key storage and key

handling capabilities. It features build-in authenti-

cation as well as transparent off-device key storage.

When used as central service CrySIL can also be

seen as a cryptographic platform for the rapid de-

ployment of new cryptographic protocols, which are

not yet supported by hardware and software solutions.

This feature is especially important for upcoming ad-

vanced cryptographic protocols that will play an im-

portant role in cloud computing security.

The remainder of this paper is organized as fol-

lows. In Section 2, the motivation for CrySIL is out-

lined by discussing the current deployment of cryp-

tographic algorithms and functions in heterogeneous

application environments. Related work in Section 3

is followed by a detailed description of the CrySIL ar-

chitecture in Section 4. Subsequently, in Section 5 the

functionality and security challenges of CrySIL are

explained by investigating the prototype of browser

application for platform-independent ﬁle-encryption.

Finally, the work is concluded by giving an outlook

on future CrySIL plans and deployment scenarios.

2 BACKGROUND

The following deployment scenarios and applica-

tion categories highlight the manifold use of crypto-

graphic algorithms and protocols and the associated

problems of deploying such technologies in heteroge-

neous application environments.

In recent years mobile platforms have provoked

a rush to applications that allow users to access and

process their data on a wide range of devices. Nowa-

days a heterogeneous application comes in versions

for desktop-based systems, different mobile device

platforms and web browsers. In addition, speciﬁc en-

vironments, such as the Chrome Apps platform

, fur-

ther speciﬁc mobile environments (e.g., tablets, ph-

ablets, smartphones) and vendor-speciﬁc aspects need

to be covered. In recent years the ﬁrst mass mar-

ket wearable devices have been released and are ex-

pected to gain signiﬁcant usage numbers in the near

future (IDC, 2014). While this heterogeneous device

landscape offers signiﬁcant new opportunities for cus-

tomers, it comes with a major price tag – complex-

ity. Developing for so many platforms requires differ-

ent user experience design (UXD) strategies, different

platform-speciﬁc programming-language and archi-

tecture skills and – especially important for the scope

of this work – in depth knowledge on how to provide

conﬁdentiality, integrity and authenticity for the pro-

cessed data. Protecting the application data is espe-

cially relevant in the context of exchanging this data

via cloud infrastructures to provide instant access on

heterogeneous application platforms. Noteworthy ex-

amples for such applications are note-taking applica-

tions, messengers, applications for collaborative doc-

ument processing, or cloud storage providers. Obvi-

ously, the secure handling of this data needs to be con-

sidered in the local environment as well as when the

data is transferred and stored at the cloud provider. To

offer the required level of protection, cryptographic

algorithms and protocols are deployed.

In a similar way, applications that advertise secu-

https://developer.chrome.com/apps/app architecture

WEBIST2015-11thInternationalConferenceonWebInformationSystemsandTechnologies

rity features as core functionality require the deploy-

ment of cryptographic algorithms and protocols. Ex-

amples for this application category are secure mes-

sengers, encrypted cloud storage solutions or pass-

word managers. On a high-level view those applica-

tions face the same challenges as the heterogeneous

applications described above. However, the security

requirements for those applications are typically more

complex due to the higher likelihood of targeted at-

tacks.

Security and especially the deployment of crypto-

graphic functions are core aspects of enterprise-level

applications. VPN solutions based on IPSEC or TLS

are widely deployed to guard network communica-

tions, S/MIME or PGP are required to ensure the

conﬁdentiality, authenticity and integrity of emails.

While these communication systems are based on

well established protocols, a rather new concept –

digital signatures to create authentic documents – is

not. Legal frameworks (e.g., (Parliament and Coun-

cil, 2000)) have established the basis for the legally

binding use of digital signatures. The applications of

advanced digital signatures within private and corpo-

rate perspectives are manifold: signing legally bind-

ing documents (e.g. contracts), automatically sign-

ing documents (e.g. invoices), or providing authen-

ticity and integrity for stored documents in general.

The security requirements for enterprise-level appli-

cations mostly exceed the requirements for applica-

tions for personal use due to much higher security re-

quirements.

All in all, the wide deployment of cloud comput-

ing in recent years has brought up many issues in re-

lation to security, privacy and data protection laws.

E.g. using U.S. cloud computing resources in Eu-

rope is linked to signiﬁcant legal issues (van Hoboken

et al., 2012). One technical approach to stand these

challenges is to deploy data encryption mechanisms.

However, when using current cryptographic schemes,

data needs to be encrypted directly at the client be-

fore it is stored at the cloud service provider. That, in

fact, keeps the data protected while at rest but makes

one of the main advantages of cloud computing – on-

line data processing – much harder. Current research,

however, focuses on new cryptographic protocols and

algorithms capable of processing encrypted data in

the cloud. The required functionality is brought –

among others – by new cryptographic protocols and

algorithms in the areas of homomorphic encryption

(Naehrig et al., 2011), searchable encryption (Bel-

lare et al., 2007), veriﬁable encryption (Camenisch

and Shoup, 2003), proxy re-encryption schemes (Ate-

niese et al., 2006) or redactable signature schemes

(e.g, (Hanser and Slamanig, 2013)). There is a high

variety in the applicability of these new protocols in

production environments. While in certain cases the

schemes are not yet suited for practical applications

(e.g. homomorphic encryption), other schemes such

as proxy-re-encryption have already reached a proto-

typical stage (e.g., the NICS CRYPT Library

). How-

ever, even protocols from the latter category cannot

yet be efﬁciently deployed in existing applications

due to the lack of compatibility with current high level

standards and the lack of hardware and software sup-

port on various platforms.

By considering the current challenges related to

platform support and secure key storage facilities, the

following conclusions on using cryptography in het-

erogeneous applications can be drawn: Due to the

presence of these challenges, heterogeneous applica-

tions either do not support cryptographic functions,

face usability issues, or suffer from implementation

weaknesses due to the wrong use of cryptographic

primitives and methods. Furthermore, certain plat-

forms currently do not have any reasonable support

for cryptographic algorithms and key storage facilities

at all. And that is where novel solutions are needed.

3 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.

SigningHub

offers the creation of advanced digi-

tal signatures with unique cryptographic keys for dif-

ferent users. As a cloud-based service, it provides

centrally-stored keys as well as signature creation us-

ing keys stored on smart cards or soft tokens. Signed

documents are stored and managed on servers pro-

vided by SigningHub. The service can be easily in-

tegrated into applications and web services using a

simple REST-based interface.

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

https://www.nics.uma.es/dnunez/nics-crypto

http://www.signinghub.com

https://www.dictao.com

http://www.cryptomathic.com

WebCrySIL-WebCryptographicServiceInteroperabilityLayer

enterprise IT infrastructure. Basically, the provided

functionality is limited to user authentication and sig-

nature creation.

The Austrian citizen card (Leitold et al., 2002),

which represents the ofﬁcial eID in Austria, is a

technology-neutral concept for unique citizen identi-

ﬁcation and secure qualiﬁed signature creation. Aside

from smart card-related implementations, a cloud-

based service is operational. The so-called Austrian

Mobile Phone Signature

is operated in a private

cloud and uses a hardware security module (HSM)

to store the private signature keys of all Austrian

citizens. Access to these keys is protected by a

strong two-factor authentication mechanism, involv-

ing 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 functionality through a well-deﬁned XML-

based interface. Although the Austrian Mobile Phone

Signature meets the demands of the law, the currently

deployed implementation fails to support use cases

other than signature creation and user identiﬁcation.

With AWS CloudHSM

, Amazon feeds the de-

mand of integrating secure cryptographic operations

into deployed applications without requiring an HSM

available on premise. To meet regulatory require-

ments for data security, customers are able to acquire

sole access to appliances on a dedicated HSM and

therefore retain full control of the keys and the cryp-

tographic operations of the HSM. The offered func-

tionality of the HSM can be integrated into applica-

tions that are deployed within the Amazon Virtual Pri-

vate Cloud (Amazon VPC) via the provided Java or

C programming API. As AWS CloudHSM can only

be used in conjunction with Amazon VPC, customers

are bound to Amazon and a migration to other cloud

providers is infeasible.

The content delivery network CloudFlare

elabo-

rated a solution that enables website visitors to estab-

lish a TLS connection with a Cloudﬂare server while

retaining the private key on the server of a customer.

The technique, entitled Keyless SSL, is transparent to

a website visitor and takes place between a Cloudﬂare

server, acting as a reverse proxy, and the key server

where the private key resides. The Cloudﬂare server

is fully capable of negotiating the TLS connection but

shifts the generation of the signatures for the client

random, server random, and public key certiﬁcate to

the customer side. While this concept ascertains that

Cloudﬂare servers have no access to the private key,

they still know the negotiated session keys and are

https://www.handy-signatur.at

https://aws.amazon.com/cloudhsm/

https://www.cloudﬂare.com

thus able to read and write any data ﬂowing between

the website visitor and a target web server. As a con-

sequence, end-to-end security is undermined and the

overall beneﬁt derogates to having out-sourced all op-

erations involving the private key.

4 CRYPTO SERVICE

INTEROPERABILITY LAYER

Motivated by the unsolved challenges and already

available solutions, we have created the Crypto Ser-

vice Interoperability Layer (CrySIL). CrySIL creates

an interoperability framework that allows the user ac-

cess to his key data regardless where the key resides.

In short, the user takes one of her devices and

launches an application to perform some crypto-

graphic task. The application interfaces with the in-

teroperability layer, CrySIL, which connects to an-

other device. This other device has access to the ac-

tual cryptographic primitive, creates and validates au-

thentication challenges if required and performs the

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 1.

Figure 1: CrySIL’s basic architecture.

The ﬂexible design of CrySIL allows for numer-

ous deployment scenarios. First and foremost, the de-

vice having access to the key material can be the very

same device the user interfaces with. Thus, CrySIL

fulﬁls the use case requirements of using local cryp-

tographic services – as provided by smart cards. Fur-

ther, the device can be a cloud service provider offer-

ing the service to a broad range of users. This scenario

reﬂects the central service paradigm as seen in in-

dustry solutions. A rather novel deployment scenario

possible with CrySIL is to move the central cloud-

based service to a user’s mobile device. This scenario

is motivated by the relative high level of security that

can be offered by a mobile device when encryption

systems and access protection systems are activated

and correctly conﬁgured.

4.1 Interoperability Layer Node

The heart of our CrySIL approach is the interoper-

WEBIST2015-11thInternationalConferenceonWebInformationSystemsandTechnologies

Figure 2: CrySIL node architecture overview.

ability layer node (denoted as IL in 1). The modular

node design enables the ﬂexibility and extensibility of

our approach while keeping the overall architecture

simple.

Most conventional cryptographic service

providers receive commands, perform the required

actions, and return the result to the caller. To achieve

CrySIL’s interoperability goal, CrySIL breaks the

classic cryptographic provider apart. The resulting

modules have different jobs and work together to

form the actual cryptographic service provider. The

most visible modules are command receivers and

the modules which act on cryptographic primitives

– actors. Another crucial module is responsible for

connecting receivers and actors. Other modules

handle inter-node communication, protocol map-

pings, advanced crypto and authentication. All are

considered as building blocks and are not restricted to

any technology, platform, or programming language.

An illustration of modules and their interconnections

is given in 2.

A receiver offers a set of cryptographic functions

to the application developer. Being a design concept,

a receiver can be implemented to run on any device,

any platform, and any technology. A receiver does

not perform any cryptographic operations but inter-

faces with the routing module after having the com-

mand encoded as interoperability protocol command.

A realisation of a receiver can be cryptographic APIs

on a programming language level like JCE, CSP, or

the W3C Web Cryptography API. Another realisa-

tion can serve as a web-service providing a SOAP-

based cryptographic interface. Having a realisation

that interfaces with clients of the PKCS#11 standard

or PC/Smart Card daemons (PCSCd) can bring re-

mote key storage capabilities to existing applications.

An actor makes the contents of a speciﬁc key

provider available to the interoperability layer. A

key provider hosts key material and performs the

actual cryptographic operation. The actor can be

implemented to connect arbitrary key providers to

CrySIL. Sample key providers are smart cards at-

tached to a PC, USB-Tokens, Software Security Mod-

ules (SSMs), as well as Hardware Security Modules

(HSMs). An actor+ might provide high-level crypto-

graphic methods such as CMS encryption or XMLD-

SIG signatures while using the cryptographic primi-

tives of other actors.

The central routing module – the router – re-

ceives commands from the receiver modules and as-

signs them to the appropriate actor modules. CrySIL

supports a many-to-many relationship between actors

and receivers in a completely transparent way.

4.2 Inter-Node Communication

The use cases ask for cryptographic primitives and

services to be available anywhere and at any time.

CrySIL’s answer is transparent off-device cryptogra-

phy, which mandates inter-node communication. Off-

device cryptography allows a device that is not capa-

ble of doing a certain cryptographic operation on its

own to use the cryptographic engine of a remote ser-

vice. The device therefore can do the operation at the

cost of having to trust the remote service.

The communication modules are in charge of

inter-node communication. They simply take a re-

quest and send it to another off-device communi-

cations module. The most basic implementation is

HTTP(s). Yet, arbitrary transport protocols, such

as HTML5 PostMessage, Web-sockets, or IPSec are

suitable.

Putting the pieces together, CrySIL renders off-

device crypto completely transparent to the user, the

developer, and to the application while maintaining a

simple architecture. With inter-node communcation,

there can be one or multiple nodes per device. The

resulting architecture is depicted in 3. Our approach

Figure 3: Interoperability architecture view.

enables almost complete key ﬂexibility. A user bene-

ﬁts from her ability to use a variety of different keys

provided by different key providers from a variety of

applications on different devices.

4.3 Authentication

Whenever cryptographic keys are used by an applica-

tion, there must be access and usage policies in place.

For local deployments, the simplest policy is that ev-

eryone can use the key. Similarly, a policy might re-

WebCrySIL-WebCryptographicServiceInteroperabilityLayer

quire a PIN code for a local smart card. Such rather

simple policies can be enforced by the device or the

operating system. However, the cross-device/inter-

node key access feature of CrySIL asks for a policy

enforcement system that meets the requirements be-

yond in-device solutions.

As CrySIL can interface with key providers that

may already require for authentication information,

CrySIL has to collect and provide the authentication

data. Within CrySIL only the actor knows about the

authentication requirements of its key provider and

has to challenge the user accordingly. CrySIL can

support simple PIN challenges over external identity

providers (OAuth, OpenID Connect) to multi-factor

authentication methods. As for standing the above

mentioned challenges, the CrySIL infrastructure gath-

ers authentication data from the user as well.

The authentication modules offered by CrySIL are

organized in a ﬂexible and extensible manner. Differ-

ent authentication modules can handle different au-

thentication concepts from a simple PIN query over

OpenID Connect to strong two-factor authentication

systems. A developer can use any service with any

authentication mechanism but does not have to bother

with authentication concerns. Applications can there-

fore offer strong authentication mechanisms with lit-

tle extra effort. Furthermore, authentication modules

are designed to keep sensible credentials away from

the receiver and therefore from the application. A ma-

licious application therefore might have a harder time

to eavesdrop or attack the credentials which results in

an overall security boost.

Last but not least, the interoperability layer proto-

col foresees the use of session information. The ses-

sion feature allows an actor to create one of the es-

tablished session management systems to allow ses-

sions with lifetime exceeding that of a single request.

An application can therefore use an authorized key

a number of times before he has to re-authenticate

again. That might enable the user to accept stronger

authentication as a hurdle during the key unlocking

procedure.

5 EVALUATION

In order to demonstrate and evaluate our approach,

we have implemented a number of prototypes in the

course of our research. The focus lies on evaluating

the ﬂexibility and combinability of the CrySIL build-

ing blocks in order to solve different use cases.

In this section, we will describe our protected-

data-at-rest prototype in terms of features, deploy-

ment scenarios, practical applicability, and beneﬁts

over other solutions. The prototype addresses the sce-

nario where a user gets some data from a friend and

wants to use the data on multiple devices. The objec-

tive is that the data is encrypted whenever it is not on

a device owned by the user or the friend. The scenario

is depicted in 4. The setup is done with state-of-the-

art communication and crypto. Trust relationships as

well as attack vectors are well known from any hard-

ware security module deployment scenario. There-

fore, a thorough security analysis would not yield new

information on security and trust issues, and is there-

fore omitted.

5.1 Deployment Scenario

The users, denoted as user 1 and user 2, have no pro-

found understanding of cryptography and are using

web browsers on PCs and mobile devices. It is as-

sumed that for users who are no experts in the ﬁeld

of IT security, it is too much of a hurdle to perform

manual key exchange in a secure way.

The storage solution used in the scenario is de-

ﬁned to be some shared storage solution with instant

sharing. For example, a public cloud storage service

like Dropbox

. This solution solicits no manual ex-

change of the data like it would be when using tech-

nologies like instant messaging or electronic mail and

therefore keeps the prototype clean and easy to under-

stand.

Figure 4: Prototype: protected-data-at-rest deployment sce-

nario.

On either device, be it the phone, the tablet, or the

PC, a web browser runs an HTML5 and JavaScript

browser application. The application encrypts arbi-

trary data before it submits the data to the shared stor-

age service with the help of the W3C Web Cryptog-

raphy API. In this case, the API is implemented by

JavaScript version of a CrySIL node. This node is

referred to as the application’s CrySIL node later on.

Hiding behind the Web Crypto API, the application’s

CrySIL node offers transparent access to a remote key

service over HTTPS.

https://dropbox.com

WEBIST2015-11thInternationalConferenceonWebInformationSystemsandTechnologies

The key service – acting as trusted third party – is

a Java 8/Spring 4 web application hosted on a Tomcat

server an referred to as key service CrySIL node later.

An HTTPS communication module offers remote ac-

cess. An actor+ capable of handling CMS containers

is available as well as an actor interfacing with a soft-

ware key store. Key store access is constraint by the

actor as follows:

• To retrieve the certiﬁcate of the key of user 1, it

is sufﬁcient to provide the correct identiﬁer of the

user.

• Using the key for decryption purpose, how-

ever, requires 2-factor authentication with a user-

name/passphrase tuple in the ﬁrst place and a mo-

bile TAN

as second factor.

To keep the prototype simple, we settled with some

less secure implementations. A hardware key store

(provided by an HSM) for the key service would bring

a major boost to the overall security. However, for the

sake of time and simplicity, the current implementa-

tions are based of software key stores.

5.2 Use Case

User 2 starts the browser application and add some

data that he wants to share with user 1. Before the

browser application sends the data to the cloud stor-

age, it interfaces with the CrySIL infrastructure to en-

crypt the data. This is where the browser applica-

tion hands over the control ﬂow to the application’s

CrySIL node. The ﬂow is only returned to the browser

application when the encrypted data arrives. An illus-

tration of the control ﬂow is given in 5.

Being asked to encrypt data, the application’s

CrySIL node asks user 2 to select a certiﬁcate that

should be used to encrypt the data. User 2 selects

the key service and the application’s CrySIL node

requests a list of certiﬁcates from the key service

CrySIL node. In any case, the key store actor of the

key service CrySIL node answers with an authenti-

cation challenge, demanding an identiﬁer. The chal-

lenge is picked up by the appropriate authentication

module within the the application’s CrySIL node. The

module interfaces with the human – user 2 – and

shows a graphical user interface where it asks for the

Mobile transaction numbers (TANs) are a two-factor au-

thentication process where the user proofs knowledge of a

secret and posession of a device, i.e. a mobile phone. The

secret is used to identify the user and therefore the mo-

bile phone. Then, a nonce is sent to the phone. The user

has to proof knowledge of the nonce. The user can know

about the nonce if and only if she has access to the mo-

bile phone in question. Mobile TANs are broadly used for

authentication in banking, industry, and cloud services.

Figure 5: Prototype encrypt command ﬂow.

required identiﬁer of user 1. User 2 provides the iden-

tiﬁer. The authentication module sends the informa-

tion back to the key service CrySIL node which an-

swers with the certiﬁcate of user 1. Note, that the

authentication information has never been processed

by the browser application itself.

The the application’s CrySIL node now sends an-

other request to the CrySIL infrastructure and asks for

encrypting the data with the just retrieved certiﬁcate

using the CMS standard. The router of the the appli-

cation’s CrySIL node decides that it has no means of

doing CMS locally and therefore forwards the whole

request to the key service CrySIL node. The key ser-

vice node receives the request, its router forwards it

to the CMS actor+ which in turn creates a CMS con-

tainer from the supplied data and returns it to the re-

ceiver of the application’s CrySIL node within the

browser application. Although sending a whole doc-

ument causes communication overhead, this example

highlights that a platform (the web browser) lacking

the required cryptographic APIs is still able to cre-

ate a CMS document. With the key service being a

trusted party and the communications being secured

by HTTPS, the encryption process is considered as

secure.

The resulting CMS container is returned to the

browser application which in turn sends it to the cloud

storage after authenticating there.

WebCrySIL-WebCryptographicServiceInteroperabilityLayer

Now user 1 can receive – i. e. read – the CMS con-

tainer which was just submitted to the shared storage

by user 2. The process is similar to the one described

above and illustrated in 5. The user takes one of her

devices and downloads the encrypted data. She uses

the same browser application to decrypt the CMS ﬁle

with the help of the CrySIL infrastructure. She has to

go through the process of selecting a certiﬁcate and

standing the challenge and standing a two-factor au-

thentication prior to the decryption process until the

result is available in the application’s CrySIL node

and therefore in the application.

5.3 Discussion

Our approach has a number of advantages over con-

ventional solutions. First and foremost, a centralised

key storage location enables a user to access her keys

at any time and anywhere. The only dependency

is an internet connection, but by having an internet-

accessible cloud storage service for data storage ren-

ders this dependency fulﬁlled whenever cloud access

is possible. Therefore, this feature closes the gap be-

tween classic cryptographic service providers and up-

coming requirement to serve multi-device users.

When sensitive key material is not stored on the

device itself, there is no need to share key data be-

tween devices. The risk of exposing the sensitive

key data during transmission is thus foreclosed com-

pletely. There is no need to align key storage solutions

to be able to translate key material where interfaces

and transmission channels are very restricted.

Not having access to the sensitive key material of

one key on different devices reduces the attack vectors

against the key drastically. Especially, since browsers

for example are most vulnerable in terms of protecting

sensitive key material. The private key material never

leaves the key provider environment.

The level of device and cryptographic expertise

required from developers is lower. The developer

can focus on creating a feature-rich application, well

tested and stable software instead of dealing with the

peculiarities of authentication and key exchange and

secure key storage on the devices in question. And,

nonetheless, create an application that uses cryptog-

raphy and enhances the privacy and security of the

user and her data.

Last but not least, CrySIL offers not only off-

device key storage but also off-device cryptographic

functions. A cryptographic service provider which

offers high level cryptographic methods such as CMS

or XMLDSIG for remote use enables a broad range of

devices and applications to use cryptography to pro-

tect the users’ data and privacy. With that, the increas-

ingly popular browser applications are enabled for the

use of cryptography in a much more secure manner

than with local key storage.

Finally, the CrySIL infrastructure relies solely on

well-known building blocks of cryptography. The se-

curity aspects of key stores, cryptographic providers,

as well as the communication solution are commonly

known and well-understood.

All the advantages come with the cost of yet an-

other trusted third party. Establishing certiﬁcations

and trust relationships are still required and come with

all advantages and drawbacks of this concept. Yet, the

CrySIL infrastructure also supports the deployment

of key stores on the user owned devices (e.g., home

servers or mobile devices), or directly supports local

crypto devices, such as smart cards.

5.4 Performance

As for performance, CrySIL does not implement any

cryptographic service itself. It solely integrates exist-

ing solutions and makes them accessible over various

APIs even on other devices. Therefore, depending on

the used key provider/crypto service, anything is pos-

sible between a few up to multi-hundred signatures

per second.

The infrastructure adds some overhead in the pro-

cess of redirecting a command to a crypto service.

The overhead is of constant size and in the magni-

tude of milliseconds. Having to collect authentication

information does require some time for fetching the

requirements, creating the challenge and reading the

response. This time lost is minimal compared to the

time a user needs to enter the required information.

Having an off-device scenario, there is of course

some delay when sending commands via the Internet.

Thus, in addition to performing the actual crypto pro-

cess and the redirecting process one round-trip-time

has to be added per command. For CrySIL, we en-

abled a batch mode so one can do multiple operations

per command as an optimization option.

Anyhow, these performance measurements are

made based on our prototypical implementation. The

implementation has not received any performance op-

timizations due to the fact that the main goal is to cre-

ate availability and not speed.

5.5 Integration Efforts

Whenever an application utilizes well-known crypto

APIs, CrySIL can be integrated with an effort next

to none. As of today, we work on receivers for

PKCS11, JCE (for desktop and Android), MS CNG,

W3C Crypto API, OpenSSL and OpenSC.

WEBIST2015-11thInternationalConferenceonWebInformationSystemsandTechnologies

In case a platform does not have the required

modules available, one can easily implement such a

module. The Java JCE receiver module for example

is implemented using only 1000 lines of prototypi-

cal code including some functionalities that are not

supported by the JCE framework. Our Java router

and sending communications modules do have 80 loc

each with a common protocol deﬁnition of 1500 loc.

The code of imported libraries are not included in the

numbers given.

6 FUTURE WORK

Our approach complements classic solutions so that

the new requirements of heterogeneous applications

and cloud environments can be met. However, there

are still gaps neither the related work nor our ap-

proach can solve currently.

The ﬁrst gap is the need to move authentication

away from the application. Our approach succeeds

in moving the authentication to the library and there-

fore preventing the sensitive credentials to be directly

processed by the application. Since the library runs

inside the application and shares its memory, an at-

tacker i. e. a malicious application might still be able

to eavesdrop or tamper with the sensitive information.

Having the credentials not reaching the application in

the ﬁrst place would foreclose this attack vector com-

pletely. For web applications, this could be realized

by using a separated iFrame, in case of mobile de-

vices, speciﬁc CrySIL apps could be used that are uti-

lized by other apps via IPC calls.

Other future use cases include the emulation

of attribute/identity based encryption, or proxy-re-

encryption schemes by using ﬂexible and ﬁne grained

authentication systems. E.g., proxy-re-encryption

schemes could be emulated by handing out authen-

tication tokens to third-parties who – by supplying

these tokens – are allowed to re-encrypt data for spe-

ciﬁc recipients. Similar approaches could be used

for the emulation of identity/attribute-based encryp-

tion schemes. However, the CrySIL platform could

also be used to directly implement such schemes and

thereby enable their usage on arbitrary platforms.

These examples represent a small collection of

possible future directions.

7 CONCLUSIONS

The deployment of cryptographic functions in het-

erogeneous applications and storing and handling key

material in a secure way faces many challenges in re-

lation to lack of platform support and high complex-

ity for the development teams. One way to approach

these problems is the introduction of central services

that deploy secure key storage facilities and provide

APIs that can be used on arbitrary platforms. Several

companies already offer such systems for the deploy-

ment of speciﬁc cryptographic functions. However,

those system lack the ﬂexibility in terms of supported

cryptographic algorithms and protocols and have not

been intended for generic use cases.

Therefore, this work presents the Crypto Service

Interoperability Layer (CrySIL) which has a highly

ﬂexible architecture that is capable of combining cen-

tral and local cryptographic services. The current sys-

tem has already been successfully used for several

prototypical applications and is constantly improved

by adding additional support for cryptographic algo-

rithms and APIs for different platforms.

REFERENCES

Ateniese, G., Fu, K., Green, M., and Hohenberger, S.

(2006). Improved proxy re-encryption schemes with

applications to secure distributed storage.

Bellare, M., Boldyreva, A., and O Neill, A. (2007). De-

terministic and Efﬁciently Searchable Encryption. In

Proceedings of the International Cryptology Confer-

ence on Advances in Cryptology (CRYPTO), pages

535–552. Springer.

Camenisch, J. and Shoup, V. (2003). Practical Veriﬁable

Encryption and Decryption of Discrete Logarithms. In

Boneh, D., editor, CRYPTO 2003: Advances in Cryp-

tology, volume 2729 of Lecture Notes in Computer

Science, pages 126–144. Springer Berlin Heidelberg.

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.

Hanser, C. and Slamanig, D. (2013). Blank digital signa-

tures. In Proceedings of the 8th ACM SIGSAC sympo-

sium on Information, computer and communications

security - ASIA CCS ’13, page 95, New York, New

York, USA. ACM Press.

IDC (2014). Worldwide Wearable Computing

Market Gains Momentum with Shipments

Reaching 19.2 Million in 2014 and Climb-

ing to Nearly 112 Million in 2018, Says

IDC. https://www.businesswire.com/news/home/

WebCrySIL-WebCryptographicServiceInteroperabilityLayer

20140410005050/en/Worldwide-Wearable-Computing-

Market-Gains-Momentum-Shipments. last visited on

March, 25th 2015.

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

architecture of the Austrian citizen card concept. 18th

Annual Computer Security Applications Conference,

2002. Proceedings.

Naehrig, M., Lauter, K., and Vaikuntanathan, V. (2011).

Can homomorphic encryption be practical? In Pro-

ceedings of the 3rd ACM workshop on Cloud comput-

ing security workshop - CCSW ’11, pages 113–124.

ACM Press.

Parliament, E. U. and Council (2000). Directive

1999/93/EC of the European Parliament and of the

Council of 13 December 1999 on a Community

framework for electronic signatures. Offcial Journal

of the European Communities, L 013:12–20.

Trusted Computing Group (2011). TCG TPM speciﬁca-

tion version 1.2 revision 116. http:// www.trusted

computinggroup.org/resources/tpm main speciﬁcation.

last visited on January 29, 2013.

van Hoboken, J. V. J., Arnbak, A., and van Eijk, N. (2012).

Cloud Computing in Higher Education and Research

Institutions and the USA Patriot Act. SSRN Electronic

Journal.

WEBIST2015-11thInternationalConferenceonWebInformationSystemsandTechnologies