A New Delegated Authentication Protocol based on PRE

Anass Sbai, Cyril Drocourt

and Gilles Dequen

MIS Laboratory, University of Picardie Jules Verne, Amiens, France

{

Keywords:

Authentication, Delegation, Single Signe On, Proxy Re-Encryption.

Abstract:

New trends highlight the use of delegated authentication solutions where identity providers do not need to

synchronize user credentials with services. It is a facility for service providers and also for users who do not

have to create multiple accounts. Different solutions for single sign-on and delegated authentication exist.

Most of these solutions require many exchanges between the different actors involved in the protocol, an

additional TLS layer and/or the use of signature schemes which, in terms of security, rely on random oracles for

reasons of efﬁciency. In this article, we recall the concept of the best known solutions (e.g. Kerberos, OpenID,

...), brieﬂy discuss the possibility of using one-way accumulators and deﬁne the Proxy Re-Encryption (PRE).

Next, we propose a new delegated authentication protocol that allows users to authenticate anonymously on

insecure networks and therefore asynchronously without direct communication between identity providers

and service providers while minimizing the number of interactions. We based our solution on the use of

PRE which could be instantiated by schemes based on standard assumptions. We ﬁrst show how our protocol

behaves against different types of attacks. Then in a more formal manner, we present the proof of security

based on an adaptation of BAN logic method that supports the use of PRE functionalities.

1 INTRODUCTION

We are increasingly using remote services, whether

on the web or other platforms. Most of these require

the user to create an account and then log in. This

allows them to limit access. There are several meth-

ods for authentication depending on the sensitivity of

data or service requested. Typically, login/password,

OTP (one time password) and certiﬁcates are the most

commonly used. But recently, due to the technolog-

ical evolution, biometrics are also used to identify

a user through his physiological characteristics such

as face, iris and ﬁngerprint (Alizadeh et al., 2016).

For users, having multiple accounts is restrictive be-

cause the most used method is login/password authen-

tication, which implies that the user must remember

each password since it should ideally be different for

each service. Then appeared the single sign-on ap-

proach (SSO) which allows users to access multiple

services by authenticating only once. The model used

by this authentication system is mainly based on three

actors: the client who requests access to a resource

or a service, the identity provider (Idp) that stores

clients’ credentials and the service provider that pro-

https://orcid.org/0000-0003-1636-9462

https://orcid.org/0000-0001-7497-1182

vides ressources and services based on clients’ per-

missions communicated by the Idp. There are three

main approaches proposed for implementing the SSO

system:

• Centralized Approach: it is mainly used for ser-

vices that depend on the same entity which man-

ages its own security policy. For this purpose, it is

possible to use a Kerberos authentication mecha-

nism.

• Federated Approach: it enables extended access

control and SSO across organizational boundaries

by distributing the control and maintenance of

the different activities, thus providing more con-

venience and efﬁciency. It allows each entity to

manage their own security policy and certain parts

of data users could be shared with other inter-

active services. Different solutions exist, mainly

SAML, OpenID...

• Cooperative Approach: in the same sense, it al-

lows each partner to manage their own authenti-

cating system but it differs from the latter in the

sense that the users’ credentials are not shared be-

tween the different services, example is Central

Authentication Service (CAS).

The different systems mentioned above are based on

what we consider as conventional methods e.g. sym-

468

Sbai, A., Drocourt, C. and Dequen, G.

A New Delegated Authentication Protocol based on PRE.

DOI: 10.5220/0010542404680478

In Proceedings of the 18th International Conference on Security and Cryptography (SECRYPT 2021), pages 468-478

ISBN: 978-989-758-524-1

metric ciphers as it is the case for Kerberos, or asym-

metric crypto-based systems which necessarily use

signatures. On the other hand, there are crypto-

graphic solutions that we consider to be unconven-

tional such as signature groups, one way accumula-

tors, etc. Which are not or rarely used in practice

usually due to efﬁciency. All cryptographic solutions

used in practice for signing rely on the random oracle

model for efﬁciency reasons (Chaidos and Couteau,

2018).

Can we avoid these conventional methods and

solve delegation issues e.g. authenticating users asyn-

chronously through identity providers and without

synchronizing their credentials with services, while

minimizing the number of communications required

and increasing the robustness of the system? This is

the main question that we aim to answer through this

paper.

2 RELATED WORKS

Kerberos: is based on Needham-Schroeder symmet-

ric key protocol. In terms of delegation, Kerberos

proposes two types of delegations: unconstrained and

constrained. In the ﬁrst one, the server or the service

account that is granted this right is able to imperson-

ate the user to communicate with any service on any

machine. Historically, this was the only choice when

the principle of delegation was introduced, but it has

been supplemented by the principle of Constrained

Delegation. It allows service administrators to spec-

ify and enforce application approval limits by limit-

ing the scope to which application services can act on

behalf of a user. Service administrators can specify

which front-end service accounts can perform dele-

gation on their primary services.

Shibboleth: is one of the most popular open sources

SSO platforms for local identity and access manage-

ment. The Shibboleth framework is based mainly

on the OASIS Security Assertion Markup Language

(SAML). It provides a SSO service and an attribute-

based authorization while maintaining user’s privacy.

Like most of the other solutions, the protocol de-

ﬁnes two functional components which are the Ser-

vice Provider (SP) that handle authorization and the

IdP. The latter manages and maintains the identity of

users. It is designed to provide federated identity with

the main assumption: the IdP and the SP trust each

other within a federation. This trust is based on Pub-

lic Key Infrastructure (PKI) and managed using PKI

certiﬁcates.

OpenId: was created for federated authentication. It

is designed as a user-centric identity management sys-

tem where any identity provider can be used by the

users (with the exception of whitelists). They can

even establish their own provider. There is no need to

pre-choose or negotiate a deal with the providers to al-

low users to use any other account they have. In 2007

OpenID Attribute Exchange extension (OpenID AX)

was published (Hardt et al., 2007). It deﬁnes how to

store or update attributes information on the OpenID

Provider (OP) and how to retrieve those attributes. In

2014 OpenID Connect was deﬁned as an evolution of

the OpenID standard and it is based on the OAuth 2.0

protocol by adding an authorization layer. It relies on

the JSON Web Token (JWT) standard for exchanging

identity information or any other relevant information

to the service provider called in OpenID context Re-

lying Party (RP).

Oauth: introduces an authorization layer that enables

applications to obtain limited access to user accounts.

It could be interfaced with kerberos and other authen-

tications solution described above. The system may

involve up to four actors : Ressource Owner (RO),

application Client (C), Authorization Server (AS) and

the resource server (RS). In general, a client C re-

quests access to resources controlled by the RO and

hosted by the RS. Instead of using the RO credentials

to access the protected resources, C obtains an access

token (A string indicating scope, lifetime, and other

speciﬁc access attributes). Access tokens are assigned

to third party clients (C) by an AS with the approval

of the RO. The C uses the access token to access the

protected resources hosted by the RO.

3 OUR CONTRIBUTION

In this section we will detail our contribution by ﬁrst

giving the main idea, then deﬁning the PRE, and ﬁ-

nally explaining the different phases of our protocol.

3.1 Main Idea

The proposed solution allows delegating authentica-

tion without the use of signatures and without the help

of a Secure Socket Layer (SSL). Thus it is possible

to authenticate the user on non-secure networks with-

out the need to synchronize user credentials with ser-

vices. Our system involves three actors including the

IdP, the client and the SP. Nevertheless, a phase of en-

rollment must be pre-established between the client

and the IdP as well as a phase of establishing a trust

relationship between the IdP and the the SP. Theses

phases mainly consist in exchanging identiﬁcation in-

A New Delegated Authentication Protocol based on PRE

469

Figure 1: Main actors and interactions of our protocol.

formation as well as pre-shared keys. The Figure 1

shows the different actors, interactions and the differ-

ent information necessary for our protocol. The secret

data are presented in the tables in red background. We

don’t need to store any user-related information on the

side of service providers.

• User ←→ SP:

• 0.0 : The user asks the list of IdPs trusted by

the SP.

• 0.1 : The SP returns the corresponding list.

• User ←→ IDP:

• 1.0 : The user chooses the IdP, creates an au-

thentication request and sends it to the corre-

sponding IdP.

• 1.1 : The IdP veriﬁes the validity of the request,

authenticates the user and then responds with

the authentication token.

• User ←→ SP:

• 2.0 : The user creates an ephemeral token, adds

it to the received one and authenticates with the

SP.

• 2.x : At each connection the user resumes 2.0

with a slight modiﬁcation.

Once enrollment and trust establishing phases are

completed, we can authenticate the users to the SP

without the need of direct communication between

the IdP and the SP with the least amount of interaction

possible (1). Also, it allows the user, once authenti-

cated, to use any service that trusts this IdP (2) and to

not need to store any information about the client on

the SP side (3). In order to do so, we will need to use

PRE as a core technology.

In the literature, it is hard to ﬁnd an efﬁcient so-

lution that combines these three advantages. For ex-

ample, OpenId needs a direct interaction between the

IDP and the SP, it involves at least ﬁve interactions

and uses JWT which are signed using a secret with

the HMAC algorithm or a public / private key pair us-

ing RSA or ECDSA. The security model in any case

relies on the random oracle model. A signature is

by design based on Non-Interactive Zero Knowledge

(NIZK) protocol. These protocols are either secure in

the standard model but inefﬁcient or practically efﬁ-

cient and usually built from the Fiat-Shamir heuristic

which are secure in the random oracle model. Thus,

we have decided to exclude the use of signatures and

thereby create a protocol that could rely on crypto-

graphic schemes that are proved to be secure in the

standard model while maintaining a good level of ef-

ﬁciency. Of course, there is always a compromise be-

tween performance in terms of time, storage and level

of security.

There are several solutions that reduce the stor-

age and complexity of information management re-

lated to identiﬁcation, such as accumulators. This

cryptographic scheme was proposed as a decentral-

ized alternative to digital signatures in the design of

secure distributed protocols (Benaloh and De Mare,

1993). For veriﬁcation of membership in the conven-

tional method a trusted third party digitally signs each

member’s IDs and distributes its public key. To verify

SECRYPT 2021 - 18th International Conference on Security and Cryptography

470

Figure 2: Main actors and interactions of a proxy re-

encryption scheme.

a user’s membership it is sufﬁcient to provide their

signed identity while the public key is accessible to

everyone (even non-members can check it). While

using an accumulator, it could be initialized and dif-

fused by a member of a group and not necessarily by a

trusted third party, the members exchange their identi-

ﬁcation information then each one calculates his wit-

ness and the accumulator. The latter may not be kept

since it can be calculated. For static accumulators

the group members cannot change which is restric-

tive, whereas with dynamic accumulators we can add

and revoke members of the group. But the present

development of the latter schemes does not allow an

actual use (Tremel, 2013).

3.2 PRE Background

Proxy Re-Encryption (PRE) allows the delegation of

the decryption rights on Alice’s data only for the in-

tended recipients (we will also refer to Alice as the

delegator and Bob as the delegate). The ﬁrst scheme

was proposed by Blaze, Bleumer, and Strauss (Blaze

et al., 1998). Their goal was to avoid that the data

must be recovered, decrypted then encrypted with the

delegate’s key. And thus, relying on a semi-trusted

proxy that converts the ciphers using re-encryption

keys created by the delegator as illustrated in Figure

The major disadvantage of their scheme is that Al-

ice’s delegation to Bob automatically allowed Bob’s

delegation to Alice. This will later be called bidirec-

tional PRE. This property is due to the fact that re-

encryption keys were created using the private keys

of the two actors. Y.Dodis (Ivan and Dodis, 2003)

formalizes the design of proxy re-encryption schemes

by categorizing these systems in two types: unidi-

rectional and bidirectional. Later, Ateniese (Ateniese

et al., 2006) gives a more formal deﬁnition for PRE

and deﬁnes concretely the properties. We deﬁne be-

low the properties that we consider to be critical to the

completion of our solution:

• Unidirectional: Delegation of decryption rights

from Alice to Bob does not allow Alice to decrypt

Bob’s cipher.

• Non-interactive: The re-encryption key can be

generated by Alice without interacting with Bob

and thus using only Bob’s public key.

• Collusion-safe: If the proxy and Bob collude, they

should not get Alice’s secret key.

• Non-transitive: The proxy can not re-delegate re-

encryption rights. (e.g. from Rk

a→b

and Rk

b→c

the proxy can not calculate Rk

a→c

)

• Non-transferable: The proxy and delegates can

not redeﬁne decryption rights. (e.g. from Rk

a→b

and Pk

and Sk

we can not calculate Rk

a→c

)

• Key-private: This means that by using the re-

encryption key it is not possible to recover the

public keys of both the delegate and the delega-

tor.

In 2008 (Canetti and Hohenberger, 2007) propose the

ﬁrst bidirectional CCA secure PRE scheme where

they prove the security of his scheme using the Uni-

versal Composability framework (Canetti, 2001). In

(Deng et al., 2008), the authors deal with the open

problem presented by Canetti (Canetti and Hohen-

berger, 2007) concerning the construction of a CCA

secure PRE without pairing. Ateniese in (Ateniese

et al., 2009) formalizes the notion of key privacy.

Their construction is single-use CPA secure. (Chow

et al., 2010) conduct a CCA attack on the Shao’s sys-

tem (Shao and Cao, 2009) and show how to ﬁx the

issue. They proposed their own scheme without using

pairing and relying only on ElGamal and the Schnorr

signature. This scheme was implemented in (Sbai

et al., 2019) and used as a service for data sharing.

(Selvi et al., 2017) ﬁnd a ﬂaw in the security proof of

Chow’s construction and propose to ﬁx it. The sys-

tem is unidirectional CCA secure in the random ora-

cle model. (Zhang et al., 2013) proposed a unidirec-

tional PRE scheme that has been claimed to be CCA

secure without relying on pairing nor random oracles.

In (Sbai et al., 2020) we ﬁrst show that the proposal of

(Zhang et al., 2013) is not CCA-secure, then we con-

struct the ﬁrst CCA secure PRE in the standard model

that does not use pairing.

In (Nunez et al., 2012) authors propose a solution

for privacy preserving in the context of OpenID AX

that is based on PRE, where the attributes are stored

encrypted. Thus, the user must create a re-encryption

key for each RP that will allow the OP to re-encrypt

the stored attributes for the RP. The same idea could

be applied for Shibboleth or SAML. So it is an extra

layer to guarantee the privacy.

A New Delegated Authentication Protocol based on PRE

471

3.3 The Proposed Protocol

The Figure 1 illustrates the different communications

required to authenticate a user as well as the informa-

tion to be stored within each entity that we will detail

below.

As mentioned before an enrollment phase is nec-

essary where the IdP would have stored the client’s

identiﬁer e.g. id and the secret to authenticate it e.g.

v . We have taken as an example the identiﬁer/secret

for identiﬁcation to illustrate our protocol (see Table

1) but other identiﬁcation methods can be used such

as biometrics. For services at the time of trust es-

tablishment the IdP should have generated a secret

asymmetric key pair (pks/sks) in addition to its own

asymmetric public/private key pair (pki/ski). The se-

cret asymmetric key pair will be used to create an au-

thentication token and re-encryption keys to the ser-

vice concerned; the other key pair will be used to ver-

ify the validity of user’s authentication request. In-

stead of using a pre-shared secret symmetric keys be-

tween the IDP and the SP in order to verify the ori-

gin of the tokens. We use an asymmetric secret pair

key known only by the IDP, through which we gener-

ate a re-encryption key from IDP to the correspond-

ing SP. As shown in Table 2 the IdP will then have

stored for each service its public key as well as the

re-encryption key generated for it. The use of a PRE

scheme that is key private is then essential. This pre-

vents the public key from being reconstructed through

the re-encryption key and thus keeping the asymmet-

ric key pair secret. On the service side it should have

stored this re-encryption key as well as the public key

of this IdP (see Table 3). The service in turn may have

established trust with other IdPs.

Table 1: Users credentials stored by the IDP.

C1 C2 C3 ... Cn

id1 id2 id3 ... idn

v1 v2 v3 ... vn

Table 2: Public, re-encryption and secret asymmetric pair

keys stored by the IDP.

S1 S2 ... Sn Services

pkp 1 pkp 2 ... pkp n pks/sks

s→p1

s→p2

... rk

s→pn

Table 3: Public and re-encryption keys information stored

by the SP.

I1 I2 I3 ... In

pki 1 pki 2 pki 3 ... pki n

s1→p

s2→p

s3→p

... rk

sn→p

We describe below the technical outlines of the proto-

col using Figure 3:

• 1.0: Pick r

←− {0, 1}

then Auth req =

Enc(pki,id||v||r) .

• 1.0 → 1.1: Dec(ski,Auth req), and verify the va-

lidity of id & v.

• 1.1: Auth token = Enc(pks,scope) ; scope =

(timestamp||expire date||r).

• 2.0: E ph token = Enc(pkp, pki||r) ; Auth resp =

Auth token||E ph token.

• 2.0 → 2.x: Dec(skp,Re-

Encrypt(rk

s→p

,Auth token));

Dec(skp,E ph token) then verify the validity

of the scope and r.

• 2.x: Auth token||Enc(pkp, pk i||r + x ).

First of all, the user asks the SP for the list of trusted

IdPs (0.0). The SP then returns its list of known

IdPs(0.1). The user chooses the corresponding IdP

and sends an authentication request (Auth req) which

contains information related to his identiﬁcation and

a random coin all encrypted with the IdP’s public

key(1.0) in order to collect the authentication token

(Auth token). The IdP, upon receiving the Auth req,

deciphers it and veriﬁes the validity of the informa-

tion. If it corresponds to some user, the latter creates

an Auth token by encrypting a scope containing pri-

marily a timestamp, expiry date and the random coin

created by the user(1.1). Other information related to

authorization could be added. However, issues related

to access control are out of the scope of this paper.

For the latter the IdP uses its own secret asym-

metric encryption key intended for services. The user

upon getting his Auth token, will encrypt this time his

random coin with the public key of the SP which cor-

responds to the ephemeral token (E ph token) , con-

catenate it with the Auth token received and send it to

the SP(2.0). The SP veriﬁes the validity of the authen-

tication response Auth resp. It starts by re-encrypting

the ﬁrst part of the response which could also be done

by an independent semi-trusted party. Then the SP de-

crypts the resulting cipher and the second part of the

Auth resp. If the random coin matches, the authenti-

cation is then successful. The SP stores the random

coin until the next connection, the Auth token dur-

ing its term of validity and the number of connections

used with this token. At each connection the user cre-

ates the E ph token by encrypting the incrementation

of the random coin (e.g. at the time of x connection

(2.x) the value of this coin will correspond to r + x

and the Auth token will be still the same.) The SP

will only have to check the existence of this token,

the number of connections related to it and the value

of the random coin.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

472

IDP :

User :

SP :

IDP’s list request

[pki 1, pki 2, ..., pki n]

(1.0) Auth req

(1.1) Auth token

opt

(2.0) Auth resp 0

(2.x) Auth resp x

Figure 3: Proposed protocol sequence diagram.

4 SECURITY ANALYSIS

4.1 Behavioral Study

A secure delegated authentication protocol should

have the following properties : completeness, secu-

rity against forgery attack, security against replay at-

tack and security against ”man in the middle attack”.

Here we will introduce and deﬁne these properties

and show that our proposal is secure.

• Completeness. The delegate (e.g. the SP) is

always able to identify the source of the authenti-

cation response created by the delegator (e.g. the

IdP) and the client (e.g. the user), if the different

actors follow the protocol.

Proof. When the SP receives the authentication

response Auth resp = Auth token||E ph token,

the re-encryption of Auth token =

Enc(pks,scope) will be valid only if it was

created by the IdP. Indeed the IdP is the only

one in possession of pks. The E ph token should

contains the same random coin found in the

scope. Thus if both the user and IdP execute the

protocol strictly, the SP will always identify the

source of the authentication response.

• Security of Forgery Attack. When an attacker

wants to forge a valid token and sends it to the

intended SP, the protocol is able to withstand the

forgery attack.

Proof. To launch a forgery attack, the attacker

must create a valid encrypted message corre-

sponding to Auth token = Enc(pks,scope). Then

create the E ph token which is Enc(pkp, pki||r).

The second part could be created easily by the

attacker since pkp is known. However, the ﬁrst

part that correspond to the Auth token could not

be created unless the attacker knows the secret

key pks.

• Security of Replay Attack. When a token trans-

mission is maliciously repeated by an attacker, the

intended SP deny the authentication request.

Proof. An attacker can obtain a valid to-

ken Auth resp (e.g. Enc(pks,scope) ||

Enc(pk p, pki||r)) by eavesdropping. When

the attacker wants to impersonate the user, the

token obtained corresponds to the cipher of

a random coin r chosen by the user, but the

value of this coin is incremented after each

connection. Therefore, re-transmisting the same

token Auth resp will not result to a successful

authentication. The SP could detect the attack by

storing the last value of the coin and compare it

with the received one.

• Security of Man in the Middle Attack. An

attacker cannot create a valid authentication re-

quest/response on behalf of the different actors.

Proof. According to our protocol, if the attacker

can create a valid authentication request on behalf

of the user e.g. Enc(pki,id||v||r) = Auth req he

must know the authentication information related

to the user. This is impossible because it implies

that he has access to the secret key allowing to

decrypt the Auth req. A second way to conduct

an attack is to create a valid authentication re-

sponse Enc(pks,scope)||Enc(pk p, pki||r) on be-

half of the user. This is also impossible since it

implies that the attacker knows the value of the

random coin chosen by the user. The only way

for the attacker to know this value is to break the

A New Delegated Authentication Protocol based on PRE

473

PRE scheme or to ﬁnd the random coin by a brute

force attack. However, it is impossible to achieve

this in the lifetime of the token because the length

of the random coin is one of the security parame-

ter of our protocol.

4.2 Correctness

At ﬁrst sight we can see that all the communication

is encrypted. An eavesdropper would not be able to

interpret the packets into something human-readable.

This is guaranteed by end to end encryption. Note that

the registration and the trust establishment phases are

done securely.

The use of random coins plays a major role in

our solution. The token by itself cannot authenti-

cate the client but can only conﬁrm its origin; it does

this by keeping secretly the IdP’s asymmetric key pair

pks/sks intended for services. Hence, if re-encryption

is done correctly, we are sure that the token was cre-

ated by the IdP. Nevertheless, anyone could inter-

cept the token and send it to any SP to be authenti-

cated. The use of random coin allows us to ensure

that the user concerned is the entity that made the

authentication request to the IdP. Its incrementation

prevents replay attacks because the value of the coin

will be different for each connection. The only way

for an attacker to pretend to be the user is to guess

the value of the random coin. In addition to that,

it makes it possible to authenticate into SPs anony-

mously. Note that the PRE must have the properties

explained in section 3.2, which are : {Unidirectional,

Non-interactive, Collusion-safe, Non-transitive, Non-

transferable, Key-private}

5 PROOF OF SECURITY

5.1 BAN Logic

Proposed in 1989 by Burrows, Abadi and Needham

(Burrows et al., 1989), it is one of the ﬁrst formal

methods of proof for authentication protocols. It is

based on the beliefs of the trusted parties involved in

the protocols. It allows to study the evolution of these

beliefs following the exchanges between the differ-

ent entities. A veriﬁcation with the BAN logic does

not necessarily imply that no attack on the protocol

is possible. Although, a proof with BAN logic is a

good proof of accuracy for an authentication protocol

based on well-deﬁned assumptions. It allows many

questions to be answered in a formal way and to ex-

clude certain possible attacks and errors.

5.1.1 BAN Logic Terms

A protocol is formalized using the following terms:

• Participants: Each entity or actor involved in the

execution of the protocol is considered as a partic-

ipant and noted by a capital letter.

• Keys: Any symmetric or asymmetric keys used

are taken into account for the proofs of security.

Asymmetric key pair is denoted by (K, K

−1

• Messages: Any cleartext or ciphertext used or

transmitted are taken into account.

5.1.2 BAN Logic Notations

Based on the terms deﬁned above, the protocol is

translated using the following notations and formulas:

• P believes in X: P |≡ X

• P sees X: P X

• P once said X: P |∼ X

• P controls X: P ⇒ X

• The formula X is fresh: #(X)

• P and Q shared a secret key K: P

←→ Q

• P holds the public key K:

7−→ P

• P and Q shared a secret X: P

−

−

5.1.3 BAN Logic Rules

Now that we have deﬁned the terms and the different

existing notations, we can follow certain laws, also

called logical postulate in order to generate new state-

ments.

• Checking the origin of the message:

– For Shared Keys: If P believes that he has

shared a secret key K with Q and sees an en-

crypted message X under this secret key, then

P believes Q once said X.

P |≡ Q

←→ P,P  {X}

P |≡ Q |∼ X

– For Public Keys: If P believes that K is the pub-

lic key of Q and sees a message X signed with

the corresponding private key −K, then P be-

lieves Q once said X.

P |≡

7−→ Q, P  {X}

−1

P |≡ Q |∼ X

SECRYPT 2021 - 18th International Conference on Security and Cryptography

474

– For Shared Secrets: If P believes that he has

shared a secret Y with Q and sees a message X

joint with this secret, then P believes Q once

said X.

P |≡ Q

−

−

P, P  hXi

P |≡ Q |∼ X

• Checking Message Freshness: If P believes that a

message X is fresh and believes that Q once said

X, then P believes that Q believes X .

P |≡ #(X), P |≡ Q |∼ X

P |≡ Q |≡ X

• Checking the Reliability of the Origin: If P be-

lieves that Q controls X and that Q believes X,

then P believes X.

P |≡ Q ⇒ X, P |≡ Q |≡ X

P |≡ X

• Other rules:

– If P sees X and Y then he sees X.

P  (X ,Y )

P  X

– If P sees X joint with a secret Y then he sees X.

P  hX i

P  X

– If P believes that he has shared a secret key K

with Q and sees an encrypted message X under

this secret key, then P sees X.

P |≡ Q

←→ P,P  {X}

P |≡ X

– If P believes that K is his public key and sees a

message X encrypted with K, then P sees X.

P |≡

7−→ P,P  {X}

P  X

– If P believes that K is the public key of Q and

sees a message X signed with the correspond-

ing private key −K, then P sees X.

P |≡

7−→ Q, P  {X}

−1

P  X

Note that this list is not exhaustive. However the

ﬂexibility of the BAN logic allows to add appropri-

ate constructions and rules. There are several exten-

sions of the BAN method such as GNY (Gong et al.,

1990) which adds the notion of possession and non

provenance. This method constructs new logical pos-

tulates different from the BAN and can be applied to

other cryptographic protocols outside the authentica-

tion system. In the context of our proof, we analyze

a system of delegated authentication. Also, the no-

tions of possessions and non-origin have no effect on

our protocol, so we use the logical BAN with a small

modiﬁcation. Some notions that do not exist in the

two logics BAN and GNY have been deﬁnedwhich

integrate elements allowing the interpretation of the

functions of PRE in the BAN and implicitly for the

GNY method too.

5.2 BAN Logic Adaptation

In order to be able to use the logical BAN for the proof

of our protocol, we propose to extend it. Some no-

tions are not formalized and must be included in the

proof such as re-encryption keys and re-encryption.

The new terms we will use to formalize these notions

will be :

• Re-encryption Key: K

A→B

• Re-encryption: {{X}

}

A→B

We also deﬁne new rules for making inferences from

new assumptions using the terms we have just de-

ﬁned.

The re-encryption of a message X encrypted with

the public key from A via a re-encryption key from

A to B corresponds to the encryption of message X

with the public key from B under the condition that

the entity performing the re-encryption knows the re-

encryption key:

P |≡

Q→P

7−−−→ Q, P  {{X}

}

Q→P

P  {X }

The second rule concerns an unusual case that we

used in our protocol where the encryption key will

be secret. We note the secret asymmetric key pair

as +(K,K

−1

). This allows us to verify the authen-

ticity of encrypted messages for well-deﬁned entities.

These entities must have received a re-encryption key

with which they will be able to re-encrypt and then

decrypt the message. If these two processes are valid,

then the encrypted message has been created by the

holder of the secret key. We include this concept in

the following rule:

P |≡ Q ⇒ +K,P  {X}

,P  X

P |≡ Q |∼ X

Thus, we assume that the jurisdiction of participant

Q over his secret asymmetric key pair +(K,K

−1

) is

that P can read the encrypted and plaintext message

allows us to deduce that P believes that Q has said

this message.

A New Delegated Authentication Protocol based on PRE

475

6 PROOF

6.1 Deﬁnition of Goals and Sub-goals of

the Protocol

The ﬁrst part of the authentication process is the vali-

dation of the user’s identity by his IdP. This is done by

encrypting the random value generated by user C with

the secret SP key held by the IdP. Since the identity in-

formation is not disclosed to the SP and the random

value can be intercepted, a second part is required for

the validation of authentication process to the SP. It

consists in encrypting the same random value but this

time by the user to the SP. This can result in a secret

message sharing r. The ﬁrst validation consists in the

fact that the IdP believes that C has shared a secret

with him. The second validation allows the SP to be-

lieve that the same secret has been shared with him by

the IdP.

• Goals:

1 . SP |≡ IdP

−

−

2 . IdP |≡ C

−

−

IdP

These goals make it possible to check whether the IdP

believes he has exchanged a secret with user C (Goal

2.) and if the SP has really exchanged the same secret

with the IdP (Goal 1.).

• Sub-goals:

1.1. IdP |≡ r

1.2. SP |≡ IdP |≡ r

2.1. C |≡ r

2.2. IdP |≡ C |≡ r

In order to SP believes that it has shared a secret with

the IdP, the IdP must believe in the validity of the

shared secret and SP must believe that the IdP be-

lieves in the validity of the shared secret. The same

reasoning applies to the secret exchange between the

IdP and C.

6.2 Deﬁnition of Assumptions

As explained previously, our protocol assumes that

a registration and trust relationship phase is pre-

established. It results in the exchange of a secret mes-

sage between the IdP and the user, which corresponds

to (id, v). Regarding the trust relationship between

the IdP and the SP, it results in the exchange of the

re-encryption key. Thus we assume that the SP holds

the re-encryption key and believes that the IdP con-

trols the secret asymmetric key through which the re-

encryption key was generated. We also assume that

the ”timestamps” are considered valid by the different

entities. The last hypothesis assumes that the IdP be-

lieves that C has control over the randomness it gen-

erates. This hypothesis cannot be applied to the SP

since it has no pre-established relationship with the

user. On the other hand, at the IdP level, the received

random values are always stated with the identiﬁer of

the user in question. We can thus make the following

assumptions :

1. IdP |≡

7−→ IdP

2. SP |≡

7−→ SP

3. SP |≡

S→P

7−−−→ SP

4. SP |≡ IdP ⇒ +K

5. IdP |≡ C

(id,v)

−−−

−−−

IdP

6. IdP |≡ #(T s) ; SP |≡ #(T s)

7. IdP |≡ C ⇒ r

6.3 Proof

• C chooses r

←− {0, 1}

1. C |≡ #(r)

2. C |≡ r (sub-goal 2.1.)

• C sends Auth req = Enc(pki,id||v||r) to IdP :

3. IdP  {(id,v,r)}

Assumption 1 and Formula 3 allow us to deduce

the postulate :

IdP|≡

7−→IdP,IdP{X }

IdPX

4. IdP  (id,v,r)

5. IdP  hri

(id,v)

Assumption5 and Formula 5 allow us to deduce

the postulate : :

IdP|≡C

−

−

IdP,IdPhX i

IdP|≡C|∼X

6. IdP |≡ C |∼ r

7. IdP |≡ #(r) *

Formulas 6 and 7 are used to deduce the following

postulate :

IdP#(r),IdP|≡C|≡r

IdP|≡r

8. IdP |≡ C |≡ r (sub-goal 2.2.)

Assumption 7 and Formula 8 allow us to deduce

the postulate :

IdP|≡C⇒r,IdP|≡C|∼r

IdP|≡C|≡r

9. IdP |≡ r (sub-goal 1.1.)

• IdP sends Auth token to C :

10. C  {r,T

}

• C chooses k

←− {0, 1}

SECRYPT 2021 - 18th International Conference on Security and Cryptography

476

11. C |≡ #(k)

• C sends Auth resp = Auth token||E ph token to

SP :

12. SP  ({r, T

}

,{r,k}

)

13. SP  {r, k}

Assumption 2 and Formula 13 allow us to deduce

the postulate :

SP|≡

7−→SP,SP{X }

SPX

14. SP  (r, k)

15. SP  {r, T

}

• The SP compute Dec(K

−1

,Re-

Encrypt(K

S→P

,Auth token));

Assumption 3 and Formula 15 allow us to deduce

the postulate :

SP|≡

S→P

7−−−→SP,SP{{X }

}

S→P

SP{X}

16. SP  {r, T

}

Assumption 2 and Formula 16 allow us to deduce

the postulate :

SP|≡

7−→SP,SP{X }

PX

17. SP  (r, T

)

Assumption 6 allows us to deduce the postulate :

SP|≡#(T

)

SP|≡#(r,T

)

