Centre for Internet and Society

Online Censorship - Perspectives From Content Creators and Comparative Law

divyank — 2024-08-26T06:55:20Z

For more details visit http://editors.cis-india.org/internet-governance/online-censorship-perspectives-from-content-creators-and-comparative-law

Legal Advocacy Manual

divyank — 2024-07-01T08:15:05Z

For more details visit http://editors.cis-india.org/internet-governance/legal-advocacy-manual

Digital Rights Guide

divyank — 2024-07-01T08:00:09Z

For more details visit http://editors.cis-india.org/internet-governance/digital-rights-guide

India’s parental control directive and the need to improve stalkerware detection

divyank — 2024-04-04T14:20:41Z

We analyse a child-monitoring app being developed by the Indian government and question whether it is an effective way to enact parental controls. We highlight how such monitoring apps are often repurposed for digital stalking and play a role in intimate partner violence. We also evaluate the protection provided by antivirus tools in detecting such stalkerware apps and describe how we collected technical evidence to help improve the detection of these apps.

This post was reviewed and edited by Amrita Sengupta.

Stalkerware is a form of surveillance targeted primarily at partners, employees and children in abusive relationships. These are software tools that enable abusers to spy on a person’s mobile device, allowing them to remotely access all data on the device, including calls, messages, photos, location history, browsing history, app data, and more. Stalkerware apps run hidden in the background without the knowledge or consent of the person being surveilled.[1] Such applications are easily available online and can be installed by anyone with little technical know-how and physical access to the device.

News reports indicate that the Ministry of Electronics and Information Technology (MeitY) is supporting the development of an app called “SafeNet”[2] that allows parents to monitor activity and set content filters on children’s devices. Following a directive from the Prime Minister’s office to “incorporate parental controls in data usage” by July 2024, the Internet Service Providers Association of India (ISPAI) has suggested that the app should come preloaded on mobile phones and personal computers sold in the country. The Department of Telecom is also asking schools to raise awareness about such parental control solutions.[3][4]

The beta version of the app is available for Android devices on the Google Play Store and advertises a range of functionalities including location access, monitoring website and app usage, call and SMS logs, screen time management and content filtering. The content filtering functionality warrants a separate analysis and this post will only focus on the surveillance capabilities of this app.

Applications like Safenet, that do not attempt to hide themselves and claim to operate with the knowledge of the person being surveilled, are sometimes referred to as “watchware”.[5] However, for all practical purposes, these apps are indistinguishable from stalkerware. They possess the same surveillance capabilities and can be deployed in the exact same ways. Such apps sometimes incorporate safeguards to notify users that their device is being monitored. These include persistent notifications on the device’s status bar or a visible app icon on the device’s home screen. However, such safeguards can be circumvented with little effort. The notifications can simply be turned off on some devices and there are third-party Android tools that allow app icons and notifications to be hidden from the device user, allowing watchware to be repurposed as stalkerware and operate secretly on a device. This leaves very little room for distinction between stalkerware and watchware apps.[6] In fact, the developers of stalkerware apps often advertise their tools as watchware, instructing users to only use them for legitimate purposes.

Even in cases where stalkerware applications are used in line with their stated purpose of monitoring minors’ internet usage, the effectiveness of a surveillance-centric approach is suspect. Our previous work on children’s privacy has questioned the treatment of all minors under the age of 18 as a homogenous group, arguing for a distinction between the internet usage of a 5-year-old child and a 17-year-old teenager. We argue that educating and empowering children to identify and report online harms is more effective than attempts to surveil them.[7][8] Most smartphones already come with options to enact parental controls on screen time and application usage[9][10], and the need for third-party applications with surveillance capabilities is not justified.

Studies and news reports show the increasing role of technology in intimate partner violence (IPV).[11][12] Interviews with IPV survivors and support professionals indicate an interplay of socio-technical factors, showing that abusers leverage the intimate nature of such relationships to gain access to accounts and devices to exert control over the victim. They also indicate the prevalence of “dual-use” apps such as child-monitoring and anti-theft apps that are repurposed by abusers to track victims.[13]

