LABMFA-MCC: A Lightweight, Risk-Adaptive, Biometric-Bound Multi-Factor Authentication Protocol for Mobile Cloud Computing

Abstract

Mobile cloud computing enables resource-constrained devices to offload storage and computation to remote servers. It involves authentication over an unsecure wireless link, while meeting stringent energy and bandwidth constraints, often with different service providers. Often, the protocols that achieve security requirements are too heavy for mobile devices or are limited to a single server. However, the adaptive risk-aware processes required by mobile platforms typically run on the top of the cryptographic layer rather than within it. This paper presents LABMFA-MCC, a lightweight authentication and key-agreement protocol that binds the credential to a biometric during each login, builds an end-to-end session key between the device and the server using an edge proxy that is intentionally excluded from the key derivation, and permits access to multiple servers through a single offline registration. Contextual risk is scored at the edge and used to raise the authentication posture, demanding a fresh biometric; we present this as a tunable mechanism rather than a calibrated policy. We validated the protocol in ProVerif under three adversary models, complemented by a computational session-key security argument in the Real-or-Random model, and developed a prototype, tested on a standard mobile phone and an x86 host, requiring about 0.88 ms of total processing (including the measured fuzzy-extractor reproduction) and 1744 bits of communication per login, measured with one enrolled user, the server’s constant-time anonymous user search adds about 3.4 µs per enrolled user.

1. Introduction

Mobile cloud computing (MCC) allows resource-constrained devices to offload storage and computation tasks to remote infrastructures, with deployments increasingly often using multiple independent providers via an open wireless channel rather than a single trusted server. In the MCC environment, the security problem is particular and persistent: a device with stringent energy and computational constraints must prove its identity to remote services over a channel an adversary can fully control and maintain that authentication as it moves between providers. Authentication is the most common cause of failure in such systems [1].

Designing an authentication scheme for this setting means balancing three conflicting requirements: resilience against a capable adversary, a computational footprint small enough for mobile devices, and scalability across independent servers. The literature reviewed in Section 2 satisfies these only in part. Verified schemes are predominantly single-server [2,3,4]; those that reach a genuine multi-server setting tend to incur higher computational or communication cost [5,6]; and many lightweight MCC schemes forgo biometrics entirely, relying instead on password-and-token credentials [7,8]. Where verification is performed, it is usually confined to a single tool or adversary model AVISPA [3], Scyther [4,5], or the ROR model [6], so the assurances a mobile deployment most needs, such as security under a lost device or a corrupted intermediary, are seldom established explicitly. And the contextual, risk-aware adaptation that mobile platforms increasingly expect typically sits in a policy layer above authentication rather than within the key-establishment protocol itself [9,10].

This work proposes LABMFA-MCC, a lightweight multi-factor authentication and key-agreement scheme for simultaneously mitigating these drawbacks, not sequentially. Three commitments shape it. The credential is server-verified, and because it cannot be reconstructed without a live biometric, a lost or cloned device is useless on its own. This protection is maintained at every session, not just during a local verification process. The session key is negotiated only between the device and the server. An Edge Authentication Proxy facilitates the exchange and assesses contextual risk, but it is never given key information, so a completely compromised proxy learns nothing about the key. Third, the device registers with an offline authority once and receives cryptographically distinct per-server tokens for multiple servers. Finally, increasing contextual risk increases the requirements for authentication (a challenge-bound step-up that requires a new live biometric capture) rather than the number of factors. The reference implementation is based on X25519 and BLAKE2s, with a prototype on standard hardware that computes a login in about 0.88 ms while transferring 1744 bits, which is roughly one to almost three orders of magnitude lighter than the comparable three factor schemas of Section 5. These rations compare our measured figures with the values each work reports on its own platform and implementation, so they indicate order of magnitude rather than a like for like ranking (Section 5.5).

The contributions are listed below.

• A lightweight biometric-based multi-factor authentication and key agreement technique for mobile cloud computing, where the edge proxy is omitted from key generation and proven able to withstand full proxy compromise.
• A risk-adaptive step-up mechanism that a contextual risk score at or above the threshold into a challenge-bound biometric step-up inside the verified protocol, rather than a separate policy layer, and the device must answer a fresh proxy nonce with a response that only a new live capture can produce. We specify and analyze the mechanism; calibration of its weights and threshold to a chosen operating point, and empirical evaluation of the resulting decisions are deployment concerns left to future work.
• Multi-server access from a single offline registration event, with cryptographically independent per-server tokens, and credential updates done entirely on the device. Token independence protects against the exposure of individual tokens but not against the compromise of server, which stores A_u and could recompute every other server’s token, resistance to server compromise lies outside the threat model.
• Formal verification with the applied-pi-calculus tool ProVerif for 3 adversary models: normal operation, stolen device, and fully compromised edge proxy. We prove perfect forward secrecy, and replay resistance and untraceability by analytical argumentation. The symbolic results are complemented by a computational session-key security proof in the Real-or-Random model, reducing the adversary’s advantage to standard hardness assumptions. Eighteen security queries (Q1-Q18) are machine checked, the six of which cover the step-up of elevated posture.
• We have implemented the prototype on real hardware (Samsung Galaxy A56 and Intel Core i7), and it achieves about 0.88 ms in total computation and 1744 bits of communication per login, and an additional 0.04 ms from the edge proxy. These are per-login figures with one enrolled user.

The remainder of this paper is structured as follows. Section 2 reviews relevant literature and discusses the research gap. Section 3 describes the system and threat models, the cryptographic preliminaries, and the overall protocol. The formal verification is given in Section 4, and the performance evaluation is discussed in Section 5. Section 6 concludes with a discussion and other directions for future research.

2. Related Work

The security of user authentication in mobile cloud computing (MCC) has received ongoing research interest, since a mobile device must establish a cryptographically strong session over an insecure wireless connection while operating under severe computational and bandwidth constraints. For this environment, a protocol must satisfy three conflicting requirements simultaneously: cryptographic strength enough to resist a resourceful adversary, computational efficiency suitable for battery-limited hardware, and architectural scalability for the multi-server topologies typical of real-world cloud deployments. This section reviews the literature on these dimensions and shows the gap that requires LABMFA-MCC.

Lamport [11] laid out the conceptual framework for remote user authentication with his hash-chain one-time-password system that enabled secure login over an untrusted channel. The stolen-verifier vulnerability of that design was later addressed by Das, Saxena, and Gulati [12], whose dynamic identity-based smart-card protocol set a widely referenced benchmark; the noted deficiencies in it, susceptibility to replay attacks, lack of mutual authentication, and absence of forward secrecy have inspired many advancements in subsequent designs. The evaluative framework for these protocols is built on two key elements: the Dolev–Yao adversary model [13], which grants the attacker complete control over the network, and BAN logic [14], a modal calculus used to analyze the beliefs of participants. Dodis, Reyzin, and Smith [15] introduced a strong model for biometric integration. Their fuzzy extractor generates a stable key from a noisy biometric using a public helper string, which allows the user to bind a biometric to a credential without storing the raw template on a server. Bellare and Rogaway defined the computational basis for session-key proofs in the Random Oracle Model [16]. Roman, Lopez, and Mambo [1] later characterized the MCC threat environment and highlighted authentication, access control, and privacy as the main challenges. They explicitly mentioned that single-server approaches are not architecturally suitable for multi-provider clouds.

2.1. Lightweight Two-Factor Authentication for MCC

A significant amount of research is related to two-factor authentication in mobile cloud computing. Abuarqoub [17] proposed hash-and-XOR schemes with little overhead, the former setting performance benchmarks for single server deployment, relying on informal security analyses and do not having a biometric factor or forward secrecy. Mo et al. [18] have done a ROM-based provable-security analysis of a two-factor ECC key-agreement system. Jegadeesan et al. [7] have described about 2.10 ms of calculation and 480-bit transmission with ECC and mutual authentication. But both methods are limited to a single server. Ahmed et al. [19] proposed the adaptability of the session using a dynamic reciprocal protocol; however, the proposed protocol did not incorporate a biometric component or symbolic verification. In a deep-learning-based anomaly-detection approach, Zeroual et al. [20] explored a method that is non-deterministic and does not provide a formal proof of session key, thus rendering it unsuitable for the bounded latency requirement of MCC.

2.2. Three-Factor and Biometric Authentication

Compromise of a smart card made two-factor systems vulnerable to offline dictionary attacks and led to the addition of a biometric third factor. Chen et al. [21] proposed an improved lightweight three-factor protocol for mobile cloud computing (MCC) based on hash operation, XOR, and fuzzy extractor that was explicitly verified in ProVerif and is the closest single-server precursor to LABMFA-MCC. Abbasi et al. [2] have proposed a comprehensive three-factor healthcare cloud security framework based on ECC-256, SHA-256 and fuzzy extractor. This framework has been validated by BAN logic, ROM, and ProVerif, and it satisfies nine out of ten security features that are included as evaluation criteria in this study. Ryu et al. [22] proposed ECC-based three-factor mutual authentication scheme for Telecare Medical Information Systems, and it satisfies most of the ten features analyzed by AVISPA, BAN, and ROR analyses. A multi-factor scheme for mobile cloud computing (MCC) is proposed in Ghazel et al. [3], including edge-assisted session-token management. It was verified in AVISPA and Scyther and requires 768 bits of communication and an estimated 13.24 ms of computation. Although it is beyond the lightweight threshold and focuses on a single server, its idea of delegating tasks to a nearby edge node directly influenced the Edge Authentication Proxy (EAP) in LABMFA-MCC. A significant difference, which we discuss below, is that the EAP here is designed to be secure even if it is completely breached.

2.3. Multi-Server Authentication