18. SP |≡ #(r,T

)

Assumption 4 and Formulas 15 and

17 allow us to deduce the postulate :

SP|≡IdP⇒+K

,SP{(r,T

)}

,SP(r,T

)

SP|≡IdP|∼(r,T

)

19. SP |≡ IdP |∼ (r,T

)

20. SP |≡ IdP |≡ (r,T

)

21. SP |≡ IdP |≡ r (sub-goal 1.2.)

Thus, we ﬁnd that the goals we deﬁned were achieved

since the sub-goals derived from it were all achieved.

6.4 Discussion

The main purpose of our protocol is to authenticate a

user to a service provider. However, the BAN model

does not allow us to present this objective directly. In

order to interpret it through the BAN logic, we deﬁned

the elements that allow the user to be authenticated.

The main element is the random value generated by

the user. If the value received from the IdP by the

user is the same that the one exchanged between the

user and the IdP, we consider that the user has been

identiﬁed by the IdP, that his authentication request

has been validated by the IdP and is valid for the SP.

This random value is never revealed in clear text but

sent encrypted to the IdP and to the SP. This value can

then be seen as a secret shared between C and the IdP

and between the IdP and the SP. The same secret is

not considered to be shared directly between C and

SP since only the IdP can verify the identity of the

user. Also, only the IdP can validate C’s authentica-

