Centre for Internet and Society

Comments on InDEA 2.0

divyank — 2022-03-22T06:26:39Z

For more details visit http://editors.cis-india.org/internet-governance/comments-on-indea-2.0

Do We Really Need an App for That? Examining the Utility and Privacy Implications of India’s Digital Vaccine Certificates

divyank — 2021-08-03T05:13:28Z

We examine the purported benefits of digital vaccine certificates over regular paper-based ones and analyse the privacy implications of their use.

This blogpost was edited by Gurshabad Grover, Yesha Tshering Paul, and Amber Sinha.
It was originally published on Digital Identities: Design and Uses and is cross-posted here.

In an experiment to streamline its COVID-19 immunisation drive, India has adopted a centralised vaccine administration system called CoWIN (or COVID Vaccine Intelligence Network). In addition to facilitating registration for both online and walk-in vaccine appointments, the system also allows for the digital verification of vaccine certificates, which it issues to people who have received a dose. This development aligns with a global trend, as many countries have adopted or are in the process of adopting “vaccine passports” to facilitate safe movement of people while resuming commercial activity.

Some places, such as the EU, have constrained the scope of use of their vaccine certificates to international travel. The Indian government, however, has so far skirted important questions around where and when this technology should be used. By allowing anyone to use the online CoWIN portal to scan and verify certificates, and even providing a way for the private-sector to incorporate this functionality into their applications, the government has opened up the possibility of these digital certificates being used, and even mandated, for domestic everyday use such as going to a grocery shop, a crowded venue, or a workplace.

In this blog post, we examine the purported benefits of digital vaccine certificates over regular paper-based ones, analyse the privacy implications of their use, and present recommendations to make them more privacy respecting. We hope that such an analysis can help inform policy on appropriate use of this technology and improve its privacy properties in cases where its use is warranted.

We also note that while this post only examines the merits of a technological solution put out by the government, it is more important to consider the effects that placing restrictions on the movement of unvaccinated people has on their civil liberties in the face of a vaccine rollout that is inequitable along many lines, including gender, caste-class, and access to technology.

How do digital vaccine certificates work?

Every vaccine recipient in the country is required to be registered on the CoWIN platform using one of seven existing identity documents. [1] Once a vaccine is administered, CoWIN generates a vaccine certificate which the recipient can access on the CoWIN website. The certificate is a single page document that contains the recipient’s personal information — their name, age, gender, identity document details, unique health ID, a reference ID — and some details about the vaccine given. [2] It also includes a “secure QR code” and a link to CoWIN’s verification portal.

The verification portal allows for the verification of a certificate by scanning the attached QR code. Upon completion, the portal displays a success message along with some of the information printed on the certificate.

Verification is done using a cryptographic mechanism known as digital signatures, which are encoded into the QR code attached to a vaccine certificate. This mechanism allows “offline verification”, which means that the CoWIN verification portal or any private sector app attempting to verify a certificate does not need to contact the CoWIN servers to establish its authenticity. It instead uses a “public key” issued by CoWIN beforehand to verify the digital signature attached to the certificate.

The benefit of this convoluted design is that it protects user privacy. Performing verification offline and not contacting the CoWIN servers, precludes CoWIN from gleaning sensitive metadata about usage of the vaccine certificate. This means that CoWIN does not learn about where and when an individual uses their vaccine certificate, and who is verifying it. This closes off a potential avenue for mass surveillance. [3] However, given how certificate revocation checks are being implemented (detailed in the privacy implications section below), CoWIN ends up learning this information anyway.

Where is digital verification useful?

The primary argument for the adoption of digital verification of vaccine certificates over visual examination of regular paper-based ones is security. In the face of vaccine hesitancy, there are concerns that people may forge vaccine certificates to get around any restrictions that may be put in place on the movement of unvaccinated people. The use of digital signatures serves to allay these fears.

In its current form, however, digital verification of vaccine certificates is no more secure than visually inspecting paper-based ones. While the “secure QR code” attached to digital certificates can be used to verify the authenticity of the certificate itself, the CoWIN verification portal does not provide any mechanism nor does it instruct verifiers to authenticate the identity of the person presenting the certificate. This means that unless an accompanying identity document is also checked, an individual can simply present someone else’s certificate.

