A Mobile Payment Scheme Using Biometric Identiﬁcation with Mutual

Authentication

Jack Sturgess

and Ivan Martinovic

Department of Computer Science, University of Oxford, Oxford, U.K.

ﬁ

Keywords:

Authentication, Identiﬁcation, Mobile Payment, Biometrics, Mutual Authentication.

Abstract:

Cashless payment systems offer many beneﬁts over cash, but also have some drawbacks. Fake terminals,

skimming, wireless connectivity, and relay attacks are persistent problems. Attempts to overcome one problem

often lead to another—for example, some systems use QR codes to avoid skimming and connexion issues,

but QR codes can be stolen at distance and relayed. In this paper, we propose a novel mobile payment

scheme based on biometric identiﬁcation that provides mutual authentication to protect the user from rogue

terminals. Our scheme imposes only minimal requirements on terminal hardware, does not depend on wireless

connectivity between the user and the veriﬁer during the authentication phase, and does not require the user

to trust the terminal until it has authenticated itself to the user. We show that our scheme is resistant against

phishing, replay, relay, and presentation attacks.

1 INTRODUCTION

Mobile payment systems have evolved rapidly over

recent years, facilitated by advances in technology

and driven by enhanced security and usability (Huh

et al., 2017). One early barrier to adoption was the

need for specialised hardware, where exclusionary

business practices mandated the use of a dedicated

point-of-sale terminal for each payment system. Mer-

chants struggled to support them all, so brand loyalty

and local trends led consumer decisions. This was

resolved by the standardisation of NFC-enabled pay-

ments (near-ﬁeld communication; for short-ranged

connectivity); now, a single terminal can accept pay-

ments made using any NFC-enabled device—whether

it be a payment card, a hand-held device, or a wear-

able device—across various payment systems.

The size, shape, and capabilities of point-of-sale

terminals have also changed, and are continuing to

change. Early terminals had a slit where magnetic

strip payment cards could be swiped to be read;

these were replaced with slots where Chip and PIN

payment cards could be inserted to have their chip

read and unlocked by the PIN (personal identiﬁca-

tion number; a short numerical password). Terminals

typically have a screen where the payment amount is

https://orcid.org/0000-0001-5708-3052

https://orcid.org/0000-0003-2340-3040

displayed, a keypad or touchscreen where the PIN can

be entered, and, for NFC-enabled terminals, a ﬂat sur-

face where the payment device is to be tapped to com-

municate with the NFC module. They need a trusted

execution environment where local cryptographic ma-

terials can be handled and stored securely and a means

to connect securely to a back-end payment server.

Many modern consumer devices satisfy these require-

ments and so can be used as terminals; new tap-

on-phone applications enable smartphones and tablet

computers to accept NFC payments, increasing the

number and diversity of potential terminals and al-

lowing the payment process to be integrated along-

side other vendor services in all-in-one applications—

e.g., restaurant applications that enable waiting staff

to take orders, transfer orders to the kitchen, and han-

dle payments in the same application.

The physical presence of a terminal can give a

false perception of trust to users that the terminal is

legitimate, but a rogue terminal or application can

easily be dressed to look genuine in order to execute

a MITM (man-in-the-middle) attack on unsuspecting

victims. An effective countermeasure to MITM at-

tacks is mutual authentication, where the payment

system must authenticate itself to the user (inasmuch

as it must prove that it is a secure communication in-

terface to a trusted server) before the user is asked to

enter any secret information. This principle has been

deployed in some smartphone applications (Marforio

Sturgess, J. and Martinovic, I.

A Mobile Payment Scheme Using Biometric Identiﬁcation with Mutual Authentication.

DOI: 10.5220/0013498600003979

In Proceedings of the 22nd International Conference on Security and Cryptography (SECRYPT 2025), pages 577-585

ISBN: 978-989-758-760-3; ISSN: 2184-7711

577

et al., 2016) and online banking interfaces (Tanger-

ine, 2017), where a personalised greeting message is

shown to the user before the system requires the pass-

word to be entered. However, we are yet to see such

a feature in point-of-sale terminals in the wild.

It is difﬁcult to prevent skimming and eavesdrop-

ping over wireless channels. The use of NFC can al-

low payment transactions to be initiated and informa-

tion stolen without the user knowing (Francis et al.,

2010; Murdoch et al., 2010) and attempts to limit

its range to reduce the risk have been shown not to

