- 149 -

CHAPTER 5

A TEXT-O-GRAPHIC PASSWORD BASED AUTHENTICATION

SCHEME

The graphical password employed in the previous chapter is

similar to Vidoop [128] except that Vidoop displays the challenge images

on a single grid as opposed to multiple grids. The problem of these

category based recognition methods is that password guessing is easy as

anyone who is close to the user can figure out the secret category images

based on the user’s personality. Once the categories are known, it is just

a matter of entering the overlaid numbers to gain access.

This chapter presents a novel graphical password named “Text-o-

Graphic” Password, a concatenation of chosen image and its tag. This

method requires the user to select an image and write a description (tag)

for chosen image so that the increased password strength ensures

utmost security. The tag can easily be recalled upon seeing the image.

The proposed password addresses the graphical password weakness by

providing the additional layer of secret which is very much difficult to

guess. Text-o-Graphic password is proposed with two variations namely

S-27 and i-16 respectively with the respective authentication schemes.

5.1 S-27

S-27 is a novel graphical password which provides a recall based

mechanism to user by allowing him to select image and then set image

related description for easy recall of password. In S-27, the user has to

- 150 -

choose three images as secret and write descriptions (tags) for each

image. The combination of image and tag becomes the user’s password

which provides better strength than other passwords.

Figure 5.1 shows a screen shot of S-27 consisting of Twenty Seven

(27) images which are displayed in the form of three 3x3 image grids.

Figure 5.1 Example Login Page of S-27

To set the password, user is required to choose one image from

each grid and write any pass phrase / tag / description for that image.

These chosen secrets i,e. image number and its tag are written in the

corresponding password fields as shown in figure 5.1 above. So, at the

end of the password selection phase, the user would have chosen three

images along with their tags as his password ‘PWi’. The PWi is strong

compared to only Image or only Text passwords. To login, the user needs

to correctly identify his secret image and enter the corresponding image

number and its tag which is verified for granting access to account. In

the following section the process of Registration and Login will be discuss

- 151 -

in detail. The pre-requisite for S-27 password is that the server should

have an Image database consisting of ‘n’ number of images each with an

image ID. It is suggested to have a large image set to ensure the large

password space.

5.1.1 Registration Process

When a user requests for registration, the server randomly picks

27 images and displays it on client. The user then sets the password as

discussed in 5.1. Once the password is submitted by the user, the

system computes the password by concatenating message-digest of each

tag with the message digest of corresponding image. The concatenation

result is then XORed with the other two grids concatenations. If each

grid image is considered as ‘I’ and its tag as ‘T’ then, the user’s password

will be PWi = h{ [h(t1)||h(I1)] ⊕⊕⊕⊕ [h(t2)||h(I2)] ⊕⊕⊕⊕ [h(t3)|| h(I3)] }. The PWi

is then submitted to the server along with image ID’s of randomly picked

21 images by client.

Upon receipt, the server creates a user profile in the database

which stores the hash of user ID’s, Image portfolio and other registration

details. The image portfolio contains the image numbers sent by the

client during registration. The image numbers serves as pointers to the

images in image database.

- 152 -

5.1.2 Login Process

When a user wants to login, he enters his ID and submits hash(ID)

to the server. After verifying the h(ID), server retrieves the images using

user’s image portfolio and adds 6 additional images by randomly picking

them from the server that makes the total count to 27. The original IDs

of these 27 images are mapped to temporary IDs and these images are

sent to client.

At each login request, the set of these 27 images are randomly

displayed within the grid. So, every time the user gets his password

images at random positions with different numbers. User enters the

image description / tag and the current image numbers of his password

images for all the three grids in order to get authenticated. This means

that in the proposed method, user needs to remember his password

image but not the image number. Moreover, once the user recognizes his

images, he can easily recall what tag he had set with that image. For

better security, it is recommended to use the images which has more

number of objects in it so that user can have more options to set the tag.

5.1.3 The Proposed Scheme

The Scheme consists of three phases namely Registration, Login

and Mutual Authentication & Session Key Agreement. During the

Registration phase the user gets registered with the server and at the end

of the phase the user receives the customized smart card / token. This

phase is invoked only once during the registration of the new user.

- 153 -

During Login & Authentication the client and the server mutually

authenticates each other thus confirming the validity of the

communicating participant. In Session Key Agreement phase, the client

and server agrees on a dynamic session key without the key values being

exchanged between the two. These phases are discussed in detail in the

following subsection:

Registration Phase

It is recommended that the registration phase be executed in

secure environment such as HTTPS. The detailed steps for registering a

user are as follows:

Whenever a new user ‘Ui’ wants to register with the Server ‘S’,

Step R1: Ui submits the registration request to ‘S’ by sending the hash of

his chosen identity i,e. h(IDi).

Step R2: Upon receipt, server checks the availability of h(IDi). If the ID is

available, server sends ‘m’ images to the client. These images are

displayed on n x n image grid, and the user Ui sets his password as

discussed in section 5.1.1.

Step R3: After computation of password, the user system sends PWi to S

through secure communication channel.

Step R4: S computes the following secret parameters:

Qi = h(IDi); Ni = h(PWi ⊕ h(IDi)); Vi = h(h(x) ⊕ h(IDi)) ⊕ Ni;

Step R5: S personalizes the Smart card / Token with {Qi, Vi}. After

completion of offline registration formalities, the Smart Card / Token is

- 154 -

sent to the user through reliable channel.

Login Phase

Whenever a registered user wants to login to access resources at

the server, he inserts the smart card into the reader or attaches the USB

token to the system and proceeds as follows:

The user Ui inserts the smart card and keys his identity IDi.

Step L1: Ui requests for login.

Step L2: Based on the received request, the server generates a random

secret ‘a1’ and then computes ‘A1’ as per the DHKE protocol and sends it

with the login page.

Step L3: The client computes Qi* = h(IDi); checks whether Qi* equals Qi

(stored in smart card); If valid it invokes the DHKE protocol which

generates a random secret ‘b1’ and then computes ‘B1’ as per the