Multi-server authentication which allows a registered user to access different cloud providers without returning to the registration center (RC) raises more complex issues with respect to trust distribution and session-key autonomy. Irshad et al. [8] presented an anonymous multi-server key agreement for mobile cloud computing based on Chebyshev chaotic maps without public key infrastructure achieving 2.60 ms and 544 bits under AVISPA. However, the chaotic-map primitive does not have established hardness assumptions, and the system only offers two-factor security. Multi-server access control in mobile cloud computing healthcare was introduced by Roy et al. [23] based on the strong theoretical foundation, focusing on data authorization instead of lightweight mutual authentication. Liu et al. [24] developed a centerless single sign-on scheme for MCC that combines privacy-preserving remote biometric authentication with ECC and a fuzzy extractor. This is the closest precedent of LABMFA-MCC’s multi-server biometric architecture, but its zero-knowledge-proof design has an overhead of approximately 22 ms and no adaptive escalation and ProVerif verification. Shukla and Patel [4,5] proposed ECC-based provably secure multi-factor protocols. The first single server protocol has a time of 600.4 ms, and the second multi-server protocol has a time of 669.8 ms. The multi-server protocol [5] satisfies all ten evaluated properties, and the single-server protocol [4] satisfies eight of them; both are analyzed in the ROM and with Scyther. However, this performance came at a computational cost in the hundreds of milliseconds, two to three orders of magnitude slower than the sub-millisecond performance of LABMFA-MCC.

Yu and Li [25] proposed a blockchain-based decentralized RC alternative that achieved a computation time of 51.535 ms and communication overhead of 1091 bits. Lightweight anonymous authentication is a new research topic at the mobile-edge frontier. Lee et al. [26], Liu et al. [27], and Jia et al. [28] focus on anonymous key agreement in mobile edge computing. The latest advances introduce new primitives, including a physical-unclonable-function factor in [29] and post-quantum multi-factor security for multi-server architectures in [6]. These initiatives are important, but each addresses a part of the problem; none combines lightweight multi-server biometric authentication with risk-adaptive escalation and verification across multiple adversary models, which is the goal of LABMFA-MCC.

2.4. Adaptive and Risk-Based Authentication

Shila and Srivastava [9] explored the concept of enhancing authentication strength based on contextual risk, using CASTRA, a continuous behavioral-biometric trust architecture for mobile services that changes access decisions in real-time. CASTRA is critical for risk-driven adaptive authentication, as it operates above the cryptographic protocol layer and does not create a formal session key. Talasila [10] demonstrated with analytical modeling that context-aware risk-based authentication can significantly reduce breach incidences as compared to static techniques, using device fingerprint, location, and behavioral context as risk indicators. This evidence has direct implications for risk design in LABMFA-MCC, where the edge proxy computes a score from three contextual signals, RS = wL·L + wT·T + wV·V, where L, T, and V denote location familiarity, time regularity, and server sensitivity, respectively. The criterion RS ≥ τ (with τ = 0.40) determines the authentication posture, independent of alternative factors. The difference is important and well articulated: prior adaptive frameworks [9,10] are generalized mobile-service risk systems, which serve as an independent policy layer, detached from any specific key-establishment protocol. LABMFA-MCC integrates the risk-scoring phase with the edge phase of a formally verified, biometric-based key-agreement protocol, thus combining context decision-making and cryptographic authentication into a single mechanism instead of two loosely coupled mechanisms. In a high-risk session, the score triggers a challenge-bound step-up and the device must answer a fresh proxy nonce with a response that only a new live biometric capture can produce, over a cryptographic floor that is biometric-bound on every session.

Table 1 compares surveyed schemes with design dimensions of this work, deployment scale, authentication factors, registration model, contextual adaptivity, and verification technique. LABMFA-MCC addresses an unaddressed combination of multi-server reach, biometric binding, and risk-adaptive operation in multi-model formal verification.

Table 1. Taxonomic comparison of representative MCC authentication schemes.

Scheme	Factors	Multi-Server	Biometric	Offline RC	Adaptive	Verification
Abuarqoub [17]	PW + SC	✗	✗	✗	✗	Informal
Mo et al. [18]	PW + SC	✗	✗	✗	✗	ROM
Jegadeesan et al. [7]	PW + SC	✗	✗	✗	✗	Informal
Ahmed et al. [19]	PW + SC	✗	✗	✗	✗	Informal
Zeroual et al. [20]	ML/anomaly	✗	✗	✗	✗	Empirical
Chen et al. [21]	PW + SC + Bio	✗	✓	✗	✗	ProVerif
Abbasi et al. [2]	PW + SC + Bio	✗	✓	✗	✗	BAN + ROM
Ryu et al. [22]	PW + SC + Bio	✗	✓	✗	✗	AVISPA/BAN
Ghazel et al. [3]	PW + SC + Bio	✗	✓	✗	✗	AVISPA/Scyther
Roy et al. [23]	ABAC	✓	✗	✗	✗	ROM
Liu et al. [24]	PW + SC + Bio	✓	✓	✗	✗	BAN + ROR
Shukla and Patel [5]	PW + SC + Bio	✗	✓	✗	✗	ROM + Scyther
Shukla and Patel [4]	PW + SC + Bio	✓	✓	✓	✗	ROM + Scyther
Yu and Li [25]	PW + SC + BC	✓	✗	✗	✗	Blockchain
Shila and Srivastava [9]	Behav. bio.	✗	✓	✗	✓	Empirical
Talasila [10]	RBA	✗	✗	✗	✓	Statistical
Lee et al. [26]	PW + SC	✗	✗	✗	✗	ProVerif
Liu et al. [27]	PW + SC	✗	✗	✗	✗	ProVerif/BAN
Jia et al. [28]	ID-based	✗	✗	✗	✗	eCK
Qiu et al. [29]	PW + SC + PUF/Bio	✗	✓	✗	✗	BAN
Wen et al. [6]	PW + SC + Bio	✓	✓	✓	✗	ROR
LABMFA-MCC (Ours)	PW + SC + Bio	✓	✓	✓	✓	ProVerif (3 models)/ROR

PW = password; SC = smart card; Bio = biometric; PUF = physical unclonable function; BC = blockchain; RBA = risk-based authentication; ABAC = attribute-based access control; ✓ = provided; ✗ = not provided, not reported.

2.5. Research Gap

This study points to four major limitations. Most of the formally verified, computationally efficient protocols are mostly confined to single server architectures. Secondly, the approaches which achieve true multi-server scalability, namely [5,24] and [6] suffer from high overhead, do not contain a biometric part, or are based on limited verification models. The established adaptable frameworks [9,10] are a policy layer separate from the underlying key-establishment protocol, rather than being an integral part of a lightweight, formally validated MCC authentication exchange. Fourth, none of the evaluated protocols has been subjected to a complete symbolic verification for several different adversary models, most of them describing only a single adversary model with a single tool.

LABMFA-MCC aims to fill those gaps under one umbrella. It integrates a lightweight key-agreement core uniformly bound to biometrics and a risk-adaptive escalation mechanism at the edge, and it retains multi-server access: one offline-RC registration provides cryptographically different, independent tokens to each server. The protocol is proved in ProVerif 2.04 in three adversarial models. The first one is the normal-execution model. The second one is the stolen-device model, where the attacker has full contents of the smart card. The third one is the edge proxy-compromise model, where the attacker has full control of the EAP. The basic secrecy and authentication properties are machine-verified in each case. The perfect forward secrecy and injective agreement is proved by analytical reasoning and machine-verified results. The design results in two architectural properties that differentiate it from the previous work. The master credential can only be unmasked via a live biometric; as such, stolen-device resistance applies uniformly across all sessions, not just a single path. Moreover, because the edge proxy does not take part in key derivation and has no key material, the session key remains confidential even if the proxy is fully compromised. On real hardware, the client-side computation is sub-millisecond, 0.40 ms on a commodity ARM smartphone, and the total computation on the three entities is 0.88 ms; thus, the cryptography cost is a small fraction of a network round trip. The evaluation section provides a complete quantitative comparison of the reviewed protocols.

3. Proposed System

This section gives all the necessary information for easy understanding and explanation about the proposed scheme. It starts with the system model and the architecture of the authentication phase, defines the notions, describes the threat model the design aims to protect against, and presents the cryptographic primitives the construction is built upon. It then describes the LABMFA-MCC protocol phase by phase, listing each message that is sent between the parties.

3.1. System Model

LABMFA-MCC is designed for a mobile cloud computing environment where a user with a resource-limited device authenticates to multiple cloud services through an intermediary at the network edge. Four types of participants are included:

• Mobile User (MU): A mobile phone with a smart card or a secure element containing the credential set {B_u, P_u, TK₁, …, TK_N, G}. The user submits a password and a live biometric at login. The device does client-side cryptography and starts each session.
• Edge Authentication Proxy (EAP): A lightweight computing node at the edge of the network, typically co-located with 5G or multi-access edge computing infrastructure. It checks message recency, computes contextual risk score, directs anonymous pseudonyms to the appropriate server, and transmits traffic. It is deliberate without any token, credential or session key. In the elevated posture, it also issues a step-up challenge nonce, N_E, which is public, and holds the withheld request until the device answers it.
• Cloud Servers (S_j): Autonomous service providers, each registered separately with the user. The server stores the user’s master credential and its own token {A_u, TK_j}, delivered once by the RC over the secure provisioning channel at registration, and is the only entity which authenticates the user and computes the shared session key with the device. Because the login request carries no user identifier, the server identifies the user by matching the login authenticator against its own enrolled credentials (Section 3.6.4).
• Registration center (RC): A completely trustworthy authority that is active only during the first registration of a user and then stays permanently inactive and out of contact with the system.

This arrangement gives rise to two structural features that are consistently observed across the research. The user never talks directly to the cloud; there is always the proxy in between. The session key is created only between the device and the server, deliberately excluding the proxy from the key-derivation process.

3.2. Architecture of the Authentication Phase

