Privacy preserving COVID-19 vaccinating-and testing-pass for the European Union

Purpose Physicians and scientists hope to gain new insights from health data to improve medical care and optimize costs in the healthcare sector. However, data protection laws in Europe often impose limits on the use of patient data. During the COVID-19 pandemic the exercise of all civil rights and liberties depends on successful vaccinations, negative tests, and recovery from the disease. Digital proof thereof was of particular importance for participation in social life. This research project aims to create a system concept for vaccination, testing, and recovery proof called P3VT (Privacy Preserving Pass for Vaccination and Testing), which makes all collected data anonymously available in real time to scientists as well as to political pandemic management. Methods Based on the Design Science Research methodology (DSR) [1], P3VT is the artifact created by the research project. It was developed over several iterations, consistently taking into consideration the goals of privacy-by-design, data minimisation and transparency of the EU-GDPR. Expert interviews have been conducted to validate the system from a medical, technical and data protection perspective.


Introduction
Nearly three years after the start of the global COVID-19 pandemic, vaccination as well as testing have become normal.Various occupational and recreational activities could only be undertaken only after proof of vaccination, negative testing, or recovery from COVID-19.Experience has shown that paper-based proofs such as the internationally recognised vaccination card ("yellow card") cannot be considered tamper-proof [2].Various countries worldwide have therefore developed digital veri cation systems, for proving vaccinations, negative tests or recoveries from COVID-19 [3].Within the European Union the system is based on the technical framework of the so-called EU Digital COVID Certi cate.The requirements for a system generating and verifying proof of vaccination, testing and recovery were de ned by the EU Commission in March 2021 [4].The aim was to create a standardised and thus compatible digital certi cate throughout Europe [5].Nevertheless, the EU requirements do not consistently adhere to the requirements of the EU Data Protection Regulation (EU-GDPR) for data minimisation, transparency and the privacy-by-design principle and thus informational self-determination [6].In addition, since the issuance of valid vaccination, testing and recovery certi cates, various forgeries have been in circulation [7].Those are highly professional made and are mostly issued by employees in the health sector or by the fraudsters themselves using a leaked certi cate signing key [8].The veri cation systems of other countries or systems developed by companies or researchers also have disadvantages.
Usually private data such as name, date of birth or ID card number are disclosed for the veri cation process.It would therefore be easy for the veri er to store or pass on this data.In addition, many veri cation systems, such as the EU digital COVID certi cate, are based on the additional veri cation of an ID document, which is rarely carried out professionally in practice.However, this devalues the proof itself, as it would not be noticed if several people use the same vaccination proof [9].Above that COVID-19 veri cation systems are always problematic from a data protection perspective.Therefore, veri cation systems should always be implemented with the best possible measures to improve data protection [10].Beyond high privacy standards the system must be fraud-resistant, interoperable and certi cates must be easy to issue and validate [3].
In addition, a particular challenge for pandemic management is that research institutions and authorities have so far had only insu cient real-time data at their disposal.[11].Most deployed systems are not able to make data on vaccinations, tests or recoveries available in an anonymized form.This is problematic since the proportion of vaccinated and the number of positively tested persons at regional level are important instruments for pandemic management.Therefore, a research project was initiated to develop the Privacy Preserving Pass for Vaccinating and Testing (P3VT) system with the aim of providing evidence of COVID-19 vaccination, recovery and testing digitally and in a tamper-proof manner, while at the same time making these data available anonymously throughout Europe.Access to P3VT-Data is easy to implement due to the standardised HL7 FHIR interfaces and the resulting compatibility with existing systems.An extended catalogue of requirements according to Table 1 is being pursued within the framework of this research project.Provision of as much data as possible for well-directed pandemic management and research, with respect to data protection [12,13] Req-9 Limitation of validity of issued certi cates based on current scienti c knowledge [14] Req-10 Processing and veri cation of more than two vaccination doses depending on which vaccines were administered [15] In contrast to existing veri cation systems, the transfer of personal data such as name, date of birth or vaccination date to the veri er, in the following called service provider (e.g., transportation system, event organizer), is avoided with P3VT.The concept is based on Distributed Identities (DIDs) as well as distributed ledger technology (DLT) and provides evidence pseudonymously but still tamper-proof.Further advantages of P3VT are the automation capabilities for service providers as well as the exibility of the veri cation.

