Privacy-preserving Realization of the STORK Framework

in the Public Cloud

Bernd Zwattendorfer and Daniel Slamanig

Institute for Applied Information Processing and Communications (IAIK),

Graz University of Technology (TUG), Inffeldgasse 16a, 8010 Graz, Austria

Keywords:

STORK, PEPS, Public Cloud, eID, eID Federation, Privacy-preservation, Proxy Re-encryption.

Abstract:

The STORK framework – enabling secure eID federation across European countries – will be the dominant

identiﬁcation and authentication framework across Europe in the future. While still in its start up phase, adop-

tion of the STORK framework is continuously increasing and high loads can be expected, since, theoretically,

the entire population of the European Union will be able to run authentications through this framework. This

can easily lead to scalability issues, especially for the proxy-based (PEPS) approach in STORK, which relies

on a central gateway being responsible for managing and handling citizen authentications. In order to mitigate

the associated scalability issues, the PEPS approach could be moved into the public cloud. However, a move

of a trusted service into the public cloud brings up new obstacles, especially with respect to citizens’ privacy.

In this paper we propose an approach how this move could be successfully realized by still preserving citizens’

privacy and keeping existing national eID infrastructures untouched. We present the approach in detail and

evaluate its capability with respect to citizens’ privacy protection as well as its practicability. We conclude, that

the proposed approach is a viable way of realizing an efﬁcient and scalable Pan-European citizen identiﬁcation

and authentication framework.

1 INTRODUCTION

To provide secure and reliable e-Government services

to their citizens, many European countries have al-

ready rolled out secure eID solutions. While such na-

tional eID solutions have been deployed in the ﬁeld

for many years, they still have been lacking cross-

border acceptance. To overcome this lack in interop-

erability, the European Commission had launched the

large scale pilot (LSP) project STORK

(Secure Iden-

tity Across Borders Linked), which involved 18 EU

Member States. The developed STORK framework is

currently heavily pushed by the European Commis-

sion (EC) and will be the dominant identiﬁcation and

authentication framework across Europe in the future.

To achieve improved maturity and sustainability of

this framework, the successor project STORK 2.0

currently aims on further piloting.

Basically, the STORK framework is based on

two different interoperability models, the Middleware

(MW) model and the Pan-European Proxy Service

(PEPS) model. In this paper, we focus on the PEPS

https://www.eid-stork.eu

https://www.eid-stork2.eu

model only. The PEPS model sets up on a centralized

approach, where a central single gateway (PEPS) per

member state acts as intermediary (gateway) between

the service providers and the national eID framework.

This PEPS is operated in a traditional data center

within a trusted environment. However, the use of

STORK is continuously increasing and high load can

be expected in the future. This may induce scalability

problems, especially for the PEPS approach, as the-

oretically the population of an entire country can use

the PEPS for authentications.

In this paper we propose an advanced STORK

framework by moving the centralized PEPS instances

into the public cloud. Scalability problems are mit-

igated due to high elasticity and scalability provided

by the public cloud. However, other obstacles par-

ticularly regarding to the citizens’ privacy emerge.

We describe how such a move could successfully be

realized by preserving citizens’ privacy and by still

keeping the existing infrastructure nearly untouched.

We thereby assume, as it is common, that the cloud

providers are honest but curious, meaning that they

perform their computing tasks correctly, but may try

to extract as much information as possible.

419

Zwattendorfer B. and Slamanig D..

Privacy-preserving Realization of the STORK Framework in the Public Cloud.

DOI: 10.5220/0004533204190426

In Proceedings of the 10th International Conference on Security and Cryptography (SECRYPT-2013), pages 419-426

ISBN: 978-989-8565-73-0

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

2 CRYPTOGRAPHIC BUILDING

BLOCKS

In this section we brieﬂy discuss required crypto-

graphic primitives. Note, that in practice in all dis-

cussed schemes the public key pk

of a user A is

bound to the user’s identity. This is typically real-

ized by means of digital certiﬁcates within some pub-

lic key infrastructure (PKI). Thus, we assume public

keys always being publicly available in an authentic

fashion. Furthermore, if an entity A is in possession

of an encryption (PKE) and signature (DSS) key pair,

we denote them by (sk

, pk

) and (sk

′

, pk

′

) respec-

tively. Moreover, we assume that if bitstrings a and b

