An Application of a Group Signature Scheme with Backward

Unlinkability to Biometric Identity Management

Julien Bringer

, Herv´e Chabanne

1,2

and Alain Patey

1,2

Morpho, Issy-Les-Moulineaux, France

T´el´ecom ParisTech, Identity and Security Alliance (The Morpho and T´el´ecom ParisTech Research Center), Paris, France

Keywords:

Group Signatures, Identity Management, Derivation, Cascade Revocation, Biometrics, Anonymity.

Abstract:

We introduce a new identity management process in a setting where users’ identities are credentials for anony-

mous authentications. Considering identity domains organized in a tree structure, where applying for a new

identity requires to previously own the parent identity, we enable a cascade revocation process that takes into

account this structure while ensuring anonymity for non-revoked users, in particular, towards the providers of

other identity domains. Our construction is based on the group signature scheme of (Bringer and Patey, 2012).

1 INTRODUCTION

In this paper we consider a scenario where users have

access to a kind of federation of identity management

systems with different identity providers that have

some dependencies between them: To each identity

provider corresponds an identity domain and the set

I of these domains is structured as a tree. When one

wants to apply for a new identity in an identity domain

, one has to own a valid identity for the parent do-

main I

. These dependencies also imply that it should

be possible to automatically revoke across different

domains. To this aim, the new identity is derived from

the previous ones in order to maintain a link with the

identities above. Contrary to what is done in central-

ized federated identity management, one important is-

sue is then to ensure the privacy of this link. We call

this property Cross-Unlinkability

Let us give an example of application of our pro-

posal. Consider the identity domain (sub-)tree de-

scribed in Figure 1. We assume that a government

sets up an identity management system, used for in-

stance to access services. In this example, applying

for an identity stating that you own a car insurance re-

quires to previously own an identity in the domain of

users with driver’s licenses. We also wish that, when

a user uses his student identity, anonymity of this user

is guaranteed against the providers of all other do-

mains, including the managers of the parent domain

(National Identity), the children domains (Colleges)

or the sibling domains (Driver’s license).

We use as elementary component of our system a

National Identity

Student Identity

College 2College 1

Driver’s License

Car Insurance HGV License

Figure 1: An example of an identity domain tree I.

biometric anonymousauthentication scheme (Bringer

et al., 2008) (BCPZ) based on Veriﬁer-Local Revo-

cation (VLR) group signatures (see Figure 2). This

protocol enables members of a group, managed by a

Group Manager GM, to authenticate, using an elec-

tronic device, to a service provider while proving

nothing more than their belonging to the group. The

use of biometrics guarantees that the legitimate user

uses the device and this, combined to the use of a

group signature scheme, leads to an anonymous re-

mote authentication. We can see the group considered

in such a scheme as an identity domain I

, where the

identity provider IP is the GM. The keys that are is-

sued by IP are actually credentials that are associated

to the issued identity. In the following, these creden-

tials will be assimilated to the identities. The users

that obtained an identity from IP can prove its validity

to service providers that rely on this identity domain.

We recall that group signatures enable authorized

users to sign anonymously on behalf of a group. We

only consider the case of VLR group signatures. The

VLR property (Boneh and Shacham, 2004) guaran-

tees that only the public parameters and a revocation

list RL are required to check a signature. Concretely,

when a user is revoked, a revocation token derived

421

Bringer J., Chabanne H. and Patey A..

An Application of a Group Signature Scheme with Backward Unlinkability to Biometric Identity Management.

DOI: 10.5220/0004123904210425

In Proceedings of the International Conference on Security and Cryptography (SECRYPT-2012), pages 421-425

ISBN: 978-989-8565-24-2

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

from his signing key is added to RL. It is used by ver-

iﬁers to prevent revoked users from further signing.

To reach our goal of Cross-Unlinkability, we use

the group signature introduced in (Bringer and Patey,

2012) (which patches and extends (Chen and Li,

2010)) that satisﬁes Backward Unlinkability. This

property enables users to sign at different time peri-

ods using the same keys, while maintaining unlinka-

bility between signatures issued at different periods,

even if the user is revoked at one of these periods. In

our proposal, we no more consider these periods as

time periods but as children of a given identity in the

identity domain tree. Thus, authentications in two dif-

ferent domains are impossible to link if the user is not

revoked from both. Moreover, the cascade revocation

process that we describe does not threaten the security

properties that we guarantee.

2 THE CL AND BP GROUP

SIGNATURES

In this section, we describe the model of group sig-