tion request to the SP, then the deﬁnition of these two

goals is: SP |≡ IdP

−

−

SP & IdP |≡ C

−

−

IdP.

In order to facilitate the sequence of proof, the

deﬁnition of sub-goals makes it possible to simplify

the proof by reducing the number of deductions to be

made, and by deriving the sub-objectives through the

previously deﬁned objectives. For example, in order

to the SP believes that the exchange of the secret is

true between him and the IdP, it is necessary that the

IdP itself believes in the validity of the secret and that

ﬁnally the SP believes that the IdP believes in this se-

cret. Similarly, we have derived the sub-goals from

the second objective.

After the goals and sub-goals were deﬁned, we

presented our assumptions. The two ﬁrst concern

the ownership of public keys by the different entities,

namely the IdP and the SP. We also present the own-

ership of the re-encryption key by the SP, and the en-

cryption key of the IdP for authentication messages

to the SP. We also assume the existence of a secret

shared between the user and the IdP. All our assump-

tions are directly related to the registration phase and

the establishment of a trust relationship. Neverthe-

less, other hypotheses have been presented such as the

trust of different entities to ”timestamps”, speciﬁcally

for IdPs and SPs. For the last hypothesis, we assume

that the value generated by the user is controlled by

the user. Since this value is always associated with