protocol. Using the received value A1 and computed values ‘b1’ and ‘B1’,

the protocol computes the secret key ‘Pi’.

Step L4: It then proceeds to compute Ri = h(IDi) ⊕ h(Pi) and sends Ri, B1

to S.

Step L5: Upon receipt of Ri, B1; server computes Pi, using received B1.

Step L6: The server then computes h(IDi) = Ri ⊕ h(Pi). Checks validity of

h(IDi) and if it is valid, it computes Ti = h(Pi+1);

Step L7: ‘S’ generates another random secret ‘a2’ and then computes ‘A2’

as per the DHKE protocol.

Step L8: Now the server retrieves the user’s portfolio images as discussed

in section 5.1.

- 155 -

Step L9: It sends Ti, Image set and A2 as challenge to user.

Step L10: Upon receipt of Ti, Images and B1, the client verifies the validity

of Ti by computing Ti’ = h(Pi+1); and then checking if Ti’ equals Ti, if valid,

it displays the images. If the validity of Ti fails then the images will not be

displayed on the client and hence the session will get terminated. This

step is very crucial in resisting the Phishing attack as the attacker

cannot reproduce the h(Pi+1) computed using Pi which is never

transmitted in plain text form across the channel.

Step L11: Ui enters his password. The client computes PWii as discussed

in 5.1.1

Step L12: The client computes Vi* = Vi ⊕ h(PWi ⊕ h(IDi));

Step L13: It then generates another random secret ‘b2’ and then

computes ‘B2’ as per the DHKE protocol. Using the received value A2 and

computed values ‘b2’ and ‘B2’, the protocol computes the secret key ‘Pj’.

Step L14: Ci = h(Vi* ⊕ h(Pj));

Step L15: Ui sends Ci, B2 to Server

Mutual Authentication & Key Agreement Phase:

Upon receipt of the login message Ci, B2, server computes Pj, using the

received B2. It then proceeds to verify the login message by computing as

follows:

Step V1: Vi’ = h(h(x) ⊕ h(IDi))

Step V2: Ci' = h(Vi' ⊕ h(Pj))

Step V3: Checks whether Ci' equals Ci. If it does not hold it rejects login

request else both (client & server) proceeds to compute session key for

- 156 -

further communication as SK = h(Vi* ⊕ h(Pi+2) ⊕ h(Pj+1))

The communication thereby between client & server will be encrypted

using this session key.

Password Change Phase

A registered user can change his password by sending password

change request to the server; but for this, he has to first login to the

server. If the login is successful, then both client and server will share

the same session key to encrypt / decrypt further communication. The

password change phase runs in secure environment meaning that all the

communication between client and server is encrypted with the newly

generated authenticated session key.

When the user submits a request for password change, the client

performs the following steps:

Step C1: Client generates a random number Pk and encrypts it with

session key as ESk(Pk).

Step C2: Upon receipt of ESk(Pk), server decrypts it as DSk(Pk) and checks

the freshness of the nonce. If valid it creates Pk+1 and picks a random

set of images for change password. It then encrypts these with Sk

Step C3: Server sends ESk(Image Set, Pk+1)

Step C4: Upon receipt of ESk(Image Set, Pk+1), the client decrypts it as

DSk(Image Set, Pk+1) and checks the freshness of nonce. If valid, it

displays the images

Step C5: User chooses a new password PWi* as discussed in 5.1.1 and

submits to client.

- 157 -

Step C6: Client computes Vi’ = h(PWi* ⊕ Qi*)⊕ Vi*; Replaces Vi (stored in

smart card) with Vi’

Step C7: Client updates the contents of smart card as {Vi’, Qi};

Step C8: It sends encrypted Portfolio and Pk+2 to Server

Step C9: Upon receipt, the server checks for the freshness of random

number and then updates the user profile as discussed in 5.1.1

The important feature of proposed password change phase is that

the client does all the required computations and updates the smart

card. Thus, the computation and communication cost at the server is

drastically reduced. Moreover, the user secret parameter Vi’, which is

important in password verification at client, is never transmitted over the

channel, thus providing the security against interception. All the three

phases are depicted in figures 5.2, 5.3 and 5.4 below:

Figure 5.2 Registration Phase

Client Server

Submits Reg. request by choosing an ID

ID

Verify whether ID is available, If new ID then sends Images

Images

User Chooses password and submits Pwi

Computes Qi = h(IDi); Ni = h(Pwi ⊕ Qi) Vi = h(h(x) ⊕ Qi) ⊕ Ni;

Personalize Smart card with {Vi, Qi} Secure Channel

Smart card

- 158 -

Figure 5.3 Mutual Authentication & Key Agreement Phase

Figure 5.4 Password Change Phase

Client Server

Ri, B1

Images, Ti, A2

h(IDi) =Ri ⊕ h(Pi); Checks the validity of h(IDi) If it is valid then computes Ti = h(Pi+1); It also computes A2 using DHKE