There are no simple solutions to this limitation; adding a requirement to inspect identity documents in addition to digital verification of the vaccine certificate would not be a strong enough security measure to prevent the use of duplicate vaccine certificates. People who are motivated enough to forge a vaccine certificate, can also duplicate one of the seven ID documents which can be used to register on CoWIN, some of which are simple paper-based documents. [4] Requiring even stronger identity checks, such as the use of Aadhaar-based biometrics, would make digital verification of vaccine certificates more secure. However, this would be a wildly disproportionate incursion on user privacy — allowing for the mass collection of metadata like when and where a certificate is used — something that digital vaccine certificates were explicitly designed to prevent. Additionally, in Russia, people were found issuing fake certificates by discarding real vaccine doses instead of administering them. No technological solution can prevent such fraud.

As such, the utility of digital certificates is limited to uses such as international travel, where border control agencies already have strong identity checks in place for travellers. Any everyday usage of the digital verification functionality on vaccine certificates would not present any benefit over visually examining a piece of paper or a screen.

Privacy implications of digital certificates

In addition to providing little security utility over manual inspection of certificates, digital certificates also present privacy issues, these are listed below along with recommendations to mitigate them:

(i) The verification portal leaks sensitive metadata to CoWIN’s servers: An analysis of network requests made by the CoWin verification portal reveals that it conducts a ‘revocation check’ each time a certificate is verified. This check was also found in the source code, which is made openly available. [5]

Revocation checks are an important security consideration while using digital signatures. They allow the issuing authority (CoWIN, in this case) to revoke a certificate in case the account associated with it is lost or stolen, or if a certificate requires correction. However, the way they have been implemented here presents a significant privacy issue. Sending certificate details to the server on every verification attempt allows it to learn about where and when an individual is using their vaccine certificate.

We note that the revocation check performed by the CoWIN portal does not necessarily mean that it is storing this information. Nevertheless, sending certificate information to the server directly contradicts claims of an “offline verification” process, which is the basis of the design of these digital certificates.

Recommendations: Implementing privacy-respecting revocation checks such as Certificate Revocation Lists, [6] or Range Queries [7] would mitigate this issue. However, these solutions are either complex or present bandwidth and storage tradeoffs for the verifier.

(ii) Oversharing of personally identifiable information: CoWIN’s vaccine certificates include more personally identifiable information (name, age, gender, identity document details and unique health ID) than is required for the purpose of verifying the certificate. An examination of the vaccine certificates available to us revealed that while the Aadhaar number is appropriately masked, other personal identifiers such as passport number and unique health ID were not masked. Additionally, the inclusion of demographic details, such as age and gender, provides little security benefit by limiting the pool of duplicate certificates that can be used and are not required in light of the security analysis above.

Recommendation: Personal identifiers (such as passport number and unique health ID) should be appropriately masked and demographic details (age, gender) can be removed.

The minimal set of data required for identity-linked usage for digital verification, as described above, is a full name and masked ID document details. All other personally identifying information can be removed. In case of paper-based certificates, which is suggested for domestic usage, only the details about vaccine validity would suffice and no personal information is required.

(iii) Making information available digitally increases the likelihood of collection: All of the personal information printed on the certificate is also encoded into the QR code. This is necessary because the digital signature verification process also verifies the integrity of this information (i.e. it wasn’t modified). A side effect of this is that the personal information is made readily available in digital form to verifiers when it is scanned, making it easy for them to store. This is especially likely in private sector apps who may be interested in collecting demographic information and personal identifiers to track customer behaviour.

Recommendation: Removing extraneous information from the certificate, as suggested above, mitigates this risk as well.

Conclusion

Our analysis reveals that without incorporating strong, privacy-invasive identity checks, digital verification of vaccine certificates does not provide any security benefit over manually inspecting a piece of paper. The utility of digital verification is limited to purposes that already conduct strong identity checks.

