![](bg7.png)
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
′
C−PEPS
now in-
cludes the result of E
R
(rpk
C−PEPS
, c
′
SP
) instead of
E
R
(rpk
C−PEPS
, 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-preservingRealizationoftheSTORKFrameworkinthePublicCloud
425