Privacy-Preserving Solution for European Union Digital Vaccine Certificates

Abstract

The recent COVID-19 pandemic situation highlights the importance of digital vaccine certificates. In response, the European Union (EU) developed EU Digital Vaccine Certificates to enable proof of non-infectivity and completed vaccinations. However, these solutions suffer from several shortcomings, such as ineffective certificate holder identification and a high violation of user privacy with the disclosure of sensitive information. In this work, we present a novel solution for privacy-preserving EU Digital Vaccine Certificates. Our solution solves the aforementioned privacy and security shortcomings and is in line with current EU legislation, i.e., the General Data Protection Regulation (GDPR), the upcoming revision of the electronic IDentification, Authentication, and trust Services (eIDAS), called regulation eIDAS 2.0, and the new tools that it envisages to be led by European digital identity. This identity is intended to allow citizens to prove their identity to access online services, share digital documents, or simply prove specific personal characteristics such as age without revealing their identity or other personal information. The core of our proposal is built on our novel attribute-based credential scheme, which can be easily implemented on various handheld devices, especially on Android smartphones and smartwatches. However, due to the lightweight nature of our scheme, it can also be implemented on constrained devices such as smart cards. In order to demonstrate the security, privacy, and practicality inherent in our proposal, we provide the security analysis of the cryptographic core along with a set of experimental results conducted on smartphones and smart cards.

1. Introduction

The COVID-19 pandemic era has significantly accelerated cooperation and development of e-healthcare. Various experts, researchers, medics, technicians, and society as a whole have to promptly design and develop many efficient tools that help to beat and mitigate this worldwide disease. Since 2020, several digital approaches, tools, and applications have been proposed and deployed. These technologies and services usually aid in digital contact/contactless tracing, infection tracking, patient monitoring, checking immunity, or injecting vaccination doses. Examples of such applications include COVID-19 certificates. On the one hand, these solutions have to be functional, robust, and resilient across borders; secure; and immune to their misusing. In fact, keeping users’ privacy is an essential requirement for society. A way to achieve the aforementioned properties is by deploying Privacy-Enhancing Technologies (PETs) and, more specifically, attribute-based authentication schemes.

Attribute-based authentication schemes help preserve user privacy by verifying only necessary pieces of a user’s private information. In comparison with classic authentication schemes, these schemes verify only the possession of specific attributes, e.g., age, driving license, authorization to access a protected area, type of traffic ticket, or possession of a COVID-19 certificate. Attribute-based schemes do not require the verification of specific user identities, such as IDs, user public keys, and shared passwords, that could cause unwanted linking and tracking of individuals.