are concatenated akb, this happens in a way such that

all individual components are uniquely recoverable.

When we want to have authenticated encryption in

the public key setting, we typically apply the generic

sign-then-encryptstrategy, but sometimes need to rely

on the generic encrypt-then-sign strategy (An, 2001).

2.1 Digital Signatures

A digital signature scheme (DSS) is a triple (K , S , V )

of poly-time algorithms, whereas K is a probabilis-

tic key generation algorithm that takes a security pa-

rameter κ and outputs a private and public key pair

(sk, pk). The probabilistic signing algorithm S takes

as input a message M ∈ {0, 1}

∗

and a private key

sk, and outputs a signature σ. The veriﬁcation al-

gorithm V takes as input a signature σ, a message

M ∈ {0, 1}

∗

and a public key pk, and outputs a sin-

gle bit b ∈ {true, false} indicating whether σ is a

valid signature for M. Furthermore, we require the

DSS to be correct, i.e., for all (sk, pk) ∈ K (κ) and all

M ∈ {0, 1}

∗

we have V (S(M, sk), M, pk) = true. A

DSS is secure, if it is existentially unforgeable under

adaptively chosen-message attacks (UF-CMA). We

note that in practice one typically employs the hash-

then-sign paradigm, i.e., instead of inputting M into S

and V , one inputs H(M) where H is a suitable cryp-

tographic hash function.

2.2 (Public Key) Encryption

A public key encryption (PKE) scheme is a triple

(K , E, D) of poly-time algorithms, whereas K is a

probabilistic key generation algorithm that takes a se-

curity parameter κ and outputs a private and public

key pair (sk, pk). The probabilistic encryption algo-

rithm E takes as input a public key pk and a message

M ∈ {0, 1}

∗

and returns a ciphertext c = E(pk, M).

The decryption algorithm D takes as input a private

key sk and a ciphertext c and returns a message M =

D(sk, c) or ⊥ in the case of failure. We require a PKE

scheme to be indistinguishable under chosen plaintext

attacks (IND-CPA). Abstractly, we can deﬁne private

key (or symmetric) encryption schemes analogously,

whereas K only generates a single key K which is

used as input to the encryption and decryption algo-

rithms. For the security of a private key encryption

scheme we also require IND-CPA security. Note that

when we speak of applying PKE to a larger message

M, then we implicitly mean applying hybrid encryp-

tion, i.e., choosing a random K and sending/storing

the tuple (c

= E(K, pk), c

= E

′

(M, K)).

2.3 Proxy Re-encryption

An unidirectional multi-use proxy re-encryption

(UM-PRE) scheme allows a semi-trusted proxy to

transform a message encrypted under the key of party

A into another ciphertext, containing the initial plain-

text, such that another party B can decrypt the cipher-

text with its key. The proxy neither gets access to

the plaintext nor to the decryption keys. The proxy

can only transform in one direction and one cipher-

text can be transformed multiple times. Therefore,

one may either use suitable identity-based (Green and

Ateniese, 2007) or a traditional (Chow et al., 2010)

multi-use proxy re-encryption scheme. An UM-PRE

is a tuple (S , K , R K , E

, R E, D

) of poly-time al-

gorithms. The algorithm S runs a setup and pro-

duces system parameters params. K is a probabilis-

tic key generation algorithm that takes a security pa-

rameter κ and outputs a private and public key pair

(rsk

, rpk

). The re-encryption key generation algo-

rithm R K takes as input a private key rsk

and an-

other public key rpk

and outputs a re-encryption key

i→j

. The probabilistic encryption algorithm E

gets a public key rpk

and a plaintext M and outputs

= E

(rpk

, M). The (probabilistic) re-encryption

algorithm gets as input a ciphertext c

under rpk

and a

re-encryption key rk

i→j

and outputs a re-encrypted ci-

phertext c

= R E(rk

i→ j

, c

) for rpk

. The decryption

algorithm D

takes private key rsk

and a ciphertext

and outputs M = D

(rsk

, c

) or an error ⊥. Here,

we require indistinguishability under chosen cipher-

text attacks (IND-CCA).

3 THE STORK FRAMEWORK

AND PEPS MODEL

The general objective of STORK was to tackle the is-

sue of eID heterogeneity across Europe and to achieve

cross-border acceptance of eIDs. To achieve that,

