BioShare: An Open Framework for Trusted Biometric Authentication under User Control

Abstract

Generally, biometric authentication is conducted either by mobile terminals in local-processing mode or by public servers in centralized-processing mode. In the former mode, each user has full control of his/her biometric data, but the authentication service is restricted to local mobile apps. In the latter mode, the authentication service can be opened up to network applications, but the owners have no control of their private data. It has become a difficult problem for biometric applications to provide open and trusted authentication services under user control. Existing approaches address these concerns in ad-hoc ways. In this work, we propose BioShare, a framework that provides trusted biometric authentication services to network applications while giving users full control of their biometric data. Our framework is designed around three key principles: each user has full control of his/her biometric data; biometric data is stored and processed in trusted environments to prevent privacy leaks; and the open biometric-authentication service is efficiently provided to network applications. We describe our current design and sample implementation, and illustrate how it provides an open face-recognition service with standard interfaces, combines terminal trusted environments with server enclaves, and enables each user to control his/her biometric data efficiently. Finally, we analyze the security of the framework and measure the performance of the implementation.

1. Introduction

With the prevalence of smartphones and e-commerce, biometric identification technologies are widely used by service providers and are favorably accepted by most consumers. Fingerprint identification and face recognition have become standard features on most Android and iOS devices, and payment platforms based on facial recognition are increasingly popular in countries such as China. Meanwhile, privacy protection has become a serious topic and is attracting comprehensive attention from scholars and governments. The European Union released the General Data Protection Regulation (GDPR) [1,2,3] in 2018, the United States issued the California Consumer Privacy Act (CCPA) [4,5] in 2018, and China published the Personal Information Protection Law (PIPL) [6] in 2021. Google, Facebook, British Airways, and many other companies were fined for data leakage, unauthorized usage, and other data issues. We are currently faced with the dilemma between data usage and privacy protection, and we need a technical solution to achieve both goals within the same framework.

Currently, there are two types of solutions available: local processing solutions and centralized-processing solutions. The former method is to process and store personal biometric data in local trusted environments integrated in personal mobile terminals, and the representative implementations include Apple Touch ID/Face ID and Windows Hello. Through local trusted computation, each user has full control of his/her biometric data without the risk of privacy leakage, but authentication services are restricted only to local mobile apps. As such, the services are secure but not open. The latter method uses a centralized system to collect and process biometric data in centralized-processing mode on public servers, and typical application scenarios include many payment platforms based on facial recognition, as described in Section 2.3. With the help of powerful servers, service providers can provide open biometric authentication services to various network applications efficiently. However, when raw biometric data or extracted feature data are stored by service providers in their database servers, users are put at risk of privacy leakages due to improper maintenance or malicious attacks. While user biometric data are fully controlled by service providers without strict regulation and independent audit, users have no control of their private data and are faced with the abuse of personal data. As a conclusion, the first method is secure but not open, while the second method is open but not secure. We need a framework that provides both secure and open biometric services.

In this paper, we propose BioShare, a framework that provides both secure and open biometric services.To achieve this goal, we store and process biomatric data in secure environments (terminal TEEs and server enclaves) to ensure security, and we coordinate the terminals and the servers to provide open services for network applications. Our framework is designed around three key principles:

a. Each user has full control of his/her biometric data. Biometric services are provided in either forwarding mode or authorized mode. In the forwarding mode, personal biometric data are stored in the user’s terminals. In the authorized mode, biometric data are temporarily stored in the server enclave under user authorization, and users can cancel the authorization at any time. Both modes ensure users have full control of their private data.

b. Open bioauthentication services are efficiently provided to network applications. We design standard interfaces for biometric services, develop service request handler modules running on the server side, and provide open services to network applications.

c. Biometric data are stored and processed in trusted environments to prevent privacy leaks. On the terminal side, we use Trusted Executive Environments to protect biometric data. On the server side, we use enclave technologies to ensure data security. We build secure channels between the terminal side and the server side using cryptographic technologies to ensure data security during transmission.

The BioShare framework is designed to provide open and secure biometric services with secure data storage both on terminal TEEs and server enclaves, and through standard interfaces between terminal–server interactions. We implemented BioShare with facial recognition as an example, and measured the performance of the implementation. Based on the test results, the end-to-end response time is 91 ms to 1011 ms, which meets business requirements in most human interactive scenarios, and the security strength is higher than 128 bits, which fulfils the recommended standard for business systems.

The rest of the paper is organized as follows: We enumerate related works in Section 2, describe key parts of our current design in Section 3, illustrate key challenges with a sample implementation in Section 4, and then measure and analyze the performance in Section 5. Finally, we discuss several open issues in Section 6 and conclude in Section 7.

2. Related Works

2.1. Biometric Identification on Personal Mobile Devices

Currently most biometric services on mobile terminals are implemented as local processing solutions, which is to say that they are secure but restricted to local mobile apps. Since fingerprint identification was introduced into iPhone 5s smartphones by Apple in 2013, biometric recognition technologies have undergone exponential development in the smartphone market. Apple provides biometric services Touch ID [7] and Face ID [8] on iOS platforms, and Microsoft offers Windows Hello [9] on personal Windows devices. Many proven biometric technologies are widely integrated into mobile devices: fingerprint [10,11], face [12,13,14], iris [15,16,17], vein [18,19], etc., and many other biometric modalities are under study: gait [20], keystroke [21], handwriting [22], etc. At the same time, auxiliary methods are used to prevent spoofing and attacks, such as liveness detection [23,24,25], 3D recognition [26,27], micro-expression recognition [28,29], and movement detection such as head-shaking or blinking [30,31]. In general, biometric services are conducted in terminal trusted environments and are provided for device unlocking, online payment, and bank account verification, etc. However, these services are limited to local apps and are not available for remote network applications.