natures presented in (Bringer and Patey, 2012). We

instantiate this model using two schemes introduced

in (Bringer and Patey, 2012): a patched version of the

(Chen and Li, 2010) scheme, denoted by CL, and an

extension of this patched version with Backward Un-

linkability (BU), denoted by BP. Notice that both can

be used with the same parameters.

2.1 Components

There are three types of entities: a Group Manager

GM, a set of members and a set of veriﬁers. A BP

or a CL Group Signature Scheme consists of the fol-

lowing algorithms. (Moreover, in the BP scheme, be-

cause of BU, all algorithms but KeyGen depend on

the current time period j and one revocation list RL

per time period has to be used (see also Remark 1)).

KeyGen. The group manager outputs the group pub-

lic parameters gpk. He also chooses a secret key msk

and its public counterpart mpk. gpk and mpk are pub-

lished. GM also publishes an empty revocation list

RL.

Join. This algorithm is an interactive protocol be-

tween GM and a member M

. M

gets a secret key

= (x

, A

, f

) where f

is chosen by M

, x

by GM

and A

is computed by GM using msk, x

and some

information about f

. GM only gets x

and A

, he also

derives a revocation token rt

from x

Revoke. GM runs this algorithm to prevent a member

from further making valid signatures. It outputs an

updated revocation list RL.

Sign. This algorithm, run by a member M

, takes as

input a message m, M

’s key sk

and a message m. It

outputs a signature σ.

Verify. This algorithm, run by a veriﬁer takes as input

a message m, its signature σ and the Revocation List

RL. It checks if the message has been signed by an un-

revoked group member, without revealing the signer’s

identity. The possible outputs are valid and invalid.

Open. This algorithm is run by GM. It takes a sig-

nature σ on a message m as input, together with all

revocation tokens of the group members. It reveals

the identity of the signer.

2.2 Security Properties

We describe the security properties fulﬁlled by the

group signature schemes. Both BP and CL schemes

satisfy Correctness, Selﬂess-Anonymity, Traceability

and Exculpability. The BP scheme moreover satisﬁes

Backward Unlinkability.

(a) Correctness. Every check of a well-formed sig-

nature, made by an unrevoked user, returns valid.

(b) Selﬂess-Anonymity. A member can say if he pro-

duced a particular signature. If it was not him, he has

no information about the user who produced it.

is able to forge a signature that can not be traced to

one of the corrupted users which participated in its

forgery.

(d) Exculpability. Nobody, even the Group Manager,

is able to produce another user’s signature.

(e) Backward Unlinkabilty. (encompasses Selﬂess-

Anonymity) The valid signatures remain anonymous,

even after the signer’s revocation. Revoked users can

come back after their revocation into the group and

use their previous keys without any loss of anonymity.

Remark 1. (Backward Unlinkability) To enable BU,

the BP scheme divides time into periods. Instead of a

unique revocation list RL, there is one revocation list

for each period j. Similarly, each member M

has

a revocation token rt

for each period j instead of a

unique rt

. Usually, for every time period j, a random

token h

is chosen. The period revocation token is

then obtained as follows: rt

= h

. Thus, two tokens

and rt

′

of the same user at different time periods

are unlinkable, which guarantees BU.

Remark 2 (BCPZ Anonymous Authentication). We

describe in Figure 2 how to adapt the BCPZ anony-

mous authentication scheme using the CL scheme. We

refer the reader to (Bringer et al., 2008) for further

details. Notice that in our adaptation, we use the

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

422

Human user H

Sensor S

Service Provider P

′

∼

b, f

= H(b)

σ =Sign

(m, sk

, gpk, mpk)

Verify

(m, σ, gpk, mpk, RL)

challenge message m

′

(Scanning)

b, x

, A

(from card)

Figure 2: The BCPZ authentication scheme.

property of Exculpability enabled by the CL scheme

and we do not give any biometric data to the GM.

3 OUR PROPOSAL

3.1 The Model

We assume that identity domains are organized as a

tree I with a root I

. When one wants to acquire a

new identity from a domain I

, one has to prove that

one owns a valid identity for its parent domain I

in I.

Each identity domain I

has an identity provider IP

and we will denote by k ≺ l the fact that the identity

domain I

is the parent of the identity domain I

For each identity that they own, the authorized

users possess the necessary keys to authenticate

anonymously following the principle of the BCPZ

scheme. The corresponding IP is in fact the group

manager for the underlying group signature scheme.

The functionalities of our protocol are the following.

KeyGen. This is run by the IP’s. IP

