Key Findings

• IATA Travel Pass (ITP), a global, opt-in app to receive, store, and share digital COVID-19 test certificates for flights, has a critical flaw in its registration process which allows an attacker to impersonate another user, needing only to know the user’s passport details but not possess the passport itself. According to the IATA this issue is the result of an intentional design decision to not verify user-provided information on its servers to minimize transmission of sensitive personal data. This flaw is currently circumvented by requiring users to present their physical passports alongside ITP.
• ITP utilizes a blockchain-based technology “Sovrin” to verify the validity and authenticity of user-supplied digital COVID-19 test reports. Sovrin is one of many “Self-Sovereign Identity (SSI)” systems. SSI is an emerging technology that aims to replace conventional cloud-based identities with decentralized systems. ITP delegates the most crucial certificate issuance function of SSI to a web application managed by the company Evernym. This design nullifies the advantages brought by a decentralized system.

Introduction

In the wake of COVID-19, governments and companies around the world are seeking ways to maximize the safety and security of airline passengers, the staff of airlines and airports, and the broader population with which passengers interact. These efforts include requiring COVID-19 testing, vaccination, or immunization prior to authorizing individuals for flights. In addition to conventional paper-based systems, various digital solutions catering to this need have been developed by governments. In April 2021, close to 50 airlines have signed up to trial ITP. For example, the European Union developed the EU Digital COVID Certificate, which stores and verifies COVID-19 statuses by QR codes; Doan, a US-based company, developed a mobile application VeriFL; and the International Chamber of Commerce developed AOKPass.

The International Air Transport Association (IATA, a trade association of the world’s airlines) has developed IATA Travel Pass (ITP), a COVID-19 digital passport solution led by an international NGO. We conducted a security and privacy audit of the application and found two vulnerabilities: an impersonation vulnerability with limited impact and a server information leak. We also found that ITP utilizes a non-conventional blockchain technology in a way that mostly neutralizes the benefits of the technology, resulting in a system with security properties that are fundamentally the same as conventional server-client systems. This core technology of the app is implemented by the company Evernym. This study adds to growing research on security and privacy issues with technologies and data privacy policies for tracking and managing COVID-19 information.

IATA Travel Pass Overview

The International Air Transport Association (IATA) Travel Pass (ITP) is a mobile application with the goal of “[i]nforming passengers on what tests, vaccines and other measures they require prior to travel, details on where they can get tested and giving them the ability to share their tests and vaccination results in a verifiable, safe and privacy-protecting manner.”

Once registered, users are able to access the app’s home screen:

The home screen includes the following features:

1. Your Flights: Users can search the flights they are planning to take based on carriers, date, and destinations. Once a flight is selected, ITP fetches and shows the travel requirements (such as COVID-19 test types and test dates) for that destination. These traveling rules are provided by the IATA Timatic database.
2. Documents: Users can see their passport details and profile photo, which were entered into the app during the registration process.
3. Health: After users receive verified COVID-19 test reports, they can access them here.
4. Privacy: Users can read FAQs and see the history of their data sharing.
5. Connect: This feature is used when the user needs to communicate with other parties in the ITP ecosystem. It is most prominently used when the user registers at a laboratory to take a COVID-19 test.

For more explanation and screenshots, Ethiopian Airlines provides a comprehensive demonstration video of ITP on YouTube.

ITP was successfully trialed on its first international flight on March 17, 2021. Currently, it can be used on selected flights by partnering airlines.

To provide COVID-19 test results, laboratories can register with IATA to join the “Lab Network.” Laboratories will gain access to the “Lab App,” which is a web-based application.

For users, traveling with the ITP involves these general steps:

1. Register ITP with their personal details and passport.
2. Go to partnering laboratories and register their personal details using ITP before taking COVID-19 tests.
3. Receive test results from the laboratory in the app.
4. The app will tell the users whether they are eligible to travel.
5. At the airport, staff will verify the users’ test results.

Methods

Our analysis combines reverse engineering the application and reviewing media reports and documentation from the IATA and Evernym websites.

“Reverse engineering” is a general term used to describe methods to dissect systems to understand their inner workings. We used a combination of static analysis and dynamic analysis.

Dynamic analysis involved runtime hooking, runtime instrumentation, and network traffic analysis. Static analysis involved analyzing the program’s source code to understand its behaviors and potential behaviors under certain conditions. In this type of analysis, the program sits statically while we peek into its parts, like taking batteries out of a clock, disassembling all the gears, then observing the shape of each gear.

Runtime instrumentation involves inspecting the program’s state at certain times of execution. It allows us to see what data is being passed around by the program at specific points. Runtime analysis is like attaching a bell to a spring in a clock: during the clock’s operation, if the spring is actuated, the bell rings. We can deduce the spring’s functions by observing when the bell rings.

Runtime hooking takes the idea of runtime instrumentation further. In runtime hooking, we not only inspect the program’s state, but we also change the program’s state or execution flow. For example, we can hook a function (“function” here can be understood as a small part of the program) in the program which would normally return false, and change the function so that it will always return true. This process is analogous to manually spinning gears in a clock to accelerate the time that it displays. With the ability to alter program execution flow, we are able to skip execution of certain parts of it or fake results generated by some function. A common tool for runtime instrumentation and hooking is Frida, which is the program we used.

Our analysis only focuses on the Android version of the app. We did not test the iOS version.

Test environment:

• Android 9 and Android 11
• IATA Travel Pass app
  • Version name: 1.0.976
  • Version code: 976
  • Downloaded in July 2021
• Android rooted with Magisk

ITP Architecture