Ci, B2 Vi’ = h(h(x) ⊕ h(IDi), Ci’ = h(Vi’ ⊕ h(Pj)); Checks if Ci' == Ci, If it holds proceeds else rejects login req

SC then computes session key SK = h(h(Pi+2) ⊕ h(Pj+1) ⊕ Vi*)

Common channel

Enters his ID, SC computes Qi* = h(IDi) and checks if Qi* == Qi; if it holds, it computes Ri = Qi* ⊕ h(Pi), Client computes Ti’ = h(Pi+1); Checks whether Ti’ equals Ti, if valid, displays received images; User enters password, client computes Vi* = h(Pwi ⊕ h(IDi)) ⊕ Vi Generates Pj using the received value A2 and computed value ‘b2’ using DHKE. Computes Ci = h(Vi* ⊕ h(Pj))

Generates a secret no. ‘b1’ and computes & sends ‘B1’ as per DHKE algorithm. Computes shared key ‘Pi’

Generates a secret no. ‘a1’ and computes & sends ‘A1’ as per DH- KE algorithm. Computes shared key ‘Ni’

A1

Computes session key Sk = h( h(Pi+2) ⊕ h(Pj+1) ⊕ Vi’)

Client Server

User Submits Password change request by generating random no. Pk. Encrypts it with Sk, Decrypts it and Checks

the freshness of Pk, Picks a random Image Set; Sends Images and Pk+1 in encrypted

ESk(Images, Pk+1) Decrypts as ESk(Images, Pk+1) and verifies the freshness of nonce. Client displays images. User Chooses password and submits. Client computes Vi’ = h(Pwi*⊕Qi*)⊕ Vi*; Replaces Vi with Vi’ Sends encrypted Portfolio Images to Server Updates Smart card with {Vi’, Qi}

Session key encrypted channel

ESk(Pk)

ESk(Images, Pk+2) Checks the freshness of Pk+2, Updates user profile

- 159 -

5.2 S-16

S-27 was proposed keeping the applications of high security in

mind and therefore ensures ‘high security’ and ‘good memorability’. For

Login, though the process of recognizing three password images and

writing their tags appears to be long, but it is a best bet to ensure more

security. For those who want ‘good security’ and ‘high memorability’, an

alternative named S-16 is proposed. Unlike S-27 which has three 3x3

image grids, S-16 has a 4x4 image grid consisting of 16 images as shown

in figure 5.5.

Figure 5.5 Example Login Page of S-16

To set the password, user has to choose one image from the grid

and write any text for that chosen image along with that image number.

The hash of concatenation of text message-digest and image message

- 160 -

digest becomes the user’s password. If ‘T’ is considered as text and ‘I’ as

image then the password computation could be represented as

PWi = h{ [h(t1) || h(I1)]}. Thus this password provides good security and

high memorability as the user has to recognize only one image and enter

its tag. But S-16 will not provide a high security as compared to S-27.

5.2.1 Registration Process

The pre-requisite for this Text-o-Graphic password is same as that

of S-27. But here, it is strongly suggested to have a large image set in

which each image should have multiple objects in order to ensure

complete resistance from guessing and dictionary attacks.

When a user wants to register with i-16, he submits the desired ID.

The server, after checking the availability of ID, picks 16 images

randomly from the database, maps the original ID’s to temporary IDs and

displays it on the client. The user now sets the password as discussed

above. Once the password is submitted by the user, the client system

picks 14 images randomly out of 16 displayed images and sends the

image numbers to the server along with the users password hash.

Upon receipt of the image numbers, the server maps the temporary

IDs to original IDs and then creates a user profile in the database. This

profile stores the users hash(ID), user’s Image portfolio and other

registration details. The user’s Image portfolio consists of numbers which

refers to the corresponding images in the database.

- 161 -

5.2.2 Login Process

When a user wants to login, he submits his ID to the server. Upon

successful verification of ID, the server picks the 14 images from the

user’s image portfolio and picks 2 images randomly from the image

database. The two randomly picked images are excluding the portfolio

images. The server then maps the image’s original IDs to temporary IDs

and sends it to the client. The client system displays the received images

randomly by shuffling the image positions at each login. For login, the

user has to enter the current number of the password image along with

the corresponding tag.

5.2.3 The Proposed Scheme

S-16 scheme is designed to utilize the strength of PKI because in

the last decade, with the tremendous growth in the online and

e-commerce industry the online threats have also increased and since

there was no appropriate clause till then in the Indian Penal Code (IPC)

to drag the cyber criminals in the court of law, the Govt. of India

introduced the Information Technology Act in 2000 (IT Act 2000) [31]

which made PKI as a standard technology with legal validity for online

transactions. In the Act it is described that the online transaction will

have legal validity only if the transactions are done using hash functions

and digital certificate. In India, currently most of the banks offer net

banking but none of the banks provide PKI based authentication so that

the user has the legal proof of performing the transactions.

- 162 -

Therefore, it is inevitable that a PKI based authentication scheme

be proposed to address the current limitations of net banking in India.

S-16 scheme uses the PKI components such as Hash functions and

Digital Signatures to authenticate user, thus ensuring the compliant of

IT ACT.

The scheme consists of three phases namely Registration, Login

and Mutual Authentication & Session Key Agreement. During the

Registration phase once the user registration is completed, the user

receives from the server a customized Smart Card / Cryptographic token

which contains the user’s secret credentials and the Digital Certificate.

This phase is invoked only once during the registration of the new user.

In Login & Authentication Phase the client and the server mutually

authenticates each other by confirming the validity of the communicating

participant. In Session Key Agreement phase, the client and server

agrees on a dynamic session key such that the key secrets are never

exchanged over the channel. These phases are discussed in detail in the

following subsection:

Registration Phase

The Registration Scheme of S-16 is similar to the one discussed in

section 5.1.3 except a small modification done to accommodate the PKI

components. It is recommended that the registration phase be executed

in secure environment such as HTTPS. The detailed steps for registering

a user are as follows:

- 163 -

Whenever a new user ‘Ui’ wants to register with the Server ‘S’,

Step R1: Ui submits the registration request to ‘S’ by sending the hash of

his chosen identity i,e. h(IDi).

Step R2: Upon receipt, server checks the availability of h(IDi). If the ID is

available, server sends ‘m’ images to the client. These images are

displayed on n x n image grid, and the user Ui sets his password as

discussed in 5.2 above.

Step R3: After computation of password, the user system sends PWi to S

through secure communication channel.

Step R4: The user also fills up the registration form and other required

details mandatory for issuance of Digital Certificate.

Step R5: S computes the following secret parameters:

Qi = h(IDi); Ni = h(PWi ⊕ h(IDi)); Vi = h(h(x) ⊕ h(IDi)) ⊕ Ni;

Step R5: S personalizes the smart card file with {Qi, Vi, and the Digital

Certificate}. After the completion of offline work such as user’s

verification process, the authority issues the Smart Card / Token to the

user through reliable channel such as courier.

Login Phase

Whenever a registered user wants to login to access resources at

the server, he inserts the smart card into the card reader or attaches the

USB token to the system and proceeds as follows:

Step L1: Based on Ui’s request for login, server sends the login page.

User submits his IDi

- 164 -

Step L2: The client computes Qi* = h(IDi); checks whether Qi* equals Qi

(stored in the smart card); If valid it generates a random number Pi and

encrypts it with server’s public key (KUb) as EKUb[Pi].

Step L3: It then computes Ri = h(IDi) ⊕ h(Pi) and EKRa[Ri, EKUb(Pi)] using

private key of user (KRa) and sends EKRa[Ri, EKUb(Pi)] to S.

Step L4: Upon receipt of EKRa[Ri, EKUb(Pi)]; server performs decryption

using user’s public key and his own private key respectively as

DKUa[Ri, EKUb(Pi)] and DKRb(Pi).

Step L5: It then computes h(IDi) = Ri ⊕ h(Pi). Checks validity of h(IDi) and

if it is valid, it computes Ti = h(Pi+1);

Step L6: Now the server retrieves the user’s portfolio images as discussed

in section 5.2.

Step L7: It encrypts Ti and Image set using user’s public key and sends

EKUa[Ti, Image Set] as challenge to the user.

Step L8: Upon receipt of EKUa[Ti, Image Set], the client decrypts it using

user’s private key and verifies the freshness of Ti by computing

Ti’ = h(Pi+1); It then checks if Ti’ equals Ti, if valid, it displays the images.

If the validity of Ti fails then the images will not be displayed on the client

and hence the session will get terminated. This step is very crucial in

resisting the Phishing attack as the attacker cannot compute Ti, without

the knowledge of Pi which was never transmitted in plain text.

Step L9: Ui enters his password PWi.

Step L10: The client computes Vi* = Vi ⊕ h(Pwi ⊕ h(IDi));

Step L11: It generates a random secret ‘Pj’.

- 165 -

Step L12: Computes Di = h(Pi+1) ⊕ Pj; and Ci = h(Vi* ⊕ h(Pj));

Step L13: Ui sends Di, Ci to Server

Mutual Authentication & Key Agreement Phase:

Upon receipt of the login message Di, Ci, the server proceeds as follows:

Step V1: Computes Pj = h(Pi+1) ⊕ Di; Vi’ = h(h(x) ⊕ h(IDi))

Step V2: Ci' = h(Vi' ⊕ h(Pj))