2.2. Trusted Executive Environment

In local processing solutions, biometric data are processed and stored in local secured environments to ensure data privacy and service security. Currently, operating systems for both terminals and servers have become huge and complex because they must support multiple devices and rich applications. As a result, they have become more and more vulnerable, because system software vulnerabilities depend on code size and complexity [32]. Therefore, current CPUs offer a special execution environment isolated from the OS, such as ARM TrustZone [33,34,35], and Intel SGX [36,37] and RISC-V Keystone [38]).

On the terminal market, based on hardware capabilities, terminal manufacturers design and implement native TEE OS software, such as Qualcomm QSEE [39], Google Trusty TEE [40], and Huawei iTrustee, etc. GlobalPlatform defines GPTEE specifications [41,42] to resolve compatibility issues between different TEE OSes, and UnionPay releases TEEI infrastructure [43] to support the coexistence and intercommunication of multiple TEEs in the same CPU. On the server market, CPU manufacturers release original Software Development Kits (SDKs) for different CPU models, such as Intel SGX SDK [44] and RISC-V Keystone SDK [45], and some other companies provide unified open-source solutions to resolve the compatibility issues of different SDKs, such as Microsoft Open Enclave SDK [46], Google Asylo [47], and Huawei secGear [48], etc.

Currently TEE technology is used on either the terminal side or the server side to provide trusted computation environments for local applications; however, no solution is available to combine the terminal TEEs and server enclaves to form an integrated trusted environment.

2.3. Payment Platforms Based on Facial Recognition

As a typical implementation of centralized-processing solutions, most facial recognition payment systems are open to network applications, but they process user biometric data in unsecure environments on public servers. Since the first facial recognition payment system was launched by Uniqul in Finland in 2013 [49], the paying-with-your-face service is becoming more and more popular in China. Alipay launched smile-to-pay products named Dragonfly [50], Tencent issued face-payment devices named Frog [51], and UnionPay cooperated with 60+ banks to provide facial payment solutions to merchants [52]. All of these cases have one thing in common: Users must upload private biometric data to service providers, and service providers store and process user biometric data in centralized mode on background servers. However, when biometric data are stored by service providers in their database servers, users are put at risk of privacy leakages due to improper maintenance or malicious attacks. When biometric data are processed by service providers without strict regulation and independent audit, users will lose control of their biometric data and face the abuse of personal data.

3. BioShare Design

The goal of BioShare is to provide trusted biometric authentication services to network applications under users’ full control of personal biometric data. It is designed to achieve:

a. Self-determination: As the owner of personal biometric data, each user is entitled to grant or cancel the authorization to the server at any time, and can specify or change authorization conditions such as a specified number of times, specified time period, whitelist, or blacklist.

b. Open Service: Biometric authentication services can be opened up to network applications rather than being restricted to local applications, and therefore, standard interfaces should be defined for the external invocation and internal processing of service requests.

c. Privacy Protection: All biometric data must be stored and processed in trusted environments to prevent privacy leaks, and all critical operations such as encryption and decryption must be conducted in trusted environments to ensure security.

The following subsections describe how our BioShare design achieves the aforementioned goals. First, we provide an overview of our framework, and then we describe the key components of our framework: the terminal-side modules, including User Application and Trusted Application, the server-side modules, including Service Application and Enclave Module, and the secured channels between both sides.

3.1. Overview

We designed a unified and scalable infrastructure for BioShare that combines the capabilities of both the terminals and the server to conduct trusted biometric authentication and provide open services to various network applications under user authorization. Figure 1 shows a high-level view of the BioShare framework. It consists of five main components:

a. User Application (UA). BioShare UA is an app deployed on user terminals to conduct user-interactive actions, such as user signup, service registration, and authorizing the server to perform biometric authentication.

b. Service Application (SA). The SA is designed to handle service requests from network applications and calls Trusted Application (TA) or Enclave Module (EM) to conduct biometric authentication.

c. Trusted Application (TA). The TA provides trusted biometric services, such as biometric recognition and comparison, in trusted executive environments (TEE) on the terminal side.

d. Enclave Module (EM). The EM provides trusted biometric services on the server side under user authorization.

e. Secured Communication Module (SCM). The SCM provides secure channels between user terminals and the server.

In the design of BioShare, standard interfaces are defined as API libraries for the external invocation and internal processing of service requests, as shown in

Table 1. Standard Interface for BioShare.

Module	API Function	Description
User Application (UA)	bool authenticate(    int biometricType,    byte[] biometricData)	(Internal Interface) Handle authentication requests from SA by calling TA function, parameters including biometric type and biometric data
Trusted Application (TA)	bool acquireFeatureData(    int biometricType)	(Internal Interface) Acquire biometric raw data of the current user with hardware sensors, conduct biometric recognition on raw data, and store feature data into secure storage parameters including biometric type (such as facial, fingerprint, etc.)
	bool authenticate(    int biometricType,    byte[] biometricData)	(Internal Interface) Conduct biometric comparison between biometric data input and feature data of the current user, parameters including biometric type, and biometric data
	byte[] exportFeatureData(    int biometricType)	(Internal Interface) export the biometric feature data of the current user from TEE in an encrypted format, parameters includingbiometric type