Figure 1 shows the relationships among the parties during the authentication process. The device communicates with the proxy over an insecure wireless link, and the proxy connects to the server over the operator’s network. The proxy is best described as semi-trusted: it is trusted to accurately relay information and assess risk, but it is never granted access to key data, thus guaranteeing that even a complete compromise of the proxy does not compromise the integrity of the session key. The server is fully trusted. Only the server verifies the user’s credentials and helps in the key generation. The registration center provides the services to the parties once and then leaves the live system completely.

Figure 1. Architecture of authentication phase.

This design cleanly separates concerns, such that the edge is responsible for latency-sensitive, contextual tasks (freshness, risk, and routing) close to the user while security-critical tasks (credential verification and key agreement) remain end-to-end between the device and the server. The realization of this design at message level is explained in Section 3.6.

The proxy is not needed for mutual authentication or key agreement; the same exchange can run directly between the device and the server, with the freshness check and the risk decision moved to the server. What a separate edge proxy adds is functional. It filters state, replayed, and flooding requests close to their source, before they reach a server where every request costs a full anonymous search; it hosts the risk decision and the step-up round at the edge, so that servers need no per-login context and the extra round trip stays on the short device-edge link; and it gives a single routing point for multi-server access. Edge nodes of this kind are presented in the multi-access edge and 5G deployments, where they are operated by parties that the user does not control. The design therefore assumes the proxy may be compromised and keeps it out of the key derivation, which is the EAP-compromise results that Q9-Q11 and Q16, Q18 establish. Its cost is measured 0.040 ms of processing per login, about 1% of the median end-to-end latency, and no additional bits, since it relays the protocol messages unchanged.

3.3. Notation

Table 2 lists the symbols used in the rest of the sections.

Table 2. Notation used throughout the protocol specification.

Symbol	Definition
MU, EAP, Sj, RC	Mobile user; Edge Authentication Proxy; Cloud Server j of N; registration center (offline after registration)
IDu, PWu, Biou	User identity, password, and biometric sample
(Ru, Pu)	Fuzzy-extractor output: stable biometric key, Ru, and public helper string, Pu
xRC	Long-term master secret of the RC
G, q	Generator and order of a prime-order group for ECDH key agreement
h2, h3, h4, h5, h6	Domain-separated hash functions; the subscript is the input arity/domain tag
PRF	Pseudorandom function (cross-server token derivation)
Gen, Rep	Fuzzy-extractor generation and reproduction algorithms
⊕, p2b(·)	Bitwise XOR; canonical point-to-byte encoding
Au	Master credential, Au = h2(IDu, xRC)
Bu	Masked credential stored on the smart card
TKj	Cross-server token for Sj
CID	Anonymous per-session pseudonym
r1, r2	Ephemeral per-session nonces (MU and server, respectively)
V1, V2	Ephemeral ECDH public values, V1 = r1·G, V2 = r2·G
SK	Session key shared by MU and Sj
M1, M2, M3	Authentication tokens exchanged during login
Ti, ΔT	Timestamp at step i; maximum permitted clock skew
RS, τ, δ	Risk score and decision threshold; biometric matching tolerance
NE, TE, SR, TSR	Step-up challenge nonce and timestamp, and step-up response and its timestamp (elevated posture)

The hash functions h2 to h6 are one function, BLAKE2s, used in five separate domains: the subscript is a domain tag prepended to the input, so that an output produced in one role (for example, the pseudonym CID under h3) can never be accepted in another (for example, the login authenticator M1 under h5); Section 3.5.3 lists which value each domain produces. The PRF is keyed BLAKE2s; keyed with the master credential Au and evaluated at a server identifier, it yields that the server’s token, TKj = PRF(Au, sid(Sj)), and its pseudorandomness are what keeps the tokens of different servers independent.

3.4. Threat Model

The protocol is evaluated against a Dolev–Yao adversary modified to the mobile cloud environment. The adversary’s abilities are assumed to be as follows:

• Full control over the wireless channel. The adversary has no restrictions to eavesdrop, intercept, modify, replay, insert, and discard messages on the connection between the device and the proxy.
• Theft of device. The attacker can obtain the smart card and recover all its information {B_u, P_u, TK_j} but does not have the password, identity, or a working biometric.
• Compromise of proxy. The attacker can take full control of the Edge Authentication Proxy, allowing him to see and change all the data that passes through it.

The design assumes that the adversary is limited in three ways. In the ordinary cryptographic sense, it is initially computationally constrained, it cannot invert or find collisions in hash functions, it cannot solve the elliptic-curve discrete logarithm or the computational Diffie–Hellman problem, and it cannot distinguish a pseudorandom function from a truly random function. These are the hardness assumptions that guide any provably secure protocol; without these, no authentication scheme can provide security guarantees. Secondly, we assume that the biometric is unforgeable: the adversary cannot present a sample Bio_u within tolerance, δ, of the enrolled characteristic without physical access to the user. This assumption is based in practice on the presence of liveness detection at the sensor level to mitigate against spoofed or replayed samples. Third, a design specific assumption rather than a universal stipulation is that the adversary does not compromise the smart card and the registration center simultaneously. This is practically difficult to perform since the RC is offline after registration. Finally, the protocol assumes loosely synchronized clocks across participants: the freshness check, |T_cur − T_i| ≤ ΔT, requires that device, proxy, and server agree on time to within the permitted skew, ΔT. In a multi-provider setting, this is a deployment requirement, met in practice by standard network time synchronization; a party whose clock drifts beyond ΔT would have its timestamps rejected as stale.

3.5. Cryptographic Primitives

The construction rests on five primitives: an elliptic-curve group, a fuzzy extractor, a family of domain-separated hash functions, a pseudorandom function, and bitwise masking. Each is recalled below to the depth the security analysis (Section 4) requires, together with its concrete instantiation and the protocol values it produces. The reference instantiation realizes the group with X25519, the hash family and the pseudorandom function with BLAKE2s, the biometric binding with a fuzzy extractor over the chosen modality, and masking with bitwise exclusive-OR. Throughout, p2b(·) denotes the canonical encoding of a group element to a fixed-length byte string, ‖ denotes concatenation, and ⊕ denotes bitwise exclusive-OR.

3.5.1. Elliptic-Curve Diffie–Hellman

Let ⟨G⟩ be a cyclic group of prime order q generated by a base point G on an elliptic curve over a finite field. Three assumptions are used. The elliptic-curve discrete-logarithm problem (ECDLP): given G and Q = k·G, recovering the scalar k is computationally infeasible. The computational Diffie–Hellman problem (CDH): Given r₁·G and r₂·G for unknown r₁ and r₂, computing r₁·r₂·G is infeasible. The decisional Diffie–Hellman problem (DDH): The tuples (r₁·G, r₂·G, r₁·r₂·G) and (r₁·G, r₂·G, z·G) for random z are computationally indistinguishable the assumption under which the derived key may be treated as pseudorandom. The reference instantiation uses X25519, the Diffie–Hellman function over Curve25519, which offers roughly 128-bit security at a 255-bit field; scalar clamping and the curve cofactor are handled by the standard routine, and p2b(·) returns the canonical 32-byte u-coordinate so that both parties hash an identical encoding of each point. In the protocol each party draws a fresh per-session nonce r₁ at the device, r₂ at the server publishes V₁ = r₁·G and V₂ = r₂·G, and computes the shared secret r₁·r₂·G, obtained as r₂·V₁ on the server and r₁·V₂ on the device. The freshness of r₁ and r₂ makes each session key independent of every other and underlies forward secrecy.

3.5.2. Fuzzy Extractor

A fuzzy extractor [15] turns noisy biometric readings into a stable, uniformly distributed key while tolerating the natural variation between two captures of the same trait. It is a pair (Gen, Rep). Generation, (R_u, P_u) = Gen(Bio_u), outputs a uniformly random key, R_u, and a public helper string, P_u. Reproduction, R_u = Rep(Bio′_u, P_u), recovers the identical key from any fresh sample within tolerance, d(Bio′_u, Bio_u) ≤ δ, where d is the modality’s distance metric and δ the correction radius. Correctness guarantees recovery whenever the distance bound holds; security guarantees that the public helper, P_u, leaves R_u with near-uniform residual entropy; it reveals, at most, a negligible amount of statistical information about R_u, given P_u, when the biometric source has sufficient min-entropy. A standard construction composes a secure sketch, which corrects errors using P_u with a strong randomness extractor, which distils the uniform key. This is what lets LABMFA-MCC bind a credential to the biometric while storing neither the raw biometric nor R_u on any device or server: only the helper P_u, which is safe to expose, is kept.

3.5.3. Cryptographic Hash Functions and Domain Separation

A cryptographic hash, H: {0,1}* → {0,1}ⁿ, is assumed preimage, second-preimage, and collision-resistant, and is modeled as a random oracle in the security analysis [16]. The reference instantiation uses BLAKE2s with n = 256. To keep the protocol’s several hash uses cryptographically independent, every hash carries domain separation: an arity tag, k, is prepended before hashing, so that h_k(x₁, …, x_k):= H(k ‖ x₁ ‖ … ‖ x_k), and the functions h₂, h₃, and h₄, h₅ behave as independent random oracles, an output of one can never be replayed as an output of another. The protocol uses five domain tags: h₂ derives the master credential, A_u; h₃ builds the masked credential (B_u), the pseudonym (CID), and the authenticators (M₂ and M₃); h₄ derives the session key, SK; and h₅ forms the login authenticator, M₁. In the elevated posture, h6 forms the step-up response, SR.

3.5.4. Pseudorandom Function

A pseudorandom function is a keyed family PRF: K × X → Y, whose outputs are, to any adversary lacking the key, computationally indistinguishable from those of a uniformly random function the PRF advantage of any efficient distinguisher is negligible. It is instantiated as keyed BLAKE2s. LABMFA-MCC uses it to derive one independent token per server, TK_j = PRF(A_u, sid(S_j)), keyed by the master credential, A_u, and evaluated at the server identifier, sid(S_j). Because PRF outputs are independent across distinct inputs, possession of one token, TK_j, gives no advantage in predicting the token of any other server; this independence is what makes single-registration, many-server access safe exposure of one server’s token does not weaken authentication to the others.

