c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3

Available online at www.sciencedirect.com

ScienceDirect

journal homepage: www.elsevier.com/locate/cose

Design strategies for a privacy-friendly

Austrian eID system in the public cloud*

Bernd Zwattendorfer*, Daniel Slamanig

Institute for Applied Information Processing and Communications (IAIK), Graz University of Technology (TUG),
Inffeldgasse 16a, 8010 Graz, Austria

article info abstract

Article history: Secure identification and authentication are essential processes in sensitive areas of
Received 10 November 2014 application such as e-Government or e-Health. In Austria, the official eID is the so called
Received in revised form the Austrian citizen card and a means of choice for secure citizen identification and
20 February 2015 authentication. To facilitate the adoption of citizen card authentication at service providers
Accepted 9 March 2015 within the Austrian e-Government strategy, the open source module MOA-ID has been
Available online 20 March 2015 developed. It acts as identity provider for different service providers and manages identi-
fication and authentication based on the Austrian citizen card. Currently, MOA-ID is
Keywords: deployed locally in every service provider's domain and is assumed to be fully trusted. With
Identity management the increasing use of eIDs, however, a move into a public cloud might be advantageous due
Cloud computing to benefits provided cloud computing, e.g., cost savings or scalability. Nevertheless, the
Electronic identity (eID) move of a trusted service into the public cloud brings up new obstacles, in particular with
Privacy respect to security and privacy. Therefore, in this paper we introduce and evaluate three
Cryptography different approaches on how the Austrian eID system based on MOA-ID could be securely
Identification moved into the cloud without violating any privacy or data protection aspects. To achieve
Authentication this, we rely on various cryptographic methods and focus on minimum changes of the
Austrian citizen card current identification and authentication process flow. Based on an evaluation of these
three different approaches, we propose a model which can be generically used for eID
identification and authentication in privacy-invasive environments such as the public
cloud.
© 2015 Elsevier Ltd. All rights reserved.

2008) as national law. Secure authentication and unique