be reliable (Diakos et al., 2013; Kortvedt and Mjol-

snes, 2009). Some payment systems communicate

over a visual channel between the user’s device and

the terminal, giving the user more control over the ex-

change and making it difﬁcult for an attacker to inter-

cept without being noticed. However, these systems

typically encode the information into barcodes or QR

(quick response) codes that can be read and stolen at

long range using a camera with sufﬁciently high res-

olution and then used in a relay attack. Furthermore,

even though a wireless connexion is not required dur-

ing the authentication phase, the user’s device must

frequently connect to the server at other times to re-

quest new tokens since the communication with the

terminal over a visual channel is unidirectional.

The use of biometrics is starting to replace the

PIN to authenticate the user because it requires less

effort from the user—in some cases directly, such as

ﬁngerprint-enabled payment cards, and in other cases

indirectly, where payment cards are provisioned to a

virtual wallet on a smartphone and the user must au-

thenticate to the device using whatever capabilities

it offers to gain access to the virtual wallet. Some

systems (Lee, 2017; Mastercard, 2022) are phas-

ing out cards and devices altogether and instead use

face recognition to identify the user among regis-

tered users and then bill the account associated with

the matched user. However, an unregistered attacker

could abuse this by getting matched to a random user

and causing that user to get billed, so a smartphone

application is required to verify the match, mean-

ing that the user must carry a wirelessly-connected

smartphone, which detracts from the potential usabil-

ity gains that these systems hoped to offer.

In this paper, we encapsulate these common prob-

lems into a set of three system requirements and then

we propose a novel payment scheme that satisﬁes

them. Our scheme leverages biometric identiﬁcation

to maximise convenience for the user and provides

mutual authentication to protect the user from rogue

terminals. We show that our scheme meets these re-

quirements and that it is resistant against phishing, re-

play, relay, and presentation attacks.

2 SYSTEM DESIGN

2.1 System Requirements

The purpose of a payment scheme is to authenticate

a user to a veriﬁer via a point-of-sale terminal to au-

thorise a payment. In addition to this, we want our

scheme to overcome the problems that are commonly

found in existing mobile payment systems. To ensure

that we meet this objective, we derive the following

three system requirements from these problems that

our scheme must satisfy:

• No specialised hardware: the system may only

impose hardware requirements on the terminal

that can be satisﬁed by typical smartphones and

tablet computers, so that the system is simple for

merchants to deploy.

• No user-to-veriﬁer connexion: the system must

not require any device of the user to communicate

directly with the veriﬁer during the authentication

phase, since network connectivity cannot always

be guaranteed.

• No expectation of trust: the user must not be ex-

pected to trust the terminal, and therefore must not

be expected to reveal any secret information to it,

until the terminal has ﬁrst authenticated itself (i.e.,

proved that it is legitimate) to the user.

2.2 System Model

We consider a system model in which a user is mak-

ing a payment at a point-of-sale terminal in a typi-

cal setting (e.g., in a shop). The system consists of

three components: a user (the prover), a point-of-sale

terminal, and a veriﬁer (the back-end payment server

that authorises the payment). The terminal is a com-

mercial off-the-shelf device that the merchant is using

to take the payment; it has a camera, a screen, an in-

put mechanism (e.g., a keypad or a touchscreen), and

an installed application that implements our scheme.

The veriﬁer is an authentication server maintained by

the payment provider and is assumed to be trusted and

secure. We assume that the terminal is registered to

the veriﬁer and that these devices have shared keys

and established a secure channel over which to com-

municate. We assume that all cryptographic materials

are stored securely on their respective devices.

During the enrolment phase, we assume that the

user has a user device, such as a smartphone, that he

uses to enrol into the system and to administer his

account. We assume that there is a secure channel

between the user device and the veriﬁer over which

they exchange materials. We assume that the user is

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

578

able to access a trusted terminal, authenticated using

the aforementioned secure channel, to submit a num-

ber of biometric samples from which his initial user

template can be constructed. We assume that the bio-

metric being used is face geometry, but other traits

could be implemented with due consideration. The

user adds a payment method to his account, chooses a

PIN, and sets a veriﬁcation message.

During the authentication phase, we assume that

there is a visual channel between the user and the ter-

minal, and a secure channel between the terminal and

the veriﬁer. The user interacts only with the termi-

nal. The user initiates the protocol by presenting his

biometric trait to the terminal. We assume that the

integrity of the biometric sample is protected with ap-

propriate liveness detection, as is standard practise in