Step V3: Checks whether Ci' equals Ci. If it does not hold it rejects login

request else both (client & server) proceeds to compute session key for

further communication as SK = h(Vi*⊕ h(Pi+1) ⊕ h(Pj+1)) and

SK = h(Vi’ ⊕ h(Pi+1) ⊕ h(Pj+1)) respectively.

Password Change Phase

A registered user can change his password by sending password

change request to the server; but for this, he has to first login to the

server. If the login is successful, then both client and server will agree on

the same session key to encrypt / decrypt further communication. The

password change phase runs in secure environment meaning that all the

communication between client and server is encrypted with the newly

generated authenticated session key.

When the user submits a request for password change, the client

performs the following steps:

Step C1: Client generates a random number Pk and encrypts it with

session key as ESk(Pk).

- 166 -

Step C2: Upon receipt of ESk(Pk), server decrypts it as DSk(Pk) and checks

the freshness of the nonce. If valid it creates Pk+1 and picks a random

set of images for change password. It then encrypts these with Sk

Step C3: Server sends ESk(Image Set, Pk+1)

Step C4: Upon receipt of ESk(Image Set, Pk+1), the client decrypts it as

DSk(Image Set, Pk+1) and checks the freshness of nonce. If valid, it

displays the images.

Step C5: User chooses a new password PWi* as discussed in 5.2 and

submits to client.

Step C6: Client computes Vi’ = h(PWi* ⊕ Qi*)⊕ Vi*; Replaces Vi with Vi’.

Step C7: Client updates the contents of smart card as {Vi’, Qi};

Step C8: It sends encrypted portfolio Images and Pk+2 to Server.

Step C9: Upon receipt, the server checks for the freshness of random

number and then updates the user profile as discussed in 5.2.

The important feature of the password change phase is that the

client does all the required computations and updates the smart card.

Thus, the computation and communication cost at the server is reduced.

Moreover, the user secret Vi’, which is important in password verification

at client, is never transmitted over the channel, thus providing the

security against interception. The Registration and Authentication & Key

Agreement Phases are depicted in figures 5.6 & 5.7 whereas the

Password change Phase is same as i-27 discussed in section 5.1.3.

- 167 -

Figure 5.6 Registration Phase

Figure 5.7 Authentication & Key Agreement Phase

Client Server Submits Reg. with chosen ID

ID Verify whether ID is available, If yes then sends Images

Images Chooses password and submits it with other registration details

Pwi Computes Qi = h(IDi); Ni = h(Pwi ⊕ Qi) Vi = h(h(x) ⊕ Qi) ⊕ Ni;

Personalize Smart card with {Vi, Qi, Digital Certificate}

Secure Channel Smart card

Client Server

EKRa[Ri, EKUb(Pi)]

EKUa[Ti, Images]

Performs DKUa[Ri, EKUb(Pi)], DKRb(Pi). It computes h(IDi) = Ri ⊕ h(Pi); Checks the validity of h(IDi); If valid it computes Ti=h(Pi+1); Retrieves Image Set and sends EKUa[Ti, Images]

Di, Ci

Computes Pj = h(Pi+1) ⊕ Di and Vi’ = h(h(x) ⊕ h(IDi)), Ci’ = h(Vi’ ⊕ Pj); Checks if Ci' == Ci, If it holds proceeds else rejects login request

Computes session key SK = h[h(Pi+1) ⊕ h(Pj+1) ⊕ Vi*]

Insecure channel

User enters his ID, client computes Qi* = h(IDi) and checks if Qi* == Qi; if it holds, it generates a random no. Pi, computes Ri = Qi* ⊕ h(Pi) and sends EKRa[Ri, EKUb(Pi)].

Performs DKRa[Ti, Images], Verifies Ti by computing Ti’ = h(Pi+1) if valid, it displays received images, User enters password, client computes Vi* = h(Pwi ⊕ h(IDi)) ⊕ Vi . It generates a random no. Pj, computes Di = h(Pi+1) ⊕ Pj Ci = h(Vi* ⊕ Pj); sends Di, Ci