identiﬁers veriﬁable by the IdP then he believes that

this value is really controlled by the user.

Now that the preliminary phases of the logical

BAN have been established then, all that remains is to

follow the evolution of the protocol. Using the differ-

ent rules we have deﬁned we can deduce the different

sub-goals and thus verify that the protocol achieves

the deﬁned goals.

7 CONCLUSION

In this paper we give a brief review of some SSO and

delegated authentication solutions. Then we intro-

duced a new delegated authentication protocol based

on the use of proxy re-encryption. It is considered

as a single sign-on method. Thanks to this protocol

a user can authenticate once, receive the Auth token

from the IdP and use any service that trust the user’s

IdP during the token’s lifetime. Our method is simple

and asynchronous. For the proof of security, we used

A New Delegated Authentication Protocol based on PRE

477

the logical BAN method. This allowed us to model

the protocol in the form of logical postulates and to

prove that our protocol achieves the objectives that

we have deﬁned for it. Thus, we used the predeﬁned

rules of the logical BAN but also new rules that we

integrated to adapt them to the use of the PRE. Au-

thorization issues have not been taken into account in

this work but have been left for futur study. Futur

work will involve the examination of (Nunez et al.,

2012) solution, which include an authorization layer

to propose a complete authentication and access con-

trol framework. We will also implement the solution