Research Project And Methodology
This publication is part of an ongoing research project that is based on the construction-oriented methodology of Design Science Research (DSR).According to this methodology, requirements are elicited, an artifact is developed and subsequently validated.This research cycle must be completed several times [1], see also Fig. 1.In the rst step, a literature review and synthesis were conducted to identify requirements for a COVID-19 veri cation system.After the initial design of the P3VT-System a critical evaluation from a medical, technical and data protection perspective was conducted in the form of expert interviews.First, an expert on IT security in health care, who was involved in the conception and testing of several European COVID-19 vaccination veri cation systems, was interviewed.[1] In addition, an interview was conducted with a data protection expert and author of various relevant specialist publications.[2] Further interviews were conducted with an expert in Business Information Technology, [3] to validate the technical design, and an Healthcare specialist and Infectiologist, [4] for the validation of the functionality.The insights generated from the interviews were integrated into a further improvement cycle.A validation of the requirements and already published IT security and data protection threats against vaccination veri cation systems has also been carried out.In the further course, it is planned to involve additional experts to optimise the design and validate it within the framework of a case study. [

State Of The Art
One of the most respected COVID19 veri cation system is the EU digital COVID certi cate, which was still issued in 2021 over 800 million times [16].It is a non-DLT-based veri cation system that issues certi cates to citizens after vaccinations, tests, and recovery.In the technical sense, these are electronically signed data records from vaccination and testing centres or doctors.In addition to the vaccination, test, or recovery data, these also contain personal data such as name, date of birth and vaccination or testing data.In the event of loss or misuse of private signature keys, revocation procedures for certi cates are envisaged [4].In practice, similar solutions have not always been able to maintain con dentiality, availability, and integrity requirements in retrospect [17,18] and the reality shows multiple approaches for abuse [8].A further overview of in scienti c papers proposed and by states operated systems is given in [3].
Although several scienti c publications on implementation concepts regarding testing and vaccination veri cation systems are available.
The systems typically consist of an app frontend and a Distributed Ledger Technology (DLT) based backend, often in combination with Technologies like Self-Sovereign-Identity (SSI) [3,19].In the case of electronic identities, it is common for the issuer to be involved during the authentication process in addition to the owner and the veri er of the identity (see electronic certi cates).In the analogue world, on the other hand, a proof of identity such as the ID-Card is veri ed directly by the veri er of the identity, without the need for the issuer to be involved.SSI technology maps this approach to the digital world using distributed ledger technology and a challenge-response protocol [20,21].The highly private blockchain based COVID-19 digital certi cate management system [22] relies on the Ethereum blockchain and uses SSI as well as proxy re-encryption to ensure maximum privacy.Proxy re-encryption is a technique where a proxy performs a re-encryption so that two communication partners do not have to know each other's keys, and the proxy has no plaintext data.The transmission of a vaccination-proof is secured with smart contracts and is only possible after release by the patient.Here, smart contracts are small programs stored in a distributed ledger and thus protected against changes; they are triggered automatically when the distributed ledger assumes a certain state.[23] This means that the sharing of certi cates and thus the provision of evidence takes around 20 seconds, which is a problem for practical implementation.In [24] a Hyperledger-Fabric Distributed Ledger is presented that only stores hash-values of vaccination-and test-datasets.Every national health authority operates a Hyperledger fabric node in this regard.NovidChain [25] uses blockchain and SSI technology and furthermore veri able credentials of world wide web consortium and as an off-chain data storage the interplanetary lesystem.To improve privacy, the ID-Card number is processed instead of the name.However, this also represents personal data and is subject to change.Immupass [26] also uses the ID-Card number instead of the name but provides statistical data including location data for health authorities above that.However, the overall level of data protection is low, as proofs always contain the entire vaccination history as well as information on tests.
The available scienti c publications as well as the existing implementation projects show that no veri cation system intends to use a central storage of all data records, as this would hardly be feasible in terms of data protection law.Instead, most of the concepts presented rely on decentralised storage of the veri cation data on citizens' smartphones.The integrity of the proof is guaranteed either by electronic signatures [4,27] or the central storage of checksums of the proof on a distributed ledger [28][29][30].This differentiates veri cation systems in scienti c publications to those operated by states which are mainly based on electronic signatures [3].In both cases protection requirements, such as the avoidance of transmission of personal data to the veri er or transparency about each veri cation process, often are not met [24-26, 31, 32].Other approaches provide a higher level of privacy but do not make testing and vaccination data publicly available, thereby making the systems unsuitable for improved regulatory pandemic management [30,[33][34][35].As far as the literature shows, there is currently no concept for a veri cation system that consistently relies on central and public data storage for improvement of pandemic management and allows proof of vaccination, testing and recovery anonymously without giving away personal data.

P3vt Concept
The P3VT concept is based not only on a user-friendly implementation of the proof, but also on user trust and data protection.P3VT supports the requirements for privacy-by-design, data minimisation and transparency.To maximise the possible bene t from the COVID-19 vaccination-, test-and recovery-data required for veri cation purposes, all data, apart from the reference to persons, is held centrally on a publicly available distributed ledger, called "P3VT data ledger" (P3VT-DL).A second distributed ledger takes over the key management for the proof process and is therefore called "P3VT authentication ledger" (P3VT-AL).The assignment of the datasets to natural persons is carried out in accordance with SSI technology by means of identities managed decentral on the smartphones of the users.Therefore, an open-source App is provided.The protection goals of integrity and availability are ensured by the distributed ledgers, con dentiality, and authenticity by the decentral managed identities.
Due to the public nature of the distributed ledgers, the processing of personal data on it must be protected by hashing or encryption procedures.Proof can also be provided pseudonymously, e.g., via public keys.Thus, each vaccination or test is stored as a transaction to an identity created by the patient, represented by a public key generated individually for this vaccination, test or recovery.The open-source app presented in Chap.4.1 is used to manage the identities as well as the generation and veri cation of proof.The digital identities serve as pseudonyms and are managed by the patients themselves, without a central trust authority.Following the SSI technology, public keys are DIDs [21], that are persisted on the P3VT-DL and will therefore be called public data keys.In addition to these keys, which are also the pseudonyms of the tested or vaccinated person, a time stamp, the region and the dates of vaccination, test or recovery are stored.The details are shown in Chap.4.2.2.Since a high degree of randomness can be assumed for all values and that no identifying characteristics allow for any conclusions to be drawn about speci c persons, public access to the data records is unproblematic.To enable a later check of the assignment of a pseudonymous dataset to a natural person, a hash value formed by stringing together of the rst name, last name and date of birth is also stored.To prevent a potential attack scenario whereby the name and date of birth of a patient is known, the P3VTapp includes a randomly generated nonce in the hash calculation.This makes it impossible for an attacker to search for datasets of a certain person.The nonce is also stored locally on the patient´s smartphone.To prevent forgery, separate key pairs derived from the identity keys are used for the authentication in veri cation process.The assignment between public data key and public authentication key is made by the P3VT-AL.This ensures that a proof cannot be active on two smartphones at the same time.Further details are provided below (see function-7).If fraud is nevertheless detected, health authorities can invalidate proofs of vaccination, test or recovery by writing a transaction with the concerned public data key in the P3VT-AL.This means that no valid link is possible between data key and authentication key from that point in time.In the following the smartphone app for generating and verifying proofs and the required backend components are described.

App/ decentralised infrastructure
A pan-European standardised open-source app (P3VT-app) is provided for citizens to prove a negative test result, vaccination, or recovery.In addition, this app takes over the management of the identities described above and the veri cation function towards third parties.
The P3VT-app supports the functions listed in Table 2.A detailed description can be found in the following chapters.As part of the identity management function, asymmetric data key pairs can be generated on the patients smartphone.While the private data key is securely stored locally, the public data key is transferred via QR code to the vaccination or testing centre or the physician so that the public data key can be stored on the P3VT-DL together with the test or vaccination data.In addition, an authentication key pair is generated for the veri cation process (see function-5).The public authentication and the public data key are signed with the private data key and afterwards written to the P3VT-AL.This transaction will be performed only if the signature proof is valid.The locally stored data keys represent the DIDs, and the P3VT-app provides the wallet to manage them.Biometric Authentication is required to access the private keys.Before a vaccination, test or recovery is con rmed, an identity check is also carried out based on the patient's ID-card, which ensures that the public data key is securely assigned to a natural person.The vaccination or testing centre creates a transaction on the P3VT-DL via the national health authority as described above after the vaccination or after the test result is received.A network connection is only required for sending the public keys to P3VT-AL.This can be performed after visiting a vaccination-or test centre.The procedure can be seen in Fig. 2.
Since the patient acts as a customer in the case of proof of a vaccination, recovery, or a negative test result, e.g., before entering an event or using public transportation, both terms are used synonymously in the following, depending on the use case.However, they refer to the same person.

Access to results (function-2)
As a second function, the P3VT-app offers the possibility to access the data records stored under one's own identities.This is particularly relevant for the fastest possible noti cation about the results after a test.For this purpose, after generating a new pseudonymous identity, the P3VT-app searches for a new transaction on the P3VT-DL with the associated public data key.As soon as a transaction exists, the identity owner is automatically noti ed.Test results as well as vaccination data can also be accessed manually afterwards.This function can be seen as analogous to a traditional paper-based vaccination card or test con rmation.Since information displayed on the customers smartphone is not su cient to detect potential tampering, this function is not intended to provide proof.For tamper-proof veri cation, functions 3 to 5 should be used.A network connection is required to use this function.The procedure can be seen in Fig. 3 4.1.3Generate a request for proof (function-3) The P3VT-app should support both the proof of the personal vaccination or test status and the veri cation of the proof.In the rst step, a request for proof must be generated.This consists of specifying the proof condition, e.g., two vaccinations completed or a negative test result not older than 48 hours, a dynamically generated random value as a cryptographic challenge and the purpose of the veri cation process.The latter is a free text eld that is stored locally in the P3VT-app of the customer in a log le and thus creates transparency about the proofs already issued.For example, the service provider can state that the proof is required for entrance to a sports event or for taking a ight.
To increase the tamper resistance, P3VT provides two types of proof: The standard case is the proof without manual identi cation.Here, the request for proof is displayed as a QR code on the service providers smartphone or an adequate device.Requests for proof can be generated without a network connection.A button can be used to switch directly from function 3 to function 5 for veri cation.
Authorities such as the police, which are trained in checking ID-Cards, are also authorised to request a proof with manual identi cation.Since this procedure removes the pseudonymity of the person concerned, it should not be used as standard, but should allow random checks to detect misuse.The procedure can be seen in Fig. 4.

Generate a proof (function-4)
The generation of a proof is always triggered by scanning a request for proof.Based on the transmitted test condition, e.g., vaccination or current test result, the P3VT-app identi es the individually matching proof.If no proof or combination of proofs is stored that ful ls the request, a corresponding error message is displayed on the smartphone of the customer.Otherwise, the cryptographic challenge of the service provider is encrypted (signed) with the private authentication key of the customer and displayed together with the public data key as a QR code on the smartphone display.If a combination of multiple vaccination-or testing-measures is required for proof the generated QR-Code will contain all relevant public identity keys and the signatures of the cryptographic challenge based on the corresponding private authentication keys.This allows P3VT to check complex test conditions, e.g.whether 3 vaccinations and/or one test have been performed in the last 24 hours in a single proof.
If a proof with manual identi cation is requested, the rst name, surname, date of birth and the nonce must also be transferred with the QR code.As this makes the person concerned identi able, a warning message is displayed before the proof is generated, stating that this proof may only be provided for authorised authorities.Biometric authentication must be carried out to generate the proof.The content and time of the request are saved locally.No network connection is required for this function.The procedure can be seen in Fig. 5.

Verifying the proof (function-5)
The function for verifying a proof can be invoked immediately after a request for proof (function-3) has been displayed.For this purpose, the QR code generated by function-4 on the customer's smartphone is scanned.Subsequently, the dataset for the transmitted public data key is retrieved from the P3VT-DL.The record is now validated according to the proof condition de ned in function-3.Evidence that the dataset belongs to the customer is provided by the cryptographic response, which, decrypted with the public authentication key corresponding to the public data key, must be equal to the previously set challenge.The currently valid public authentication key is queried from the P3VT-AL (see Fig. 8, step 3).A con rmation (green tick) is displayed on the service providers smartphone if the proof condition has been met and the response has been successfully veri ed.In case of a negative veri cation, a rejection is shown by a red cross.A network connection on the part of the service provider is required for the veri cation of the proof.The procedure can be seen in Fig. 6.
In case of veri cation with manual identi cation, a hash value is calculated from the rst name, last name, date of birth and nonce transmitted via QR code, which is automatically compared with the hash value on the P3VT-DL.In addition, this data is shown in plain text on the smartphone display of the veri er, who in this case must be an authorized person.The identity can now be manually compared with an ID-Card of the customer.This makes it possible to randomly check whether counterfeit proofs are used.Except for the increased transparency regarding the purpose of the proof, this procedure is similar to the EU digital COVID certi cate.The procedure can be seen in Fig. 7.

Read access log (function-6)
Users of the P3VT-app can see at any time when and for what purpose a proof was created, and which dataset was used for the answer.For this purpose, the smartphone records all proof procedures locally and lists them if required.Deletion can be initiated manually by the app user.No network connection is required for this function.

Backup and restore Key Material (function-7)
The export function allows the storage of all public and private keys plus access logs in the form of an encrypted le.For this, the user of the P3VT-app must choose a su ciently secure password or connect a FIDO2 token and authenticate via biometrics.The export is performed in a structured le format.All key and log data are encrypted with AES-256, which allows for le backup even via cloud storage, by mail or instant messenger.Restoring to the same or another smartphone is only possible after entering the previously selected password or via the FIDO2 token.Alternatively, an automated backup function like that of current crypto messengers can be used.To prevent forgery of this function by sharing private keys with third parties, a new authentication key pair is generated when key material is restored from a backup.The public authentication and the public identity key are signed with the private data key and afterwards written to the P3VT-AL.This transaction will be performed only if the signature is valid (see Fig. 8).All proofs generated after restoring the backup on the new smartphone must be signed with the new authentication key.Thus, a proof performed on the previously used smartphone would not be valid anymore.A network connection is required for the key restore function; the export function is also available o ine.

Operating model
Two distributed ledgers in the form of public permissioned ledgers are used as central components of P3VT.These are public ledgers which can be accessed for reading without authentication.To improve interoperability, data retrieval is offered via a web service interface based on the HL7-FHIR standard.Health authorities as well as individuals and service providers can access it for veri cation purposes.It also enables data use by researchers and authorities.Write access to the distributed ledgers however is limited to the health authorities as well as vaccination and testing centres under their control.The public permissioned Hyperledger Indy, which was developed to manage decentralised identities [36], will be used for the future implementation.Hyperledger Indy combines the public read access of known cryptocurrencies with the restricted write access of private ledger technologies [37].It is optimised for many and fast read operations to verify distributed identities -in this case including the COVID-19 vaccination, test and recovery data linked to it.The distributed ledger network consists of explicitly authorised nodes -in this case the highest health authorities of each EU state.The consensus method used is an advanced Redundant Byzantine Fault Tolerance (RBFT) method, which is considered tamper-proof and fail-safe even in networks with several malicious nodes and still offers high performance with 27 nodes.The latency and thus delay for the creation of new vaccination and test datasets respectively key assignments in the P3VT-AL is a few seconds [38].This ensures that on the one hand each member state can contribute transactions and that on the other hand control is carried out within the framework of the consensus procedure between the health authorities of the EU states.It is ruled out that unauthorised persons introduce counterfeit transactions.

Potential uses and scaling
The described public data structure forms the basis for several use cases.Although no personal data is made publicly available, the veri cation of the vaccination or testing status of individual persons is possible.During such a check, the identity of the customer as well as the authenticity of the dataset must be ensured, but this requires neither a central public key infrastructure nor contacting the issuer of the digital identity, which improves privacy.Even though the data structure does not refer to a person, it also helps health authorities and researchers.Thus, the spread of the coronavirus as well as the progress of vaccinations can be tracked transparently and almost in real time across Europe at any time, as all vaccination-, test-and recovery-data on this can be accessed via P3VT-DL.Existing complex and error-prone reporting procedures from each testing or vaccination centre via local health o ces to national health authorities can be eliminated or accelerated.Delays that regularly occur today due to reporting chains [39,40] would thus become a thing of the past.
Other challenges of distributed ledger technology such as scaling, performance, or energy consumption [41] are also signi cantly reduced by this approach, as only less that 130 bytes are to be expected per dataset and energy-saving proof-of-stake consensus procedures are used.If ten transactions were carried out on the P3VT-DL for each EU citizen -e.g., 3 vaccinations and 7 tests-this would result in a storage size of less than 600 gigabytes.
In contrast to the digital COVID certi cate of the EU, P3VT does not specify its own technological standard which does not enable interoperability.Internationally, the HL7 FHIR standard has gained acceptance for communication between healthcare providers and with patients mobile devices. 4All interfaces of the P3VT backend use this open standard, which ensures that alternative implementations of the veri cation app as well as other systems can access P3VT-data via standardised web services.The backend ensures that writing operations are authenticated and only possible through health authorities, read access is allowed without authentication.One challenge in the implementation according to the FHIR standard is the P3VT architecture, which separates personal reference and health data.All existing FHIR resources, such as for immunisations, include mandatory person identi cation [42].Therefore, two new FHIR resources has been designed for P3VT.The structure of the resource ProofOfCovidImmunity, and an example application is shown in Table 3.In addition, another resource called ProofOfAuthenticity is needed for authenticity preservation, which establishes a mapping between currently valid public authentication key and public data key.

Discussion
In contrast to existing concepts, P3VT is based more consistently on privacy-by-design, data minimisation and transparency.Proofs can be provided in a tamper-resistant manner without the transmission of personal data to the service provider conducting the veri cation.
Communication is limited to cryptographically secured data, one-time tokens, and pseudonyms, which can only be assigned to a natural person by the person concerned.This design prevents possible misuse on the side of the operators of the central components as well as on the side of the service provider.In the following, P3VT will be compared especially with the EU digital COVID certi cate.In this context, an IT security assessment based on threats against veri cation systems is performed.
5.1 Differences to the EU digital COVID certi cate P3VT basically works with publicly available, non-personal data.Only in the case of providing a proof for vaccination, testing or recovery, a personal reference is established explicitly by the person concerned.The high protection of sensitive data is in strong contrast to low protection requirements from the legislators' point of view, due to the missing reason to intervene as the individual remains the master over his or her data. 2In contrast to the veri cation systems used today, this requires two QR code scans instead of one, which creates additional effort on the part of both the customer and the service provider.Therefore, no manual ID-card check is needed.However, this has the added bene t of conveying the purpose of the proof.With P3VT the user can see when, where and for what purpose which proof was disclosed in pseudonymous form.The trust in this solution is increased, as the data is meaningless without the assignment to a natural person.Service providers only receive the data required to check the proof condition instead of a complete data set with name, date of birth and vaccination or testing data.In contrast, with one-sided scanning, such as the EU digital COVID certi cate, neither a pseudonymous proof can be provided, nor is there transparency about the data transfer.A complicating factor of the EU digital COVID certi cate is that the scanning and thus the transfer of the personal veri cation data could also take place unnoticed, such as taking a screenshot containing personal data.Another advantage of P3VT is the potential to automate the veri cation process, for example for accessing public transport or attending large events.In contrast, systems that require a comparison with an identity document to assign a proof to a natural person rely on a manual veri cation.
A special feature of P3VT is the public availability of all gathered data in anonymous form, which can be used to advance regulatory pandemic management and research.This allows health authorities to observe how the proportion of vaccinations, or the ratio of tests performed to positive tests develops over time in a region.This information is an important basis for determining targeted regional measures instead of blanket lockdown regulations.
The strict separation of proof and identity data also enables a particularly high degree of exibility regarding veri cation conditions.Thus, by de ning individual veri cation conditions in the request for proof (function-3), service providers can request a con rmation that is su cient for the individual case.For example, it would be conceivable that a certain vaccine may be effective a maximum of 6 months after vaccination, or a negative test result may be two days old for certain use cases and only one day old for others.P3VT also allows the combination of multiple proofs in one request, e.g., 2 vaccinations in the last 360 days and a negative test result not older than 24 hours.This exibility is not provided in the EU digital COVID certi cate [4].
A functional limitation of P3VT arises in the event of a loss of the smartphone without data backup (function-7).In this case, no further proof can be generated due to the lack of private keys.Therefore, backup functions are provided.Increased requirements also result from the veri cation process, which in the presented solution depends on an internet connection.However, such a connection is only required on the part of the service provider and the volume of data being transmitted is minimal.This signi cantly reduces susceptibility to tampering, as revoked proofs are always recognized as such, so this represents a minor reduction in convenience in favour of a signi cant gain in security.
In contrast to the EU digital COVID certi cate, P3VT is embedded as far as possible in existing healthcare processes by using the HL7 FHIR standard which is widely used in healthcare.Nevertheless, the integration of COVID veri cation systems is expected to improve in the future, e.g., by integrating with an existing electronic health record (EHR).Due to the heterogeneity of the healthcare systems in Europe and the different technical solutions used in the individual states, this does not seem to be possible at present.Standardization in technical and procedural terms, as envisaged in various political projects like [43], is desirable and would also facilitate the implementation of veri cation systems in the event of a future pandemic.Another challenge for innovative privacy-friendly systems in healthcare is that standards such as FHIR do not provide for the separation of personal reference data and health data, nor do they provide for data storage on a distributed ledger by default [42].

Validation of the requirements and the security architecture
In Table 4, the requirements in 1 are compared with the properties of the EU digital COVID certi cate.It shows that the digital COVID certi cate of the EU cannot meet the extended data protection requirements.
Tab. 4 Summary comparison of the P3VT and the EU digital COVID certi cate according to the requirements described in Tab. 1 In addition, an evaluation was made with typical IT security threats to COVID-19 vaccination veri cation systems.These were published by the German Society for the Advancement of Vaccination Medicine in a white paper [45].The evaluation of P3VT in Table 5 shows that threats can be mitigated better than with the EU digital COVID certi cate.Spying out metadata during certi cate status check P3VT is not based on A centralized public key infrastructure.
However due to its architecture, there is another threat to which P3VT is exposed.It is conceivable that identities are passed on in the form of private data keys.People who have been vaccinated may have no interest in protecting their private data key, so that they could give it to family members, for example, for the purpose of manipulated proof. 1 Due to the pseudonymity of the certi cates, this is not recognisable to the service provider.To prevent such misuse, it is ensured that only one smartphone for a speci c customer can provide a valid proof at the same time and every proof requires a biometric authentication.In addition, the proof with manual identi cation, with which authorities can detect unauthorized disclosures of digital identities, is possible.In combination with strong sanctions for the disclosure and use of false digital identities from the veri cation system, which are comparable to document forgery as well as identity theft, potential abuse can be reduced to a minimum.
Regarding application security we can assume a high to very high protection level for con dentiality, integrity, and authenticity.Attacks on integrity and authenticity are conceivable in this and other systems but are complex.Weaknesses in systems based on digital signatures have been revealed several times [17,18,46].Regarding con dentiality, the high need for protection arises from the processing of health data.The separation of proof data and identities in P3VT makes attack scenarios against con dentiality much more di cult.From the perspective of data protection, P3VT is therefore to be preferred over existing solutions in Europe, since pseudonymisation takes place at the earliest possible point in time and the connection between proof data and natural person can only be performed by the person concerned.Data minimisation is consistently observed and common principles such as need-to-know are put into practice. 2To be able to meet the high requirements for transparency and data minimisation, P3VT is deliberately limited to digital proof via smartphone.Less tamper-resistant and privacy-friendly paper-based proofs, such as the "yellow card", remain valid internationally.

Conclusion And Future Work
The need for general lockdowns is reduced since advances in testing strategies as well as higher vaccination rates are reached.Veri cation systems are established to prove adequate vaccination, negative testing or a recovery of COVID-19.They must be tamper-proof, private, and easy to use to gain wide acceptance.In addition, it is essential for health authorities to be able to take targeted and effective measures to contain the further spread of COVID-19 based on ne-grained and regional data on vaccinations and tests that have been carried out.
Existing veri cation systems such as the EU digital COVID certi cate only partially addresses data protection and are not able to support pandemic management by providing needed data.With P3VT, a system has been designed that, based on DLT, Distributed Identities, FHIR standard and a veri cation app on the smartphones of vaccinated, tested and recovered citizens, adheres to privacy-by-design, data minimisation, transparency, and security.The enhanced functionality of P3VT includes exible speci cation of proof conditions and better pandemic management by providing anonymous vaccination and testing data.Even though P3VT will not replace the EU's digital COVID certi cate, it is intended to demonstrate that a higher level of functionality can be achieved despite an improved level of data protection.

Figures
Page 16/  Generation and management of a digital pseudonymous identity (function-1) Access to vaccination records and test results (function-2) Generation of request for proof (function-3) Generation of a proof, in case authorities request a manual identity veri cation, the name, date of birth and nonce are also transferred (function-4) Veri cation of Proof without manual ID checking (function-5) Figure 7

Figure 1 Structure
Figure 1

Table 5
[45]uation of safety and privacy threats to a COVID-19 vaccination veri cation system according to the German Society for the Advancement of Vaccine Medicine[45]