STORK developed an interoperability layer on top

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

420

of the existing national solutions to avoid any severe

changes in the individual national infrastructures. By

the help of STORK, EU citizens are now able to se-

curely authenticate at foreign online applications by

using their own national eID issued by their home

country. To make the individual national eID solu-

tions comparable, STORK quantitatively modeled the

strength of the different authentication mechanisms

and quality of eID registration to STORK deﬁned

quality authentication assurance (QAA) levels.

Basically, the STORK framework sets up on two

different identity models. The ﬁrst model is called

middleware (MW), where users directly authenticate

at the service provider. The second model relies on

a proxy-based approach, where a proxy (PEPS) acts

as intermediary (gateway) between the user and the

service provider. In this paper, we focus on the PEPS

model only. Further details on both models can be

found in (Leitold and Zwattendorfer, 2010; Zwatten-

dorfer et al., 2013). The PEPS model, its setup, and

its detailed process ﬂow will be presented in the next

subsections.

3.1 PEPS Model

In this model, a proxy or gateway(PEPS) acts as inter-

mediary between the service provider and the actual

authenticating entity (identity provider). Hence, seg-

mented trust relationships apply. The PEPS basically

has three functionalities. First, the PEPS is hiding

the complexity and speciﬁcs of national eID solutions

to other countries. Thereby, the PEPS connects to

all required existing national identity providers (IdPs)

or attribute providers (APs). Second, it enables the

secure transfer of identity data to service providers.

Different service providers can connect to the PEPS

using appropriate interfaces. Third, the PEPS imple-

ments the STORK protocol (STORK, 2011b), which

is based on the Security Assertion Markup Language

(SAML)

and allows for secure cross-border identi-

ﬁcation and authentication. Figure 1 illustrates the

PEPS model in a cross-border identiﬁcation and au-

thentication scenario.

More precisely, a PEPS can either act as S-

PEPS (PEPS in the service provider’s home coun-

try) or as C-PEPS (PEPS in the citizen’s home coun-

try). The S-PEPS communicates with different ser-

vice providers and acts as intermediary between the

service providers and the C-PEPS. The C-PEPS trig-

gers identiﬁcation and authentication of a citizen at

an IdP and/or AP and thereby acts as intermediary

between an S-PEPS and the IdP and/or AP. A ba-

sic cross-border PEPS-PEPS authentication scenario

http://saml.xml.org

is illustrated in Figure 1. Subsequently, we present

details on the required setup and the process ﬂow in a

cross-border PEPS-PEPS scenario (cf. Figure 2).

Figure 1: PEPS Model.

3.1.1 Setup

Within the STORK project, a cross-border interoper-

ability protocol (STORK, 2011b) for a secure identity

and authentication data exchange had been developed.

This protocol is mainly applied in the cross-border

context, involving PEPS and MW components. In the

STORK PEPS-PEPS model, the STORK protocol is

used in the communication between an S-PEPS and a

C-PEPS and vice versa.

For setting up a STORK communication using its

protocol, appropriate metadata information has to be

exchanged between the involved STORK entities. In

particular, for the PEPS-PEPS scenario these meta-

data includes the endpoint location URL of every

PEPS (URL

S−PEPS

and URL

C−PEPS

), where messages