Service Application (SA)	bool authenticate(    String userId,    int biometricType,    byte[] biometricData)	(Open Service Interface) Handle biometric authentication requests from Network Applications, parameters including user ID, biometric type and biometric data
	bool registerService(    String userId,    String terminalId,    Map<String,String> params)	(Internal Interface) Handle register-service requests from User Application, inputs including user ID, terminal ID, andadditional parameters.
	bool authorizeServer(    String userId,    String terminalId,    int biometricType,    byte[] featureData,    Map<int,object> options)	(Internal Interface) Handle authorize-server requests from User Application, parameters including user ID, terminal ID, biometric type, encrypted biometric feature data, and authorization options.
Enclave Module (EM)	bool authenticate(    string userId,    int biometricType,    byte[] biometricData)	(Internal Interface) Conduct biometric comparison between feature data input and feature data of user input, parameters including user ID, biometric type, and the biometric data input
	bool importFeatureData(    String userId,    int biometricType,    byte[] encryptedFeatureData)	(Internal Interface) Import the biometric feature data of a user into server enclave, parameters including user ID, biometric type and feature data in an encrypted format
Secured Communication Module (SCM)	byte[] encryptMessage(    byte[] plainMsg)	(Internal Interface) Encrypt a message with the symmetric encryption algorithm, parameters including plain text message
	byte[] decryptMessage(    byte[] encryptedMsg)	(Internal Interface) Decrypt a message with the symmetric encryption algorithm, parameters including the encrypted message
	byte[] signMessage(    byte[] msg)	(Internal Interface) Sign a message, parameters including the message

. This facilitates the development and deployment of new biometric authentication services for open access under user control. For example, a new iris authentication service can be implemented by replacing the biometric recognition algorithm and making minor changes to the User Application. Current terminal manufacturers can easily extend their biometric services to network application scenarios with unified infrastructure and standard interfaces.

3.2. User Application (UA)

A key design principle for BioShare is that the framework should enable each user to control his/her biometric data handily and to authorize the server efficiently on personal mobile terminals. We develop a user application and deploy it on user terminals. The UA handles user commands as illustrated in Algorithm 1. The major functions include:

User Signup: Each user inputs his/her basic information, including user name, mobile phone number, identity card number, etc., and UA verifies the authenticity of data input and creates an account for the user. Please be reminded that each user can log in on multiple terminals simultaneously with the same account.

Service Registration: Currently, most mobile terminals are capable of providing biometric services to local apps. We extend the service object from local applications to network applications through a service-registration mechanism: a. The user registers terminal biometric capabilities to the server in UA and the server maintains a user-registration database. b. When the server receives biometric authentication requests for the user from network applications, it will forward the requests to the user’s terminals through standard interfaces of UA, listed in Table 1. c. On the terminal side UA coordinates with Trusted Application (TA) to conduct biometric authentication, and return the result to the server. The service-registration mechanism successfully expands the biometric capabilities of user terminals to empower network applications, but the service may sometimes be unstable due to network issues or terminal power-off.

Authorizing the Server: BioShare is designed as a general framework for various biometric services, including facial authentication, fingerprint authentication, and other biometric services, so users can choose a specific biometric type and authorize the server to conduct the biometric authentication. To provide stable services, each user can authorize the server to conduct biometric authentication with the following process: a. In UA, the user authorizes the server to conduct specified biometric authentication (such as facial authentication, fingerprint authentication and so on) with specified options, such as a specified number of times, specified time period, whitelist or blacklist, etc., and the server updates authentication information of the user in the user-registration database. b. UA exports the user’s private biometric data from the terminal TEE and imports it into the server enclave, and the data will be stored temporarily in the server enclave according to authorization options. c. When the server receives biometric authentication requests from network applications, it will call the Enclave Module to conduct biometric authentication with stored biometric data and return the result. Each user may cancel his/her authorization anytime and anywhere, and accordingly, his/her private data will be purged from the server enclave.

Algorithm 1 Request-Handling Process in User Application

Input:  The ID Value of the Current User, $userId$; Request Action, $requestAction$; Request Data, $requestData$ Output:  Result (true or false), $returnResult$  1: Initialize $returnResult$ with 0  2: if$requestAction$ = UserSignUp then  3:     Verify requestData  4:     Call TA to acquire biometric data with hardware  5:     Create a new account for $userId$  6:     return true  7: else if$requestAction$ = ServiceRegistration then  8:     Call SA to create new UserRecord into database set       UserRecord.UserId = $userId$ and       UserRecord.TerminalId = $requestData$.TerminalId  9:     return true  10: else if$requestAction$ = AuthorizeServer then  11:     Call SA to update database set       serRecord.ServerAuthorized=true and       serRecord.AuthorizeOptions = $requestData$.AuthorizeOptions       where UserRecord.UserId = $userId$ and       UserRecord.TerminalId = $requestData$.TerminalId  12:     Call SCM to build a secure channel between TA and EM  13:     Transfer Biometric Data of the current user from TA to EM  14:     return true  15: else if$requestAction$ = AuthenticateUser then  16:     Validate the service request  17:     Call TA to conduct biometric authentication  18:     return authentication result from TA  19: end if  20: return$returnResult$

3.3. Service Application (SA)