3.5.5. Bitwise Masking

Bitwise exclusive-OR is used as a perfectly hiding one-time mask. The master credential, A_u, is never stored in the clear; the device instead holds B_u = h₃(ID_u, PW_u, R_u) ⊕ A_u. Because the mask, h₃(ID_u, PW_u, R_u), is the output of a random oracle keyed on identity, password, and biometric key, B_u reveals nothing about A_u to anyone who cannot reconstruct that mask which requires both the password and a live biometric. At login, the device regenerates R_u via Rep, recomputes the mask, and recovers A_u = B_u ⊕ h₃(ID_u, PW_u, R_u). The same mechanism carries password and biometric updates locally, without contacting the registration center.

3.5.6. From Primitives to Protocol Values

The list below collects every cryptographic value that the protocol forms, the primitive that produces it, and its role, making the link between the primitives and the message exchange of Section 3.6 explicit:

• A_u = h₂(ID_u, x_RC): Master credential, bound to the registration-center secret (hash h₂).
• (R_u, P_u) = Gen(Bio_u): Biometric key and public helper (fuzzy extractor).
• B_u = h₃(ID_u, PW_u, R_u) ⊕ A_u: Masked credential stored on the device (h₃ and XOR).
• TK_j = PRF(A_u, sid(S_j)): Independent per-server token (PRF).
• CID = h₃(ID_u, T₁, r₁): One-time login pseudonym (hash h₃).
• V₁ = r₁·G, V₂ = r₂·G: Ephemeral Diffie–Hellman public points (scalar multiplication).
• SK = h₄(TK_j, p2b(r₁·r₂·G), T₁, T₂): Session key (ECDH and hash h₄).
• M₁ = h₅(A_u, TK_j, p2b(V₁), T₁, CID): Login authenticator, device → server (hash h₅).
• M₂ = h₃(SK, T₂, p2b(V₂)): Server authenticator, server → device (hash h₃).
• M₃ = h₃(SK, T₃, CID): Client key-confirmation, device → server (hash h₃).
• SR = h6(Au, TKj, CID, NE, TSR): Step-up response, device → proxy → server, elevated posture only (hash h6).

At login, the device reconstructs A_u = B_u ⊕ h₃(ID_u, PW_u, R_u) after R_u = Rep(Bio′_u, P_u); the server verifies M₁, the device verifies M₂, and the server verifies M₃, after which both hold the same session key, SK.

3.6. The LABMFA-MCC Protocol

3.6.1. Design Rationale

Two commitments shape the construction. First, the session key is established strictly between the Mobile User and the Cloud Server. The proxy accelerates the exchange and scores risk but is never given a value from which the key could be rebuilt; this is why the server, not the proxy, contributes the second half of the key agreement. Second, the credential needed to authenticate is tied to the biometric on every login. The value the server checks cannot be formed without first reproducing the biometric key from a live sample, so a stolen card alone is inert. The risk engine never relaxes this binding; it varies only the posture of the session above all whether a challenge-bound step-up with a fresh biometric capture is required before the request is forwarded. LABMFA-MCC thus offers no credential-only shortcut: the risk score decides how strict a session is, not which factors take part.

Figure 2 provides an end-to-end overview of the three protocol phases. In Phase 1, the registration center performs a single enrolment deriving the master credential, masking it onto the smart card, and issuing independent per-server tokens, it then goes permanently offline. In Phase 2, the Edge Authentication Proxy evaluates the contextual risk score locally and sets the authentication posture; in the elevated posture, it withholds the request and runs the step-up round of Section 3.6.5. In Phase 3, the three-message exchange authenticates both parties and establishes the session key end-to-end between the Mobile User and the Cloud Server, with the proxy relaying each message unchanged and holding no key material. In the figure, colors identify the sending entity, and purple marks the steps that occur only in the elevated posture.

Figure 2. End-to-end overview of the LABMFA-MCC protocol across its phases.

3.6.2. Registration Phase

Registration happens once, over a channel that is both secret and authenticated, and it is the only time when the registration center is active. The user hands the RC an identity, a password, and a biometric sample; the RC derives the long-term material, provisions every party, and goes offline. The derivations are as follows.

A_u = h₂(ID_u, x_RC)

(R_u, P_u) = Gen(Bio_u)

B_u = h₃(ID_u, PW_u, R_u) ⊕ A_u

TK_j = PRF(A_u, sid(S_j)) for each server S_j

The master credential, A_u, is bound to the RC secret and never sent over a public channel: it is delivered one; at registration, to each enrolled server over the secure authenticated provisioning channel (message 3 of Table 3), it never stored in the clear on the device, and it appears in no message of the authentication phase, where only values derived from it through one-way functions, such as M1, are transmitted; the masked credential, B_u, can be unlocked only with all three factors together; and the per-server tokens are pseudorandomly independent as values. The RC then provisions the parties and disappears. Table 3 lists every registration message.

Table 3. Messages exchanged during registration, all over a secure, authenticated channel. After the last of them, the registration center is permanently offline.

#	From	To	Message Contents	Channel
1	MU	RC	{ IDu, PWu, Biou }	secure, authenticated
2	RC	MU	smart card: { Bu, Pu, TK1, …, TKN, G }	secure, authenticated
3	RC	Sj	{ Au, TKj }   (one per server, j = 1, …, N)	secure, authenticated
4	RC	EAP	server-index routing table (j → S_j address)	secure, authenticated

3.6.3. Risk-Assessment Phase

When a login attempt arrives, the proxy first decides how demanding the session should be, from three contextual signals an unfamiliar location, an unusual time, and a sensitive target server:

RS = w_L·L + w_T·T + w_V·V

with weights w_L = w_T = 0.30; w_V = 0.40; and threshold, τ (default 0.40). Each signal is scored on [0, 1] as a risk contribution: L rises with the unfamiliarity of the location, T with the irregularity of the access time, and V with the sensitivity of the target server. Because the weights sum to one, RS is itself confined to [0, 1] and reads directly as a fraction of the maximum attainable risk, which lets τ be interpreted on the same scale and remain portable across deployments. If RS < τ, the session runs in the standard posture; otherwise, it runs in the elevated posture of Section 3.6.5.

The weighting reflects the different roles the three signals play rather than empirically fitted constants. The two contextual signals, L and T, are circumstantial anomaly detectors of the same kind and are weighted equally in the absence of operational evidence that one predicts misuse better than the other. The server-sensitivity signal, V, is given the largest single weight because it measures impact rather than likelihood: the friction imposed on the user should scale with what is actually at stake, so that a high-value triggers the biometric step-up even on an ordinary-looking login. The default threshold, τ = 0.40, is positioned deliberately within this structure. A maximally sensitive server (V = 1) reaches the threshold on its own and so always triggers the elevated posture; a single contextual anomaly (0.30) falls below it and adds no friction in isolation; and two corroborating anomalies (0.30 + 0.30 = 0.60) clear it. The policy therefore tolerates isolated weak evidence while escalating on either high stakes or mutually reinforcing signals. These values are tunable defaults: in a real deployment the weights and τ should be calibrated against logged authentication data to a chosen operating point that balances unnecessary step-ups against missed high-risk sessions. Establishing such a point quantifying the trade-off between unnecessary step-ups on legitimate logins and missed high-risk sessions requires labeled deployment data and is left to future work.

In the reference instantiation the three signals are computed by the proxy from information it holds without learning the user’s identity, and each is normalized to [0, 1] by construction. V is a sensitivity class assigned to each server index, j, when the routing table is provisioned, for example, 0 for public services, 0.5 for services holding personal data, and 1 for financial or health services, so the proxy reads it directly from its routing entry. L grades the network location of the request: 0 when it enters through an attachment point of the proxy’s own service area, 0.5 when it arrives from another operator’s network, and 1 when it arrives through an anonymizing relay or from outside the region the target service declares. T grades the access time against the operating profile declared for Sj: 0 inside the profile, 1 outside it, and 0.5 in its boundary hours. Because the login request is anonymous, these are context-level rather than user-level signals: a per-user behavioral profile at the proxy would require it to link a user’s sessions, which the protocol is designed to prevent. User-level signals, for example a profile held and evaluated on the device, are left to future work. In the prototype, L, T, and V are supplied to the proxy as inputs.

The score itself is computed locally at the proxy. In the standard posture no further message is sent; in the elevated posture the proxy withholds message 1 and runs the step-up round of Section 3.6.5. The key-agreement exchange and the derivation of the session key are identical in both postures.

3.6.4. Authentication and Key Agreement

This is the heart of the protocol. Over three round trips, six messages once the proxy’s relay hops are counted, the device and the server authenticate each other and agree on a fresh session key, while the proxy passes traffic in both directions without ever touching the key. Table 4 lists every message; the prose then walks through each step.

Table 4. Every message in the authentication exchange, including the proxy’s relay hops.

#	From	To	Message Contents
1	MU	EAP	{ CID, M1, V1, T1, j }
1a	EAP	MU	{ CID, NE, TE } (elevated posture only: step-up challenge)
1b	MU	EAP	{ CID, SR, TSR }, SR = h6(Au, TKj, CID, NE, TSR) (elevated only, after a fresh capture)
2	EAP	Sj	{ CID, M1, V1, T1, j }   (relayed unchanged); in the elevated posture followed by { NE, SR, TSR }
3	Sj	EAP	{ M2, V2, T2 }
4	EAP	MU	{ M2, V2, T2 }   (relayed unchanged)
5	MU	EAP	{ M3, T3 }
6	EAP	Sj	{ M3, T3 }   (relayed unchanged)

• Step 1: The user builds and sends the login request.