and instantiate it with several PREs in order to com-

pare results.

REFERENCES

Alizadeh, M., Abolfazli, S., Zamani, M., Baharun, S., and

Sakurai, K. (2016). Authentication in mobile cloud

computing: A survey. Journal of Network and Com-

puter Applications, 61:59–80.

Ateniese, G., Benson, K., and Hohenberger, S. (2009). Key-

private proxy re-encryption. In Cryptographers’ Track

at the RSA Conference, pages 279–294. Springer.

Ateniese, G., Fu, K., Green, M., and Hohenberger, S.

(2006). Improved proxy re-encryption schemes with

applications to secure distributed storage. ACM Trans-

actions on Information and System Security (TISSEC),

9(1):1–30.

Benaloh, J. and De Mare, M. (1993). One-way accumula-

tors: A decentralized alternative to digital signatures.

In Workshop on the Theory and Application of of

Cryptographic Techniques, pages 274–285. Springer.

Blaze, M., Bleumer, G., and Strauss, M. (1998). Divertible

protocols and atomic proxy cryptography. In Interna-

tional Conference on the Theory and Applications of

Cryptographic Techniques, pages 127–144. Springer.

Burrows, M., Abadi, M., and Needham, R. M. (1989). A

logic of authentication. Proceedings of the Royal So-