BioShare achieves the goal of providing open services via the Service Application running on the server, and Algorithm 2 shows the process flow in detail. SA listens for biometric authentication requests from remote network applications, verifies the request data, and checks the user in the user-registration database. If the user has registered the biometric service, SA will process the request with either of the following modes:

Forwarding Mode: If the user does not authorize the server to conduct biometric authentication, then SA will forward the request to the user terminals, and on the terminal side, UA coordinates with TA to conduct biometric authentication and returns the result to the server, as described in step “Service registration” of Section 3.2.

Authorized Mode: If the user has authorized the server, SA will call Enclave Module to conduct biometric authentication and return the result, as described in step “Authorizing the server” of Section 3.2.

The BioShare Service Application is also designed to handle command requests from the users, including service-registration requests and authorizing-the-server requests, which are described in Section 3.2. The server maintains a user-registration database that records the registration and authorization information for each user.

Algorithm 2 Process for Handling Service Requests from Network Applications

Input:  The ID of The Target User, $userId$ Biometric Modality Value, $biometricType$ Biometric Feature/Raw Data, $biometricData$ Output:  Authentication Result, $returnResult$       (0-false/1-true/-1-failed)  1: Initialize $returnResult$ with -1  2: Receive service requests from Network Applications  3: Verify input data  4: Search database for UserRecord where       UserRecord.UserId=$userId$  5: if UserRecord IS NOT NULL then // user registered  6:     if UserRecord.ServerAuthorized = false then             //forwarding mode  7:         Connect to the terminal with UserRecord.TerminalId  8:         Call SCM to build a secure channel to TA through UA  9:         Call TA to conduct biometric authentication  10:        $returnResult$ = authentication result of TA  11:     else // authorized mode  12:         Call EM to conduct biometric authentication  13:         $returnResult$ = authentication result of EM  14:     end if  15: end if  16: return$returnResult$

3.4. Trusted Application (TA)

The trusted application is a module running in terminal TEE that receives calls from the UA and conducts biometric operations through the standard interfaces listed in Table 1. Because all actions are performed in the terminal TEE and all private data are stored in tamper-resistant secure storage, biometric services from TA are secure and trusted.

Biometric Data Acquisition: TA captures biometric raw data through biometric hardware integrated into mobile terminals, such as fingerprint devices, cameras, and other devices. TA calls the hardware driver to control the biometric sensor, the sensor captures raw data and writes it to a memory buffer, and finally, the raw data are copied to secure memory.

Biometric Recognition: Biometric recognition transmutes biometric raw data into feature data in the terminal TEE. A typical process of biometric recognition consists of three steps: a. Data processing. TA processes the raw data with specified algorithms, such as biometric detection algorithms. b. Liveness detection. As an option, TA performs liveness detection with infrared images, RGB images, or depth images, etc. c. Feature extraction. TA extracts feature data from raw data using a specified model. Taking face recognition as an example, the typical process includes face detection, liveness detection, and facial feature extraction.

Secure Data Storage: Biometric feature data are stored in secure storage in terminal TEEs and are protected by hardware isolation to ensure privacy protection, and only trusted applications (TAs) can obtain permissions to access biometric data in TEE mode. When biometric data are moved from secure storage to insecure environments, they are encrypted by the SCM module to ensure data security, as in Section 3.6.

Biometric Comparison: TA conducts a biometric comparison by calculating the similarity between source feature values and the target feature values. If the similarity score exceeds the threshold value, TA returns a success, otherwise it returns a failure. To ensure security, private biometric data are transmitted to TA in encrypted formats, and are decrypted in the terminal TEE before biometric comparison.

Constraints: Terminal TEE is a restricted zone in mobile CPU platforms with limited capabilities, and the limitations include CPU speed, maximum RAM, and maximum secure storage, etc.

Table 2. TEE Capabilities of Typical CPUs.

CPU Model	TEE	CPU Cores	Max RAM	Max Secure Storage
SamSung Exynos 1080	ARM Trustronic	8	100 MB	5 MB
Qualcomm Snapdrago 888	QSEE	8	100 MB	16 MB
Hisilicon Kirin 9000	iTrustee	8	48 MB	12 MB

lists the TEE capabilities of typical CPUs. We therefore chose algorithms and models with low computing and memory costs in the implementation of biometric recognition and comparison.

3.5. Enclave Module (EM)

The Enclave Module is a module running on the server side that conducts biometric recognition and comparison using the standard interfaces listed in Table 1. During the user-authorizing process, EM exports private biometric data from Terminal TEEs and stores it temporarily in the server enclave, as described in Section 3.2. Based on the data, EM can conduct biometric authentication without the intervention of user terminals. Because all actions are performed in the server enclave, biometric services provided by EM are secure and trusted.

Biometric recognition: Biometric recognition transmutes biometric raw data into feature data. EM conducts biometric recognition with the same algorithm and the same steps as TA on the terminal side: data processing, and liveness detection and feature extraction, as described in Section 3.4.

Biometric comparison: EM on the server side conducts a biometric comparison with the same algorithm as TA on the terminal side, which is described in Section 3.4.

Privacy Protection: Within BioShare, the security mechanisms for server enclaves are used to protect biometric data during both storage and processing. Specifically, the EPC (Enclave Page Cache) protects all EM code and data in encrypted format during runtime state, the Sealing/Unsealing mechanism secures EM data in encrypted format during persistent storage, and the Attestation technology ensures that genuine code runs in secure enclave environments to avoid data interception and code tampering.