The user enters identity and password and offers a live biometric sample, Bio’_u. The device reproduces the biometric key, unmasks the master credential, draws a one-time nonce, and assembles the authenticator:

R_u = Rep(Bio’_u, P_u), A_u = B_u ⊕ h₃(ID_u, PW_u, R_u)

CID = h₃(ID_u, T₁, r₁), V₁ = r₁·G

M₁ = h₅(A_u, TK_j, p2b(V₁), T₁, CID)

Unmasking succeeds only when the fresh sample is close enough to the enrolled one, d(Bio’_u, Bio_u) ≤ δ; otherwise, the recovered credential is wrong and everything downstream fails. The authenticator M₁ ties together the master credential, the server token, the ephemeral key, the timestamp, and the pseudonym CID. Binding CID in is deliberate, the analysis in Section 4 shows that leaving it out lets an active attacker swap the pseudonym on a captured request. The device sends message 1, {CID, M₁, V₁, T₁, j}, to the proxy.

• Step 2: The proxy checks freshness and relays.

The proxy confirms the request is recent, |T_cur − T₁| ≤ ΔT, looks up the route for the server index j, settles the risk posture, and forwards the request untouched as message 2. It changes nothing and keeps nothing: no token, no credential, and no key. In the elevated posture, it first runs the step-up round of Section 3.6.5 and then forwards the request together with (NE, SR, and TSR).

• Step 3: The server verifies the user and derives the key.

The request carries no recoverable identifier: CID is a fresh per-session pseudonym and exposes nothing about ID_u. To authenticate the requester anonymously, the server scans its own table of enrolled users and, for each registered pair (A_u, TK_j) it holds, recomputes the authenticator and tests it for a match:

M₁ ?= h₅(A_u, TK_j, p2b(V₁), T₁, CID)

A match proves, in one stroke, that the requester holds a valid card, knows the password and identity, and presents a matching biometric. In the elevated posture, the server additionally verifies SR = h6(Au, TKj, CID, NE, TSR) with the matched credential and proceeds only if both checks succeed. The server then contributes its half of the key agreement and forms its reply:

V₂ = r₂·G, SK = h₄(TK_j, p2b(r₂·V₁), T₁, T₂)

M₂ = h₃(SK, T₂, p2b(V₂))

It is the server, not the proxy, that draws r₂, which is what places the key out of a compromised proxy’s reach, since the relay sees only the public points V₁ and V₂. The server returns message 3, {M₂, V₂, T₂}; the proxy relays it as message 4. V₂ travels explicitly because the device needs it both to finish the key and to check M₂.

This anonymous lookup is a deliberate design choice. Keeping the request free of any user identifier is what makes the login unlinkable to the edge proxy and to a network eavesdropper, and it is the basis of the anonymity result of Section 4. The cost is borne by the server, which evaluates one keyed hash per enrolled user, an O(N) scan in the number of users registered at that server; the scan is bounded per server rather than across the federation, since each server holds only its own enrolled users. It is performed in constant time with respect to the requester: every enrolled user is evaluated, each result is compared with M1 in constant time, and the scan does not stop at the first match, because an early exit would let the response time reveal the requester’s position in the table and so allow the relaying proxy to link sessions. Before scanning, the server re-checks the freshness of T1, so stale or replayed requests are rejected at constant cost, and the proxy applies a per-source rate limit. The measured cost is reported in Section 5.2. A deployment that prefers direct lookup can add an optional server-indexable tag to the request, trading anonymity against the honest server for O(1) selection; LABMFA-MCC takes the stronger-anonymity option by default.

• Step 4: The user derives the same key and confirms.

Receiving the reply, the device completes the agreement and authenticates the server:

SK = h₄(TK_j, p2b(r₁·V₂), T₁, T₂), M₂ ?= h₃(SK, T₂, p2b(V₂))

Because r₁·V₂ = r₁·r₂·G = r₂·V₁, both sides reach the very same key without it ever crossing the wire. A correct M₂ tells the device the responder really is the registered server. The device replies with message 5, the confirmation M₃ = h₃(SK, T₃, CID), which the proxy relays as message 6.

• Step 5: The server closes the loop.

The server checks M₃? = h₃(SK, T₃, CID). Once it matches, the session is open and the key protects everything that follows. Because SK rests on the fresh, single-use nonces, r₁ and r₂, which are discarded afterward, a later compromise of long-term secrets cannot unlock past sessions, and the protocol has perfect forward secrecy.

3.6.5. Risk-Adaptive Posture

The risk score chooses the posture. In the standard posture (RS < τ), the proxy relays message 1 immediately and the exchange above runs unchanged; the session is still biometric-bound, since Au cannot be formed without a biometric-aided unmask. In the elevated posture (RS ≥ τ), the proxy does not forward message 1. It draws a fresh nonce NE and a timestamp TE, returns the step-up challenge {CID, NE, TE} to the device (message 1a), and holds message 1 for at most ΔT. The device checks that CID belongs to its pending login and that TE is fresh, discards the Au and Ru used to form M1, performs a new capture under the stricter liveness threshold configured for the elevated posture, reproduces Ru, unmasks Au again, and returns {CID, SR, TSR} with SR = h6(Au, TKj, CID, NE, TSR) (message 1b). A capture that fails the liveness threshold or the tolerance, δ, aborts the attempt on the device, and nothing further is sent. The proxy checks the freshness of TSR and that CID matches the withheld request, and forwards message 1 together with (NE, SR, and TSR); the server verifies M1 and SR and proceeds to key agreement only if both succeed, after which the exchange continues unchanged. Because NE is fresh and SR can be formed only with the biometric-bound credential, an accepted SR shows that the credential was used after the challenge was issued; a request prepared in advance cannot satisfy it. The cost is one additional device–proxy round trip, a second reproduction and one hash on the device, and one hash verification at the server (Section 5.4). The limit is that posture enforcement relies on the proxy: a fully compromised proxy can decline to issue the challenge and route an elevated session as a standard one. Such a downgrade removes the step-up for that session but leaves session-key secrecy and mutual authentication intact, since the proxy still holds no key material.

3.6.6. Multi-Server Access

One registration is enough to reach every enrolled server. To contact a different server, S_k, the device takes the matching token, TK_k, already on the card and runs the same six-message exchange of Section 3.6.4, with TK_k in place of TK_j. No return to the RC takes place, and no message between servers is needed. Safety rests on the pseudorandom independence of the token values: without the master credential, A_u, knowledge of one token, TK_j, gives no advantage in predicting TK_k for k ≠ j, so a token exposed in transit does not weaken authentication to the other servers. This independence does not, however, extend to a fully compromised server. Because each server stores A_u to verify logins and because the identifiers, sid(S_k), are public, any entity that recovers A_u can recompute every token, TK_k = PRF(A_u, sid(S_k)). Resistance to a breached server is therefore outside the threat model adopted here, in which the servers are honest, and is identified as a direction for future work.

3.6.7. Credential Update

Changing a password or re-enrolling a biometric is done entirely on the device, with no message to the RC or the servers. To change the password, the device recovers A_u with the current factors and rewrites the mask:

B_u^new = h₃(ID_u, PW_new, R_u) ⊕ A_u

To re-enroll a biometric, it recovers A_u, regenerates the key and helper from a new sample, and rewrites the mask as follows:

(R_u^new, P_u^new) = Gen(Bio_u^new), B_u^new = h₃(ID_u, PW_u, R_u^new) ⊕ A_u

In both cases, A_u itself never changes, so every server token stays valid and no message needs to leave the device.

4. Formal Validation of Security

Security claims are most convincing when supported by formal analysis. We approach this on two complementary fronts: automated symbolic verification with ProVerif, which mechanically searches for structural attacks under a Dolev–Yao adversary across three trust models; and a computational argument in the Real-or-Random model, which bounds a bounded adversary’s advantage against the session key by reduction to standard hardness assumptions. This section describes the symbolic models and results, and then it presents the computational argument.

4.1. Modeling in ProVerif

ProVerif takes a protocol as a set of concurrent processes and a Dolev–Yao adversary that controls the network, and either proves some property or returns an attack trace. Three autonomous models are constructed, each corresponding to a different trust assumption, as described in the threat model of Section 3.4:

• Main.pv (normal mode): The adversary controls the open channel between the device and the proxy, so he can eavesdrop, modify, replay, and inject data.
• Eap_compromise.pv (edge-proxy adversary): An improved model where the adversary fully manages the Edge Authentication Proxy and sees all traffic passing through it.
• Stolen_device.pv (stolen-device adversary): The adversary has the entire contents of the smart card {B_u, P_u, TK_j}, and the biometric Bio_u is kept secret.

One modeling decision is shown for transparency. The credential mask B_u = h₃(ID_u, PW_u, R_u) ⊕ A_u is XORed, which is not part of the standard equational theory of ProVerif, as it cannot reason about XOR without using fallible simplifications; hence, the mask is modeled as symmetric encryption with key h₃(ID_u, PW_u, R_u). This is a valid abstraction for the qualities studied here; it preserves the requirement of all three parameters for retrieving Au, and the actual protocol uses the XOR mask. To guard against vacuous results, correspondence queries that hold only because their precondition is never reached, each model includes a reachability probe confirming that an honest session can complete. All three models pass, so the reported properties hold over models in which the protocol genuinely runs. Each model contains both postures: the proxy’s risk decision is abstracted as a nondeterministic choice between a standard relay and a step-up relay, so every result holds for either outcome. The two models that contain injective step-up queries (Q17 and Q18) are run with the ProVerif option preciseActions, without which these queries cannot be proved; no attack is reported in either case.

4.2. Verification Results

Table 5 enumerates the eighteen queries executed by ProVerif across the three models. Secrecy questions verify that a value is unattainable by the attacker; correspondence queries establish that one event can transpire only after another, hence ensuring authentication and integrity.