Computes session key Sk = h[h(Pi+1) ⊕ h(Pj+1) ⊕ Vi’]

- 168 -

5.3 SECURITY ANALYSIS OF S-27 AND S-16

Graphical passwords are considered to be strong comparing to

other knowledge-based authentication methods, but there still exist

weaknesses and threats which cannot be overlooked when proposing a

novel scheme. So, in this section the security of i-27 & i-16 is analyzed

against common attacks discussed in 2.3.2 and 2.7.

Security against Reconnaissance Attack

This attack is already discussed in detailed in section 4.3.1 under

the security analysis of Graphical Password based authentication. Since

the process of displaying the images received by the client from server is

same in S-27 and S-16, the resistance method of such an attack will also

be same.

Security against Replay Attack

S-27 and s-16 schemes provide resistance against replay attack.

The discussion is as follows:

S-27: In this scheme, the parameters which are being transmitted

between client and server include A1, Ri, B1, Ti, A2, Images, Ci and B2

(where A1, A2, B1 and B2 are the public values computed by server and

client respectively as per DHKE to generate random secrets Pi and Pj).

Suppose that if an adversary intercepts all or any of these

messages and try to forge the login by replaying it at later time say ‘T’,

the attack will fail because every time the server receives these, it checks

- 169 -

for the freshness of the message(s) (created using fresh random

numbers). If the server finds that the received parameters were earlier

used, then it terminates the session. Hence, it is proved that S-27 is

secure against the replay attack.

S-16: This scheme is based on PKI where in each time the client

and server create digital signatures and exchange it for mutual

authentication. If the transmitted messages {EKRa[Ri, EKUb(Pi)], EKUa[Ti,

Images], Ci, Di} are intercepted by the attacker who at some later time

tries to replay it will be unsuccessful to do so as the server checks the

freshness of the received messages using the random numbers Pi and Pj.

Security against Insider Attack

As all the user related sensitive information such as user ID, secret

questions etc. in S-27 and S-16 are stored in message digest form, the

scheme allows the resistance against Insider Attack.

Security against Stolen Verifier Attack

Both schemes doesn’t maintain verifier table, they are secure

against stolen verifier attack.

Security against Shoulder Surfing Attack

S-27 & S-16 provides assurance against such attacks because

firstly, the user enters the image number in contrast to clicking the

chosen image. Secondly, the user has to write a tag about the image in a

password field which shows xxxxxx pattern for the entered text. This

- 170 -

method of password entry even captured on camera will not reveal the

user secret. Hence, it is shown that both the schemes are secure against

the shoulder surfing attack.

Provision of User Anonymity

S-27: If the attacker intercepts Ri (from step L4) to violate the user

anonymity and get the knowledge of the user IDi, he will fail in doing so

because Ri is computed by XORing the message digest of IDi with

message digest of the shared random secret Pi. Thus, without the

knowledge of the Pi (which was never transmitted in plain text over

channel); the adversary cannot derive the IDi. Hence, S-27 scheme

provides user anonymity.

S-16: In S-16, if the adversary intercepts the messages EKRa[Ri,

EKUb(Pi)] transmitted in step L3, he can decrypt it using server’s public

key and can try to derive h(IDi) from Ri. Here he will fail because the

computation requires the knowledge of h(Pi) which is unknown to the

adversary. Hence, the adversary cannot make out who the user is.

Therefore, S-16 achieves the user anonymity.

Security against Server Spoofing Attack

S-27: The server spoofing attack will not work on S-27, because to

masquerade as server, the adversary has to replace all computations of

server with its own computations and progress as follows:

- 171 -

In response to the user’s request for login page in Step L1, the

adversary creates A1’ and sends it to client. Upon receipt, the client

performs the computations discussed in Steps L2, L3 and L4 using A1’

and sends Ri, B1 to server. The adversary could compute Ti based on the

Step L6. It then sends to client the parameters Ti, A2 and Image set

captured during registration phase (Recall that the registration phase

runs on HTTPS. So, it is not possible to capture image set from the

registration phase, but here the worst case scenario of breaking the SSL to

get the image set is considered).

Upon receipt of this, the client verifies the received parameters and

displays the images. User then enters the password and client computes

Ci, B2 and sends to masqueraded server (Steps L10 to L15). Upon receipt

of Ci, the attacker may try to login to server by sending Ci to it but he will

fail because, firstly the server will not accept Ci for verification due to

lack of communication with client in earlier steps. Secondly, even if

server accepts Ci for verification, it will fail because server has never

communicated with client with a valid random number in this session.

Hence, attack will fail. Moreover, the adversary will not get any secret

information of the user as Ci is a message digest.

S-16: It resists the server spoofing attack because here the first

message transmitted from client to server contains the random number

as challenge to the server which is encrypted using server’s public key.

This result is then signed with the user’s private key. In the subsequent

transmissions, both the client and server exchange the random numbers

- 172 -

as part of challenge response mechanism which are unknown to the

adversary. Therefore, it is impossible for the adversary to masquerade as

server.

Security against Guessing Attack

The two ways of performing guessing attack on graphical password

was discussed in detail under guessing attack of section 4.3.8. If the

same methods are employed to crack S-27 and S-16, it will be more

difficult than the graphical password because of the following reasons:

The Text-o-graphic password provides high security against

guessing attack because firstly the amount of effort required to guess

three images from set of twenty seven images will be enormous.

Secondly, the amount of effort required for guessing the tags/

descriptions for those three images correctly will again be enormous.

Similarly, in the case of S-16, the attacker have to guess one correct

image out of 16 images and guess the correct tag / description for that

image. Moreover, while implementation, it can be checked that if the

number of failed login attempts exceeds its limit then the account may be

blocked.

Security against Dictionary Attack

Since, as of today there are no such concrete graphical password

dictionaries available, it is highly difficult for the attacker to perform this

attack. Moreover, if the dictionary is created using the reconnaissance

attack discussed above, the attacker has to successfully guess its tags