In this section, we describe ITP’s backend system architecture and its use of blockchain technology.

Figure 2 shows the interaction between the ITP app and other components of the ecosystem. The passport details and profile photos gathered during the registration process are only processed and stored on the device itself. Later on, when a laboratory completes a user’s COVID-19 test report, it is sent to ITP on the phone for storage, instead of a central server. When airlines or border control need to see the user’s test report, the user can show it to them on the screen, or by scanning their QR code to establish a “connection”¹ to send it.

However, what is not shown on the diagram is the provider of the core transmission and verification feature of test reports and passport details: Evernym. Evernym is a company that provides solutions to issue, transmit, and verify digital “verifiable credentials.” Verifiable credential is a technology standard that specifies a machine-readable format for verifiable information. Essentially, verifiable credentials² are digital counterparts to the credentials that are used in our daily lives; for instance, driver’s licenses are used to assert that we are capable of operating a motor vehicle, and university degrees can be used to assert our level of education. In Evernym’s products, verifiable credentials are implemented with “Sovrin.” Sovrin is a project consisting of several of its own standards further specifying the verifiable credentials format and communications, an open-source software suite that implements Sovrin standards, and a peer-to-peer network of computers forming the Sovrin blockchain.

Verifiable credentials can be issued on any subject by anyone, and they can be verified without the verifier needing to interact directly with the issuer or requiring a centralized authority. Verifiable credentials also allow for advanced usage, such as selective disclosure. For instance, if someone was issued a driver’s license, which contains their name, date of birth, and the type of vehicle they are licensed to operate, when trying to prove, they could decide to not reveal their date of birth. In verifiable credentials, trust is peer-to-peer, as anyone can issue credentials on any subject, but it is also up to the verifier of the credentials to decide who and what to trust. Verifiable credentials can also be stored offline only (without needing a copy at a central registry) and transmitted when needed (for instance, when the prover wants to prove to the verifier, the prover can send the credentials directly to the verifier, much like when we present our drivers’ license to a roadside police).

Collectively, verifiable credentials, Decentralized Identifiers, and other digital technologies are used as building blocks to provide a “Self-Sovereign Identity (SSI)” system. It is generally recognized that for an identity system to be self-sovereign, users control the verifiable credentials that they hold and their consent is required to use those credentials. This design reduces the unintended sharing of users’ personal data. SSI is contrasted with a centralized identity paradigm where identity is provided by some centralized entities. For instance, the OAuth protocol implemented by Google and Facebook provides identity systems for other applications to rely on, so that users may log in to the application with their Google or Facebook account.³

In the case of ITP, verifiable credentials are issued by laboratories to attest the users’ COVID-19 test results, and also by the ITP app installed on the users’ phones to attest their passport identity. During registration, ITP issues a credential attesting that ITP represents the owner of those inputted passport details (ITP can issue the credential on itself, without contacting any external services). When ITP establishes a connection with laboratories or border control, users can share their passport details in the form of a verifiable credential. At the laboratories, they issue COVID-19 test results of the test subject identity previously shared with them, also in the form of verifiable credentials. Finally, at the airport, users can share their passport verifiable credential (issued by ITP itself) and the COVID-19 test result verifiable credential (issued by the laboratories), and the border control or airline can verify that the COVID-19 test result credential is issued by an approved laboratory, and also that its content has not been tampered with. Note that, the verification process at the airport that we just described is only one of the possible methods that airlines and border authorities are actually using. We do not have sufficient information on the actual verification process.

Laboratories use the Lab App to receive users’ passport identity credentials and issue verifiable credentials of users’ COVID-19 test result. Evernym has a product called “Verity Flow,” which is a customizable web app that allows issuing verifiable credentials from a graphical user interface. ITP Lab App is the first deployment of Verity Flow. According to Evernym, Verity Flow is “provided on a SaaS basis, hosted in Evernym’s cloud infrastructure.” Verity Flow was designed to meet the needs of laboratories, who tend to have minimal IT capacity.

As for Timatic, it is an online database of travel regulations provided by IATA. After the user receives their digital COVID-19 test report, ITP queries the Timatic database to see if the test date, type, and laboratory fulfills the regulatory requirements of their destination.

ITP Registration Process

A user is required to complete nine steps to register an account on ITP. In order to understand the critical flaw we identified in the ITP registration process, it is necessary to be familiar with each of these nine steps. This flaw allows an attacker to bypass step 5 and step 8, which in turn allows an attacker to register an ITP account without possessing a valid passport.

This section provides an overview of the registration process.

Step 1: Invitation code

On first startup, the app requires users to enter a 6-digit invitation code. The invitation codes are provided by the airlines. We found that the invitation code submitted by the user was never sent out of the phone. Therefore, the app must know if a given code is valid, and it is likely that the set of valid codes is hard-coded somewhere in the source code. We were not able to locate the valid codes through static analysis, so we developed a Frida script to intercept the valid codes. Once the code was known, we entered it via the user interface and were able to pass this step of the registration process.

Following this analysis, in July 2021 we found that the invitation codes for both the Android and iOS versions of the app were available from Etihad Airlines (link to snapshot) and Azerbaijan Airlines’ (link to snapshot taken in August) websites.

Usually, apps incorporate invitation codes to allow only invited users. Having the codes on public websites defeats this purpose. Perhaps realizing the error, both airlines removed the codes from their websites when we checked on November 15, 2021. According to IATA, the invitation code was introduced for two reasons:

1. To limit the number of simultaneous users as IATA were not yet ready to scale.
2. To avoid passenger disappointment as only some flights for selected airlines participating in the trial are available. Otherwise they might install the app and be frustrated not to find their flight.