ﬁrst returns the

public parameters gpk for all the domains. Then each

creates a secret/public key pair (msk

, mpk

) and

publishes mpk

Enrolment. For a domain I

, this algorithm is jointly

run by the identity provider IP

and a user M

. The

input for the user is a fresh acquisition b

of a biomet-

ric trait B and for IP

is his secret key msk

. It returns

a new secret key sk

= (x

, A

, f

) for M

for the iden-

tity domain I

. f

is only knownfrom M

and the other

parts x

and A

are known from both. x

is in particular

used as a revocation token rt

for M

for this domain.

Derivation. For a domain I

, this algorithm is jointly

run by a user M

requiring to get a new identity for

the domain I

and the identity provider IP

of I

. The

input for M

is his secret key for the parent domain I

of I

in I and the input for IP

is his secret key msk

It returns the result of the enrolment of M

to I

if M

successfully proves to IP

that he owns a valid (and

non revoked) identity for I

Authentication. For a domain I

, this is jointly run

by a user M

and a service provider requiring a valid

identity from I

. The input of M

is his secret sk

and

a fresh biometric acquisition b

′

. The service provider

only needs gpk and mpk

. It returns a boolean denot-

ing the acceptance or the reject of the authentication.

Revocation. This recursive algorithm is run by the

identity provider IP

of I

who wants to revoke a mem-

ber M

of I

. It takes as input the revocation token rt

of the user M

and the revocation list RL

• Local Revocation: It returns an updated RL

where the revocation token of M

for I

is added.

• Downwards Revocation (compulsory): The

newly published revocation token rt

is sent to the

IP’s of the domains that are children of I

, who then

run the Revocation algorithm.

• Upwards Revocation (optional): IP

sends an in-

formation rt

k≺l

to IP

, where I

is the parent of I

who can then decide to revoke (in that case we will

say that the upwards revocation has been accepted) or

not the user, using rt

k≺l

to retrieve the user’s identity

for I

Remark 3 (Revocation). This corresponds to the cas-

cade revocation capability. The goal of the down-

wards revocation process it to ensure that once a user

is revoked of a given domain I

then this user is also

revoked from all identity domains that are derived

from I

, i.e. the children of I

in I, the children of these

children, and so on. The optional upwards revocation

is there to give the possibility for a domain to signal

to the parent domain that a user has been revoked. If

this is not executed, IP

does not learn anything on

the identity of the user revoked by IP

3.2 Security

The main security property that we require from our

scheme is that an authentication in a given domain re-

mains anonymous even for the providers of the other

identity domains, for instance of the sibling domains

in I. We insist on the fact that, in case of revocation,

if IP

does not inform the provider IP

of the parent

identity I

of I

that a given user is revoked from I

then IP

is not able to know about the identity of this

user. We call this property Cross-Unlinkability (CU).

CU is an adaptation of Selﬂess-Anonymity. Addition-

ally, we directly adapt the security properties a), c)

and d) of VLR group signature to our setting of iden-

tity management.

3.3 The Construction

We instantiate our algorithms using the CL and BP

group signatures, as follows.

AnApplicationofaGroupSignatureSchemewithBackwardUnlinkabilitytoBiometricIdentityManagement

423

KeyGen. IP

runs the KeyGen

algorithm of the BP

group signature to generate the public parameters gpk

of the scheme. Then each IP

, including IP

, creates

a key pair (mpk

, msk

) compatible with gpk. The

msk

’s are kept secret by the IP’s. gpk and all the

msk

’s are published. The IP’s also agree on a set of

period tokens h

k≺l

, that are used for the Derivation

from I

to I

. We need, for each internal node I

the tree I, to set one period “k ≺ l” per child I

of I

Enrolment. We assume that M

has fulﬁlled all the

conditions to acquire an identity from the domain I

The enrolment phase is then the same as in the BCPZ

scheme. M

is acquired a biometric trait b

. This trait

is hashed to form a ﬁrst part f

= Hash(b

) of his new

secret key. M

and IP

then jointly run the Join

al-

gorithm. If I

6= I

, x

is not chosen randomly by the

IP, as in the Join

algorithm, but it uses the output

of the Derivation algorithm as the choice for x

, to

enable the revocation process. At the end of this algo-

rithm, M

stores x

, A

and his biometric reference b

knows x

and A

and derives the revocation token

for M

for domain I

: rt

= x

Authentication. The authentication for a member M

to a service provider P requiring to belong to I

merely a BCPZ authentication using the group signa-