- 173 -

and associate it correctly to the secret image which is highly difficult in

case if maximum failed attempts restriction is implemented.

Security against Phishing Attack

In the scheme, both the client and server between steps L1 and L4

ensures that both are communicating with valid participants by checking

the freshness of nonce. Therefore, phishing attack cannot be performed

successfully.

Security against Man-in-the-Middle Attack (MITM)

S-27: In this scheme, the random secret Pi is shared between client

and server using DHKE. But DHKE itself is vulnerable to MITM attack

discussed in section 2.1.5 wherein, the adversary intercepts & replaces

the global values A1 and B1 with Z1 to maintain separate random secrets

Pi’ and Pi’’ with client and server respectively.

S-27 resists the MITM attack, because the attack will fail in step

L4 which computes and sends Ri, B1 to server. Here Ri was computed

using the message digest of Pi’ (attackers created random secret Pi’)

which is to be verified at server during steps L5 and L6 in order to send

the password page. But since the adversary sends B1’ instead of B1 to

server to share a different random secret (Pi”), the server could not

recreate the original h(Pi) used in computation of Ri. Hence, the server

could not verify it and therefore rejects the login request suspecting the

malicious activity in the middle.

- 174 -

S-16: This scheme is based on the PKC where in both the client

and server requires digital certificate. S-16 resists the MITM attack; the

details of it are as follows:

Suppose that the adversary intercepted the message EKRa[Ri,

EKUb(Pi)] sent in step L3. He could try to decrypt the intercepted message

using user’s public key as DKUa[Ri, EKUb(Pi)]. He could then replace Ri with

Ri’ to disrupt the services but will fail to do so because the tampered

message is to be encrypted using user’s private key which is unknown to

him. He may also intercept EKUa[Ti, Images], but to decrypt it he requires

the private key of the user which is impossible to get. Hence, MITM will

fail for S-16 scheme.

Security against Impersonation Attack

In S-27, the adversary can intercept the messages Ri, B1 and Ci, B2

sent by the client in steps L4 and L15 respectively, but he cannot modify

it because Ri and Ci are message digests. He cannot replay it at later time

to get access because Ri and Bi are computed using random numbers.

So, the server always checks the freshness of Pi and Pj. Hence, this

attack will fail.

In S-16, the adversary can intercept EKRa[Ri, EKUb(Pi)] and Ci, Di

sent by client in steps L3 and L13 respectively. But since he does not

have the knowledge of Pi and Pj, he cannot modify the intercepted

messages successfully. Therefore, the attack will fail.

- 175 -

Smart Card Loss

If the user’s smart card is lost and goes in the hands of an

adversary, he can try anything including guessing the user’s password,

try logging in to the account or impersonate the legal user to get access

of the resources.

In S-27 and S-16, the smart card contains Vi, Qi and Digital

certificate (Digital Certificate only in case of S-16). The loss of smart card

means that the adversary gets access to Vi and Qi where Qi = h(IDi) which

is not a secret; and Vi is computed as Vi = h(h(x) ⊕ h(IDi)) ⊕ Ni; here to

guess the user’s password, the adversary should have the knowledge of

server’s master’s secret which is not practically possible. Moreover, the

adversary cannot perform impersonation attack without the knowledge of

the user’s password.

Security of Session Key

Known-key security

S-27 provides known-key security as firstly, the key is never

transmitted over the channel during agreement phase, thus providing

resistance from interception. Secondly, the session key SK is computed

in step V3 of the scheme using Vi, h(Pi+2) and h(Pj+1). These parameters

were never transmitted over the channel. Since the session key is

message digest, the adversary cannot derive the parameters. This implies

that, a new key cannot be generated using the past intercepted key.

- 176 -

S-16 achieves the known-key security property. Here the key is

computed in step V3 Using Pi and Pj (generated by client), Vi* (the

resultant value after password verification at client) and Vi’ (the

computation using h(IDi) and h(x) by server). As Pi, Pj and Vi are never

transmitted in plain text form. The adversary cannot compute a new key

with the compromised key.

Forward Secrecy

Suppose that the attacker has the knowledge of ‘x’ and he

intercepted the earlier transmitted session & session key as well. So, in

order to compromise the session & session key, the attacker must

decrypt it using the session key used in that session. The session key in

every session of S-27 is a message digest computed using Vi, h(Pi+2)

(a nonce) and h(Pj+1) (another nonce) and in S-16 computed using Vi’,

h(Pi+1)and h(Pj+1) which were never transmitted over channel, the

attacker cannot create the session key with the knowledge of only ‘x’.

Hence, it is shown that both schemes achieve forward secrecy.

Explicit Key Authentication

As discussed in section 2.3.2, Explicit Key Authentication involves

the assurance of both the Implicit Key Authentication and Key

Confirmation.

- 177 -

Implicit Key Authentication

In the proposed scheme, neither the key nor the secret values used

to compute the key are transmitted in plaintext over the channel.

Therefore, there is no way that a third party could learn the key value

being agreed on.

Key Confirmation

In Steps V1 to V2 of both S-27 and S-16, the client and server

mutually authenticates each other and also shares secret values Pi and

Pj. This shows that only client and server are in possession of the secret

values which are later used in computing the session key. This proves

that Implicit Key Authentication is achieved. Moreover, in step V3 of S-27

and S-16 both client and server assure that both posses the secret

session key which is enough to prove that Key confirmation is achieved.

5.4 EFFICIENCY ANALYSIS OF S-27 & S-16

This section presents the comparative analysis of the efficiency of

S-27 and S-16 in terms of the computational cost, communication cost

and the memory required in smart card & server for each user. In both

the schemes hash functions, XOR operations, random number

generators and encryption functions are used for computations at Client

and the Server. The detailed comparison is given in Table 5.1. It is

assumed that the PWi, nonce, output of hash functions and other

computations etc. are all 128-bit long and the images are of 20 Kb each.

- 178 -

Client Side Computations: In registration phase, S-27 performs

seven hash functions and five XOR / concatenation operations, where as

S-16 performs three hash functions and one XOR / concatenation

operations.