Step 2: Sign-in with Google

After entering the correct invitation code, the app shows a login screen, which requires the user to log in with their Google account:

In this log-in process, ITP relies on Google to tell it whether the user is authenticated. This design reduces the burden for ITP to implement an complete account system, and removes the need for users to create and remember another set of account credentials.

The app will log the user out after a period of inactivity. The login requirement aims to prevent other people from accessing and using the owner’s data and identity.

Underneath, the login function is implemented using a service provided by Auth0. The Auth0 service essentially serves as a proxy for login requests. This way, apps only need to integrate with Auth0, without needing to integrate with each individual identity provider. This makes it easier for app developers to integrate multiple identity providers. (However, ITP is only using one identity provider, Google.) Auth0 also provides a client-side library for integration into the app, which ITP uses.

Step 3: Fingerprint reading

After logging in with Google, the app invokes a system prompt requesting the user’s fingerprint. According to our static code analysis, the app itself is unable to obtain the user fingerprint in this process. Instead, the operating system will only tell the app if the fingerprint is authorized by the system. If no fingerprint is registered with the system at the time and if the phone supports reading fingerprints, the system will instruct the user to register one.

Upon subsequent successful authentication from Google OAuth⁴, the app always requires the user to input their fingerprint. We believe this requirement is set up in tandem with the Sign-in with Google requirement, which aims to make sure the person operating the phone is the owner of the phone.

Step 4: Consent screen

Next, ITP asks for the user’s consent and agreement to the Terms & Conditions.

Step 5: Profile photo

The app asks the user to take a profile photo using the phone’s front camera.

We first attempted to take a photo of a blank wall and send it. The app showed a generic error message asking us to try again, indicating that the server software does actually check for a face.

To continue our test, we used the website This Person Does Not Exist , which hosts an algorithm that generates real-looking faces, then took a picture of the generated face from ITP. The ITP server accepted the picture.

Step 6: Liveness test

The app opens the front camera, and asks the user to “move their head, close their eyes in

front of the camera as instructed.” According to IATA, the liveness test is used to make sure “You are not a robot or another individual and to prevent (sic) You are not taking a picture of a picture to enroll.”

When testing this feature, we noticed the network traffic was relatively quiet. In the Android log output (adb logcat) we noticed a lot of messages referencing Google’s Firebase ML Kit. We therefore concluded that the liveness test is processed entirely on-device, which means the video data of the user’s face is analyzed using the device’s processor. The result of the analysis will be either pass or fail. If the result is “pass,” the app proceeds to the next step.

Because of this characteristic, we were able to modify the app to directly return the “check passed” result. This allowed us to bypass the liveness test. The modifications we made are detailed in the following section “Bypassing liveness test.”

Step 7: MRZ scanning

The app opens the back camera and instructs the user to scan their passport Machine Readable Zone (MRZ). The MRZ is an area on paper passports printed with characters in a specific format. It is designed to be scanned optically, that is, a scanner will take a “photo” of the area, and use a computer program to recognize characters in the photo, then decode these characters into different fields. This process is known as Optical Character Recognition (OCR).

The passport MRZ contains the following data:

• Given name
• Family name
• Passport number
• Date of birth
• Nationality
• Sex
• Personal number (may be used by the issuing country as it desires)

ITP also provides an option for the user to skip MRZ scanning and enter passport details manually.

We tried to enter the data manually, and when saving, we observed no network traffic sending the entered data. This result indicates that the passport data is only stored on-device.

Step 8: Passport NFC chip reading

The app instructs the user to tap their phone on their passport NFC (Near Field Communication) chip. The chip is embedded in the passport booklet. A scanner communicates to the chip by sending radio waves to the booklet, which powers the chip and sends commands at the same time. The chip processes the commands and sends back a response using radio waves, which is processed by the scanner to decode data. The chip and its communication follow the ICAO Doc 9303 standard. The chip stores all text-based data that is printed on the passport, a digitally-encoded profile photo, and digital signatures that helps with verifying the data.

According to ITP’s Privacy Policy, the profile photo read from the passport NFC chip will be compared with the profile photo taken in an earlier step, and also compared with the photo taken during the liveness test. This comparison is designed to make sure that the user of the phone is actually in possession of the physical passport booklet, since the user is able to enter arbitrary data in the previous step, but it would be much harder for the user to fake a passport NFC scan.

To test this step, we developed a Frida script to send fake NFC scan results to ITP, which we detail in later sections. By doing so, we discovered that only the avatar photo contained in the chip was sent to IATA’s servers, but not the passport details. As indicated by its Privacy Policy, it is likely compared with the profile photo taken in step 5, to confirm the person taking the profile photo is actually the passport holder.

The passport chip reading seemed to be quite unreliable, barring many users from completing registration. This was a problem mentioned in many Google Play Store reviews.

Step 9: Complete registration

After scanning the passport chip, the registration is complete, and the user is directed to the app’s home screen.

Summary of Personally Identifiable Data collected by ITP

Through the registration ITP processes the following pieces of personally identifiable data (PII):

1. Fingerprint
2. Full name
3. Passport number
4. Date of birth
5. Passport expiry date
6. Nationality

Personal identifiable data sent out of the device includes:

1. Google account number is sent to Auth0 and Google
2. The profile picture taken in step 5 is sent to IATA servers
3. The avatar photo embedded in the passport’s NFC chip is sent to IATA servers

Impersonation by bypassing passport and liveness check