biometric-based systems. The terminal extracts a fea-

ture vector from the biometric sample and sends it to

the veriﬁer for identiﬁcation. When the veriﬁer iden-

tiﬁes the user, it retrieves the veriﬁcation message as-

sociated with his account and returns it to the termi-

nal, which displays it to the user. The user veriﬁes

the message and enters his PIN to the terminal, which

passes it to the veriﬁer. The veriﬁer checks the PIN

to verify that the identiﬁcation was correct and to au-

thenticate the user. The veriﬁer can then authorise the

payment using the payment method associated with

the account. We assume that the classiﬁer used by

the veriﬁer has a low misclassiﬁcation rate and that,

when a user is correctly identiﬁed and authenticated,

his template can be safely updated using the latest fea-

ture vector to counter the effects of drift (where a bio-

metric trait changes over time, such as due to ageing).

We assume that the veriﬁer will reject simultaneous

authentication sessions that are identiﬁed to be of the

same user to prevent crossover. A visualisation of the

authentication phase is shown in Figure 1.

visual channel secure channel

User

£10

Terminal Verifier

Figure 1: The system model of our scheme during the au-

thentication phase. The user presents his biometric trait(s)

to the terminal

⃝, which extracts a feature vector and sends

it to the veriﬁer

⃝, which attempts to identify the user. The

veriﬁer returns the veriﬁcation message associated with the

account of the nearest matching user to the terminal

⃝,

which displays it to the user to authenticate the terminal to

the user

⃝. The user then enters his PIN to the terminal

⃝,

which sends it to the veriﬁer, which veriﬁes the match to

authenticate the user and then authorises the payment

⃝.

2.3 Threat Model

We consider an adversary that is attempting to make

a payment at the expense of a legitimate user. We as-

sume that the adversary can observe everything that is

shared across the visual channel. We assume that the

adversary can deploy rogue terminals and that these

are dressed to look genuine. Our goal here is to au-

thenticate the legitimate user without leaking any se-

cret information, to facilitate legitimate mobile pay-

ment transactions, and to reject the adversary. We

consider the following six types of attack:

• Phishing Attack: the adversary has deployed a

rogue terminal to trick a legitimate user into re-

vealing his PIN.

• Replay attack: the adversary is attempting to

make a new payment by re-using (eavesdropped)

messages that were previously sent between a le-

gitimate user and the veriﬁer.

• Relay Attack (in-store): a legitimate user is at-

tempting to make a payment at a rogue terminal

that is passing his biometric trait (e.g., a captured

image of his face) to an adversary who is attempt-

ing to use it to authorise a different payment at a

legitimate terminal.

• Relay Attack (skimming): while a legitimate user

is not involved in a transaction (e.g., he might be

commuting on public transport or walking on a

busy street), the proximate adversary is attempt-

ing to capture his biometric trait using a concealed

rogue terminal so as to pass it to a distant accom-

plice who is attempting to use it to authorise a

payment at a legitimate terminal.

• Presentation Attack (particular victim): the adver-

sary has observed the PIN and biometric trait of

a legitimate user in a previous transaction and is

attempting to make a payment by impersonating

that user.

• Presentation Attack (random victim): the adver-

sary is attempting to make a payment as a random

user.

In this work, we concentrate on how the proposed

scheme can be used to defend against these attacks.

We do not consider attacks that take place during

the enrolment phase, attacks on the liveness detection

system, attacks on the veriﬁer, malware, or denial of

service attacks.

A Mobile Payment Scheme Using Biometric Identiﬁcation with Mutual Authentication

579

Table 1: Summary of the cryptographic materials used in our scheme.

Known to Stored Stored

or Inherent on on

Material to User Terminal Veriﬁer Purpose

a (✓) (✓) × payment amount; known at start of session

b ✓ × (✓) biometric feature vector; identiﬁes the user to

the veriﬁer by nearest match

m ✓ × ✓ short alphanumeric string; authenticates the

terminal to the user

PIN ✓ × ✓ short numerical password; authenticates the

user to the veriﬁer

k × ✓ ✓ secret key; secures communication between

the terminal and the veriﬁer

3 SYSTEM ARCHITECTURE

3.1 Cryptographic Materials

During the enrolment phase, the user account is cre-

ated and the user exchanges some materials with the

veriﬁer that are stored securely and later used in the

authentication phase. A summary of these materials

is shown in Table 1.

b is the biometric feature vector. During the enrol-