ciety of London. A. Mathematical and Physical Sci-

ences, 426(1871):233–271.

Canetti, R. (2001). Universally composable security: A new

paradigm for cryptographic protocols. In Proceedings

42nd IEEE Symposium on Foundations of Computer

Science, pages 136–145. IEEE.

Canetti, R. and Hohenberger, S. (2007). Chosen-ciphertext

secure proxy re-encryption. In Proceedings of the 14th

ACM conference on Computer and communications

security, pages 185–194. ACM.

Chaidos, P. and Couteau, G. (2018). Efﬁcient designated-

veriﬁer non-interactive zero-knowledge proofs of

knowledge. In Annual International Conference on

the Theory and Applications of Cryptographic Tech-

niques, pages 193–221. Springer.

Chow, S. S., Weng, J., Yang, Y., and Deng, R. H. (2010).

Efﬁcient unidirectional proxy re-encryption. In Inter-

national Conference on Cryptology in Africa, pages

316–332. Springer.

Deng, R. H., Weng, J., Liu, S., and Chen, K. (2008).

Chosen-ciphertext secure proxy re-encryption without

pairings. In International Conference on Cryptology

and Network Security, pages 1–17. Springer.

Gong, L., Needham, R. M., and Yahalom, R. (1990). Rea-

soning about belief in cryptographic protocols. In