As described in previous sections, the liveness test during registration is processed entirely on-device. Further, the app does not check the authenticity of the data read from passport NFC chips. These design flaws allowed us to register an account using entirely fake names, profile pictures and other personal information. In this section, we explain our methods and discuss the impact of this loophole.

Bypassing liveness test

To bypass the liveness test, one needs to know how the app works internally in a normal operation flow. Through static analysis we learned that two components of the app are involved in the liveness test process: a view component and a tester component. The view component is in charge of controlling and displaying the user interface, as well as launching the tester component. The tester component is in charge of actually processing the video stream from the camera to tell if it passes or fails the liveness test.

Normally, when the tester component completes processing the video and considers the result passed, it sends a signal to the view component. When the view component receives the “pass” signal, it adjusts the user interface to show the next registration step, and also edits a value in the app’s database to mark passage of the liveness test.

To bypass the liveness test, we simply sent a fake “pass” signal to the view component. This signal is achieved by attaching a Frida script to the app.

One way to prevent bypass of the liveness test is to record videos of users performing specified head-tilting actions, and uploading the videos to the server for determination. However, this method adds a lot of bandwidth requirements and collects much more data from the user. It also might still be bypassed by users uploading fake videos.

Faking a passport NFC scan

Similar to the liveness test, the passport NFC scan is implemented with a view component and a tester component. The tester component first launches a NFC scan by sending a “scan request” to the system NFC service. (In the meantime, it also sends a signal to the view component telling it to show the “scanning” message.) Upon completing the scan, the system NFC service returns the raw data, which is parsed by the tester component into various passport data fields and the profile photo. Then, a completion signal called “PassportDataFetched” is sent to the view component. Different from the liveness test, the completion signal in this case also contains the passport details. After receiving the passport details from the PassportDataFetched signal, the view component compares them with the data obtained from the earlier MRZ scanning (or manual entry). If the data files match, the app concludes the user is in possession of the physical passport booklet, which fulfills the registration criteria.

To bypass the passport NFC scan, we sent a fake PassportDataFetched signal to the NFC scan view component, which is similar to how we bypassed the liveness test. Only in this case, we need to additionally construct fake data and attach them with the signal.

In our fake data, we made sure that:

1. The passport expiry date is in the future.
2. The profile photo contains the same face that we supplied in an earlier registration step, because this profile photo will be sent to the server for comparison.

Our script successfully faked a passport NFC scan, resulting in this screen:

 A solution that prevent attackers from faking passport scans is to upload all of the data along with digital signatures read from the passport NFC chip to the server, and check the signatures on the server (the check should not be performed on the client because if so it would also be susceptible to modification by faking a “check passed” status). NFC passports provide such digital signatures allowing the readers to check the authenticity of the data (determining whether the read data is identical to the data initially issued by the country authority), called Document Security Object (SOD). The process of authenticating data using the SOD is specified in ICAO Doc 9303 Part 11 Chapter 5.1 “Passive Authentication.” And the public keys that are needed for authentication can be found in the ICAO PKD Master List. Data authentication drastically increases the difficulty to fake passport data, while simultaneously giving the server access to highly sensitive personal information.

Impact

The ability to bypass liveness test and passport NFC scan allows an attacker to register ITP accounts only needing the victim’s passport details, but not the physical passport. If ITP accounts are used as the sole identity credential in physical-world situations, attackers will be able to use someone else’s identity to carry out these actions. There are three situations that require the traveler to prove their identity:

1. Registering with a COVID-19 test laboratory before taking a test
2. Checking in on a flight
3. Passing border control

We inquired with IATA regarding each of these situations. IATA responded that the impersonation attacks in those situations are not feasible either because the digital passports were not used or because physical passports were also checked. (IATA’s full response is listed in Appendix 1.)

When registering with a laboratory, IATA notes that “physical passports are required to ensure that the person present at the lab is the person holding the phone, showing the physical passport allows the lab agent to verify that the name and the passport picture match the details received on the Lab App screen and the face of the person in front of them.

When checking in to a flight, IATA explains that no airlines are using the digital passport feature for passenger check ins.

After disclosing the issues with the liveness check we found IATA is aware of the limitations and that these were “a business decision”. They note that:

“we could enforce a higher level of face matching and stronger controls to prevent bypassing the biometrics or to validating the passport authenticity, but for the time being, we do not want the app to be used to pass border controls nor to replace them, therefore these security levels are not required. They make the user experience very difficult and the onboarding onto the app painful, Currently, the priority is given to ease the passenger travel experience by allowing them to ensure that they have all the required travel documents for their journey (health certificates) – the app is an assistant to the passenger, not a controller”.

ITP digital passport

The results of the liveness test and passport NFC scans, and passport details, are used to create a “digital passport” in ITP. This feature is mentioned on the main webpage of ITP, where IATA states one of the functionalities of the app: “Enables passengers to (1) create a digital passport”. In a press release, IATA states “Global standards recognized by governments to ensure verified identity and test/vaccine information” as one of the key design elements of ITP, under which it further explains the digital passport feature:

“Verified identity: A government-issued ePassport is used to verify the identity of the user. It also serves to create a digital representation of the user’s passport to allow the information to be sent electronically in a secured way that is linked to their verified identity. The key to this are global standards developed by the International Civil Aviation Organization (ICAO) which match biometric passport data and a selfie taken by the user. This creates a Type 1 digital travel credential (a verified digital identify**) in line with ICAO standards”.

ITP does not contain a digital passport module on its home screen. We think the digital passport is likely only referring to a verifiable credential (i.e., a file) that contains the passport details entered during registration. The verifiable credential could be sent over to a verifier when needed.