In addition to their limited applicability, in their current form, these digital certificates also generate a trail of data and metadata, giving both government and industry an opportunity to infringe upon the privacy of the individuals using them.

Keeping this in mind, the adoption of this technology should be discouraged for everyday use.

References

[1] Exceptions exist for people without state-issued identity documents.

[2] This information was gathered by inspecting three vaccine certificates linked to the author’s CoWIN account, which they were authorised to view, and may not be fully accurate.

[3] This design is similar to Aadhaar’s “offline KYC” process.

[4] “Aadhaar Card: UIDAI says downloaded versions on ordinary paper, mAadhaar perfectly valid”, Zee Business, April 29 2019, https://www.zeebiz.com/india/news-aadhaar-card-uidai-says-downloaded-versions-on-ordinary-paper-maadhaar-perfectly-valid-96790.

[5] This check was also verified to be present in the reference code made available for private-sector applications incorporating this functionality, suggesting that private sector apps will also be affected by this.

[6] Certificate Revocation Lists allow the server to provide a list of revoked certificates to the verifier, instead of the verifier querying the server each time. This, however, can place heavy bandwidth and storage requirements on the verifying app as this list can potentially grow long.

[7] Range Queries are described in this paper. In this method, the verifier requests revocation status from the server by specifying a range of certificate identifiers within which the certificate being verified lies. If there are any revoked certificates within this range, the server will send their identifiers to the verifier, who can then check if the certificate in question is on the list. For this to work, the range selected must be sufficiently large to include enough potential candidates to keep the server from guessing which one is in use.

For more details visit http://editors.cis-india.org/internet-governance/blog/do-we-really-need-an-app-for-that-examining-the-utility-and-privacy-implications-of-india2019s-digital-vaccine-certificates

cis-mozilla-doh-trr

divyank — 2021-01-19T07:26:04Z

For more details visit http://editors.cis-india.org/internet-governance/cis-mozilla-doh-trr

Investigating Encrypted DNS Blocking in India

divyank — 2020-10-27T11:21:08Z

We find that encrypted DNS protocols are not blocked in India and share our test methodology.

This report was edited and reviewed by Gurshabad Grover and Simone Basso.

The Domain Name System (DNS) translates human-readable web addresses, like ‘cis-india.org’, into machine-readable IP addresses, such as ‘172.67.211.18’, that the routers that comprise the internet can understand and direct traffic to. This basic function of the web has historically operated unencrypted — allowing intermediaries that facilitate access to the internet, like coffee shop Wi-Fi operators and internet service providers (ISPs), to view what websites we visit. This gap in privacy is being exploited by both public and private entities to censor access to the web and surveil our browsing habits.

New internet protocols are being deployed that attempt to encrypt connections to DNS providers. Through the use of these methods, the contents of DNS queries are hidden from network intermediaries and eavesdroppers and are only visible to the DNS provider chosen by an individual or a default one assigned to them by their ISP or web browser. While there are other ways of censoring web traffic, encrypted DNS protocols prevent censors from using their older DNS-based methods. In response to these new protocols, states like Iran are trying to block them entirely, to maintain the status quo.

In this report, we investigate and find that encrypted DNS protocols, specifically the DNS over HTTPS (DoH) and DNS over TLS (DoT) standards, are accessible through major Indian ISPs, and describe the technical details of our testing methodology.

Test Setup

We compiled a list of publicly accessible DNS resolvers that support the encrypted DoH and DoT protocols and tested access to them from four popular Indian ISPs, namely Airtel, Atria Convergence Technologies (ACT), Reliance Jio, and Vodafone. Together, these cover a large majority (roughly 95%, as reported by TRAI) of the Indian internet subscriber base.

To test connectivity, we used the Open Observatory for Network Interference (OONI) probe engine (version 0.18.0). Specifically, the ‘miniooni’ command-line interface tool bundled with it. Instructions on how to install this can be found here.

Test methodology