should be delivered to, and its signature certiﬁcate (in-

cluding the PEPS public key pk

′

S−PEPS

or pk

′

C−PEPS

The exchanged STORK messages between the indi-

vidual PEPS will be digitally signed using the corre-

sponding private signing key (sk

′

S−PEPS

or sk

′

C−PEPS

)

to ensure integrity and authenticity of the exchanged

messages. Currently, PEPS metadata exchange is

handled by the individual countries using various or-

ganizational means. However, the STORK 2.0 con-

sortium together with the European Commission are

currently in the progress of setting up an appropriate

governance structure for managing these metadata,

where a European Commission body will be responsi-

ble for PEPS metadata management and maintenance.

Basically, to accomplish a PEPS-PEPS authen-

tication scenario, the following setup is required.

Every PEPS country generates an individual DSS

key pair for their PEPS, (sk

′

S−PEPS

, pk

′

S−PEPS

)

and (sk

′

C−PEPS

, pk

′

C−PEPS

) respectively. Both

Privacy-preservingRealizationoftheSTORKFrameworkinthePublicCloud

421

Figure 2: The PEPS-PEPS Process Flow.

′

S−PEPS

and pk

′

C−PEPS

as well as URL

S−PEPS

and

URL

C−PEPS

are published. Additionally, each service

provider SP

relying on PEPS authentication creates a

DSS key pair (sk

′

, pk

′

) to sign its messages. Of

course, a setup procedure of the IdP is necessary too.

However, we consider this procedure country-speciﬁc

and hence do not present any details.

Since, instead of the SP, the individual PEPS as

trusted intermediaries are liable for any fraudulent ac-

tivity, each PEPS is responsible to log certain authen-

tication and transaction information in case a later au-

dit or inspection is required. These log data include

information on the sender for incoming messages, on

the receiver for outgoing messages, a message iden-

tiﬁer, date/time of the message, a hash value of the

message (using SHA-256), and a log entry counter

(STORK, 2011a).

3.1.2 Process Flow

The detailed cross-border PEPS-PEPS process ﬂow

as illustrated in Figure 2 will be the basis to dis-

cuss our cloud-based PEPS-PEPS approach. For the

sake of simplicity, we denote the particular entities

S − PEPS

, C − PEPS

, SP

and IdP

in the process

ﬂow simply by SP, S− PEPS, etc.

1) Access Protected Resource. A citizen (user) orig-

inating from country B wants to access a protected

(e-Government) service in the foreign country A.

2) SP Authentication Request. The SP has no secu-

rity context established with the user yet and thus

requires authentication at a speciﬁc strength reqQAA.

Furthermore, speciﬁc citizen attributes reqAttr

are required in order to provide the requested

service to the user. The authentication request of

the SP including reqAttr, reqQAA, and the name

of the SP sp_name is signed by the SP resulting

in σ

= S(sk

′

, reqAttrkreqQAAksp_name),

and the tuple (reqAttr, reqQAA, sp_name, σ

) is

forwarded via the user to the S-PEPS. The protocol

for transmitting the SP authentication request can be

nation-speciﬁc.

3) Select home Country. The S-PEPS veriﬁes σ

and

if valid, the S-PEPS provides the citizen a country

selection page.

4) Provide Home Country Information. The citizen

selects her country of origin and submits the infor-

mation country (B) back to the S-PEPS.

5) S-PEPS Authentication Request. The S-PEPS

takes the information received from the SP

(reqAttr, reqQAA, sp_name) and signs it using

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

422

its private key sk

′

S−PEPS

resulting in σ

S−PEPS

S(sk

′

S−PEPS

, reqAttrkreqQAAksp_name). De-

pending on country, the S-PEPS forwards

its authentication request including the data

(reqAttr, reqQAA, sp_name,σ

S−PEPS

) to the C-

PEPS, which is responsible for authentications of

country, i.e., C− PEPS of country B.

6) Show Requested Attributes. The C-PEPS veriﬁes

S−PEPS

and sends reqAttr and sp_name for

attribute selection to the citizen.

7) Conﬁrm/Deselect Requested Attributes. According

to STORK, citizens must conﬁrm the reception of

reqAttr from the IdP. Thereby, citizens can deselect

attributes for denying further transmission of those

attributes to the SP, whereas only attributes which

have been requested as being optional by the SP can

be deselected.

8) Connect to Appropriate IdP. The implementation

of this step and the subsequent steps 9 and 10 are

country speciﬁc. Depending on reqQAA, the appro-

priate IdP for citizen identiﬁcation and authentication

is contacted. The C-PEPS forwards the requested

attributes reqAttr to the IdP.

9) Authenticate. Depending on the IdP, the citizen

authenticates using the respective authentication

method. For the highest authentication level reqQAA,

the citizen must authenticate using her ofﬁcial na-

tional eID.

10) Return Identity and Authentication Data. The IdP

returns citizen’s identity and attribute information

attr, which include the attribute values correspond-

ing to reqAttr, to the C-PEPS. Additionally, QAA

stating the actual level of the authentication process

is returned.

11) Get Consent. The C-PEPS sends attr and

sp_name to the citizen to get consent for further

transmission of attr to the C-PEPS and then subse-

quently to SP.

12) Give Consent. The citizen may give or deny

consent for attr transmission.

13) C-PEPS Authentication Response. The C-

PEPS takes attr and QAA, signs it generating