There is some data available that indicates the use of stalkerware apps in India. Kaspersky anti-virus’ annual State of Stalkerware reports consistently place India among the top 4 countries with the most number of infections detected by its product, with a few thousand infections reported each year between 2020 and 2023.[14][15][16[17] TechCrunch’s Spyware Lookup Tool, which compiles information from data leaks from more than nine stalkerware apps to notify victims, also identifies India as a hotspot for infections.[18] Avast, another antivirus provider, reported a 20% rise in the use of stalkerware apps during COVID-19 lockdowns.[19] The high rates of incidence of intimate partner violence in India, with the National Family Health Survey reporting that about a third of all married women aged 18–49 years have experienced spousal violence [20], also increases the risk of digitally-mediated abuse.

Survivors of digitally-mediated abuse often require specialised support in handling such cases to avoid alerting abusers and potential escalations. As part of our ongoing work on countering digital surveillance, we conducted an analysis of seven stalkerware applications, including two that are based in India, to understand and improve how survivors and support professionals can detect their presence on devices.

In some cases, where it is safe to operate the device, antivirus solutions can be of use. Antivirus tools can often identify the presence of stalkerware and watchware on a device, categorising them as a type of malware. We measured how effective various commercial antivirus solutions are at detecting stalkerware applications. Our results, which are detailed in the Appendix, indicate a reasonably good coverage, with six out of the seven apps being flagged as malicious by various antivirus solutions. We found that Safenet, the newest app on the list, was not detected by any antivirus. We also compared the detection results with a similar study conducted in 2019 [21] and found that some newer versions of previously known apps saw lower rates of detection. This indicates that antivirus solutions need to analyse new apps and newer versions of apps more frequently to improve coverage and understand how they are able to evade detection.

In cases where the device cannot be operated safely, support workers use specialised forensic tools such as the Mobile Verification Toolkit [22] and Tinycheck [23], which can be used to analyse devices without modifying them. We conducted malware analysis on the stalkerware apps to document the traces they leave on devices and submitted them to an online repository of indicators of compromise (IOCs).[24] These indicators are incorporated in detection tools used by experts to detect stalkerware infections.

Despite efforts to support survivors and stop the spread of stalkerware applications, the use of technology in abusive relationships continues to grow.[25] Making a surveillance tool like Safenet available for free, publicising it for widespread use, and potentially preloading it on mobile devices and personal computers sold in the country, is an ill-conceived way to enact parental controls and will lead to an increase in digitally-mediated abuse. The government should immediately take this application out of the public domain and work on developing alternate child protection policies that are not rooted in distrust and surveillance.

If you are affected by stalkerware there are some resources available here:
https://stopstalkerware.org/information-for-survivors/
https://stopstalkerware.org/resources/

Appendix

Our analysis covered two apps based in India, SafeNet and OneMonitar, and five other apps, Hoverwatch, TheTruthSpy, Cerberus, mSpy and FlexiSPY. All samples were directly obtained from the developer’s websites. The details of the samples are as follows:

Name

File name

Version

Date sample was obtained

SHA-1 Hash

SafeNet

Safenet_Child.apk

0.15

16th March, 2024

d97a19dc2212112353ebd84299d49ccfe8869454

OneMonitar

ss-kids.apk

5.1.9

19th March, 2024

519e68ab75cd77ffb95d905c2fe0447af0c05bb2

Hoverwatch

setup-p9a8.apk

7.4.360

5th March, 2024

50bae562553d990ce3c364dc1ecf44b44f6af633

TheTruthSpy

TheTruthSpy.apk

23.24

5th March, 2024

8867ac8e2bce3223323f38bd889e468be7740eab

Cerberus

Cerberus_disguised.apk

3.7.9

4th March, 2024

75ff89327503374358f8ea146cfa9054db09b7cb

mSpy

bt.apk

7.6.0.1

21st March, 2024

f01f8964242f328e0bb507508015a379dba84c07

FlexiSPY

5009_5.2.2_1361.apk

5.2.2

26th March, 2024

5092ece94efdc2f76857101fe9f47ac855fb7a34

We analysed the network activity of these apps to check what web servers they send their data to. With increasing popularity of Content Delivery Networks (CDNs) and cloud infrastructure, these results may not always give us an accurate idea about where these apps originate, but can sometimes offer useful information:

Name Domain IP Address[26] Country ASN Name and Number

SafeNet safenet.family 103.10.24.124 India Amrita Vishwa Vidyapeetham, AS58703

OneMonitar onemonitar.com 3.15.113.141 United States Amazon.com, Inc., AS16509

OneMonitar api.cp.onemonitar.com 3.23.25.254 United States Amazon.com, Inc., AS16509

Hoverwatch hoverwatch.com 104.236.73.120 United States DigitalOcean, LLC, AS14061

Hoverwatch a.syncvch.com 158.69.24.236 Canada OVH SAS, AS16276

TheTruthSpy thetruthspy.com 172.67.174.162 United States Cloudflare, Inc., AS13335

TheTruthSpy protocol-a946.thetruthspy.com 176.123.5.22 Moldova ALEXHOST SRL, AS200019

Cerberus cerberusapp.com 104.26.9.137 United States Cloudflare, Inc., AS13335

mSpy mspy.com 104.22.76.136 United States Cloudflare, Inc., AS13335

mSpy mobile-gw.thd.cc 104.26.4.141 United States Cloudflare, Inc., AS13335

FlexiSPY flexispy.com 104.26.9.173 United States Cloudflare, Inc., AS13335

FlexiSPY djp.bz 119.8.35.235 Hong Kong HUAWEI CLOUDS, AS136907

To understand whether commercial antivirus solutions are able to categorise stalkerware apps as malicious, we used a tool called VirusTotal, which aggregates checks from over 70 antivirus scanners.[27] We uploaded hashes (i.e. unique signatures) of each sample to VirusTotal and recorded the total number of detections by various antivirus solutions. We compared our results to a similar study by Citizen Lab in 2019 [28] that looked at a similar set of apps to identify changes in detection rates over time.

Product

VirusTotal Detections (March 2024)

VirusTotal Detections (January 2019) (By Citizen Lab)

SafeNet [29]

0/67 (0 %)

N/A

OneMonitar [30]

17/65 (26.1%)

N/A

Hoverwatch

24/58 (41.4%)

22/59 (37.3%)

TheTruthSpy

38/66 (57.6%)

0

Cerberus

8/62 (12.9%)

6/63 (9.5%)

mSpy

8/63 (12.7%)

20/63 (31.7%)

Flexispy [31]

18/66 (27.3%)

34/63 (54.0%)

We also checked if Google’s Play Protect service [32], a malware detection tool that is built-in to Android devices using Google’s Play Store. These results were also compared with similar checks performed by Citizen Lab in 2019.

Product

Detected by Play Protect (March 2024)

Detected by Play Protect (January 2019) (By Citizen Lab)

SafeNet

no

N/A

OneMonitar

yes

N/A

Hoverwatch

yes

yes

TheTruthSpy

yes

yes

Cerberus

yes

no

mSpy

yes

yes

Flexispy

yes

yes

Endnotes

1. Definition adapted from Coalition Against Stalkerware, https://stopstalkerware.org/

2. https://web.archive.org/web/20240316060649/https://safenet.family/

3. https://www.hindustantimes.com/india-news/itministry-tests-parental-control-app-progress-to-be-reviewed-today-101710702452265.html

4. https://www.hindustantimes.com/india-news/schools-must-raise-awareness-about-parental-control-in-internet-usage-says-dot-101710840561172.html

5. https://github.com/AssoEchap/stalkerware-indicators/blob/master/README.md

6. https://cybernews.com/privacy/difference-between-parenting-apps-and-stalkerware/

7. https://timesofindia.indiatimes.com/blogs/voices/shepherding-children-in-the-digital-age/

8. https://blog.avast.com/stalkerware-and-children-avast

9. https://safety.google/families/parental-supervision/

10. https://support.apple.com/en-in/105121

11. R. Chatterjee et al., "The Spyware Used in Intimate Partner Violence," 2018 IEEE Symposium on Security and Privacy (SP), 2018, pp. 441-458.

12. https://www.computerweekly.com/news/252492575/Use-of-abusive-stalkerware-against-women-skyrocketed-in-2020

13. D. Freed et al., "Digital technologies and intimate partner violence: A qualitative analysis with multiple stakeholders", PACM: Human-Computer Interaction: Computer-Supported Cooperative Work and Social Computing (CSCW), vol. 1, no. 2, 2017.

14. https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2024/03/07160820/The-State-of-Stalkerware-in-2023.pdf

15. https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2023/03/07152747/EN_The-State-of-Stalkerware_2022.pdf

16. https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2022/04/12075509/EN_The-State-of-Stalkerware-2021.pdf

17. https://media.kasperskycontenthub.com/wp-content/uploads/sites/100/2020/03/25175212/EN_The-State-of-Stalkerware-2020.pdf

18. https://techcrunch.com/pages/thetruthspy-investigation/

19. https://www.thenewsminute.com/atom/avast-finds-20-rise-use-spying-and-stalkerware-apps-india-during-lockdown-129155

20. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10071919/

21. https://citizenlab.ca/docs/stalkerware-holistic.pdf

22. https://docs.mvt.re/en/latest/

23. https://tiny-check.com/

24. https://github.com/AssoEchap/stalkerware-indicators/pull/125

25. https://stopstalkerware.org/2023/05/15/report-shows-stalkerware-is-not-declining/

26. IP information provided by https://ipinfo.io/

27. https://docs.virustotal.com/docs/how-it-works

28. https://citizenlab.ca/docs/stalkerware-holistic.pdf

29. Sample was not known to VirusTotal, it was uploaded at the time of analysis

30. Sample was not known to VirusTotal, it was uploaded at the time of analysis

31. Sample was not known to VirusTotal, it was uploaded at the time of analysis

32. https://developers.google.com/android/play-protect

For more details visit http://editors.cis-india.org/internet-governance/blog/india2019s-parental-control-directive-and-the-need-to-improve-stalkerware-detection

DoT’s order to trace server IP addresses will lead to unintended censorship

divyank — 2024-01-25T11:19:27Z

This post was reviewed and edited by Isha Suri and Nishant Shankar.

In December 2023, the Department of Telecommunications (DoT) issued instructions to internet service providers (ISPs) to maintain and share a list of “customer owned” IP addresses that host internet services through Indian ISPs so that they can be immediately traced in case “they are required to be blocked as per orders of [the court], etc”.

For the purposes of the notification, tracing customer-owned IP addresses implies identifying the network location of a subset of web services that possess their own IP addresses, as opposed to renting them from the ISP. These web services purchase IP Transit from Indian ISPs in order to connect their servers to the internet. In such cases, it is not immediately apparent which ISP routes to a particular IP address, requiring some amount of manual tracing to locate the host and immediately cut off access to the service. The order notes that “It has been observed that many times it is time consuming to trace location of such servers specially in case the IP address of servers is customer owned and not allocated by the Licensed Internet Service Provider”.

This indicates that, not only is the DoT blocking access to web services based on their IP addresses, but is doing so often enough for manual tracing of IP addresses to be a time consuming process for them.

While our legal framework allows courts and the government to issue content takedown orders, it is well documented that blocking web services based on their IP addresses is ineffectual and disruptive. An explainer on content blocking by the Internet Society notes, “Generally, IP blocking is a poor filtering technique that is not very effective, is difficult to maintain effectively, has a high level of unintended additional blockage, and is easily evaded by publishers who move content to new servers (with new IP addresses)”. The practice of virtual hosting is very common on the internet, which entails that a single web service can span multiple IP addresses and a single IP address can be shared by hundreds, or even thousands, of web services. Blocking access to a particular IP address can cause unrelated web services to fail in subtle and unpredictable ways, leading to collateral censorship. For example, a 2022 Austrian court order to block 11 IP addresses associated with 14 websites that engaged in copyright infringement rendered thousands of unrelated websites inaccessible.

The unintended effects of IP blocking have also been observed in practice in India. In 2021, US-based OneSignal Inc. approached the Delhi High Court challenging the blockage of one of its IP addresses by ISPs in India. With OneSignal being an online marketing company, there did not appear to be any legitimate reason for it to be blocked. In response to the petition the Government said that they had already issued unblocking orders for the IP address. There have also been numerous reports by internet users of inexplicable blocking of innocuous websites hosted on content delivery networks (which are known to often share IP addresses between customers).

We urge the ISPs, government departments and courts issuing and implementing website blocking orders to refrain from utilising overly broad censorship mechanisms like IP blocking which can lead to failure of unrelated services on the internet.

For more details visit http://editors.cis-india.org/internet-governance/blog/dot2019s-order-to-trace-server-ip-addresses-will-lead-to-unintended-censorship

Detecting Encrypted Client Hello (ECH) Blocking

divyank — 2023-09-05T12:10:47Z

A new internet protocol makes it harder for internet service providers to censor websites. We made a technical intervention to check if censors are interfering with its deployment.

This blogpost was edited by Torsha Sarkar.

The Transport Layer Security (TLS) protocol, which is widely recognised as the lock sign in a web browser’s URL bar, encrypts the contents of internet connections when an internet user visits a website so that network intermediaries (such as Internet Service Providers, Internet Exchanges, undersea cable operators, etc.) cannot view the private information being exchanged with the website.

TLS, however, suffers from a privacy issue – the protocol transmits a piece of information known as the Server Name Indication (or SNI) which contains the name of the website a user is visiting. While the purpose of TLS is to encrypt private information, the SNI remains unencrypted – leaking the names of the websites internet users visit to network intermediaries, who use this metadata to surveil internet users and censor access to certain websites. In India, two large internet service providers – Reliance Jio and Bharti Airtel – have been previously found using the SNI field to block access to websites.

Encrypted Client Hello (or ECH) is a new internet protocol that has been under development since 2018 at the Internet Engineering Task Force (IETF) and is now being tested for a small percentage of internet users before a wider rollout. It seeks to address this privacy limitation by encrypting the SNI information that leaks the names of visited websites to internet intermediaries. The ECH protocol significantly raises the bar for censors – the SNI is the last bit of unencrypted metadata in internet connections that censors can reliably use to detect which websites an internet user is visiting. After this protocol is deployed, censors will find it harder to block websites by interfering with network connections and will be forced to utilise blocking methods such as website fingerprinting and man-in-the-middle attacks that are either expensive and less accurate, or unfeasible in most cases.

We have been tracking the development of this privacy enhancement. To assist the successful deployment of the ECH protocol, we contributed a new censorship test to the Open Observatory for Network Interference (OONI) late last year. The new test attempts to connect to websites using the ECH protocol and records any interference from censors to the connection. As censors in some countries were found blocking a previous version of the protocol entirely, this test gives important early feedback to the protocol developers on whether censors are able to detect and block the protocol.

We conducted ECH tests during the first week of September 2023 from four popular Indian ISPs, namely Airtel, Atria Convergence Technologies (ACT), Reliance Jio, and Vodafone Idea, which account for around 95% of the Indian internet subscriber base. The results indicated that ECH connections to a popular website were successful and are not currently being blocked. This was the expected result, as the protocol is still under development. We will continue to monitor for interference from censors closer to the time of completion of the protocol to ensure that this privacy enhancing protocol is successfully deployed.

For more details visit http://editors.cis-india.org/internet-governance/blog/detecting-encrypted-client-hello-ech-blocking

Security of Open Source Software : A Survey of Technical Stakeholders’ Perceptions and Actions

divyank — 2023-04-13T06:02:20Z

For more details visit http://editors.cis-india.org/openness/security-of-open-source-software-a-survey-of-technical-stakeholders2019-perceptions-and-actions

Securing Our Dependence on Code Reuse in Software

divyank — 2023-04-13T05:47:00Z

Dividing and breaking up a software project into smaller modules with functionality that can be reused to build other software is an increasingly common practice in software development today. We examine our infrastructural dependence on reuse of open-source software (OSS) components, examine the unique security risks posed by the widespread reuse of code, and survey systemic solutions to securing code reuse.

Dividing and breaking up a software project into smaller modules with functionality that can be reused to build other software is an increasingly common practice in software development today. Much of this reuse happens in the form of open-source software (OSS) packages, i.e. software whose source code is openly available on the internet with a permissive licence which allows for its reuse and modification. A study that analysed the composition of over 2400 commercial software applications from seventeen industries found that, on average, 78% of the code used to build them was open-source software – indicating that code reuse is not merely supplemental, but foundational to software development processes today. Relying on domain experts to build and maintain the functionality that is ancillary to a software application’s primary purpose saves effort and allows application developers to focus on their own work domains. For instance, a developer building a video conferencing application – such as Zoom – may reuse an open-source library called ffmpeg to encode and decode video streams, or another open-source component, OpenSSL, to encrypt and decrypt the encoded streams as they are transmitted over the internet, rather than reimplementing this functionality from scratch.

Despite the well-known practical benefits of code reuse and its prevalence in all of the digital products and services our society relies on, several security incidents in widely used OSS projects have shown that such projects are often underfunded and under-maintained. The ‘Heartbleed’ vulnerability most clearly illustrates this. In 2014, a security vulnerability in the OpenSSL software library – which is widely used to encrypt web traffic – affected about one-fifth of the servers on the internet. Malicious actors could have exploited this vulnerability to decrypt all of the data that these servers handled and even impersonated them.

In this report, we examine our infrastructural dependence on reuse of OSS components and develop an understanding of the security risks posed by the widespread reuse of code that is developed and maintained by untrusted individuals and organisations that have no obligation to provide these services or any subsequent support.

We present an analysis of common security issues in OSS packages, with a focus on the unique security issues that arise in the tooling and processes used to store, distribute and operate reused code. Finally, we survey solutions and frameworks which seek to address some of these issues on a systemic level.

This report is primarily aimed at regulators, technical decision-makers and organisations invested in furthering research in this area. It can also serve as a starting point for software developers who want to learn about the common security pitfalls of using OSS components and how they can avoid them.

Click to download the full report

For more details visit http://editors.cis-india.org/openness/securing-our-dependence-on-code-reuse-in-software

Securing Our Dependence on Code Reuse.pdf

divyank — 2023-04-12T11:40:31Z

For more details visit http://editors.cis-india.org/openness/Securing%20Our%20Dependence%20on%20Code%20Reuse.pdf

CensorWatch: On the Implementation of Online Censorship in India

divyank — 2023-03-15T11:58:56Z

Results from a nation-wide empirical study on web censorship

Abstract: State authorities in India order domestic internet service providers (ISPs) to block access to websites and services. We developed a mobile application, CensorWatch, that runs network tests to study inconsistencies in how ISPs conduct censorship. We analyse the censorship of 10,372 sites, with measurements collected across 71 networks from 25 states in the country. We find that ISPs in India rely on different methods of censorship with larger ISPs utilizing methods that are harder to circumvent. By comparing blocklists and contextualising them with specific legal orders, we find concrete evidence that ISPs in India are blocking different websites and engaging in arbitrary blocking, in violation of Indian law.

The paper authored by Divyank Katira, Gurshabad Grover, Kushagra Singh and Varun Bansal appeared as part of the conference on Free and Open Communications on the Internet (FOCI '23) and can be accessed here.

The authors would like to thank Pooja Saxena and Akash Sheshadri for contributing to the visual design of Censorwatch; Aayush Rathi, Amber Sinha and Vipul Kharbanda for their valuable legal inputs; Internet Freedom Foundation for their support; ipinfo.io for providing free access to their data and services. The work was made possible because of research grants to the Centre for Internet and Society from the MacArthur Foundation, Article 19, the East-West Management Institute and the New Venture Fund. Gurshabad Grover’s contributions were supported by a research fellowship from the Open Tech Fund.

For more details visit http://editors.cis-india.org/internet-governance/blog/censorwatch-on-the-implementation-of-online-censorship-in-india

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

Name	Domain	IP Address[26]	Country	ASN Name and Number
SafeNet	safenet.family	103.10.24.124	India	Amrita Vishwa Vidyapeetham, AS58703
OneMonitar	onemonitar.com	3.15.113.141	United States	Amazon.com, Inc., AS16509
OneMonitar	api.cp.onemonitar.com	3.23.25.254	United States	Amazon.com, Inc., AS16509
Hoverwatch	hoverwatch.com	104.236.73.120	United States	DigitalOcean, LLC, AS14061
Hoverwatch	a.syncvch.com	158.69.24.236	Canada	OVH SAS, AS16276
TheTruthSpy	thetruthspy.com	172.67.174.162	United States	Cloudflare, Inc., AS13335
TheTruthSpy	protocol-a946.thetruthspy.com	176.123.5.22	Moldova	ALEXHOST SRL, AS200019
Cerberus	cerberusapp.com	104.26.9.137	United States	Cloudflare, Inc., AS13335
mSpy	mspy.com	104.22.76.136	United States	Cloudflare, Inc., AS13335
mSpy	mobile-gw.thd.cc	104.26.4.141	United States	Cloudflare, Inc., AS13335
FlexiSPY	flexispy.com	104.26.9.173	United States	Cloudflare, Inc., AS13335
FlexiSPY	djp.bz	119.8.35.235	Hong Kong	HUAWEI CLOUDS, AS136907

Product	VirusTotal Detections (March 2024)	VirusTotal Detections (January 2019) (By Citizen Lab)
SafeNet [29]	0/67 (0 %)	N/A
OneMonitar [30]	17/65 (26.1%)	N/A
Hoverwatch	24/58 (41.4%)	22/59 (37.3%)
TheTruthSpy	38/66 (57.6%)	0
Cerberus	8/62 (12.9%)	6/63 (9.5%)
mSpy	8/63 (12.7%)	20/63 (31.7%)
Flexispy [31]	18/66 (27.3%)	34/63 (54.0%)

Product	Detected by Play Protect (March 2024)	Detected by Play Protect (January 2019) (By Citizen Lab)
SafeNet	no	N/A
OneMonitar	yes	N/A
Hoverwatch	yes	yes
TheTruthSpy	yes	yes
Cerberus	yes	no
mSpy	yes	yes
Flexispy	yes	yes