Constraints: Server enclaves are protected execution environments with restricted capabilities, and the restrictions include available CPU cores, maximum RAM, and memory access latency, etc. Meanwhile, in EM, we have to choose the same algorithm as that of TA on the terminal side due to the incompatibility of different algorithms.

3.6. Secured Communication Module (SCM)

The Secured Communication Module ensures secure and undeniable communication between user terminals and the server through cryptographic techniques such as symmetric encryption, asymmetric encryption, and hash and digital signatures. To ensure security, all encryption/decryption actions are conducted in the trusted environment of either the server or the terminal. Secured communication channels combine terminal TEEs and the server enclave, forming an integrated trusted environment for trusted computing.

Secured Channels: Before the server and the terminal communicate with each other, for example, the UA module on the terminal authorizes the server in Section 3.2 and Algorithm 1 and the SA module on the server forwards service requests to the user terminals in Section 3.3, we use an asymmetric encryption algorithm RSA (with a key length of 3072 bytes) to build secure communication channels between the server and the terminal. RSA algorithms with a key length of 7680 bytes will provide higher security, and alternative algorithms include ECC algorithms with key lengths of 256/384 bytes. First, random numbers are generated in the server enclave and terminal TEEs, then public/private key pairs are generated on both sides, based on the random numbers with an asymmetric encryption algorithm (i.e., the RSA or ECC algorithm). Finally, private keys are stored in trusted environments and public keys are exchanged with each other. Please be reminded that asymmetric encryption applies only to small data sets due to high computing costs.

Data Encryption: In BioShare, user biometric data are only processed in secure environments including terminal TEEs and server enclaves, and that are transferred in encrypted format outside secure environments and decrypted in secure environments to ensure data security and privacy protection. We use the symmetric encryption algorithm AES-128 to efficiently encrypt/decrypt the biometric data during terminal–server communications. The following are the main steps: a. A random number is generated for each user by the hardware device in the server enclave. b. A working key is generated for the user based on the random numbers using the symmetric encryption algorithm (i.e., AES), and saved in the server enclave. c. The working key is encrypted with the terminal public key and sent to the user’s terminal. d. The working key is decrypted and stored in the terminal TEE, so that both sides share the same working key.

Digital Signatures: To ensure nonrepudiation, we use digital signatures on both the server and terminal sides. In the terminal TEE, a message can be signed with the following steps: a. Calculate the hash value for the target message with the hash algorithm SHA-256. b. Encrypt the hash value with the user’s private key. c. Send the message along with the ciphertext to the server. On the server enclave, the message can be verified via the following steps: a. Decrypt the ciphertext to a plaintext format. b. Calculate the hash value for the message with the SHA-256 algorithm. c. Check whether the hash value is consistent with the plaintext. Digital signatures are used in the return values of the SA module as a response to service requests from network applications as in Section 3.3 and Algorithm 2.

4. Sample Implementation

BioShare is currently implemented with facial recognition as an example, and deployed on Android mobile terminals with TEE communicating with a server with enclaves. The following sections describe several implementation details and challenges specific to our current implementation.

4.1. General Information

In our implementation, we chose mainstream CPU architectures with dominant TEE platforms, specifically ARM Cortex-A architecture with ARM TrustZone on the terminal side, and Intel Xeon E3 CPU with Intel SGX support on the server side.

Table 3. The Configurations of Mobile Terminals and the Server.

	Terminal	Server
CPU	Mediatek MT8788 (ARM Cortex-A)	Intel Xeon E3
RAM	1.3 GB	64 GB
TEE	ARM TrustZone	Intel SGX
OS	Android 9.0	CentOS Linux 7.4
TEE OS	Nebula TEEI 1.1.0

lists the configurations of the hardware and software on each side.

4.2. User Application (UA)

The BioShare User Application is implemented as an Android app that is deployed on mobile terminals. The key challenge in the implementation of UA is to maintain a reliable connection between the terminals and the server in a changing environment.

TCP Connections: The user application either creates a short TCP/IP connection to the server for each call, or keeps a long connection with the server for a certain period. The former requires lower resource costs, while the latter shows better performance.

Notification Mechanism: Because Android or iOS kills the application running in the background automatically at irregular intervals, the User Application may be unreachable to the server from time to time. We need a notification mechanism through which the service application can notify the terminal to relaunch the user application at any time. Apple Push Notification Service [53], Google Firebase Cloud Messaging [54], and other third-party products provide reliable notification services for iOS and Android devices.

4.3. Service Application (SA)

The BioShare Service Application is implemented as two system service processes running in the background. One service process is responsible for handling the command requests from user applications on the terminal side, while the other is responsible for handling the service requests from network applications. The two processes coordinate with each other by sharing the same user-registration database.

We have developed two different experiments in which network applications call the biometric service in either forwarding mode or authorized mode. Experimenters can currently register terminal biometric capabilities to the server in the User Application on the terminal side, then the biometric service on the server will run in forwarding mode and all service requests from network applications will be forwarded to the user’s terminals registered. Furthermore, experimenters can also authorize the server in the User Application; accordingly, the biometric service on the server will run in authorized mode and all service requests from network applications will be handled locally by the Enclave Module on the server.

4.4. Trusted Application (TA)