ment phase, the user submits a number of biometric

samples to a terminal, which extracts feature vectors

and sends them to the veriﬁer, which constructs a bio-

metric template for the user. This template is stored

as part of the user’s account. During the authentica-

tion phase, the user provides a biometric sample to the

terminal. The terminal extracts a feature vector b and

sends it to the veriﬁer to identify the user. It is best

practice for biometric data to be processed locally on

the device that collects it and for only the feature vec-

tor to be transferred, due to the irrevocable nature of

biometric data and the impact that theft may have on

the security and privacy of the user (across this system

and other systems).

m is the veriﬁcation message. During the enrol-

ment phase, the user chooses a recognisable string

and submits it to the veriﬁer. This message is stored

as part of the user’s account. During the authentica-

tion phase, the veriﬁer sends m to the terminal so that

the terminal can authenticate to the user before the

user is asked to reveal any secret information. Since

the adversary can see m when it is displayed, it must

be changed after each use for mutual authentication to

hold. We assume that this is achieved by using seeded

random string generators to generate the same mes-

sages at regular intervals (e.g., every minute) on both

the user device and the veriﬁer to remove the need

for any user-to-veriﬁer connexion—however, this re-

quires the user to carry the user device. We consider

alternative implementations that prioritise usability in

Section 5.

PIN is the PIN. During the enrolment phase, the

user chooses a short (e.g., 4 digits), memorable PIN

and submits it to the veriﬁer. This PIN is stored as

part of the user’s account. During the authentication

phase, the user inputs PIN to authenticate to the veri-

ﬁer. More speciﬁcally, when the veriﬁer has selected

the candidate user that most closely matches b, the

PIN input by the user is used to verify the match.

We assume that the user will enter PIN on the termi-

nal over a physical channel. Alternative implementa-

tions might explore the use of other channels to verify

the match, such as having the user speak PIN over

an audio channel, gesticulate PIN over a visual chan-

nel, or provide some input in response to a challenge

on a user device. In an ideal implementation of the

scheme, only salted hashes of PIN should be stored,

transferred, and compared in order to mitigate any

damage from attacks against the veriﬁer.

k is a secret key shared between the terminal and

the veriﬁer. We assume that this is exchanged as part

of the secure channel and is cryptographically secure.

3.2 Biometric-Based Identiﬁcation

We exploit the property that biometrics can be classi-

ﬁed in a one-to-many manner (i.e., for identiﬁcation

purposes) to enable the user to bypass initially hav-

ing to reveal any concrete information to the termi-

nal. The user presents only his biometric trait to the

terminal—in our case, this is his face, which is freely

observable in public. The user’s account information,

such as his account number, is known only to the user

and the veriﬁer and does not need to be transferred

during the authentication phase.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

580

Biometric classiﬁcation can result in false posi-

tives. If the identiﬁcation task performed by the ver-

iﬁer returns a false positive, this will be caught when

the user is presented with a message that does not

match m. If the user tries to proceed anyway, he will

fail because he does not know the PIN associated with

the mismatched account. For usability, one approach

to resolving this problem could be for the classiﬁer to

return a shortlist of candidate users ordered by how

closely they match b and for the subsequent message

veriﬁcation steps to repeat, iterating through the list,

until the correct m is displayed and veriﬁed. How-

ever, this approach would enable an attacker to col-

lect veriﬁcation messages of near-matching users that

could be used in a phishing attack. Moreover, it would

train users to tolerate false matches. In either case, the

mutual authentication property would be undermined.

For security, the protocol should instead terminate if

the veriﬁcation message is not as expected. The user

can then restart it by presenting to the terminal again

to give the system a fresh opportunity to identify him

correctly.

3.3 Authentication Protocol

During the authentication phase, a visual channel be-

tween the user and the terminal and a secure channel

between the terminal and the veriﬁer are required for

the system to achieve mutual authentication. Figure 2

shows the authentication protocol and the following

steps describe it.

Steps 1 to 2: User Presents Trait to Terminal. The

user approaches the terminal to initiate a payment

transaction in the amount of a. The user presents his

biometric trait to the terminal. The terminal samples

the trait and extracts a feature vector, b.

Steps 3 to 12: Terminal Authenticates to User. The

terminal sends a and b to the veriﬁer over a secure

channel. Nonces are used so that the freshness of

messages can be veriﬁed by the receiver; we assume

that these will take the form of timestamps. The ver-

iﬁer identiﬁes the user by performing a one-to-many