The number of hash and XOR operations in S-27 is more than S-

16 because of the difference in computation of password; refer section

5.1.1 and 5.2 for password computation. The memory required to store Vi

and Qi (the user’s credentials) in smart card is 256 bits in both schemes.

The communication cost for transmitting IDi and PWi from client to

server in both the schemes is also same I,e. 256 bits which is very less in

view of the today’s high speed networks.

In Login, Authentication & key agreement phase, S-27 performs

sixteen hash computations, eleven XOR operations, two random number

generations and two DHKE computations, where as S-16 performs twelve

hashes, eight XOR operations, two random number generations and

three encryption functions. Here also the number of hash and XOR

operations includes the computation of PWi.

The communication cost of authentication includes the capacity of

message transmission involved in the authentication scheme. In S-27,

the transmission cost from client to server is 512 bits for Ri, Ci, B1 and

B2 (S-27) and for S-16, it is 384 bits for EKRa[Ri, EKUb(Pi)], Ci and Di.

The major difference between S-27 and S-16 is the usage of DHKE

and public key encryption for respective schemes to achieve high security

- 179 -

over the channel. Though the number of hash and XOR operations is

more in S-27, it is more efficient in terms of time than S-16 due to the

fact that public key encryption takes more time than DHKE

implementations. This does not means that any of the schemes is weak

in providing transmission security as most of the parameters transmitted

in both the schemes are either encryption results or message digests.

The Password Change phase of S-27 and S-16 are almost same

except the number of hash and XOR computations. S-27 performs eight

hash computations, seven XOR operations where as S-16 performs three

hash and XOR operations. Both the schemes generate one random

number to provide resistance against the replay attack. The transmission

cost for both the schemes is same i,e 540 KB for images and 256 bits for

messages.

Server Side Computations: The registration phase of S-27 and S-16

are same and thus both perform four hash functions and three XOR /

concatenation operations. There are no random number generations or

encryptions involved in the scheme as it is suggested that the

Registration phase is to run in secure environment such as HTTPS.

The memory required to store h(IDi) in the user profile of both the

schemes is 128 bits where as the user image portfolio (consisting of 21

image reference numbers which are pointers to images in database) is

assumed to consume another 128 bits. The communication cost for

- 180 -

transmitting Images from Server to Client in both the schemes is 540 Kb.

This is very less in view of the today’s high speed networks.

In Login, Authentication & key agreement phase, S-27 performs

nine hash computations, five XOR operations, two random number

generations and two DHKE computations, where as S-16 performs ten

hashes, five XOR operations and three encryption functions. Thus, from

the above comparison it can be inferred that server computations of S-16

are more efficient than S-27 because of more number of hash, XOR and

random functions.

The transmission cost of S-27 is 540 K (27x 20 Kb) for images and

384 bits (3x 128) for A1, A2 and Ti, where as the transmission cost for

S-16 is 540 K (27x 20 Kb) for images and 128 bits for EKUa[Ti, Images]

The Password Change phase of S-27 and S-16 are almost same

wherein both the schemes require only three encryption / decryptions

using the generated session key. Thus, in both the schemes the server

will not have much computation in this phase except sending a random

image set to user for setting his password. The efficiency comparison is

summarized in table 5.1 and the symbols used in table are listed below:

E1: Number of hash computations (Th)

E2: Number of Encryptions / Decryptions or DHKE computations (Te)

E3: Number of Random number generations (Tr)

E4: Number of XOR and concatenation operations (Tx)

E5: Memory needed to store user credentials;

E6: Communication cost in terms of transmitting messages and images

- 181 -

Table 5.1 Efficiency comparison of S-27 and S-16

* It includes hash and XOR operations performed to get PWi refer 5.2

5.5 FORMAL VERIFICATION OF S-27

Section 5.5 and 5.6 presents the formal analysis of S-27 & S-16

respectively. It presents the verification source code of the schemes

written in .spdl, and the screen shots of the result. As per the discussion

of section 2.3.3, the Agent model in both schemes has two agents i,e. ‘C’

– Client and ‘S’ – Server. Each agent performs the roles, therefore there

are two roles named after the agents i,e. ‘role C’ and ‘role S’. Role Event is

E1 (Th)

E2 (Te)

E3 (Tr)

E4 (TX)

E5 (Bits)

E6 (Bits)

S-27 7 5 Registration Phase S-16 3

0 NA

1 256 256

S-27 16* 2 2 11* 512 Login, Auth.

& Key Agreement

phase S-16 12* 3 2 8*

-NA- 384

S-27 8* 3 1 7*

Cli

en

t

Password Change Phase S-16 3* 3 1 3*

Nil, as the contents will be updated

540Kb for images and 256 bits for

message

S-27 Registration

Phase S-16 4 0 NA 3

128 (excluding portfolio imges)

540 Kbits

S-27 9 2 2 5 Login, Auth.

& Key Agreement

phase S-16 10 3 0 5

-NA-

540Kbits for images and 384 bits for

message

S-27 3 540Kb and

256 bits

Serv

er

Password Change Phase

S-16

0

3

0 0

Nil, as the contents will be updated

540Kb and 128 bits

- 182 -

role H which is defined to handle the intermediate computations. The

adversary model is also designed considering that the adversary has

complete control of the network. Since Scyther checks for the freshness

and synchronization by default, these attributes also in defined in the

claims. Note that, S-16 requires public key encryption which is declared

here as Ekus function as per the specification of the language.