From the web page descriptions and FAQ document, it sounded like one of ITP’s goals is to replace physical passports.⁵ If this was the case, the impersonation vulnerability we found would have a much wider impact. However, we found this was not the case after our correspondence with IATA clarified that “…for the time being, we do not want the app to be used to pass border controls nor to replace them…”

According to ICAO standards, Digital Travel Credential (DTC) Type 1 is derived from an existing travel document and the traveler must have their physical passport (eMRTD) in their possession while traveling.

In summary, despite its descriptions, the ITP digital passport currently only serves as an unverified digital version of the physical passport. It is currently only used when the user registers with a COVID-19 testing laboratory to take a test. And, in this scenario, according to IATA’s response to us: “physical passports are required to ensure that the person present at the lab is the person holding the phone, showing the physical passport allows the lab agent to verify that the name + the passport picture match the details received on the Lab App screen and the face of the person in front of them.”

Communicating with laboratories

After an account is created, the user’s next step is to go to a laboratory to test for COVID-19 infection. In order for the laboratory to send test results to the user’s ITP app, the user must first register their account with the laboratory. In this section, we first explain the user flow, then present our analysis of its inner workings.

Upon arriving, the user needs to scan a QR code provided by the laboratory, as can be seen in IATA’s demonstration video. The QR code scanner can be launched by pressing “CONNECT” on the ITP home screen.

 The QR code points to a URL which contains information needed to establish connection with the laboratory. ITP will fetch that information, which includes a list of data items required by the laboratory to register the user, and ask if the user would like to share these data items, as seen in the screenshot below.

In our case, clicking the “SHARE DATA” button resulted in the error message “We were unable to get information from that url.” This was likely because the QR code from the video is only for demonstration. To advance our investigation, we tried to look for other URLs used by laboratories in production. We noticed the QR code from the demonstration video actually contained the URL “https://vty.im/detmw”, and it redirects to a longer URL “http://vas.evernym.com/agency/msg?oob=eyJsYWJlbCI6IklBVEEg…”.

Based on the observation that “https://vty.im/” is a URL shortening service, and that URL shortening services usually produce short URLs in the same format, we developed a program to scan all 5-character “A” to “Z” combinations under https://vty.im/. We were able to discover many more URLs. One URL that we found was https://vty.im/npnlw, which redirects to “https://vas.evernym.com/agency/msg?oob=eyJsYWJlbCI6Ikc0M…”. The “label” on the response showed “G42 Abu Dhabi,” which is a COVID-19 testing laboratory in the United Arab Emirates. From IATA’s list of “Lab Network partners,” G42’s logo is also listed.

We generated a QR code containing the URL we just found and used ITP to scan it. ITP displayed a similar screen which listed the name “G42 Abu Dhabi” and the requested data items. We clicked “SHARE DATA.” This time there were no error messages, which shows that we have successfully registered with the laboratory.

With the network communication captured in this process, we identified that ITP was using the Aries protocol, which is a protocol built on top of HTTP and JSON Web Encryption (JWE), designed to transmit verifiable credentials. Various API calls to Evernym were also made.

The Aries protocol uses JWE to build another layer of encryption on top of the HTTPS that we were already able to intercept and decrypt. Theoretically, we are also able to decrypt the JWE encryption, however, this would be a tedious task. Therefore, we decided to continue our analysis based only on the Aries protocol documentation, which documents the communication steps in detail, and the Evernym product documentation, which documents the API call functions and formats provided by Evernym.

By studying the documentation, we pieced together the steps that were involved when ITP registers with the laboratory:

1. The user scans a QR code provided by the laboratory. The QR code contains a URL leading to an invitation to share data with the laboratory. The invitation also contains basic information about the inviter and the data fields it requests the user to share. Upon receiving the invitation, ITP shows the invitation on screen for the user to decide whether to share data.

2. The user clicks the “SHARE DATA” button. ITP will then encrypt and send those requested data fields to the laboratory. ITP also needs to make itself reachable for future messages from the laboratory. However, the device running ITP could be switched off and become unreachable. Therefore, ITP contacts Evernym to provision an always-online program called a “cloud agent.” The cloud agent acts like a mailbox: it receives all messages destined to ITP and stores them until ITP comes online to fetch them. With the data sent back to the laboratory, ITP also instructs the laboratory to send all future messages to the cloud agent.

These steps complete ITP’s registration with the laboratory.

Receiving test results

Since we did not actually go to the laboratory and take a COVID-19 test, we were unable to test further interactions in practice. We explain the following procedure based on what we learned studying the Aries protocol documentation and Evernym product documentation.

After the laboratory completes processing the user’s COVID-19 test results, it generates a test result certificate in verifiable credentials format and signs the certificate with its unique digital signature. Then, the certificate is sent to the user specified cloud agent. The cloud agent stores the certificate until ITP comes online and fetches the certificate. Note that the cloud agent is unable to see the certificate content because it is encrypted.

Verifying test results

We did not find public information documenting how the verification procedure works in practice. Thus, we also rely on our static analysis and reading of Aries and Evernym documentation to reconstruct the verification procedure. Therefore, the procedure outlined in this section may be different from what is actually performed by verifiers.

Once ITP receives the certificate, it will store the certificate in its local database. When a verifier needs to verify the certificate, the user must also “connect” with them by pressing the “CONNECT” button and scanning the QR code provided by the verifier. Once the QR code is scanned, the data fields requested by the verifier, which now may include fields from the COVID-19 test certificate, are displayed to the user. The user needs to confirm sharing by pressing a button. This action sends the requested data fields over to the verifier.