The BioShare Trusted Application is implemented as a trusted module deployed in the Trusted Executive Environment on the terminal side. The key challenge is the choice of the appropriate biometric algorithms and implementations for facial recognition and comparison, due to the limitations of TEE capabilities. We attempt to choose open-source implementations with complete functionality, good performance, low computing and memory overheads, embedded-environment support, and appropriate licensing agreements.

Facial Recognition and Comparison: Currently, many open-source projects for facial recognition are available from GitHub, and

Table 4. Typical Opensource Projects for Facial Recognition.

Open-Source Project	Functionality		Hardware Support		Language	License
	Recognition	Comparison	X86	Embedded
SeetaFace Engine	Yes	Yes	Yes	Yes	C++	BSD
SeetaFace Engine2	Yes	Yes	Yes	Yes	C++	BSD
SeetaFace2	Yes	Yes	Yes	Yes	C++	BSD
FaceBoxes	No	No	Yes	Yes	C++	BSD
libfacedetection	No	No	Yes	Yes	C	BSD
OpenCV 4	Yes	Yes	Yes	No	C++	BSD
RetinaFace	Yes	Yes	Yes	No	Python	MIT
deepinsight/insightface	Yes	Yes	Yes	No	Python	MIT

lists some popular projects. In our implementation, we chose SeetaFace2 because it is built with C++, is independent of third-party libraries, and is compatible with X86, iOS, and Android systems. We used pretrained models from the SeetaFace2 project. According to the SeetaFace2 document, Cascaded-CNN is used as a face-detection algorithm, achieving 92% in the FDDB public dataset. FEC-CNN is used as a face landmaker algorithm, achieving a 0.069 average positioning error on the 300-W Challenge public dataset. ResNet50 is used for facial feature extraction/comparison with 25 million parameters, and the model has been pretrained with 33 million photos with an accuracy rate of more than 98% in the general 1:N scenario on a 1000-person dataset when the error acceptance rate is 1%. Figure 2 shows the flow chart of the processes.

Liveness Detection: We chose the open-source project FeatherNets for liveness detection in the implementation, because several models provided by the project achieve the goal of low computing cost (about 80 M FLOPs), small model size (0.35 M parameters), and complete functionality (applicable to infrared images and depth images, etc.).

Table 5. Test Results of Liveness Detection Models.

Model	ACER	TPR@FPR = 1%	TPR@FPR = 0.1%	FLOPS
FishNet150	0.00144	0.999668	0.998330	6452.72M
FishNet150	0.00181	1.0	0.9996	6452.72M
FishNet150	0.00496	0.998664	0.990648	6452.72M
MobileNet v2	0.00228	0.9996	0.9993	306.17M
MobileNet v2	0.00387	0.999433	0.997662	306.17M
MobileNet v2	0.00402	0.9996	0.992623	306.17M
MobileLiteNet54	0.00242	1.0	0.99846	270.91M
MobileLiteNet54-se	0.00242	1.0	0.996994	270.91M
FeatherNetA	0.00261	1.00	0.961590	79.99M
FeatherNetB	0.00168	1.0	0.997662	83.05M
Ensembled all	0	1	1	-

shows the test results of the models within the FeatherNets project.

4.5. Enclave Module (EM)

The BioShare Enclave Module is implemented as trusted code that runs in the Intel SGX enclave on the server side. On other TEEs such as ARM TrustZone and RISC-V keystone, we have to develop new code due to incompatibilities between them. In order to achieve the goal “develop once and deploy anywhere”, we use Microsoft Open Enclave SDK [46] to resolve compatibility issues between different TEEs, and other opensource projects including Google Asylo [47] and Huawei secGear [48] etc., provide similar functionality.

We have developed invocation interfaces to authenticate both facial image data and facial feature data, and experimenters can specify either raw data or feature data in service requests from network applications. We use the open-source code SeetaFace2 to conduct facial recognition and comparison. If the input is facial feature data, the service request will be processed with high performance due to the low computing overhead of the feature comparison algorithm, but this is achieved with low compatibility because the input feature data must be extracted with the same algorithm as that of the Enclave Module. If the input is facial image data, the service request will be processed with higher computing costs but with better compatibility. The experimental results are described in Section 5.2.

4.6. Secured Communication Module (SCM)

The BioShare Secured Communication Module is implemented as trusted functions running in trusted environments on both the terminal and server sides to provide cryptographic services. In our implementation, we choose Advanced Encryption Standard (AES) as the symmetric encryption algorithm and specify 128 or 192 bytes as the key length to ensure a sufficient encryption intensity. We select RSA or ECC as the asymmetric encryption algorithm, specify 3072 or 7680 bytes as the key length for RSA, and 256 or 384 bytes as the key length for ECC; and we specify the SHA-256 algorithm in the hash value calculation.

During the entire lifecycle of each transaction, all biometric data are transmitted in encrypted format in untrusted environments, and decrypted and processed only in trusted environments; and the result is returned with a digital signature to ensure non-repudiation.

5. Evaluation and Analysis

We now evaluate and analyze BioShare in terms of terminal-side performance, server-side performance, communication performance, and holistic security.

5.1. Overview

BioShare processes service requests from network applications in either forwarding mode or authorized mode, and we measure the time overhead of processing a service request in both modes.

In forwarding mode, the server forwards the service request to the user terminal, as shown in Figure 3. The total overhead of processing a service request varies from 91 ms to 1011.5 ms, and the major parts are the request-processing cost and the server-client communication cost, which are evaluated in Section 5.2 and Section 5.4.