ture parameters for the domain I

. Concretely, when

a user wants to prove to P that he owns an identity, he

selects his associated device, connects it to a trusted

sensor that communicates with P. The sensor checks

using biometricsthat the legitimate person is using the

card, reads the keys on the card and signs a challenge

message sent by P.

Derivation. We now explain how to derive identi-

ties. Let I

be the parent domain of I

in I and let

us assume that a user M

owns an identity for I

and

wants to acquire an identity for the domain I

. M

has

to engage a speciﬁc authentication process with the

identity provider IP

First, the user authenticates to IP

, viewed as a ser-

vice provider for I

to prove validity of his identity in

However, he uses the BP signature at period k ≺ l

instead of the CL scheme. M

also sends the revo-

cation token rt

k≺l

corresponding to the k ≺ l period.

checks the validity of the signature using Ver-

ify

and checks that the token is the good one using

Verify

with a revocation list set as {rt

k≺l

} (which

should fail during the Revocation Check). If all tests

succeed, IP

computes x

= Hash(msk

||rt

k≺l

), which

is then used as input for the Enrolment algorithm.

This derivation process is described in Figure 3.

Remark 4 (Explanations on the Derivation Process).

The BU property of the BP scheme prevents from link-

ing revocation tokens of the same user at different

User M

Identity Provider for I

k≺l

, challenge message m

Derivation Phase

k≺l

, m

=Sign

(gpk, mpk

, sk

, m, H

)

, rt

k≺l

Verify

(gpk, mpk

, m, σ

, RL

)

Verify

(gpk, mpk

, m, σ

, k ≺ l, RL = {rt

k≺l

})

Derive x

= rt

=Hash(msk

||rt

k≺l

)

Fresh acquisition b

=Hash(b

)

Enrolment Phase

Enrolment to I

using f

and x

Store b

, x

and A

Store (rt

k≺l

, rt

) on DB

Figure 3: The derivation process.

time periods. Here, periods do not represent time, but

the different children identities of a given identity do-

main. Thus, the identities of one user for different do-

mains will not be linkable. Furthermore, the copy of

k≺l

kept by IP

is used in the revocation process de-

scribed below. We consequently achieve our property

of Cross-Unlinkability while maintaining a cascade

revocation process.

Notice also that this derivation process at the

same time takes into account the parent identities and

preserves consistency with the original biometric ref-

erences, since the new acquisitions have to match with

the previous ones.

Revocation. Let us assume that the identity provider

of the identity domain I

wants to revoke a user

. He proceeds as follows.

Local Revocation: IP

takes as input the revocation list

and the revocation token rt

of M

, then adds rt

to RL

: RL

= RL

∪ {rt

}. The new RL

is published.

Downwards Revocation: This direction is automatic.

All providers for the identity domains (I

)

m∈M

that

are children of I

learn the revocation token rt

. They

all compute h

l≺m

and look in their databases DB

’s if

this token is present. If it is, they start the Revocation

algorithm for the associated user, using the revocation

token rt

associated to rt

l≺m

in DB

Upwards Revocation: We recall that this part of the

Revocation algorithm is optional. IP

can report to

the provider of the parent domain I

the user M

if he

thinks that IP

should revoke him too. He sends to IP

the item rt

k≺l

associated to M

in DB

. If IP

wishes

to discover to whom it corresponds, he computes h

′

for all the M

′

’s that belong to I

. When h

′

= rt

k≺l

the associated user M

′

is the user M

that was revoked

by IP

. IP

can then, if he desires, revoke M

′

from I

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

424

ACKNOWLEDGEMENTS

This work is partially funded under the European FP7

FIDELITY project (SEC-2011-284862).

REFERENCES

Boneh, D. and Shacham, H. (2004). Group signatures with

veriﬁer-local revocation. In ACM Conference on Com-

puter and Communications Security, pages 168–177.

Bringer, J., Chabanne, H., Pointcheval, D., and Zimmer, S.

(2008). An application of the Boneh and Shacham

group signature scheme to biometric authentication.

In IWSEC, pages 219–230.

Bringer, J. and Patey, A. (2012). VLR group signatures:

How to achieve both backward unlinkability and efﬁ-

cient revocation checks. In SECRYPT.

Chen, L. and Li, J. (2010). VLR group signatures with in-

disputable exculpability and efﬁcient revocation. In

SocialCom/PASSAT, pages 727–734.

AnApplicationofaGroupSignatureSchemewithBackwardUnlinkabilitytoBiometricIdentityManagement

425