C−PEPS

= S(sk

′

C−PEPS

, attrk QAA), and transfers

(attr, QAA,σ

C−PEPS

) to the S-PEPS.

14) S-PEPS Authentication Response. The S-PEPS

veriﬁes σ

C−PEPS

, signs again attr and QAA resulting

in σ

′

S−PEPS

= S (sk

′

S−PEPS

, attrk QAA), and transfers

Note, that depending on the country and its implemen-

tation, Steps 6 and 7 as well as Steps 10 and 11 can also be

included in Step 9.

(attr, QAA,σ

S−PEPS

) to the SP.

15) Grant Access. The SP veriﬁes σ

S−PEPS

and

checks if the citizen has been authenticated with the

requested reqQAA. Based on the attributes attr

received, the SP either grants or denies access to the

requested service to the citizen.

4 PORTING THE PEPS MODEL

INTO THE PUBLIC CLOUD

The current PEPS Model relies on a central PEPS in-

stance, which is operated for every single country in

a trusted conventional data center. Since STORK will

be the dominant authentication framework across Eu-

rope in the future, quite a large number of authenti-

cations running through the PEPS are to be expected.

This, however,can lead to scalability issues at the data

center, especially when imaging that the population

of an entire country is able to use this PEPS. Con-

sequently, a move of the trusted PEPS service into

the public cloud will considerably improve scalabil-

ity. Nevertheless, a move of a trusted service into the

public cloud clearly brings up new obstacles, espe-

cially with respect to citizens’ privacy. Even when

assuming that the PEPS in the public cloud works cor-

rectly, it still has to be assured that the cloud provider

does neither learn nor leak any sensitive informa-

tion. In the following, we propose a solution how

the PEPS model can be securely realized in the public

cloud by still preserving citizens’ privacy. We thereby

moveboth the S-PEPS and the C-PEPS into the public

cloud.

4.1 Setup

For the setup of this cloud-based PEPS-PEPS sce-

nario, similar to the current situation, we consider a

trusted European Commission body to be responsible

for managing and maintaining the PEPS metadata. In

particular, the following metadata for accomplishing

this cloud approach are required:

The European Commission body EC

generates a UM-PRE and DSS key pair

for every countries’ S-PEPS and C-PEPS,

resulting in (rsk

S−PEPS

, rpk

S−PEPS

) and

(sk

′

S−PEPS

, pk

′

S−PEPS

), and (rsk

C−PEPS

, rpk

C−PEPS

)

and (sk

′

C−PEPS

, pk

′

C−PEPS

) respectively. The EC,

however, must ensure that the secret keys rsk

S−PEPS

and rsk

C−PEPS

are kept secret by the EC and

cannot be accessed by S − PEPS

or C − PEPS

Additionally, it provides every SP

and IdP

tak-

ing part in this cloud-based STORK architecture

Privacy-preservingRealizationoftheSTORKFrameworkinthePublicCloud

423

with appropriate UM-PRE keys: (rsk

, rpk

)

and (rsk

IdP

, rpk

IdP

). Also the following re-

encryption keys rk

S−PEPS

→C−PEPS

, rk

C−PEPS

→IdP

C−PEPS

→S−PEPS

, rk

S−PEPS

→SP

are generated.

The DSS key pairs ensuring integrity and authenticity

of outgoing messages from either SP

or IdP

are

created by the individual entities themselves, result-

ing in the key pairs (sk

′

, pk

′

) and (sk

′

IdP

, pk

′

IdP

where the corresponding certiﬁcates must be publicly

available.

To support the same logging and audit capabil-

ity as in the current approach, EC additionally gen-

erates re-encryption keys for itself rk

S−PEPS

→EC

and

C−PEPS

→EC

. During the authentication process, the

individual S − PEPS

and C − PEPS

log the same

data as in the current approach, but in encrypted form

using either key rk

S−PEPS

→EC

or rk

C−PEPS

→EC

. This

allows the EC to inspect or audit transaction data if

required.

4.2 Process Flow

In the following we discuss the detailed process

ﬂow when moving the individual PEPS instances

into the public cloud. Again, we use a simpliﬁed

notation for the individual entities (SP instead of SP

etc.) to describe the process ﬂow of one particular

authentication. The individual process steps are

basically conform to the current PEPS-PEPS process

ﬂow. However, we generally assume that "attribute

selection" (Steps 6 and 7 in Figure 2) and "giving

consent" (Steps 11 and 12 in Figure 2) are carried

out by the IdP for reasons that will be explained in

Section 5.2.

1) Access Protected Resource. Same as in current