Despite the fact that global pandemic situation is slowly weakening in the world, secure and privacy-preserving COVID-19 or non-infection certificate solutions will be required further. COVID-19 certificate applications can be divided into two basic groups: (1) currently deployed/used solutions, and (2) experimental/academic solutions still under development. The first group includes applications that are used to prove non-infectiousness. These solutions are mainly focused on the usability of the application rather than on data privacy protection, e.g., European Union (EU) Digital COVID Certificates (DCC) (https://commission.europa.eu/strategy-and-policy/coronavirus-response/safe-covid-19-vaccines-europeans/eu-digital-covid-certificate_en, accessed on 5 March 2023). Further, some commercial applications are providing a certain level of privacy protection and are often integrated into larger health data management systems. An example is the IBM Digital Health Pass [1], which integrates test results and other health data into one system. Finally, the ongoing development of experimental solutions try to overcome the main issues of the previous applications, primarily focusing on protecting personal data. Well-known and experimental solutions from both groups are extensively explored in Section 2.

Generally speaking, current solutions are not compatible with the EU DCC, and those that are compatible suffer from several shortcomings, such as inefficient identification of the certificate holder and high invasion of user privacy with disclosure of sensitive information. Therefore, we need to find a solution for digital EU vaccination certificates that will protect citizens’ privacy. This solution should solve the mentioned shortcomings in the field of privacy and security and be in accordance with the applicable EU legislation.

The paper is organized as follows. Section 2 presents the related work and our contribution. Section 3 presents the security and privacy issues of existing EU DCC solutions. Section 4 outlines the used notation and cryptographic primitives used in our proposal. Section 5 introduces our privacy-preserving solution for EU Digital Vaccine Certificates. Section 6 presents the security analysis of our proposal. Section 7 shows the implementation details, and Section 8 shows our experimental results. In Section 9, we discuss usability, benefits, and possible future extensions of our solution. In the last section, we conclude this work.

2. Related Work

There exist several proposals for the COVID-19 Pass, COVID-19 Certificates, or the Green Pass. Recently, Karopoulos et al. [2], Mbunge et al. [3], and Kissi et al. [4] surveyed proposals and works focused on COVID-19 digital certificates. In this section, we firstly present well-known deployed solutions; then, we present privacy-preserving proposals and concepts that are relevant to our scheme.

In 2021, the EU worked on uniforming documents on COVID-19 vaccinations, completed tests, and suffered disease to facilitate and make the proof of these facts in Europe efficient. The created system was called EU Digital COVID Certificates (DCC). This system was gradually adopted in several European countries [5]. In order to enhance the user experience for presenting and verifying the certificate, several countries, including the Czech Republic, developed dedicated smartphone applications. The applications are developed and managed by each EU member state independently, but they are compatible with each other due to unified rules on how to generate the certificates. For instance, the čTečka and Tečka [6] applications are considered the official applications of the digital Czech COVID-19 certificate. This application is available free of charge for both Android and iOS mobile platforms. The certificate compliance can be demonstrated through either a QR code or the raw data. Therefore, the app is used to show either a valid test, vaccination, or recent illness. In order for the system to function, there must be a central authority (i.e., EU), and so-called EU gateways must be operated in individual countries, mediating the mutual recognition of certificates. Therefore, a specific infrastructure and a defined chain of cryptographic trust are necessary for the system to function. All participating countries are required to adhere to the central technical specifications, but at the same time, they also have the flexibility to incorporate nationally defined rules, e.g., duration of recognition of the validity of Polymerase Chain Reaction (PCR) or antigen tests. The data structure presented by the QR code contains the following information: (1) Name and surname of the given person (in the format according to the national alphabet and also separately without diacritics or other characters of the national alphabet), (2) Date of birth, (3) Vaccination-related data (vaccine used, number of vaccinations, date of last vaccination, member state, issuer, certificate identifier, and validity of vaccination according to national rules), or relevant data regarding tests or the disease experienced, and (4) Certificate signature (seal) to verify the authenticity of the given certificate. Everything stored in a QR code is in the JavaScript Object Notation (JSON) format, as prescribed by the relevant [7] specification.

Recently, Halpin [8] discussed the contradiction between privacy and unforgeability properties in EU Digital COVID Certificates (DCC). He concludes that DCCs could be more privacy-preserving than various blockchain-based vaccine passport solutions. Nevertheless, the privacy of DCCs could be improved by minimizing identifiers, abandoning transaction authentication numbers, and solving the unlinkability problem. On the other hand, maintaining unforgeability is impossible without revealing some personal data.

The IBM Digital Health Pass (IDHP) [1] is IBM’s solution for authentication using COVID-19 vaccination certificates or test results. It is a complex system combining testing and vaccination into one unit using blockchain technology. The IDHP system includes the entire process, spanning from authorizing issuers and establishing the format of individual health certificates, to the issuance of certificates and their subsequent verification. The user end can be imagined as a certain form of digital wallet, wherein the user has his health data stored. This gives the user a degree of control over their sensitive health data. Nevertheless, only the following data can be inputted into the wallet: (1) SMART Health card, (2) Good Health Pass, and (3) IBM Digital Health Pass credentials (https://www.ibm.com/downloads/cas/EVD69GQ0, accessed on 5 March 2023). Consequently, it is therefore not possible to load a standard European vaccination certificate onto the system. According to IBM, the application does not hold any information that would link the presented data to the person in question. The user application is freely available for Android devices through the Google Play application. This solution is integrated into Amadeus’ Traveler ID system.

The CoronaCheck app [9] is the official CovidPass app of the Netherlands. Its functionality is similar to ČTečka and Tečka. These are two separate applications for proof and verification of COVID certificates. However, the application takes into account the protection of personal data. The verifier application, CoronaCheck Scanner, does not show all the data read from the certificate. After identity verification, it only reveals the initial letters of the user’s first and last name, along with the day and month of birth, while keeping the year concealed.

The COOV app [10] is South Korea’s solution to the COVID Pass app. The application is focused on the protection of personal data. The vaccination certificate against COVID-19 is just one of the attributes that can be used to authenticate with this application. In addition to vaccination status and test results, this application can also be used to prove maturity. PASS-INFRA, which includes the COOV application, is a freely available solution and can also be used outside the Republic of South Korea. This solution uses a blockchain technology called InfraBlockchain [11]. This technology is independent of native cryptocurrencies, so it is suitable for this use. The technology is developed by Blockchain Labs, which is an active member of the Decentralized Identity Fund (DIF) foundation.

According to Halpin [8], IRMA [12] technology, with the modified Idemix [13] attribute-based authentication scheme, has been already used in Dutch COVID-19 credentials ensuring strong privacy. Nevertheless, as EU DCCs do not support IRMA/Idemix technology, there can be a problem when borders are crossed.

COVID Credentials Initiative (CCI) [14], as an open global community, collaborates on issuing open-standard-based privacy-preserving credentials and other related technologies for public health purposes. CCI deploys Verifiable Credentials (VCs) for representing user health and personal information in a digital, trustful, and tamper-evident manner.

In the recent years, numerous research works in the literature have adopted blockchain and smart contract techonologies, with the aim of harnessing the high availability, immutability, and traceability features that stem from utilizing a distributed public ledger [2]. Early decentralized approaches using Decentralized Identifiers (DIDs), public ledgers, and VCs have been analyzed by Halpin [15]. The work points to several issues such as lacking advanced cryptography or putting personal data on the blockchains. The work also raises ethical questions related to the use of immunity passports.

Recently, Barros et al. [16] proposed a privacy-preserving vaccination pass solution based on a self-sovereign identity concept with decentralized identifiers, VCs, zero-knowledge proofs, and blockchain. Their implemented prototype uses the Sovrin blockchain; Hyperledger Indy; JavaScript-based websites; Aries agents; Near-Field Communication (NFC) and Quick Response (QR) codes for local transfer of data; and digital wallet (connect.me) that is capable of managing VCs. There are also other blockchain-based privacy-preserving digital vaccine certificate solutions such as [17,18,19] that share similar advantages with Barros’s solution, but also have several drawbacks such as robust user registration on the blockchain [17,18] or costly Ethereum transactions [19].

Karopoulos et al. [2] surveyed numerous proposals and works focused on blockchain-based COVID certificates. Their study observes that performance results, implementation details, and deployment aspects are often not given in those proposals. For instance, Kobbaey et al. [20] proposed a blockchain-based vaccination certificate model. Nevertheless, the proposal just employs underlying techniques without more information, and it does not specify how zero-knowledge-proofs and other techniques are designed or implemented.

In this paper, we present a novel solution for privacy-preserving EU Digital Vaccine Certificates (DVC). Our proposal is based on our Attribute-Based Credential (ABC) scheme, which allows us to disclose only the necessary attributes from a certificate. These attributes can represent, e.g., a photo of the certificate holder and the date of the last vaccination. Our solution addresses significant shortcomings of the current EU DVC, such as (1) insufficient identification of the person presenting the given digital certificate and (2) disclosure of all sensitive personal information about the holder and his/her vaccination status. We clarified, defined, and discussed the main security requirements for a privacy-preserving DVC. Furthermore, we provide a security analysis of our cryptographic core and system design. Finally, we provide implementation details about our proof-of-concept application and present several experimental results.

3. Identified Security and Privacy Issues of EU Digital COVID-19 Certificates

In this section, we present the most relevant security and privacy issues related to the implementation of EU DCCs, with a specific focus on the presentation of certificates through smartphone apps. Since there are several smartphone applications with equivalent characteristics, we use Czech Tečka [6] as a reference. In this application, the following issues can be identified:

• Ineffective certificate holder identification: The first issue of the EU DCC is the insufficient identification of the certificate holder. Although the certificate contains information about the holder such as name, date of birth, and nationality, it is not possible to verify and bind this information to the holder of the certificate without the presentation of additional identity documents, such as a national identity card, passport, or other similar documents according with the regulations of the respective state. These documents contain a photo of the holder, enabling their binding with the certificate holder. The problem arises when the verifying person lacks the authority to request these additional documents from the person being verified or this person refuses to provide such documents, is not capable of doing so, or does not possess them. Without this step, the binding of the presented certificate to the given person is not verified, and the meaning of the entire control process is not achieved. Consequently, nothing prevents multiple people from using a single certificate.
  Solution: Include a photo of the certificate holder in the digital vaccination certificate.
• High violation of user privacy: The second issue of the EU DCCs is the high violation of user privacy by revealing much personal information about the user. As part of the non-infectivity or completed vaccination verification phase, the user has to present a complete vaccination certificate in the form of a QR code to a verifier. Therefore, a large amount of sensitive information about the user is revealed to the verifier. The verifying person not only gets basic information about non-infectivity or completed vaccinations, but also lots of other sensitive information such as name, surname, date of birth, nationality, or applied vaccination type. Moreover, the verifier may even take pictures of the QR codes, which implies that they do not only verify the validity of the certificate but also handle and store the personal data of all entering persons. In several situations, it is not necessary to disclose all of this information. Leaving aside the matter of binding the certificate to a specific person, the only relevant information is whether the user has a valid certificate or not.
  Solution: Disclose only the necessary information from the certificate. Keep the rest of the information hidden from the verifier.
• Impersonation, alienation, or misuse of certificates: The third issue of the EU DCCs is that QR codes only include static data about the certificate holder and vaccination details. There is no interactive cryptographic protocol used in order to prevent replay attacks. Therefore, an eavesdropper or anyone with access to the QR code can easily load the certificate onto one’s own smartphone application, and the given certificate can be presented as their own. In fact, in some businesses, staff take pictures of the QR codes under the pretense that they will verify the QR code later or as evidence that they conducted the verification process.
  Solution: Implement an interactive cryptographic protocol (i.e., a challenge-response protocol) and integrate the user’s secret keys to the certificate verification phase.
• Missing revocation mechanisms: The fourth issue of the EU DCCs is the absence of a certificate revocation mechanism. No certificate revocation list is used in smartphone applications and throughout the EU DCC system. Therefore, there is no standardized procedure to revoke compromised, stolen or fake certificates, such as publicly available QR codes of certificates issued in the name of Adolf Hitler or Mickey Mouse. The same problem occurs with invalid certificates, e.g., due to illness of the certificate holder.
  Solution: Deploy online revocation databases which will include compromised, stolen, fake, and invalid certificates.
• Application hacking: The fifth issue of the EU DCC is the time parameter of the digital certificate and the graphical display of certificate validation in smartphone applications. The applications retrieve the time information from the digital certificate and compare it with the system time of the smartphone. If someone changes the system time, the application will display the desired information about the validity of the given certificate (i.e., valid or invalid). In case the QR code is not read by the verifying application and the verifying person is satisfied with the displayed information presented by the certificate holder’s smartphone application, changing the system time can be a serious problem. In fact, by adjusting the system time, the application will display the certificate as valid, even if the presented certificate has already expired.
  Solution: Use a verifying application to verify the validity of the digital vaccination certificates.

4. Cryptographic Preliminaries

In this section, at first, we outline the used notation and the security assumptions needed to understand our scheme and our security proofs. Second, we briefly introduce the attribute-based credential scheme [21] and the elliptic curve integrated encryption scheme [22] as the main building blocks of the cryptographic core of our privacy-preserving solution for EU digital vaccine certificates.

4.1. Notation and the Security Assumptions

From now on, the symbol “:” states for “such that”, “$\left|x\right|$” the bitlength of x, and “$\left|\right|$” the concatenation of two binary strings. We write $a{\in }_{R}A$ when a is sampled uniformly at random from A. A secure hash function is denoted as $\mathcal{H}:{\{0,1\}}^{\ast }\to {\{0,1\}}^{\kappa }$, where $\kappa$ is the given security parameter. Let ${\mathbb{G}}_1$, ${\mathbb{G}}_2$, and ${\mathbb{G}}_T$ be cyclic groups of the same prime order q, where ${\mathbb{G}}_1$ and ${\mathbb{G}}_2$ are additive groups and ${\mathbb{G}}_T$ is a multiplicative group. Let $g_1\in {\mathbb{G}}_1$ and $g_2\in {\mathbb{G}}_2$ be points of the respective group, and $\mathcal{O}$ be the point at infinity.

Definition 1 (Bilinear pairing).

A bilinear pairing is a map $\mathit{e}:{\mathbb{G}}_1\times {\mathbb{G}}_2\to {\mathbb{G}}_T$ which satisfies the following properties:

• Bilinearity: $\forall x,y\in {\mathbb{Z}}_q,g_1\in {\mathbb{G}}_1,g_2\in {\mathbb{G}}_2:\mathit{e}(g_1^x,g_2^y)=\mathit{e}{(g_1,g_2)}^{xy}$.
• Non-degeneracy: $\forall g_1\ne \mathcal{O}\exists g_2\in {\mathbb{G}}_2:\mathit{e}(g_1,g_2)\ne 1\in {\mathbb{G}}_T$ and $\forall g_2\ne \mathcal{O}\exists g_1\in {\mathbb{G}}_1:\mathit{e}(g_1,g_2)\ne 1\in {\mathbb{G}}_T.$
• Computability: There exists an efficient algorithm $\mathcal{G}(1^{\kappa })$ to compute $\mathit{e}(g_1,g_2)$.

By definition, $(q,{\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_T,\mathbf{e},g_1,g_2)$ is a bilinear group if it satisfies all above properties.

Let $\mathbb{G}$ be a cyclic group of order q and $g\in \mathbb{G}$ be its generator. The security of the proposed protocol relies on the n-Strong Computational Diffie–Hellman Inversion (n-SCDHI) assumption [21]:

Definition 2 (n-SCDHI Problem).

Let $\mathcal{O}(·)$ be the oracle that on input $(m_1,\dots ,m_n)\in {({\mathbb{Z}}_q^{\ast })}^n$ adds $(m_1,\dots ,m_n)$ to Q and outputs $\{0,1\}$. Let $O^i(·)$ be the oracle that on input h outputs $h^{x^i}$. Then for all probabilistic polynomial time adversary B, the advantage is defined as follows:

$$Ad{v}_B^{n-\mathrm{SCDHI}}=\mathbf{Pr}[(x_0,\dots ,x_n)\leftarrow \{0,\dots ,q-1\};(y,m_1^{\ast },\dots ,m_n^{\ast })\leftarrow B^{\mathcal{O}(·),{\mathcal{O}}^0(·),\dots ,{\mathcal{O}}^n(·)}:y=$$

$$g^{\frac{1}{x_0+{\sum }_{i=1}^n{m}_i^{\ast }{x}_i}}\wedge (m_1^{\ast },\dots ,m_n^{\ast })\notin Q]$$

SCDHI is $(t,ϵ)$-hard if no t-time adversary has the advantage at least ϵ.

Theorem 1. 

The n-SCDHI problem is hard in the generic group model. More precisely, an adversary working in a generic group of order q with advantage ϵ requires time $\Omega (3\sqrt{ϵq})$.

In this article, we consider the case ${\mathbb{G}}_1\ne {\mathbb{G}}_2$; that is, when $\mathbf{e}$ is an asymmetric bilinear map and the SCDHI assumption holds. Moreover, having ${\mathbb{G}}_1\ne {\mathbb{G}}_2$ permits obtaining the shortest possible signature; see [23] for more details.

4.2. Attribute-Based Credentials from wBB Signature

The Weak Boneh–Boyen (wBB) signature scheme [23] is a pairing-based short signature scheme. The scheme is provably secure, and it is proven to be existentially unforgeable against a weak (non-adaptive) chosen message attack. The scheme can be easily combined with zero-knowledge proofs as shown in the attribute-based credential scheme [21]. In this way, it is possible to prove the ownership of issued attributes in an unlinkable, anonymous, and efficient manner. The scheme was designed to be easily implementable and efficiently executed on computationally and memory-constrained devices such as smart cards. The scheme supports all the standard privacy-enhancing features of attribute-based credential schemes, such as anonymity, unlinkability, untraceability, and selective disclosure of attributes. The main sign of the scheme is its symmetrical character, namely that the credential issuer also serves as the verifier, and therefore, they share secret keys. The scheme is briefly described below:

• $(par)\leftarrow$SetupI$(1^{\kappa })$: on the input of the security parameter $\kappa$, the protocol generates the public system parameters $par=(\mathbb{G},g,q)$ satisfying $\left|q\right|=\kappa$.
• $(sk,ipar)\leftarrow$CredKeygen$(par)$: on the input of the public system parameters $par$, protocol chooses $x_i{\in }_R{\mathbf{Z}}_q^{\ast }$ for $i=(0,\dots ,n)$ and outputs secret key $sk=(x_0,\dots ,x_n)$ and issuer parameters $ipar=(X_0,\dots ,X_n)$ where $X_i=g^{x_i}$.
• ($\sigma ,{\sigma }_{x_0},\dots ,{\sigma }_{x_n})\leftarrow$Issue$(sk,(m_1,\dots ,m_n),par)$: on the input of the issuer’s private key $sk$ and the user’s attributes $(m_1,\dots ,m_n)$, the protocol computes $\sigma =g^{\frac{1}{x_0+{\sum }_{i=1}^n{m}_i{x}_i}}$ and auxiliary values ${\sigma }_{x_i}\leftarrow {\sigma }^{x_i}$ for $i=(1,\dots ,n)$. The protocol outputs the credential $cred=(\sigma ,{\sigma }_{x_0},\dots ,{\sigma }_{x_n})$.
• $(0,1)\leftarrow$Show$(ipar,par,cred,(m_1,\dots ,m_n),nonce,(D,{\langle m_i\rangle }_{i\in D}))$: on the input of the issuer parameters $ipar$, the public system parameters $par$, credential $cred$, user’s attributes $(m_1,\dots ,m_n)$, and an authentication challenge $nonce$ of the verifier, the protocol randomizes the credential $cred$ by taking a random $r{\in }_R{\mathbf{Z}}_q^{\ast }$ and computing $\hat{\sigma }={\sigma }^r$, taking ${\rho }_r,{\rho }_{m_{i\notin D}}{\in }_R{\mathbf{Z}}_q^{\ast }$ and computing:

  $$t=\prod _{i\notin D}{\sigma }_{x_i}^{{\rho }_{m_i}·r}{g}^{{\rho }_r},c=\mathcal{H}((D,{\langle m_i\rangle }_{i\in D}),t,\hat{\sigma },par,ipar,nonce),$$

  (1)

  $$s_r={\rho }_r+cr,{\langle s_{m_i}={\rho }_{m_i}-c{m}_i\rangle }_{i\notin D}.$$

  The protocol outputs user’s proof $proof=(\hat{\sigma },c,s_r,{\langle s_{m_i}\rangle }_{i\notin D})$.
• $(0/1)\leftarrow (sk,par,(D,{\langle m_i\rangle }_{i\in D}),proof)$: on the input of the secret key $sk$, disclosed attributes ${\langle m_i\rangle }_{i\in D}$, and user’s proof $proof=(\hat{\sigma },c,s_r,{\langle s_{m_i}\rangle }_{i\notin D})$, the protocol computes:

  $$t_{verify}\leftarrow g^{s_r}·{\hat{\sigma }}^{-c·x_0+{\sum }_{i\notin D}(x_i·s_{m_i})-{\sum }_{i\in D}(x_i·m_i·c)}$$

  (2)

  and checks that $c=\mathcal{H}((D,{\langle m_i\rangle }_{i\in D}),t,\hat{\sigma },par,ipar,nonce)$. Output 1 if valid and 0 otherwise.

4.3. Elliptic Curve Integrated Encryption Scheme (ECIES)

ECIES [22] is an efficient and provable-secure encryption scheme based on the elliptic curve discrete logarithm problem. Let $\mathbb{G}$ denote a group of prime order q with generator g. Then, the public system parameters are $par=(\mathbb{G},g,q)$. The scheme needs a symmetric encryption scheme $SYM=(E_k,D_k)$, a message authentication code $MA{C}_k$, and a key derivation function $KDF$. The ECIES scheme is briefly described below:

• $(pk,sk)\leftarrow$KeyGen$(par)$: on the input of the system parameters $par$, the protocol randomly chooses the secret key $v{\in }_R{\mathbb{Z}}_q$ and computes the public key $pk=g^v$.
• $(e)\leftarrow$Enc$(par,pk,m)$: on the input of the public key $pk$ and a message m, the protocol randomly chooses $x{\in }_R{\mathbb{Z}}_q$ and computes $u=g^x$ and $t=p{k}^x$. Then, it computes the keys $(k_1,k_2)=KDF(t)$ which are used for encrypting the message $c=E_{k_1}(m)$ and for generating the message authentication code $r=MA{C}_{k_2}(c)$ of ciphertext c. The algorithm outputs $e=u\left|\right|r\left|\right|c$.
• $(\perp /m)\leftarrow$Dec$(par,sk,e)$: on the input of the secret key $sk$ and the ciphertext c, the protocol parses e as $u\left|\right|r\left|\right|c$ and computes $t=u^{sk}$ and $(k_1,k_2)=KDF(t)$. If $r=MA{C}_{k_2}(c)$, then the algorithm returns $m=D_{k_1}(c)$; otherwise it returns an invalid ⊥ result.

In addition to proving that the algorithm is secure, Smart [24] provides several specifications on the choice of $SYM$ and $KDF$. Our scheme builds on the ECIES scheme and takes into consideration Smart’s recommendations.

5. Privacy-Preserving Solution for EU Digital Vaccine Certificates

In this section, we define the whole system architecture, the roles of involved entities, and the used algorithms. Specifically, in Section 5.1, we describe the high-level architecture of our proposal, all involved entities, their roles in the system, and the communication model. In Section 5.2, we present our cryptographic core and all involved cryptographic algorithms.

5.1. System Architecture

• Issuer/Revocation Authority (I/RA). This is the entity responsible for issuing individual attributes to the end-users. To do so, it runs the Issue protocol. The I/RA signs all issued attributes with its private key. We suppose that the I/RA is entrusted with the authority to process the users’ personal data.
• Verifier (VER). This is the entity responsible for verifying the ownership of required attributes by users who are interested in using the service. If revocation mechanisms are implemented in the system, the VER also verifies the revocation status of the presented certificates. Certificates are verified using the Verify protocol. In order to verify the attributes, the VER must possess the I/RA public key.
• User (USR). This is the entity that holds the attributes issued by the I/RA and anonymously provides proof of their ownership to the VER in whose services it is interested. For this purpose, the USR runs the Show protocol.

Our cryptographic core is based on using the Fast Keyed-Verification Anonymous Credentials (FKVAC) [21]. Similarly to the FKVAC scheme, our scheme employs the weak Boneh–Boyen (wBB) [23] digital signatures to create the cryptographic credentials over user attributes. In contrast to the FKVAC scheme, our scheme offers to separate the cryptographic keys of the VER and the I/RA, resulting in an asymmetric cryptographic scheme. This way, it can be used in the application scenario of EU Digital Vaccine Certificates, where the VER and the I/RA are distinct entities which have different rights to the users’ data. All this is performed, while ensuring the same (i.e., low) computing, memory, and cryptographic requirements on the user side (where users have an authentication device in the form of a smartphone or smart card). The system architecture of our solution is shown in Figure 1.

The communication model for presenting the vaccination certificate is shown in Figure 2. The USR is equipped with a smartphone capable of Bluetooth Low-Energy (BLE) communication. The service provider (acting as the VER) broadcasts the BLE advertisement (named, for example, PPCOVIDPASS). If the USR is interested in using the services of the service provider, it initiates a search and connection process through the BLE advertisement. The USR’s mobile app will then connect to the VER app, and both apps will exchange verification data. Namely, the VER sends the verifier certificate with the verifier public key and required attributes for disclosing and cryptographic nonce. Note that the verifier certificate is signed by the I/RA, which is trusted by both communication parties. The USR’s app verifies the validity of the certificate, i.e., the validity of the generated I/RA signature. If the signature is valid, the USR decides whether to accept or decline the attributes required by the VER. If the user approves the attributes, the app sends an encrypted USR’s photo (one of the user attributes), other required attributes (such as, for example: Dose number, Date of Vaccination), and unencrypted proof of knowledge of hidden attributes. In case of successful verification of the presented attributes and identification of the person presenting these attributes by the VER, the USR is granted access to the service; otherwise, it is denied.

The detailed structure of the digital vaccine certificate, including the representation of individual attributes, is shown in Figure 3. The cryptographic credential contains a total of 20 attributes. However, it can be expanded if it is needed. The first 16 attributes correspond to the attributes from EU Digital Vaccine Certificate. The following attributes extend the certificate by (1) a photo of the certificate holder enabling the connection of the holder with the certificate, (2) time stamp, (3) information about the completed vaccination (i.e., yes, no), and (4) one optional field according to the needs of the service provider.

5.2. Cryptographic Core

In this section, cryptographic algorithms are described in more detail, including their input and output variables.

• $(s{k}_I,p{k}_I,param{s}_I,p{k}_v,s{k}_v)\leftarrow$Setup$(1^{\kappa })$: This algorithm works in two phases. At first, on the input of the security parameter $\kappa$, the I/RA generates and publishes the public parameters $param{s}_I$ and generates the private/public key pair $(s{k}_I,p{k}_I)$, where $p{k}_I$ is published and $s{k}_I$ is kept secret. Therefore, the I/RA works as follows:
  • Choose a bilinear map $\mathbf{e}:{\mathbb{G}}_1\times {\mathbb{G}}_2\to {\mathbb{G}}_T$, where ${\mathbb{G}}_1$, ${\mathbb{G}}_2$, and ${\mathbb{G}}_T$ are groups of the same prime order q, $g_1$ is a generator of ${\mathbb{G}}_1$, and $g_2$ is a generator of ${\mathbb{G}}_2$.
  • Define a secure hash function $:{\mathbb{G}}_1\times {\mathbb{G}}_1\times {\mathbb{G}}_1\to {\mathbb{Z}}_q$.
  • Choose a symmetric encryption scheme $SYM=(En{c}_{SYM},De{c}_{SYM})$.
  • Choose $s{k}_I=(x_0,\dots ,x_n){\in }_R{\mathbb{Z}}_q$ as the issuer’s private key, and set $p{k}_I=(h_0,\dots ,h_n)=(g_2^{x_0},\dots ,g_2^{x_n})$ as the issuer’s public key.
  • Publish the public system parameters $param{s}_I=(q,{\mathbb{G}}_1,{\mathbb{G}}_2$, ${\mathbb{G}}_T,g_1,g_2$, $\mathbf{e})$.
  Second, on the input of the parameter $\kappa$, the VER performs the following steps:
  • Randomly choose a private key $s{k}_V{\in }_R{\mathbb{Z}}_q$.
  • Compute and publish its public key $p{k}_V=g_1^{s{k}_V}$.
• $(\sigma ,{\sigma }_{x_0},\dots ,{\sigma }_{x_n})\leftarrow$Issue$(s{k}_I,(m_1,\dots ,m_n))$: On the input of the issuer’s private key $s{k}_I$ and the user’s attributes $(m_1,\dots ,m_n)$, this protocol outputs the issuer’s signature of the user’s attributes $\sigma ,{\sigma }_{x_0},\dots ,{\sigma }_{x_n}$. This algorithm is run as an interactive protocol between the I/RA and the USR as follows:
  • The USR sends all its attributes $(m_1,\dots ,m_n)$ to the I/RA.
  • The I/RA computes the signatures of the USR’s attributes as $\sigma =g_1^{\frac{1}{x_0+m_1{x}_1+\dots +m_n{x}_n}}$ where $s{k}_I=(x_0,\dots ,x_n)$ is its private key.
  • The I/RA calculates the auxiliary values as ${\sigma }_{x_i}={\sigma }^{x_i}$, for $i=0,1,\dots n$.
  • The I/RA sends $\sigma$ and $\Lambda =({\sigma }_{x_0},\dots ,{\sigma }_{x_n})$ to the USR.
  Issue protocol steps are sketched in Figure 4.
• $(0,1)\leftarrow$Show-Verify$(m_{z\in D},\Lambda ,p{k}_V,p{k}_I,nonce)$: This algorithm works in two phases. At first, on the input of the verifier’s public key $p{k}_V$, signatures $\sigma ,\Lambda$, authentication challenge $nonce$, and disclosed attributes $m_{z\in D}$ (where D denotes the set of all revealed attributes), the USR outputs the encryption of the disclosed attributes $c_{z\in D}$, its cryptographic proof $\pi$, and the randomized credential $\hat{\sigma }$. This phase is defined as the Show algorithm. Secondly, on the input of the issuer’s public key $p{k}_I$, the encrypted attributes $c_{z\in D}$, the proof $\pi$, and the randomized credential $\hat{\sigma }$, the VER outputs 0/1, i.e., rejection or acceptance of the proof of knowledge of attributes. This phase is defined as the Verify algorithm. Therefore, the steps are as follows:
  • The VER generates a random authentication challenge $nonce$ and sends it to the USR.
  • The USR randomizes its digital credential $\sigma$ and $\Lambda$ and constructs a proof of knowledge $(\hat{\sigma },\pi )$, including the VER’s authentication challenge $nonce$.
  • The USR generates a symmetric key $k_{\mathrm{enc}}=KDF(j)$ and encrypts the attributes $c_i=En{c}_{SYM}(m_i,k_{\mathrm{enc}})$.
  • The VER reconstructs the symmetric key $k_{\mathrm{enc}}=KDF(j)$, decrypts the attributes $m_i=De{c}_{SYM}(c_i,k_{\mathrm{enc}})$, and verifies the resulting proof $\pi$ by using its challenge $nonce$ and the issuer’s public key $p{k}_I$.
  Figure 5 depicts the Show-Verify protocol in detail. The part of the protocol where the communication between the communicating parties is encrypted is marked in red.

6. Security Analysis

In this section, the security analysis of the cryptographic core takes place. In particular, we provide the proof of correctness, unforgeability, anonymity, and key–parameter consistency of our proposal. Note that the equality $t\stackrel{?}{=}{t}_{verify}$, i.e., Equations (1) and (2), has been proven in [21]. Therefore, the correctness of our proposal is proven as follows:

Theorem 2 (Correctness).

The Verification process in Section 5.2, point 3, is correct.

Proof. 

Since a symmetric cryptographic scheme is used to encrypt the attributes, at first, we show that the VER can reconstruct the USR’s encryption key. In fact,

$$\begin{array}{cc}\hfill & j^{\prime }=u^{s{k}_V}={(g_1^{ϵ})}^{s{k}_V}=p{k}_V^{ϵ}=j\hfill \\ \hfill & k_{\mathrm{enc}}^{\prime }=KDF(j^{\prime })=KDF(j)=k_{\mathrm{enc}}\hfill \end{array}$$

(3)

and, therefore, $m_i^{\prime }=De{c}_{SYM}(c_i,k_{\mathrm{enc}}^{\prime })=De{c}_{SYM}(c_i,k_{\mathrm{enc}})=m_i$ for all $m_i\in D$. Accordingly, the decryption process is correct as shown in Equation (3). Once the message is correctly decrypted, we need to show that $\mathbf{e}(t_{verify},g_2)$ is equal to $\mathbf{e}(\hat{\sigma },\alpha )·\mathbf{e}(g_1^{s_v},g_2)$. Note that $e^{\prime }$ is equal to $\mathcal{H}(t_{verify},\hat{\sigma },nonce)=e$. The pairing equality can be proven as shown in Equations (4) and (5):

$$\begin{array}{cc}\hfill \mathbf{e}(\hat{\sigma },\alpha )=& \mathbf{e}(g_1^{(\frac{1}{x_0+m_1{x}_1+\dots +m_n{x}_n})\rho },h_0^{-e}·{\prod }_{i\notin D}{h}_i^{s_{m_i}}{\prod }_{i\in D}{h}_i^{-e{m}_i})\hfill \\ \hfill =& \mathbf{e}(g_1^{(\frac{1}{x_0+m_1{x}_1+\dots +m_n{x}_n})\rho },g_2^{-e{x}_0+{\prod }_{i\notin D}({\rho }_{m_i}-e{m}_i)x_i+{\prod }_{i\in D}-e{m}_i{x}_i})\hfill \\ \hfill =& \mathbf{e}(g_1^{(\frac{1}{x_0+{\sum }_{i=1}^n{m}_i{x}_i})\rho },g_2^{-e(x_0+{\sum }_{i=1}^n{m}_i{x}_i)+{\prod }_{i\notin D}{\rho }_{m_i}{x}_i})\hfill \\ \hfill =& \mathbf{e}{(g_1,g_2)}^{-e\rho +(\frac{1}{x_0+{\sum }_{i=1}^n{m}_i{x}_i}){\prod }_{i\notin D}{\rho }_{m_i}{x}_i\rho }\hfill \end{array}$$

(4)

and, therefore,

$$\begin{array}{cc}\hfill \mathbf{e}(\hat{\sigma },\alpha )·\mathbf{e}(g_1^{s_v},g_2)=& \mathbf{e}{(g_1,g_2)}^{-e\rho +(\frac{1}{x_0+{\sum }_{i=1}^n{m}_i{x}_i}){\prod }_{i\notin D}{\rho }_{m_i}{x}_i\rho }·\mathbf{e}{(g_1,g_2)}^{{\rho }_V+e\rho }\hfill \\ \hfill =& \mathbf{e}{(g_1,g_2)}^{{\rho }_V+(\frac{1}{x_0+{\sum }_{i=1}^n{m}_i{x}_i}){\prod }_{i\notin D}{\rho }_{m_i}{x}_i\rho }\hfill \\ \hfill =& \mathbf{e}(g_1^{{\rho }_V}{g}_1^{(\frac{1}{x_0+{\sum }_{i=1}^n{m}_i{x}_i}){\prod }_{i\notin D}{\rho }_{m_i}{x}_i\rho },g_2)\hfill \\ \hfill =& \mathbf{e}(g_1^{{\rho }_V}{\sigma }^{{\prod }_{i\notin D}{\rho }_{m_i}{x}_i\rho },g_2)\hfill \\ \hfill =& \mathbf{e}(g_1^{{\rho }_v}{({\prod }_{i\notin D}{\sigma }_{x_i}^{{\rho }_{m_i}})}^{\rho },g_2)=\mathbf{e}(t_{verify},g_2)\hfill \end{array}$$

(5)

   □

Theorem 3 

(Unforgeability). Our scheme is $(t,ϵ,q_H)$-unforgeable if the n-SCDHI problem (see Theorem 2 for more details) is $(2t,{ϵ}^{\prime })$-hard, where $q_H$ is the maximum number of random oracle queries and ${ϵ}^{\prime }=ϵ(\frac{ϵ}{qH}-\frac{1}{q})$.

Proof. 

Since no modifications are made on the Issue protocol, the proof follows directly from the unforgeability of the KVAC protocol [21].    □

We recall the definition of anonymity:

Definition 3 ([21]).

A keyed-verification credential system is anonymous if for all PPT adversaries $\mathcal{A}$, there exists an efficient algorithm SimShow such that for all κ, for all $\varphi \in \Phi$ and $(m_1,\dots ,m_n)\in$ such that $(\varphi (m_1,\dots ,m_n)=1$, and for all ($s{k}_I,p{k}_I,param{s}_I,p{k}_v,s{k}_v$) $\leftarrow \mathtt{Setup}(1^{\kappa })$: $\mathtt{Show}(param{s}_I,A,(m_1,\dots ,m_n),\varphi$) $\leftrightarrow \mathcal{A}\to \approx SimShow(param{s}_I,s{k}_I,\varphi )$, i.e., the adversary’s view given the proof can be simulated by $\mathtt{SimShow}$ given only ϕ and a valid secret key corresponding to $param{s}_I$.

Theorem 4 (Anonymity).

Our scheme is anonymous, as defined in Definition 3, in the random oracle model.

Proof. 

Since the modifications of the Show-Verify protocol do not affect the credential generation, the proof follows directly from the anonymity of the KVAC protocol [21].    □

We recall the definition of key-parameter consistency:

Definition 4. 

A keyed-verification credential system is key-parameter consistent if for any PPT adversary, the probability that $\mathcal{A}$ given $param{s}_I$ can produce $(param{s}_I,s{k}_{I_1},s{k}_{I_2})$ with $s{k}_{I_1}\ne s{k}_{I_2}$ such that $(param{s}_I,s{k}_{I_1})$ and $(param{s}_I,s{k}_{I_2})$ are both in the range ofSetup$(1^{\kappa })$ is negligible in κ (where the probability is taken over the choice of $param{s}_I$ and the random coins of $\mathcal{A}$).

Theorem 5 (Key-parameter consistency).

Our scheme is key-parameter consistent as defined in Definition 4.

Proof. 

Following the KVAC protocol proof [21], Setup outputs $sk=(x_0,\dots ,x_n)\in {\mathbb{Z}}_q^{\ast }$ and $param{s}_I=(x_0,\dots ,x_n)$, where $x_i=g_2^{x_i}$. Since ${\mathbb{Z}}_q^{\ast }$ is a prime order group, all of its elements have a unique discrete logarithm, and therefore, there is a unique $sk$ corresponding to every $param{s}_I$.    □

7. Implementation Details

In this section, we present our proof of concept implementation of privacy-preserving digital vaccine certifications. The implementation serves primarily to evaluate performance tests and verify the functionality of the proposed solution. On one side, we have a smartphone application that is used by users to download and store their own digital vaccine certificates. If users need to prove themselves with the certificates, the application has the functionality to check the attributes required by the verifier (i.e., the service provider). These attributes are then displayed to the users, and their action is required (i.e., their approval or rejection). The user application is developed for the Android platform. We use the Kotlin programming language and the Android Studio development environment for its implementation. The application implements all algorithms presented in Section 5.2 and uses BLE communication to send the digital certificates from the user to the verifier. On the second side, we have a verifier’s terminal application which is also implemented in Kotlin and partially shares the program code with a user’s smartphone application. The source codes of our applications are publicly available on the online GitLab repository here: https://gitlab.com/brno-axe/mvcr-adiopsio, accessed on 1 September 2023.

7.1. Cryptographic Core

The cryptographic core is the same for both applications and is implemented using the MCL library [25]. This library supports the bilinear pairing operations and shows the best performance results according to [26]. The library is available in a native form for the Android platform and provides support for BN254 and BL12_381 elliptic curves. Note that our implementation uses the BN254 elliptic curve and requires bilinear pairing operations in the verification phase. Since the library is available only in native C/C++ form, we use the Android Native Development Kit (NDK) and a wrapper enabling the use of the library functions on the Android platform. The cryptographic core is represented with the CryptoCore class and implements eight methods: see Figure 6 for more detail. The first four methods implement the cryptographic algorithms (i.e., Setup, Issue, Show, Verify), and the other four methods provide support functions.

7.2. Data Structures

Both applications use several data classes. These classes define the structure of communication messages, certificates, and keys, and are defined in the DataElements.kt file. The data structures used in our implementation are detailed below:

• Certificate: This is the most important data structure. It represents the user’s digital vaccine certificate. The structure itself contains the following values:

  –

  attributes: This is a value of type HashMap<Int, String> holding attributes in plain text form. Attributes are indexed based on their position (i.e., $1,2,\dots ,20$), not their name.

  –

  attributesSigma: Similarly to the attributes, attributesSigma is also of type HashMap<Int, String>, where in this case, the values are the ${\sigma }_{x_i}$ signatures of all issued attributes.

  –

  sigma: This value represents the main signature of $\sigma$.

• Pubkey: This structure represents the issuer’s public key. The class holds the value of HashMap<Int, String>, which is indexed in the same way as the attributes and attributesSigma structures.
• NonceRequest: This is the first data structure used within communication between the user’s application and the verifier terminal. Its purpose is to transmit the verifier’s challenge to the user.
• VerifierCert: This structure defines the digital certificate of the verifier issued by the I/RA. The verifier uses this certificate within the verification phase. In particular, the verifier decides which attributes the user should reveal during the verification phase. However, these attributes may vary based on the nature of the verifier. Therefore, the certificate is used to control whether a given verifier is entitled to see these required attributes or not. The data structure includes the following values:

  –

  issuer_name: The name of the I/RA. It is a variable of type String.

  –

  verifier_name: The name of the verifier. It is set when the certificate is issued. It is directly linked to the name of the entity that verifies digital certificates as part of the operation of services. attributes: A list of attributes that the verifier is entitled to query. This is a list of type List<String>.

  –

  signature: The digital signature of all values listed above.

• VerifyRequest: This data structure represents the user’s response to the previous verifier’s request NonceRequest and contains the following values: sigma_roof, disclosedValues, t_verify, sm, and sv. These values are used as cryptographic proof.
• JsonResponse: This data structure is used to process user digital vaccine certificates downloaded from the web server. The JSON containing this certificate has a slightly different form than the Certificate data structure, which is why this structure was created. A significant difference between the objects holding the certificates within the user application is the indexing method. Certificates downloaded from the web server are indexed by attribute name, while the application indexes the attributes using their position. The data structure contains the following information:

  –

  creation_time: Date of certificate issuance, data type String.

  –

  email: User email, data type String.

  –

  status: This information indicates whether the certificate is valid, data type Boolean.

  –

  certificate. Attributes of the digital vaccine certificate, data type Map.

  –

  sigma: Signatures of $\sigma$, data type Map.

• Device: The structure created to display selected information about discovered BLE devices and their subsequent display. This structure holds the following information:

  –

  name: Advertised device name of type String.

  –

  address: MAC address of the Bluetooth interface of the device type String. power: Signal power of the discovered device String.

7.3. Communication Protocol

The communication between the user application and the verifier application is performed using four fixed messages corresponding to the data structures described above: see Figure 7. We use the BLE communication protocol to transmit data between the user and the verifier. The verifier’s terminal is acting as a beacon. The user application is able to search for a device whose advertisement name includes the string covidpass-terminal. When the user selects one of the available verifier’s devices, the first message is sent by the user device. To ensure the reliability of the communication, a simple acknowledgment of the sent chunks has been created.

The first message carries the string STARTVERIFY. In response to receiving this message, the verifier’s terminal responds with a message of the data type NonceRequest. The message thus carries a $nonce$ challenge, a list of attributes to reveal, and the verifier’s certificate. The verifier’s certificate is used to verify the identity of the verifier, verify what attributes are to be disclosed to the verifier, and whether the verifier has the right to query those attributes. The certificate is verified upon receipt of the NonceRequest message, and the requested attributes are compared against the allowed attributes. Once the user decides to proceed with the verification process, the cryptographic proof is generated and sent to the verifier along with the revealed attributes. The sending of this message is signaled by including the string VERIFYREQUEST at the beginning of the message before the proof in the form of the data structure VERIFYREQUEST. When the message is received by the verifier device, the proof is verified. Based on the result of this verification, the final user–verifier communication message is produced. The final message may take the form VERIFY_OK if the authentication is successful. If the verification fails, a message VERIFY_FAILED or BAD_VERIFYREQUEST is sent. The first message indicates that the verification failed. The second message indicates that a communication error occurred and the user is prompted to resend the third message of the protocol.

7.4. Application Structure

The Android mobile application is built upon the Model–View–ViewModel (MVVM) architectural pattern and implemented using modern technologies such as the Kotlin programming language, local Room database, and Jetpack Compose framework for rendering the user interface. The application is composed of user interface elements, database access classes, and support classes providing communication and cryptographic core functions. The interrelation of these elements is illustrated in Figure 8.

The user interface elements include the following classes:

• Models: Classes containing data structures that hold the data of different parts of the application.
• Views: Classes defining the graphical environment using the Jetpack Compose framework. These classes may include basic logic for controlling the rendering of individual elements.
• View Models: Classes containing models that affect the displayed values of the graphical interface of Android application activities.

Additionally, the application includes a persistent data model consisting of classes that offer basic operations over the database store and the definition of individual data entities, such as certificate data items. The last component of the application comprises supporting classes, mainly implementing the cryptographic core using the MCL library, followed by the implementation of the communication stack through BLE. The BLE Stack is based on the standard functions provided by the Android operating system Application Programming Interface (API).

7.5. Application Database

User digital vaccine certificates are stored in a class representing the Cert entity containing the following items: certificate identifier, creation date, email, status, certificate $\sigma$ value, and the values of their attributes and corresponding $\sigma$ values. The implementation also includes a CertRepository class that allows basic certificate operations such as inserting, deleting, and reading from the Room database. The certificates can be inserted into the database using a one-time access token that allows the certificate to be downloaded from the I/RA’s web server. The token can be scanned as a QR code for increased user-friendliness.

8. Experimental Results

In this section, we present our performance tests on various smartphone platforms and one smart card platform. First, we provide benchmark results of our cryptographic core. Second, we evaluate the overall performance of the verification phase including the BLE communication overhead.

8.1. Cryptographic Core Performance

To measure the time consumption of our algorithms, we developed a test application in the Java programming language that does not perform any communication overhead between system entities (i.e., issuer, user, and verifier). Each algorithm of the cryptographic core runs in this test application. Therefore, saving and loading of individual parameters was not performed. The application implements the cryptographic core listed in Section 7.1. The application uses the measureTimeMillis() function to measure the elapsed time of each algorithm. This feature allows us to measure Central Processing Unit (CPU) time with millisecond accuracy. Our experimental results are presented in

Table 1. The time consumed to perform each phase of the cryptographic core on various devices.

Device	Attributes	2	10	20	30	40	60	80	100	200	500
Google Pixel 4a	Setup [ms]	1	4	7	10	12	18	25	31	68	162
	Issue [ms]	1	2	4	5	7	10	14	17	22	55
	Verify [ms]	5	11	16	20	25	34	41	50	103	262
Samsung S21 FE	Setup [ms]	1	2	4	6	8	12	16	19	42	106
	Issue [ms]	1	2	3	5	6	9	11	14	32	82
	Verify [ms]	3	7	10	13	16	22	26	32	65	163
Honor 8X	Setup [ms]	1	6	11	16	21	31	41	51	110	275
	Issue [ms]	1	3	6	9	12	17	24	28	58	150
	Verify [ms]	8	19	27	34	42	57	69	84	165	410
Average	Setup [ms]	1.0	4.0	7.3	10.7	13.7	20.3	27.3	33.7	73.3	181.0
	Issue [ms]	1.0	2.3	4.3	6.3	8.3	12.0	16.3	19.7	37.3	95.7
	Verify [ms]	5.3	12.3	17.7	22.3	27.7	37.7	45.3	55.3	110.0	278.3

and Figure 9. The measurements confirmed the expectation that the time requirement of the algorithm increases with the number of hidden attributes. To make the experimental results more indicative, we performed all tests with all hidden attributes except the first attribute that was revealed. The most computationally demanding algorithm is the Verify algorithm. However, even when revealing a theoretical number of 500 attributes (which is a highly inflated value) from a cryptographic credential, the required time reaches less than 300 ms. Therefore, the measurements show that the cryptographic core does not represent any performance issue on current smartphone platforms.

8.2. Overall Performance Including BLE Communication Overhead

The second part of the performed experiments focused on testing all components of our privacy-preserving digital vaccine certificate application. Within the testing infrastructure, test certificates with a different number of attributes were created by the I/RA. These certificates were downloaded to the smartphone application using a secured web service. Then, the system performance was measured during user authentication to the VER’s terminal. To run the application, we used a Raspberry Pi 4B single-board computer and a lower-performance Raspberry Pi Zero 2 W. Both of these devices have a built-in Bluetooth 5 interface which supports communication via the energy-efficient BLE protocol. The results show that the time duration of each protocol phase (i.e., Scanning, Nonce, Verify) is nearly identical for both computers. For representative results, all measurements were performed on a Raspberry Pi Zero 2 W: see Figure 10. Note that the Scanning protocol phase is responsible for finding and connecting the smartphone application to the BLE server, the Nonce phase performs the sending of an authentication challenge from the Verifier and the computation of the cryptographic proof of the user, and the Verify phase then checks the correctness of the cryptographic proof on the VER’s side.

Each certificate issued under the Issue algorithm contains one or more attributes and the appropriate attribute signature for each attribute. In the data structure representing the certificate, the attributes are stored as pairs containing a key and a value. The user application generates a VerifyRequest containing the revealed certificate entries and the digital signatures of the attributes. This request is serialized to the JSON format, and images, such as user photos, are converted to text using Base64 encoding. For testing purposes, a certificate containing attributes representing a possible certificate proving vaccination was used. The specific details included in the certificate are listed in

Table 2. Data fields and sample values within the test certificate. The field size includes keys and JSON delimiters.

Certificate Field	Field Key	Sample Value	Size [B]
First name	firstname	John	17
Surname	surname	Doe	14
Day of birth	brithdate_day	25	19
Month of birth	brithdate_month	8	20
Year of birth	birthdate_year	1990	22
Photo	photo	(Base64 data)	12, 600
Unique issuer ID	unique_id	12345678	21
Vaccination day	vaccination_day	10	21
Vaccination month	vaccination_month	10	20
Vaccation year	vaccation_year	2022	24
Order of dose	dose	2	9
Total doses	total_dose	2	15
Completed vaccination	completed_vaccination	True	29
Vaccine	vaccine	SARS CoV-2 Sample Vaccine	36
Product	product	Product A	20
Manufacturer	manufacturer	Manufacturer A	30
Issuer	issuer	BUT Brno, Czech Republic	34
State of EU	state_eu	CZ	14

. In total, there were 19 attributes. Additional attributes added for performance measurement purposes were added to the end of the certificate and contained 32-byte values for simplicity.

In addition, we also evaluated the computational complexity of our application in the case of revealing a theoretical number of 500 attributes (which is a highly inflated value) from a cryptographic credential: see Figure 11. The required verification time, including the BLE communication overhead, takes up to 3 s for most of the tested smartphones. The measurements therefore show that our application can be practical even in the case of a high number of attributes contained in the cryptographic credentials.

8.3. Performance on Smart Cards

To evaluate the performance of our privacy-preserving digital vaccine certificate on the smart card platform, we used the MULTOS-based smart card implementation from our previous work in [21,27]. The Show-Verify algorithms were implemented using Barreto–Naehrig (BN) BN254 elliptic curve from the MCL library [25]. Only standard Multos API and free public development environment (Eclipse IDE for C/C++ Developers, SmartDeck 3.0.1, MUtil 2.8) were used. In the case of using smart cards for storing and presenting certificates, the verification time (in the worst case, i.e., 20 stored attributes, all hidden) can be expected to be up to around 3 s as shown in Figure 12. Since smart cards do not support BLE communication, it would be necessary to use Personal Computer/Smart Card (PC/SC) and contact/contactless communication interface.

9. Discussion

The experimental results show that our solution is feasible to implement on current handheld devices, especially on Android smartphones and smartwatches. Applying cryptographic attribute-based credentials in digital vaccine certificates brings benefits in higher protection of citizens’ privacy and is in line with current European legislations such as GDPR, the upcoming eIDAS 2.0, and its new tools that it envisages led by European digital identity (https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/european-digital-identity_en, accessed on 1 September 2023). This identity is intended to allow citizens to prove their identity to access online services, share digital documents, or simply prove specific personal characteristics such as age without revealing their identity or other personal information. We show that even in scenarios where certificates have a theoretical maximum of 500 attributes (which is a highly inflated value), the processing time remains under 300 ms on current smartphones. Consequently, our application can be practical even when dealing with certificates containing a high number of attributes.

European Health Insurance Cards are free cards that grant EU citizens access to medically necessary, state-provided healthcare while temporarily staying in any of the 27 EU countries, Iceland, Liechtenstein, Norway, Switzerland, and the United Kingdom, under the same conditions and at the same price. Therefore, European Health Insurance Smart Cards can be used to store information about the citizen vaccination status in the form of our privacy-preserving digital vaccine certifications. Our experimental results show that deploying the implementation of our solution on a smart card platform within a real-world environment is possible. Even with a digital vaccine certificate containing 20 attributes, the verification of completed vaccination would take approximately 3 s.

In our work, we consider various devices as secure storage of digital certificates (including smartphones/smartwatches and smart cards). Indeed, different devices bring different pros and cons, especially considering the security, time efficiency, and acquisition cost. Some works such as, for example [28], point out the problematic implementation of attribute-based credentials into real-world applications due to privacy and security risks. For instance, the identity disclosing risk allows a dishonest participant to start the conversation by requesting the entire set of attributes, resulting in a total loss of privacy and anonymity. This risk is caused, besides other reasons, by the use of smart cards. Smart cards do not have a user interface that allows users to directly control the attributes that are revealed and, if possible, stop the authentication protocol. Another disadvantage of smart cards is their computing power. As we have shown in our tests, the calculation of cryptographic proof is up to 1000× slower on a smart card than on smartphones, and it is limited by a small number of attributes. In this work, we assumed these risks mitigated these shortcomings and demonstrated a practical implementation of attribute-based credentials in a real-world scenario. To do this, we developed an Android mobile application allowing users present and control the revealed attributes from the digital certificate. Even if smartphones and smartwatches are not considered tamper-resistant devices like smart cards, they provide sufficient security protection for user data thanks to the separation of applications, processes, and data (use of application sandbox) on the operating system level. That is why they are used in a number of security applications, such as bank or e-government applications. It is true that the acquisition costs of a smartphone are higher than the acquisition costs of a smart card, but if we take into account that most citizens already have a smartphone, this shortcoming is negligible.

Although our solution provides high security and privacy protection (see the security analysis in Section 6), we see also other possibilities to continue our work. This is primarily a further increase in the protection of citizen privacy and the decentralization of solutions for the support of cross-border Information and Communication Technologies (ICT) systems. Namely, our solution protects user privacy by disclosing only some information from the digital vaccine certificates. Furthermore, the disclosure of this information is also directly confirmed by the user (i.e., the certificate holder). All transmitted data are encrypted with end-to-end encryption (between the user and the verifier). Encrypted communication and randomized cryptographic proofs make it impossible for an eavesdropper to access data and profile users. Most of the disclosed attributes from the certificate have a general character and, therefore, do not directly lead to user profiling by the verifier (i.e., the service provider). However, the attribute of the user photo has a unique character and has to be always disclosed to allow a visual identification of the certificate holder. Thus, it allows the verifier to track the users (albeit anonymous users) within its services. To eliminate this risk, technologies such as Fuzzy extractors [29] deserve to be investigated. On the other hand, the blockchain technology (i.e., a public verifiable open ledger) and smart contracts (i.e., programmable logic programs integrated into the blockchain) have emerged as promising tools for devising decentralized models to securely settle arbitrary resource transactions such as digital vaccine certificates. This technology holds the potential to eliminate centralized entities involved in certificate management throughout their lifecycle, while ensuring the immutability, traceability, and availability of the involved assets. For instance, storing credential revocation schemes on the ledger would ensure high availability and maintain an immutable record of revoked certificates. Finally, our solution assumes the personal identification of certificate holders based on the presented photo (i.e., revealed attribute) from the digital certificate. However, the identification of the certificate holder itself is up to the inspecting person and is therefore subjective in nature. In order to guarantee the defined accuracy of the correct identification of certificate holders, it would be interesting to incorporate some of the biometric authentication methods into our solution.

10. Conclusions

This work presents a novel solution for the privacy-preserving EU Digital Vaccine Certificates. Our solution solves the privacy and security shortcomings of the current solution such as ineffective certificate holder identification and a high violation of user privacy with the disclosure of sensitive information. Furthermore, our solution is in line with current EU legislation, i.e., GDPR and eIDAS 2.0 regulations. The core of our proposal is built on our novel attribute-based credential scheme, which can be easily implemented on various handheld devices, especially on Android smartphones and smartwatches. However, due to the lightweight nature of our scheme, it can also be implemented on constrained devices such as smart cards. Our experimental results show that even if we use certificates with a theoretical number of 500 attributes (which is a highly inflated value), the required time would reach less than 300 ms on current smartphones. However, implementation of our solution on a smart card platform is also possible. In the case of a certificate containing 20 attributes, the verification of completed vaccination would take approximately 3 s. This would allow European Health Insurance Cards to be used as a repository for privacy-protecting digital vaccine certifications.