To verify the data, verifiers will check the digital signature attached with the data and fetch information from the Sovrin blockchain to make sure the data received (COVID-19 test certificate) had not been revoked by the issuer (laboratory).⁶ The intended verifiers of ITP users’ COVID-19 test results are airlines and border controls, according to IATA.

We also discovered that Evernym provides a web-based “Airline App,” which could be used by airlines to verify ITP users’ COVID-19 test results. However, when asked about the Airline App, both IATA and Evernym stated that to their knowledge it is not currently used by any airlines.

IATA provided no further details other than that “Verifiers are using the Verifiable Credentials technology provided by Evernym to authenticate and validate the data received.”

Based on this information there are two likely methods that the verifiers are currently using to verify ITP users’ COVID-19 test certificates. First, verifiers could ask the user to show the digital COVID-19 certificate they received in ITP and visually inspect the user’s screen. This method is extremely unreliable and could allow forged certificates to slip past the check, because as we have shown, it is technically possible to modify ITP’s execution flow. An attacker could alter the display logic of ITP and show a certificate that looks valid on screen, or even use more rudimentary methods like editing a screenshot of ITP.

Second, verifiers could rely on a standalone “verifier application” running on computers or phones. The standalone application would independently verify the certificate without relying on a centralized authority like Evernym to tell it the answers. Since ITP follows the verifiable credential and Sovrin open standards, as long as the verifier application also follows the standards, it would be able to correctly verify certificates (given a list of trusted issuers). In our study of verifiable credentials and Sovrin specifications, we did not find serious loopholes allowing forgery of certificates or improper verification of certificates. So, if the verifier application is implemented closely according to the standards, it should be able to correctly verify certificates and spot forged ones. However, the use of a standalone verifier application is purely hypothetical, as we did not see any mention of something similar throughout our research.

There is also a potential verification method that does not involve ITP at all: checking the users’ paper COVID-19 test certificates. In our correspondence IATA stressed to us that even when using ITP, “Airlines do not lose the ability to verify COVID-19 test results via other methods, including visual inspection of provided documentation.”

The verification process is key to any trustworthy credential system. Out of the three possible verification methods above, only the second method actually utilizes the technical guarantees of verifiable credentials to improve system trustworthiness. In the other two scenarios, the verifiable credentials technology is entirely sidelined. It would have made little difference to system trustworthiness if verifiable credentials technology were entirely removed from it.

Entering flights and determining eligibility of travel

The “Your Flights” module allows users to add their flights, query the travel requirements for their destinations, and automatically check if the COVID-19 test taken meets the travel requirements. If the user has not entered their upcoming flights before registering with the laboratory, the interface will prompt them to do so.

Adding a flight involves four steps:

1. The user clicks “Add a flight” in the “Your Flights” module.
2. The app queries its “airlines API” for a list of participating airlines. The airlines API returns two kinds of airlines which are using different “handlers”: “INTERNAL” handler and “COLLINS” handler. The “COLLINS” handler likely refers to the TransAction passenger management software produced by Collins Aerospace. The list of airlines is presented to the user as an options list.
   1. If the user selects an airline using the “INTERNAL” handler, a date picker will be shown for the user to select their flight date.
   2. If the user selects an airline using the “COLLINS” handler, a text input box is displayed for the user to enter their booking reference code.
3. The app queries its “flights API” with data entered in the previous step, to obtain a list of flights for user selection.
   3. For the “INTERNAL” handler, the carrier code and date of flight are sent.
   4. For the “COLLINS” handler, the booking reference code, family name, and given name are sent.
4. The app queries the Timatic API with the flight selected. The API returns the travel requirements, and the app shows them on a popup. (We could only test this step with airlines using the “INTERNAL” handler, since we do not have a flight booking reference code.)

In step 3, when testing the “COLLINS” handler, we noticed that it sends the user’s family name and given name along with the booking reference code:

GET /flight?carrier=NZ&bookingIdentifier=MFB7EH&familyName=SAMPLE&givenNames=DANIEL&date=2022-01-17T00:00:00Z HTTP/1.1
Authorization: [SNIP]
Host: prod.travelpassinfra.org
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/4.9.0

These personal data seem to be necessary to fetch the user’s flight booking details, which would be used later in step 4.

In step 4, we captured an HTTP request sending the user’s birth date, nationality, and passport expiration date to the IATA server:

POST /rules/timatic-check HTTP/1.1
Authorization: [SNIP]
Content-Type: application/json; charset=UTF-8
Content-Length: 220
Host: prod.travelpassinfra.org
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/4.9.0

{"origin":"AUH","destination":"MXP","departureDate":"2022-01-31T08:55:00","birthDate":"1970-11-11","nationality":"CAN","carrier":"EY","flightNumber":"81","passportExpiry":"2030-01-01","arrivalDate":"2022-01-31T12:10:00"}

This personal data seems to be necessary to check the entry requirements.

The personal data sent in step 4 is not specified in the privacy policy, nor anywhere on the user interface. This data transfer therefore may come as a surprise to most users and runs counter to the model of sharing personal data with laboratories, in which users are prompted to provide their consent.

Server API information leak vulnerability

We discovered an information leak vulnerability in the profile photo upload API, which is called when the user uploads their profile photo during registration. If we intercept and modify the request content to contain malformed image data like this request:

PATCH /image/ HTTP/1.1                                                                                                                                                         
Authorization: [SNIP]                                                                                                  
Content-Type: application/json; charset=UTF-8                                                                                                                                                                      
Content-Length: 398711                                                                                                                                                                                             
Host: prod.travelpassinfra.org                                                                                                                                                                                     
Connection: close                                                                                                                                                                                                  
Accept-Encoding: gzip, deflate                                                                                                                                                                                     
User-Agent: okhttp/4.9.0

