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
identification 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 efficient and scalable Pan-European citizen identification
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 field
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
1
(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 identification and
authentication framework across Europe in the future.
To achieve improved maturity and sustainability of
this framework, the successor project STORK 2.0
2
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
1
https://www.eid-stork.eu
2
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
Copyright
c
2013 SCITEPRESS (Science and Technology Publications, Lda.)
2 CRYPTOGRAPHIC BUILDING
BLOCKS
In this section we briefly discuss required crypto-
graphic primitives. Note, that in practice in all dis-
cussed schemes the public key pk
A
of a user A is
bound to the user’s identity. This is typically real-
ized by means of digital certificates 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
A
, pk
A
) and (sk
A
, pk
A
) 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 verification 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 define 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
1
= E(K, pk), c
2
= 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
, R E, D
R
) 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
i
, rpk
i
). The re-encryption key generation algo-
rithm R K takes as input a private key rsk
i
and an-
other public key rpk
j
and outputs a re-encryption key
rk
ij
. The probabilistic encryption algorithm E
R
gets a public key rpk
i
and a plaintext M and outputs
c
i
= E
R
(rpk
i
, M). The (probabilistic) re-encryption
algorithm gets as input a ciphertext c
i
under rpk
i
and a
re-encryption key rk
ij
and outputs a re-encrypted ci-
phertext c
j
= R E(rk
i j
, c
i
) for rpk
j
. The decryption
algorithm D
R
takes private key rsk
j
and a ciphertext
c
j
and outputs M = D
R
(rsk
j
, c
j
) 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 defined
quality authentication assurance (QAA) levels.
Basically, the STORK framework sets up on two
different identity models. The first 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 flow 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 specifics 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)
3
and allows for secure cross-border identi-
fication and authentication. Figure 1 illustrates the
PEPS model in a cross-border identification 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 identification 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
3
http://saml.xml.org
is illustrated in Figure 1. Subsequently, we present
details on the required setup and the process flow 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
SPEPS
and URL
CPEPS
), where messages
should be delivered to, and its signature certificate (in-
cluding the PEPS public key pk
SPEPS
or pk
CPEPS
).
The exchanged STORK messages between the indi-
vidual PEPS will be digitally signed using the corre-
sponding private signing key (sk
SPEPS
or sk
CPEPS
)
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
SPEPS
i
, pk
SPEPS
i
)
and (sk
CPEPS
i
, pk
CPEPS
i
) respectively. Both
Privacy-preservingRealizationoftheSTORKFrameworkinthePublicCloud
421
Figure 2: The PEPS-PEPS Process Flow.
pk
SPEPS
i
and pk
CPEPS
i
as well as URL
SPEPS
i
and
URL
CPEPS
i
are published. Additionally, each service
provider SP
j
relying on PEPS authentication creates a
DSS key pair (sk
SP
j
, pk
SP
j
) to sign its messages. Of
course, a setup procedure of the IdP is necessary too.
However, we consider this procedure country-specific
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-
tifier, 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 flow
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
i
, C PEPS
i
, SP
j
and IdP
k
in the process
flow 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 specific strength reqQAA.
Furthermore, specific 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 σ
SP
= S(sk
SP
, reqAttrkreqQAAksp_name),
and the tuple (reqAttr, reqQAA, sp_name, σ
SP
) is
forwarded via the user to the S-PEPS. The protocol
for transmitting the SP authentication request can be
nation-specific.
3) Select home Country. The S-PEPS verifies σ
SP
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
SPEPS
resulting in σ
SPEPS
=
S(sk
SPEPS
, reqAttrkreqQAAksp_name). De-
pending on country, the S-PEPS forwards
its authentication request including the data
(reqAttr, reqQAA, sp_name,σ
SPEPS
) 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 verifies
σ
SPEPS
and sends reqAttr and sp_name for
attribute selection to the citizen.
7) Confirm/Deselect Requested Attributes. According
to STORK, citizens must confirm 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 specific. Depending on reqQAA, the appro-
priate IdP for citizen identification 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 official 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.
4
13) C-PEPS Authentication Response. The C-
PEPS takes attr and QAA, signs it generating
σ
CPEPS
= S(sk
CPEPS
, attrk QAA), and transfers
(attr, QAA,σ
CPEPS
) to the S-PEPS.
14) S-PEPS Authentication Response. The S-PEPS
verifies σ
CPEPS
, signs again attr and QAA resulting
in σ
SPEPS
= S (sk
SPEPS
, attrk QAA), and transfers
4
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,σ
SPEPS
) to the SP.
15) Grant Access. The SP verifies σ
SPEPS
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
SPEPS
i
, rpk
SPEPS
i
) and
(sk
SPEPS
i
, pk
SPEPS
i
), and (rsk
CPEPS
i
, rpk
CPEPS
i
)
and (sk
CPEPS
i
, pk
CPEPS
i
) respectively. The EC,
however, must ensure that the secret keys rsk
SPEPS
i
and rsk
CPEPS
i
are kept secret by the EC and
cannot be accessed by S PEPS
i
or C PEPS
i
.
Additionally, it provides every SP
j
and IdP
k
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
SP
j
, rpk
SP
j
)
and (rsk
IdP
k
, rpk
IdP
k
). Also the following re-
encryption keys rk
SPEPS
i
CPEPS
i
, rk
CPEPS
i
IdP
k
,
rk
CPEPS
i
SPEPS
i
, rk
SPEPS
i
SP
j
are generated.
The DSS key pairs ensuring integrity and authenticity
of outgoing messages from either SP
j
or IdP
k
are
created by the individual entities themselves, result-
ing in the key pairs (sk
SP
j
, pk
SP
j
) and (sk
IdP
k
, pk
IdP
k
),
where the corresponding certificates 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
SPEPS
i
EC
and
rk
CPEPS
i
EC
. During the authentication process, the
individual S PEPS
i
and C PEPS
i
log the same
data as in the current approach, but in encrypted form
using either key rk
SPEPS
i
EC
or rk
CPEPS
i
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
flow when moving the individual PEPS instances
into the public cloud. Again, we use a simplified
notation for the individual entities (SP instead of SP
j
,
etc.) to describe the process flow of one particular
authentication. The individual process steps are
basically conform to the current PEPS-PEPS process
flow. 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
SPEPS
=
E
R
(rpk
SPEPS
, reqAttrkreqQAAksp_name)
and signs this ciphertext resulting in σ
SP
=
S(sk
SP
, c
SPEPS
). Both the signature σ
SP
and
the ciphertext c
SPEPS
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
SPEPS
received from the
SP, re-encrypts it for the C-PEPS using key
rk
SPEPSCPEPS
resulting in c
CPEPS
, and finally
signs it using its private key sk
SPEPS
resulting in
σ
SPEPS
= S(sk
SPEPS
, c
CPEPS
). Depending on
country, the S-PEPS forwards its authentication
request including the data (σ
SPEPS
, c
CPEPS
) to the
C-PEPS, which is responsible for authentications of
country.
6) Show Requested Attributes. The C-PEPS verifies
σ
SPEPS
. Additionally, the C-PEPS re-encrypts
c
CPEPS
for the IdP using rk
CPEPSIdP
and signs the
resulting ciphertext c
IdP
using key sk
CPEPS
. Both
results (c
IdP
, σ
CPEPS
) are transmitted to the IdP. The
IdP verifies σ
CPEPS
, decrypts c
IdP
, and presents the
citizen reqAttr and sp_name.
7) Confirm/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
CPEPS
=
E
R
(rpk
CPEPS
, attrk QAA). Subsequently, the
IdP generates the signature σ
IdP
= S (sk
IdP
, c
CPEPS
)
and transfers (σ
IdP
, c
CPEPS
) 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 verifies σ
IdP
,
re-encrypts c
CPEPS
for the S-PEPS resulting in
c
SPEPS
= E
R
(rk
CPEPSSPEPS
, c
CPEPS
), and
signs c
SPEPS
using key sk
CPEPS
. The signature
denoted as σ
CPEPS
and the Ciphertext c
SPEPS
are
transmitted to the S-PEPS.
14) S-PEPS Authentication Response. The S-PEPS
verifies σ
CPEPS
and re-encrypts c
SPEPS
for the
SP using key rk
SPEPSSP
. Finally, the S-PEPS
signs the resulting ciphertext c
SP
using key sk
SPEPS
.
(σ
SPEPS
, c
SP
) are transmitted to the SP.
15) Grant Access. The SP verifies σ
SPEPS
and
decrypts c
SP
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
i
as in case of a fraudulent cooperation of
one single SP
i
with any S PEPS
i
may break the
UM-PRE infrastructure and allow the S PEPS
i
to
channel off or disclose any data (attrkQAA of the
individual citizen) processed by or flowing through
S PEPS
i
5
. 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
i
additional generate a one-time use
PKE key pair (sk
SP
i
, pk
SP
i
). According to the pro-
posed process flow, the public key pk
SP
i
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
SP
=
E(pk
SP
, attrk qaa). Additionally, c
CPEPS
now in-
cludes the result of E
R
(rpk
CPEPS
, c
SP
) instead of
E
R
(rpk
CPEPS
, attrk QAA). For the subsequent Steps
13 and 14 also c
SP
instead of attrkqaa is used for
re-encryption. In Step 14, the SP now takes sk
SP
to
decrypt c
SP
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
i
and S PEPS
i
only disclosure of c
SP
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 firstly 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,
5
We are aware that this risk also relates to the connection
C PEPS
i
and IdP
i
. However, we consider an IdP
i
acting
trustworthier than an SP
i
.
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 first 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 flow. Ba-
sically, for supporting the cloud approach no se-
vere changes in the communication and authentica-
tion process flow 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
(Confirm/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 certificates 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
identification 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 finally 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 flow are required. Finally, our pro-
posed solution perfectly fits 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). Efficient 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 Specification.
Zwattendorfer, B., Sumelong, I., and Leitold, H. (2013).
Middleware Architecture for Cross-Border Identifica-
tion and Authentication. JIAS, 8(2):107–118.
SECRYPT2013-InternationalConferenceonSecurityandCryptography
426