lookup of b amongst the user templates of all users

registered on the system. When the nearest match,

′

, is identiﬁed, the veriﬁer retrieves the account in-

formation of b

′

and gets its veriﬁcation message, m

′

and PIN, PIN

′

. The veriﬁer sends m

′

to the terminal,

which displays it to the user. The user veriﬁes m

′

performing a string comparison against the expected

message, m. This demonstrates to the user that the

terminal is securely communicating with and trusted

by the veriﬁer and so authenticates the terminal to the

user before the user is required to reveal any secret

information.

Steps 13 to 18: User Authenticates to Veriﬁer via

Terminal. The user enters PIN on the terminal,

which sends it to the veriﬁer. The veriﬁer veriﬁes PIN

against the expected PIN

′

. This authenticates the user

as the identiﬁed user to the veriﬁer and enables the

veriﬁer to process the payment of a using the payment

method associated with the identiﬁed user account.

4 SECURITY ANALYSIS

Our scheme meets all of the system requirements. It

requires no specialised hardware: the terminal needs

only a camera, a screen, and a touchscreen or keypad

for input; these requirements can be satisﬁed by any

modern smartphone or tablet, making it easily deploy-

able. The user is identiﬁed and authenticated to the

veriﬁer via the terminal, using a visual channel, with-

out requiring a direct connexion between the user (or

any user device) and the veriﬁer. Finally, the authenti-

cation protocol ensures that the terminal demonstrates

to the user that it is connected to and trusted by the

veriﬁer before the user is required to reveal PIN.

Phishing Attack. For the phishing attack, the adver-

sary attempts to have a legitimate user reveal PIN by

deploying a rogue terminal. At Step 10, the terminal

must display m to the user before the user reveals PIN.

As long as m is changed after each use, the rogue ter-

minal will not be able to achieve this. Therefore, our

scheme provides resistance against phishing attacks.

Replay Attack. For the replay attack, the adversary

attempts to authorise a repeat payment by re-sending

encrypted messages sent between the terminal and the

veriﬁer during a previous transaction. Nonces are in-

cluded in every encrypted message sent over the se-

cure channel to enable their freshness to be checked,

so the attack will fail at Step 5. Therefore, our scheme

provides resistance against replay attacks.

Relay Attack. For the in-store relay attack, the ad-

versary attempts to authorise a different payment by

passing a copy of the legitimate user’s biometric trait.

For the skimming relay attack, the adversary attempts

to have an accomplice authorise a payment by captur-

ing the biometric trait of an oblivious legitimate user.

In each case, owing to the use of a visual channel,

the legitimate terminal being used by the accomplice

is able to validate the authenticity of the user. The

copied biometric will fail the liveness check and be

rejected, so the attack will fail at Step 2. Therefore,

our scheme provides resistance against relay attacks.

Presentation Attack. For the presentation attack on

a particular victim, the adversary knows the victim’s

PIN and attempts to mimic his biometric trait so as to

impersonate him to a legitimate terminal. Biometric

A Mobile Payment Scheme Using Biometric Identiﬁcation with Mutual Authentication

581

visual channel

Present trait

secure channel

Read m’

Send {a + b + n

}

Send {m’ + n

}

Enter PIN

Send {PIN + n

}

Extract b

Generate nonce n

Verify freshness of n

Display m’

Verify m’ == m

Verify PIN == PIN’

Charge a to account

Generate nonce n

Verify freshness of n

Generate nonce n

Verify freshness of n

Find nearest match, b’;

retrieve associated account

information; get m’ and PIN’

Figure 2: The authentication protocol of our scheme.

identiﬁcation is weaker than authentication inasmuch

as the attacker only needs to achieve being matched

nearer to the intended victim than to some other user.

We can minimise this discrepancy by tightening the

decision threshold of the classiﬁer to ensure that the

matching must meet a certain minimum accuracy,

akin to authentication. The tighter this is set, the more

it will increase the FRR (i.e., the greater the gains in

security, the greater the cost to usability). This will

increase the effort required of the adversary. An im-

plementation of the scheme can further increase the

effort required of the adversary by using multiple bio-

metric traits, since he would need to achieve being the

nearest match for all of the traits simultaneously.

For the presentation attack on a random victim,

the adversary simply presents his own biometric trait,

either modiﬁed or not, so that the system matches him

to a random victim in Step 6. We assume that the

adversary is not registered to the system and that a