In authorized mode, the server processes service requests in the server enclave under user authorization, as shown in Figure 4. The total overhead of processing a service request varies from 16.1 ms to 168.6 ms, and the major part is the request-processing cost, which is evaluated in Section 5.3.

5.2. Performance Evaluation of Terminal TEE

We measure the performance of the terminal TEE in conducting facial authentication upon different data inputs. The overhead of face recognition is 507.1 ms upon facial raw image input, while the overhead of face comparison reduces to 1.6 ms upon facial feature data input, as shown in

Table 6. Overhead of TA in Processing Facial Recognition.

Input	Action	Time (ms)
Facial Image Data	Face Recognition	507.1
Facial Feature Data	Face Comparison	1.6

. Figure 5 shows the cumulative distribution of time consumption in face recognition, and we can see that the performance of the terminal TEE is quite stable. We perform further research on each step of face recognition and find that feature extraction and liveness detection are the most time-consuming steps, accounting for 70.9% and 22.9%, respectively, as shown in Figure 6.

We measure the prediction accuracy rate of facial recognition with an actual business dataset of 329 pre-captured photos with a resolution of 640 × 480 from 110 employees. In the test, we compare each photo in the dataset with other photos, and the test results are shown in

Table 7. Test Results of Facial Recognition and Comparison.

Actual Result	Prediction Result
	TRUE	FALSE
TRUE	323 (TP)	5 (FN)
FALSE	29 (FP)	53599 (TN)

. The accuracy rate is 99.937%, the false acceptance rate (FAR) is 0.054%, and the false rejection rate (FRR) is 1.524%, which meets business requirements in most scenarios.

We measure the performance difference between the terminal TEE and the server enclave during facial authentication. To ensure the comparability of experimental results, we specify that the same algorithmic code runs in a single thread on a single CPU core in both environments. The evaluation results show that the face-recognition cost of the terminal TEE is more than three times that of the server enclave, the face-comparison overhead on both sides is as low as 1–2 ms, and the face-recognition accuracy is equal on both sides. Please refer to Figure 7 for more details.

5.3. Performance Evaluation of Server Enclave

The key challenge with server-side facial authentication is the performance of the server enclave, which differs across CPU platforms. Our demo implementation works fine on the Pentium Silver CPU enclave with four physical cores and 128 MB RAM at most for low or moderate load scenarios, but more powerful enclave environments with more CPU cores and higher RAM support are required in high load scenarios.

Table 8. Key Indicators of Enclaves on Different CPU Platforms.

Key Indicators	Pentium Silver	Xeon E3	Xeon SP Ice Lake
Maximum Physical Cores	4	6	80
Maximum Encalve RAM	128 MB	128 MB	1 TB
Encalve Dynamic Memory Management	Yes	No	Yes

lists some key indicators of enclaves on specific Intel CPU platforms.

Generally, the performance overhead of server enclaves consists of three major parts: enclave memory access latency, enclave switching cost, and enclave dynamic-memory-management cost. Figure 8 lists the evaluation results of the three parts in professional tests [55]. Specifically, on the Intel Xeon Icelake platform, the overhead caused by enclave memory access latency is almost negligible, the enclave switching cost is less than 10,000 CPU lifecycles, and the enclave dynamic-memory-management cost is quite high. The performance analysis is instructive for further optimization of the current implementation.

5.4. Performance Analysis of Mobile Communication

Most user terminals communicate with the server through short or long TCP/IP connections over a 4G/5G network, and we measure the end-to-end delays of different communication methods. Based on the experiment, the average delay is 39.7 ms for one-way trips between the terminal and the server, long TCP/IP connections have lower latency than short connections (average 21.1 ms vs. 58.3 ms), and 5G networks show better performance than 4G (average 27.3 ms vs. 52.1 ms). Figure 9 shows the experimental results in detail.

We have performed further research on the performance of the notification mechanism used in BioShare. We kill the user application on the user terminal, relaunch it with the notification services [56], and measure the communication delay from the server to the terminal. Based on the experiment, it takes 415 ms for Aurora Mobile JPush to notify the terminal from the server, which is close to the reported time delay for Apple Push Notification Service and Google Firebase Cloud Messaging, as shown in

Table 9. Normal Delay of Notification Services.

Provider	Platform	Notification Service	Delay (ms)
Apple	IOS	Apple Push Notification Service	400
Google	Android	Firebase Cloud Messaging	500
Aurora Mobile	Android/iOS	Aurora Mobile JPush	415

.

5.5. Security Analysis of BioShare

We evaluate the security level of secure communication channels between the terminal TEE and the server enclave by analyzing the cryptographic algorithms used in BioShare, as shown in

Table 10. Security Strength of Cryptographic Algorithms of BioShare.

Category	Algorithms	NIST Recommendations (Key Length)	Algorithms of BioShare
			Algorithm	Key Length	Security Strength
Symmetric encryption	AES	128+	AES-128	128	128
			AES-192	192	192
Asymmetric encryption	RSA	2048+	RSA	3072	128
			RSA	7680	192
	ECC	224+	ECC	256	128
			ECC	384	192
Hash	SHA	224+	SHA-256	256	256

. In the implementation, we specify key lengths of 128/192 for the AES algorithm; thus, the security strength of symmetric encryption is 128/192. We specify key lengths of 3072/7680 for the RSA algorithm and key lengths of 256/384 for the ECC algorithm, and therefore, the security strength of asymmetric encryption is 128/192. We use SHA-256 as the hash algorithm, and the security strength is 256. In conclusion, the security strength of secure communication channels is 128/192, which fulfils and even exceeds the values recommended by the National Institute of Standards and Technology (NIST) [57].