usertype SessionKey; secret k: Function; const succ: Function; const Fresh: Function; const Compromised: Function; const hash: Function; const XOR: Function; const plus: Function; const compare: Function; protocol StarCompromise(H) { // Read the names of 3 agents and disclose a session between them including corresponding session key to simulate key compromise role H { const a1,a2, A1,A2,Skey, b1,b2,B1,B2,ID,Qi,Ri,Pi,Pj,Vi,Pwd,Images,1: Nonce; var S,C: Agent; read_!H1(H,H, S,C); send_!H2(H,H, (S,{{B1}Pi}k(S,C)), hash(XOR(XOR(hash(XOR(hash(Pwd),hash(ID))),Vi)),hash(Pj)), {b2}B2, {a1}A1,{b1}B1,{{B1}Pi}k(C,S),hash(ID),{XOR(hash(ID),hash(Pi))}k(C,S),hash(plus(Pi,1)),Images,{a2}A2, {b2}B2, hash(XOR(XOR(hash(XOR(hash(Pwd),hash(ID))),Vi)),hash(Pj)) ); # claim_H3(C,Empty, (Compromised)); } } protocol S27(S,C) { role S { const a1,a2, A1,A2,Skey, b1,b2,B1,B2,ID,Qi,Ri,Pi,Pj,Vi,Pwd,Images,1: Nonce; send_1(S,C, {a1}A1 ); read_2(C,S, {b1}B1,{{B1}Pi}k(C,S),hash(ID),{XOR(hash(ID),hash(Pi))}k(C,S)); send_3(S,C, hash(plus(Pi,1)),Images,{a2}A2);

- 183 -

read_4(C,S, {b2}B2, hash(XOR(XOR(hash(XOR(hash(Pwd),hash(ID))),Vi)),hash(Pj)) ); claim_S1(S,Nisynch); claim_S2(S,Niagree); claim_S3(S,Secret,XOR(hash(ID),hash(Pi)) ); claim_S4(S,Secret,hash(plus(Pi,1) )); claim_S5(S,Secret,hash(XOR(XOR(hash(XOR(hash(Pwd),hash(ID))),Vi)),hash(Pj))); } role C{ const a1,a2, A1,A2,Skey, b1,b2,B1,B2,ID,Qi,Ri,Pi,Pj,Vi,Pwd,Images,1: Nonce; read_1(S,C, {a1}A1); send_2(C,S, {b1}B1,{{B1}Pi}k(C,S),hash(ID),{XOR(hash(ID),hash(Pi))}k(C,S)); read_3(S,C, hash(plus(Pi,1)),Images,{a2}A2); send_4(C,S, {b2}B2, hash(XOR(XOR(hash(XOR(hash(Pwd),hash(ID))),Vi)),hash(Pj)) ); claim_C1(C,Nisynch); claim_C2(C,Niagree); claim_C3(C,Secret,XOR(hash(ID),hash(Pi)) ); claim_C4(C,Secret,hash(plus(Pi,1) )); claim_C5(C,Secret,hash(XOR(XOR(hash(XOR(hash(Pwd),hash(ID))),Vi)),hash(Pj))); } } const Alice,Bob,Eve: Agent; untrusted Eve; const ne: Nonce; const kee: SessionKey; compromised k(Eve,Eve); compromised k(Eve,Alice); compromised k(Eve,Bob); compromised k(Alice,Eve); compromised k(Bob,Eve);

Figure 5.8 Screenshot of Verification Result of S-27

- 184 -

5.6 FORMAL VERIFICATION OF S-16

usertype SessionKey; secret k: Function; const Compromised: Function; const hash: Function; const XOR: Function; const plus: Function; const Ekua: Function; const Ekra: Function; const Ekub: Function; protocol StarCompromise(H) { role H { const Pi,Qi,Vi,ID,Pj,Skey,Images,1,Pwi:Nonce; var S,C: Agent; read_!H1(H,H, S,C); send_!H2(H,H, (S, Ekra( XOR( hash(ID),hash(Pi) ), Ekub(Pi) )),Ekua( hash(plus(Pi,1)), Images ),XOR(hash(plus(Pi,1)),Pj),hash( XOR(Pj,XOR( Vi,hash( XOR(Pwi,hash(ID))) ))) ); # claim_H3(C,Empty, (Compromised)); } } protocol S16(S,C) { role C{ const Pi,Qi,Vi,ID,Pj,Skey,Images,1,Pwi:Nonce; send_1(C,S, Ekra( XOR( hash(ID),hash(Pi) ), Ekub(Pi) ) ); read_2(S,C, Ekua( hash(plus(Pi,1)), Images )); send_3(C,S, XOR( hash( plus(Pi,1)),Pj ), hash( XOR(Pj,XOR( Vi,hash( XOR(Pwi,hash(ID))) ))) ); claim_C1(C,Nisynch); claim_C2(C,Niagree); claim_C3(C, Secret,Ekra(XOR( hash(ID),hash(Pi) ), Ekub(Pi))); claim_C4(C, Secret,Ekua( hash(plus(Pi,1)), Images )); claim_C5(C, Secret,XOR( hash( plus(Pi,1)),Pj )); claim_C6(C, Secret,hash( XOR(Pj,XOR( Vi,hash( XOR(Pwi,hash(ID))) ))) ); } role S{ const Pi,Qi,Vi,ID,Pj,Skey,Images,1,Pwi:Nonce; read_1(C,S, Ekra( XOR( hash(ID),hash(Pi) ), Ekub(Pi) ) ); send_2(S,C, Ekua( hash(plus(Pi,1)), Images )); read_3(C,S, XOR( hash( plus(Pi,1)),Pj ), hash( XOR(Pj,XOR( Vi,hash( XOR(Pwi,hash(ID))) ))) ); claim_S1(S,Nisynch); claim_S2(S,Niagree); claim_S3(S, Secret,Ekra( XOR( hash(ID),hash(Pi) ), Ekub(Pi))); claim_S4(S, Secret,Ekua( hash(plus(Pi,1)), Images ));

- 185 -

claim_S5(S, Secret,XOR( hash( plus(Pi,1)),Pj ));#, hash( XOR(Pj,XOR( Vi,hash( XOR(Pwi,hash(ID))) ))) ); claim_S6(S, Secret,hash( XOR(Pj,XOR( Vi,hash( XOR(Pwi,hash(ID))) ))) ); } } const Alice,Bob,Eve: Agent; untrusted Eve; const ne: Nonce; const kee: SessionKey; compromised k(Eve,Eve); compromised k(Eve,Alice); compromised k(Eve,Bob); compromised k(Alice,Eve); compromised k(Bob,Eve);

Figure 5.9 Screenshot of Verification Result of S-16