match is found, even with a tightened decision thresh-

old. The adversary does not know the PIN of the ran-

dom victim, so the attack will fail at Step 17. The

adversary may attempt to perform a brute force guess-

ing attack against the PIN by presenting in the same

manner repeatedly to generate the same victim each

time. An ideal implementation of the scheme should

use common anomaly detection and throttling tech-

niques to defend against guessing attacks.

The ﬁrst of these attacks does not work at scale,

because the adversary must expend effort to obtain the

victim’s PIN, and is defeated by further increasing the

effort (cost) required. The second does work at scale,

but is defeated by the PIN. In each case, our scheme

provides resistance against presentation attacks.

5 DISCUSSION

Convenience. Our scheme enables the user to make

a payment without needing to carry any form of cash,

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

582

payment card, or user device (although he may need

to consult his user device to verify m, depending on

how it has been implemented). Furthermore, since

the user is identiﬁed as part of the process, any rele-

vant status checks can be made automatically against

the information held on record. This means that the

user does not need to carry loyalty cards, discount

coupons, or proof of age or membership—as these

can all be applied upon identiﬁcation.

For security, we have assumed that seeded ran-

dom string generators on the user device and the ver-

iﬁer generate a fresh m every minute. To improve us-

ability, an implementation of the scheme might con-

sider ways to increase the size of the interval between

changes of m to free the user from the requirement

that he must carry a user device during the authenti-

cation phase. This could include the use of message

templates, along with shapes or colours to increase the

message space, so that what needs to be memorised is

more user-friendly, rather than a random string. For

example, the system might allow the user to create or

select a rule pertaining to the structure of an expected

message that is valid for a day, then the veriﬁer would

randomly generate a fresh string every transaction that

satisﬁes the rule so that the user only needs to ver-

ify that it ﬁts the template (e.g., ‘a valid 5-letter word

followed by a green triangle’). The user would then

memorise the rule before a shopping session and not

need to further consult his user device. The adversary

could replay such a message to perform a phishing at-

tack, but not at scale, so the gains in usability may be

worth the risks to security.

Asymmetrical Channel. The visual channel enables

asymmetric communication, as the capabilities re-

quired for sending information are different to those

required for receiving it. Each party can either dis-

play to or read from the channel depending on its ca-

pabilities. This means that there are constraints on

what each party can do to each other and parts of the

system can be restricted to unidirectional communi-

cation. Our scheme leverages this property in Steps 1

and 2, where the user presents his biometric trait and

the terminal can only read it, and in Steps 10 and 11,

where the terminal displays m

′

and the user can only

choose whether or not to verify it.

Contextual Awareness. The capabilities that can be

used to read information from the visual channel can

also collect incidental information from the surround-

ing environment. Depending on its position, the cam-

era on the terminal can capture additional information

around the user that could be used to facilitate ad-

vanced fraud detection techniques, such as verifying

that the terminal is operating in the expected environ-

ment. An implementation of the scheme might lever-

age this property by passing an image of the scene to

the veriﬁer; expected objects, markers, or lighting ef-

fects could be placed in the environment as a form

of signature, or a clock could be placed in the en-

vironment such that the time captured in the image

could be extracted and cross-checked with the times-

tamps used as nonces to strengthen the assertion of

freshness with an independent factor. A sophisticated

adversary could still fabricate the entire environment,

but each step would increase the effort required of the

adversary and present a potential point of failure for

an attack.

Privacy Risk Mitigation. The use of a vi-

sual channel—especially when collecting peripheral

information—poses a risk to the privacy of the user.

Any images sent to the veriﬁer should have their util-

ity weighed against their potential impact on privacy.

Countermeasures to mitigate privacy leakage from

images include reducing the resolution and blurring

unnecessary details before sending. To protect the

biometric data of the user, biometric traits should only

be processed locally on the terminal and should be ob-

scured from any images sent to the veriﬁer.

6 RELATED WORK

Identiﬁcation-based Systems. With regard to the use

of biometric identiﬁcation as part of an authentica-

tion system, some payment providers have trialled the

technique with the promise of improved convenience

for the user. Smile-to-Pay (Lee, 2017), developed by

Ant Financial for AliPay, uses a 3D camera to cap-

ture the user’s facial likeness, perform liveness de-

tection, and identify the user within 2 seconds. The

system then sends a veriﬁcation request to the user’s

smartphone that requires a timely response to verify

the match. Biometric Checkout Program (Mastercard,

2022), developed by Mastercard, operates in a similar