To test whether DNS providers are reachable over encrypted communication protocols, the tool performs a DNS query using the specified one (either DoH or DoT). If the connection is successful and we receive a response from the DNS server, we conclude that the protocol is not blocked. Failing to query a specific DNS server over DoT or DoH does not necessarily mean that it has been censored. To understand whether a failure could be censorship, rather than a transient error, we would correlate measurements from many users within the same ISP and country and use an alternate network, such as a VPN, to access the possibly blocked service from another country.

In Iran, where DNS over TLS is reported to be blocked, it was found that censorship occurs by interfering with the TLS handshake. Traffic corresponding to DNS over TLS is easier to identify and block as it communicates over a unique port and a distinctive ALPN, while DNS over HTTPS traffic is harder to block effectively as the HTTPS standard is widely used on the web and interference would lead to collateral censorship.

Results

The tests were run on each ISP in early October 2020 using the following command:

$ ./miniooni --file=./resolvers.txt dnscheck

The raw results in the OONI data format can be found here. A summary of the observations are as follows:

All DNS resolvers tested were accessible over both DoH and DoT protocols from all ISPs tested.
IPv6 addresses were not reachable through ACT broadband. This limitation was independently confirmed using the Test-IPv6 tool and has also been discussed on Reddit.

Limitations

As our previous research by the Centre for Internet and Society indicates, censorship practices vary across ISPs. While we find no evidence of encrypted DNS protocols being blocked on these four major ISPs, there may be others implementing such blocking.

The second limitation is that these tests were run on a handful of connections from a couple of locations (Delhi and Bangalore). Web censorship mechanisms may vary by location within the country.

Finally, the results only indicate the accessibility of encrypted DNS resolvers at a particular point in time. We have not put in place any continuous monitoring of the censorship of encrypted DNS protocols.

Conclusion

Broadly, the legal framework of web censorship in India allows the Government and courts to ask ISPs to block access to online resources. The precise technical details of how to implement the censorship are left to the ISPs.

Because of net neutrality obligations, ISPs are not supposed to arbitrarily block resources. Coupled with the fact that the use of encrypted DNS protocols is not related to any particular content/website deemed unlawful, it might be expected that ISPs are not blocking encrypted DNS protocols. However, previous evidence of arbitrary blocking by ISPs motivated us to study whether any major ISP was blocking the use of these protocols or preventing access to any third-party DNS server.

As part of this exercise, we also contributed code to the OONI probe engine, making it easier for other researchers to test connectivity to multiple DNS providers.

For more details visit http://editors.cis-india.org/internet-governance/blog/investigating-encrypted-dns-blocking-in-india

The State of Secure Messaging

divyank — 2020-07-17T08:12:15Z

A look at the protections provided by and threats posed to secure communication online.

This blogpost was edited by Gurshabad Grover and Amber Sinha.

The current benchmark for secure communication online is end-to-end encrypted messaging. It refers to a method of encryption wherein the contents of a message are only readable by the devices of the individuals, or endpoints, participating in the communication. All other Internet intermediaries such as internet service providers, internet exchange points, undersea cable operators, data centre operators, and even the messaging service providers themselves cannot read them. This is achieved through cryptographic mechanisms that allow independent devices to establish a shared secret key over an insecure communication channel, which they then use to encrypt and decrypt messages. Common examples of end-to-end encrypted messaging are applications like Signal and WhatsApp.

This post attempts to give at-risk individuals, concerned citizens, and civil society at large a more nuanced understanding of the protections provided and threats posed to the security and privacy of their communications online.

Threat Model

The first step to assessing security and privacy is to identify and understand actors and risks. End-to-end encrypted messaging applications consider the following threat model:

Device compromise: Can happen physically through loss or theft, or remotely. Access to an individual’s device could be gained through technical flaws or coercion (legal, or otherwise). It can be temporary or be made persistent by installing malware on the device.
Network monitoring and interference: Implies access to data in transit over a network. All Internet intermediaries have such access. They may either actively interfere with the communication or passively observe traffic.
Server compromise: Implies access to the web server hosting the application. This could be achieved through technical flaws, insider access such as an employee, or through coercion (legal, or otherwise).

End-to-end encrypted messaging aims to offer complete message confidentiality and integrity in the face of server and network compromise, and some protections against device compromise. These are detailed below.