situation.

2) SP Authentication Request. This step is

similar to the current situation. However, in-

stead of including the data reqAttr, reqQAA,

and sp_name in plain in the SP authenti-

cation request, the SP computes c

S−PEPS

(rpk

S−PEPS

, reqAttrkreqQAAksp_name)

and signs this ciphertext resulting in σ

S(sk

′

, c

S−PEPS

). Both the signature σ

and

the ciphertext c

S−PEPS

are transmitted to the S-PEPS.

3) Select Home Country. Same as in current situation.

4) Provide Home Country Information. Same as in

current situation.

5) S-PEPS Authentication Request. The S-PEPS

takes the ciphertext c

S−PEPS

received from the

SP, re-encrypts it for the C-PEPS using key

S−PEPS→C−PEPS

resulting in c

C−PEPS

, and ﬁnally

signs it using its private key sk

′

S−PEPS

resulting in

S−PEPS

= S(sk

′

S−PEPS

, c

C−PEPS

). Depending on

country, the S-PEPS forwards its authentication

request including the data (σ

S−PEPS

, c

C−PEPS

) to the

C-PEPS, which is responsible for authentications of

country.

6) Show Requested Attributes. The C-PEPS veriﬁes

S−PEPS

. Additionally, the C-PEPS re-encrypts

C−PEPS

for the IdP using rk

C−PEPS→IdP

and signs the

resulting ciphertext c

IdP

using key sk

′

C−PEPS

. Both

results (c

IdP

, σ

C−PEPS

) are transmitted to the IdP. The

IdP veriﬁes σ

C−PEPS

, decrypts c

IdP

, and presents the

citizen reqAttr and sp_name.

7) Conﬁrm/Deselect Requested Attributes. Similar to

the current situation. Instead of the C-PEPS, the IdP

carries out this process step.

8) Connect to Appropriate IdP. This step is now

included in step 6.

9) Authenticate. Same as in current situation.

10) Return Identity and Authentication Data. This

step is now included in step 12.

11) Get Consent. Instead of the C-PEPS, the IdP

sends attr to the citizen to get consent for further

transmission to the C-PEPS and SP subsequently.

12) Give Consent. Same as in current situa-

tion. Additionally, the IdP encrypts attr and

QAA for the C-PEPS resulting in c

′

C−PEPS

(rpk

C−PEPS

, attrk QAA). Subsequently, the

IdP generates the signature σ

IdP

= S (sk

′

IdP

, c

′

C−PEPS

)

and transfers (σ

IdP

, c

′

C−PEPS

) to the C-PEPS.

13) C-PEPS Authentication Response. This step is

similar to the current situation. However, in this

cloud-based approach, the C-PEPS veriﬁes σ

IdP

re-encrypts c

′

C−PEPS

for the S-PEPS resulting in

′

S−PEPS

= E

(rk

C−PEPS→S−PEPS

, c

′

C−PEPS

), and

signs c

′

S−PEPS

using key sk

′

C−PEPS

. The signature

denoted as σ

′

C−PEPS

and the Ciphertext c

′

S−PEPS

are

transmitted to the S-PEPS.

14) S-PEPS Authentication Response. The S-PEPS

veriﬁes σ

′

C−PEPS

and re-encrypts c

′

S−PEPS

for the

SP using key rk

S−PEPS→SP

. Finally, the S-PEPS

signs the resulting ciphertext c

using key sk

′

S−PEPS

(σ

′

S−PEPS

, c

) are transmitted to the SP.

15) Grant Access. The SP veriﬁes σ

′

S−PEPS

and

decrypts c

to extract attr and QAA. The SP checks

the QAA the citizen has been authenticated with and

based on the attributes attr received, the SP either

grants or denies access to the requested service to the

citizen.

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

424

Using PKE instead of UM-PRE. Although in

the presented approach the key management using

UM-PRE is less complex than using PKE, the use

of UM-PRE may require stronger trust assumptions.

Particularly, a strong trust must be put on the indi-

vidual SP

as in case of a fraudulent cooperation of