manner, allowing the user to identify himself to the

terminal over a visual channel using either his face

or palm. Both of these systems require a user-to-

veriﬁer connexion to verify the match. To the best of

our knowledge, we are the ﬁrst to propose the use of

biometric identiﬁcation to facilitate mutual authenti-

cation and to do so without requiring a user-to-veriﬁer

connexion.

Visual Channel. With regard to the use of a visual

channel, some existing mobile payment systems have

explored the use of a QR code to pass information

between a user device and the terminal. In Yoyo Wal-

let (Yoyo, 2017), the user must ﬁrst authenticate to

a smartphone application using a PIN and can then

access a QR code that contains tokenised payment in-

A Mobile Payment Scheme Using Biometric Identiﬁcation with Mutual Authentication

583

formation. To make a payment, the QR code is shown

to the terminal over a visual channel and can be used

up to three times before it expires. When the user’s

smartphone next connects to the Yoyo cloud server,

where the user’s virtual wallet is stored, a new QR

code is downloaded. The limited number of uses per

QR code mitigates the damage from theft, but makes

this payment system more dependent than typical tap-

and-pay systems on a user-to-veriﬁer connexion be-

tween transactions. WeChat (WeChat, 2017) and Ali-

Pay (AliPay, 2017), both widely used payment sys-

tems in China, support the use of QR codes and bar-

codes to transfer information. VisAuth (Sturgess and

Martinovic, 2017) embeds information into an image

as a robust watermark to send it over a visual channel.

However, the system state on the user device can be-

come desynchronised from that on the veriﬁer—while

the authors describe this as a beneﬁt, since it unavoid-

ably draws attention to an attack, it can also happen

if the protocol is interrupted at various steps, provid-

ing plausible deniability to an attacker and making

the wider scheme impractical. All of these systems

transfer conﬁdential information over a visual chan-

nel, whereas we transfer authentication information.

Our scheme makes broader use of the visual channel

by observing the user’s biometric trait(s) to identify

him to the veriﬁer, where his payment information is

stored, rather than encoding the payment information

directly into a visual token.

Smart city transport networks, such as Oxford

SmartZone (OxfordBusCompany, 2022), enable bus

tickets to be purchased in advance and delivered as

QR codes to the user’s smartphone application. In-

stead of buying a ticket from the driver, the user

presents the QR code to a terminal on the bus to expe-

dite boarding. In this case, a product, rather than the

user, is being authenticated, so the threat model pri-

marily considers theft. The user can only be logged in

to one device at a time to prevent account-sharing on

multiple devices and the screen contains additional,

animated elements that are veriﬁed by the terminal to

prevent token-sharing using a screenshot.

Mutual Authentication. With regard to mutual au-

thentication, related works in the ﬁeld of mobile cloud

computing have focused on the mutual authentication

of the user device and the veriﬁer in a general setting

without consideration for any other components that

might be involved in the system, such as the point-

of-sale terminal in our case, that also need to be au-

thenticated before the user should be expected to re-

veal any secret information. Dey et al. (Dey et al.,

2018) proposed a scheme that relies on the location

of the user device and the current time at the veriﬁer,

and so requires a persistent user-to-veriﬁer connex-

ion. Other works (Munivel and Kannammal, 2019;

Olakanmi and Oke, 2018; Purnomo et al., 2016) have

proposed schemes in which mutual authentication is

achieved via a trusted third party. These schemes re-

quire there to be a persistent connexion between the

user device and the third party from the start of the

transaction. We have sought to avoid this for the same

reason that we avoid a user-to-veriﬁer connexion.

7 CONCLUSION

In this paper, we proposed and analysed a novel mo-

bile payment scheme based on biometric identiﬁca-

tion that operates over a visual channel. We showed

that our scheme (i) requires no specialised hardware,

imposing only minimal requirements on the terminal

that can be satisﬁed by most commercially available

smartphones and tablet computers, to ease deploy-

ment, (ii) requires no user-to-veriﬁer connexion dur-

ing the authentication phase, such that it remains us-

able regardless of wireless connectivity, and (iii) mu-

tually authenticates the terminal and the veriﬁer to the

user before he is asked to reveal any secret informa-

tion to authenticate himself. We explored the proper-

ties that a visual channel provides and we showed that

our scheme is extensible in various ways depending

on the needs of the wider system in which it is imple-

mented. Furthermore, our scheme provides a num-