Protections Provided

Secure messaging services guarantee certain properties. For mature services that have received adequate study from researchers, we can assume them to be sound, barring implementation flaws which are described later.

Confidentiality: The contents of a message are kept private and the ciphers used are practically unbreakable by adversaries.

Integrity: The contents of a message cannot be modified in transit.

Deniability: Aims to mimic unrecorded real-world conversations where an individual can deny having said something. Someone in possession of the chat transcript cannot cryptographically prove that an individual authored a particular message. While some applications feature such off-the-record messaging capabilities, the legal applicability of such mechanisms is debatable.

Forward and Future Secrecy: These properties aim to limit the effects of a temporary compromise of credentials on a device. Forward secrecy ensures messages collected over the network, which were sent before the compromise, cannot be decrypted. Future secrecy ensures messages sent post-compromise are protected. These mechanisms are easily circumvented in practice as past messages are usually stored on the device being compromised, and future messages can be obtained by gaining persistent access during compromise. These properties are meant to protect individuals aware of these limitations in exceptional situations such as a journalist crossing a border.

Shortcomings

While secure messaging services offer useful protections they also have some shortcomings. It is useful to understand these and their mitigations to minimise risk.

Metadata: Information about a communication such as who the participants are, when the messages are sent, where the participants are located, and what the size of a message is can offer important contextual information about a conversation. While some popular messaging services attempt to minimize metadata generation, metadata leakage, in general, is still considered an open problem because such information can be gleaned by network monitoring as well as from server compromise. Application policies around whether such data is stored and for how long it is retained can improve privacy. There are also experimental approaches that use techniques like onion routing to hide metadata.

Authentication: This is the process of asserting whether an individual sending or receiving a message is who they are thought to be. Current messaging services trust application servers and cell service providers for authentication, which means that they have the ability to replace and impersonate individuals in conversations. Messaging services offer advanced features to mitigate this risk, such as notifications when a participant’s identity changes, and manual verification of participants’ security keys through other communication channels (in-person, mail, etc.).

Availability: An individual’s access to a messaging service can be impeded. Intermediaries may delay or drop messages resulting in what is called a denial of service attack. While messaging services are quite resilient to such attacks, governments may censor or completely shut down Internet access.

Application-level gaps: Capabilities offered by services in addition to messaging, such as contact discovery, online status, and location sharing are often not covered by end-to-end encryption and may be stored by the application server. Application policies around how such information is gathered and retained affect privacy.

Implementation flaws and backdoors: Software or hardware flaws (accidental or intentional) on an individual’s device could be exploited to circumvent the protections provided by end-to-end encryption. For mature applications and platforms, accidental flaws are difficult and expensive to exploit, and as such are only accessible to Government or other powerful actors who typically use them to surveil individuals of interest (and not for mass surveillance). Intentional flaws or backdoors introduced by manufacturers may also be present. The only defence against these is security researchers who rely on manual inspection to examine software and network interactions to detect them.

Messaging Protocols and Standards

In the face of demands for exceptional access to encrypted communication from governments, and risks of mass surveillance from both governments and corporations, end-to-end encryption is important to enable secure and private communication online. The signal protocol, which is open and adopted by popular applications like WhatsApp and Signal, is considered a success story as it brought end-to-end encryption to over a billion users and has become a de-facto standard.

However, it is unilaterally developed and controlled by a single organisation. Messaging Layer Security (or MLS) is a working group within the Internet Engineering Task Force (IETF) that is attempting to standardise end-to-end encryption through participation of individuals from corporations, academia, and civil society. The draft protocol offers the standard security properties mentioned above, except for deniability which is still being considered. It incorporates novel research that allows it to scale efficiently for large groups up to thousands of participants, which is an improvement over the signal protocol. MLS aims to increase adoption further by creating open standards and implementations, similar to the Transport Layer Security (TLS) protocol used to encrypt much of the web today. There is also a need to look beyond end-to-end encryption to address its shortcomings, particularly around authentication and metadata leakage.

For more details visit http://editors.cis-india.org/internet-governance/blog/the-state-of-secure-messaging