one single SP

with any S − PEPS

may break the

UM-PRE infrastructure and allow the S − PEPS

channel off or disclose any data (attrkQAA of the

individual citizen) processed by or ﬂowing through

S − PEPS

. This issue is particular risky in a cloud

environment, as the individual entities are easier to

access via the Internet as in a trusted environment

and consequently the attack surface is larger.

In order to reduce this risk, we propose an al-

ternative based on conventional PKE. In this setting,

the individual SP

additional generate a one-time use

PKE key pair (sk

, pk

). According to the pro-

posed process ﬂow, the public key pk

is included

in the encrypted SP authentication request sent to

the S-PEPS in Step 2. The key is further forwarded

to the C-PEPS and IdP in Step 5. After success-

ful citizen authentication, in Step 12, the IdP en-

crypts attr and qaa for the SP resulting in c

′

E(pk

, attrk qaa). Additionally, c

′

C−PEPS

now in-

cludes the result of E

(rpk

C−PEPS

, c

′

) instead of

(rpk

C−PEPS

, attrk QAA). For the subsequent Steps

13 and 14 also c

′

instead of attrkqaa is used for

re-encryption. In Step 14, the SP now takes sk

decrypt c

′

and to extract attrkQAA to be used for

the authentication decision in Step 15.

The advantage of this alternative is that in case of

a fraudulent cooperation between SP

and S− PEPS

only disclosure of c

′

instead of attrkQAA is possi-

ble, which does not leak any sensitive information. In

addition, by using a one-time use PKE key pair no

further registration or complex setup is required.

5 EVALUATION

In this section we evaluate our proposed cloud-based

PEPS-PEPS approach ﬁrstly with respect to privacy

and security aspects, and, secondly, with respect to

operational and practicability issues.

5.1 Security and Privacy Discussion

As already noted, we assume cloud providers are act-

ing honest but curious and we are interested which

personal and thus sensitive information, e.g., attr,

We are aware that this risk also relates to the connection

C − PEPS

and IdP

. However, we consider an IdP

acting

trustworthier than an SP

are disclosed to an S-PEPS or C-PEPS operated in the

public cloud. Table 1 compares the information seen

by the individual entities (SP, S-PEPS, C-PEPS, IdP)

in the current PEPS-PEPS scenario with the cloud-

based scenario.

Note that the SP, in both approaches, clearly ob-

tains all citizen information, since they are required

for successfully providing its services.

The S-PEPS, acting as ﬁrst gateway, also sees all

citizen information in the current approach. Addi-

tionally, it gains knowledge on the country the citizen

originates from. In contrast, the originating country

remains the only information visible to the S-PEPS

in the cloud-based approach. All other information is

only available in encrypted form. With just the infor-

mation of the country of origin, the S-PEPS is not able

to determine the identity of any authenticating citizen.

For the current approach, also the C-PEPS sees

all citizen information. Adopting our cloud-based ap-

proach, the C-PEPS is able to inspect processed data

in encrypted form only, which does not allow for any

personal data disclosure.

Finally, the IdP is considered to be trusted in the

current and the cloud-based approach. The IdP gets

knowledge on reqAttr, reqQAA, sp_name, attr,

and QAA. Compared to the current approach, in the

cloud-based approach the IdP gets to know which par-

ticular SP the information is provided to.

5.2 Practicability Discussion

In this section we discuss our proposed cloud ap-

proach based on selected criteria relating to practica-

bility.

Re-use of Existing Infrastructure. One criterion we

focused on when having designed our cloud approach

was to keep as much as of the existing infrastructure

unaltered or unchanged. In general, main parts of the

existing infrastructure can be kept untouched. This

is particular important for the individual countries’

eID infrastructures, as no new eID solution needs

to be rolled out, which follows the general objective

of STORK. The remaining entities (SP, S-PEPS, C-

PEPS, IdP) need to be adapted to support UM-PRE.

The STORK protocol does not necessarily need to be

extended as SAML already supports the transfer of

encrypted attributes and messages out of the box.

Conformance to Current Process Flow. When de-

signing our cloud-based approach, we took care on

staying conform with the current process ﬂow. Ba-

sically, for supporting the cloud approach no se-

vere changes in the communication and authentica-

tion process ﬂow are necessary. However, Step 7