Table 5. ProVerif verification results. Eighteen queries are machine-checked across three adversary models; every query passes. Each model also passes a non-vacuity reachability probe.

#	Property	Model	ProVerif Query	Result
Q1	Session-key secrecy	Normal	attacker(SK_test)	Secret
Q2	User anonymity	Normal	attacker(ID_u)	Secret
Q3	Password secrecy	Normal	attacker(PW_u)	Secret
Q4	OPG resistance	Stolen-device	weaksecret PW_u	Resists
Q5	Server authenticates MU	Normal	inj-event(Server_verifies_M3(CID,SK)) ==> inj-event(MU_sends_M3(CID,SK))	Holds
Q6	MU authenticates server	Normal	inj-event(MU_verifies_M2(CID,SK)) ==> inj-event(Server_sends_M2(CID,SK))	Holds
Q7	Session integrity	Normal	Session_established(CID,SK) ==> MU_verifies_M2(CID,SK)	Holds
Q8	Biometric-key secrecy	Normal	not attacker(Ru)	Secret
Q9	Session-key secrecy	EAP-compromise	not attacker(SK)	Secret
Q10	Server authenticates MU	EAP-compromise	inj-event(Server_verifies_M3(CID,SK)) ==> inj-event(MU_sends_M3(CID,SK))	Holds
Q11	MU authenticates server	EAP-compromise	inj-event(MU_verifies_M2(CID,SK)) ==> inj-event(Server_sends_M2(CID,SK))	Holds
Q12	Stolen-device resistance	Stolen-device	Server_verifies_attacker(CID,SK)	Resists
Q13	Step-up authenticity	Normal	event(Server_accepts_stepup(CID,N)) ==> event(MU_stepup_response(CID,N))	Holds
Q14	Challenge provenance	Normal	event(Server_accepts_stepup(CID,N)) ==> event(EAP_issues_challenge(CID,N))	Holds
Q15	Step-up forgery resistance	Stolen-device	event(Server_accepts_stepup(CID,N)) ==> event(MU_stepup_response(CID,N))	Holds
Q16	Step-up authenticity	EAP-compromise	event(Server_accepts_stepup(CID,N))==> event(MU_stepup_response(CID,N))	Holds
Q17	Elevated-session agreement	Normal	inj-event(Server_verifies_M3_SU(CID,SK,N))==> inj-event(MU_sends_M3_SU(CID,SK,N))	Holds
Q18	Elevated-session agreement	EAP-compromise	inj-event(Server_verifies_M3_SU(CID,SK,N)) ==> inj-event(MU_sends_M3_SU(CID,SK,N))	Holds

• Normal operation (Q1–Q8): The adversary cannot access the session key (Q1), user identity (Q2), password (Q3), and biometric key (Q8). Offline-guessing resistance is established separately, in the stolen-device model, by the weak-secret test of Q4 (Section 4.2). Thus, even with the full stolen card, an attacker cannot verify a password guess offline, because the verification of a password guess needs biometric authentication, so PWu remains confidential despite the publication of Bu. The exchanges Q5 and Q6 provide mutual authentication, and Q7 authenticates that a session is established only after the mutual authentication.
• Edge-proxy adversary (Q9–Q11): Edge-proxy adversary. The following are architecturally significant results. The session key is kept secret (Q9), and mutual authentication is maintained (Q10 and Q11), even if the proxy is completely penetrated. This is the empirical justification for the design decision to exclude the proxy from key derivation: the relay does not manage any key material, so controlling it does not benefit the key.
• Stolen-device adversary (Q12): The adversary cannot force the server to accept the whole card content without biometric data. Therefore, the event Serververifiesattacker can never be reached. Because a live biometric is not involved, the master credential is not exposed, and this resistance persists across all channels, not just one.
• Step-up (Q13–Q18): Under normal operation the server accepts a step-up only for a challenge the proxy issued to that session (Q14) and only when the biometric-holding device has answered it (Q13), and every elevated session completed at the server corresponds injectively to a distinct elevated session of the device with the same challenge and session key (Q17). With the card contents published, a card-only adversary cannot forge a step-up response (Q15). Under full proxy compromise, where the adversary issues the challenge itself, the server still accepts only responses computed by the device (Q16), and injective agreement on the elevated session is preserved (Q18). Each model also carries a non-vacuity query for the step-up path, and Q1–Q12 were re-run on the revised models with unchanged results.
• Properties argued analytically: As usual in the MCC literature, two properties are proved by argumentation, not by the tool: perfect forward secrecy, which follows from the ephemeral term r1·r2·G, and untraceability, which stems from the fresh per-session pseudonym CID. These two are analytical conclusions, not machine-verified. Injective agreement and the replay resistance it entails are now machine-checked directly through the injective correspondences of Q5, Q6, Q10, and Q11, and are therefore no longer argued analytically.

4.3. Computational Security of the Session Key (ROR Model)

The symbolic analysis of Section 4.2 establishes the absence of structural attacks under a Dolev–Yao adversary. We complement it with a computational argument in the Real-or-Random (ROR) model, which bounds the advantage of a probabilistic polynomial-time adversary in distinguishing the session key from a random string and reduces this advantage to the protocol’s underlying hardness assumptions. We give a proof sketch; the full game sequence follows the standard structure of Abdalla–Fouque–Pointcheval [30].

Adversary model. The adversary controls the network and interacts with participant instances through the usual queries: execute (passive eavesdropping on an honest run), send (active injection and modification), reveal (disclosure of a non-target session key), corrupt (disclosure of long-term secrets, used for forward secrecy), and a single test query. On the test query, a fair coin b is flipped; the adversary receives the real session key if b = 1 and a random string of equal length if b = 0, and outputs a guess b′. The session-key advantage is Adv = |2·Pr[b′ = b] − 1|. The hash functions h2…h5 are modeled as random oracles.

Theorem (sketch). For any PPT adversary making at most q_s send queries, q_e execute queries, and q_h random-oracle queries, the session-key advantage is bounded by Adv ≤ q_h²/2^l + 2·q_s/2^l + 2·q_h·Adv^CDH + 2·Adv^PRF, where l is the output length of the hash and nonce space, Adv^CDH is the advantage against the computational Diffie–Hellman problem on Curve25519, and Adv^PRF is the distinguishing advantage against the keyed-BLAKE2s pseudorandom function. All terms are negligible under the stated assumptions, so Adv is negligible.

Proof sketch (game sequence). We proceed through a sequence of games G0–G4, with S_i the event b′ = b in game G_i:

• G0 is the real ROR experiment, so Adv = |2·Pr[S0] − 1|.
• G1 adds collision avoidance for the random oracles and for the ephemeral nonces r1, r2, T1, and T2; the simulation aborts on any repeated oracle input or nonce collision. By the birthday bound, |Pr[S1] − Pr[S0]| ≤ q_h²/2^(l+1) + q_s/2^l. This isolates oracle consistency and ephemeral freshness, on which the remaining hops rely.
• G2 handles authentication. The simulator aborts if the adversary produces a valid authenticator (M1, M2, or M3) not output by an honest instance. Each authenticator is a random-oracle image binding the master credential, A_u (respectively, the session key, SK), values the adversary cannot form without the biometric-derived A_u; such a forgery requires guessing an oracle output or breaking the binding, giving |Pr[S2] − Pr[S1]| ≤ 2·q_s/2^l. After G2, the test session is guaranteed a matching partner, ruling out active attacks on the keyed exchange.
• G3 reduces to CDH. The shared secret r1·r2·G inside SK = h4(TK_j, p2b(r1·r2·G), T1, T2) is replaced by a random group element. A distinguisher between G3 and G2 yields a CDH solver: a CDH challenge (a·G, b·G) is embedded in the ephemeral values, V1 and V2, and the adversary’s distinguishing power is used to compute a·b·G. Hence, |Pr[S3] − Pr[S2]| ≤ q_h·Adv^CDH. Under DDH, the substitution is tight; the CDH-based bound is stated for the weaker assumption.
• G4 reduces to PRF security. The per-server token, TK_j = PRF(A_u, sid(S_j)), which keys the session-key hash, is replaced by an independent random value. Distinguishing G4 from G3 breaks the keyed-BLAKE2s PRF, so |Pr[S4] − Pr[S3]| ≤ Adv^PRF. In G4, the session key is the image, under a random oracle, of an input containing a uniformly random element independent of all adversary-observable values; it is therefore distributed identically to a random string, and Pr[S4] = 1/2.

Collecting the hops gives the stated bound. Forward secrecy follows by permitting the corrupt query after the test session completes because the substituted term r1·r2·G in G3 depends only on the ephemeral nonces, which are discarded, and disclosure of the long-term values A_u, TK_j, and x_RC does not help distinguish the already-established key. This computational result complements the three-model symbolic verification of Section 4.2, establishing session-key security in the computational model, as well as the symbolic one.

4.4. Comparative Security Analysis

When compared, to directly comparable designs, the guarantees of a protocol become more meaningful. In order to make a fair comparison, it is restricted to the schemes that employ three-factor authentication with a biometric (or a PUF) along with a password and smart card like LABMFA-MCC, and that disclose both the computational and communicational costs, i.e., the schemes that are appropriate for a fair quantitative and qualitative comparison. In this work, a ten-property axis is used, which includes mutual authentication, user anonymity, untraceability, perfect forward secrecy, session-key secrecy, replay resistance, impersonation resistance, MITM resistance, offline-guessing resistance, and stolen-card protection. Table 6 shows the summary of security score, verification method, and deployment of this peer set, along with LABMFA-MCC.

Table 6. Security comparison over the directly comparable peer set of three-factor biometric schemes. ✓ = provided; ✗ = not provided; the score is the number of properties satisfied out of ten. Property abbreviations are defined in the text.