ber of conveniences to the user, such as not having

to carry any payment or loyalty cards, and provides

resistance against phishing, replay, relay, and presen-

tation attacks.

ACKNOWLEDGEMENTS

This work was supported by Mastercard and the En-

gineering and Physical Sciences Research Council

[grant number EP/P00881X/1]. The authors would

like to thank these organisations for their support.

REFERENCES

AliPay (2017). Alipay, trusted! In

https://wglobal.alipay.com/products/spot

(https://archive.vn/NU14f).

Dey, S., Ye, Q., and Sampalli, S. (2018). Amlt: A mutual

authentication scheme for mobile cloud computing. In

IEEE International Conference on Internet of Things

(iThings), IEEE Green Computing and Communica-

tions (GreenCom), IEEE Cyber, Physical and Social

Computing (CPSCom), and IEEE Smart Data (Smart-

Data).

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

584

Diakos, T. P., Briffa, J. A., Brown, T. W. C., and Wese-

meyer, S. (2013). Eavesdropping near ﬁeld contactless

payments: A quantitative analysis. In The Journal of

Engineering.

Francis, L., Hancke, G., Mayes, K., and Markantonakis, K.

(2010). On the security issues of nfc-enabled mobile

phones. In International Journal of Internet Technol-

ogy and Secured Transactions.

Huh, J. H., Verma, S., Rayala, S. S. V., Bobba, R. B.,

Beznosov, K., and Kim, H. (2017). I don’t use apple

pay because it’s less secure...: Perception of security

and usability in mobile tap-and-pay. In Workshop on

Usable Security (USEC).

Kortvedt, H. and Mjolsnes, S. (2009). Eavesdropping near

ﬁeld communication. In The Norwegian Information

Security Conference (NISK).

Lee, A. (2017). Alipay rolls out world’s ﬁrst ‘smile

to pay’ facial recognition system at kfc outlet in

hangzhou. In https://www.scmp.com/tech/start-

ups/article/2109321/alipay-rolls-out-worlds-

ﬁrst-smile-pay-facial-recognition-system-kfc

(https://archive.vn/r0yTR).

Marforio, C., Masti, R. J., Soriente, C., Kostiainen, K.,

and Capkun, S. (2016). Evaluation of personalized

security indicators as an anti-phishing mechanism for

smartphone applications. In CHI Conference on Hu-

man Factors in Computing Systems (CHI).

Mastercard (2022). With a smile or a wave,

paying in store just got personal. In

https://www.mastercard.com/news/press/2022/may/with-

a-smile-or-a-wave-paying-in-store-just-got-personal

(https://archive.vn/Rm23Z).

Munivel, E. and Kannammal, A. (2019). New authentica-

tion scheme to secure against the phishing attack in

the mobile cloud computing. In Security and Commu-

nication Networks.

Murdoch, S. J., Drimer, S., Anderson, R., and Bond, M.

(2010). Chip and pin is broken. In IEEE Symposium

on Security and Privacy (S&P).

Olakanmi, O. O. and Oke, S. O. (2018). Mashed: Secu-

rity and privacy-aware mutual authentication scheme

for heterogeneous and distributed mobile cloud com-

puting services. In Information Security Journal: A

Global Perspective.

OxfordBusCompany (2022). Mobile ticketing tech-

nology launched for oxford smartzone. In

https://www.oxfordbus.co.uk/press-release-oxford-

smartzone-app (https://archive.vn/IS3Vk).

Purnomo, A. T., Gondokaryono, Y. S., and Kim, C.-S.

(2016). Mutual authentication in securing mobile pay-

ment system using encrypted qr code based on public

key infrastructure. In IEEE International Conference

on System Engineering and Technology (ICSET).

Sturgess, J. and Martinovic, I. (2017). Visauth: Authentica-

tion over a visual channel using an embedded image.

In International Conference on Cryptology and Net-

work Security (CANS).

Tangerine (2017). Doublesafe: Your picture, your

phrase. In https://www.tangerine.ca/en/security

(https://archive.vn/rjbOp).

WeChat (2017). Wechat pay. In

https://pay.weixin.qq.com/index.php/public/wechatpay

(https://archive.vn/nxbi3).

Yoyo (2017). Yoyo wallet - upgrade your wal-

let. In https://www.yoyowallet.com/support.html

(https://archive.vn/FYksa).

A Mobile Payment Scheme Using Biometric Identiﬁcation with Mutual Authentication

585