Privacy-preservingRealizationoftheSTORKFrameworkinthePublicCloud

425

Table 1: Comparison of personal data disclosure between the current and the cloud-based PEPS-PEPS approach.

Approach / Entitity SP S-PEPS C-PEPS IdP

Current reqAttr, reqQAA,

sp_name, attr, QAA

reqAttr, reqQAA,

sp_name, attr, QAA,

country

reqAttr, reqQAA,

sp_name, attr, QAA

reqAttr, reqQAA,

sp_name, attr, QAA

Cloud reqAttr, reqQAA,

sp_name, attr, QAA

country × reqAttr, reqQAA,

sp_name, attr, QAA

(Conﬁrm/deselect requested attributes) and Steps 11

and 12 (Get consent and Give consent) must be car-

ried out at the IdP when operating the C-PEPS in a

public cloud. The reason is that otherwise the C-PEPS

could present the citizen a list of different attributes

than actually requested from the IdP. In this case, the

C-PEPS could provide the SP with more citizen infor-

mation than actually required.

Scalability. The main objective of our work was to

design a scalable PEPS-PEPS scenario as increased

and high usage of STORK can be expected in the fu-

ture. This objective is mainly realized by moving im-

portant components, where high load can be expected,

such as the S-PEPS and the C-PEPS, into the public

cloud. Load bottlenecks at the SP or IdP are rather

unlikely, because not all citizens are going to use the

same SP or IdP at the same time.

Governance Structure. The governance structure

of the STORK framework is currently in its detailed

setup process. Thereby, a European Commission

body will manage and maintain the individual PEPS

metadata. This metadata includes the URLs and

the individual signature certiﬁcates of the countries’

PEPS. For supporting our cloud-based approach, this

governance structure needs to be extended. In particu-

lar, the European Commission body additionally will

be responsible for managing and issuing appropriate

encryption keys based on a public key infrastructure

(PKI) to the individual PEPS. However, the effort for

these tasks can be kept within reasonable limits as we

consider in the cloud approach to have one single S-

PEPS and C-PEPS per country only.

6 CONCLUSIONS

The STORK framework – allowing secure citizen

identiﬁcation and authentication across borders – will

play a major role across Europe in the future. Cur-

rently, STORK is in its start up phase, but continu-

ously increasing usage can be expected. However,

increased usage can easily lead to scalability issues,

especially in the centralized PEPS approach, as theo-

retically the entire population of a country will be able

to use and run authentications through a countries’

PEPS. To overcome such scalability bottlenecks, in

this paper we presented a solution by moving central-

ized country PEPS into a public cloud, which con-

siderably improves scalability. We further evaluated

this solution with respect to citizens’ privacy preser-

vation and practicability issues. We ﬁnally conclude

that in terms of privacy, no identifying citizen infor-

mation will be disclosed to a PEPS in the public cloud

when applying the proposed approach. Additionally,

existing national eID infrastructures can be kept un-

touched and no major changes to the current authen-

tication process ﬂow are required. Finally, our pro-

posed solution perfectly ﬁts into the STORK gover-

nance structure, which is currently being established.

ACKNOWLEDGEMENTS

We thank the anonymous reviewers for their valuable

feedback. The second author has been partly sup-

ported by the European Commission through project

FP7-FutureID, grant agreement number 318424.

REFERENCES

An, J. H. (2001). Authenticated Encryption in the Public-

Key Setting: Security Notions and Analyses. IACR

Cryptology ePrint Archive, 2001:79.

Chow, S. S. M., Weng, J., Yang, Y., and Deng, R. H.

(2010). Efﬁcient Unidirectional Proxy Re-Encryption.

In AFRICACRYPT, pages 316–332.

Green, M. and Ateniese, G. (2007). Identity-Based Proxy

Re-encryption. In ACNS, pages 288–306.

Leitold, H. and Zwattendorfer, B. (2010). STORK: Archi-

tecture, Implementation and Pilots. In ISSE, pages

131–142.

STORK (2011a). STORK D5.7.3 Functional Design for

PEPS, MW models and interoperability.

STORK (2011b). STORK D5.8.3b Interface Speciﬁcation.

Zwattendorfer, B., Sumelong, I., and Leitold, H. (2013).

Middleware Architecture for Cross-Border Identiﬁca-

tion and Authentication. JIAS, 8(2):107–118.

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

426