Protocol/Scheme	MA	UA	UT	PFS	SKS	RR	UIR	MITM	OPG	SCP	Score
Wen et al. [6]	✓	✓	✓	✓	✓	✓	✓	✗	✓	✗	8/10
Ghazel et al. [3]	✓	✓	✗	✓	✓	✓	✓	✓	✓	✓	9/10
Abbasi et al. [2]	✓	✓	✓	✓	✓	✓	✓	✓	✓	✗	9/10
Shukla and Patel [4]	✓	✓	✓	✓	✓	✓	✓	✓	✗	✗	8/10
Shukla and Patel [5]	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	10/10
LABMFA-MCC	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	10/10

Table 6 presents the comparison of the ten required security properties for a mobile cloud computing authentication and key agreement protocol: mutual authentication (MA), user anonymity (UA), untraceability (UT), perfect forward secrecy (PFS), session-key security (SKS), replay resistance (RR), user-impersonation resistance (UIR), man-in-the-middle resistance (MITM), offline-password-guessing resistance (OPG), and stolen-card protection (SCP).

LABMFA-MCC satisfies all ten evaluated properties. In the considered threat model where the registration center is trusted and offline, and the servers are honest, that places it on top of the peer set, equal with Shukla and Patel [5] and ahead of the other schemes.

This peer set has a strong position. Only [5] matches LABMFA-MCC in the coverage of all ten properties, but its computation takes hundreds of milliseconds, while [2,3,4] and [6] fall behind. Crucially, it does this while being the only scheme in the set to be simultaneously multi-server, risk-adaptive, and verified under three different adversary models, a depth of formal assurance not provided by the single-model treatments here, and at the lowest reported computational cost, as Section 5 shows, with the caveat that the peer figures were obtained on different platforms and implementations. Moreover, this symbolic breadth is paired with a computational session-key proof in the Real-or-Random model, so LABMFA-MCC matches the reductionist assurance of the peer schemes while exceeding the adversary-model coverage of their symbolic analyses.

4.5. Security Summary

The formal analysis establishes, with machine-checked rigor across three adversary models, that LABMFA-MCC achieves session-key secrecy, mutual authentication, anonymity, offline-guessing resistance, biometric secrecy, and, most distinctively, session-key secrecy under a fully compromised edge proxy and impersonation resistance under a stolen device. Injective agreement and the replay resistance it entails are likewise machine-checked. Forward secrecy and untraceability are argued analytically. Together, these results account for all ten properties evaluated in this work. The six step-up queries further establish that an elevated session is accepted only with a fresh response bound to the proxy’s challenge, including under full proxy compromise.

5. Performance Evaluation

This section measures the computation, communication, and costs of risk-adaptive operation. The data comes from a working prototype tested on real hardware (not a simulation), thereby accurately representing authentic device and network performance. This evaluation concerns the protocol’s computational and communication cost, including the inline overhead of the risk mechanism; it does not assess the decision quality of the risk policy, whose calibration is deployment-specific (Section 3.6.3) and left to future work.

5.1. Experimental Methodology

The protocol was implemented as three networked processes, one for each entity. The Mobile User was run on a Samsung Galaxy A56 (Android 15, ARM64), the Edge Authentication Proxy and the Cloud Server were run on an Intel Core i7-6500U (2.50 GHz, 16 GB, x86-64), and the two machines communicated over a local Wi-Fi network. The key agreement was X25519 (RFC 7748), and all hashing was BLAKE2s (RFC 7693), with the native constant-time backend active on both machines. Each entity was instrumented for its own per-session computation and the device also logged end-to-end latency over the real network. Figures are taken over 100 consecutive successful logins, excluding 5 warm-up logins and one cold-start measurement. Per-entity computation is summarized as mean and median over 100 logins; the network and end-to-end numbers, which have right-skewed distributions due to occasional wireless retransmission, are summarized by their median.

5.2. Computational Cost Analysis

The measured per-entity computation is reported in Table 7. The work is light and almost symmetric: the device and the server each do two X25519 scalar multiplications and a handful of BLAKE2s hashes, so their near-equal cost reflects the symmetry of the structure of the protocol.

Table 7. Measured per-entity computation (native X25519, n = 100). The total is the sum of the three entities’ computation plus the device-side fuzzy-extractor reproduction.

Component	Mean (ms)	Median (ms)
Mobile User (Galaxy A56, ARM)	0.401	0.377
Edge Auth. Proxy (i7, relay only)	0.040	0.038
Cloud Server (i7, x86)	0.358	0.353
Fuzzy-extractor reproduction (Galaxy A56, 72× BCH(31,21,2))	0.078	0.071
Total computation (3 entities)	0.878	0.850

Two points are significant. The device performs its cryptographic work in roughly 0.40 ms on real ARM mobile hardware, making it comparable in performance to optimized implementations in the literature. To this is added the cost of fuzzy-extractor reproduction, the secure-sketch decode that recovers the stable biometric key at each login. Following the fingerprint fuzzy-commitment construction of [31], the Finger Code is partitioned into 72 sectors, each protected by a BCH(31,21,2) code correcting up to two corrupted minutiae; a login therefore performs 72 sector decodes. Measured on the same Galaxy A56, this step costs 0.078 ms (mean; 0.071 ms median) per login. The device-side total is therefore approximately 0.48 ms, and this reproduction cost, previously excluded, is now included in the figures reported here. The proxy overhead of 0.040 ms is about two orders of magnitude lower than either endpoint since it only does a freshness check, a pseudonym lookup, and a risk-score computation, never touching a key, the measured echo of the formal result that the protocol resists a compromised proxy of 0.88 ms (0.85 ms by median), inclusive of fuzzy-extractor reproduction. The code corrects, at most, two erroneous bits in each 31-bit sector, and this choice fixes the trade-off between false rejection of genuine but noisy captures and false acceptance of impostor samples. The prototype measures the decoding time only; the recognition error rates of the construction were not evaluated here and must be calibrated for the sensor and user population of a deployment.

On a real link, the protocol is bound to the network. The device computation is only 0.40 ms of the median end-to-end latency of 3.40 ms, and the rest is the Wi-Fi round trip with a median of 3.04 ms. The distribution contains a tail (max 44.5 ms) from occasional retransmission; hence, the median, not the mean, as shown in Figure 3, is the representative figure. The practical implication is that further reducing the cost of cryptography would have little impact on the user-perceived latency, but terminating round trips at the edge would. The server figure in Table 7 was measured with one enrolled user. Because the request is anonymous, the server evaluates h5 once per enrolled user, and this part of its cost grows linearly with the population N. The scan was therefore timed separately on the server host (i7-6500U, Python 3.14, native BLAKE2s) for N = 1 to 10,000 synthetic users, with the matching user first, in the middle, last, or absent, 200 timed runs per case after 20 warm-up runs, both for the constant-time scan used by the protocol and for an early-exit scan. Table 8 gives the medians.

Figure 3. Mean values of each entity computation time.

Table 8. Measured server-side cost of the anonymous user search.

Enrolled Users, N	Constant-Time Scan (ms)	Early Exit, Match First (ms)	Early Exit, Match Last (ms)
10	0.080–0.082	0.009	0.032
100	0.465–0.480	0.005	0.469
1000	4.21–4.64	0.005	4.65
10,000	34.3–42.3	0.004	34.1

In the no-match case, which an attacker can force, the constant-time scan costs 3.4–4.7 µs per enrolled user from N = 100 upward, so 1000 users add about 4.6 ms, and 10,000 users about 34–39 ms, to the 0.353 ms median server computation; since the implementation is interpreted, these figures probably overstate the cost of a compiled server. The early-exit scan is faster on average but leaks the requester’s position in the server’s table: at N = 10,000, the first enrolled user is served in 0.004 ms, and the last in 34.1 ms, a difference that the relaying proxy can observe and use to link sessions despite the fresh CID. The constant-time scan removes this systematic dependence. Its four case medians are not identical (Table 8), and a repeat with the cases timed in random interleaved order gave 4.67–8.00 ms at N = 1000 and 36.9–44.1 ms at N = 10,000; however, the differences do not follow the match position, since the match-first case was the slowest twice and the fastest once across the four measurements, whereas a leak would make it consistently the fastest. We therefore attribute them to timing noise on the host, whereas the early-exit leak recurs at several orders of magnitude in every measurement. Because a non-matching request costs a full scan, the freshness check before the scan and the proxy’s per-source rate limit bound the number of scans any single source can force. The trials are independent and could be divided across cores, and for much larger populations, the optional server-indexable tag remains available at the cost of anonymity toward the honest server. The single-user figures of Table 7 remain the basis of the comparison with other schemes below; the search cost is a separate, population-dependent characteristic of the server and is not added to them.

5.3. Communication Overhead Analysis

Communication overhead was measured directly from the serialized messages of a real login. Unlike the timing figures, this quantity is deterministic, identical for every login, and platform-independent, since it is fixed by the protocol’s field sizes rather than by the hardware. Table 9 gives the per-message breakdown.

Table 9. Measured communication overhead (payload of the three protocol messages).

Message	Fields	Bits	Bytes
Message 1 (MU → server)	CID, M1, V1, T1, j	848	106
Message 2 (server → MU)	M2, V2, T2	576	72
Message 3 (MU → server)	M3, T3	320	40
Total (3 messages)	—	1744	218

The total protocol communication is 1744 bits (218 bytes) as shown in Figure 4. When the three authenticators, M₁, M₂, and M₃, are truncated to 128-bit tags an explicit option, the payload is reduced to 1360 bits. The encoding uses 256-bit BLAKE2s tags and X25519 points, 64-bit timestamps and a 16-bit server index, and elliptic-curve points cannot be represented in less than 256 bits, thus setting the lower bound on the achievable size.

Figure 4. Per-message breakdown of the 1744-bit communication overhead.

5.4. Adaptive-Posture Overhead