1. Introduction
The Austrian eID system constitutes one major building block
within the Austrian e-Government strategy, which is laid
down in the Austrian e-Government Act (Federal Chancellery,
identification of Austrian citizens e by still preserving citizens'
privacy e are the main functions of the Austrian eID system.
The basic building block for secure authentication and unique
identification in the Austrian eID system is the Austrian citi-
zen card (Leitold et al., 2002), the official eID in Austria.

*
A preliminary version of this paper appeared under the title “On Privacy-Preserving Ways to Porting the Austrian eID System to the
Public Cloud” in Proc. of SEC 2013, Auckland, New Zealand, July 2013 (Zwattendorfer and Slamanig, 2013a).
* Corresponding author.
E-mail address: bernd.zwattendorfer@iaik.tugraz.at (B. Zwattendorfer).
http://dx.doi.org/10.1016/j.cose.2015.03.002
0167-4048/© 2015 Elsevier Ltd. All rights reserved.
 c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3
To facilitate the adoption of this eID concept at online
applications, the open source module MOA-ID has been
developed. Basically, MOA-ID manages the identification and
authentication process based on the Austrian citizen card
for service providers. Currently, the Austrian eID concept
treats MOA-ID as a trusted entity, which is deployed locally
in every service provider's domain. While this model has
indeed some benefits, in some situations a centralized
deployment approach of MOA-ID may be preferable. For
instance, a centralized MOA-ID can save service providers a
lot of operational and maintenance costs. However, in terms
of scalability e theoretically the whole Austrian population
could use this central service for identification and authen-
tication at service providers e the existing approach is
advantageous.
To bypass the issue of scalability, in this paper, we propose
a centralized deployment approach of MOA-ID in the public
cloud. The public cloud is able to provide nearly unlimited
computing resources and hence the scalability problem can
easily be compensated. However, the move of a trusted ser-
vice into the public cloud brings up new obstacles. In partic-
ular, MOA-ID, since now running in the public cloud, can no
longer be considered a fully trusted entity. We encounter
these obstacles by introducing three different approaches
relying on different cryptographic mechanisms, each
describing how the current Austrian eID system can be
securely migrated into the public cloud. All approaches retain
the workflow of the current Austrian eID system and preserve
citizens' privacy when assuming that MOA-ID acts honest but
curious, i.e., operates correctly but is not trusted with respect
to (data) privacy. Our first approach relies on the use of proxy
re-encryption and redactable signatures, the second is based
upon anonymous credentials, and the third one sets up on
fully homomorphic encryption. Based on an evaluation of
these three different approaches, we propose a model which
can be generically used for eID identification and authenti-
cation in privacy-invasive environments such as the public
cloud.
Our paper is structured as follows. In Section 2 we briefly
introduce the current Austrian eID system and the architec-
ture using MOA-ID for identification and authentication at
online services. In Section 3 we present the cryptographic
building blocks that are underlying our approaches. Subse-
quently, our approaches are discussed in detail in Section 4. In
Section 5 we thoroughly evaluate the proposed approaches
based on selected criteria. Based on the results of the evalu-
ation we propose a generic model in Section 6, which is called
Privacy-Preserving Identity as a Service-Model for eIDs. Related
work is discussed in Section 7. Finally, we draw conclusions in
Section 8.
2. The current Austrian eID system
In the following subsections we discuss the basic ideas of the
Austrian eID concept by presenting involved components and
processes.
179
2.1. The Austrian citizen card concept
Unique identification and secure authentication are essen-
tial processes in e-Government. In particular, unique iden-
tification is essential when a large amount of users comes
into play, such as the population of a whole country. In
such a huge population, identification of citizens based on
first name, last name, and date of birth may be ambiguous.
To mitigate this problem, each Austrian citizen is registered
in a central register and is assigned a unique identification
number. Furthermore, another unique identifier is
computed from this number and stored on each citizen
card. This so-called sourcePIN is created by a trusted entity,
the so-called SourcePIN Register Authority (SRA), and can be
used for unique citizen identification at online applications.
However, the sourcePIN requires special protection as it is
forbidden by law to permanently store the sourcePIN outside
the citizen card. Therefore, the Austrian eID concept uses a
sector-specific model for identification at online applica-
tions. In this sector-specific model, the sourcePIN is used to
derive unique sector-specific identifiers, so called sector-
specific PINs (ssPINs) for every different governmental
sector, e.g., tax, finance, etc. Thereby, citizens' privacy is
assured as the sourcePIN cannot be derived from a given
ssPIN and different ssPIN s of one citizen cannot be linked
together.
The key element of the Austrian eID concept constitutes
the Austrian citizen card (Leitold et al., 2002), which is basi-
cally an abstract definition of a secure eID token possessed by
every Austrian citizen. Due to this abstract definition, the
Austrian citizen card is a technology-neutral concept, which
allows for different implementations. Currently, imple-
mentations based on smart cards and mobile phones are in
use. In general, the main functions of the Austrian citizen card
are.
1. identification and authentication of citizens and
2. secure and qualified electronic signature creation.
Citizen identification is based on a special data structure
(the Identity Link), which is solely stored on the Austrian citizen
card. This special data structure contains the citizen's first
name, last name, date of birth, a unique identifier (sourcePIN),
and the citizen's qualified signature certificate. To guarantee
its integrity and authenticity, the Identity Link is digitally
signed by the SRA at issuance.
Citizen authentication is carried out by creating a qualified
electronic signature according to the EU Signature Directive
(European Union, 1999). Referring to this directive, qualified
electronic signatures created by the Austrian citizen card are
equivalent to handwritten signatures.
2.2. Identification and authentication at online services
To integrate the citizen card's identification and authentica-
tion functionality into online services, the open source mod-
ule MOA-ID is used. The current Austrian eID system relies on
180 c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3
Fig. 1 e Simplified illustration of MOA-ID based
authentication.
a local deployment model, where MOA-ID is deployed and
operated in basically every service provider's domain. Due to
that fact, MOA-ID is assumed to be trusted, i.e., it will not leak
sensitive information such as the citizen's sourcePIN. Fig. 1 il-
lustrates in an abstract way the typical identification and
authentication scenario of Austrian citizens using MOA-ID
and Protocol 2.2 illustrates the detailed process. Below, we
firstly discuss the involved entities.
Service Provider: The service provider usually provides
web-based services, which require unique identification and
secure authentication by means of the Austrian citizen card.
This organization can be either a public authority or a private
sector company. In our further descriptions, we focus on
governmental applications only. As an example, typical e-
Government applications may include tax or electronic de-
livery services.
Client-Side Middleware: To facilitate the integration of
citizen card functionality into applications, the Austrian eID
concept foresees an abstract and generic access layer (Hollosi
et al., 2008) to the citizen card, irrespective of its imple-
mentation. The client-side middleware implements this
interface, which provides online applications easy access to
citizen card functionality without the need of knowing any
citizen card specifics. The identity provider MOA-ID uses this
interface for accessing diverse citizen card functions.
 c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3
Currently, different implementations of this client-side mid-
dleware exist. Some require local software installations in the
user's domain such as a piece of software on the user's PC or a
Java Applet (Centner et al., 2009). These middleware ap-
proaches are used to access citizen card implementations
which are based on smart cards. Other citizen card imple-
mentations can also be server-based such as the mobile
phone-based alternative of Orthacker et al. (2010), which in
fact require no local software installations on the client. The
approach of Orthacker et al. (2010) uses short messages (SMS)
to transfer transaction codes to the citizen's mobile phone.
Hence, no additional software needs to be installed on the
mobile phone.
Identity Provider (MOA-ID): MOA-ID represents an identity
provider for governmental or private sector service providers.
On the one hand, MOA-ID manages the communication with
the citizen and her citizen card through the client-side mid-
dleware. The client-side middleware e irrespective of its
implementation e is accessed by MOA-ID through a generic
national interface (Hollosi et al., 2008), which is common for
all middleware implementations. On the other hand, MOA-ID
provides specific and authentic citizen card attributes to the
service provider for further processing.
In the following we briefly explain an authentication pro-
cess flow at online services (cf. Protocol 1). Steps 1 and 2
represent the identification and steps 3 and 4 the authenti-
cation process of the Austrian citizen (Stranacher et al., 2013).
3. Cryptographic building blocks
In the following we briefly review all required cryptographic
building blocks. For the sake of completeness we also include
conventional (public key) encryption and digital signature
schemes.
3.1. Digital signatures
A digital signature scheme (DSS) is a triple
ðDSS:KG; DSS:Sign; DSS:VerifyÞ of efficient algorithms, where
DSS:KG is a probabilistic key generation algorithm that takes a
security parameter k and outputs a private and public key pair
ðsk; pkÞ. The (probabilistic) signing algorithm DSS:Sign takes as
input a message m2f0; 1g and a private (signing) key sk, and
outputs a signature s. The verification algorithm DSS:Verify
takes as input a public (verification) key pk, a message
m2f0; 1g and a signature s, and outputs a single bit
b2ftrue; falseg indicating whether s is a valid signature for m
under pk. One requires a DSS to be correct, i.e., all honestly
generated signatures verify, and existentially unforgeable
under adaptively chosen-message attacks (EUF-CMA). In
practice one typically employs the hash-then-sign paradigm,
i.e., instead of inputting m into DSS:Sign and DSS:Verify, one
inputs HðmÞ where H is a suitable cryptographic hash function.
3.2. (Public key) encryption
A public key encryption (PKE) scheme is a triple
ðPKE:KG; PKE:Enc; PKE:DecÞ of efficient algorithms, where
PKE:KG is a probabilistic key generation algorithm that takes
181
a security parameter k and outputs a private and public key
pair ðsk; pkÞ. The probabilistic encryption algorithm PKE:Enc
takes as input a public key pk and a message m2f0; 1g and
returns a ciphertext c ¼ PKE:Encðpk; mÞ. The decryption algo-
rithm PKE:Dec takes as input a private key sk and a cipher-
text c and returns a message m ¼ PKE:Decðsk; cÞ or ⊥ in the
case of failure. A PKE scheme needs to be correct, i.e.,
decrypting a ciphertext yields the encrypted message, and at
least indistinguishable under chosen plaintext attacks (IND-
CPA).
Abstractly, we can define private key (or symmetric)
encryption schemes (SE) analogously. SE:KG generates only a
single key k which is used as input to the encryption and
decryption algorithms. For the security of a private key
encryption scheme (SE) one also requires at least IND-CPA
security. Note that when we speak of applying PKE to a mes-
sage m, then we implicitly mean applying hybrid encryption,
i.e., generating a random key k of an SE scheme and sending/
storing the tuple ðc1 ¼ PKE:Encðk; pkÞ; c2 ¼ SE:Encðm; kÞÞ.
3.3. Redactable signatures
A conventional DSS scheme does not allow for alterations of a
signed message without invalidating the signature. So called
malleable signatures allow to modify (specified) parts of a
signed message without invalidating the signature. Malleable
signature schemes which allow removal of parts (replacement
by some special symbol ⊥) by any party are called redactable
signature (RS) schemes (Steinfeld et al., 2001; Johnson et al.,
2002). Basically, they can be constructed from any secure
DSS relying on the hash-then-sign paradigm by virtue of
modifying the construction of the hash value (typically using
randomized Merkle-Hash trees instead of a plain crypto-
graphic hash of the entire message). Besides RS constructions
for linear documents, there are also approaches for tree-
structured documents, e.g., XML documents (Brzuska et al.,
2010; Slamanig and Rass, 2010). Below, we present an ab-
stract definition of redactable signature schemes. Henceforth
we assume that a secure scheme for linear documents is used
and refer the reader to (Steinfeld et al., 2001) for required se-
curity properties.
RS.KG: This probabilistic key generation algorithm takes a
security parameter k and produces and outputs a private
and public key pair ðsk; pkÞ.
RS.Sign: This (probabilistic) signing algorithm gets as input
the signing key sk and a message m ¼ ðm½1; …; m½[Þ, split
into blocks m½i2f0; 1g , and outputs a signature
s ¼ RS:Signðsk; mÞ.
RS.Verify: This deterministic signature verification algo-
rithm gets as input a public key pk, a message
m ¼ ðm½1; …; m½[Þ, m½i2f0; 1g , and a signature s and out-
puts a single bit b ¼ RS:Verifyðpk; m; sÞ, b2ftrue; falseg,
indicating whether s is a valid signature for m under pk.
RS.Redact: This (probabilistic) redaction algorithm takes as
input a message m ¼ ðm½1; …; m½[Þ, m½i2f0; 1g , a public
key pk, a signature s, and a list MOD of indices of blocks to
be redacted. It returns a modified message and signature
b b
pair ð m; s Þ ¼ RS:Redactðm; pk; s; MODÞ or an error.
182 c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3
b s
Note that for any redacted signature ð m; b Þ, we have that
b b
RS:Verifyðpk; m; s Þ ¼ true holds.
3.4. Anonymous signatures
Anonymous signature schemes allow members of some group
to issue signatures on behalf of a group in a way that a
signature does not reveal which group member actually pro-
duced it. There are several flavors of anonymous signatures:
Group signatures (Chaum and van Heyst, 1991; Ateniese
et al., 2000) involve a dedicated entity (the group manager),
who runs a setup and an explicit join protocol for every group
member to create the signing key ski of the respective member
i. Furthermore, the group manager is able to open signatures
issued by group members to identify the respective signer and
thus the anonymity provided by group signatures is
conditional.
List signatures (Canard et al., 2006) further allow to limit the
number of issued group signatures per user and thus allow
linkability of group signatures, i.e., group signatures issued by
the same group member can be (publicly) linked (if a certain
threshold is reached).
Ring signatures (Rivest et al., 2001; Abe et al., 2002) are
conceptually similar to group signatures, but there is no group
manager and the anonymity provided is unconditional. They
are “ad-hoc”, meaning that a user may take an arbitrary set
(ring) R of valid public keys to construct a ring signature and R
represents the anonymity set.
We choose to use ring signatures for two of our approaches
and present an abstract definition of ring signatures below.
We assume that the used scheme is secure and refer the
reader to (Rivest et al., 2001; Abe et al., 2002) for the required
security properties.
AS.KG: This probabilistic key generation algorithm takes a
security parameter and outputs a private and public key
pair (sk.pk).
AS.Sign: This (probabilistic) signing algorithm gets as input
a signing key ski s.t. pki 2R, a ring of public keys
R ¼ ðpk1 ; …; pkn Þ, a message m and outputs a signature
s ¼ AS:Signðski ; R; mÞ.
AS.Verify: This deterministic signature verification algo-
rithm gets as input a ring of public keys R ¼ ðpk1 ; …; pkn Þ, a
message m, and a signature s and outputs a single bit
b ¼ AS:VerifyðR; m; sÞ, b2ftrue; falseg, indicating whether s
is a valid signature for m under R.
3.5. Proxy re-encryption
Proxy re-encryption (RE) (Blaze et al., 1998) is a public key
encryption paradigm where a semi-trusted proxy, given a
transformation key, can transform a message encrypted
under the key of party A into another ciphertext to the same
message such that another party B can decrypt with its private
key. Although the proxy can perform this re-encryption
operation, it does not learn anything about the encrypted
message. According to the direction of this re-encryption
operation, such schemes can be classified into bidirectional,
i.e., the proxy can transform from A to B and vice versa, and
unidirectional, i.e., the proxy can convert in one direction
only, schemes. Furthermore, one can distinguish between
multi-use schemes, i.e., the ciphertext can be transformed
from A to B to C etc., and single-use schemes, i.e., the
ciphertext can be transformed only once. Moreover, it is
desirable that an RE scheme is non-interactive, i.e., a trans-
formation key from A to B can be locally computed by A, where
only the public key of B is required. In our approach we
exemplarily use the unidirectional single-use identity-based
proxy re-encryption scheme of Green and Ateniese (Green and
Ateniese, 2007), as in our setting we have a master authority
(SRA) which can take care of the key generation.
RE.Setup: This probabilistic algorithm gets a security
parameter k. It outputs the master public parameters
params, which are distributed to users, and the master
private key msk, which is kept private.
RE.KG: This probabilistic key generation algorithm gets
params, the master private key msk, and an identity
id2f0; 1g and outputs a private key skid corresponding to
identity id.
RE.Enc: This probabilistic encryption algorithm gets
params, an identity id2f0; 1g , and a plaintext m and out-
puts cid ¼ RE:Encðparams; id; mÞ.
RE.RKGen: This probabilistic re-encryption key generation
algorithm gets params, a private key skid1 (derived via
RE:KG), and two identities ðid1 ; id2 Þ2ðf0; 1g Þ2 and outputs a
re-encryption key
 
rkid1 /id2 ¼ RE:RKGen params; skid1 ; id1 ; id2 :
RE.ReEnc: This (probabilistic) re-encryption algorithm gets
as input a ciphertext cid1 under identity id1 and a re-
encryption key rkid1 /id2 (generated by RE:RKGen) and out-
puts a re-encrypted ciphertext
 
cid2 ¼ RE:ReEnc cid1 ; rkid1 /id2 :
RE.Dec: This decryption algorithm gets params, a private
key skid , and a ciphertext cid and outputs
m ¼ RE:Decðparams; skid ; cid Þ or an error ⊥.
We note that as with PKE schemes one requries at least
IND-CPA security and one could as well use other secure
unidirectional single-use schemes (Ateniese et al., 2005; Chow
et al., 2010; Libert and Vergnaud, 2011) instead of the one
mentioned above.
3.6. Anonymous credentials
Anonymous credential systems (Brands, 2000; Camenisch and
Lysyanskaya, 2001, 2002, 2004; Baldimtsi and Lysyanskaya,
2013; Hanser and Slamanig, 2014) enable anonymous
attribute-based authentication, i.e., they allow to selectively
 c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3
reveal attributes while hiding the identity of the credential's
owner as well as undisclosed attributes. Multi-show ap-
proaches support unlinkability, i.e., different showings of a
credential remain unlinkable and are unlinkable to the
issuing (Camenisch and Lysyanskaya, 2001, 2002, 2004;
Hanser and Slamanig, 2014), while others are one-show
(Brands, 2000; Baldimtsi and Lysyanskaya, 2013), i.e., multi-
ple showings of the same credential can be linked together
while issuing and showing cannot be linked. Anonymous
credentials are typically very expressive meaning that
credential holders can not only selectively reveal values of
attributes, but also prove that certain relations among attri-
butes hold, without revealing the attribute values, e.g.,
proving that for attribute age encoded into the credential it
holds that age > 18 without revealing anything beyond. We
use a very simple abstract definition of an anonymous
credential system following (Akagi et al., 2008):
AC.KG: This probabilistic key generation algorithm is run
by an authority and takes a security parameter k and pro-
duces and outputs a private and public key pair ðski ; pki Þ.
AC.Issue: This interactive algorithm is run between a user
U and an authority A. U has as input a list of attributes with
corresponding values attr and wants to obtain a credential
for attr (U may also have as input a long term secret). U
executes the credential issuing protocol for attr with A by
using U's input attr and A has as input it's private key sk.
Both algorithms have as input pk and at the end of this
interaction U obtains a credential Cred corresponding to
attr.
AC.Prove: This interactive algorithm is run between a user
U and a verifier V. U proves the possession of Cred for attr',
which represents some subset of attr, to a verifier V. At the
end of the protocol, V outputs accept if U has a valid
credential Cred for attr', otherwise V outputs reject.
We note that the Prove algorithm may also be non-
interactive, i.e., the credential holder produces a signature of
knowledge which can then be given to the verifier to check the
validity of the proof locally and that attr' may also include
predicates about attributes in attr.
3.7. Fully homomorphic encryption
Fully homomorphic encryption (FHE) schemes are semanti-
cally secure (public-key) encryption schemes which allow
arbitrary functions to be evaluated on ciphertexts without
having access to the secret key and without learning neither
the inputs nor the result in plain. Gentry (Gentry, 2009) pro-
vided the first construction along with a general blue-print to
construct (bootstrap) such schemes from less powerful ones.
Since then lots of improvements and alternate approaches
have been proposed (cf. (Vaikuntanathan, 2011)), although it
can be assumed to require some more years of research to
make FHE practical in general (Gentry et al., 2012; Halevi and
Shoup, 2014, 2015). A fully homomorphic public-key
encryption scheme is defined by the following efficient
algorithms.
183
FHE.KG: This probabilistic key generation algorithm takes a
security parameter and produces and outputs a public-key
pk, a public evaluation key evk, and a private key sk.
FHE.Enc: This probabilistic encryption algorithm takes a
message m2f0; 1g and a public-key pk and outputs a
ciphertext c ¼ FHE:Encðm; pkÞ.
FHE.Dec: This deterministic algorithm takes a ciphertext c
and a private key sk and outputs m ¼ FHE:Decðc; skÞ.
FHE.Eval: This homomorphic evaluation algorithm
takes an evaluation key evk, a function f : f0; 1gn /f0; 1g
and k ciphertexts and outputs a ciphertext
cf ¼ FHE:Evalðf ; c1 ; …; ck ; evkÞ.
In this definition messages are bits, but this can easily be
generalized to larger spaces. Let us consider arbitrary message
spaces in the following. For one of our approaches we need to
assume that FHE schemes exists which support homomorphic
function evaluation and proxy re-encryption. Loosely
speaking, after (or prior to) evaluating some arbitrary function
on a ciphertext we additionally require that for each pair of
public keys pk1 and pk2 one can derive f1;2 and evk1;2 such that
   
m ¼ FHE:Dec FHE:Eval f1;2 ; FHE:Encðm; pk1 Þ; evk1;2 ; sk2 :
This means that by using f1;2 one performs a “re-encryp-
tion” of m encrypted under pk1 to another ciphertext under
pk2 , which can then be decrypted using sk2 . Such a scheme can
trivially be realized using any FHE scheme by letting f1;2
represent the circuit, which firstly decrypts the ciphertext c
using sk1 obtaining m and then encrypts m using pk2 and
evk1;2 ¼ evk1 . Gentry (Gentry, 2009) has shown that this feature
can be realized by encrypting the ciphertext under the re-
ceivers public key and then homomorphically apply the
decryption function (using an encryption of the private key) to
the result.
4. Porting the Austrian eID system to the
public cloud
The current Austrian eID system relies on a local deploy-
ment model, where MOA-ID is deployed and operated in
basically every service provider's domain. Due to that fact,
MOA-ID is assumed to be trusted, i.e., it will not leak sen-
sitive information such as the citizen's sourcePIN. The cur-
rent local deployment model of MOA-ID has some benefits
in terms of end-to-end security or scalability, but still some
issues can be identified compared to a centralized deploy-
ment model of MOA-ID. The adoption of a centralized
model may have the following advantages and
disadvantages:
On the one hand, the use of one single and central instance
of MOA-ID has a clear advantage for citizens as they only need
to trust one specific identity provider. In addition, users could
benefit from a comfortable single sign-on (SSO). On the other
hand, especially service providers can save a lot of costs
because they do not need to operate and maintain a separate
MOA-ID installation. In addition, several different identity
184 c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3
protocols can be supported and hence the service provider
could select its favorite protocol.
Nevertheless, still some disadvantages can be identified.
For instance, a single instance of MOA-ID constitutes a single
point of failure or attack. Additionally, a centralized MOA-ID
relies on a brokered trust model and the service provider has
no direct trust relationship with the citizen anymore as it is in
the local deployment model. Finally, scalability may be an
issue as all citizen authentications will run through this
centralized system. This is probably the main issue, as theo-
retically the whole Austrian population could use this service
for identification and authentication at service providers.
However, the issue on scalability can be tackled by moving
MOA-ID into a public cloud, which is able to theoretically
provide unlimited computing resources. Needless to say, a
move of a trusted service into the public cloud brings up some
new obstacles. For instance, assuming that MOA-ID in the
cloud works correctly, it still has to be ensured that the cloud
provider has no access to private citizen data during the
authentication process. In general, MOA-ID in the cloud must
still work equivalent to the current Austrian eID system and
must still be compliant to the Austrian national law.
In order to make a migration of the Austrian eID system
and MOA-ID into the public cloud possible, we have identified
three approaches to adapt the existing Austrian eID system
for running it in the public cloud. The adapted Austrian eID
system of the respective solution will provide all functions of
MOA-ID (identification, ssPIN generation, and authentication)
as in the current settings, but protects citizen's privacy with
respect to the cloud provider. For providing compact de-
scriptions, we denote the SourcePIN Register Authority by SRA
and the Identity Link by I ¼ ððA1 ; a1 Þ; …; ðAk ; ak ÞÞ as a sequence
of attribute labels and attribute values. Let the set of citizens
be C ¼ fC1 ; …; Cn g and the set of service providers be
S ¼ fS1 ; …; S[ g as well as the citizen's client-side middleware
be denoted as M. Moreover, let us assume that Citizen Ci wants
to authenticate at service provider Sj who requires the set of
attributes A j from I and exactly one ”pseudonym”, i.e., the
ssPIN for the sector s the service provider Sj is associated to.
Additionally, recall that every citizen Ci has a signing key skCi
stored on the card and the public key pkCi is publicly available.
For simplicity, we use a single security parameter k for all
schemes, although depending on the instantiation of the
respective scheme different ones may be required. Table 1
summarizes the abbreviations used in the remaining
subsections.
Table 1 e Abbreviations used within the protocol
descriptions.
A[ Attribute label
a[ Attribute value
Aj Set of required attributes
Ci Citizen
I Identity Link
M Client-side middleware
Sj Service provider
4.1. Using proxy re-encryption and redactable
signatures
Here, the Identity Link I ' is modified in a way that it does no
longer include the sourcePIN, but additionally all ssPINs ac-
cording to all possible governmental sectors. In this
augmented Identity Link I ', every attribute ai is encrypted
using an uni-directional single-use proxy re-encryption
scheme under a public key (the identity of MOA-ID) such
that the corresponding private key is not available to MOA-ID
and is only known to the SRA. Furthermore, instead of using
a conventional digital signature scheme, I' is signed by the
SRA using a redactable signature scheme such that every ai
from I ' can be redacted. The public verification key is available
to MOA-ID. Every service provider Sj obtains a key pair for the
proxy re-encryption scheme when registering at the SRA. The
latter entity produces a re-encryption key, which allows to re-
encrypt ciphertexts intended for MOA-ID to Sj , and gives it to
MOA-ID. In Protocol 2 we present the detailed workflow.
We note that neither step 1 nor step 2 reveal anything aside
from encrypted data to MOA-ID and thus any of the two steps
may be implemented. Furthermore, observe that in step 3 we
provide three distinct ways to realize the protocol. Thereby,
the second choice (3.2) is identical to the state-of-the-art (cf.
Protocol 1) with the drawback that it would allow unique
identification of the citizen. In order to overcome this issue,
one could omit an additional signature (3.1), when assuming
that I' is only available on the respective citizen card and thus
can be already seen as a proof that MOA-ID is interacting with
an authorized citizen. Additionally, one could use anonymous
signature schemes for this purpose. As already noted
in Section 3.4, we propose the use of ring signatures due to
their characteristics. Thereby, the ring R a citizen should use
could be fixed by some party, e.g., the SRA, or could be
assembled on the fly by the citizen (Persiano and Visconti,
2000; Lindell) and be of a size such that it provides the
desired level of anonymity. We, however, note that if citizens
assemble the rings on the fly, the choice of the ring has to be
done with care (Slamanig and Stingl, 2008). For example,
randomly sampling two distinct rings R and R' which both
include Ci and presented along with the same I ' will almost
certainly identify Ci uniquely. For a suitable choice of the
rings, however, MOA-ID only learns that the citizen perform-
ing the authentication is someone within the set S, but there is
no unique identification.
Finally, we want to note that the use of multi-use instead of
single-use PRE schemes in our setting (i.e., where a ciphertext
could be re-encrypted multiple times successively) would
merely make a conceptual difference. Therefore note that
intercepting a ciphertext re-encrypted for some service pro-
vider would require another re-encryption key from the ser-
vice provider to some other party. Computing this re-
encryption key, however, requires access to the private key
of the service provider. Hence, when loosing the private key,
the service provider gives anybody who has access to the
private key access to all encrypted data anyways. Neverthe-
less, since multi-use functionality is not required it makes
c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3 185
186 c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3

sense to restrict ourselves to the use of single-use schemes the following: The Identity Link I of a citizen holds the same
though. attributes as it is in the currently deployed system (and in
particular the sourcePIN), but every attribute ai is encrypted
4.2. Using anonymous credentials using an FHE scheme with the above described property under
MOA-ID's public key, for which MOA-ID does not hold the
As above, the Identity Link I is augmented to I' in a way that it private key. Furthermore, this resulting I ' is conventionally
does no longer include the sourcePIN, but additionally all signed by the SRA. Then, for authentication at Sj , the resulting
ssPIN’s. Now, the SRA issues an anonymous credential Cred to I ' and the signature s are sent to MOA-ID who checks the
every citizen for attr being all attributes in I'. Essentially, a signature and homomorphically computes the respective
citizen then authenticates to a service provider by proving to ssPIN from the encrypted sourcePIN (without learning neither
MOA-ID the possession of a valid credential, i.e., MOA-ID sourcePIN nor ssPIN). Then, for all encrypted attributes
checks whether the credential has been revoked or not. Note required by Sj (including the afore computed encrypted ssPIN),
that for one-show credentials, if the entire credential Cred is MOA-ID performs the “FHE re-encryption” to Sj's public key.
shown to MOA-ID, this amounts to a simple lookup in a
blacklist. If the credential is not revoked, MOA-ID signs the
credential to confirm that it is not revoked and the citizen
Table 2 e Evaluation of the various approaches. We use ✓
performs via M a non-interactive proof by revealing the to indicate that a criterion is fully applicable, z if it is
necessary attributes A j including the required ssPIN to Sj , who partly applicable, and  if it is not applicable. For
can then in turn verify the proof(s) as well as MOA-ID's quantitative criteria we use L (low), M (medium), and H
signature. In Protocol 3 we present the detailed workflow, (high).
where we emphasize that the ratio behind the distinct choices Approach1 Approach2 Approach3
in step 3 is identical to the first approach.
Re-use of existing z z z
Note that in this approach Cred is shown to MOA-ID, which infrastructure
however does not reveal the attribute values but makes Conformance to current ✓ z ✓
revocation easier, since it only requires blacklist lookups. One workflow
could also use multi-show credentials, where M would then Scalability ✓ ✓, z ✓
have to perform a proof with MOA-ID which convinces MOA- Practicability ✓ ✓, z 
Extensibility  z ✓
ID that the credentials are not revoked (Lapon et al., 2011),
Middleware complexity L L, H L
which provides stronger privacy guarantees.
Service provider effort L M H
Trust in MOA-ID L L L
4.3. Using fully homomorphic encryption Anonymity , ✓ ✓ , ✓
Unlinkability  , ✓ 
This approach is a rather theoretic one and requires an FHE Auth. without prior ✓ ✓ ✓
registration
scheme as discussed before. The idea behind this approach is
 c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3
On receiving the respective information from MOA-ID, the
service provider can decrypt all attribute values. In Protocol 4
we present the detailed workflow.
5. Evaluation
In this section we evaluate the three different approaches
based on selected criteria targeting several aspects, e.g.,
evaluating the overall architecture or aspects regarding the
individual entities. We briefly describe the selected criteria for
evaluation below and in Table 2 we present a compact com-
parison of the approaches.
Re-use of existing infrastructure: How much of the existing
infrastructure of the Austrian eID system can be re-used or
do a lot of parts need to be exchanged or modified?
Conformance to current workflow: Is the authentication
process flow of the approach conformable to the existing
citizen card authentication process flow?
187
Scalability: Is the approach applicable in a large scale?
Practicability: Can the authentication process be carried
out within a reasonable time frame?
Extensibility: Is the applied infrastructure of the approach
easily extensible to new requirements, e.g., adding new
sectors and thus requiring new ssPINs.
Middleware complexity: Does the approach require high
complexity or computational power from the client-side
middleware?
Service provider effort: How much effort is required by the
service provider adopting a particular approach?
Trust in MOA-ID: Does the approach require MOA-ID being
trusted?
Anonymity: Does the approach support citizens to be
anonymous with respect to MOA-ID?
Unlinkability: Are users unlinkable to MOA-ID, i.e., can
different authentications of one citizen be linked together?
Authentication without prior registration: The current
Austrian eID system allows registration-less authentica-
tions. Hence, is this feature still possible?
188 c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3
In the following, we give some explanations why specific
criteria could be fulfilled, partly fulfilled, or not-fulfilled by the
respective approach.
Re-use of existing infrastructure: This criterion can only be
partly fulfilled by all approaches, since they require some
modification of the existing Austrian eID infrastructure.
For instance, the attribute values of the existing Identity
Link structure must be exchanged by encrypted values and
the Identity Link needs to be augmented. For approach 1,
the conventional signature of the Identity Link must also
be exchanged by a redactable signature. In contrast to that,
Approach 2 using anonymous credentials requires a com-
plete re-structuring of the Identity Link. However, all ap-
proaches can still rely on the same basic architectural
concept of the Austrian eID infrastructure, using MOA-ID
as identity provider.
Conformance to current workflow: Approach 1 and 3 fully
comply with the current citizen card authentication pro-
cess flow as they follow the steps identification, ssPIN
provision, and authentication. Approach 2 is slightly
different, as MOA-ID just checks if a provided credential is
not valid. The actual verification of the credential is carried
out directly at the service provider.
Scalability: Basically, all approaches can be adopted in a
large scale. Approach 1 and 3 are similar to the existing
Austrian eID system, as only a few attributes need to be
exchanged within the Identity Link and the computational
requirements for the middleware remain low. For approach
2, it must be distinguished whether one-show or multi-
show anonymous credentials will be used. For one-show
credentials, revocation checking is a very light-weight pro-
cess (Baldimtsi and Lysyanskaya, 2013) and hence easy
adoptable. In contrast to that, revocation for multi-show
credentials is much more complex (Lapon et al., 2010,
2011) and not easily applicable for a large amount of users
such as the Austrian population. Finally, any scalability
doubts concerning MOA-ID can be neglected as it is running
in a public cloud providing nearly unlimited resources.
Practicability: Approach 1 and 2 can be considered to be the
most promising practical approaches to date. All the
cryptographic primitives required by approach 1 can
already be implemented efficiently, i.e., redactable signa-
tures typically only have a negligible overhead over con-
ventional digital signature schemes, and (Nunez et al.,
2012; Zwattendorfer et al., 2014) already demonstrate the
practical use of proxy re-encryption. For approach 2, again
we must distinguish between one-show and multi-show
credentials. For one-show credentials, proof generation
requires moderate effort and can be considered entirely
practical (Baldimtsi and Lysyanskaya, 2013; Hinterwa € lder
et al., 2013). For multi-show credentials, revocation is still
complex and computational expensive on a very large
scale as it is the case within eID scenarios (Lapon et al.,
2010, 2011). This makes approach 2 when using multi-
show credentials quite impracticable. For approach 3,
FHE still requires extensive further research to make it
entirely practical, even when relying on high computa-
tional power in public clouds (Halevi and Shoup, 2014,
1
2015).
Extensibility: For adding new sectors, approach 1 would
require a full exchange of the Identity Link, as it must be re-
signed when adding a new encrypted ssPIN. The same issue
holds for approach 2, since a new credential incorporating
the new ssPIN must be stored on the citzen card (with the
exception when using scope-exclusive pseudonyms as
proposed in the ABC4Trust project).1 In approach 3, ssPIN’s
are computed from the encrypted version of the sourcePIN
and no modifications of the Identity Link are required.
Middleware complexity: In approach 1, client-side mid-
dleware complexity is low as only redaction of the Identity
Link is required. Middleware complexity in approach 2
depends on the type of anonymous credentials used.
Depending on the used revocation mechanism, the use of
multi-show credentials can be very expensive for M (Lapon
et al., 2010, 2011), when taking into account that the system
covers all citizens of Austria. For approach 3, middleware
complexity is low again as its functionality is equal to
current middleware implementations.
Service provider effort: The effort for service providers
adopting approach 1 is low. Service providers just need to
verify the data received by MOA-ID and do some decryp-
tion operations. For approach 2, the effort is slightly higher
because service providers need to set up appropriate veri-
fication mechanisms for the claims provided by the user.
The effort for service providers in approach 3 is can be
considered highest with the use of current FHE systems.
Trust in MOA-ID: Since no sensitive citizen data such as
the sourcePIN or any ssPIN are revealed to MOA-ID, no trust
is required. In approach 1 and 3 MOA-ID only sees
encrypted citizen data. In approach 2 MOA-ID does only see
the credential but none of its attribute values. However, in
any case we assume that MOA-ID works correctly.
Anonymity: For approach 2, anonymity is obvious as the
whole approach sets up on anonymous credentials.
Achieving anonymity in approach 1 and 3 depends on the
sub-processes to be chosen for citizen authentication
(signature creation). Both approaches 1 and 3 rely on three
similar alternative sub-processes. Sub-process 1 does not
request a citizen signature and fully relies on the Identity
Link's signature for citizen authentication, as the Identity
Link is only available to the citizen. In this case, the citizen
stays fully anonymous in the face of MOA-ID. In sub-
process 2, citizen signature creation is requested by MOA-
ID for citizen authentication. In this case, citizens are
uniquely identifiable by MOA-ID due to pkCi . Finally, within
sub-process 3 ring signatures are created and enable citi-
zen anonymity with respect to the defined ring.
Unlinkability: For our approaches, it is very hard to achieve
unlinkability with respect to MOA-ID. In approach 1 and 3
citizens are linkable because they always present the same
Identity Link and corresponding signature. Citizens could
only be unlinkable in approach 2, where one-show cre-
dentials allow linking, but multi-show credentials provide
unlinkability.
Authentication without prior registration: This criterion
can still be fulfilled by all of our approaches.
https://abc4trust.eu.
 c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3
5.1. Discussion
After discussing our evaluation, we can conclude that all ap-
proaches might be feasible but not all of are entirely practical
when considering an implementation of a cloud-based
approach instead of the current Austrian eID system. In our
opinion, approach 1 seems to be the best solution for a current
deployment, as it could be quickly realized and requires less
effort for the client-side middleware and the service provider.
However, linkability and higher efforts for extensions are the
drawbacks of this approach. Depending on the type of anony-
mous credential system, approach 2 might also be practicable
and possible to implement. However, it introduces more
complexity and efforts for the client-side middleware
compared to approach 1, while having the benefit of full ano-
nymity and unlinkability. Finally, although approach 3 has its
advantages, e.g., in terms of extensibility, and would be
promising for the future, it is currently not practicable.
Implementations of FHE schemes are currently still in the early
stages which definitely hinder a fast adoption of this approach.
The results of this evaluation lead us to enhance and refine
approach 1 to build a generic model for the use of eIDs in the
public cloud. This generic model can be applied to any eID
system and thus is not restricted to the Austrian eID system.
In the following section we present this generic model, which
we call Privacy-Preserving Identity as a Service-Model for eIDs.
6. Privacy-preserving identity as a service-
model for eIDs
Fig. 2 illustrates the generic Identity as a Service-Model for
eIDs, which can be used for secure identification and
authentication in privacy-invasive environments such as a
public cloud.
Fig. 2 e Privacy-Preserving Identity as a Service-Model for eIDs.
189
The following entities or stakeholders, respectively, are
involved in this generic model:
Registration authority (RA): The registration authority is a
fully trusted entity that issues secure tokens including
authentic and qualified attributes to users. The novelty in
this issuance process is that the issued tokens contain the
user attributes in encrypted form using a proxy re-
encryption scheme.
Service provider (SP): The service provider holds protected
resources or services, which require proper identification
and authentication for gaining access.
Identity provider (IdP): The identity provider manages the
identification and authentication process for the service
provider and provides the service provider the user's
identity and authentication information in a structured
form. In this scenario, the identity provider is deployed in a
privacy-invasive environment such as the public cloud.
Client-Side middleware (M): The client-side middleware
acts as intermediary between the secure token storing
encrypted attributes and the identity provider who verifies
them.
In the following we present the registration and authenti-
cation process within the generic model.
6.1. Registration process
The registration and issuance of an eID (secure token) in this
model is carried out by a trusted entity, the so-called regis-
tration authority (RA). Users need to register at the RA and
prove their attributes to the RA to get a secure token issued.
Details of this registration and proving process are out of
scope of this model as they are dependent on the underlying
respective eID approach. However, the secure token (eID)
190 c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3
issued to the user contains approved attributes in encrypted
format only. User's attributes and identity data are encrypted
for the user using a proxy re-encryption scheme and signed by
the registration authority using a redactable signature
scheme. On the one hand, this ensures that the user stays in
full control of her data because only the user is able to decrypt
her data. On the other hand, a redactable signature scheme
ensures authenticity and integrity of the encrypted data while
still being able to redact data which is not required during an
authentication process.
6.2. Identification and authentication process
The identification and authentication process in this generic
model is also illustrated in Fig. 2. In the following, we briefly
describe the individual process steps.
1. The user wants to access a protected resource or service at
the service provider, which required proper identification
and authentication for gaining access. For identification
and authentication, the service provider forwards the user
to the identity provider.
2. The identity provider requests required identity and
authentication data from the client-side middleware. By
interacting with the client-middleware and the underlying
eID, the user redacts all the data she does not want to
disclose to the service provider. Additionally, the user also
generates a re-encryption key for the service provider. Re-
encryption key generation is based on the user's private
key and the service provider's public key.
3. The redacted identity and attribute data as well as the re-
encryption key are transferred to the identity provider.
4. The identity provider verifies the signature of the redacted
identity data and re-encrypts the data for the service pro-
vider using the received re-encryption key. The re-
encrypted data is also re-structured according to a com-
mon identity and authentication protocol such as SAML.
5. The identity provider transfers the re-encrypted data to the
service provider. To ensure authenticity and integrity of
the transferred data, the identity provider also signs the
data.
6. The service provider verifies the received data and decrypts
it. Based on the decrypted attributes received, the service
provider is able to either allow or deny access to the pro-
tected resource.
7. Related work
In following we discuss related work with respect to electronic
identity covering cryptographic technologies we relied on in
our approach.
7.1. Proxy Re-Encryption
Nunez et al. (Nunez et al., 2012) were one of the first who
started to integrate proxy re-encryption for enhancing privacy
in cloud-based identity services. In Nunez et al. (2012) they
showed how proxy re-encryption can be successfully inte-
grated into the OpenID protocol (http://openid.net). Thereby,
encrypted attributes are stored at an OpenID provider
deployed in a public cloud and only if the user provides an
appropriate re-encryption key, the encrypted attributes can be
decrypted by a service provider. They also did a prototypical
implementation to make a quantitative evaluation of their
proposal. The evaluation provides reasonable figures in terms
of performance (computations can be done in the range of a
few milliseconds) and economic aspects, which lets the
approach to conclude as practical. Nunez and Agudo (Nun ~ ez
and Agudo, 2014) amended their first OpenID-based
approach to a more general privacy-preserving cloud iden-
tity management model, which they call BlindIdM. In fact, the
BlindIdM model is protocol agnostic but they illustrate its
functionality by using SAML. Regarding performance, similar
practical figures are provided in Nun ~ ez and Agudo (2014) as in
Nunez et al. (2012), where cryptographic operations can be
computed in several milliseconds.
A similar architectural approach e but particularly
focusing on eIDs e has been introduced in Slamanig et al.
(2014). The authors propose a user-centric Identity as a
Service-Architecture for eIDs with selective attribute disclo-
sure to be especially applicable in semi-trusted environments
such as the public cloud. This architecture also relies on proxy
re-encryption and a signature variant (blank digital signatures
(Hanser and Slamanig, 2013)) which allows to emulate
redactable signatures. A privacy-preserving identity man-
agement model using proxy re-encryption in a federated ar-
chitecture has been introduced in Zwattendorfer et al. (2014).
In this model, different cloud identity brokers are federated
enabling secure and privacy-preserving identification and
authentication across multiple identity providers in the cloud.
Finally, this privacy-preserving federated cloud identity bro-
ker model has been applied to the STORK framework (http://
eid-stork.eu) to illustrate its applicability also in existing in-
frastructures (Zwattendorfer and Slamanig, 2013b).
7.2. Anonymous credentials
The use of anonymous credentials for eIDs is not new. In 2009,
Bichsel et al. (Bichsel et al., 2009) showed on of the first
implementations of an anonymous credential system (Idemix
(Camenisch and Herreweghen, 2002)) on Java Card 2.2.1.
Hence, due to that the realization of secure identity tokens
relying on anonymous credentials became possible. However,
this application of anonymous credentials is strongly tight-
ened to smart cards. Additionally, the transaction time figures
provided by Bichsel et al. (2009) are still in the range of a few
seconds, which makes the approach more practical but still
inconvenient for users. A different architectural approach of
using anonymous credentials in the German eID system was
shown in Bjones et al. (2014). There, the anonymous credential
system U-Prove (Paquin and Zaverucha, 2013) has been inte-
grated with the German eID architecture. This integration has
been further demonstrated in a typical e-Participation sce-
nario. The performance figures provided by Bjones et al. (2014)
are faster than the ones provided by Bichsel et al. (2009),
because Bjones et al. (2014) relied on one-show credentials (U-
Prove) whereas Bichsel et al. (2009) used multi-show creden-
tials (Idemix). Nevertheless, computations are still approxi-
mately 10 times slower than when using proxy re-encryption.
 c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3
7.3. Homomorphic encryption
To the best of our knowledge, at the current time there is no
related work dealing with fully homomorphic encryption and
eIDs. Somewhat related, Barni et al. (Barni et al., 2010) use well
known paritally homomorphic encryption schemes for a
privacy-compliant fingerprint recognition system. Although
not even requiring FHE, figures provided in there paper indi-
cate problems with the practicality (approximately 50s per
transaction).
8. Conclusions
Unique identification and secure authentication are essential
processes in e-Government. In Austria, for these processes the
Austrian citizen card is the means of choice. Currently, the
Austrian eID system relies on a local deployment approach,
where the identity provider MOA-ID is directly installed in the
service provider's domain. While this local approach has some
benefits in terms of end-to-end security and scalability, a
centralized approach would be more advantageous to users and
service providers. Users could benefit from comfortable single
sign-on authentications and service providers could benefit by
saving operational and maintenance costs. However, the set up
of a centralized identification and authentication service for a
whole country is not trivial due to scalability reasons. To bypass
this problem, we proposed to operate such a central service in a
public cloud, which is able to provide nearly unlimited re-
sources. Nevertheless, although assuming the cloud service
works trustworthy, porting the current Austrian eID system
directly to the public cloud would allow the cloud service pro-
vider to inspect or link sensitive citizen data. To overcome these
issues, we proposed three approaches for the cloud transfer
allowing similar and equal functionality of the current eID
system but still preserving citizen's privacy with respect to the
public cloud provider at the same time. The three approaches
are based on different cryptographic primitives, one using
proxy re-encryption and redactable signatures, one anony-
mous credentials, and one fully homomorphic encryption.
All of the proposed approaches have their benefits and
drawbacks. However, based on the results of the evaluation in
Section 5 we could conclude that approach 1 using proxy re-
encryption and redactable signatures seems to be the most
promising one in terms of a practical implementation. Based
on these findings, we enhanced and refined approach 1, which
was actually tailored to the Austrian eID system, to a generic
model applicable for arbitrary eIDs in privacy-invasive envi-
ronments such as the public cloud. The generic model allows
the application of eID identification and authentication in a
privacy-preserving manner even if the identity provider is
deployed in a public cloud. This generic model also relies on
proxy re-encryption and redactable signatures for ensuring
privacy with respect to the cloud provider. The proposed
model has the following advantages. First, since the identity
data are encrypted for the user and the user herself generates
the re-encryption key for the proxy re-encryption, the user
always stays under maximum control of her data. Second, due
to the use of redactable signature schemes the user is able to
191
define which data to disclose to the identity provider and
subsequently the service provider, respectively. Future work
will include an implementation of the proposed approach for
different eIDs to further illustrate its applicability.
Acknowledgements
We would like to thank the anonymous reviewers for their
valuable suggestions. The second author has been supported
by the European Commission through project FP7-FutureID,
grant agreement number 318424.
references
Abe M, Ohkubo M, Suzuki K. 1-out-of-n signatures from a variety
of keys. In: Advances in cryptology e ASIACRYPT ’02. Vol. 2501
of LNCS. Springer; 2002. p. 415e32.
Akagi N, Manabe Y, Okamoto T. An efficient anonymous credential
system. In: FC 2008. Vol. 5143 of LNCS. Springer; 2008. p. 272e86.
Ateniese G, Camenisch J, Joye M, Tsudik G. A practical and
provably secure coalition-resistant group signature scheme.
In: Advances in cryptology e CRYPTO ’00. Vol. 1880 of LNCS.
Springer; 2000. p. 255e70.
Ateniese G, Fu K, Green M, Hohenberger S. Improved proxy re-
encryption schemes with applications to secure distributed
storage. In: NDSS; 2005. p. 29e43.
Baldimtsi F, Lysyanskaya A. Anonymous credentials light. In:
2013 ACM SIGSAC Conference on Computer and
Communications Security, CCS’13. ACM; 2013. p. 1087e98.
Barni M, Bianchi T, Catalano D, Di Raimondo M, Labati R, Failla P,
et al. A privacy-compliant fingerprint recognition system
based on homomorphic encryption and fingercode templates.
In: Biometrics: theory applications and systems (BTAS), 2010
Fourth IEEE International Conference on; 2010. p. 1e7.
Bichsel P, Camenisch J, Groß T, Shoup V. Anonymous credentials
on a standard java card. In: ACM Conference on Computer and
Communications Security, CCS 2009, CCS ’09. New York, NY,
USA: ACM; 2009. p. 600e10.
Bjones R, Krontiris I, Paillier P, Rannenberg K. Integrating
anonymous credentials with eIDs for privacy-respecting online
authentication. In: Preneel B, Ikonomou D, editors. Privacy
technologies and policy. Vol. 8319 of Lecture Notes in Computer
Science. Heidelberg: Springer Berlin; 2014. p. 111e24.
Blaze M, Bleumer G, Strauss M. Divertible protocols and atomic
proxy cryptography. In: Advances in cryptology e
EUROCRYPT’98. Vol. 1403 of LNCS. Springer; 1998. p. 127e44.
Brands S. Rethinking public key infrastructures and digital
certificates: building in privacy. MIT Press; 2000.
Brzuska C, Busch H, Dagdelen O, € Fischlin M, Franz M,
Katzenbeisser S, et al. Redactable signatures for tree-
structured data: definitions and constructions. In: Applied
cryptography and network security, ACNS 2010. Vol. 6123 of
LNCS. Springer; 2010. p. 87e104.
Camenisch J, Herreweghen EV. Design and implementation of the
idemix anonymous credential system. In: ACM CCS. ACM;
2002. p. 21e30.
Camenisch J, Lysyanskaya A. An efficient system for non-
transferable anonymous credentials with optional anonymity
revocation. In: Advances in Cryptology e EUROCRYPT 2001.
Vol. 2045 of LNCS. Springer; 2001. p. 93e118.
Camenisch J, Lysyanskaya A. A signature scheme with efficient
protocols. In: Security and cryptography for networks. Vol.
2576 of LNCS. Springer; 2002. p. 268e89.
192 c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3
Camenisch J, Lysyanskaya A. Signature schemes and anonymous
credentials from bilinear maps. In: CRYPTO. Vol. 3152 of LNCS.
Springer; 2004. p. 56e72.
Canard S, Schoenmakers B, Stam M, Traor J. List signature
schemes. Discrete Appl Math 2006;154(2):189e201. coding and
Cryptography.
Centner M, Orthacker C, Bauer W. Minimal-footprint middleware
for the creation of qualified signatures. In: WEBIST 2010; 2009.
p. 64e9.
Chaum D, van Heyst E. Group signatures. In: Advances in
cryptology e EUROCRYPT ’91. Vol. 547 of Lecture Notes in
Computer Science. Springer; 1991. p. 257e65.
Chow SSM, Weng J, Yang Y, Deng RH. Efficient unidirectional proxy
re-encryption. In: Progress in Cryptology - AFRICACRYPT 2010.
Vol. 6055 of LNCS. Springer; 2010. p. 316e32.
European Union. Directive 1999/93/EC of the European Parliament
and of the Council of 13. December 1999 on a community
framework for electronic signatures. 1999.
Federal Chancellery. The Austrian e-Government act, Austrian
Federal Law Gazette I 7. 2008. p. 1e11. URL, https://www.ris.
bka.gv.at/GeltendeFassung.wxe?
Abfrage¼Bundesnormen&Gesetzesnummer¼20003230.
Gentry C. Fully homomorphic encryption using ideal lattices. In:
ACM STOC 2009, ACM; 2009. p. 169e78.
Gentry C, Halevi S, Smart NP. Homomorphic evaluation of the
AES circuit. In: Advances in cryptology - CRYPTO 2012; 2012.
p. 850e67.
Green M, Ateniese G. Identity-based proxy re-encryption. In:
ACNS 2007. Vol. 4521 of LNCS. Springer; 2007. p. 288e306.
Halevi S, Shoup V. Algorithms in HElib. In: Advances in cryptology
e CRYPTO 2014. Vol. 8616 of LNCS. Springer; 2014. p. 554e71.
Halevi S, Shoup V. Bootstrapping for HElib. In: Advances in
cryptology e EUROCRYPT 2015, LNCS. Springer; 2015. p. 873.
Hanser C, Slamanig D. Blank digital signatures. In: ACM
ASIACCS’13, ACM; 2013. p. 95e106. ext.: IACR ePrint 2013/130.
Hanser C, Slamanig D. Structure-preserving signatures on
equivalence classes and their application to anonymous
credentials. In: ASIACRYPT. Vol. 8873 of LNCS. Springer; 2014.
p. 491e511. Full version: Cryptology ePrint Archive, Report
2014/705.
Hinterwa € lder G, Zenger CT, Baldimtsi F, Lysyanskaya A, Paar C,
Burleson WP. Efficient e-cash in practice: NFC-based
payments for public transportation systems. In: Privacy
enhancing technologies, PETS 2013. Vol. 7981 of LNCS.
Springer; 2013. p. 40e59.
Hollosi A, Karlinger G, Ro€ ssler T, Centner M. The Austrian citizen
card. 2008. http://www.buergerkarte.at/konzept/securitylayer/
spezifikation/aktuell/.
Johnson R, Molnar D, Song DX, Wagner D. Homomorphic
signature schemes. In: CT-RSA ’02. Vol. 2271 of LNCS.
Springer; 2002. p. 244e62.
Lapon J, Kohlweiss M, Decker BD, Naessens V. Performance
analysis of accumulator-based revocation mechanisms. In:
International Information Security Conference, SEC 2010;
2010. p. 289e301.
Lapon J, Kohlweiss M, Decker BD, Naessens V. Analysis of
revocation strategies for anonymous idemix credentials. In:
CMS 2011. Vol. 7025 of LNCS. Springer; 2011. p. 3e17.
Leitold H, Hollosi A, Posch R. Security architecture of the Austrian
citizen card concept. In: ACSAC 2002; 2002. p. 391e402.
Libert B, Vergnaud D. Unidirectional chosen-ciphertext secure
proxy re-encryption. IEEE Trans Inf Theory 2011;57(3):1786e802.
Y. Lindell, Anonymous authentication, J Priv Confid 2(2).
Nun~ ez D, Agudo I. BlindIdM: A privacy-preserving approach for
identity management as a service. Int J Inf Secur April
2014;13(2):199e215.
Nunez D, Agudo I, Lopez J. Integrating OpenID with proxy re-
encryption to enhance privacy in cloud-based identity services.
In: 4th IEEE International Conference on Cloud Computing
Technology and Science proceedings. IEEE; 2012. p. 241e8.
Orthacker C, Centner M, Kittl C. Qualified Mobile server signature.
In: SEC 2010. Vol. 330 of AICT. Springer; 2010. p. 103e11.
Paquin C, Zaverucha G. U-prove cryptographic specification v1.1,
revision 3. Tech. rep. Microsoft Corporation; 2013.
Persiano P, Visconti I. User privacy issues regarding certificates
and the TLS protocol: the design and implementation of the
SPSL protocol. In: ACM Conference on Computer and
Communications Security, CCS 2000. ACM; 2000. p. 53e62.
Rivest RL, Shamir A, Tauman Y. How to leak a secret: theory and
applications of ring signatures. In: ASIACRYPT 2001. Vol. 2248
of LNCS. Springer; 2001. p. 552e65.
Slamanig D, Rass S. Generalizations and extensions of redactable
signatures with applications to electronic healthcare. In:
Communications and multimedia security, CMS 2010. Vol.
6109 of LNCS. Springer; 2010. p. 201e13.
Slamanig D, Stingl C. Investigating anonymity in group based
anonymous authentication. In: The future of identity in the
information society. Vol. 298 of AICT. Springer; 2008. p. 268e81.
Slamanig D, Stranacher K, Zwattendorfer B. User-centric identity
as a service-architecture for eIDs with selective attribute
disclosure. In: 19th ACM Symposium on access control models
and technologies (SACMAT 2014), ACM; 2014. p. 153e63.
Steinfeld R, Bull L, Zheng Y. Content extraction signatures. In:
ICISC 2001. vol. 2288 of LNCS. Springer; 2001. p. 285e304.
Stranacher K, Tauber A, Zefferer T, Zwattendorfer B. The Austrian
identity ecosystem: an e-Government experience. In:
Martı́nez AR, Marin-Lopez R, Pereniguez-Garcia F, editors.
Architectures and protocols for secure information technology
infrastructures. IGI Global; 2013. p. 288e309.
Vaikuntanathan V. Computing blindfolded: new developments in
fully homomorphic encryption. In: IEEE FOCS 2011; 2011. p. 5e16.
Zwattendorfer B, Slamanig D. On privacy-preserving ways to
porting the Austrian eID system to the public cloud. In:
International Information Security Conference, SEC 2013. Vol.
405 of IFIP AICT. Springer; 2013. p. 300e14.
Zwattendorfer B, Slamanig D. Privacy-preserving realization of
the STORK framework in the public cloud. In: International
Conference on Security and Cryptography (SECRYPT 2013);
2013. p. 419e26.
Zwattendorfer B, Slamanig D, Stranacher K, Ho € randner F. A
federated cloud identity broker-model for enhanced privacy
via proxy re-encryption. In: International Conference on
Communications and Multimedia Security, CMS’2014; 2014.
p. 92e103.
Bernd Zwattendorfer has studied Telematics and received his
master’s degree from Graz University of Technology. Additionally,
he holds a master’s degree in International Business received
from University of Graz. He has finished his PhD degree in Tele-
matics in 2014. In 2007 he joined the eGovernment Innovation
Center (EGIZ) in Graz, which supports the Austrian Federal
Chancellery in further developing the Austrian ICT-Strategy by
research and innovation. He is currently working on several topics
related to IT security and eGovernment, focusing on electronic
identity and cloud computing. During his work he participated in
the following EU projects: FP6 project eGov-Bus (Cross-Border
eGovernment Services), LSP project STORK (Cross-Border eID
Federation), GINI-SA (Vision of Personal Identity Management
Environment).
Daniel Slamanig is a postdoctoral researcher at IAIK, Graz Uni-
versity of Technology (TUG). He received his PhD degree
(Dr.techn.) in computer science from Alpen-Adria-Universita €t
Klagenfurt in 2011 with distinction, where he was working in the
area of public key cryptography focusing on privacy-preserving
cryptography. From 2011 to 2012 he was a postdoctoral
 c o m p u t e r s & s e c u r i t y 5 2 ( 2 0 1 5 ) 1 7 8 e1 9 3 193

researcher at the Carinthia University of Applied Sciences (CUAS)
where he led a project on privacy-preserving cloud computing and
taught introductory and advanced courses and seminars on
cryptography, IT-security and computer science. His main
research interests include cryptography, privacy and information
security. Currently he is particularly interested in privacy-
enhancing cryptographic primitives and cryptographic protocols
for cloud computing. Daniel is a member of the International
Association for Cryptologic Research (IACR) and the Austrian
Computer Society (OCG).