The terminal TEE empowers the Trusted Application with secure hardware, secure OS, secure storage, and secure provisioning, etc. The server enclave empowers the Enclave Module with isolated execution, encrypted RAM, secure storage, sealing and attestation mechanisms, etc. The TEEs on both terminal and server sides provide trusted environments to process and store biometric data at a high security level, and

Table 11. Security Properties of Terminal TEE and Server Enclave.

Security Properties	Terminal TEE (ARM Trustzone)	Server Enclave (Intel SGX)
Isolated Execution	Yes	Yes
Encrypted RAM	No	Yes
Secure Storage	Yes	Yes
Remote Attestation	Yes	Yes
Secure provisioning	Yes	Yes
Privileged software attack defense	Yes	Yes
Trusted Path	Yes	No

lists some security properties of trusted environments.

6. Discussion and Future Work

This paper makes the case for biometric authentication as a trusted service under users’ full control, and demonstrates how we addressed several challenges in making this service secure, practical, and efficient. Our solution reconciles the demand for open services and the requirement for privacy security, and shows comparative advantages over the currently available solutions.

Table 12. Security Properties of Terminal TEE and Server Enclave.

Objectives	Local-Processing Solutions	Centralized-Processing Solutions	BioShare
Each user has full control of his/her biometric data	Yes (Biomatric data are stored in the local secure storage of private mobile terminals)	No	Yes (Each user can authorize the server to conduct biometric authentication or cancel the authorization at any time)
Open biometric services	No (The service is restricted to local mobile apps)	Yes (The service is open to network applications)	Yes (The service is open to network applications)
Biometric data storage	Secure storage (Terminal TEEs)	Nonsecure storage(Public databases)	Secure storage (Terminal TEEs and Server Enclaves)
Biometric data processing environment	Trusted Environment (Terminal TEEs)	Nontrusted environment (Public servers)	Trusted Environment (Terminal TEEs and Server Enclaves)
Biometric datatransmission	Not applicable (Localprocessing)	Secure/unsecure	Secure channels, the data are transmitted in decrypted format
Prevent data leakage	Yes	No	Yes
Resisting data interception and code tampering attacks	Yes (Attestation mechanism of terminal TEE)	No	Yes (Attestation mechanism of server Enclave)
Resisting memory dumpattacks	No	No	Yes (Enclave memory protection mechanism)
Resisting privileged codeattacks	Yes (Isolated Execution mechanism of terminal TEEs)	No	Yes (Isolated Execution mechanisms of terminal TEEs and server Enclaves)

lists the details of the comparisons. When compared to terminal local-processing solutions, such as Apple Touch ID and Windows Hello, as shown in Section 2.1, our solution extends open biometric authentication services from local mobile apps to remote network applications with high security levels. When compared to centralized-processing solutions such as facial recognition payment systems, as listed in Section 2.3, BioShare can avoid both unintentional leakages and the intentional abuse of biometric data by keeping private data in an encrypted format within secure storage, and running trusted code in isolated secure environments. Based on our test results, the BioShare implementation meets the performance requirements of most human-interactive businesses and fulfills the security requirements of recommended standards for business systems.

We now discuss important challenges that are outside the focus of this paper.

TEE Fragmentation: BioShare relies on terminal TEEs and server enclaves to handle service requests; however, the TEE market as a whole is currently fragmented. In both terminal and server markets, different manufacturers offer different TEE solutions that are incompatible with each other, such as QSEE/iTrustee on the terminal side and SGX/TrustZone on the server side, and therefore, we have to develop native code for each manufacturer, and even for each system model. This tremendously increases the development costs and implementation complexity for large-scale applications of BioShare, and we need a universal standard and interface protocol for terminal TEEs as well as server enclaves.

Network Attacks: BioShare opens up terminal capabilities to network applications, meaning that the terminals are faced with various network attacks, such as replay attacks and man-in-the-middle attacks. In addition, the server connects to numerous terminals through TCP/IP connections, and therefore is put at risk of cyber-attacks such as impersonation attacks and distributed denial of service attacks. We need to design defense technology and systems against various network attacks on user terminals, as well as the BioShare server.

Business Model: BioShare relies on users to install the User Application on individual terminals, raising the question of whether there are proper incentives for users to do so. We need a business model for BioShare to ensure that all participants can benefit from service provision. One possible solution is to charge a fee for each service request from network applications, and reward the user with a certain proportion of the income.

7. Conclusions

In this paper, we make the case for a unified framework that provides trusted biometric authentication services to network applications under the user’s full control of personal biometric data. Our demo implementation of BioShare provides: (a) authorized and forward service modes to ensure users’ full control of personal data, (b) standard interfaces to ensure service openness to network applications, (c) trusted computation to prevent privacy leaks on both terminal and server sides, (d) secure channels to ensure data security during transmission, and (e) a unified framework to ensure effective collaboration between user terminals and the server. We showed that our system is efficient, based on standard interfaces, and provides a unified terminal–server collaboration mode to support new biometric services under user control. As part of our future work, we are designing standard TEE solutions to facilitate the development of new biometric service experiments, developing defense technology and systems against various network attacks, and exploring business models to ensure that each user benefits from participation.