XFVS Security

Background

Cross-side face verification systems (XFVS) are widely used in mobile apps to verify an individual's claimed identity. Prior works have studied the attacks against XFVSes (and other FVSes) from the perspective of adversarial machine learning (ML), including presentation attacks and adversary attacks.

However, despite the previous success in studying the ML-driven attacks against XFVSes and the escalating arms race between defenses and attacks, one largely ignored perspective of XFVS security is the system design. In other words, it remains unclear whether the verification protocol adopted by XFVSes is secure due to the involvement of complex cross-side two-phase face verification.

FVS classification

To verify a person's identity, A face verification system (FVS) first collects his/her face data (face collection), and then verifies whether the collected face data is matched with the reference face data (face matching). In real-world applications, the two steps of face collection and face matching may occur in different places. Based on the split between face collection and face matching, we classify FVSes into three types: local FVS, remote FVS, and cross-side FVS.

• Type I: Local FVS. A local FVS is designed to collect and match faces within the user’s device. The face data are saved locally and never leave the device.

• Type II: Remote FVS. A remote FVS is designed to collect and match faces at a location away from the user, such as those used at border gates.

• Type III: Cross-side FVS. A cross-side FVS (XFVS) collects faces on user-side devices, sends the face data to a trusted server, and performs face matching on the server side. Unlike local and remote FVSes which have to be done on specific devices, currently XFVSes usually allow users to use them from different devices, thus users can remotely verify their identities at any time and any place.

Threat Model

Our threat model of XFVS security involves two parties: (i) an untrusted client, and (ii) a trusted server.

First, an XFVS client is untrusted because attackers can use XFVSes on a device under their control, such as a custom ROM, a rooted OS or even a phone with special hardware. More specifically, inscope attacks involve but are not limited to code injection and data tampering, which modify client-side XFVS code and data.

Second, an XFVS server is trusted because attackers do not have any control over the server-side code. At the same time, an XFVS server may be vulnerable: For example, a vulnerable server may forget to validate the untrusted data coming from the client.

Our Method

To perform a comprehensive measurement analysis on the security of cross-side face verification systems (XFVSes), we design and implement a semi-automated testing framework, called XFVSCHECKER. It mainly solves two main challenges:

1. How to detect XFVS applications with high accuracy?
2. How to check the security properties of XFVS applications?

XFVS Detection

The key idea of detecting XFVS apps is that the semantics of “face” and “verification” should be closely present in the apps, with clear boundaries from the rest of the code. Therefore, we use a lightweight static analysis method to locate such semantics from app code and privacy policies, As shown in the figure below.

XFVS Security Analysis

By considering confidentiality and integrity in and across each step of XFVS's workflow, so that together they can guarantee the security of XFVS, we propose four key security properties:

• SP1: Reliable Environment. Reliable Environment property is to ensure that the code, data and machine learning models at XFVS client are not tampered with by local attackers.

• SP2: Camera Security. Camera Security property is to ensure that the face data to verify should come directly from the physical camera lens, instead of an injected data stream.

• SP3: Reliable Liveness. Reliable Liveness property is to accurately determine whether the collected face data are being presented by a live person, as opposed to a fake or synthetic face.

• SP4: Data Consistency. Data Consistency property is to ensure that XFVS data—including the collected face, the liveness configurations, and the validation results—are consistent between all steps across the client and the server.

For more detailed explaination, please refer to our paper or join our talk at IEEE S&P 2023.