In the standard posture (RS < τ), which is the expected common case, the exchange is exactly that of Table 7 and Table 9, and the only inline cost of adaptivity is the proxy’s risk-score evaluation, already included in the 0.040 ms proxy overhead. In the elevated posture (RS ≥ τ), the step-up adds one device–proxy round trip, a second fuzzy-extractor reproduction and one BLAKE2s evaluation on the device, nonce generation and one lookup at the proxy, and one additional hash verification at the server; no elliptic-curve operation is added, and the session-key derivation is unchanged. The step-up was measured on the revised prototype over 100 elevated logins, with five warm-up logins excluded, on the same handset and host, alongside a standard-posture run. The device’s step-up response, excluding the physical capture, took a median of 0.067 ms, and the device’s total computation rose from a median of 0.499 ms in the standard run to 0.548 ms; the second reproduction, which the prototype simulates, adds a further 0.078 ms measured separately (Section 5.2). The verification of SR at the server took a median of 0.011 ms, and the proxy’s processing rose from 0.044 ms to 0.060 ms. The serialized challenge and response measured 576 bits each, so an elevated login carries 2896 bits on the device–proxy link, and the backhaul copy of message 2 grows by 576 bits. The wireless link during these runs was slow and variable (median network time about 15.6 ms), and the median end-to-end latency of an elevated login (16.13 ms) could not be distinguished from that of a standard login (16.25 ms); the extra round trip lay below the resolution of the measurement. The time of the user’s second capture depends on the sensor and is not included.

Sensitivity of the posture decision. Because the weights and threshold are not calibrated, we examine how the decision depends on them. With binary signals (each of L, T, and V either 0 or 1), there are eight contexts, and RS takes only the values 0, 0.3, 0.4, 0.6, 0.7, and 1. Table 10 shows which contexts are elevated as τ varies, together with the fraction of logins that would be elevated if the three signals were independent and uniform on [0, 1]; this uniform case is an illustration, not a model of real traffic, in which low-risk contexts dominate.

Table 10. Sensitivity of the posture decision to the threshold, τ (reference weights are wL = wT = 0.30, and wV = 0.40).

τ	Elevated Binary Contexts (of 8)	Contexts Elevated	Elevated Fraction, Uniform Signals
0.30	7	any single signal	0.88
0.35	5	V = 1, or L = T = 1	0.80
0.40 (default)	5	V = 1, or L = T = 1	0.71
0.45–0.60	4	any two signals	0.61–0.29
0.65–0.70	3	V = 1 and at least one of L, T	0.12 (at 0.70)
0.80	1	all three signals	0.04

Two observations follow. First, every τ in (0.30, 0.40] gives the same decisions on binary contexts, so the default is not sensitive to small changes in τ within that interval; it does, however, sit on its upper edge. A maximally sensitive server alone gives RS = wV = 0.40 = τ, so the property that such a server always triggers the step-up holds only while wV ≥ τ: lowering wV below 0.40 with wL = wT = (1 − wV)/2, or raising τ above 0.40, removes that context from the elevated set, while raising wV leaves the decisions unchanged. A deployment that wants this property with a margin can choose τ = 0.35, which yields the same decisions with a margin of 0.05 on both sides. Second, the cost of the elevated posture scales with the fraction pe of logins it affects: per login, it adds, on average, pe × 0.145 ms at the device (the 0.067 ms response and a second 0.078 ms reproduction), pe × 0.011 ms at the server, pe × 0.016 ms at the proxy, and pe × 1152 bits on the device–proxy link, so that, at pe = 0.2, the device cost rises by about 0.03 ms and the traffic by about 230 bits. The decision quality of any setting, that is, its false step-up and missed high-risk rates, can only be measured against labeled authentication logs and remains future work.

5.5. Consolidated Comparison

Table 11 places LABMFA-MCC against the same peer set, three-factor biometric (or PUF) schemes that report both computation and communication, ordered from lightest to heaviest computation. The comparison must be read with one caveat stated plainly: the device figure is measured on ARM and is directly comparable to the mobile literature, whereas the server figure is measured on an x86 cloud host, and the literature values are drawn from each paper, as reported on its own platform.

Table 11. Consolidated comparison over the directly comparable peer set: Computation, communication, deployment, and security score.

Protocol/Scheme	Comp. (ms)	Comm. (bits)	Deployment	Security Score
Wen et al. [6]	8.50	1280	Multi-server	8/10
Ghazel et al. [3]	13.24	768	Single-server	9/10
Abbasi et al. [2]	77.60	1328	Single-server	9/10
Shukla and Patel [5]	600.40	1856	Single-server	8/10
Shukla and Patel [4]	669.80	1856	Multi-server	10/10
LABMFA-MCC	0.88	1744	Multi-server	10/10

LABMFA-MCC is the lightest scheme in the set by a wide margin. Its 0.88 ms total computation is about ten times below the nearest peer [6] (8.5 ms), about fifteen times below [3] (13.24 ms, an estimate from operation counts), and two to almost three orders of magnitude below [2,3,4,5], the last being the only peer whose security coverage matches its own, as shown in Figure 5.

Figure 5. Computation cost per login across the comparable three-factor schemes (milliseconds): Shukla and Patel 2024 [5], Shukla and Patel 2022 [4], Abbasi et al. 2024 [2], Ghazel et al. 2026 [3], Wen et al. 2025 [6], and LABMFA-MCC (this work).

Its communication of 1744 bits is mid-range: higher than the single-server schemes [2,3] (1328 and 768 bits), and higher than the lower bound of 1280 bits reported for [6], but below [4,5] (1856 bits each), as shown in Figure 6. The difference from the lower two reflects LABMFA-MCC’s full 256-bit elliptic-curve points and tags; truncating the three authenticators to 128-bit tags brings the total to 1360 bits, comparable to [2].

Figure 6. Communication overhead per login across the comparable three-factor schemes (bits): Shukla and Patel 2024 [5], Shukla and Patel 2022 [4], Abbasi et al. 2024 [2], Ghazel et al. 2026 [3], Wen et al. 2025 [6], and LABMFA-MCC (this work).

5.6. Performance Summary

Measured on real hardware, LABMFA-MCC requires about 0.48 ms of device computation (0.40 ms cryptographic plus 0.078 ms fuzzy-extractor reproduction) and 1744 bits of communication per login, with the edge proxy adding only 0.040 ms and contributing no key material. End-to-end latency is dominated by the network rather than by cryptography. Risk-adaptive operation adds nothing in the standard posture; the elevated posture adds a two-message step-up of 1152 bits on the device–proxy link and well under a tenth of a millisecond of computation at each entity. Based on the formal results of Section 4, the evaluation supports the central claim: strong, multi-model-verified security and risk-adaptive, multi-server operation are achieved at a cost light enough for commodity mobile hardware. Separately, the server’s anonymous user search, performed in constant time to avoid a timing leak, adds about 3.4–4.7 µs per enrolled user on the x86 host (about 4.6 ms for 1000 users); this is a server-side scalability cost, distinct from the per-login figures above.

6. Conclusions and Future Work

In this paper, we propose LABMFA-MCC, a lightweight authentication and key-agreement protocol for mobile cloud computing which binds a biometric into the credential at each login, maintains the session key end-to-end between the device and the server, and reaches many servers from a single offline registration while adapting its posture to contextual risk through a challenge-bound biometric step-up. Formal analysis in ProVerif under three adversary models demonstrated session-key secrecy, mutual authentication, anonymity, offline-guessing resistance and biometric secrecy, and the two architecturally distinct results of secrecy under a fully compromised edge proxy and impersonation resistance under a stolen device, with injective agreement and replay resistance additionally machine-checked, and six further queries (Q13–Q18) established that an elevated session is accepted only with a fresh response bound to the proxy’s challenge, even under full proxy compromise; forward secrecy and untraceability were proved analytically, and session-key security was further established by a computational reduction in the Real-or-Random model. A prototype run on real hardware took about 0.88 ms of total computation (including the measured fuzzy-extractor reproduction) and 1744 bits of communication per login, putting the protocol at the light end of comparable three-factor schemes while still maintaining multi-server reach and a strong security profile.

One design tension is worth stating explicitly, as it informs the protocol’s guarantees. Binding the master credential to the login authenticator is precisely what renders a stolen device useless without the biometric, but that same binding requires that each server hold that credential to verify a login. This is consistent under the threat model adopted here where the registration authority is offline and the servers are honest. Extending the guarantees to settings with untrusted or breached servers is a natural next step rather than a property the present design claims.

A second limitation concerns availability. Because the login request is anonymous, each server searches its table of enrolled users at a cost that grows linearly with the population, and the constant-time search makes every request, valid or not, cost a full search. The proxy’s rate limit bounds this while the proxy is honest; a compromised proxy, which still cannot learn the session key, could forward fresh invalid requests to degrade the server’s availability. Availability lies outside the verified properties, and a per-proxy rate limit enforced at the server, or the optional server-indexable tag for very large populations, are the natural mitigations.

This work suggests several directions:

• Improving the protocol against untrusted or compromised servers, for example, by masking the password on the device so the registration authority never sees it in the clear and storing only per-server tokens, to recover resistance to a privileged insider or a server storage breach.
• The fuzzy-extractor reproduction cost has now been measured on the device under test: the fingerprint fuzzy-commitment decode (72 sectors, each BCH(31,21,2)), per costs 0.078 ms per login on the Galaxy A56 and is included in the client figure. Profiling this step across additional biometric modalities and error-rate regimes remains a useful refinement.
• Testing the protocol under a wider range of network conditions–cellular and congested links–than the local wireless testbed used here, since end-to-end latency is network-bound.
• Empirically calibrating and evaluating the risk policy, selecting weights and τ against labeled authentication logs and characterizing the false-step-up versus missed-high-risk trade-off to move it from a specified mechanism to a validated policy.

Overall, the results show that strong, multi-model-verified security and risk-adaptive, multi-server operation can be delivered at a computational cost light enough for commodity mobile hardware and that being explicit about where the guarantees end is as important as the guarantees themselves.