{"userImage":"/9j/4AAQSkZJRgABAQAAAQABAAD/4gIoSUNDX1BST                                                                                                                                                            
[SNIP]                                                                                                                                                                                                             
"otherImage":"DSUq",                                                                                                                                                                                               
[SNIP]   

We receive a “HTTP/1.1 400 Bad Request” response from the server containing the error message and extra information:

{"status":400,"message":"Request has invalid image format","stack":"InvalidImageFormatException: Request has invalid image format\n    at Request.extractError (/app/node_modules/aws-sdk/lib/protocol/json.js:52:
27)\n    at Request.callListeners (/app/node_modules/aws-sdk/lib/sequential_executor.js:106:20)\n    at Request.emit (/app/node_modules/aws-sdk/lib/sequential_executor.js:78:10)\n    at Request.emit (/app/     
node_modules/aws-sdk/lib/request.js:688:14)\n    at Request.transition (/app/node_modules/aws-sdk/lib/request.js:22:10)\n    at AcceptorStateMachine.runTo (/app/node_modules/aws-sdk/lib/state_machine.js:14:    
12)\n    at /app/node_modules/aws-sdk/lib/state_machine.js:26:10\n    at Request. (/app/node_modules/aws-sdk/lib/request.js:38:9)\n    at Request. (/app/node_modules/aws-sdk/lib/request.  
js:690:12)\n    at Request.callListeners (/app/node_modules/aws-sdk/lib/sequential_executor.js:116:18)","code":"InvalidImageFormatException","name":"InvalidImageFormatException"} 

The response not only specified “Request has invalid image format,” but also showed us the exact lines of server-side software code and path names of the source code files (i.e., a “backtrace”) at which this check was performed and failed. This information is not necessary for the client to function and is considered sensitive to the server. While this information does not contain any personal data and discovery of it does not directly lead to a server compromise, it could still aid exploitation.

We disclosed this vulnerability to IATA on November 18, 2021. On November 26, IATA communicated to us that the vulnerability had been fixed, which we confirmed.

Policy

We analyzed ITP’s Privacy Policy and Terms & Conditions. The Privacy Policy outlined the assessments that vendors have to undergo; however, it did not mention Evernym at all, who implements the core function of ITP. The policy failed to list any of the data processors we found, which includes at least Evernym, Collins Aerospace, Auth0, and Google, according to our findings. According to the GDPR, data controllers shall provide information on the recipients of the personal data.

Also, to our understanding, ITP’s Privacy Policy covers only the scope of the app and does not cover scenarios such as when users use ITP to share their information with laboratories and airlines. However, in these scenarios, ITP provides no mechanism for the laboratories and airlines to show users their privacy policies. It would be up to those recipients to implement methods outside of the app to present privacy policies to the users.

Discussion and Conclusion

Digital passport design and caveats

Our research shows that it is possible to create impersonated ITP digital passports. In our disclosure engagements with IATA they stated:

“We are aware of the limitation of the liveness check and this is a business decision.

We could enforce a higher level of face matching and stronger controls to prevent bypassing the biometrics or to validating the passport authenticity, but for the time being, we do not want the app to be used to pass border controls nor to replace them, therefore these security levels are not required. They make the user experience very difficult and the onboarding onto the app painful.

Currently, the priority is given to ease the passenger travel experience by allowing them to ensure that they have all the required travel documents for their journey (health certificates) – the app is an assistant to the passenger, not a controller”.

IATA’s statements show that ITP digital passports were not designed to be as trustworthy as a physical passport. This design decision is understandable since it would require much more personal information to be sent over to the server for verification to reach the same level of trustworthiness as physical passports. This additional exposure increases the risk of data breaches.

However, this limitation makes the name “digital passport” misleading, because it should not be trusted on the same level as physical passports. Verifiers must not take the digital passport as trustworthy information and always verify the physical passport. Failure to do so will allow impersonation to go unchecked. So far, based on IATA’s statements, whenever the ITP digital passport is used, physical passports are always checked. However, as ITP expands to more airports and potentially other use cases, verifiers must take care to make sure physical passports continue to be verified.

Since the digital passport must be cross checked with a physical passport during identity verification, it essentially serves no security purpose. In other words, there would be no loss of security if the digital passport was completely omitted from the process.

Centrally-managed private signing keys and Lab App

Laboratories participating in the ITP program issue digital COVID-19 test certificates using the Lab App, which is a web application provided by Evernym on a SaaS (Software as a Service) basis. Issuing requires the certificates to be digitally signed using a private key. Each private key has a corresponding public key, which could be used to verify whether a signed certificate is authentic (i.e., signed by the private key). Through correspondence with Evernym, we learned that the Lab App stores and manages the private keys on behalf of the laboratories.

Storing private keys in the Lab App essentially gives Evernym full control over the certificate issuing process. If the Lab App was ever compromised, it could be used to issue rogue certificates. Even when it is operating normally, Evernym will be able to see the full content of the communication between the laboratories and the ITP app, which includes passport details and COVID-19 test results. Although this is not a vulnerability itself, it does nullify most of the benefits brought by the peer-to-peer verifiable credentials technology, and make the system very similar to a conventional centralized system.

If ITP laboratories store and manage their private keys on their own, and issue certificates using those keys, no central authority would be able to know anything about the issued certificates nor the personal information of the certificate holders. If one laboratory’s key was compromised, other laboratories would not be affected. However, an individual laboratory is unlikely to possess the technical expertise to protect the private keys on the same level as a central management authority like Evernym. These difficulties are a central challenge in choosing between a centralized and decentralized system architecture.

We lack the technical details on ITP’s implementation to verify test results. If a centralized web application similar to the Airline App was used, Evernym would be in control of both the issuing and verification of COVID-19 test reports. Compared to the traditional paper-based issuing and verification system, this design consolidates the power held by the issuer (laboratories) and verifier (airlines and border control) into one entity. Even if a standalone verifier application was used, based on IATA’s statements, it is still using the technology provided by Evernym, and that still gives Evernym a lot of control. The standalone application could malfunction, or be biased towards trusting certificates issued by Evernym’s Lab App.

In short, ITP’s current low-level system architecture is decentralized; however, it is encapsulated by a centralized high-level interface. If operated through the centralized interface, the system possesses the same set of security and privacy properties as conventional centralized systems.

One likely reason for why Evernym implemented a centralized interface is to remove the burden on laboratories to securely manage their private keys. Also, laboratory staff need a simple and stable graphical interface to upload test results, which could be achieved more easily with a centralized interface rather than a peer-to-peer client program.

Since the low-level system is based on an open peer-to-peer standard, anyone with technical capabilities could theoretically build a compatible client. To our knowledge, Evernym’s Lab App is also just a standard-complying client to the peer-to-peer protocol. When laboratories feel the need, they can switch to different clients that allow them to manage their own private keys.

The future of Self-Sovereign Identity (SSI)

Other than COVID-19 passports, SSI have many other use cases. Scenarios where the requirements of a identity system can be mapped onto the following model can be implemented with SSI:

• there is a credential that needs to be proved by the prover
• a credential can be issued by an issuer to the prover
• a verifier needs to verify authenticity and integrity of the credential provided by the prover

These features make SSI highly versatile. For instance, it can be used to issue diplomas, financial statements, driver’s licenses, entry permits (to a building or country), and many more. This versatility attracts implementers in different fields to evaluate the adoption of SSI, or to interoperate with it. For instance, there have been discussions on how the Pan-Canadian Trust Framework⁷ drafted by the Digital ID & Authentication Council of Canada (a neutral forum) can map to SSI models. The government of British Columbia, Canada is also trialing “OrgBook,” a directory service (of legally registered organizations) based on Hyperledger Indy, a SSI platform. Within the European Union, there are also experimental SSI-based identity system projects that aim to interoperate with national identity systems, such as the European Self-Sovereign Identity Framework (ESSIF).

The problems we found in ITP are not inherent to SSI, but rather specific to this implementation of SSI. However, an incorrectly implemented instance of SSI may consolidate even more control to one entity than conventional paper-based systems.

SSI technology is currently in its early adoption phase and there are only a few vendors providing compatible software. Whoever controls the implementation also controls the system. The decentralized and standardized nature of Sovrin only guarantees a level competing ground for different implementations, but does not necessarily prevent one implementation from becoming dominant. In ITP, we see such implementater’s power being consolidated into one entity. In the future, third-party audits, reproducible builds, and private key management all have to work together to prevent abuse of the implementer’s power. But most fundamentally, implementers of certificate issuance systems and verification systems should be separated for the entire system to be trustworthy.

While SSI has potential, it is also complex. In ITP’s case, we found that the integration with SSI provides little practical improvement on decentralization, user control of personal data, or trustworthiness of the credentials. These problems show that not all SSI-based systems are more trustworthy and better protect user privacy over conventional ones and research is still needed to improve SSI-based systems.

Sovrin versus Public Key Infrastructure (PKI)

The usage scenarios of SSI mentioned in the previous section overlaps with the usage scenarios of Public Key Infrastructure. PKI is a more conventional technology that is currently widely used, such as in verifying the identity of websites. These similarities posit the option of using PKI to implement ITP features instead of Sovrin. Compared to PKI, using Sovrin seems to introduce a lot of complexities, most notably, a blockchain network.

The main benefits of Sovrin over PKI are:

1. Checking revocation status of a certificate without contacting the issuer or a central authority. In PKI, checking certificate revocation status generally requires the checker to contact the issuer of the certificate or a central authority, which comes with a privacy risk.⁸

2. Selectively disclose (proof) information on a certificate. Using Sovrin, the certificate holder can prove to the verifier only selected attributes on the certificate. For instance, when proving oneself to be COVID-19 negative, the COVID-19 test certificate holder can decide to disclose only the name and test result, without the birth date. When numerical attributes are involved, such as people’s ages, one can even use Sovrin to prove that they are “over the age of 18,” without disclosing the actual age, though this capability was not used in ITP. In PKI, one can not verify partial information from a certificate.

It is unclear if Sovrin’s benefits over PKI are worth the complexities also introduced by it, since it is difficult to estimate the complexities and cost of a hypothetical, alternate ITP built with PKI. However, our research shows the technical aspects where Sovrin differs from PKI.

Collection and tracking of digital information to validate identity and COVID-19 status will continue to be required as companies and airlines impose and enforce COVID-19 protocols. Our study highlights ongoing privacy issues and questions for how these technologies are designed and managed.

Acknowledgements

Special thanks to Masashi Crete-Nishihata, Christopher Parsons, Siena Anstis , Adam Senft, and Miles Kenyon. Funding for this research was provided by foundations listed on the Citizen Lab’s website. Research for this project was supervised by Masashi Crete-Nishihata and Professor Ron Deibert.

Appendices

Appendix 1: IATA’s response to our questions

Note: we replaced the IATA representative’s name with “IATA”.

Appendix 2: Evernym’s response to our questions