IEEE Symposium on Security and Privacy, pages 234–

248. Citeseer.

Hardt, D., Bufu, J., and Hoyt, J. (2007). Openid attribute

exchange 1.0-ﬁnal. at, Dec, 5:11.

Ivan, A.-A. and Dodis, Y. (2003). Proxy cryptography re-

visited. In NDSS.

Nunez, D., Agudo, I., and Lopez, J. (2012). Integrating

openid with proxy re-encryption to enhance privacy

in cloud-based identity services. In 4th IEEE Inter-

national Conference on Cloud Computing Technology

and Science Proceedings, pages 241–248. IEEE.

Sbai, A., Drocourt, C., and Dequen, G. (2019). Pre as

a service within smart grid city. In Proceedings of

the 16th International Joint Conference on e-Business

and Telecommunications - Volume 2: SECRYPT,,

pages 394–401. INSTICC, SciTePress.

Sbai, A., Drocourt, C., and Dequen, G. (2020). CCA Se-

cure Unidirectional PRE with Key Pair in the Standard

Model without Pairings. In 6th International Con-

ference on Information Systems Security and Privacy,

pages 440–447, Valletta, Malta. SCITEPRESS - Sci-

ence and Technology Publications.

Selvi, S. S. D., Paul, A., and Pandurangan, C. (2017).

A provably-secure unidirectional proxy re-encryption

scheme without pairing in the random oracle model.

In International Conference on Cryptology and Net-

work Security, pages 459–469. Springer.

Shao, J. and Cao, Z. (2009). Cca-secure proxy re-

encryption without pairings. In International Work-

shop on Public Key Cryptography, pages 357–376.

Springer.

Tremel, E. (2013). Real-world performance of crypto-

graphic accumulators. Undergraduate Honors Thesis,

Brown University.

Zhang, M., Wang, X. A., Li, W., and Yang, X. (2013). Cca

secure publicly veriﬁable public key encryption with-

out pairings nor random oracle and its applications.

JCP, 8(8):1987–1994.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

478